SBC Security Strategy

Overview

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. 

Unable to show "metadata-from": No such page "_space_variables"

 SBC Security Architecture

The security goals of the

 include:

• Protecting the operational integrity of the 
  Unable to show "metadata-from": No such page "_space_variables"
• Protecting the confidentiality, integrity, and availability of end-users’ communications

To meet these security goals, the 

 is  modeled on B2BUA (Back-to-Back User Agent) architecture. In this model, all signaling and media are received and terminated at the  and then regenerated on the other interface of the . 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 . It also provides topology hiding and supports the application by the  of policy-based controls on access and resource utilization.

According to the security principles, the

 includes the following factors:

• Defense in depth: The
  Unable to show "metadata-from": No such page "_space_variables"
   uses a layered system of redundant and diverse defenses to facilitate secondary defenses in case the primary ones fail.
• General and adaptable defenses: The
  Unable to show "metadata-from": No such page "_space_variables"
   uses defenses that are as broad as possible to minimize the possibility of circumvention.
• Minimized system: No unnecessary packages or network services are present.
• Least-privilege model: Software processes, operator accounts, and and so forth are given minimum access and privileges needed to accomplish their jobs.
• Detection and response: The
  Unable to show "metadata-from": No such page "_space_variables"
   performs extensive audit and event logging to detect and report on potential attacks and anomalies so that automatic and manual responses are brought to bear.
• Hardened code: The
  Unable to show "metadata-from": No such page "_space_variables"
   code is carefully developed and reviewed to eliminate defects that create security vulnerabilities.
• Avoid assumptions: No assumptions of "trusted" network interfaces that do not need to be protected.
• Cryptographic protection: The
  Unable to show "metadata-from": No such page "_space_variables"
   includes robust cryptographic protection for external interfaces.

High Level Protection Summary (

Unable to show "metadata-from": No such page "_space_variables"

)

The

 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

 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 . 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 . 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

 for access and interconnect traffic are as follows:

For access:

• SIP over TLS
• SIP over IPsec with IMS-AKA authentication per 3GPP 33.203
• Secure RTP/RTCP (SRTP/SRTCP). Both Security Descriptions based and DTLS-SRTP key exchange mechanisms are supported.

For interconnect:

• SIP over TLS
• SIP over IPsec with IKEv1 or IKEv2,
• Secure RTP/RTCP (SRTP/SRTCP). Both Security Descriptions based and DTLS-SRTP key exchange mechanisms are supported.

For OAM (https, ssh, sftp, snmpv3), including both access and interconnect:

• the 
  Unable to show "metadata-from": No such page "_space_variables"
   platforms feature a wire-rate DoS and DDoS protection mechanism that classifies, filters, and rate limits all the received packets. This is fully integrated with a flexible, configurable Access Control List (ACL) capability.
• the 
  Unable to show "metadata-from": No such page "_space_variables"
   platforms do not forward media (RTP/RTCP) messages except in conjunction with a valid, current call as established by signaling , sometimes referred as "dynamic media pinholes".
• the 
  Unable to show "metadata-from": No such page "_space_variables"
  feature a powerful, flexible Call Admission Control (CAC) capability that allows control at various levels of granularity over bandwidth used, call rates, registration rates, etc.
• the 
  Unable to show "metadata-from": No such page "_space_variables"
  incorporate overload controls honed through 15 years of carrier deployment. The overload controls cause the system to shed load gracefully when facing resource (CPU, memory, bandwidth) exhaustion.

Access Control and DoS Protection (

Unable to show "metadata-from": No such page "_space_variables"

)

Protection Against DoS/DDoS at Layer 3, Layer 4, and SIP Signaling Levels

The

  provides admission control at different layers:

• Packet-aware admission control at the IP layer
• VoIP-aware admission control at the application layer

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.

DoS/DDoS Protections on the Media Interface

For each call leg established through signaling, the

 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.

DoS/DDoS Protections For MSRP Data Flows

For each MSRP data flow leg established through signaling, the

 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.

Malformed RTP Data Treatment

The 

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.

Malformed MSRP Data Treatment

The

 applies its standard IP and TCP layer validations to MSRP data, and non-conforming packets are discarded. The  does not inspect or process the MSRP layer data (either the MSRP headers or the payload data); that data is merely forwarded.

Dynamically Labeling Sources/Peers as Trusted/Untrusted on the 

Unable to show "metadata-from": No such page "_space_variables"

For access (registration-based) scenarios, the

 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  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 .  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

 is generally configured in advance with some knowledge of each peer and the  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

 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.

Protection of the Management Interfaces/Ports

The management ports on the 

 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

Using a Firewall in Front of the Management Ports

Most customers deploy the 

 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  through those firewalls without any issues.

 does not recommend connecting the Management ports directly to a public network due to risks such as password guessing.

Third-party Verification

The

 has the ability to perform at line rate even while security and complex call-processing functions are enabled on the system.   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:

• http://www.miercom.com/?s=sonus+7000&x=0&y=0
• http://www.miercom.com/?s=sonus+5200&x=0&y=0 and
• http://www.miercom.com/2012/05/sonus-sbc-5100-maintains-high-resiliency-when-exposed-to-attack-traffic/