summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5853.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5853.txt')
-rw-r--r--doc/rfc/rfc5853.txt1459
1 files changed, 1459 insertions, 0 deletions
diff --git a/doc/rfc/rfc5853.txt b/doc/rfc/rfc5853.txt
new file mode 100644
index 0000000..dcb1ff6
--- /dev/null
+++ b/doc/rfc/rfc5853.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) J. Hautakorpi, Ed.
+Request for Comments: 5853 G. Camarillo
+Category: Informational Ericsson
+ISSN: 2070-1721 R. Penfield
+ Acme Packet
+ A. Hawrylyshen
+ Skype, Inc.
+ M. Bhatia
+ 3CLogic
+ April 2010
+
+
+ Requirements from Session Initiation Protocol (SIP)
+ Session Border Control (SBC) Deployments
+
+Abstract
+
+ This document describes functions implemented in Session Initiation
+ Protocol (SIP) intermediaries known as Session Border Controllers
+ (SBCs). The goal of this document is to describe the commonly
+ provided functions of SBCs. A special focus is given to those
+ practices that are viewed to be in conflict with SIP architectural
+ principles. This document also explores the underlying requirements
+ of network operators that have led to the use of these functions and
+ practices in order to identify protocol requirements and determine
+ whether those requirements are satisfied by existing specifications
+ or if additional standards work is required.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc5853.
+
+
+
+
+
+
+
+
+Hautakorpi, et al. Informational [Page 1]
+
+RFC 5853 Requirements from SIP SBC Deployments April 2010
+
+
+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) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hautakorpi, et al. Informational [Page 2]
+
+RFC 5853 Requirements from SIP SBC Deployments April 2010
+
+
+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 ....................................25
+
+
+
+
+
+
+
+
+
+
+Hautakorpi, et al. Informational [Page 3]
+
+RFC 5853 Requirements from SIP SBC Deployments April 2010
+
+
+1. Introduction
+
+ In the past few years, there has been a rapid adoption of the Session
+ Initiation Protocol (SIP) [1] and deployment of SIP-based
+ communications networks. This has often outpaced the development and
+ implementation of protocol specifications to meet network operator
+ requirements. This has led to the development of proprietary
+ solutions. Often, these proprietary solutions are implemented in
+ network intermediaries known in the marketplace as Session Border
+ Controllers (SBCs) because they typically are deployed at the border
+ between two networks. The reason for this is that network policies
+ are typically enforced at the edge of the network.
+
+ Even though many SBCs currently behave in ways that can break end-to-
+ end security and impact feature negotiations, there is clearly a
+ market for them. Network operators need many of the features current
+ SBCs provide, and often there are no standard mechanisms available to
+ provide them.
+
+ The purpose of this document is to describe functions implemented in
+ SBCs. A special focus is given to those practices that conflict with
+ SIP architectural principles in some way. The document also explores
+ the underlying requirements of network operators that have led to the
+ use of these functions and practices in order to identify protocol
+ requirements and determine whether those requirements are satisfied
+ by existing specifications or if additional standards work is
+ required.
+
+2. Background on SBCs
+
+ 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 denial-of-
+ service prevention and detection); b) functionality not available in
+ the endpoints (NAT traversal, protocol interworking or repair); and
+ c) traffic management (media monitoring and Quality of Service
+ (QoS)). Some of these functions may also get integrated into other
+ SIP elements (like pre-paid platforms, Third Generation Partnership
+ Project (3GPP) Proxy CSCF (P-CSCF) [6], 3GPP I-CSCF, etc.).
+
+
+
+
+
+Hautakorpi, et al. Informational [Page 4]
+
+RFC 5853 Requirements from SIP SBC Deployments April 2010
+
+
+ SIP-based SBCs typically handle both signaling and media and can
+ implement behavior that is equivalent to a "privacy service" (as
+ described in [2]) 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.
+
+ +-----------------+
+ | SBC |
+ [signaling] | +-----------+ |
+ <------------|->| signaling |<-|---------->
+ outer | +-----------+ | inner
+ network | | | network
+ | +-----------+ |
+ <------------|->| media |<-|---------->
+ [media] | +-----------+ |
+ +-----------------+
+
+ Figure 1: SBC Architecture
+
+ Figure 1 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. An SBC
+ is logically associated with the inner network, and it typically
+ provides functions such as controlling and protecting access to the
+ inner network from the outer network. The SBC itself is configured
+ and managed by the organization operating the inner network.
+
+ In some scenarios, SBCs operate with users' (implicit or explicit)
+ consent; while in others, they operate without users' consent (this
+ latter case can potentially cause problems). For example, if 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 choose to
+ route through the SBC, then the SBC can be seen as having the users'
+ implicit consent. Another example is a scenario where a service
+ provider has broken gateways and it deploys an SBC in front of them
+ for protocol repair reasons (see Section 3.6). Users can choose to
+ configure the SBC as their gateway and, so, the SBC can be seen as
+ having the users' implicit consent.
+
+
+
+
+
+
+Hautakorpi, et al. Informational [Page 5]
+
+RFC 5853 Requirements from SIP SBC Deployments April 2010
+
+
+2.1. Peering Scenario
+
+ A typical peering scenario involves two network operators who
+ exchange traffic with each other. An example peering scenario is
+ illustrated in Figure 2. An originating gateway (GW-A1) in Operator
+ A's network sends an INVITE that is routed to the SBC in Operator B's
+ network. Then, the SBC forward it to the softswitch (SS-B). The
+ softswitch responds with a redirect (3xx) message back to the SBC
+ that points to the appropriate terminating gateway (GW-B1) in
+ Operator B's network. If Operator B does not have an SBC, the
+ redirect message would go to the Operator A's originating gateway.
+ After receiving the redirect message, the SBC sends the INVITE 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 SBC
+
+ From the SBC's perspective the 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 denial-of-service (DoS)
+ attacks, and monitor the signaling and media traffic. It also
+ simplifies network management by minimizing the number of 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.
+
+2.2. Access Scenario
+
+ In an access scenario, presented in Figure 3, 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,
+
+
+
+Hautakorpi, et al. Informational [Page 6]
+
+RFC 5853 Requirements from SIP SBC Deployments April 2010
+
+
+ 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.
+
+ Access Network Operator Network
+
+ +-----+
+ | UA1 |<---------\
+ +-----+ \
+ \
+ +-----+ \------->+-----+ +-------+
+ | UA2 |<-------------------->| SBC |<----->| proxy |<-- -
+ +-----+ /--->+-----+ +-------+
+ /
+ +-----+ +-----+ /
+ | UA3 +---+ NAT |<---/
+ +-----+ +-----+
+
+ Figure 3: Access Scenario with SBC
+
+ 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). Despite where the SBC is
+ hosted, it is managed by the organization maintaining the operator
+ network.
+
+ Some endpoints may be behind enterprise or residential NATs. In
+ cases where the access network is a private network, the SBC is a NAT
+ for all traffic. It is noteworthy 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 subsequent requests to the
+ registered address-of-record are routed to the SBC. This is done
+ either with a Path header field [3] 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.
+
+
+
+
+
+
+
+Hautakorpi, et al. Informational [Page 7]
+
+RFC 5853 Requirements from SIP SBC Deployments April 2010
+
+
+3. Functions of SBCs
+
+ 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 (Session Description Protocol)
+ [7] messages are displayed.
+
+3.1. Topology Hiding
+
+3.1.1. General Information and Requirements
+
+ 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 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 [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 cannot be removed (e.g., From and To
+ headers), the SBC may replace these IP addresses with its own IP
+ address or domain name.
+
+ For a reference, there are also other ways of hiding topology
+ information than inserting an intermediary, like an SBC, to the
+ signaling path. One of the ways is the UA-driven privacy mechanism
+ [8], where the UA can facilitate the concealment of topology
+ information.
+
+
+
+
+
+
+Hautakorpi, et al. Informational [Page 8]
+
+RFC 5853 Requirements from SIP SBC Deployments April 2010
+
+
+3.1.2. Architectural Issues
+
+ Performing topology hiding, as described above, by SBCs that do not
+ have the users' consent presents some issues. 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 the subscriber's consent
+ and could potentially modify or remove information 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 distinguish the SBC actions from a man-in-
+ the-middle (MITM) attack.
+
+ The topology hiding function does not work well with Authenticated
+ Identity Management [4] in scenarios where the SBC does not have any
+ kind of consent from the users. 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
+ aforementioned header fields and the message body is in violation of
+ [4]. Some forms of topology hiding are in violation, because they
+ are, e.g., replacing the Contact header of a SIP message.
+
+3.1.3. Example
+
+ The current way of implementing topology hiding consists of having an
+ SBC act as a B2BUA (Back-to-Back User Agent) 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 Figure 4.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hautakorpi, et al. Informational [Page 9]
+
+RFC 5853 Requirements from SIP SBC Deployments April 2010
+
+
+ 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 Hiding
+
+ 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 Via and Record-Route header fields with its own SIP
+ URI. After the topology hiding function, the message could appear as
+ shown in 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 Hiding
+
+ 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., SBC restarts for some reason), it may not be able
+ to route messages properly (note: some SBCs preserve the state
+ information also on restart). 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. Besides topology hiding
+ (i.e., information related to the network elements is being hidden),
+ SBCs may also do identity hiding (i.e., information related to
+ identity of subscribers is being hidden). While performing identity
+ hiding, SBCs may modify Contact header field values and other header
+ fields containing identity information. The header fields containing
+ identity information is listed in Section 4.1 of [2]. Since the
+ publication of [2], the following header fields containing identity
+ information have been defined: "P-Asserted-Identity", "Referred-By",
+ "Identity", and "Identity-Info".
+
+
+
+
+
+
+
+Hautakorpi, et al. Informational [Page 10]
+
+RFC 5853 Requirements from SIP SBC Deployments April 2010
+
+
+3.2. Media Traffic Management
+
+3.2.1. General Information and Requirements
+
+ Media traffic management 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 management helps the creation of
+ different kinds of billing models (e.g., video telephony can be
+ priced differently than voice-only calls) and it also makes it
+ possible for operators to enforce the usage of selected codecs.
+
+ One of the use cases for media traffic management is the
+ implementation of intercept capabilities that are required to support
+ audit or legal obligations. It is noteworthy that the legal
+ obligations mainly apply to operators providing voice services, and
+ those operators typically have infrastructure (e.g., SIP proxies
+ acting as B2BUAs) for providing intercept capabilities even without
+ SBCs.
+
+ 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
+ management can be done, for example, to ensure a certain QoS level,
+ or to ensure that subscribers are using only allowed codecs. It is
+ noteworthy that the SBCs do not have direct ties to routing topology
+ and they do not, for example, change bandwidth reservations on
+ Traffic Engineering (TE) tunnels, nor do they have direct interaction
+ with routing protocol.
+
+ Some operators do not want to manage the traffic, but only to monitor
+ it to collect statistics and make sure that they are able to meet any
+ business service level agreements with their subscribers and/or
+ partners. The protocol techniques, from the SBC's viewpoint, needed
+ for monitoring media traffic are the same as for managing 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 clean up any state in other intermediate elements and
+ the endpoints.
+
+ One possible form of media traffic management 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 the
+
+
+
+Hautakorpi, et al. Informational [Page 11]
+
+RFC 5853 Requirements from SIP SBC Deployments April 2010
+
+
+ subscriber runs out of credits. Media management is needed to ensure
+ that the subscriber cannot just ignore the BYE request generated by
+ the SBC and continue its media sessions.
+
+3.2.2. Architectural Issues
+
+ Implementing traffic management 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
+ of Authenticated Identity Management [4], see Section 3.1.2.
+
+ The insertion of a media relay can prevent "non-media" uses of the
+ media path, for example, the media path key agreement. Sometimes
+ this type of prevention is intentional, but it is not always
+ necessary. For example, if an SBC is used just for enabling media
+ monitoring, but not for interception.
+
+ There are some possible issues related to the media relaying. If the
+ media relaying is not done in the correct manner, it may break
+ functions like Explicit Congestion Notification (ECN) and Path MTU
+ Discovery (PMTUD), for example. The media relays easily break such
+ IP and transport layer functionalities that rely on the correct
+ handling of the protocol fields. Some especially sensitive fields
+ are, for example, ECN and Type of Service (ToS) fields and the Don't
+ Fragment (DF) bit.
+
+ The way in which media traffic management functions impedes
+ innovation. The reason for the impediment is that in many cases,
+ SBCs need to be able to support new forms of communication (e.g.,
+ extensions to the SDP protocol) before new services can be put into
+ use, which slows the adoption of new innovations.
+
+ If an SBC directs many media streams through a central point in the
+ network, it is likely to cause a significant amount of additional
+ traffic to a path to that central point. This might create possible
+ bottleneck in the path.
+
+ 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.
+
+
+
+
+
+
+
+Hautakorpi, et al. Informational [Page 12]
+
+RFC 5853 Requirements from SIP SBC Deployments April 2010
+
+
+3.2.3. Example
+
+ Traffic management 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 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 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 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/2
+
+ Figure 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/8000
+
+ Figure 7: Request Body After Media Management
+
+
+
+
+
+
+Hautakorpi, et al. Informational [Page 13]
+
+RFC 5853 Requirements from SIP SBC Deployments April 2010
+
+
+ Media traffic management 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 a similar
+ problem, but with header fields, applies to, for example, topology
+ hiding function, see Section 3.1. Certain extensions that do not
+ require active manipulation of the session descriptors to facilitate
+ traffic management 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.
+
+3.3. Fixing Capability Mismatches
+
+3.3.1. General Information and Requirements
+
+ SBCs fixing capability mismatches enable communications 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
+ 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.
+
+3.3.2. Architectural Issues
+
+ SBCs that are fixing capability mismatches do it by inserting a media
+ element into the media path using the procedures described in
+ Section 3.2. Therefore, these SBCs have the same concerns as SBCs
+ performing 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.
+
+ 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.
+
+
+
+
+
+
+Hautakorpi, et al. Informational [Page 14]
+
+RFC 5853 Requirements from SIP SBC Deployments April 2010
+
+
+3.3.3. Example
+
+ 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:
+
+ 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/8000
+
+ Figure 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/8000
+
+ Figure 9: Request after Capability Match
+
+ This message is then sent by the SBC to the onward IPv6 network.
+
+3.4. Maintaining SIP-Related NAT Bindings
+
+3.4.1. General Information and Requirements
+
+ 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. The
+
+
+
+Hautakorpi, et al. Informational [Page 15]
+
+RFC 5853 Requirements from SIP SBC Deployments April 2010
+
+
+ primary purpose of NAT traversal function is to keep up a control
+ connection to user agents behind NATs. This can, for example, be
+ achieved by generating periodic network traffic that keeps bindings
+ in NATs alive. SBCs' NAT traversal function is required in scenarios
+ where the NAT is outside the SBC (i.e., not in cases where SBC itself
+ acts as a NAT).
+
+ 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.
+
+ SBCs can also force traffic to go through a media relay for NAT
+ traversal purposes (more about media traffic management in
+ Section 3.2). 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, in some cases, it is enough to relay only the
+ media from one direction (e.g., in a scenario where only the other
+ endpoint is behind a NAT).
+
+3.4.2. Architectural Issues
+
+ This approach to NAT traversal does not work if end-to-end
+ confidentiality or integrity-protection mechanisms are used (e.g.,
+ Secure/Multipurpose Internet Mail Extensions (S/MIME)). 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 of 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. Some SBCs do not have any deterministic
+
+
+
+Hautakorpi, et al. Informational [Page 16]
+
+RFC 5853 Requirements from SIP SBC Deployments April 2010
+
+
+ method for choosing a suitable value. However, SBCs can just use a
+ sub-optimal, relatively small value that usually works. An example
+ from such value is 15 seconds (see [9]).
+
+ NAT traversal for media using SBCs poses few issues as well. For
+ example, an SBC normally guesses the recipient's public IP address on
+ one of the media streams relayed by the SBC 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 on media streams it is
+ relaying. For example, an attacker may snoop on the local IP address
+ and ports used by the SBC for media relaying the streams and send a
+ few packets from a malicious IP address to these destinations. In
+ most cases, this can cause media streams in the opposite directions
+ to divert traffic to the attacker resulting in a successful MITM or
+ DoS attack. A similar example of an interoperability issue is caused
+ when an endpoint behind a NAT attempts to switch the IP address of
+ the media streams by 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 Function
+
+ When performing the NAT traversal function, the SBC may rewrite the
+ expiry time to coax the UA to re-register prior to the intermediating
+ NAT deciding to close the pinhole. Figure 11 shows a possible
+ modification of the response from Figure 10.
+
+
+
+
+
+
+
+
+
+
+Hautakorpi, et al. Informational [Page 17]
+
+RFC 5853 Requirements from SIP SBC Deployments April 2010
+
+
+ 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 Traversal
+
+ Naturally, other measures could be taken in order to enable the NAT
+ traversal (e.g., non-SIP keepalive messages), but this example
+ illustrates only 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 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 to either only the signaling or 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 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.
+
+
+
+
+
+Hautakorpi, et al. Informational [Page 18]
+
+RFC 5853 Requirements from SIP SBC Deployments April 2010
+
+
+ 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
+ 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.
+
+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 is performed for signaling and for media, then there are similar
+ problems as 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).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hautakorpi, et al. Informational [Page 19]
+
+RFC 5853 Requirements from SIP SBC Deployments April 2010
+
+
+ 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 Callflow
+
+ In 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).
+
+
+
+
+
+Hautakorpi, et al. Informational [Page 20]
+
+RFC 5853 Requirements from SIP SBC Deployments April 2010
+
+
+3.6.2. Architectural Issues
+
+ In many cases, doing protocol repair for SIP header fields 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.
+
+ However, protocol repair may break security mechanism that do
+ cryptographical computations on SIP header values. Attempting
+ protocol repair for SIP message bodies (SDP) is incompatible with
+ Authenticated Identity Management [4] and end-to-end security
+ mechanisms such as S/MIME.
+
+ A similar problem related to increasing complexity, as explained in
+ Section 3.3.2, also affects protocol repair function.
+
+3.6.3. Examples
+
+ The SBC can, for example, receive an INVITE message from a relatively
+ new SIP UA as illustrated 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 Client
+
+ If the SBC does protocol repair, it can rewrite the 'lr' parameter on
+ the Via header field into the form 'lr=true' in order 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/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 provide the ability to do legal
+
+
+
+
+
+Hautakorpi, et al. Informational [Page 21]
+
+RFC 5853 Requirements from SIP SBC Deployments April 2010
+
+
+ interception while still giving their customers the ability to
+ encrypt media in the access network. One possible way to do this is
+ to perform 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 to the media path. It
+ must be noted that this kind of behavior is the same as a classical
+ MITM attack. Due to this, the 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 Example
+
+
+
+
+Hautakorpi, et al. Informational [Page 22]
+
+RFC 5853 Requirements from SIP SBC Deployments April 2010
+
+
+ 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 User Agent
+ Server (UAS) replies with a 200 OK response and the SBCs inject
+ themselves in the returning media path. After signaling, the media
+ starts flowing, and both SBCs perform media encryption and
+ decryption.
+
+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
+
+
+
+
+Hautakorpi, et al. Informational [Page 23]
+
+RFC 5853 Requirements from SIP SBC Deployments April 2010
+
+
+ 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, often, user agents
+ cannot distinguish between the actions of an attacker and those of an
+ SBC, users cannot know whether they are being eavesdropped on or if
+ 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 type of attacks. It 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 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.
+
+
+
+
+
+
+
+
+
+Hautakorpi, et al. Informational [Page 24]
+
+RFC 5853 Requirements from SIP SBC Deployments April 2010
+
+
+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.
+
+
+
+
+Hautakorpi, et al. Informational [Page 25]
+
+RFC 5853 Requirements from SIP SBC Deployments April 2010
+
+
+Authors' Addresses
+
+ Jani Hautakorpi (editor)
+ Ericsson
+ Hirsalantie 11
+ Jorvas 02420
+ Finland
+
+ EMail: Jani.Hautakorpi@ericsson.com
+
+
+ Gonzalo Camarillo
+ Ericsson
+ Hirsalantie 11
+ Jorvas 02420
+ Finland
+
+ EMail: Gonzalo.Camarillo@ericsson.com
+
+
+ Robert F. Penfield
+ Acme Packet
+ 71 Third Avenue
+ Burlington, MA 01803
+ US
+
+ EMail: bpenfield@acmepacket.com
+
+
+ Alan Hawrylyshen
+ Skype, Inc.
+ 2055 E. Hamilton Ave
+ San Jose, CA 95125
+ US
+
+ EMail: alan.ietf@polyphase.ca
+
+
+ Medhavi Bhatia
+ 3CLogic
+ 9700 Great Seneca Hwy.
+ Rockville, MD 20850
+ US
+
+ EMail: mbhatia@3clogic.com
+
+
+
+
+
+
+Hautakorpi, et al. Informational [Page 26]
+