draft-ietf-sipping-sbc-funcs-05.txt   draft-ietf-sipping-sbc-funcs-06.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: September 26, 2008 R. Penfield Expires: December 18, 2008 R. Penfield
Acme Packet Acme Packet
A. Hawrylyshen A. Hawrylyshen
Ditech Networks Inc. Ditech Networks Inc.
M. Bhatia M. Bhatia
3CLogic 3CLogic
March 25, 2008 June 16, 2008
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-05.txt draft-ietf-sipping-sbc-funcs-06.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 September 26, 2008. This Internet-Draft will expire on December 18, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
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 11 skipping to change at page 3, line 11
practices in order to identify protocol requirements and determine practices in order to identify protocol requirements and determine
whether those requirements are satisfied by existing specifications whether those requirements are satisfied by existing specifications
or additional standards work is required. or additional standards work is required.
Table of Contents Table of Contents
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 . . . . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . . 9
3.1.3. Example . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.3. Example . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Media Traffic Management . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . 11 3.2.2. Architectural Issues . . . . . . . . . . . . . . . . . 11
3.2.3. Example . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.3. Example . . . . . . . . . . . . . . . . . . . . . . . 12
3.3. Fixing Capability Mismatches . . . . . . . . . . . . . . . 12 3.3. Fixing Capability Mismatches . . . . . . . . . . . . . . . 13
3.3.1. General Information and Requirements . . . . . . . . . 12 3.3.1. General Information and Requirements . . . . . . . . . 13
3.3.2. Architectural Issues . . . . . . . . . . . . . . . . . 13 3.3.2. Architectural Issues . . . . . . . . . . . . . . . . . 14
3.3.3. Example . . . . . . . . . . . . . . . . . . . . . . . 13 3.3.3. Example . . . . . . . . . . . . . . . . . . . . . . . 14
3.4. Maintaining SIP-related NAT Bindings . . . . . . . . . . . 14 3.4. Maintaining SIP-related NAT Bindings . . . . . . . . . . . 15
3.4.1. General Information and Requirements . . . . . . . . . 14 3.4.1. General Information and Requirements . . . . . . . . . 15
3.4.2. Architectural Issues . . . . . . . . . . . . . . . . . 15 3.4.2. Architectural Issues . . . . . . . . . . . . . . . . . 16
3.4.3. Example . . . . . . . . . . . . . . . . . . . . . . . 15 3.4.3. Example . . . . . . . . . . . . . . . . . . . . . . . 16
3.5. Access Control . . . . . . . . . . . . . . . . . . . . . . 16 3.5. Access Control . . . . . . . . . . . . . . . . . . . . . . 17
3.5.1. General Information and Requirements . . . . . . . . . 16 3.5.1. General Information and Requirements . . . . . . . . . 17
3.5.2. Architectural Issues . . . . . . . . . . . . . . . . . 17 3.5.2. Architectural Issues . . . . . . . . . . . . . . . . . 18
3.5.3. Example . . . . . . . . . . . . . . . . . . . . . . . 17 3.5.3. Example . . . . . . . . . . . . . . . . . . . . . . . 18
3.6. Protocol Repair . . . . . . . . . . . . . . . . . . . . . 18 3.6. Protocol Repair . . . . . . . . . . . . . . . . . . . . . 19
3.6.1. General Information and Requirements . . . . . . . . . 18 3.6.1. General Information and Requirements . . . . . . . . . 19
3.6.2. Architectural Issues . . . . . . . . . . . . . . . . . 19 3.6.2. Architectural Issues . . . . . . . . . . . . . . . . . 20
3.6.3. Examples . . . . . . . . . . . . . . . . . . . . . . . 19 3.6.3. Examples . . . . . . . . . . . . . . . . . . . . . . . 20
3.7. Media Encryption . . . . . . . . . . . . . . . . . . . . . 19 3.7. Media Encryption . . . . . . . . . . . . . . . . . . . . . 20
3.7.1. General Information and Requirements . . . . . . . . . 19 3.7.1. General Information and Requirements . . . . . . . . . 20
3.7.2. Architectural Issues . . . . . . . . . . . . . . . . . 20 3.7.2. Architectural Issues . . . . . . . . . . . . . . . . . 21
3.7.3. Example . . . . . . . . . . . . . . . . . . . . . . . 20 3.7.3. Example . . . . . . . . . . . . . . . . . . . . . . . 21
4. Derived Requirements for Future SIP Standardization Work . . . 21 4. Derived Requirements for Future SIP Standardization Work . . . 22
5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.1. Normative References . . . . . . . . . . . . . . . . . . . 23 8.1. Normative References . . . . . . . . . . . . . . . . . . . 24
8.2. Informational References . . . . . . . . . . . . . . . . . 23 8.2. Informational References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . . . . 26
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 44 skipping to change at page 4, line 44
The term SBC is relatively non-specific, since it is not standardized 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 or defined anywhere. Nodes that may be referred to as SBCs but do
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 denial of
prevention and detection); b) functionality not available in the service prevention and detection); b) functionality not available in
endpoints (NAT traversal, protocol interworking or repair); and c) the endpoints (NAT traversal, protocol interworking or repair); and
network management (traffic monitoring, management, and QoS). Some c) traffic management (media monitoring and QoS). Some of these
of these functions may also get integrated into other SIP elements functions may also get integrated into other SIP elements (like pre-
(like pre-paid platforms, 3GPP P-CSCF [5], 3GPP I-CSCF, etc). 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 5, line 33 skipping to change at page 5, line 33
[media] | +-----------+ | [media] | +-----------+ |
+-----------------+ +-----------------+
Figure 1: SBC architecture Figure 1: SBC architecture
Figure 1 shows the logical architecture of an SBC, which includes a Figure 1 shows the logical architecture of an SBC, which includes a
signaling and a media component. In this document, the terms outer signaling and a media component. In this document, the terms outer
and inner network are used for describing these two networks. An SBC and inner network are used for describing these two networks. An SBC
is logically associated to the inner network, and it typically is logically associated to the inner network, and it typically
provides functions such as controlling and protecting access to the provides functions such as controlling and protecting access to the
inner network from the outer network. 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 consent and in
others they operate completely without users' consent. For example,
if an SBC is at the edge of an enterprise network performing topology
hiding (see Section 3.1), it is in the same administrative domain as
the enterprise users, and the users may choose to route through it.
If they choose to route through the SBC, then the SBC can be seen as
having an implicit consent from the users. Another example is a
scenario where a service provider has broken gateways and it deploys
an SBC in front of them for protocol repair (see Section 3.6)
reasons, then users may choose to configure the SBC as their gateway,
and so the SBC can be seen as having an implicit consent.
2.1. Peering Scenario 2.1. Peering Scenario
A typical peering scenario involves two network operators who A typical peering scenario involves two network operators who
exchange traffic with each other. For example, in a toll bypass exchange traffic with each other. An example peering scenario is
application, a gateway in operator A's network sends an INVITE that illustrated in Figure 2. An originating gateway (GW) in operator A's
is routed to the softswitch (proxy) in operator B's network. The network sends an INVITE that is routed to the SBC in operator B's
proxy responds with a redirect (3xx) message back to the originating network. Then the SBC forward it to the softswitch (SS). The
gateway that points to the appropriate terminating gateway in softswitch responds with a redirect (3xx) message back to the SBC
operator B's network. The originating gateway then sends the INVITE that points to the appropriate terminating gateway in operator B's
to the terminating gateway. network. If operator B would 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 Operator A . Operator B
. .
. 2) INVITE . 2) INVITE
+-----+ . /--------------->+-----+ +-----+ . /--------------->+-----+
| SSA | . / 3) 3xx (redir.) | SSB | |SS-A | . / 3) 3xx (redir.) |SS-B |
+-----+ . / /---------------+-----+ +-----+ . / /---------------+-----+
. / / . / /
+-----+ 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 an SBC where From SBC's perspective the Operator A is the outer network, and
Operator A is the outer network, and Operator B is the inner network. Operator B is the inner network. Operator B can use the SBC, for
Operator B can use the SBC, for example, to control access to its example, to control access to its network, protect its gateways and
network, protect its gateways and softswitches from unauthorized use softswitches from unauthorized use and Denial of Service (DoS)
and DoS attacks, and monitor the signaling and media traffic. It attacks, and monitor the signaling and media traffic. It also
also simplifies network management by minimizing the number ACL simplifies network management by minimizing the number ACL (Access
(Access Control List) entries in the gateways. The gateways do not Control List) entries in the gateways. The gateways do not need to
need to be exposed to the peer network, and they can restrict access be exposed to the peer network, and they can restrict access (both
(both media and signaling) to the SBCs. The SBC helps ensure that media and signaling) to the SBCs. The SBC helps ensure that only
only media from sessions the SBC authorizes will reach the gateway. media from sessions the SBC authorizes will reach the gateway.
2.2. Access Scenario 2.2. Access Scenario
In an access scenario, presented in Figure 3, the SBC is placed at In an access scenario, presented in Figure 3, the SBC is placed at
the border between the access network (outer network) and the the border between the access network (outer network) and the
operator's network (inner network) to control access to the operator's network (inner network) to control access to the
operator's network, protect its components (media servers, operator's network, protect its components (media servers,
application servers, gateways, etc.) from unauthorized use and DoS application servers, gateways, etc.) from unauthorized use and DoS
attacks, and monitor the signaling and media traffic. Also, since attacks, and monitor the signaling and media traffic. Also, since
the SBC is call stateful, it may provide access control functions to the SBC is call stateful, it may provide access control functions to
skipping to change at page 7, line 24 skipping to change at page 7, line 28
/ /
+-----+ +-----+ / +-----+ +-----+ /
| UA3 +---+ NAT |<---/ | UA3 +---+ NAT |<---/
+-----+ +-----+ +-----+ +-----+
Figure 3: Access scenario with SBC Figure 3: Access scenario with SBC
The SBC may be hosted in the access network (e.g,. this is common 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 when the access network is an enterprise network), or in the operator
network (e.g., this is common when the access network is a network (e.g., this is common when the access network is a
residential or small business network). 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 Some endpoints may be behind enterprise or residential NATs. In
cases where the access network is a private network, the SBC is a NAT 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 for all traffic. It is noteworthy that SIP traffic may have to
traverse more that one NAT. The proxy usually does authentication traverse more that one NAT. The proxy usually does authentication
and/or authorization for registrations and outbound calls. The SBC and/or authorization for registrations and outbound calls. The SBC
modifies the REGISTER request so that subsequent requests to the modifies the REGISTER request so that subsequent requests to the
registered address-of-record are routed to the SBC. This is done registered address-of-record are routed to the SBC. This is done
either with a Path header, or by modifying the Contact to point at either with a Path header, or by modifying the Contact to point at
the SBC. the SBC.
skipping to change at page 8, line 18 skipping to change at page 8, line 29
3.1. Topology Hiding 3.1. Topology Hiding
3.1.1. General Information and Requirements 3.1.1. General Information and Requirements
Topology hiding consists of limiting the amount of topology Topology hiding consists of limiting the amount of topology
information given to external parties. Operators have a requirement information given to external parties. Operators have a requirement
for this functionality because they do not want the IP addresses of for this functionality because they do not want the IP addresses of
their equipment (proxies, gateways, application servers, etc) to be their equipment (proxies, gateways, application servers, etc) to be
exposed to outside parties. This may be because they do not want to exposed to outside parties. This may be because they do not want to
expose their equipment to DoS (Denial of Service) attacks, they may expose their equipment to DoS attacks, they may use other carriers
use other carriers for certain traffic and do not want their for certain traffic and do not want their customers to be aware of it
customers to be aware of it or they may want to hide their internal or they may want to hide their internal network architecture from
network architecture from competitors or partners. In some competitors or partners. In some environments, the operator's
environments, the operator's customers may wish to hide the addresses customers may wish to hide the addresses of their equipment or the
of their equipment or the SIP messages may contain private, non- SIP messages may contain private, non-routable addresses.
routable addresses.
The most common form of topology hiding is the application of header The most common form of topology hiding is the application of header
privacy (see Section 5.1 of [2]), which involves stripping Via and privacy (see Section 5.1 of [2]), which involves stripping Via and
Record-Route headers, replacing the Contact header, and even changing Record-Route headers, replacing the Contact header, and even changing
Call-IDs. However, in deployments which use IP addresses instead of Call-IDs. However, in deployments which use IP addresses instead of
domain names in headers that cannot be removed (e.g. From and To 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 headers), the SBC may replace these IP addresses with its own IP
address or domain name. 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 User Agent (UA) driven
privacy mechanism [7], where the UA can facilitate the conceal of
topology information.
3.1.2. Architectural Issues 3.1.2. Architectural Issues
This functionality is based on a hop-by-hop trust model as opposed to 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 an end-to-end trust model. The messages are modified without
subscriber consent and could potentially modify or remove information subscriber consent and could potentially modify or remove information
about the user's privacy, security requirements and higher layer about the user's privacy, security requirements and higher layer
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] in scenarios where the SBC does not have any
mechanism is based on a hash value that is calculated from parts of kind of consent from the users. The Authenticated Identity
From, To, Call-Id, CSeq, Date, and Contact header fields plus from Management mechanism is based on a hash value that is calculated from
the whole message body. If the authentication service is not parts of From, To, Call-Id, CSeq, Date, and Contact header fields
provided by the SBC itself, the modification of the forementioned plus from the whole message body. If the authentication service is
not provided by the SBC itself, the modification of the forementioned
header fields and the message body is in violation of [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 Agent) and remove all traces of 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 topology information (e.g., Via and Record-Route entries) from
outgoing messages. outgoing messages.
skipping to change at page 10, line 26 skipping to change at page 10, line 44
3.2. Media Traffic Management 3.2. Media Traffic Management
3.2.1. General Information and Requirements 3.2.1. General Information and Requirements
Media traffic management is the function of controlling media Media traffic management is the function of controlling media
traffic. Network operators may require this functionality in order traffic. Network operators may require this functionality in order
to control the traffic being carried on their network on behalf of to control the traffic being carried on their network on behalf of
their subscribers. Traffic management helps the creation of their subscribers. Traffic management helps the creation of
different kinds of billing models (e.g., video telephony can be different kinds of billing models (e.g., video telephony can be
priced differently to voice-only calls) and it also makes it possible priced differently to voice-only calls) and it also makes it possible
for operators to enforce the usage of selected codecs. Additionally, for operators to enforce the usage of selected codecs.
traffic management can be used to implement intercept capabilities
where required to support audit or legal obligations. One of the use cases for media traffic management is the
implementation of intercept capabilities where 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 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
management can be done, for example, to ensure a certain QoS (Quality management can be done, for example, to ensure a certain QoS (Quality
of Service) level, or to ensure that subscribers are using only of Service) level, or to ensure that subscribers are using only
allowed codecs. 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.
Some operators do not want to manage the traffic, but only to monitor Some operators do not want to manage the traffic, but only to monitor
it for collecting statistics and making sure that they are able to it for collecting statistics and making sure that they are able to
meet any business service level agreements with their subscribers meet any business service level agreements with their subscribers
and/or partners. The protocol techniques needed for monitoring media and/or partners. The protocol techniques, from the SBC's viewpoint,
traffic are the same as for managing media traffic. 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 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 management 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 the of procedure can take place, for example, in a situation where the
skipping to change at page 11, line 20 skipping to change at page 11, line 48
Implementing traffic management 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
of Authenticated Identity Management [3], see Section 3.1.2. of Authenticated Identity Management [3], see Section 3.1.2.
The insertion of a media relay can prevent "non-media" uses of media
path, for example 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 a 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 field
are, for example, ECN and Type of Service (TOS) fields, and Don't
Fragment (DF) bit.
Media traffic management function also hinders innovations. The Media traffic management function also hinders innovations. The
reason for the hinderance is that in many cases SBCs need to be able 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 to support new ways of communicating (e.g., extensions to the SDP
protocol) before new services can be taken into use, and that slows protocol) before new services can be taken into use, and that slows
down the adoption of innovations. down the adoption of 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 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 management 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,
skipping to change at page 12, line 48 skipping to change at page 13, line 48
existing SBCs, depending on the degree of transparency the SBC existing SBCs, depending on the degree of transparency the SBC
implementation affords. In cases requiring an SBC modification to implementation affords. In cases requiring an SBC modification to
support the new protocol features, the rate of service deployment may support the new protocol features, the rate of service deployment may
be affected. 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, an
agents on networks which implement SIP differently (for example 3GPP SBC can enable a plain SIP [1] user agent to connect to a 3GPP
or SIP [1] network etc) or those that support different IP versions, network, or enable a connection between user agents that support
different codecs, or that are in different address realms. Operators different IP versions, different codecs, or that are in different
have a requirement and a strong motivation for performing capability address realms. Operators have a requirement and a strong motivation
mismatch fixing, so that they can provide transparent communication for performing capability mismatch fixing, so that they can provide
across different domains. In some cases different SIP extensions or transparent communication across different domains. In some cases
methods to implement the same SIP application (like monitoring different SIP extensions or methods to implement the same SIP
session liveness, call history/diversion etc) may also be interworked application (like monitoring session liveness, call history/diversion
through the SBC. etc) may also be interworked 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 that are fixing capability mismatches do it by insert a media
path using the procedures described in Section 3.2. Therefore, these element to the media path using the procedures described in
SBCs have the same concerns as SBCs performing traffic management: Section 3.2. Therefore, these SBCs have the same concerns as SBCs
the SBC modifies SIP messages without explicit consent from any of performing traffic management: the SBC may modify SIP messages
the user-agents. This may break end-to-end security and application without consent from any of the user-agents. This may break end-to-
extensions negotiation. end security and application 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
Consider the following example scenario where the inner network is an Consider the following example scenario where the inner network is an
skipping to change at page 15, line 26 skipping to change at page 16, line 26
3.4.2. Architectural Issues 3.4.2. Architectural Issues
This approach to NAT traversal does not work if end-to-end This approach to NAT traversal does not work if end-to-end
confidentiality or integrity-protection mechanisms are used (e.g., confidentiality or integrity-protection mechanisms are used (e.g.,
S/MIME). The SBC would be seen as a MitM modifying the messages S/MIME). The SBC would be seen as a MitM modifying the messages
between the user-agent and the registrar. between the user-agent and the 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
be as high as possible, but it still needs to be low enough to be as high as possible, but it still needs to be low enough to
maintain the NAT binding. Typically SBCs do not have any maintain the NAT binding. Some SBCs do not have any deterministic
deterministic method for choosing a suitable value. However, SBCs method for choosing a suitable value. However, SBCs can just use a
can just use a sub-optimal, relatively small value which usually sub-optimal, relatively small value which usually works. An example
works. from such value is 15 seconds (see [8]).
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 interop 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 3.4.3. Example
Consider the following example scenario: The SBC resides between the Consider the following example scenario: The SBC resides between the
UA and Registrar. Previously the UA has sent a REGISTER request to UA and Registrar. Previously the UA has sent a REGISTER request to
Registrar, and the SBC receives the registration response shown in Registrar, and the SBC receives the registration response shown in
Figure 10. Figure 10.
SIP/2.0 200 OK SIP/2.0 200 OK
From: Bob <sip:bob@biloxi.example.com>;tag=a73kszlfl From: Bob <sip:bob@biloxi.example.com>;tag=a73kszlfl
skipping to change at page 19, line 11 skipping to change at page 20, line 11
only the signaling component of an SBC, and that the protocol repair only the signaling component of an SBC, and that the protocol repair
function is not the same as protocol conversion (i.e., making function is not the same as protocol conversion (i.e., making
translation between two completely different protocols). translation between two completely different protocols).
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. However, the protocol repair might have problems with such
security mechanism that do cryptographical computations to the SIP
messages (e.g., hashing).
A similar problem related to increasing complexity, as explained in A similar problem related to increasing complexity, as explained in
Section 3.3.2, also affects protocol repair function. Section 3.3.2, also affects protocol repair function.
3.6.3. Examples 3.6.3. Examples
The SBC can, for example, receive an INVITE message from a relatively The SBC can, for example, receive an INVITE message from a relatively
new SIP UA as illustrated in Figure 13. new SIP UA as illustrated in Figure 13.
INVITE sip:callee@sbchost.example.com INVITE sip:callee@sbchost.example.com
skipping to change at page 19, line 44 skipping to change at page 20, line 46
excess white spaces to make the SIP message more human readable. excess white spaces to make the SIP message more human readable.
3.7. Media Encryption 3.7. Media Encryption
3.7.1. General Information and Requirements 3.7.1. General Information and Requirements
SBCs are used to perform media encryption / decryption at the edge of SBCs are used to perform media encryption / decryption at the edge of
the network. This is the case when media encryption (e.g., Secure the network. This is the case when media encryption (e.g., Secure
Real-time Transport Protocol (SRTP)) is used only on the access Real-time Transport Protocol (SRTP)) is used only on the access
network (outer network) side and the media is carried unencrypted in network (outer network) side and the media is carried unencrypted in
the inner network. Operators may have an obligation to provide the the inner network. Some operators may have an obligation to provide
ability to do legal interception, while they still want to give their the ability to do legal interception, while they still want to give
customers the ability to encrypt media in the access network. This their customers the ability to encrypt media in the access network.
leads to a situation where operators have a requirement to perform One possible way to do this is to perform media encryption function.
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. It 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 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 MitM attack. Due to this, the SBCs have the same architectural
issues as explained in Section 3.2. issues as explained in Section 3.2.
3.7.3. Example 3.7.3. Example
skipping to change at page 21, line 17 skipping to change at page 22, line 17
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 of requirements is derived from the functions than others. This list of requirements is derived from the functions
that break the principles of SIP in one way or another. The derived that break the principles of SIP in one way or another. 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 (see Section 3.1). SIP on behalf of some header fields (see Section 3.1). The
topology hiding is especially problematic in scenarios where
an SBC does not have users' consent.
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 by modifying
consent by modifying session descriptors, which is against session descriptors, which is against the principles of SIP
the principles of SIP (see Section 3.2, Section 3.4, (see Section 3.2, Section 3.4, Section 3.5, and Section 3.7).
Section 3.5, and Section 3.7). This is especially problematic in scenarios where an SBC does
not have users' consent.
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/SIP [1] fulfill on complex mismatch cases, like the 3GPP/SIP [1]
network mismatch. Currently this is done by modifying SIP network mismatch. Currently this is done by modifying SIP
messages, which violates end-to-end security (see Section 3.3 messages, which may violate end-to-end security (see
and Section 3.6). Section 3.3 and Section 3.6), on behalf of some header
fields. This is especially problematic in scenarios where an
SBC does not have users' consent.
Req-1 and Req-3 do not have an exiting solution today. There is Req-1 and Req-3 do not have an existing, standardized solution today.
ongoing work in the IETF for addressing Req-2, such as SIP session There is ongoing work in the IETF for addressing Req-2, such as SIP
policies, Traversal Using Relays around NAT (TURN), and Interactive session policies, Traversal Using Relays around NAT (TURN), and
Connectivity Establishment (ICE). Nonetheless, future work is needed Interactive Connectivity Establishment (ICE). Nonetheless, future
in order to develop solutions to these requirements. work is needed in order to develop solutions to these requirements.
It is noteworthy that a subset of the functions of SBCs will remain It is noteworthy that a subset of the functions of SBCs will remain
as non-standardized functions, because it is not reasonable, or as non-standardized functions, because it is not reasonable, or
feasible to develop a standardized solutions to replace them. feasible to develop a standardized solutions to replace them.
Examples from this kind of functions are the ability to enforce the Examples from this kind of functions are the ability to enforce the
usage of a specific codec and the protocol repair (see Section 3.6) usage of a specific codec and the protocol repair (see Section 3.6)
functionality. functionality.
5. Security Considerations 5. Security Considerations
skipping to change at page 22, line 22 skipping to change at page 23, line 30
on the path is performing some other function. SBCs place themselves on the path is performing some other function. SBCs place themselves
on the media path because it allows them to, for example, perform on the media path because it allows them to, for example, perform
legal interception. legal interception.
On a general level SBCs prevent the use of end-to-end authentication. 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 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 like MitM attacks, and in order for user agents to communicate, they
must allow those type of attacks. It other words, user agents can must allow those type of attacks. It other words, user agents can
not use end-to-end security. This is especially harmful because also not use end-to-end security. This is especially harmful because also
other network element, besides SBCs, are then able to do similar other network element, besides SBCs, are then able to do similar
attacks. attacks. However, on some cases, user agents can establish encrypted
media connections between each other. 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 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
skipping to change at page 23, line 29 skipping to change at page 24, line 39
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., Jacobson, V., and C. Perkins, "SDP: Session [6] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[7] Munakata, M., Schubert, S., and T. Ohba, "UA-Driven Privacy
Mechanism for SIP", draft-ietf-sip-ua-privacy-01 (work in
progress), February 2008.
[8] Eggert, L. and G. Fairhurst, "Guidelines for Application
Designers on Using Unicast UDP",
draft-ietf-tsvwg-udp-guidelines-08 (work in progress),
June 2008.
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. 32 change blocks. 
119 lines changed or deleted 207 lines changed or added

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