Requirements from SIP (Session Initiation Protocol) Session Border Control Deployments

The term SBC is relatively non-specific, since it is not standardized or defined anywhere. Nodes that may be referred to as SBCs but do not implement SIP are outside the scope of this document. SBCs usually sit between two service provider networks in a peering environment, or between an access network and a backbone network to provide service to residential and/or enterprise customers. They provide a variety of functions to enable or enhance session-based multi-media services (e.g., Voice over IP). These functions include: a) perimeter defense (access control, topology hiding, and DoS prevention and detection); b) functionality not available in the endpoints (NAT traversal, protocol interworking or repair); and c) network management (traffic monitoring, shaping, and QoS). Some of these functions may also get integrated into other SIP elements (like pre-paid platforms, 3GPP P-CSCF , 3GPP I-CSCF, etc). SIP-based SBCs typically handle both signaling and media and can implement behavior which is equivalent to a "privacy service" (as described in) performing both Header Privacy and Session Privacy). SBCs often modify certain SIP headers and message bodies that proxies are not allowed to modify. Consequently, they are, by definition, B2BUAs (Back-to-Back User Agents). The transparency of these B2BUAs varies depending on the functions they perform. For example, some SBCs modify the session description carried in the message and insert a Record-Route entry. Other SBCs replace the value of the Contact header field with the SBCs address, and generate a new Call-ID and new To and From tags.

| signaling |<-|----------> outer | +-----------+ | inner network | | | network | +-----------+ | <------------|->| media |<-|----------> [media] | +-----------+ | +-----------------+ ]]> shows the logical architecture of an SBC, which includes a signaling and a media component. In this document, the terms outer and inner network are used for describing these two networks.

A typical peering scenario involves two network operators who exchange traffic with each other. For example, in a toll bypass application, a gateway in operator A's network sends an INVITE that is routed to the softswitch (proxy) in operator B's network. The proxy responds with a redirect (3xx) message back to the originating gateway that points to the appropriate terminating gateway in operator B's network. The originating gateway then sends the INVITE to the terminating gateway.

+-----+ | SSA | . / 3) 3xx (redir.) | SSB | +-----+ . / /---------------+-----+ . / / +-----+ 1) INVITE +-----+--/ / +-----+ |GW-A1|---------------->| SBC |<---/ 4) INVITE |GW-B1| +-----+ +-----+---------------------->+-----+ . +-----+ . +-----+ |GW-A2| . |GW-B2| +-----+ . +-----+ ]]> illustrates the peering arrangement with a SBC where Operator A is the outer network, and Operator B is the inner network. Operator B can use the SBC, for example, to control access to its network, protect its gateways and softswitches from unauthorized use and DoS attacks, and monitor the signaling and media traffic. It also simplifies network management by minimizing the number ACL (Access Control List) entries in the gateways. The gateways do not need to be exposed to the peer network, and they can restrict access (both media and signaling) to the SBCs. The SBC helps ensure that only media from sessions the SBC authorizes will reach the gateway.

In an access scenario, presented in , the SBC is placed at the border between the access network (outer network) and the operator's network (inner network) to control access to the operator's network, protect its components (media servers, application servers, gateways, etc.) from unauthorized use and DoS attacks, and monitor the signaling and media traffic. Also, since the SBC is call stateful, it may provide access control functions to prevent over subscription of the access links. Endpoints are configured with the SBC as their outbound proxy address. The SBC routes requests to one or more proxies in the operator network.

+-----+ +-------+ | UA2 |<-------------------->| SBC |<----->| proxy |<-- - +-----+ /--->+-----+ +-------+ / +-----+ +-----+ / | UA3 +---+ NAT |<---/ +-----+ +-----+ ]]> The SBC may be hosted in the access network (e.g,. this is common when the access network is an enterprise network), or in the operator network (e.g., this is common when the access network is a residential or small business network). Some endpoints may be behind enterprise or residential NATs. In cases where the access network is a private network, the SBC is the NAT for all traffic. The proxy usually does authentication and/or authorization for registrations and outbound calls. The SBC modifies the REGISTER request so that subsequent requests to the registered address-of-record are routed to the SBC. This is done either with a Path header, or by modifying the Contact to point at the SBC. The scenario presented in this section is a general one, and it applies also to other similar settings. One example from a similar setting is the one where an access network is the open internet, and the operator network is the network of a SIP service provider.

