Will it be possible to use Credit-Control-Failure-Handling AVP in Gx interface.
If PCRF goes down or due to network problem, so will it be possible that PCEF can use a Credit-Control-Failure-Handling AVP to try the failover. Is this an allowed behavior in Gx-Interface as per 3GPP Standards.
Thanks
Underlying SCTP layer carrying the Diameter traffic can take care of the Failover, where multi-homed SCTP path and session failure detection mechanisms (Heartbeat) can actively monitor the connectivity of the session and if there is any failure it can automatically choose the alternate path.
Credit-Control-Failure-Handling is applicable to Gy Interface only.
Related
As I know, in BLE Secure-Connections Only (SCO) mode, all incoming and outgoing traffic between two paired devices is both authenticated and encrypted. However, BLE also allows to assign individual access permissions to attributes.
Thus, I am wondering whether the BLE specification allows the existence of attributes that neither require authentication nor encryption if two devices are communicating in SCO mode. To give a concrete example: Can device A have an attribute that does not require security and can device B access that attribute without security?
Note that the Secure Connections Only mode is just a high-level "concept" in GAP that doesn't really exist on the ATT/GATT protocol level.
This is all in the spec there is to say about it (Bluetooth Core specification v5.3, Vol 3 Part C (GAP)):
10.2.4 Secure Connections Only mode
A device may be in a Secure Connections Only mode. When in Secure Connections Only mode only security mode 1 level 4 shall be used except for services that only require security mode 1 level 1.
The device shall only accept new outgoing and incoming service level connections for services that require Security Mode 1, Level 4 when the remote device supports LE Secure Connections and authenticated pairing is used.
Mode 1 level 1 means unencrypted, unauthenticated. Mode 1 level 4 means that LE Secure Connections are used with authenticated pairing, i.e. not "LESC Just Works".
So to claim that your device is in SCO mode, you can have a mix of services that don't require any encryption at all and services that only allow to be used when authenticated LESC is used. The services that don't require any encryption can be used at anytime, both when the link is encrypted and when it is unencrypted. The other services can only be used when the connection is encrypted with authenticated LESC.
If I interpret it correctly, you can therefore not have a GATT service with multiple characteristics such that one characteristic is accessable without encryption and one other characteristic is only accessable with encryption. In that case you need to split it up into two services, one without encryption requirements and one with authenticated LESC as requirement.
Anyway, "SCO mode" is just abstract terminology that doesn't have any implications in practice except that it categorises service structures. Basically what you can do with it is to print a label on your product "certified to support SCO mode". It can also be useful as a flag in Bluetooth stacks you can set that validates that the local GATT db fulfills the requirements for SCO.
I have a Client and Server programs communicating on TCP, implementing IEC-60870-5-104 protocol on the application layer. I am sniffing a copy of all traffic between them,
How do I exactly replicate the IP and TCP layer functionalities on packets sniffed from libpcap in C ?. like IP-reassembly, Managing out-of-order segments, re-transmission, and duplicate TCP segments and separating PDUs, such that I get the same packet as if I was sniffing on the application layer at the Server. (Also please suggest any Frame-works which helps to do this).
This is a very difficult and involved task. It's what network intrusion detection / deep packet inspection systems do and AFAIK there is no drop-in library that handles it.
Your best bet is to build on an existing system such as Bro or Suricata (or maybe wireshark internals) that is already doing the session tracking, state management, re-assembly, re-ordering, duplicate detection, etc. You can then add your own application layer decoding to operate on the re-assembled data stream provided.
Why ISP's deploy RR in BGP core design and what can be done to ensure traffic patterns never traverse the RR router?
BGP requires that all iBGP speakers be fully meshed. However, this requirement does not scale well when there are many iBGP speakers. Instead of configuring a confederation, you can reduce the iBGP mesh by using a route reflector configuration.
A route reflector is a BGP router that is allowed to break the iBGP loop avoidance rule. Route reflectors can advertise updates received from an iBGP peer to another iBGP peer under specific conditions.
By breaking the rules, route reflectors are used to eliminate the full mesh requirement and allow for building iBGP networks that scale easily and cleanly.
https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/200153-BGP-Route-Reflection-and-Multiple-Cluste.html
RR is deployed to reduce the number of IBGP connections among IBGP routers in one AS. RR design is much more simpler to configure compared to BGP confederation.
http://packetpushers.net/bgp-rr-design-part-2/
http://packetpushers.net/bgp-rr-design-part-1/
I am investigating the types of security available in Bluetooth Low Energy (BLE) related to GATT. More specifically, what kind of operations are done when using gatttool with different security levels specified (low, med, high)? My understanding is that the Security Manager in BLE supports 4 different security properties:
no pairing
pairing with an association model that doesn't support man-in-the-middle (MitM) protections (JustWorks)
pairing with MitM protections (passkey entry, numeric comparison, OOB)
LE Secure Connections pairing.
Are these security properties related to the security levels specified with gatttool or is there some other security feature I missed while reading the Bluetooth Specification?
Edit: I would like to extend my question in order to clarify the issue. How does the 4.2 Bluetooth stack determine whether to use legacy pairing or not? That is to say, if I have a packet capture of two BLE 4.2 devices pairing, how can I tell whether legacy pairing is being used vs pairing that uses ECDH? Does the Secure Connections flag indicate that legacy pairing should not be used or is it just its own mode that ensures FIPS approved algorithms are used?
You are correct but you forget one main threat in BLE communication. Here are the three basic threats :
Man In The Middle (MITM) :
A MITM requires an attacker to have the ability to both monitor and alter or inject messages into a communication channel
Eavesdropping :
Passive Eavesdropping is secretly listening (by using a sniffing device) to the private communication of others without consent
Privacy/Identity tracking :
Since most of the Bluetooth LE advertisement and data packets have the source addresses of the devices that are sending the data, third-party devices could associate these addresses to the identity of a user and track the user by that address
The quotes come from developer.bluetooth.org.
You already mentioned the protections against MitM and Eavesdropping, however there is still the problem of identity tracking.
The protection against identity tracking is to use a MAC address that cannot be linked to the same device through time, i.e. a MAC address that changes (typically every 15 minutes). There are four types of MAC address :
Public address : This address is unencrypted and contains your company unique ID and your device ID. It's unsafe since it does not change through time.
Random static address : This address is random (and known as random thanks to flags inside) and unencrypted. Once it does change, you loose the ability to reconnect with the devices that already knows you, you've got to restart the connection from scratch.
Random resolvable private address : This address can be resolved by the devices that know its IRK, a shared secret between the devices. As for the static random address it changes often but is always resolvable. It's the most common option since it preserves privacy and allow to restore a connection.
Random non-resolvable private address : This address cannot be resolved. The Core Spec doesn't say that much about it and it seems not to be very common. The difference with the static address is that it is not stored since it's a private address (i.e. a device doesn't expect to be able to restore a connection with a private address device).
This is explained in BLE Core Spec 4.2 Vol. 3 Part C 15.1.1 Bluetooth Device Address Types.
Concerning the security level, I don't know gatttool but I will assume it's somehow similar to nRF Connect/Master Control Panel or LightBlue. What you see here is probably the security level associated with each attribute. There are four security levels and they can be different for each attribute :
Mode 1 Level 1 :
No encryption required. The attribute is accessible on a plain-text, non-encrypted connection.
Mode 1 Level 2 :
Unauthenticated encryption required. The connection must be encrypted to access this attribute, but the encryption keys do not need to be authenticated (although they can be).
Mode 1 Level 3 :
Authenticated encryption required. The connection must be encrypted with an authenticated key to access this attribute.
Mode 1 Level 4 :
Authenticated LE Secure Connections pairing with encryption. The connection must be encrypted using the Secure Connection Pairing, which was introduced in Bluetooth LE since version 4.2.
The definitions of modes 1 level 1-3 come from 'Getting Started with Bluetooth Low Energy' by Robert Davidson, Akiba, Carles Cufi, Kevin Townsend.
The device can also be in a mode called Secure Connection Only in which all its services, except the one in Mode 1 Level 1, can only be accessed in Mode 1 Level 4.
How does the 4.2 Bluetooth stack determine whether to use legacy pairing or not? That is to say, if I have a packet capture of two BLE 4.2 devices pairing, how can I tell whether legacy pairing is being used vs pairing that uses ECDH? Does the Secure Connections flag indicate that legacy pairing should not be used or is it just its own mode that ensures FIPS approved algorithms are used?
During the pairing feature exchange stage, if the Secure Connections (SC) flag is set in the Pairing Request and Pairing Response PDUs, then LE SC is used. It indicates that both devices support LE SC and agree to use it.
If LE SC is used, the logs will show "Pairing Public Key" and the "Pairing DHKey Check" PDUs being exchanged. These are specific to LE SC.
Yes it's correct but you should note that their are still exists security mode,LE security mode 1 and LE security mode 2, which is combined by different security levels. And before Bluetooth 4.2, LE is not secure i.e. you can sniffer the encrypt key at the just beginning of the LE connection.
I have a number of services running on various machines which need to communicate over arbitrary ports. Right now port discovery happens by pushing a config file to each machine which contains mappings of a service-name to a hostname/port combo.
For all the same reasons that DNS works better than manually maintaining an /etc/hosts on each machine, I'd like to have a centralized system to register and lookup these hostname/port combos.
Yes, building a simple version of this system wouldn't take long at all (it's just a key-value store), but ideally the service would be fast, redundant, auto-updating and have fail-over, which would obviously take a bit more time to build from scratch.
I can't imagine I'm the first to need such a tool, but so far my Google-fu has failed me. Is there something out there built for this purpose? Or should I just set up Kyoto Tycoon or ZooKeeper and write a bit of caching/lookup/failover logic myself?
DNS supports SRV records that are designed just for this (service location.)
SRV records are of the following form (courtesy Wikipedia):
_service._proto.name TTL class SRV priority weight port target
service: the symbolic name of the desired service.
proto: the transport protocol of the desired service; this is usually either TCP or UDP.
name: the domain name for which this record is valid.
TTL: standard DNS time to live field.
class: standard DNS class field (this is always IN).
priority: the priority of the target host, lower value means more preferred.
weight: A relative weight for records with the same priority.
port: the TCP or UDP port on which the service is to be found.
target: the canonical hostname of the machine providing the service.
Most modern DNS servers support SRV records.
Avahi advertises services (by port) that each machine offers. (aka Apple's Bonjour)
Not sure if it's exactly what you're looking for, but definately in this vein.
The concept is that each machine would announce what services it is running on each port.
But this is limited to a LAN implementation, which I'm not sure fits your requirements.
To add a little more meat to this answer, here is an example service file for Avahi advertising a webpage:
<?xml version="1.0" standalone='no'?><!--*-nxml-*-->
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
<name replace-wildcards="yes">%h Web Server</name>
<service>
<type>_http._tcp</type>
<port>80</port>
</service>
</service-group>
I personally think zookeeper is a great fit for this use case. Ephemeral nodes mean that registration cleanup is not a problem, freeing you to use dynamic port allocation on the server side and watches will help with rebalancing client->server mappings. That said, using zookeeper for server side registration and using DNS SRV records for client side lookup(using a zookeeper to dns bridge) would work well for most use cases.