SecurityArena

Guide to Practical Info Security!

Who's Online

We have 6 guests online
Print E-mail
Written by Administrator   
Thursday, 01 July 2010 08:07

An Introduction to SBC

Traditionally, IP and data networks have been poor revenue generators as compared to voice services. Even of today when everyone is buzzing about broadband data access, some 70 to 80 percent of service providers revenues comes from voice oriented services. As service providers and operators converge networks to reduce CAPEX and OPEX, they are face with new challenges to maintain there revenues and fulfill legal requirements. Session Border Controllers (SBCs) help to address these challenges by enabling new revenue genrating communication services across IP network boundaries.

In order to understand the SBC better, we decompose the term:
Session is any real-time, interactive voice, video or multimedia communication using application layer IP signalling protocols such as SIP, H.323, MGCP or Megaco/H.248.
Border is any IP-IP network boundry between two service providers or between a service provider and its end users,
while, Control stands for control functions pertaining to security, service assurance and law enforcement requirements to provide legal intercept capabilities.

SBC functions as a demarcation point between two networks, with one designated as an inner network, and other as an outer network.  SBC architecture can be functionally distributed down to two components, a signaling component, and a mediacomponent, that logically and physically connect these inner and outer networks. The signaling component deals with service requests, including connect, disconnect, authentication, and authorization. The media component deals with the transport of the information, including the monitoring of QoS and SLA.

Furthermore, SBC can be deployed in two scenarios: a peering scenario, and an access scenario.

In the peering scenario, the inner and outer networks represent different service providers that are exchanging traffic. The function of the SBC at the inner network is to control access to its network resources, protect its gateways and switching systems from unauthorized access and use, and monitor both the signaling and media traffic.
In the access scenario, the inner network represents a service provider, and the outer network represents the access network. For example, this access network could represent the open Internet, and the inner network could represent a SIP service provider.

Some of the key functions a SBC performs as per its network deployment scenario are discussed here:

Inner Network Topology Hiding

To implement topology hiding, the SBC must remove and rewrite any addressing information that is carried in the SIP message headers (such as the Record-Route and Via entries) that would reveal any internal network topology information. To accomplish this, the SBC operates as a Back-to-Back User Agent (B2BUA). The B2BUA acts as both a User Agent Server  by receiving and processing requests, and as a User Agent Client by generating requests. The SBC receives the signaling information from the inner network, and then generates a new call that is destined for the outer network. During this process, any proprietary topology information (such as might be contained within the Record-Route entry) is replaced with information that only identifies the SBC, and thus protecting the internal network topology.

Content Media Traffic Shaping

Network operators may perform this function for several reasons, including, flexible billing as per service type, enforce the use of specific codecs, ensuring a specified Quality of Service (QoS) level, monitoring the traffic to verify compliance with a Service Level Agreement, or implementing auditing or traffic intercept for law enforcement functions.
To implement traffic shaping, the SBC must access and modify the Session Description Protocol messages that are exchanged between the SIP user-agents. As in Topology Hiding function, the SBC operates as a B2BUA, and is inserted in the media path. It then modifies the session description messages that are carried in the SIP messages, and can receive the media from one user-agent, and relay it to the other user-agent. A similar process is performed in the opposite direction.

Fixing Capability Mismatches

Slight protocol implementation mismatches do occur in real world implementations of various network standards. There could be slight difference in implementation of various signalling protocols by competitor vendors. Simmilarly two interconnecting networks may be using different versions of IP, or differences in the types of codecs that are supported by each network.
Network operators need to fix these capability mismatches so that their communication capabilities can extend past their own networks. To correct these mismatches, the SBC intercept protocol message as it is being passed from the outer network to the inner network. The SBC then examines the message and rewrites the part of message that is not compatible.

Maintaining SIP-related NAT Bindings

Although simple NAT and NAPT functions are often incorporated into security devices, such as a firewalls, but SBCs are require in more specific scenarios. For example, some upper layer protocols, like FTP and SIP embed IP addresses within their upper layer protocol messages, with the intention of using this address information for part of the message processing. In the case of SIP, those addresses may identify the end point (e.g., a softphone) that is being called. And if the destination endpoint address is translated mid stream between the calling and called parties, how do you complete that call?
Moreover firewalls main objective is to protect the private network from unauthorized access, and for this purpose its decision mostly rely on source and destination addresses or the type of traffic that is being sent. However, as a SIP call is comprised of two parts: signaling for the call setup/disconnect, and media transfer of the actual call information. If a SIP station is located behind a firewall/NAT device, an inbound SIP INVITE message will not be successful since the destination address is translated by the NAT. In addition, any inbound media streams will be blocked at the firewall, and if they were allowed to get through, the embedded addresses would identify private, not public (or routable) addresses, thus resulting in packet delivery problems. SBC are designed to provide enhanced NAT functions for SIP.

Signalling and Media Access Control

Access control can be applied to the two key elements of the SBC: to signaling, or to both signaling and media. When access control is applied to the signaling function, then the SBC operates similarly to a proxy server, which receives a service request, and then forwards it on behalf of the requestor. When access control is applied to both signaling and media, then the SBC operates similarly to the media shaping function that we discussed previously, where session description parameters are modified in transit. In either event, the ultimate result is that only media for authorized sessions is allowed to pass through the SBC.
Another aspect of access control is the management of bandwidth on access links. The SBC can compute the potential bandwidth usage requirements based on the codec selections that are stated in the Session Description Protocol (SDP) offer and answer messages. If this result exceeds the available bandwidth, or if an acceptable quality of service could no longer be maintained, then that particular session could be rejected by the SBC.

Protocol Repair

Some signaling messages from nonstandard clients may not be formatted according to the rules defined for that protocol. In other cases, a client may implement an older version of the protocol, and not take advantage of a new parameter or option that is available in the latest protocol release.

Media Encryption

A media encryption/decryption function is performed by the SBC at the edge of the network when the media from the access (outer) network is encrypted, yet the media is transported unencrypted in the inner network. Note that encryption within the inner (provider) network may not be feasible, as the network operator may have a legal obligation to allow legal intercept of the information, which requires that media to be transmitted in the clear.

Last Updated on Thursday, 01 July 2010 09:37
 
Please register or login to add your comments to this article.
 
Joomla 1.5 Templates by Joomlashack