This section lists those functions that are used in SBC deployments in current communication networks. Each subsection describes a particular function or feature, the operators' requirements for having it, explanation of any impact to the end-to-end SIP architecture, and a concrete implementation example. Each section also discusses potential concerns specific to that particular implementation technique. Suggestions for alternative implementation techniques that may be more architecturally compatible with SIP are outside the scope of this document. All the examples given in this section are simplified; only the relevant header lines from SIP and SDP messages are displayed.

Topology hiding consists of limiting the amount of topology information given to external parties. Operators have a requirement for this functionality because they do not want the IP addresses of their equipment (proxies, gateways, application servers, etc) to be exposed to outside parties. This may be because they do not want to expose their equipment to DoS (Denial of Service) attacks, they may use other carriers for certain traffic and do not want their customers to be aware of it or they may want to hide their internal network architecture from competitors or partners. In some environments, the operator's customers may wish to hide the addresses of their equipment or the SIP messages may contain private, non-routable addresses. The most common form of topology hiding is the application of header privacy (see Section 5.1 of ), which involves stripping Via and Record-Route headers, replacing the Contact header, and even changing Call-IDs. However, in deployments which use IP addresses instead of domain names in headers that cannot be removed (e.g. From and To headers), the SBC may replace these IP addresses with its own IP address or domain name.

This functionality is based on a hop-by-hop trust model as opposed to an end-to-end trust model. The messages are modified without subscriber consent and could potentially modify or remove information about the user's privacy, security requirements and higher layer applications which are communicating end-to-end using SIP. Neither user agent in an end-to-end call has any way to distinguish the SBC actions from a Man-In-The-Middle (MitM) attack. Topology hiding function does not work well with Authenticated Identity Management . The Authenticated Identity Management mechanism is based on a hash value that is calculated from parts of From, To, Call-Id, CSeq, Date, and Contact header fields plus from the whole message body. If the authentication service is not provided by the SBC itself, the modification of the forementioned header fields and the message body is in violation with . Some forms of topology hiding are in violation, because they are e.g., replacing the Contact header of a SIP message.

The current way of implementing topology hiding consists of having an SBC act as a B2BUA (Back-to-Back User Agents) and remove all traces of topology information (e.g., Via and Record-Route entries) from outgoing messages. Imagine the following example scenario: The SBC (p4.domain.example.com) receives an INVITE request from the inner network, which in this case is an operator network. The received SIP message is shown in .

Record-Route: Record-Route: ]]> Then the SBC performs a topology hiding function. In this scenario, the SBC removes and stores all existing Via and Record-Route headers, and then inserts a Via and Record-Route header fields with its own SIP URI. After the topology hiding function, the message could appear as shown in .

]]> Like a regular proxy server that inserts a Record-Route entry, the SBC handles every single message of a given SIP dialog. If the SBC loses state (e.g., the SBC restarts for some reason), it may not be able to route messages properly. For example, if the SBC removes Via entries from a request and then restarts, thus losing state, the SBC may not be able to route responses to that request; depending on the information that was lost when the SBC restarted. This is only one example of topology hiding. In some cases, SBCs may modify other headers, including the Contact header field values. The header fields containing identity information is listed in Section 4.1 of .

Media traffic shaping is the function of controlling media traffic. Network operators may require this functionality in order to control the traffic being carried on their network on behalf of their subscribers. Traffic shaping helps the creation of different kinds of billing models (e.g., video telephony can be priced differently to voice-only calls) and it also makes it possible for operators to enforce the usage of selected codecs. Additionally, traffic shaping can be used to implement intercept capabilities where required to support audit or legal obligations. Since the media path is independent of the signaling path, the media may not traverse through the operator's network unless the SBC modifies the session description. By modifying the session description the SBC can force the media to be sent through a media relay which may be co-located with the SBC. This kind of traffic shaping can be done, for example, to ensure a certain QoS (Quality of Service) level. Some operators do not want to reshape the traffic (e.g., allowing only certain codecs), but only to monitor it for collecting statistics and making sure that they are able to meet any business service level agreements with their subscribers and/or partners. The protocol techniques needed for monitoring media traffic are the same as for reshaping media traffic. SBCs on the media path are also capable of dealing with the "lost BYE" issue if either endpoint dies in the middle of the session. The SBC can detect that the media has stopped flowing and issue a BYE to both sides to cleanup any state in other intermediate elements and the endpoints. One possible form of media traffic shaping is that SBCs terminate media streams and SIP dialogs by generating BYE requests. This kind of procedure can take place, for example, in a situation where subscriber runs out of credits.

