Session Border Controllers

The ABC’s of SBC’s – definition, characteristics and advantages

The Firewall is the quintessential element providing network security when you need to interconnect with other networks, allowing outgoing traffic and blocking unsolicited incoming traffic. The Firewall is a necessary element, although it is insufficient for security purposes since some threats are hidden from network firewalls within legitimate-appearing traffic, thus resulting in the need for other specialized protective elements such as antivirus or antispam.

The case of Voice over IP is even more special. Firewalls are generally based on NAT but, unfortunately, VoIP connections are incompatible with NAT. A possible solution would be to open exceptions in the NAT Firewall for Voice over IP. This this is not a good idea, though, because it compromises security and does not protect against Denial of Service and intrusion attacks. Intrusion control deserves special mention, not only at the network layer (which a Firewall could perform) but, primarily, at the application layer, aimed at ensuring legitimate call traffic, avoiding attacks, intrusions and fraud. On top of this and to make matters worse, the VoIP sessions are created randomly as calls are established, further complicating control.

A new element is required to address these risks. This element should monitor and be actively involved in the VoIP sessions established between the internal and external network, ensuring that these connections are properly established and that they are legitimate, secure and reliable. This element is the Session Border Controller (SBC).

How are they used?

Session Border Controllers (SBCs) work behind the scenes to ensure that voice, video and data communications flow smoothly and securely between networks and the people who use them. An SBC is part firewall, protecting the network from IP-based attacks; part traffic cop, policing traffic to prevent overloads and directing it over shorter distances to save money; and part peacemaker, ensuring that networked devices from different vendors all speak the same language. Why does a network need an SBC? Because, in order to take advantage of new IP-based communications services like SIP trunking, VoIP, video and Unified Communications, networks must have an SBC in place to provide the requisite security, control and interoperability for these services.

Characteristics and Advantages

While the SBC’s main feature is usually security, it is by no means the only one. The SBC is usually responsible for the following functions, among others:

The experience from various interoperability events shows that different vendors interpret the SIP specifications slightly differently. Especially parts that are specified with the strength of “SHOULD” or “MAY” are often implemented as a “MUST” or ignored completely. This makes the communication between two components from different vendors sometimes impossible. Some SBCs can be configured to overcome some of these issues and to fix certain issues that cause these interoperability problems.

As the result of a SIP session establishment the involved end points will know the IP addresses of where to send and receive media traffic. This means that a user using SIP for calling a PSTN number will know the IP address of the PSTN gateway that is responsible for bridging the VoIP service with the PSTN. Further, during the session establishment phase all the involved proxies will include their addresses in the Via headers.

A malicious user could use this information to either attack an operator’s proxies or even get access to the PSTN gateways directly. By having the ability to contact the PSTN gateways directly, an attacker might be able to misuse any security holes that might exist at the PSTN gateway. This would allow the attacker to initiate calls to the PSTN with the costs being incurred on the operator.

To hide the internal components of an operator, all messages leaving the operator’s network would traverse an SBC. The SBC replaces the addresses of internal components with its own. Hence, headers such as Contact, Via, Record-Route, Route and so on would include the SBCs address only.

Especially on the borders between fixed and mobile networks there might be some need for transcoding the audio or video compression system from one format to the other. Different SBCs offer the possibility to integrate specialized transcoding hardware. For the case when the expected need for transcoding is low, some SBCs offer software based transcoding solutions.

SIP can be transported over UDP, TCP and SCTP. Further, it can work over IPv4 and IPv6. The capabilities of different SIP implementations might vary with this regard. That is, some components could support UDP but not TCP and others prefer to use SCTP. An SBC could solve interworking problems

Like any other Internet-based service VoIP servers can be the target of denial of service attacks. Attacks can be disguised as legitimate VoIP traffic so distinguishing between a denial of service attack or a sudden surge in traffic due to some event is not always possible. Hence, VoIP operators need to incorporate mechanisms that monitor the load and the incoming traffic, identify the overloaded resources and the cause of the overload and react in a manner that will prevent a complete service interruption.

In order to keep the malicious traffic and overload away from the core servers, e.g. applications servers, proxies and PSTN gateways, there are protection mechanisms located at the SBCs.

As the name already implies, SBCs are tasked with controlling which users and what messages can cross the borders of a VoIP infrastructure and use the offered VoIP services.

SBCs arose out of need, catching standards bodies off balance, which created some ambiguity about their roles and limits. Initially SBCs were dedicated devices located at the border between provider networks and their customers or the Internet, evolving towards virtualized networks at times integrated with Firewall and routers. Today it is common to deploy SBC functions even in remote areas to protect the central office’s internal network, especially where there is a direct connection to the internet.

Enterprise SBC’s

Enterprises are increasingly replacing their PBXs with VoIP PBX or are extending their PBX with a VoIP module to benefit from attractive VoIP minute prices. Enterprise SBCs are used to secure the access to the PBX. The enterprise SBC is also expected to secure the communication to the VoIP operator, which is offering the VoIP service to the enterprise.

A VoIP PBX is a special case of a SIP user agent. On the one side the features and supplementary services supported by a PBX exceed by far the features supported by a VoIP phone used by a residential subscriber.

In enterprise environments complex call flows such as call forwarding, music on hold or call parking are used much more often then in residential scenarios. This means that an enterprise SBC will have to deal with more complex call flows than a UNI or NNI SBC.

Further, one PBX will be providing VoIP service for more than one subscriber. A residential subscriber sends a single REGISTER request to inform the registrar server at his VoIP operator about its contact information. Using the same approach in an enterprise scenario would mean that a PBX has to possibly send hundreds if not thousands of registration messages depending on the number of served users in the enterprise. To avoid this avalanche of registrations some specification listed recommends either using static registrations or registration for multiple phones. With the static registration, the registrar server of the VoIP operator would be pre-configured with the address of the PBX and the SIP addresses served by this PBX.

An SBC on the border of the enterprise network will have to support not only the general SIP specifications but also the recommendations for connecting enterprises to an operator.

Solutions for business


Non-Microsoft Applications

© 2019 Copyright - Q-KON South Africa | All Rights Reserved | Disclaimer | Designed and Maintained by Thoughtcorp