RFC 5853
Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments
Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments 🎀
Bestie, here's the paperwork vibe 📋
- Series: Internet Engineering Task Force (IETF), Request for Comments: 5853 💖
- Editor and authors: J. Hautakorpi, Ed. (the editor, so 👑), G. Camarillo (Ericsson), R. Penfield (Acme Packet), A. Hawrylyshen (Skype, Inc.), and M. Bhatia (3CLogic)
- Category: Informational 🦋
- ISSN: 2070-1721
- Date: April 2010 🌸
- Obsoletes / Updates: Nothing. The header doesn't list any RFCs that this one obsoletes or updates, so it stands on its own ✨
Abstract ✨
Okay so this doc is all about the functions that live inside SIP intermediaries called Session Border Controllers (SBCs) 🧚 The main goal is to describe the stuff SBCs commonly do, and it gives extra attention to the practices that clash with SIP's architectural principles 👀 It also digs into what network operators actually need that made them use these functions. The point is to figure out which protocol requirements come from those needs, then check whether existing specs already cover them or if more standards work is needed. Lowkey a big investigation, and I'm obsessed 💅
Status of This Memo 📜
Not an Internet Standards Track specification, just published for informational purposes 🧠
It's a product of the IETF, so it reflects the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 for that. 🫶
For the current status, errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc5853.
Copyright Notice 🌈
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read these, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License. ⚖️
Table of Contents 🗂️
1. Introduction ....................................................4
2. Background on SBCs ..............................................4
2.1. Peering Scenario ...........................................6
2.2. Access Scenario ............................................6
3. Functions of SBCs ...............................................8
3.1. Topology Hiding ............................................8
3.1.1. General Information and Requirements ................8
3.1.2. Architectural Issues ................................9
3.1.3. Example .............................................9
3.2. Media Traffic Management ..................................11
3.2.1. General Information and Requirements ...............11
3.2.2. Architectural Issues ...............................12
3.2.3. Example ............................................13
3.3. Fixing Capability Mismatches ..............................14
3.3.1. General Information and Requirements ...............14
3.3.2. Architectural Issues ...............................14
3.3.3. Example ............................................15
3.4. Maintaining SIP-Related NAT Bindings ......................15
3.4.1. General Information and Requirements ...............15
3.4.2. Architectural Issues ...............................16
3.4.3. Example ............................................17
3.5. Access Control ............................................18
3.5.1. General Information and Requirements ...............18
3.5.2. Architectural Issues ...............................19
3.5.3. Example ............................................19
3.6. Protocol Repair ...........................................20
3.6.1. General Information and Requirements ...............20
3.6.2. Architectural Issues ...............................21
3.6.3. Examples ...........................................21
3.7. Media Encryption ..........................................21
3.7.1. General Information and Requirements ...............21
3.7.2. Architectural Issues ...............................22
3.7.3. Example ............................................22
4. Derived Requirements for Future SIP Standardization Work .......23
5. Security Considerations ........................................23
6. Acknowledgements ...............................................24
7. References .....................................................25
7.1. Normative References ......................................25
7.2. Informative References ....................................251. Introduction 🦋
Okay so over the last few years, SIP [1] got adopted super fast, and SIP-based communications networks popped up everywhere 🚀 Honestly the deployments moved faster than the protocol specs could keep up with what operators needed. That gap led to proprietary solutions. A lot of those ended up inside network intermediaries that the market calls Session Border Controllers (SBCs), because they usually sit at the border between two networks. Why there? Network policies are typically enforced at the edge of the network, so that's where they live 🏰
Now, real talk: a lot of SBCs behave in ways that can break end-to-end security and mess with feature negotiations. 😬 Still, there's clearly a market for them. Network operators need many of the features current SBCs offer, and often there's no standard mechanism for providing them. So people just keep buying them, iykyk 💅
So what's this doc for? It describes the functions SBCs implement, with a special focus on the practices that conflict with SIP architectural principles in some way. It also explores the underlying operator requirements behind those functions and practices. The goal is to pin down protocol requirements and figure out whether existing specifications already satisfy them, or whether additional standards work is required. ✨
2. Background on SBCs 🌸
Quick heads-up: the term SBC is pretty vague, since nobody standardized or defined it anywhere. 🙈 Any node that gets called an SBC but doesn't implement SIP is outside the scope of this document, so we're not talking about those.
SBCs usually sit in one of two places. One is between two service provider networks in a peering environment. The other is between an access network and a backbone network, where they serve residential and/or enterprise customers. They offer a bunch of functions that enable or enhance session-based multimedia services (for example, Voice over IP). Those functions include:
- a) perimeter defense, which covers access control, topology hiding, and denial-of-service prevention and detection
- b) functionality the endpoints don't have, like NAT traversal and protocol interworking or repair
- c) traffic management, which covers media monitoring and Quality of Service (QoS)
Some of these functions also get built into other SIP elements, like pre-paid platforms, Third Generation Partnership Project (3GPP) Proxy CSCF (P-CSCF) [6], and 3GPP I-CSCF, among others. 🧚
Here's the B2BUA situation. SIP-based SBCs typically handle both signaling and media. They can behave like a "privacy service" (as described in [2]), doing both Header Privacy and Session Privacy 🔒 SBCs also often change certain SIP headers and message bodies that proxies aren't allowed to change. Because of that, by definition, they're B2BUAs (Back-to-Back User Agents). How transparent a B2BUA is depends on what it does. For example, some SBCs modify the session description in the message and insert a Record-Route entry. Others replace the value of the Contact header field with the SBC's own address, and they generate a new Call-ID plus new To and From tags. Wild, right? 🤯
+-----------------+
| SBC |
[signaling] | +-----------+ |
<------------|->| signaling |<-|---------->
outer | +-----------+ | inner
network | | | network
| +-----------+ |
<------------|->| media |<-|---------->
[media] | +-----------+ |
+-----------------+
Figure 1: SBC ArchitectureFigure 1 shows the logical architecture of an SBC. It has a signaling component and a media component 🎀 In this doc, the terms outer and inner network describe the two networks on either side. An SBC is logically associated with the inner network, and it typically provides functions like controlling and protecting access to the inner network from the outer network. The organization that operates the inner network is the one that configures and manages the SBC. 🛡️
Now the consent part, which is kinda the tea ☕ Sometimes SBCs operate with users' consent, whether implicit or explicit. Other times they operate without users' consent, and that latter case can potentially cause problems 😬 For example, say an SBC in the same administrative domain as a set of enterprise users performs topology hiding (see Section 3.1). The enterprise users can choose to route their SIP messages through it. If they do, the SBC can be seen as having the users' implicit consent 💜 Another example: a service provider has broken gateways, so it deploys an SBC in front of them for protocol repair reasons (see Section 3.6). Users can choose to configure that SBC as their gateway, so once again the SBC can be seen as having the users' implicit consent. ✨
2.1. Peering Scenario 🦋
okay so peering is basically two network operators swapping traffic with each other, and the example in Figure 2 is giving. an originating gateway (GW-A1) in Operator A's network sends an INVITE, which gets routed to the SBC in Operator B's network. then the SBC forwards it to the softswitch (SS-B). the softswitch replies with a redirect (3xx) back to the SBC, pointing at the right terminating gateway (GW-B1) in Operator B's network. if Operator B doesn't have an SBC, that redirect goes straight back to Operator A's originating gateway. once the SBC has the redirect, it sends the INVITE on to the terminating gateway 💅
Operator A . Operator B
.
. 2) INVITE
+-----+ . /--------------->+-----+
|SS-A | . / 3) 3xx (redir.) |SS-B |
+-----+ . / /---------------+-----+
. / /
+-----+ 1) INVITE +-----+--/ / +-----+
|GW-A1|---------------->| SBC |<---/ 4) INVITE |GW-B1|
+-----+ +-----+---------------------->+-----+
.
+-----+ . +-----+
|GW-A2| . |GW-B2|
+-----+ . +-----+
Figure 2: Peering with SBCfrom the SBC's point of view, Operator A is the outer network and Operator B is the inner network 👑. Operator B can use the SBC to control access to its network, protect its gateways and softswitches from unauthorized use and denial-of-service (DoS) attacks, and monitor both signaling and media traffic. it also makes network management way easier, because it cuts down the number of ACL (Access Control List) entries needed in the gateways 🧚. the gateways don't need to be exposed to the peer network, and they can restrict access (both media and signaling) to the SBCs. the SBC helps make sure only media from sessions it has authorized reaches the gateway 🔥
2.2. Access Scenario 🏠
in an access scenario, shown in Figure 3, the SBC sits at the border between the access network (outer network) and the operator's network (inner network). its job is 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 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, and the SBC routes requests to one or more proxies in the operator network.
Access Network Operator Network
+-----+
| UA1 |<---------\
+-----+ \
\
+-----+ \------->+-----+ +-------+
| UA2 |<-------------------->| SBC |<----->| proxy |<-- -
+-----+ /--->+-----+ +-------+
/
+-----+ +-----+ /
| UA3 +---+ NAT |<---/
+-----+ +-----+
Figure 3: Access Scenario with SBCthe 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). wherever it's hosted, it's managed by the organization maintaining the operator network 💖
some endpoints may be behind enterprise or residential NATs. when the access network is a private network, the SBC is a NAT for all traffic. it's worth noting that SIP traffic may have to traverse more than one NAT 😭. the proxy usually does authentication and/or authorization for registrations and outbound calls. the SBC modifies the REGISTER request so that later requests to the registered address-of-record get routed to the SBC. this is done either with a Path header field [3] or by modifying the Contact to point at the SBC 🎀
this scenario is general, and it applies to other similar settings too. one example is an access network that's the open internet, with the operator network belonging to a SIP service provider 🌈
3. Functions of SBCs ✨
this section lists the functions used in SBC deployments in current communication networks. each subsection describes a particular function or feature, the operators' requirements for having it, any impact on the end-to-end SIP architecture, and a concrete implementation example. each one also covers potential concerns specific to that implementation technique. suggestions for alternative techniques that may be more architecturally compatible with SIP are out of scope for this document 🫶
all the examples in this section are simplified, so only the relevant header lines from SIP and SDP (Session Description Protocol) [7] messages are displayed.
3.1. Topology Hiding 🕵️♀️
3.1.1. General Information and Requirements
topology hiding means limiting the amount of topology information given to external parties. operators need this because they don't want the IP addresses of their equipment (proxies, gateways, application servers, etc.) exposed to outside parties 🙈. maybe they don't want to expose that equipment to DoS attacks, maybe they use other carriers for certain traffic and don't want their customers to know, or maybe they want to hide their internal network architecture from competitors or partners. in some environments, the operator's customers may also want to hide the addresses of their own equipment, or the SIP messages may contain private, non-routable addresses.
the most common form of topology hiding is header privacy (see Section 5.1 of [2]), which involves stripping Via and Record-Route headers, replacing the Contact header, and even changing Call-IDs. however, in deployments that use IP addresses instead of domain names in headers that can't be removed (e.g., From and To headers), the SBC may replace those IP addresses with its own IP address or domain name.
for reference, there are also other ways to hide topology information than inserting an intermediary, like an SBC, into the signaling path. one of them is the UA-driven privacy mechanism [8], where the UA can help conceal topology information 🦋
3.1.2. Architectural Issues
doing topology hiding like this, through SBCs that don't have the users' consent, comes with some issues 😬. the whole thing is based on a hop-by-hop trust model instead of an end-to-end trust model. the messages get modified without the subscriber's consent, and that could potentially modify or remove info about the user's privacy, security requirements, and higher-layer applications that are communicated end-to-end using SIP. neither user agent in an end-to-end call has any way to tell SBC actions apart from a man-in-the-middle (MITM) attack. scary, right? 💀
topology hiding also doesn't play nicely with Authenticated Identity Management [4] when the SBC doesn't have any kind of consent from the users. that mechanism relies on a hash value calculated from parts of the From, To, Call-ID, CSeq, Date, and Contact header fields, plus the whole message body. if the authentication service isn't provided by the SBC itself, changing those header fields and the message body violates [4]. some forms of topology hiding are violations because they, e.g., replace the Contact header of a SIP message 🙅♀️
3.1.3. Example
the current way of doing topology hiding is to have an SBC act as a B2BUA (Back-to-Back User Agent) and strip out all traces of topology information (e.g., Via and Record-Route entries) from outgoing messages 🧠
imagine this scenario: the SBC (p4.domain.example.com) receives an INVITE request from the inner network, which in this case is an operator network. the SIP message it gets looks like Figure 4 👀
INVITE sip:callee@u2.domain.example.com SIP/2.0
Via: SIP/2.0/UDP p3.middle.example.com;branch=z9hG4bK48jq9w174131.1
Via: SIP/2.0/UDP p2.example.com;branch=z9hG4bK18an6i9234172.1
Via: SIP/2.0/UDP p1.example.com;branch=z9hG4bK39bn2e5239289.1
Via: SIP/2.0/UDP u1.example.com;branch=z9hG4bK92fj4u7283927.1
Contact: sip:caller@u1.example.com
Record-Route: <sip:p3.middle.example.com;lr>
Record-Route: <sip:p2.example.com;lr>
Record-Route: <sip:p1.example.com;lr>
Figure 4: INVITE Request Prior to Topology Hidingthen the SBC does its topology hiding thing. here, it removes and stores all the existing Via and Record-Route headers, then inserts Via and Record-Route header fields with its own SIP URI. after the topology hiding, the message could look like Figure 5 ✨
INVITE sip:callee@u2.domain.example.com SIP/2.0
Via: SIP/2.0/UDP p4.domain.example.com;branch=z9hG4bK92es3w230129.1
Contact: sip:caller@u1.example.com
Record-Route: <sip:p4.domain.example.com;lr>
Figure 5: INVITE Request after Topology Hidinglike a regular proxy server that inserts a Record-Route entry, the SBC handles every single message in a given SIP dialog 🫡. if the SBC loses state (e.g., it restarts for some reason), it may not be able to route messages properly. (note: some SBCs preserve state information across restarts too). for example, if the SBC removes Via entries from a request and then restarts, losing state, it may not be able to route responses to that request, depending on what information was lost in the restart 😵
this is only one example of topology hiding. besides topology hiding (hiding info about network elements), SBCs may also do identity hiding (hiding info about subscriber identity). while doing identity hiding, SBCs may modify Contact header field values and other header fields that carry identity information. Section 4.1 of [2] lists the header fields containing identity information. since [2] was published, these identity-related header fields have also been defined: "P-Asserted-Identity", "Referred-By", "Identity", and "Identity-Info" 📝
3.2. Media Traffic Management 🎶
3.2.1. General Information and Requirements
Media traffic management is all about controlling the media traffic itself 🎀. Network operators may need this so they can control what's flowing over their network for their subscribers. It also makes different billing models possible (video calls can be priced differently than voice-only calls, obviously 💅), and it lets operators enforce the use of selected codecs.
One big use case is intercept capabilities, which are needed to meet audit or legal obligations. Lowkey, the legal stuff mainly hits operators who provide voice services, and those operators usually already have intercept infrastructure (like SIP proxies acting as B2BUAs) even without SBCs 🧚.
The media path is separate from the signaling path, so the media may not go through the operator's network at all unless the SBC changes the session description ✨. If the SBC edits that session description, it can force the media through a media relay that might live right alongside the SBC 🦋. Operators do this to make sure a certain QoS level is met or that subscribers only use allowed codecs. Also, SBCs have no direct ties to routing topology. They don't change bandwidth reservations on Traffic Engineering (TE) tunnels, and they don't directly interact with the routing protocol. Not their vibe 💀
Some operators don't want to manage the traffic, only monitor it 📊. They want statistics and proof that they're hitting any business service level agreements with their subscribers and/or partners. From the SBC's point of view, the protocol techniques for monitoring media traffic are the same as the ones for managing it.
SBCs on the media path can also deal with the "lost BYE" issue if either endpoint dies in the middle of a session 🧹. The SBC can notice the media has stopped flowing and send a BYE to both sides to clean up state in other intermediate elements and the endpoints.
Another form of media traffic management is when SBCs terminate media streams and SIP dialogs by generating BYE requests 🙅. This can happen when a subscriber runs out of credits 💸. Media management is needed so the subscriber can't just ignore the BYE the SBC generated and keep going with its media sessions.
3.2.2. Architectural Issues
Doing traffic management this way means the SBC has to access and modify the session descriptions (offers and answers) exchanged between the user agents 👀. So this approach doesn't work if user agents encrypt or integrity-protect their message bodies end-to-end. Again, messages get modified without subscriber consent, and user agents have no way to tell SBC actions apart from an attack by a MITM 😱. Furthermore, this is in violation of Authenticated Identity Management [4], see Section 3.1.2 🙃.
Inserting a media relay can prevent "non-media" uses of the media path, like the media path key agreement 🔐. Sometimes that prevention is intentional, but it isn't always necessary. For example, if an SBC is only used for enabling media monitoring and not for interception.
There are some possible issues with media relaying too 🧐. If media relaying isn't done the right way, it may break functions like Explicit Congestion Notification (ECN) and Path MTU Discovery (PMTUD), for example. Media relays can easily break IP and transport layer functionality that depends on protocol fields being handled correctly. The especially sensitive fields are things like the ECN and Type of Service (ToS) fields and the Don't Fragment (DF) bit.
Media traffic management also impedes innovation 🐢. In many cases, SBCs need to support new forms of communication (e.g., extensions to the SDP protocol) before new services can be put into use, which slows down the adoption of new innovations.
If an SBC directs many media streams through a central point in the network, it's likely to cause a significant amount of additional traffic on the path to that central point 🚧. That might create a possible bottleneck.
In this application, the SBC may also originate messages that the user can't authenticate as coming from the dialog peer or the SIP Registrar/Proxy 🫣.
3.2.3. Example
Traffic management may be done like this: the SBC behaves as a B2BUA and inserts itself, or some other entity under the operator's control, into the media path 🔁. In practice, the SBC modifies the session descriptions carried in the SIP messages. So the SBC receives media from one user agent and relays it to the other user agent, and it does the identical operation with media traveling in the reverse direction.
As mentioned in Section 3.2.1, codec restriction is a form of traffic management 🎧. The SBC restricts the codec set negotiated in the offer/answer exchange [5] between the user agents. After modifying the session descriptions, the SBC can check whether or not the media stream matches what was negotiated in the offer/answer exchange. If it differs, the SBC can terminate the media stream or take other appropriate (configured) actions, e.g., raise an alarm 🚨.
Let's look at an 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 Figure 6.
v=0
o=owner 2890844526 2890842807 IN IP4 192.0.2.4
c=IN IP4 192.0.2.4
m=audio 49230 RTP/AVP 96 98
a=rtpmap:96 L8/8000
a=rtpmap:98 L16/16000/2Figure 6: Request Prior to Media Management
In this example, the SBC performs the media traffic management function by rewriting the "m=" line and removing one "a=" line according to some (external) policy 🪄. Figure 7 shows the session description after the traffic management function.
v=0
o=owner 2890844526 2890842807 IN IP4 192.0.2.4
c=IN IP4 192.0.2.4
m=audio 49230 RTP/AVP 96
a=rtpmap:96 L8/8000Figure 7: Request Body After Media Management
Media traffic management has a problem though 😭: the SBC needs to understand the session description protocol and all the extensions the user agents use. This means that to use a new extension (e.g., one that implements a new service) or a new session description protocol, SBCs in the network may need to be upgraded along with the endpoints 🛠️. A similar problem, but with header fields, applies to the topology hiding function, see Section 3.1. Certain extensions that don't require active manipulation of the session descriptors to facilitate traffic management can be deployed without upgrading existing SBCs, depending on how transparent the SBC implementation is 🦋. In cases where an SBC modification is needed to support the new protocol features, the rate of service deployment may be affected.
3.3. Fixing Capability Mismatches
3.3.1. General Information and Requirements
SBCs fixing capability mismatches enable communication between user agents with different capabilities or extensions 🤝. For example, an SBC can enable a plain SIP [1] user agent to connect to a 3GPP network, or enable a connection between user agents that support different IP versions, different codecs, or that are in different address realms. Operators have a requirement and a strong motivation to do capability mismatch fixing, so they can provide transparent communication across different domains 🌍. In some cases, different SIP extensions or methods that implement the same SIP application (like monitoring session liveness, call history/diversion etc.) may also be interworked through the SBC 🔄.
3.3.2. Architectural Issues
SBCs that fix capability mismatches do it by inserting a media element into the media path, using the procedures described in Section 3.2 🧩. So these SBCs have the same concerns as SBCs doing traffic management: the SBC may modify SIP messages without consent from any of the user agents. This may break end-to-end security and application extensions negotiation 💔.
Capability mismatch fixing is a fragile function in the long term 😵💫. The number of incompatibilities built into various network elements keeps increasing, which adds fragility and complexity over time. This might lead to a situation where SBCs need to handle a large number of capability mismatches in parallel.
3.3.3. Example
Let's consider an example 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:
INVITE sip:callee@ipv6.domain.example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4
Contact: sip:caller@u1.example.com
v=0
o=owner 2890844526 2890842807 IN IP4 192.0.2.4
c=IN IP4 192.0.2.4
m=audio 49230 RTP/AVP 96
a=rtpmap:96 L8/8000Figure 8: Request Prior to Capabilities Match
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. Figure 9 shows the request after the capability mismatch adjustment.
INVITE sip:callee@ipv6.domain.com SIP/2.0
Record-Route: <sip:[2001:DB8::801:201:2ff:fe94:8e10];lr>
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=owner 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/8000Figure 9: Request after Capability Match
This message is then sent by the SBC on to the onward IPv6 network 🚀.
3.4. Maintaining SIP-Related NAT Bindings 🌸
3.4.1. General Information and Requirements 🦋
okay bestie, so NAT traversal here is the SBC doing a few tweaks to SIP messages so a user agent hiding behind a NAT can keep its SIP and media connections alive. The NAT sits between that UA and a proxy/registrar, and maybe some other UA too 🌸. The main goal is keeping a control connection open to UAs behind NATs. One way to do that is sending periodic network traffic that keeps the NAT bindings alive ✨. The SBC's NAT traversal function is needed when the NAT is outside the SBC. If the SBC is the NAT itself, that's a different situation 💅.
An SBC doing NAT (Network Address Translator) traversal for a UA behind a NAT sits between the UA and the domain's registrar. NATs are everywhere in today's access networks, so operators have a real need to support this 😭. When the registrar gets a REGISTER from the UA and replies with a 200 (OK), the SBC edits that response so the registration expires sooner. This pushes the UA to send a new REGISTER to refresh earlier than it would have after the original response from the registrar 🔥. The UA's REGISTERs refresh the NAT binding before it expires.
Note that the SBC doesn't have to pass along every REGISTER to the registrar. It can generate responses to REGISTERs that come in before the registration is about to expire at the registrar 🧚. Also, the SBC needs to deregister the UA if it fails to refresh the registration in time, even if the registrar's registration would still be valid 💀.
SBCs can also force traffic to go through a media relay for NAT traversal (more on media traffic management in Section 3.2 🎀). A typical call has media streams in two directions. Even though SBCs can force media from both directions through a media relay, sometimes it's enough to relay only one direction (e.g., when only the other endpoint is behind a NAT) 🫶.
3.4.2. Architectural Issues
Here's the tea 🍵 this approach doesn't work if end-to-end confidentiality or integrity-protection mechanisms are used (e.g., Secure/Multipurpose Internet Mail Extensions (S/MIME)). The SBC would look like a MITM 😱 modifying the messages between the UA and the registrar.
There's also a problem with how SBCs choose the validity period for a registration. This value should be as high as possible, but it still needs to be low enough to keep the NAT binding alive ⏱️. Some SBCs don't have a deterministic method for picking a suitable value 🤷♀️. They can just use a sub-optimal, relatively small value that usually works. An example of such a value is 15 seconds (see [9]) 💜.
NAT traversal for media using SBCs has issues too 🙈. For example, an SBC normally guesses the recipient's public IP address on one of the media streams it relays by snooping on the source IP address of another media stream relayed by the same SBC. This causes security and interoperability issues, since the SBC can end up associating wrong destination IP addresses with the media streams it's relaying. For example, an attacker may snoop on the local IP address and ports the SBC uses for relaying the streams, then send a few packets from a malicious IP address to those destinations. In most cases this can make media streams in the opposite directions divert traffic to the attacker, resulting in a successful MITM or DoS attack 🚨. A similar interoperability issue happens when an endpoint behind a NAT tries to switch the IP address of its media streams using a re-INVITE. If any media packets are re-ordered or delayed in the network, they can cause the SBC to block the switch from happening, even if the re-INVITE successfully goes through 😤.
3.4.3. Example 👀
Consider the following example scenario: the SBC resides between the UA and Registrar. Previously, the UA has sent a REGISTER request to the Registrar, and the SBC receives the registration response shown in Figure 10.
SIP/2.0 200 OK
From: Bob <sip:bob@biloxi.example.com>;tag=a73kszlfl
To: Bob <sip:bob@biloxi.example.com>;tag=34095828jh
CSeq: 1 REGISTER
Contact: <sips:bob@client.biloxi.example.com>;expires=3600
Figure 10: Response Prior to NAT Maintenance FunctionWhen performing the NAT traversal function, the SBC may rewrite the expiry time to coax the UA into re-registering before the intermediating NAT decides to close the pinhole 🪟. Figure 11 shows a possible modification of the response from Figure 10 ✍️.
SIP/2.0 200 OK
From: Bob <sip:bob@biloxi.example.com>;tag=a73kszlfl
To: Bob <sip:bob@biloxi.example.com>;tag=34095828jh
CSeq: 1 REGISTER
Contact: <sips:bob@client.biloxi.example.com>;expires=60
Figure 11: Manipulated Response for NAT TraversalNaturally, other measures could be taken to enable NAT traversal (e.g., non-SIP keepalive messages), but this example only illustrates one mechanism for preserving the SIP-related NAT bindings 💖.
3.5. Access Control 🔐
3.5.1. General Information and Requirements
Network operators may wish to control what kind of signaling and media traffic their network carries. There's strong motivation and a requirement to do access control at 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, configured so they only accept SIP traffic from the SBC. That way, all SIP traffic entering the inner network has to be routed through the SBC, which only routes messages from authorized parties, or traffic that meets a specific policy expressed administratively in the SBC 🛡️.
Access control can be applied to either only the signaling, or to both the signaling and media. If it's only applied to the signaling, then the SBC might behave as a proxy server. If access control is applied to both signaling and media, then the SBC behaves in a similar manner to what's explained in Section 3.2. 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 🌈.
Operators implement some functionalities, like NAT traversal for example, in an SBC instead of other elements in the inner network 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 🧚.
In environments where there is limited bandwidth on the access links, the SBC can compute the potential bandwidth use by examining the codecs present in SDP offers and answers. With this information, the SBC can reject sessions before the available bandwidth is exhausted, so existing sessions keep 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.
3.5.2. Architectural Issues
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's performed for signaling and for media, then there are similar problems to those described in Section 3.2.2 🤓.
3.5.3. Example 📞
Figure 12 shows a callflow where the SBC is providing both signaling and media access control (ACKs omitted for brevity).
caller SBC callee
| | |
| Identify the caller | |
|<- - - - - - - - - - - >| |
| | |
| INVITE + SDP | |
|----------------------->| |
| [Modify the SDP] |
| | INVITE + modified SDP |
| |----------------------->|
| | |
| | 200 OK + SDP |
| |<-----------------------|
| [Modify the SDP] |
| | |
| 200 OK + modified SDP | |
|<-----------------------| |
| | |
| Media [Media inspection] Media |
|<======================>|<======================>|
| | |
Figure 12: Example Access CallflowIn this scenario, the SBC first identifies the caller, so it can determine whether or not to give signaling access to 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 so that the media is going to flow through the SBC itself. When the media starts flowing, the SBC can inspect whether the callee and caller use the codec(s) upon which they had previously agreed 🎧.
3.6. Protocol Repair 🔧
3.6.1. General Information and Requirements
SBCs are also used to repair protocol messages generated by not-fully-standard-compliant or badly implemented 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 an SBC, and that the protocol repair function is not the same as protocol conversion (i.e., making translation between two completely different protocols) ✨.
3.6.2. Architectural Issues 💅
Okay so protocol repair on SIP header fields is lowkey compatible with SIP architecture 🦋. It doesn't break the end-to-end model of SIP. The SBC doing the repairing acts like a proxy server that is liberal in what it accepts and strict in what it sends ✨.
However, protocol repair may break security mechanisms that do cryptographic computations on SIP header values 😭. Attempting protocol repair on SIP message bodies (SDP) is incompatible with Authenticated Identity Management [4] and end-to-end security mechanisms such as S/MIME. Not me being dramatic, but this is a big deal 💀.
A similar problem related to increasing complexity, as explained in Section 3.3.2, also affects the protocol repair function 🙈.
3.6.3. Examples 🎀
The SBC can, for example, receive an INVITE message from a relatively new SIP UA, as shown in Figure 13 🧚.
INVITE sip:callee@sbchost.example.com
Via: SIP/2.0/UDP u1.example.com:5060;lr
From: Caller <sip:caller@one.example.com>
To: Callee <sip:callee@two.example.com>
Call-ID: 18293281@u1.example.com
CSeq: 1 INVITE
Contact: sip:caller@u1.example.com
Figure 13: Request from a Relatively New ClientIf the SBC does protocol repair, it can rewrite the 'lr' parameter on the Via header field into the form 'lr=true' to support some older, badly implemented SIP stacks 🍓. It could also remove excess white spaces to make the SIP message more human readable 🌸.
3.7. Media Encryption 🦋
3.7.1. General Information and Requirements
SBCs are used to perform media encryption and decryption at the edge of the network ✨. This is the case when media encryption (e.g., Secure Real-time Transport Protocol (SRTP)) is used only on the access network (outer network) side, and the media is carried unencrypted in the inner network. Some operators give their customers the ability to encrypt media in the access network while still letting them do legal interception 👑. One possible way to do this is to perform the media encryption function.
3.7.2. Architectural Issues
While performing a media encryption function, SBCs need to be able to inject either themselves, or some other entity, into the media path. This behaviour is the same as a classical MITM attack 😬. Because of this, SBCs have the same architectural issues as explained in Section 3.2.
3.7.3. Example 🌈
Figure 14 shows an example where the SBC is performing media-encryption-related functions (ACKs omitted for brevity) 💖.
caller SBC#1 SBC#2 callee
| | | |
| INVITE + SDP | | |
|------------------->| | |
| [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 |
|<==================>|<- - - - - - - - ->|<==================>|
| | | |
Figure 14: Media Encryption ExampleFirst, the UAC sends an INVITE request, and the first SBC modifies the session descriptor so that it injects itself into the media path 🔥. The same thing happens at the second SBC. Then the User Agent Server (UAS) replies with a 200 OK response, and the SBCs inject themselves into the returning media path 🎀. After signaling, the media starts flowing, and both SBCs perform media encryption and decryption. Slay 💅.
4. Derived Requirements for Future SIP Standardization Work ✨
Some of the functions listed in this document are more SIP-unfriendly than others 🙈. This list of requirements is derived from the functions that break the principles of SIP in one way or another when performed by SBCs that do not have the users' consent. The derived requirements are:
Req-1: There should be a SIP-friendly way to hide network topology information. Currently, this is done by stripping and replacing header fields, which is against the principles of SIP on behalf of some header fields (see Section 3.1).
Req-2: There should be a SIP-friendly way to direct media traffic through intermediaries. Currently, this is done by modifying session descriptors, which is against the principles of SIP (see Sections 3.2, 3.4, 3.5, and 3.7).
Req-3: There should be a SIP-friendly way to fix capability mismatches in SIP messages. This requirement is harder to fulfill on complex mismatch cases, like the 3GPP/SIP [1] network mismatch. Currently, this is done by modifying SIP messages, which may violate end-to-end security (see Sections 3.3 and 3.6), on behalf of some header fields.
Req-1 and Req-3 do not have an existing, standardized solution today 😭. There is ongoing work in the IETF for addressing Req-2, such as SIP session policies [10], Traversal Using Relays around NAT (TURN) [11], and Interactive Connectivity Establishment (ICE) [12]. Nonetheless, future work is needed in order to develop solutions to these requirements 🌸.
5. Security Considerations 💀
Many of the functions this document describes have important security and privacy implications 🚨. One major security problem is that many functions implemented by SBCs (e.g., topology hiding and media traffic management) modify SIP messages and their bodies without the user agents' consent. The result is that the user agents may interpret the actions taken by an SBC as a MITM attack. SBCs modify SIP messages because it allows them to, for example, protect elements in the inner network from direct attacks.
SBCs that place themselves (or another entity) on the media path can be used to eavesdrop on conversations 👀. Since user agents often cannot distinguish between the actions of an attacker and those of an SBC, users cannot know whether they are being eavesdropped on or whether an SBC on the path is performing some other function. SBCs place themselves on the media path because it allows them to, for example, perform legal interception.
On a general level, SBCs prevent the use of end-to-end authentication. This is because SBCs need to be able to perform actions that look like MITM attacks, and in order for user agents to communicate, they must allow those types of attacks. In other words, user agents cannot use end-to-end security. This is especially harmful because other network elements, besides SBCs, are then able to do similar attacks 😱. However, in some cases, user agents can establish encrypted media connections between one another. One example is a scenario where an SBC is used for enabling media monitoring but not for interception.
An SBC is a single point of failure from the architectural point of view 💔. This makes it an attractive target for DoS attacks. The fact that some functions of SBCs require those SBCs to maintain session-specific information makes the situation even worse. If the SBC crashes (or is brought down by an attacker), ongoing sessions experience undetermined behavior 💀.
If the IETF decides to develop standard mechanisms to address the requirements presented in Section 4, the security and privacy-related aspects of those mechanisms will, of course, need to be taken into consideration 🔐.
6. Acknowledgements 🫶
The ad hoc meeting about SBCs, held on November 9, 2004 in Washington DC during the 61st IETF meeting, provided valuable input to this document ✨. The authors would also like to thank Sridhar Ramachandran, Gaurav Kulshreshtha, and Rakendu Devdhar. Reviewers Spencer Dawkins and Francois Audet also deserve special thanks 👑.
7. References 📚
7.1. Normative References
- [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
- [2] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
- [3] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, December 2002.
- [4] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
- [5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
7.2. Informative References
- [6] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP TS 23.228 10.0.0, March 2010.
- [7] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
- [8] Munakata, M., Schubert, S., and T. Ohba, "User-Agent-Driven Privacy Mechanism for SIP", RFC 5767, April 2010.
- [9] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008.
- [10] Hilt, V., Camarillo, G., and J. Rosenberg, "A Framework for Session Initiation Protocol (SIP) Session Policies", Work in Progress, February 2010.
- [11] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
- [12] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, MonthTBD 2010.
Authors' Addresses 💌
okay bestie, the people who wrote this are so cute and so smart, and here's exactly how to find them 🫶
Jani Hautakorpi is the editor 🎀 and you can reach them here:
Jani Hautakorpi (editor)
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
EMail: Jani.Hautakorpi@ericsson.comGonzalo Camarillo is also at Ericsson, same street and everything 🦋
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
EMail: Gonzalo.Camarillo@ericsson.comRobert F. Penfield is at Acme Packet in Burlington 🌸
Robert F. Penfield
Acme Packet
71 Third Avenue
Burlington, MA 01803
US
EMail: bpenfield@acmepacket.comAlan Hawrylyshen was at Skype, Inc. in San Jose when this was written ✨
Alan Hawrylyshen
Skype, Inc.
2055 E. Hamilton Ave
San Jose, CA 95125
US
EMail: alan.ietf@polyphase.caAnd last but definitely not least, Medhavi Bhatia is at 3CLogic in Rockville 👑
Medhavi Bhatia
3CLogic
9700 Great Seneca Hwy.
Rockville, MD 20850
US
EMail: mbhatia@3clogic.comThat's the whole crew, periodt 💅🧚
📦 where this page comes from
- ietf: rfc5853 2010-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms