In this section:
As communications technologies advance, new security concerns are constantly created. However, new techniques are also developed to address those concerns to stay ahead of evoving threats and risks and also ensuring the compliance.
The security goals of the SBC include:
To meet these security goals, the SBC is modeled on B2BUA (Back-to-Back User Agent) architecture. In this model, all signaling and media are received and terminated at the SBC and then regenerated on the other interface of the SBC. This model prevents malformed messages or message sequences, message floods, and many more from propagating from untrusted/unmanaged interfaces to networks and systems that are being protected by the SBC. It also provides topology hiding and supports the application by the SBC of policy-based controls on access and resource utilization.
According to the security principles, the SBC includes the following factors:
The SBC is based on a Back-to-Back User Agent (B2BUA) architecture which means that incoming signaling and media are deconstructed, processed, and then reconstructed for forwarding to downstream devices. This model protects downstream devices from malicious content in these messages.
Closely related to the B2BUA architecture are "disjoint networking" and "topology hiding". Disjoint networking refers to the SBC support of separate, operator-defined groups of network interfaces for connection to any number of distinct signaling and/or media networks. No communication happens between these separate domains except as mediated by the SBC. Topology hiding occurs because the IP addresses and FQDNs in the signaling and media messages are removed and replaced as these messages propagate through the SBC. This prevents IP addressing and topology information about a private network from propagating to external VoIP/UC peers.
All these mechanisms scale to very high levels.
The security mechanisms and security protocols supported by the SBC for access and interconnect traffic are as follows:
For access:
For interconnect:
For OAM (https, ssh, sftp, snmpv3), including both access and interconnect:
The Ribbon SBC provides admission control at different layers:
The packet-aware admission control operates at wire rate on all network interfaces simultaneously and protects the system from brute-force DoS attack.
VoIP-aware admission control is aware of application layer constructs such as calls, peer groups, and many more. This can impose nuanced limits on the consumption of resources by particular subscribers or peers or groups thereof.
The packet admission controls screen all arriving IP packets by their layer 3 and layer 4 headers and related information such as arrival interface.The packets are accepted or discarded based on their match with various static and dynamic rules defining the acceptable signaling and media communications. The packets that appear acceptable are nonetheless rate limited to guard against DoS attack on the system and over-consumption of resources by certain peers. The media packets must match the “pinhole” of an established session and fall within the expected arrival rate for the negotiated codec. The signaling packets are addressed to a local signaling port and their source must comport with established policy. The packet layer admission controls ensures that even under a wire-rate bombardment of legitimate or illegitimate packets, the system as a whole continues to function and deliver service to trusted peers.
The application layer admission controls (commonly referred to as CAC controls) are applied simultaneously at several levels of granularity that is per individual remote device and per various groupings of remote devices. These controls limit network usage by such measures as calls per second, registrations per second, total simultaneous calls, total media bandwidth, and many more Each identified group of remote devices can be individually limited based on existing business arrangements. Hierarchies of groups may be created to support oversubscription while still protecting the network. Emergency calls or calls by priority callers are identified and given prioritized access to network resources.
For each call leg established through signaling, the SBC creates a table entry in its network processor hardware section, which classify and police arriving packets at full line rate on all interfaces simultaneously. Arriving media packets that match such a table entry are accepted, but policed to an arrival rate expected for the signaled codec and packetization interval. Arriving packets that do not match such an entry do not belong to any current call and are discarded. The system validates the arrival interface, the destination address, and the port number, and optionally the source address and port number for each arriving packet. When SRTP is used, the system also performs a cryptographic integrity check and anti-replay check on each arriving media and SRTCP packet, at full wire rate. When a call is torn down through the signaling plane, the table entries for all associated media legs are removed from the system, which disallows reception and forwarding of any further media packets for that call.
For each MSRP data flow leg established through signaling, the SBC creates a table entry in its network processor hardware section, which can classify and police arriving packets at full line rate on all interfaces simultaneously. The Arriving TCP media packets that do not match such an entry are discarded. The Arriving MSRP data packets that match such a table entry are accepted, but metered against a reasonable arrival rate. Packets received in excess of the arrival rate will be processed anyway, if there is adequate bandwidth available on the interface. When a call is torn down through the signaling plane, the table entries for associated MSRP data flow legs are removed from the system, which disallows reception and forwarding of any further packets for that call.
The SBC 5xx0/5400/7000 systems provide line-rate DoS/DDoS and Rogue RTP protection as described above. These protections ensure that the overall set of media packets arriving on a given call leg is well formed as far as the IP and UDP headers and the expected arrival rate are concerned. For media streams not processed for transcoding, tone detection,and many more, there is no further validation. For the other streams, the RTP packets are deconstructed by the SBC's Digital Signal Processing (DSP) devices and any malformed RTP headers detected will lead to packet discard. This includes validation of the RTP version, RTP payload type, and some size verification. Malformed encoded audio is not specifically detected, but when processed through the DSPs for transcoding, it will be modified to a valid audio sample.
The SBC applies its standard IP and TCP layer validations to MSRP data, and non-conforming packets are discarded. The SBC does not inspect or process the MSRP layer data (either the MSRP headers or the payload data); that data is merely forwarded.
For access (registration-based) scenarios, the SBC 5xx0/5400/7000 platforms identify, classify, and regulate each individual incoming packet stream. This is done at wire rate on all interfaces simultaneously. When a new incoming non-media stream is detected, it is expected to be a UDP packet containing a REGISTER or a TCP handshake preparatory to sending a REGISTER. The stream is allotted a small allowance of incoming packets the SBC will accept if the corresponding REGISTER requests is challenged. When the registrar recognizes the REGISTER and sends back a challenge, that challenge is propagated to the client and an incremental allowance of incoming packets from the client is permitted at the SBC. Once the registration is successfully authenticated by the registrar, that client is given an ongoing allowed rate of permitted incoming signaling packets commensurate with their service level.
For peering scenarios the SBC is generally configured in advance with some knowledge of each peer and the SBC sets up an ongoing allowed rate of permitted incoming signaling packets from the peer. The same wire rate packet classification and rate limiting is then applied.
In all cases, incoming media (RTP) packets are only accepted if they match a particular call leg previously established through the signaling plane. The incoming packet rate on each media leg is enforced based on the appropriate rate for the selected codec.
Additionally, the SBC also supports a dynamic blacklist feature that detects when endpoints are sending malformed SIP messages or trying to brute-force registration credentials and blocks traffic from those endpoints for a configured period of time.
The access clients become "trusted" through an authenticated registration while interconnect peers become trusted through a configuration action. The incoming packet streams from these trusted entities are classified and identified for acceptance, but still rate limited based on their expected traffic to guard against overspending by even a trusted peer.
Incoming packets from as-yet-untrusted sources are accepted at limited rates as provisioned. This is used to handle the initial packets from not-yet-authenticated access clients as well as any traffic from interconnect peers that have not been pre-configured.
The rate limiting of the incoming packets happens in two tiers – one per peer entity and another level in aggregate. The overall result of the classification and rate limiting is that packets that appear to be legitimate are accepted, unexpected packets are discarded, and the rate of accepted packets is strictly controlled to prevent deleterious impact on the system.
The management ports on the SBC 5xx0/5400/7000 are protected by the same wire-rate-capable, NP-based ACL and policing mechanisms that are used on the packet ports. Any arriving packet that does not match a "permit" ACL rule is discarded. Packets that do match a permit rule are rate limited according to policing parameters associated with that rule. The Microflow rules are not currently implemented for OAM traffic. For more information, see Secure Network Configuration
Most customers deploy the SBC 5xx0/5400/7000 with the management ports connected to some non-public, company-internal, managed network that is dedicated to OAM uses (that is not connecting these ports to the Internet. There are user with firewalls separating various parts of their OAM network, and they manage the SBC 5xx0/5400/7000 through those firewalls without any issues.
Ribbon does not recommend connecting the Management ports directly to a public network due to risks such as password guessing.
The SBC has the ability to perform at line rate even while security and complex call-processing functions are enabled on the system. Ribbon used independent third-party verification of device performance, including with relevant security mechanisms enabled with testing done through Miercom.
The reports may be accessed on the Miercom website at: