In our two previous tutorials, we examined four Session Border Controller (SBC) functions that the IETF's Session Initiation Proposal Investigation (sipping) Working Group documented in its recently issued Internet Draft document titled Requirements from SIP (Session Initiation Protocol) Session Border Control Deployments (see http://www.ietf.org/internet-drafts/draft-ietf-sipping-sbc-funcs-01.txt). (Keep in mind that Internet Draft documents are considered works in progress, and are therefore subject to change.)
The functions we discussed were Topology Hiding, which is designed to maintain the proprietary of the private network topology; Media Traffic Shaping, which modifies the session description messages, thus changing the characteristics of the network traffic (see Part 21); Fixing Capability Mismatches, which corrects minor differences in protocol implementations; and Maintaining SIP-related NAT Bindings, which addresses the issue of transporting VoIP traffic through a Network Address Translation (NAT) device (see Part 23).
This tutorial will examine the three remaining functions: Access Control, Protocol Repair, and Media Encryptionand will conclude our discussion of SBCs.
A big part of the security of any network is controlling access to the networkdetermining what persons or systems may enter the it, and what activities they can perform once they get inside. 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.
Interestingly, this function of the SBC is perhaps more demanding than some of the others, in that a difficulty with the access control function becomes a single point of failure, which could have a serious effect on the communication between networked peers.
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 (yet) take advantage of a new parameter or option that is available in the latest protocol release. When these protocol issues occur, the SBC can repair the protocol messages before sending them on their way. When it performs such a repair, it operates like a proxy server, being liberal in what it receives and accepts, but being strict in what is transmits. An example of this condition would be a SIP INVITE message that requires a simple parameter modification in order for it to be compatible with the version supported on the other side of the SBC. Note that protocol repair is only applicable to the signaling messages, and that the protocol repair function does not constitute protocol conversion, which could be substantially more complex.
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.
With this background into the functions that a SBC should perform, in our next tutorial we will begin a review of various vendors' products.
Copyright Acknowledgement: © 2007 DigiNet Corporation ®, All Rights Reserved
Mark A. Miller, P.E. is President of DigiNet Corporation®, a Denver-based consulting engineering firm. He is the author of many books on networking technologies, including Voice over IP Technologies, and Internet Technologies Handbook, both published by John Wiley & Sons.