Implementing traffic shaping in this manner requires the SBC to access and modify the session descriptions (i.e., offers and answers) exchanged between the user-agents. Consequently, this approach does not work if user-agents encrypt or integrity-protect their message bodies end-to-end. Again, messages are modified without subscriber consent, and user-agents do not have any way to distinguish the SBC actions from an attack by a MitM. Furthermore, this is in violation with , see . In this application, the SBC may originate messages that the user may not be able to authenticate as coming from the dialog peer or the SIP Registrar/Proxy.

Traffic shaping may be performed in the following way: The SBC behaves as a B2BUA and inserts itself, or some other entity under the operator's control, in the media path. In practice, the SBC modifies the session descriptions carried in the SIP messages. As a result, the SBC receives media from one user-agent and relays it to the other user-agent and performs the identical operation with media traveling in the reverse direction. As mentioned in , codec restriction is a form of traffic shaping. The SBC restricts the codec set negotiated in the offer/answer exchange between the user-agents. After modifying the session descriptions, the SBC can check whether or not the media stream corresponds to what was negotiated in the offer/answer exchange. If it differs, the SBC has the ability to terminate the media stream or take other appropriate (configured) actions (e.g. raise an alarm). Consider the following example scenario: The SBC receives an INVITE request from the outer network, which in this case is an access network. The received SIP message contains the SDP session descriptor shown in .

In this example, the SBC performs the media traffic shaping function by rewriting the 'm' line, and removing one 'a' line according to some (external) policy. shows the session description after the traffic shaping function.

Media traffic shaping has a problem where the SBC needs to understand the session description protocol and all extensions used by the user-agents. This means that in order to use a new extension (e.g., an extension to implement a new service) or a new session description protocol, SBCs in the network may need to be upgraded in conjunction with the endpoints. It is noteworthy that similar problem, but with header fields, applies to, for example, topology hiding function, see . Certain extensions that do not require active manipulation of the session descriptors to facilitate traffic shaping will be able to be deployed without upgrading existing SBCs, depending on the degree of transparency the SBC implementation affords. In cases requiring an SBC modification to support the new protocol features, the rate of service deployment may be affected.

SBCs fixing capability mismatches enable communications between user-agents with different capabilities or extensions. For example, user-agents on networks which implement SIP differently (for example 3GPP or Packet Cable etc) or those that support different IP versions, different codecs, or that are in different address realms. Operators have a requirement and a strong motivation for performing capability mismatch fixing, so that they can provide transparent communication across different domains. In some cases different SIP extensions or methods to implement the same SIP application (like monitoring session liveness, call history/diversion etc) may also be interworked through the SBC.

SBCs fixing capability mismatches insert a media element in the media path using the procedures described in . Therefore, these SBCs have the same concerns as SBCs performing traffic shaping: the SBC modifies SIP messages without explicit consent from any of the user-agents. This may break end-to-end security and application extensions negotiation. The capability mismatch fixing is a fragile function in the long term. The number of incompatibilities built into various network elements is increasing the fragility and complexity over time. This might lead to a situation where SBCs need to be able to handle a large number of capability mismatches in parallel.

Consider the following example scenario where the inner network is an access network using IPv4 and the outer network is using IPv6. The SBC receives an INVITE request with a session description from the access network:

Then the SBC performs a capability mismatch fixing function. In this scenario the SBC inserts Record-Route and Via headers, and rewrites the 'c' line from the sessions descriptor. shows the request after the capability mismatch adjustment.

