draft-ietf-sipping-sbc-funcs-03.txt   draft-ietf-sipping-sbc-funcs-04.txt 
SIPPING Working Group J. Hautakorpi, Ed. SIPPING Working Group J. Hautakorpi, Ed.
Internet-Draft G. Camarillo Internet-Draft G. Camarillo
Intended status: Informational Ericsson Intended status: Informational Ericsson
Expires: October 19, 2007 R. Penfield Expires: June 23, 2008 R. Penfield
Acme Packet Acme Packet
A. Hawrylyshen A. Hawrylyshen
Ditech Networks Inc. Ditech Networks Inc.
M. Bhatia M. Bhatia
3CLogic 3CLogic
April 17, 2007 December 21, 2007
Requirements from SIP (Session Initiation Protocol) Session Border Requirements from SIP (Session Initiation Protocol) Session Border
Control Deployments Control Deployments
draft-ietf-sipping-sbc-funcs-03.txt draft-ietf-sipping-sbc-funcs-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 41 skipping to change at page 1, line 41
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 19, 2007. This Internet-Draft will expire on June 23, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes functions implemented in Session Initiation This document describes functions implemented in Session Initiation
Protocol (SIP) intermediaries known as Session Border Controllers Protocol (SIP) intermediaries known as Session Border Controllers
(SBCs). The goal of this document is to describe the commonly (SBCs). The goal of this document is to describe the commonly
skipping to change at page 3, line 16 skipping to change at page 3, line 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Background on SBCs . . . . . . . . . . . . . . . . . . . . . . 4 2. Background on SBCs . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Peering Scenario . . . . . . . . . . . . . . . . . . . . . 5 2.1. Peering Scenario . . . . . . . . . . . . . . . . . . . . . 5
2.2. Access Scenario . . . . . . . . . . . . . . . . . . . . . 6 2.2. Access Scenario . . . . . . . . . . . . . . . . . . . . . 6
3. Functions of SBCs . . . . . . . . . . . . . . . . . . . . . . 7 3. Functions of SBCs . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Topology Hiding . . . . . . . . . . . . . . . . . . . . . 8 3.1. Topology Hiding . . . . . . . . . . . . . . . . . . . . . 8
3.1.1. General Information and Requirements . . . . . . . . . 8 3.1.1. General Information and Requirements . . . . . . . . . 8
3.1.2. Architectural Issues . . . . . . . . . . . . . . . . . 8 3.1.2. Architectural Issues . . . . . . . . . . . . . . . . . 8
3.1.3. Example . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.3. Example . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Media Traffic Shaping . . . . . . . . . . . . . . . . . . 10 3.2. Media Traffic Management . . . . . . . . . . . . . . . . . 10
3.2.1. General Information and Requirements . . . . . . . . . 10 3.2.1. General Information and Requirements . . . . . . . . . 10
3.2.2. Architectural Issues . . . . . . . . . . . . . . . . . 10 3.2.2. Architectural Issues . . . . . . . . . . . . . . . . . 11
3.2.3. Example . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.3. Example . . . . . . . . . . . . . . . . . . . . . . . 11
3.3. Fixing Capability Mismatches . . . . . . . . . . . . . . . 12 3.3. Fixing Capability Mismatches . . . . . . . . . . . . . . . 12
3.3.1. General Information and Requirements . . . . . . . . . 12 3.3.1. General Information and Requirements . . . . . . . . . 12
3.3.2. Architectural Issues . . . . . . . . . . . . . . . . . 12 3.3.2. Architectural Issues . . . . . . . . . . . . . . . . . 13
3.3.3. Example . . . . . . . . . . . . . . . . . . . . . . . 13 3.3.3. Example . . . . . . . . . . . . . . . . . . . . . . . 13
3.4. Maintaining SIP-related NAT Bindings . . . . . . . . . . . 14 3.4. Maintaining SIP-related NAT Bindings . . . . . . . . . . . 14
3.4.1. General Information and Requirements . . . . . . . . . 14 3.4.1. General Information and Requirements . . . . . . . . . 14
3.4.2. Architectural Issues . . . . . . . . . . . . . . . . . 15 3.4.2. Architectural Issues . . . . . . . . . . . . . . . . . 15
3.4.3. Example . . . . . . . . . . . . . . . . . . . . . . . 15 3.4.3. Example . . . . . . . . . . . . . . . . . . . . . . . 15
3.5. Access Control . . . . . . . . . . . . . . . . . . . . . . 16 3.5. Access Control . . . . . . . . . . . . . . . . . . . . . . 16
3.5.1. General Information and Requirements . . . . . . . . . 16 3.5.1. General Information and Requirements . . . . . . . . . 16
3.5.2. Architectural Issues . . . . . . . . . . . . . . . . . 16 3.5.2. Architectural Issues . . . . . . . . . . . . . . . . . 17
3.5.3. Example . . . . . . . . . . . . . . . . . . . . . . . 17 3.5.3. Example . . . . . . . . . . . . . . . . . . . . . . . 17
3.6. Protocol Repair . . . . . . . . . . . . . . . . . . . . . 17 3.6. Protocol Repair . . . . . . . . . . . . . . . . . . . . . 18
3.6.1. General Information and Requirements . . . . . . . . . 17 3.6.1. General Information and Requirements . . . . . . . . . 18
3.6.2. Architectural Issues . . . . . . . . . . . . . . . . . 18 3.6.2. Architectural Issues . . . . . . . . . . . . . . . . . 18
3.6.3. Examples . . . . . . . . . . . . . . . . . . . . . . . 18 3.6.3. Examples . . . . . . . . . . . . . . . . . . . . . . . 18
3.7. Media Encryption . . . . . . . . . . . . . . . . . . . . . 18 3.7. Media Encryption . . . . . . . . . . . . . . . . . . . . . 19
3.7.1. General Information and Requirements . . . . . . . . . 18 3.7.1. General Information and Requirements . . . . . . . . . 19
3.7.2. Architectural Issues . . . . . . . . . . . . . . . . . 19 3.7.2. Architectural Issues . . . . . . . . . . . . . . . . . 19
3.7.3. Example . . . . . . . . . . . . . . . . . . . . . . . 19 3.7.3. Example . . . . . . . . . . . . . . . . . . . . . . . 19
4. Derived Requirements for Future SIP Standardization Work . . . 20 4. Derived Requirements for Future SIP Standardization Work . . . 20
5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 8.1. Normative References . . . . . . . . . . . . . . . . . . . 22
8.2. Informational References . . . . . . . . . . . . . . . . . 21 8.2. Informational References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 23 Intellectual Property and Copyright Statements . . . . . . . . . . 24
1. Introduction 1. Introduction
In the past few years there has been a rapid adoption of the Session In the past few years there has been a rapid adoption of the Session
Initiation Protocol (SIP) [1] and deployment of SIP-based Initiation Protocol (SIP) [1] and deployment of SIP-based
communications networks. This has often outpaced the development and communications networks. This has often outpaced the development and
implementation of protocol specifications to meet network operator implementation of protocol specifications to meet network operator
requirements. This has led to the development of proprietary requirements. This has led to the development of proprietary
solutions. Often, these proprietary solutions are implemented in solutions. Often, these proprietary solutions are implemented in
network intermediaries known in the marketplace as Session Border network intermediaries known in the marketplace as Session Border
skipping to change at page 4, line 47 skipping to change at page 4, line 47
not implement SIP are outside the scope of this document. not implement SIP are outside the scope of this document.
SBCs usually sit between two service provider networks in a peering SBCs usually sit between two service provider networks in a peering
environment, or between an access network and a backbone network to environment, or between an access network and a backbone network to
provide service to residential and/or enterprise customers. They provide service to residential and/or enterprise customers. They
provide a variety of functions to enable or enhance session-based provide a variety of functions to enable or enhance session-based
multi-media services (e.g., Voice over IP). These functions include: multi-media services (e.g., Voice over IP). These functions include:
a) perimeter defense (access control, topology hiding, and DoS a) perimeter defense (access control, topology hiding, and DoS
prevention and detection); b) functionality not available in the prevention and detection); b) functionality not available in the
endpoints (NAT traversal, protocol interworking or repair); and c) endpoints (NAT traversal, protocol interworking or repair); and c)
network management (traffic monitoring, shaping, and QoS). Some of network management (traffic monitoring, management, and QoS). Some
these functions may also get integrated into other SIP elements (like of these functions may also get integrated into other SIP elements
pre-paid platforms, 3GPP P-CSCF [5], 3GPP I-CSCF, etc). (like pre-paid platforms, 3GPP P-CSCF [5], 3GPP I-CSCF, etc).
SIP-based SBCs typically handle both signaling and media and can SIP-based SBCs typically handle both signaling and media and can
implement behavior which is equivalent to a "privacy service" (as implement behavior which is equivalent to a "privacy service" (as
described in[2]) performing both Header Privacy and Session Privacy). described in[2]) performing both Header Privacy and Session Privacy).
SBCs often modify certain SIP headers and message bodies that proxies SBCs often modify certain SIP headers and message bodies that proxies
are not allowed to modify. Consequently, they are, by definition, are not allowed to modify. Consequently, they are, by definition,
B2BUAs (Back-to-Back User Agents). The transparency of these B2BUAs B2BUAs (Back-to-Back User Agents). The transparency of these B2BUAs
varies depending on the functions they perform. For example, some varies depending on the functions they perform. For example, some
SBCs modify the session description carried in the message and insert SBCs modify the session description carried in the message and insert
a Record-Route entry. Other SBCs replace the value of the Contact a Record-Route entry. Other SBCs replace the value of the Contact
skipping to change at page 6, line 22 skipping to change at page 6, line 22
+-----+ 1) INVITE +-----+--/ / +-----+ +-----+ 1) INVITE +-----+--/ / +-----+
|GW-A1|---------------->| SBC |<---/ 4) INVITE |GW-B1| |GW-A1|---------------->| SBC |<---/ 4) INVITE |GW-B1|
+-----+ +-----+---------------------->+-----+ +-----+ +-----+---------------------->+-----+
. .
+-----+ . +-----+ +-----+ . +-----+
|GW-A2| . |GW-B2| |GW-A2| . |GW-B2|
+-----+ . +-----+ +-----+ . +-----+
Figure 2: Peering with SBC Figure 2: Peering with SBC
Figure 2 illustrates the peering arrangement with a SBC where Figure 2 illustrates the peering arrangement with an SBC where
Operator A is the outer network, and Operator B is the inner network. 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 Operator B can use the SBC, for example, to control access to its
network, protect its gateways and softswitches from unauthorized use network, protect its gateways and softswitches from unauthorized use
and DoS attacks, and monitor the signaling and media traffic. It and DoS attacks, and monitor the signaling and media traffic. It
also simplifies network management by minimizing the number ACL also simplifies network management by minimizing the number ACL
(Access Control List) entries in the gateways. The gateways do not (Access Control List) entries in the gateways. The gateways do not
need to be exposed to the peer network, and they can restrict access 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 (both media and signaling) to the SBCs. The SBC helps ensure that
only media from sessions the SBC authorizes will reach the gateway. only media from sessions the SBC authorizes will reach the gateway.
skipping to change at page 8, line 49 skipping to change at page 8, line 49
applications which are communicating end-to-end using SIP. Neither applications which are communicating end-to-end using SIP. Neither
user agent in an end-to-end call has any way to distinguish the SBC user agent in an end-to-end call has any way to distinguish the SBC
actions from a Man-In-The-Middle (MitM) attack. actions from a Man-In-The-Middle (MitM) attack.
Topology hiding function does not work well with Authenticated Topology hiding function does not work well with Authenticated
Identity Management [3]. The Authenticated Identity Management Identity Management [3]. The Authenticated Identity Management
mechanism is based on a hash value that is calculated from parts of 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 From, To, Call-Id, CSeq, Date, and Contact header fields plus from
the whole message body. If the authentication service is not the whole message body. If the authentication service is not
provided by the SBC itself, the modification of the forementioned provided by the SBC itself, the modification of the forementioned
header fields and the message body is in violation with [3]. Some header fields and the message body is in violation of [3]. Some
forms of topology hiding are in violation, because they are e.g., forms of topology hiding are in violation, because they are e.g.,
replacing the Contact header of a SIP message. replacing the Contact header of a SIP message.
3.1.3. Example 3.1.3. Example
The current way of implementing topology hiding consists of having an The current way of implementing topology hiding consists of having an
SBC act as a B2BUA (Back-to-Back User Agents) and remove all traces SBC act as a B2BUA (Back-to-Back User Agents) and remove all traces
of topology information (e.g., Via and Record-Route entries) from of topology information (e.g., Via and Record-Route entries) from
outgoing messages. outgoing messages.
skipping to change at page 10, line 4 skipping to change at page 10, line 4
SBC handles every single message of a given SIP dialog. If the SBC SBC handles every single message of a given SIP dialog. If the SBC
loses state (e.g., the SBC restarts for some reason), it may not be loses state (e.g., the SBC restarts for some reason), it may not be
able to route messages properly. For example, if the SBC removes able to route messages properly. For example, if the SBC removes
"Via" entries from a request and then restarts, thus losing state, "Via" entries from a request and then restarts, thus losing state,
the SBC may not be able to route responses to that request; depending the SBC may not be able to route responses to that request; depending
on the information that was lost when the SBC restarted. on the information that was lost when the SBC restarted.
This is only one example of topology hiding. In some cases, SBCs may This is only one example of topology hiding. In some cases, SBCs may
modify other headers, including the Contact header field values. The modify other headers, including the Contact header field values. The
header fields containing identity information is listed in Section header fields containing identity information is listed in Section
4.1 of [2]. 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".
3.2. Media Traffic Shaping 3.2. Media Traffic Management
3.2.1. General Information and Requirements 3.2.1. General Information and Requirements
Media traffic shaping is the function of controlling media traffic. Media traffic management is the function of controlling media
Network operators may require this functionality in order to control traffic. Network operators may require this functionality in order
the traffic being carried on their network on behalf of their to control the traffic being carried on their network on behalf of
subscribers. Traffic shaping helps the creation of different kinds their subscribers. Traffic management helps the creation of
of billing models (e.g., video telephony can be priced differently to different kinds of billing models (e.g., video telephony can be
voice-only calls) and it also makes it possible for operators to priced differently to voice-only calls) and it also makes it possible
enforce the usage of selected codecs. Additionally, traffic shaping for operators to enforce the usage of selected codecs. Additionally,
can be used to implement intercept capabilities where required to traffic management can be used to implement intercept capabilities
support audit or legal obligations. where required to support audit or legal obligations.
Since the media path is independent of the signaling path, the media Since the media path is independent of the signaling path, the media
may not traverse through the operator's network unless the SBC may not traverse through the operator's network unless the SBC
modifies the session description. By modifying the session modifies the session description. By modifying the session
description the SBC can force the media to be sent through a media 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 relay which may be co-located with the SBC. This kind of traffic
shaping can be done, for example, to ensure a certain QoS (Quality of management can be done, for example, to ensure a certain QoS (Quality
Service) level. of Service) level.
Some operators do not want to reshape the traffic (e.g., allowing Some operators do not want to manage the traffic (e.g., allowing only
only certain codecs), but only to monitor it for collecting certain codecs), but only to monitor it for collecting statistics and
statistics and making sure that they are able to meet any business making sure that they are able to meet any business service level
service level agreements with their subscribers and/or partners. The agreements with their subscribers and/or partners. The protocol
protocol techniques needed for monitoring media traffic are the same techniques needed for monitoring media traffic are the same as for
as for reshaping media traffic. managing media traffic.
SBCs on the media path are also capable of dealing with the "lost 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 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 SBC can detect that the media has stopped flowing and issue a BYE to
both sides to cleanup any state in other intermediate elements and both sides to cleanup any state in other intermediate elements and
the endpoints. the endpoints.
One possible form of media traffic shaping is that SBCs terminate One possible form of media traffic management is that SBCs terminate
media streams and SIP dialogs by generating BYE requests. This kind media streams and SIP dialogs by generating BYE requests. This kind
of procedure can take place, for example, in a situation where of procedure can take place, for example, in a situation where
subscriber runs out of credits. subscriber runs out of credits. Media management is needed for
ensuring that the subscriber cannot just ignore the BYE request
generated by the SBC and continue their media sessions.
3.2.2. Architectural Issues 3.2.2. Architectural Issues
Implementing traffic shaping in this manner requires the SBC to Implementing traffic management in this manner requires the SBC to
access and modify the session descriptions (i.e., offers and answers) access and modify the session descriptions (i.e., offers and answers)
exchanged between the user-agents. Consequently, this approach does exchanged between the user-agents. Consequently, this approach does
not work if user-agents encrypt or integrity-protect their message not work if user-agents encrypt or integrity-protect their message
bodies end-to-end. Again, messages are modified without subscriber bodies end-to-end. Again, messages are modified without subscriber
consent, and user-agents do not have any way to distinguish the SBC 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 actions from an attack by a MitM. Furthermore, this is in violation
with [3], see Section 3.1.2. of [3], see Section 3.1.2.
Media traffic management function also hinders innovations. The
reason for the hinderance is that in many cases SBCs need to be able
to support new ways of communicating (e.g., extensions to the SDP
protocol) before new services can be taken into use, and that slows
down the adoption of innovations.
In this application, the SBC may originate messages that the user may 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 not be able to authenticate as coming from the dialog peer or the SIP
Registrar/Proxy. Registrar/Proxy.
3.2.3. Example 3.2.3. Example
Traffic shaping may be performed in the following way: The SBC Traffic management may be performed in the following way: The SBC
behaves as a B2BUA and inserts itself, or some other entity under the 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 operator's control, in the media path. In practice, the SBC modifies
the session descriptions carried in the SIP messages. As a result, 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 the SBC receives media from one user-agent and relays it to the other
user-agent and performs the identical operation with media traveling user-agent and performs the identical operation with media traveling
in the reverse direction. in the reverse direction.
As mentioned in Section 3.2.1, codec restriction is a form of traffic As mentioned in Section 3.2.1, codec restriction is a form of traffic
shaping. The SBC restricts the codec set negotiated in the offer/ management. The SBC restricts the codec set negotiated in the offer/
answer exchange [4] between the user-agents. After modifying the answer exchange [4] between the user-agents. After modifying the
session descriptions, the SBC can check whether or not the media session descriptions, the SBC can check whether or not the media
stream corresponds to what was negotiated in the offer/answer stream corresponds to what was negotiated in the offer/answer
exchange. If it differs, the SBC has the ability to terminate the exchange. If it differs, the SBC has the ability to terminate the
media stream or take other appropriate (configured) actions (e.g. media stream or take other appropriate (configured) actions (e.g.
raise an alarm). raise an alarm).
Consider the following example scenario: The SBC receives an INVITE Consider the following example scenario: The SBC receives an INVITE
request from the outer network, which in this case is an access request from the outer network, which in this case is an access
network. The received SIP message contains the SDP session network. The received SIP message contains the SDP session
descriptor shown in Figure 6. descriptor shown in Figure 6.
v=0 v=0
o=mhandley 2890844526 2890842807 IN IP4 192.0.2.4 o=mhandley 2890844526 2890842807 IN IP4 192.0.2.4
c=IN IP4 192.0.2.4 c=IN IP4 192.0.2.4
m=audio 49230 RTP/AVP 96 98 m=audio 49230 RTP/AVP 96 98
a=rtpmap:96 L8/8000 a=rtpmap:96 L8/8000
a=rtpmap:98 L16/16000/2 a=rtpmap:98 L16/16000/2
Figure 6: Request Prior to Media Shaping Figure 6: Request Prior to Media Management
In this example, the SBC performs the media traffic shaping function In this example, the SBC performs the media traffic management
by rewriting the 'm' line, and removing one 'a' line according to function by rewriting the 'm' line, and removing one 'a' line
some (external) policy. Figure 7 shows the session description after according to some (external) policy. Figure 7 shows the session
the traffic shaping function. description after the traffic management function.
v=0 v=0
o=mhandley 2890844526 2890842807 IN IP4 192.0.2.4 o=mhandley 2890844526 2890842807 IN IP4 192.0.2.4
c=IN IP4 192.0.2.4 c=IN IP4 192.0.2.4
m=audio 49230 RTP/AVP 96 m=audio 49230 RTP/AVP 96
a=rtpmap:96 L8/8000 a=rtpmap:96 L8/8000
Figure 7: Request Body After Media Shaping Figure 7: Request Body After Media Management
Media traffic shaping has a problem where the SBC needs to understand Media traffic management has a problem where the SBC needs to
the session description protocol and all extensions used by the user- understand the session description protocol and all extensions used
agents. This means that in order to use a new extension (e.g., an by the user-agents. This means that in order to use a new extension
extension to implement a new service) or a new session description (e.g., an extension to implement a new service) or a new session
protocol, SBCs in the network may need to be upgraded in conjunction description protocol, SBCs in the network may need to be upgraded in
with the endpoints. It is noteworthy that similar problem, but with conjunction with the endpoints. It is noteworthy that similar
header fields, applies to, for example, topology hiding function, see problem, but with header fields, applies to, for example, topology
Section 3.1. Certain extensions that do not require active hiding function, see Section 3.1. Certain extensions that do not
manipulation of the session descriptors to facilitate traffic shaping require active manipulation of the session descriptors to facilitate
will be able to be deployed without upgrading existing SBCs, traffic management will be able to be deployed without upgrading
depending on the degree of transparency the SBC implementation existing SBCs, depending on the degree of transparency the SBC
affords. In cases requiring an SBC modification to support the new implementation affords. In cases requiring an SBC modification to
protocol features, the rate of service deployment may be affected. support the new protocol features, the rate of service deployment may
be affected.
3.3. Fixing Capability Mismatches 3.3. Fixing Capability Mismatches
3.3.1. General Information and Requirements 3.3.1. General Information and Requirements
SBCs fixing capability mismatches enable communications between user- SBCs fixing capability mismatches enable communications between user-
agents with different capabilities or extensions. For example, user- agents with different capabilities or extensions. For example, user-
agents on networks which implement SIP differently (for example 3GPP agents on networks which implement SIP differently (for example 3GPP
or Packet Cable etc) or those that support different IP versions, or Packet Cable etc) or those that support different IP versions,
different codecs, or that are in different address realms. Operators different codecs, or that are in different address realms. Operators
skipping to change at page 12, line 47 skipping to change at page 13, line 13
mismatch fixing, so that they can provide transparent communication mismatch fixing, so that they can provide transparent communication
across different domains. In some cases different SIP extensions or across different domains. In some cases different SIP extensions or
methods to implement the same SIP application (like monitoring methods to implement the same SIP application (like monitoring
session liveness, call history/diversion etc) may also be interworked session liveness, call history/diversion etc) may also be interworked
through the SBC. through the SBC.
3.3.2. Architectural Issues 3.3.2. Architectural Issues
SBCs fixing capability mismatches insert a media element in the media SBCs fixing capability mismatches insert a media element in the media
path using the procedures described in Section 3.2. Therefore, these path using the procedures described in Section 3.2. Therefore, these
SBCs have the same concerns as SBCs performing traffic shaping: the SBCs have the same concerns as SBCs performing traffic management:
SBC modifies SIP messages without explicit consent from any of the the SBC modifies SIP messages without explicit consent from any of
user-agents. This may break end-to-end security and application the user-agents. This may break end-to-end security and application
extensions negotiation. extensions negotiation.
The capability mismatch fixing is a fragile function in the long The capability mismatch fixing is a fragile function in the long
term. The number of incompatibilities built into various network term. The number of incompatibilities built into various network
elements is increasing the fragility and complexity over time. This elements is increasing the fragility and complexity over time. This
might lead to a situation where SBCs need to be able to handle a might lead to a situation where SBCs need to be able to handle a
large number of capability mismatches in parallel. large number of capability mismatches in parallel.
3.3.3. Example 3.3.3. Example
skipping to change at page 14, line 44 skipping to change at page 15, line 11
Operators implement this functionality in an SBC instead of in the Operators implement this functionality in an SBC instead of in the
registrar for several reasons: (i) preventing packets from registrar for several reasons: (i) preventing packets from
unregistered users to prevent chances of DoS attack, (ii) unregistered users to prevent chances of DoS attack, (ii)
prioritization and/or re-routing of traffic (based on user or prioritization and/or re-routing of traffic (based on user or
service, like E911) as it enters the network, and (iii) performing a service, like E911) as it enters the network, and (iii) performing a
load balancing function or reducing the load on other network load balancing function or reducing the load on other network
equipment. equipment.
SBCs can also force traffic to go through a media relay for NAT SBCs can also force traffic to go through a media relay for NAT
traversal purposes (more about media traffic shaping in Section 3.2). traversal purposes (more about media traffic management in
A typical call has media streams to two directions. Even though SBCs Section 3.2). A typical call has media streams to two directions.
can force media streams from both directions to go through a media Even though SBCs can force media streams from both directions to go
relay, it is usually enough to relay only the media from one through a media relay, in some cases it is enough to relay only the
direction. media from one direction (e.g., in a scenario where only other
endpoint is behind a NAT).
3.4.2. Architectural Issues 3.4.2. Architectural Issues
This approach to NAT traversal does not work when end-to-end This approach to NAT traversal does not work when end-to-end
confidentiality or integrity-protection is used. The SBC would be confidentiality or integrity-protection is used. The SBC would be
seen as a MitM modifying the messages between the user-agent and the seen as a MitM modifying the messages between the user-agent and the
registrar. registrar.
There is also a problem related to the method how SBCs choose the There is also a problem related to the method how SBCs choose the
value for the validity of a registration period. This value should value for the validity of a registration period. This value should
skipping to change at page 17, line 41 skipping to change at page 18, line 5
| | | | | |
Figure 12: Example Access Callflow Figure 12: Example Access Callflow
In this scenario, the SBC first identifies the caller, so it can In this scenario, the SBC first identifies the caller, so it can
determine whether or not to give signaling access for the caller. determine whether or not to give signaling access for the caller.
This might be achieved using information gathered during This might be achieved using information gathered during
registration, or by other means. Some SBCs may rely on the proxy to registration, or by other means. Some SBCs may rely on the proxy to
authenticate the user-agent placing the call. After identification, authenticate the user-agent placing the call. After identification,
the SBC modifies the session descriptors in INVITE and 200 OK the SBC modifies the session descriptors in INVITE and 200 OK
messages in a way that the media is going to flow through SBC itself. messages in a way that the media is going to flow through the SBC
When the media starts flowing, the SBC can inspect whether the callee itself. When the media starts flowing, the SBC can inspect whether
and caller use the codec(s) that they had previously agreed on. the callee and caller use the codec(s) that they had previously
agreed on.
3.6. Protocol Repair 3.6. Protocol Repair
3.6.1. General Information and Requirements 3.6.1. General Information and Requirements
SBC are also used to repair protocol messages generated by not-fully- SBCs are also used to repair protocol messages generated by not-
standard clients. Operators may wish to support protocol repair, if fully-standard clients. Operators may wish to support protocol
they want to support as many clients as possible. It is noteworthy, repair, if they want to support as many clients as possible. It is
that this function affects only the signaling component of SBC, and noteworthy, that this function affects only the signaling component
that protocol repair function is not the same as protocol conversion. of an SBC, and that protocol repair function is not the same as
protocol conversion.
3.6.2. Architectural Issues 3.6.2. Architectural Issues
In most cases, this function can be seen as being compatible with SIP In most cases, this function can be seen as being compatible with SIP
architectural principles, and it does not violate the end-to-end architectural principles, and it does not violate the end-to-end
model of SIP. The SBC repairing protocol messages behaves as a proxy 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 server that is liberal in what it accepts and strict in what it
sends. sends.
A similar problem related to increasing complexity, as explained in A similar problem related to increasing complexity, as explained in
skipping to change at page 19, line 8 skipping to change at page 19, line 21
the access network (outer network) side and the media is carried the access network (outer network) side and the media is carried
unencrypted in the inner network. Operators may have an obligation unencrypted in the inner network. Operators may have an obligation
to provide the ability to do legal interception, while they still to provide the ability to do legal interception, while they still
want to give their customers the ability to encrypt media in the want to give their customers the ability to encrypt media in the
access network. This leads to a situation where operators have a access network. This leads to a situation where operators have a
requirement to perform media encryption function. requirement to perform media encryption function.
3.7.2. Architectural Issues 3.7.2. Architectural Issues
While performing a media encryption function, SBCs need to be able to While performing a media encryption function, SBCs need to be able to
inject either themselves, or some other entity to the media path. inject either themselves, or some other entity to the media path. It
Due to this, the SBCs have the same architectural issues as explained must be noted that this kind of behavior is the same as a classical
in Section 3.2. MitM attack. Due to this, the SBCs have the same architectural
issues as explained in Section 3.2.
3.7.3. Example 3.7.3. Example
Figure 14 shows an example where the SBC is performing media Figure 14 shows an example where the SBC is performing media
encryption related functions (ACKs omitted for brevity). encryption related functions (ACKs omitted for brevity).
caller SBC#1 SBC#2 callee caller SBC#1 SBC#2 callee
| | | | | | | |
| INVITE + SDP | | | | INVITE + SDP | | |
|------------------->| | | |------------------->| | |
skipping to change at page 20, line 9 skipping to change at page 20, line 46
First the UAC sends an INVITE request , and the first SBC modifies 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 the session descriptor in a way that it injects itself to the media
path. The same happens in the second SBC. Then the UAS replies with path. The same happens in the second SBC. Then the UAS replies with
a 200 OK response, the SBCs inject themselves in the returning media a 200 OK response, the SBCs inject themselves in the returning media
path. After signaling the media start flowing, and both SBCs are path. After signaling the media start flowing, and both SBCs are
performing media encryption and decryption. performing media encryption and decryption.
4. Derived Requirements for Future SIP Standardization Work 4. Derived Requirements for Future SIP Standardization Work
Some of the functions listed in this document are more SIP-unfriendly Some of the functions listed in this document are more SIP-unfriendly
than others. This list requirements that are derived from the than others. This list of requirements is derived from the functions
functions that break the principles of SIP in one way or another. that break the principles of SIP in one way or another. The derived
The derived requirements are: requirements are:
Req-1: There should be a SIP-friendly way to hide network topology Req-1: There should be a SIP-friendly way to hide network topology
information. Currently this is done by stripping and information. Currently this is done by stripping and
replacing header fields, which is against the principles of replacing header fields, which is against the principles of
SIP. SIP.
Req-2: There should be a SIP-friendly way to direct media traffic Req-2: There should be a SIP-friendly way to direct media traffic
through intermediaries. Currently this is done without user through intermediaries. Currently this is done without user
consent by modifying session descriptors, which is against consent by modifying session descriptors, which is against
the principles of SIP. the principles of SIP.
Req-3: There should be a SIP-friendly way to fix capability Req-3: There should be a SIP-friendly way to fix capability
mismatches in SIP messages. This requirement is harder to mismatches in SIP messages. This requirement is harder to
fulfill on complex mismatch cases, like the 3GPP/Packet Cable fulfill on complex mismatch cases, like the 3GPP/Packet Cable
mismatch. Currently this is done by modifying SIP messages, mismatch. Currently this is done by modifying SIP messages,
which violates end-to-end security. which violates end-to-end security.
All the above-mentioned requirements are such that they do not have Req-1 and Req-3 does not have an exiting solution today. There is
an existing solution today. Thus, future work is needed in order to ongoing work in the IETF for addressing Req-2, such as SIP session
develop solutions to these requirements. policies, Traversal Using Relays around NAT (TURN), and Interactive
Connectivity Establishment (ICE). Nonetheless, future work is needed
in order to develop solutions to these requirements.
5. Security Considerations 5. Security Considerations
Many of the functions this document describes have important security Many of the functions this document describes have important security
and privacy implications. One major security problem is that many and privacy implications. One major security problem is that many
functions implemented by SBCs (e.g., topology hiding and media functions implemented by SBCs (e.g., topology hiding and media
traffic shaping) modify SIP messages and their bodies without the traffic management) modify SIP messages and their bodies without the
user agents' consent. The result is that the user agents may user agents' consent. The result is that the user agents may
interpreted the actions taken by SBC as a MitM attack. interpret the actions taken by an SBC as a MitM attack.
SBCs that place themselves (or another entity) on the media path can SBCs that place themselves (or another entity) on the media path can
be used to eavesdrop conversations. Since, often, user agents cannot be used to eavesdrop on conversations. Since, often, user agents
distinguish between the actions of an attacker and those of a SBC, cannot distinguish between the actions of an attacker and those of an
users cannot know whether they are being eavesdropped or a SBC on the SBC, users cannot know whether they are being eavesdropped or an SBC
path is performing some other function. on the path is performing some other function.
A SBC is a single point of failure form the architectural point of 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 view. This makes it an attractive target for DoS attacks. The fact
that some functions of SBCs require those SBCs to maintain session that some functions of SBCs require those SBCs to maintain session
specific information makes the situation even worse. If the SBC specific information makes the situation even worse. If the SBC
crashes (or is brought down by an attacker), ongoing sessions crashes (or is brought down by an attacker), ongoing sessions
experience undetermined behavior. experience undetermined behavior.
If the IETF decides to develop standard mechanisms to address the If the IETF decides to develop standard mechanisms to address the
requirements presented in Section 4, the security and privacy-related requirements presented in Section 4, the security and privacy-related
aspects of those mechanisms will, of course, need to be taken into aspects of those mechanisms will, of course, need to be taken into
consideration. consideration.
skipping to change at page 21, line 47 skipping to change at page 22, line 40
RFC 4474, August 2006. RFC 4474, August 2006.
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002. Session Description Protocol (SDP)", RFC 3264, June 2002.
8.2. Informational References 8.2. Informational References
[5] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP TS 23.228 [5] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP TS 23.228
5.15.0, June 2006. 5.15.0, June 2006.
[6] Handley, M. and V. Jacobson, "SDP: Session Description [6] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Protocol", RFC 2327, April 1998. Description Protocol", RFC 4566, July 2006.
Authors' Addresses Authors' Addresses
Jani Hautakorpi (editor) Jani Hautakorpi (editor)
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: Jani.Hautakorpi@ericsson.com Email: Jani.Hautakorpi@ericsson.com
 End of changes. 42 change blocks. 
102 lines changed or deleted 120 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/