Via: SIP/2.0/UDP sip:[2001:DB8::801:201:2ff:fe94:8e10] Via: SIP/2.0/UDP 192.0.2.4 Contact: sip:caller@u1.example.com v=0 o=mhandley 2890844526 2890842807 IN IP4 192.0.2.4 c=IN IP6 2001:DB8::801:201:2ff:fe94:8e10 m=audio 49230 RTP/AVP 96 a=rtpmap:96 L8/8000 ]]> This message is then sent by the SBC to the onward IPv6 network.

NAT traversal in this instance refers to the specific message modifications required to assist a user-agent in maintaining SIP and media connectivity when there is a NAT device located between a user-agent and a proxy/registrar and, possibly, any other user-agent. An SBC performing a NAT (Network Address Translator) traversal function for a user agent behind a NAT sits between the user-agent and the registrar of the domain. NATs are widely deployed in various access networks today, so operators have a requirement to support it. When the registrar receives a REGISTER request from the user-agent and responds with a 200 (OK) response, the SBC modifies such a response decreasing the validity of the registration (i.e., the registration expires sooner). This forces the user-agent to send a new REGISTER to refresh the registration sooner that it would have done on receiving the original response from the registrar. The REGISTER requests sent by the user-agent refresh the binding of the NAT before the binding expires. Note that the SBC does not need to relay all the REGISTER requests received from the user-agent to the registrar. The SBC can generate responses to REGISTER requests received before the registration is about to expire at the registrar. Moreover, the SBC needs to deregister the user-agent if this fails to refresh its registration in time, even if the registration at the registrar would still be valid. Operators implement this functionality in an SBC instead of in the registrar for several reasons: (i) preventing packets from unregistered users to prevent chances of DoS attack, (ii) prioritization and/or re-routing of traffic (based on user or service, like E911) as it enters the network, and (iii) performing a load balancing function or reducing the load on other network equipment. SBCs can also force traffic to go through a media relay for NAT traversal purposes (more about media traffic shaping in ). A typical call has media streams to two directions. Even though SBCs can force media streams from both directions to go through a media relay, it is usually enough to relay only the media from one direction.

This approach to NAT traversal does not work when end-to-end confidentiality or integrity-protection is used. The SBC would be seen as a MitM modifying the messages between the user-agent and the registrar. There is also a problem related to the method how SBCs choose the value for the validity of a registration period. This value should be as high as possible, but it still needs to be low enough to maintain the NAT binding. Typically SBCs do not have any deterministic method for choosing a suitable value.

Consider the following example scenario: The SBC resides between the UA and Registrar. Previously the UA has sent a REGISTER request to Registrar, and the SBC receives the registration response shown in .

;tag=a73kszlfl To: Bob ;tag=34095828jh CSeq: 1 REGISTER Contact: ;expires=3600 ]]> When performing the NAT traversal function, the SBC may re-write the expiry time to coax the UA to re-register prior to the intermediating NAT deciding to close the pinhole. shows a possible modification of the response from .

;tag=a73kszlfl To: Bob ;tag=34095828jh CSeq: 1 REGISTER Contact: ;expires=60 ]]> Naturally also other measures need to be taken in order to enable the NAT traversal, but this example illustrates only one mechanism for preserving the SIP related NAT bindings.

Network operators may wish to control what kind of signaling and media traffic their network carries. There is strong motivation and a requirement to do access control on the edge of an operator's network. Access control can be based on, for example, link-layer identifiers, IP addresses or SIP identities. This function can be implemented by protecting the inner network with firewalls and configuring them so that they only accept SIP traffic from the SBC. This way, all the SIP traffic entering the inner network needs to be routed though the SBC, which only routes messages from authorized parties or traffic that meets a specific policy that is expressed in the SBC administratively. Access control can be applied either only to the signaling, or to both the signaling and media. If it is applied only to the signaling, then the SBC might behave as a proxy server. If access control is applied to both the signaling and media, then the SBC behaves in a similar manner as explained in . A key part of media-layer access control is that only media for authorized sessions is allowed to pass through the SBC and/or associated media relay devices. In environments where there is limited bandwidth on the access links, the SBC can compute the potential bandwidth usage by examining the codecs present in SDP offers and answers. With this information, the SBC can reject sessions before the available bandwidth is exhausted to allow existing sessions to maintain acceptable quality of service. Otherwise, the link could become over subscribed and all sessions would experience a deterioration in quality of service. SBCs may contact a policy server to determine whether sufficient bandwidth is available on a per-session basis.

Since the SBC needs to handle all SIP messages, this function has scalability implications. In addition, the SBC is a single point of failure from an architectural point of view. Although, in practice, many current SBCs have the capability to support redundant configuration, which prevents the loss of calls and/or sessions in the event of a failure on a single node. If access control is performed only on behalf of signaling, then the SBC is compatible with general SIP architectural principles, but if it is performed for signaling and for media, then there are similar problems as described in .

shows a callflow where the SBC is providing both signaling and media access control (ACKs omitted for brevity).

| | | | | | INVITE + SDP | | |----------------------->| | | [Modify the SDP] | | | INVITE + modified SDP | | |----------------------->| | | | | | 200 OK + SDP | | |<-----------------------| | [Modify the SDP] | | | | | 200 OK + modified SDP | | |<-----------------------| | | | | | Media [Media inspection] Media | |<======================>|<======================>| | | | ]]> In this scenario, the SBC first identifies the caller, so it can determine whether or not to give signaling access for the caller. This might be achieved using information gathered during registration, or by other means. Some SBCs may rely on the proxy to authenticate the user-agent placing the call. After identification, the SBC modifies the session descriptors in INVITE and 200 OK messages in a way that the media is going to flow through SBC itself. When the media starts flowing, the SBC can inspect whether the callee and caller use the codec(s) that they had previously agreed on.

SBC are also used to repair protocol messages generated by not-fully-standard clients. Operators may wish to support protocol repair, if they want to support as many clients as possible. It is noteworthy, that this function affects only the signaling component of SBC, and that protocol repair function is not the same as protocol conversion.

In most cases, this function can be seen as being compatible with SIP architectural principles, and it does not violate the end-to-end model of SIP. The SBC repairing protocol messages behaves as a proxy server that is liberal in what it accepts and strict in what it sends. A similar problem related to increasing complexity, as explained in , also affects protocol repair function.

The SBC can, for example, receive an INVITE message from a relatively new SIP UA as illustrated in .

To: Callee Call-ID: 18293281@u1.example.com CSeq: 1 INVITE Contact: sip:caller@u1.example.com ]]> If the SBC does protocol repair, it can re-write the 'lr' parameter on the Via header field into the form 'lr=true', in order to support some older, non-standard SIP stacks. It could also remove excess white spaces to make the SIP message more human readable.

SBCs are used to perform media encryption / decryption at the edge of the network. This is the case when media encryption is used only on the access network (outer network) side and the media is carried unencrypted in the inner network. Operators may have an obligation to provide the ability to do legal interception, while they still want to give their customers the ability to encrypt media in the access network. This leads to a situation where operators have a requirement to perform media encryption function.

While performing a media encryption function, SBCs need to be able to inject either themselves, or some other entity to the media path. Due to this, the SBCs have the same architectural issues as explained in .

shows an example where the SBC is performing media encryption related functions (ACKs omitted for brevity).

| | | | [Modify the SDP] | | | | | | | | INVITE + mod. SDP | | | |------------------->| | | | [Modify the SDP] | | | | | | | | INVITE + mod. SDP | | | |------------------->| | | | | | | | 200 OK + SDP | | | |<-------------------| | | [Modify the SDP] | | | | | | | 200 OK + mod. SDP | | | |<-------------------| | | [Modify the SDP] | | | | | | | 200 OK + mod. SDP | | | |<-------------------| | | | | | | | Encrypted | Plain | Encrypted | | media [enc./dec.] media [enc./dec.] media | |<==================>|<- - - - - - - - ->|<==================>| | | | | ]]> First the UAC sends an INVITE request , and the first SBC modifies the session descriptor in a way that it injects itself to the media path. The same happens in the second SBC. Then the UAS replies with a 200 OK response, the SBCs inject themselves in the returning media path. After signaling the media start flowing, and both SBCs are performing media encryption and decryption.