draft-ietf-sipping-sbc-funcs-00.txt   draft-ietf-sipping-sbc-funcs-01.txt 
SIPPING Working Group J. Hautakorpi, Ed. SIPPING Working Group J. Hautakorpi, Ed.
Internet-Draft G. Camarillo Internet-Draft G. Camarillo
Expires: May 28, 2007 Ericsson Expires: August 24, 2007 Ericsson
R. Penfield R. Penfield
Acme Packet Acme Packet
A. Hawrylyshen A. Hawrylyshen
Ditech Networks Inc. Ditech Networks Inc.
M. Bhatia M. Bhatia
NexTone Communications NexTone Communications
November 24, 2006 February 20, 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-00.txt draft-ietf-sipping-sbc-funcs-01.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 May 28, 2007. This Internet-Draft will expire on August 24, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This documents describes functions implemented in Session Initiation This documents describes functions implemented in Session Initiation
Protocol (SIP) intermediaries known as Session Border Controllers Protocol (SIP) intermediaries known as Session Border Controllers
(SBCs). Although the goal of this document is to describe all the (SBCs). The goal of this document is to describe the commonly
functions of SBCs, a special focus is given to those practices that provided functions of SBCs. A special focus is given to those
are viewed to be in conflict with SIP architectural principles. It practices that are viewed to be in conflict with SIP architectural
also explores the underlying requirements of network operators that principles. This document also explores the underlying requirements
have led to the use of these functions and practices in order to of network operators that have led to the use of these functions and
identify protocol requirements and determine whether those practices in order to identify protocol requirements and determine
requirements are satisfied by existing specifications or additional whether those requirements are satisfied by existing specifications
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 . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Topology Hiding . . . . . . . . . . . . . . . . . . . . . 7 3.1. Topology Hiding . . . . . . . . . . . . . . . . . . . . . 8
3.1.1. General Information and Requirements . . . . . . . . . 7 3.1.1. General Information and Requirements . . . . . . . . . 8
3.1.2. Architectural Issues . . . . . . . . . . . . . . . . . 8 3.1.2. Architectural Issues . . . . . . . . . . . . . . . . . 8
3.1.3. Example . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.3. Example . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Media Traffic Shaping . . . . . . . . . . . . . . . . . . 9 3.2. Media Traffic Shaping . . . . . . . . . . . . . . . . . . 10
3.2.1. General Information and Requirements . . . . . . . . . 9 3.2.1. General Information and Requirements . . . . . . . . . 10
3.2.2. Architectural Issues . . . . . . . . . . . . . . . . . 10 3.2.2. Architectural Issues . . . . . . . . . . . . . . . . . 10
3.2.3. Example . . . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . 12
3.3.3. Example . . . . . . . . . . . . . . . . . . . . . . . 12 3.3.3. Example . . . . . . . . . . . . . . . . . . . . . . . 13
3.4. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 13 3.4. Maintaining SIP-related NAT Bindings . . . . . . . . . . . 13
3.4.1. General Information and Requirements . . . . . . . . . 13 3.4.1. General Information and Requirements . . . . . . . . . 14
3.4.2. Architectural Issues . . . . . . . . . . . . . . . . . 14 3.4.2. Architectural Issues . . . . . . . . . . . . . . . . . 14
3.4.3. Example . . . . . . . . . . . . . . . . . . . . . . . 14 3.4.3. Example . . . . . . . . . . . . . . . . . . . . . . . 15
3.5. Access Control . . . . . . . . . . . . . . . . . . . . . . 15 3.5. Access Control . . . . . . . . . . . . . . . . . . . . . . 15
3.5.1. General Information and Requirements . . . . . . . . . 15 3.5.1. General Information and Requirements . . . . . . . . . 15
3.5.2. Architectural Issues . . . . . . . . . . . . . . . . . 16 3.5.2. Architectural Issues . . . . . . . . . . . . . . . . . 16
3.5.3. Example . . . . . . . . . . . . . . . . . . . . . . . 16 3.5.3. Example . . . . . . . . . . . . . . . . . . . . . . . 16
3.6. Protocol Repair . . . . . . . . . . . . . . . . . . . . . 17 3.6. Protocol Repair . . . . . . . . . . . . . . . . . . . . . 17
3.6.1. General Information and Requirements . . . . . . . . . 17 3.6.1. General Information and Requirements . . . . . . . . . 17
3.6.2. Architectural Issues . . . . . . . . . . . . . . . . . 17 3.6.2. Architectural Issues . . . . . . . . . . . . . . . . . 18
3.6.3. Examples . . . . . . . . . . . . . . . . . . . . . . . 18 3.6.3. Examples . . . . . . . . . . . . . . . . . . . . . . . 18
3.7. Media Encryption . . . . . . . . . . . . . . . . . . . . . 19 3.7. Media Encryption . . . . . . . . . . . . . . . . . . . . . 18
3.7.1. General Information and Requirements . . . . . . . . . 19 3.7.1. General Information and Requirements . . . . . . . . . 18
3.7.2. Architectural Issues . . . . . . . . . . . . . . . . . 19 3.7.2. Architectural Issues . . . . . . . . . . . . . . . . . 18
3.7.3. Example . . . . . . . . . . . . . . . . . . . . . . . 19 3.7.3. Example . . . . . . . . . . . . . . . . . . . . . . . 19
4. Derived Requirements . . . . . . . . . . . . . . . . . . . . . 20 4. Derived Requirements . . . . . . . . . . . . . . . . . . . . . 20
5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . . 22 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21
8.2. Informational References . . . . . . . . . . . . . . . . . 22 8.2. Informational References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 24 Intellectual Property and Copyright Statements . . . . . . . . . . 23
1. Introduction 1. Introduction
In the past few years there has been a rapid adoption of 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 out-paced the development communications networks. This has often outpaced the development and
and implementation of protocol specifications to meet network implementation of protocol specifications to meet network operator
operator requirements. This has led to the development of requirements. This has led to the development of proprietary
proprietary solutions. Often these proprietary solutions are solutions. Often, these proprietary solutions are implemented in
implemented in network intermediaries known in the marketplace as network intermediaries known in the marketplace as Session Border
Session Border Controllers (SBCs) because they typically are deployed Controllers (SBCs) because they typically are deployed at the border
at the border between two networks. The reason for this is that between two networks. The reason for this is that network policies
network policies are typically enforced at the edge of the network. are typically enforced at the edge of the network.
Even though many SBCs currently break things like end-to-end security Even though many SBCs currently behave badly in a sense that they
and can impact feature negotiations, there is clearly a market for break end-to-end security and impact on feature negotiations, there
them. Network operators need many of the features current SBCs is clearly a market for them. Network operators need many of the
provide and many times there are no standard mechanisms available to features current SBCs provide and many times there are no standard
provide them in a better way. This document describes the most mechanisms available to provide them in a better way.
common functions of current SBCs and the reasons that network
operators require them. It also describes the architectural issues The purpose of this document is to describe functions implemented in
with these functions. Although this document focuses on functions SBCs. A special focus is given to those practices that are
common to SBCs, many of the issues raised apply to other types of conflicting with SIP architectural principles in some way. The
Back-to-Back User Agents (B2BUAs.) document also explores the underlying requirements of network
operators that have led to the use of these functions and practices
in order to identify protocol requirements and determine whether
those requirements are satisfied by existing specifications or
additional standards work is required.
2. Background on SBCs 2. Background on SBCs
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, 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, shaping, and QoS). Some of
these functions may also get integrated into other SIP elements (like these functions may also get integrated into other SIP elements (like
pre-paid platforms, 3GPP P-CSCF, 3GPP I-CSCF etc). pre-paid platforms, 3GPP P-CSCF [4], 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
header field with the SBCs address, and generate a new Call-ID and header field with the SBCs address, and generate a new Call-ID and
new To and From tags. new To and From tags.
+-----------------+ +-----------------+
skipping to change at page 6, line 24 skipping to change at page 6, line 24
+-----+ +-----+---------------------->+-----+ +-----+ +-----+---------------------->+-----+
. .
+-----+ . +-----+ +-----+ . +-----+
|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 a 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 uses the SBC to control access to its network, protect its Operator B can use the SBC, for example, to control access to its
gateways and softswitches from unauthorized use and DoS attacks, and network, protect its gateways and softswitches from unauthorized use
monitor the signaling and media traffic. It also simplifies network and DoS attacks, and monitor the signaling and media traffic. It
management by minimizing the number ACL (Access Control List) entries also simplifies network management by minimizing the number ACL
in the gateways. The gateways do not need to be exposed to the peer (Access Control List) entries in the gateways. The gateways do not
network, and they can restrict access (both media and signaling) to need to be exposed to the peer network, and they can restrict access
the SBCs. The SBC helps ensure that only media from sessions the SBC (both media and signaling) to the SBCs. The SBC helps ensure that
authorizes will reach the gateway. only 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 operator's network (inner network) to control access to the
network, protect its components (media servers, application servers, operator's network, protect its components (media servers,
gateways, etc.) from unauthorized use and DoS attacks, and monitor application servers, gateways, etc.) from unauthorized use and DoS
the signaling and media traffic. Also, as a part of access control, attacks, and monitor the signaling and media traffic. Also, as a
since the SBC is call stateful, it can prevent over subscription of part of access control, since the SBC is call stateful, it can
the access links. Endpoints are configured with the SBC as their prevent over subscription of the access links. Endpoints are
outbound proxy address. The SBC routes requests to one or more configured with the SBC as their outbound proxy address. The SBC
proxies in the operator network. routes requests to one or more proxies in the operator network.
Access Network . Operator Network Access Network . Operator Network
. .
+-----+ . +-----+ .
| UA1 |<---------\ . | UA1 |<---------\ .
+-----+ \ . +-----+ \ .
\ . \ .
+-----+ \------->+-----+ +-------+ +-----+ \------->+-----+ +-------+
| UA2 |<-------------------->| SBC |<----->| proxy |<-- - | UA2 |<-------------------->| SBC |<----->| proxy |<-- -
+-----+ /--->+-----+ +-------+ +-----+ /--->+-----+ +-------+
skipping to change at page 7, line 29 skipping to change at page 7, line 29
Figure 3: Access scenario with SBC Figure 3: Access scenario with SBC
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 the cases where the access network is a private network, the SBC is the
NAT for all traffic. The proxy usually does authentication and/or NAT for all traffic. The proxy usually does authentication and/or
authorization for registrations and outbound calls. The SBC modifies authorization for registrations and outbound calls. The SBC modifies
the REGISTER request so that subsequent requests to the registered the REGISTER request so that subsequent requests to the registered
address-of-record are routed to the SBC. This is done either with a address-of-record are routed to the SBC. This is done either with a
Path header, or by modifying the Contact to point at the SBC. Path header, or by modifying the Contact to point at the SBC.
The scenario presented in this section is a general one, and it
applies also to other similar settings. One example from a similar
setting is the one where an access network is the open internet, and
the operator network is the network of a SIP service provider.
3. Functions of SBCs 3. Functions of SBCs
This section lists those functions that are used in SBC deployments This section lists those functions that are used in SBC deployments
in current communication networks. Each subsection describes a in current communication networks. Each subsection describes a
particular function or feature, the operators' requirements for particular function or feature, the operators' requirements for
having it, explanation on any impact to the end-to-end SIP having it, explanation of any impact to the end-to-end SIP
architecture, and a concrete implementation example. Each section architecture, and a concrete implementation example. Each section
also discusses potential concerns specific to that particular also discusses potential concerns specific to that particular
implementation technique. Suggestions for alternative implementation implementation technique. Suggestions for alternative implementation
techniques that may be more architecturally compatible with SIP are techniques that may be more architecturally compatible with SIP are
outside the scope of this document. outside the scope of this document.
All the examples given in this section are simplified; only the All the examples given in this section are simplified; only the
relevant header lines from SIP and SDP [4] messages are displayed. relevant header lines from SIP and SDP [5] messages are displayed.
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
skipping to change at page 8, line 27 skipping to change at page 8, line 35
deployments which use IP addresses instead of domain names in headers deployments which use IP addresses instead of domain names in headers
that cannot be removed (e.g. From and To headers), the SBC may that cannot be removed (e.g. From and To headers), the SBC may
replace these IP addresses with its own IP address or domain name. replace these IP addresses with its own IP address or domain name.
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. Either applications which are communicating end-to-end using SIP. Neither
user in an end-to-end call may perceive this as a Man In The Middle user agent in an end-to-end call does not have any way to distinguish
(MitM) attack. the SBC actions from a Man-In-The-Middle (MitM) attack.
Modification of IP addresses in Unifor Resource Indetifiers (URIs) Modification of IP addresses in Uniform Resource Identifiers (URIs)
within SIP headers can lead to application failures if these URIs are within SIP headers can lead to application failures if these URIs are
communicated to other SIP servers outside the current dialog. These communicated to other SIP servers outside the current dialog. These
URIs could appear in a REFER request or in the body of NOTIFY request URIs could appear in a REFER request or in the body of NOTIFY request
as part of an event package. If these messages traverse the same as part of an event package. If these messages traverse the same
SBC, it has the opportunity to restore the original IP address. On SBC, it has the opportunity to restore the original IP address. On
the other hand, if the REFER or NOTIFY message returns to the the other hand, if the REFER or NOTIFY message returns to the
original network through a different SBC that does not have access to original network through a different SBC that does not have access to
the address mapping, the recipient of the message will not see the the address mapping, the recipient of the message will not see the
original address. This may cause the application function to original address. This may cause the application function to fail.
fail.[[Comment.1: Do we have a sane example of where this is a real
problem? It sounds somewhat contrived to me, but I agree it is a
theoretical concern - Alan.]][[Comment.2: I personally would like to
include this text, although it might be more of a theoretical
concern. - Jani]]
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., Record-Route and Via entries) from of topology information (e.g., Record-Route and Via entries) from
outgoing messages. outgoing messages.
Imagine the following example scenario: The SBC Imagine the following example scenario: The SBC
(p4.domain.example.com) is receiving an INVITE request from the inner (p4.domain.example.com) receives an INVITE request from the inner
network, which in this case is an operator network. The received SIP network, which in this case is an operator network. The received SIP
message is shown in Figure 4. message is shown in Figure 4.
INVITE sip:callee@u2.domain.example.com SIP/2.0 INVITE sip:callee@u2.domain.example.com SIP/2.0
Contact: sip:caller@u1.example.com Contact: sip:caller@u1.example.com
Record-Route: <sip:p3.middle.example.com> Record-Route: <sip:p3.middle.example.com>
Record-Route: <sip:p2.example.com;lr> Record-Route: <sip:p2.example.com;lr>
Record-Route: <sip:p1.example.com;lr> Record-Route: <sip:p1.example.com;lr>
Figure 4: INVITE Request Prior to Topology Hiding Figure 4: INVITE Request Prior to Topology Hiding
skipping to change at page 9, line 35 skipping to change at page 9, line 41
INVITE sip:callee@u2.domain.example.com SIP/2.0 INVITE sip:callee@u2.domain.example.com SIP/2.0
Contact: sip:caller@u1.example.com Contact: sip:caller@u1.example.com
Record-Route: <sip:p4.domain.example.com;lr> Record-Route: <sip:p4.domain.example.com;lr>
Figure 5: INVITE Request After Topology Hiding Figure 5: INVITE Request After Topology Hiding
Like a regular proxy server that inserts a Record-Route entry, the Like a regular proxy server that inserts a Record-Route entry, the
SBC handles every single message of a given SIP dialog. If the SBC 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 losing state, the SBC "Via" entries from a request and then restarts, thus losing state,
may not be able to route responses to that request; depending on the the SBC may not be able to route responses to that request; depending
information that was lost when the SBC restarted. [[Comment.3: There on the information that was lost when the SBC restarted.
are techniques to mitigate this problem, not all SBCs suffer from
this. Is this worth capturing in the text? [Alan]]][[Comment.4: No,
not all suffer from this, but some do, so I believe we shouldn't
remove this text. - Jani]]
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. modify other headers, including the Contact header field values. The
header fields containing identity information is listed in Section
4.1 of [2].
3.2. Media Traffic Shaping 3.2. Media Traffic Shaping
3.2.1. General Information and Requirements 3.2.1. General Information and Requirements
Media traffic shaping is the act of controlling media traffic. Media traffic shaping is the act of controlling media traffic.
Network operators may require this functionality in order to control Network operators may require this functionality in order to control
the traffic being carried on their network on behalf of their the traffic being carried on their network on behalf of their
subscibers. Traffic shaping helps create different kinds of billing subscribers. Traffic shaping helps the creation of different kinds
models (e.g., video telephony can be priced differently than voice- of billing models (e.g., video telephony can be priced differently to
only calls). Additionally, traffic shaping can be used to implement voice-only calls) and it also makes it possible for operators to
intercept capabilities where required to support audit or legal enforce the usage of selected codecs. Additionally, traffic shaping
obligations. can be used to implement intercept capabilities where required to
support audit or legal obligations.
Since the media path is independent of the signaling path, the media 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. relay which may be co-located with the SBC. This kind of traffic
shaping can be done, for example, to ensure a certain QoS (Quality of
Service) level.
Some operators do not want to reshape the traffic, but only to Some operators do not want to reshape the traffic (e.g., change a
monitor it for collecting statistics and making sure that they are codec), but only to monitor it for collecting statistics and making
able to meet any business service level agreements with their sure that they are able to meet any business service level agreements
subscribers and/or partners. The protocol techniques needed for with their subscribers and/or partners. The protocol techniques
monitoring media traffic are the same as for reshaping media traffic. needed for monitoring media traffic are the same as for reshaping
media traffic.
SBCs on the media path are also capable of dealing with the "lost 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
the both sides to cleanup any state in other intermediate elements both sides to cleanup any state in other intermediate elements and
and the endpoints. the endpoints.
One possible form of media traffic shaping is that SBCs terminate One possible form of media traffic shaping 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 e.g., in a situation where subscriber of procedure can take place, for example, in a situation where
runs out of credits. subscriber runs out of credits.
3.2.2. Architectural Issues 3.2.2. Architectural Issues
Implementing traffic shaping in this manner requires the SBC to Implementing traffic shaping 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 (Man-in-the-Middle). actions from an attack by a MitM.
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 shaping 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.
CODEC restriction is an example application of traffic shaping. The As mentioned in Section 3.2.1, codec restriction is a form of traffic
SBC restricts the codec set negotiated in the offer/answer exchange shaping. The SBC restricts the codec set negotiated in the offer/
[3] between the user agents. After modifying the session answer exchange [3] between the user-agents. After modifying the
descriptions, the SBC can check whether or not the media stream session descriptions, the SBC can check whether or not the media
corresponds to what was negotiated in the offer/answer exchange. If stream corresponds to what was negotiated in the offer/answer
it differs, the SBC has the ability to terminate the media stream or exchange. If it differs, the SBC has the ability to terminate the
take other appropriate (configured) actions (e.g. alarming or media stream or take other appropriate (configured) actions (e.g.
reporting). 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 one 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 10.16.64.4 o=mhandley 2890844526 2890842807 IN IP4 192.0.2.4
c=IN IP4 10.16.64.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 Shaping
In this example, the SBC performs the media traffic shaping function In this example, the SBC performs the media traffic shaping function
by rewritting the 'm' line, and removing one 'a' line according to by rewritting the 'm' line, and removing one 'a' line according to
some (external) policy. Figure 7 shows the session description after some (external) policy. Figure 7 shows the session description after
the traffic shaping function. the traffic shaping function.
v=0 v=0
o=mhandley 2890844526 2890842807 IN IP4 10.16.64.4 o=mhandley 2890844526 2890842807 IN IP4 192.0.2.4
c=IN IP4 10.16.64.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 Shaping
One problem with media traffic shaping is that the SBC needs to Media traffic shaping has a problem where the SBC needs to understand
understand the session description protocol and all extensions used the session description protocol and all extensions used by the user-
by the user agents. This means that in order to use a new extension agents. This means that in order to use a new extension (e.g., an
(e.g., an extension to implement a new service) or a new session extension to implement a new service) or a new session description
description protocol, SBCs in the network may need to be upgraded in protocol, SBCs in the network may need to be upgraded in conjunction
conjunction with the endpoints. Certain extensions that do not with the endpoints. It is noteworthy than similar problem, but with
require active manipulation of the session descriptors to facilitate header fields, applies to, for example, topology hiding function, see
traffic shaping will be able to be deployed without upgrading Section 3.1. Certain extensions that do not require active
existing SBCs, depending on the degree of transparency the SBC manipulation of the session descriptors to facilitate traffic shaping
implementation affords. In cases requiring an SBC modification to will be able to be deployed without upgrading existing SBCs,
support the new protocol features, the rate of service deployment may depending on the degree of transparency the SBC implementation
be affected. [[Comment.5: I do not think this will slow down affords. In cases requiring an SBC modification to support the new
innovation; innovation is a distinct phase of development and protocol features, the rate of service deployment may be affected.
separable from operational network deployment. -Alan]][[Comment.6: I
don't quite get what you are suggesting. If you want to change the
text, go ahead. - Jani]]
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, SIP profiles or extensions. For agents with different capabilities or extensions. For example, user-
example, user agents on networks which implement different SIP agents on networks which implement SIP differently (for example 3GPP
Profiles (for example 3GPP or Packet Cable etc) or those that support or Packet Cable etc) or those that support different IP versions,
different IP versions, different codecs, or that are in different different codecs, or that are in different address realms. Operators
address realms. Operators have a requirement and a strong motivation have a requirement and a strong motivation for performing capability
for performing capability mismatch fixing, so that they can provide mismatch fixing, so that they can provide transparent communication
transparent communication across different domains. In some cases across different domains. In some cases different SIP extensions or
different SIP extensions or methods to implement the same SIP methods to implement the same SIP application (like monitoring
application (like monitoring session liveness, call history/diversion session liveness, call history/diversion etc) may also be interworked
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 shaping: the
SBC modifies SIP messages without explicit consent from any of the SBC modifies SIP messages without explicit consent from any of the
user agents. This may break end-to-end security and application user-agents. This may break end-to-end security and application
extensions negotiation. extensions negotiation.
[[Comment.7: I have removed the network engineering concern; this is There is also a problem related to increasing complexity. If the
an unrealistic anti-Apple-Pie problem that could only arise through a number of incompatibilites increase, which is probable, then SBCs
fundamental bug in either configuration or SBC implementation. need to be able to handle a large number of capability mismatches in
-Alan]][[Comment.8: Ok. - Jani]] 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
access network using IPv4 and the outer network is using IPv6. The access network using IPv4 and the outer network is using IPv6. The
SBC receives an INVITE request with a session description from the SBC receives an INVITE request with a session description from the
access network: access network:
INVITE sip:callee@ipv6.domain.example.com SIP/2.0 INVITE sip:callee@ipv6.domain.example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4 Via: SIP/2.0/UDP 192.0.2.4
skipping to change at page 13, line 23 skipping to change at page 13, line 33
a=rtpmap:96 L8/8000 a=rtpmap:96 L8/8000
Figure 8: Request Prior to Capabilities Match Figure 8: Request Prior to Capabilities Match
Then the SBC performs a capability mismatch fixing function. In this Then the SBC performs a capability mismatch fixing function. In this
imagined situation the SBC inserts Record-Route and Via headers, and imagined situation the SBC inserts Record-Route and Via headers, and
rewrites the 'c' line from the sessions descriptor. Figure 9 shows rewrites the 'c' line from the sessions descriptor. Figure 9 shows
the request after the capability mismatch adjusment. the request after the capability mismatch adjusment.
INVITE sip:callee@ipv6.domain.com SIP/2.0 INVITE sip:callee@ipv6.domain.com SIP/2.0
Record-Route: <sip:[2001:620:8:801:201:2ff:fe94:8e10];lr> Record-Route: <sip:[2001:DB8::801:201:2ff:fe94:8e10];lr>
Via: SIP/2.0/UDP sip:[2001:620:8:801:201:2ff:fe94:8e10] Via: SIP/2.0/UDP sip:[2001:DB8::801:201:2ff:fe94:8e10]
Via: SIP/2.0/UDP 192.0.2.4 Via: SIP/2.0/UDP 192.0.2.4
Contact: sip:caller@u1.example.com Contact: sip:caller@u1.example.com
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 IP6 2001:620:8:801:201:2ff:fe94:8e10 c=IN IP6 2001:DB8::801:201:2ff:fe94:8e10
m=audio 49230 RTP/AVP 96 m=audio 49230 RTP/AVP 96
a=rtpmap:96 L8/8000 a=rtpmap:96 L8/8000
Figure 9: Request After Capability Match Figure 9: Request After Capability Match
This message is then sent by the SBC to the onward IPv6 network. This message is then sent by the SBC to the onward IPv6 network.
3.4. NAT Traversal 3.4. Maintaining SIP-related NAT Bindings
3.4.1. General Information and Requirements 3.4.1. General Information and Requirements
NAT traversal in this instance refers to the specific message NAT traversal in this instance refers to the specific message
modifications required to assist a user-agent in maintaining SIP and modifications required to assist a user-agent in maintaining SIP and
media connectivity when there is a NAT device located between the media connectivity when there is a NAT device located between a user-
user-agent and the proxy/registrar and, most likely, any other user- agent and a proxy/registrar and, possibly, any other user-agent.
agent.
An SBC performing a NAT (Network Address Translator) traversal An SBC performing a NAT (Network Address Translator) traversal
function for a user agent behind a NAT sits between the user agent function for a user agent behind a NAT sits between the user-agent
and the registrar of the domain. NATs are widely deployed in various and the registrar of the domain. NATs are widely deployed in various
access networks today, so operators have a requirement to support it. access networks today, so operators have a requirement to support it.
When the registrar receives a REGISTER request from the user agent When the registrar receives a REGISTER request from the user-agent
and responds with a 200 (OK) response, the SBC modifies such a and responds with a 200 (OK) response, the SBC modifies such a
response decreasing the validity of the registration (i.e., the response decreasing the validity of the registration (i.e., the
registration expires sooner). This forces the user agent to send a registration expires sooner). This forces the user-agent to send a
new REGISTER to refresh the registration sooner that it would have new REGISTER to refresh the registration sooner that it would have
done on receiving the original response from the registrar. The done on receiving the original response from the registrar. The
REGISTER requests sent by the user agent refresh the binding of the REGISTER requests sent by the user-agent refresh the binding of the
NAT before the binding expires. NAT before the binding expires.
Note that the SBC does not need to relay all the REGISTER requests Note that the SBC does not need to relay all the REGISTER requests
received from the user agent to the registrar. The SBC can generate received from the user-agent to the registrar. The SBC can generate
responses to REGISTER requests received before the registration is responses to REGISTER requests received before the registration is
about to expire at the registrar. Moreover, the SBC needs to about to expire at the registrar. Moreover, the SBC needs to
deregister the user agent if this fails to refresh its registration deregister the user-agent if this fails to refresh its registration
in time, even if the registration at the registrar would still be in time, even if the registration at the registrar would still be
valid. valid.
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.
Also other measures, such as acting as a media relay by modifying SDP SBCs can also force traffic to go through a media relay for NAT
session descriptors (see Section 3.2), may be taken by SBC to ensure traversal purposes (more about media traffic shaping in Section 3.2).
media connectivity. A typical call has media streams to two directions. Even though SBCs
can force media streams from both directions to go through a media
relay, it is usually enough to relay only the media from one
direction.
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.
[[Comment.9: Is there something more specific to this function we can There is also a problem related to the method how SBCs choose the
put here? This is very generic and a general limitation of SBC value for the validity of a registration period. This value should
architectures.]][[Comment.10: If you want to add something, please be as high as possible, but it still needs to be low enough to
do. - Jani]] maintain the NAT bindind. Typically SBCs do not have any
deterministic method for choosing a suitable value.
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 15, line 37 skipping to change at page 15, line 51
NAT traversal, but this example illustrates only one mechanism for NAT traversal, but this example illustrates only one mechanism for
preserving the SIP related NAT bindings. preserving the SIP related NAT bindings.
3.5. Access Control 3.5. Access Control
3.5.1. General Information and Requirements 3.5.1. General Information and Requirements
Network operators may wish to control what kind of signaling and Network operators may wish to control what kind of signaling and
media traffic their network carries. There is strong motivation and media traffic their network carries. There is strong motivation and
a requirement to do access control on the edge of an operator's a requirement to do access control on the edge of an operator's
network. Access control can be based on, for example, IP addresses network. Access control can be based on, for example, link-layer
or SIP identities. identifiers, IP addresses or SIP identities.
This function can be implemented by protecting the inner network with This function can be implemented by protecting the inner network with
firewalls and configuring them so that they only accept SIP traffic firewalls and configuring them so that they only accept SIP traffic
from the SBC. This way, all the SIP traffic entering the inner from the SBC. This way, all the SIP traffic entering the inner
network needs to be routed though the SBC, which only routes messages network needs to be routed though the SBC, which only routes messages
from authorized parties or traffic that meets a specific policy that from authorized parties or traffic that meets a specific policy that
is expressed in the SBC administratively. is expressed in the SBC administratively.
Access control can be applied either only to the signaling, or to Access control can be applied either only to the signaling, or to
both the signaling and media. If it is applied only to the both the signaling and media. If it is applied only to the
skipping to change at page 16, line 26 skipping to change at page 16, line 41
3.5.2. Architectural Issues 3.5.2. Architectural Issues
Since the SBC needs to handle all SIP messages, this function has Since the SBC needs to handle all SIP messages, this function has
scalability implications. In addition, the SBC is a single point of scalability implications. In addition, the SBC is a single point of
failure from an architectural point of view. Although, in practice, failure from an architectural point of view. Although, in practice,
many current SBCs have the capability to support redundant many current SBCs have the capability to support redundant
configuration, which prevents the loss of calls and/or sessions in configuration, which prevents the loss of calls and/or sessions in
the event of a failure on a single node. the event of a failure on a single node.
[[Comment.11: I am tempted to remove this paragraph; this is a
general architectural problem that is not truly specific to SBCs. A
proxy configured into a SIP architecture that Record-Route'd requests
would ALSO be a single point of failure. Provisioning a network to
deal with the outage of a single element is just good design.
-Alan]][[Comment.12: I agree that this is not specific only to SBCs,
but is specific also to SBCs. I wouldn't like to remove this
paragraph. - Jani]]
If access control is performed only on behalf of signaling, then the If access control is performed only on behalf of signaling, then the
SBC is compatible with general SIP architectural principles, but if SBC is compatible with general SIP architectural principles, but if
it is performed for signaling and for media, then there are similar it is performed for signaling and for media, then there are similar
problems as described in Section 3.2.2. problems as described in Section 3.2.2.
3.5.3. Example 3.5.3. Example
Figure 12 shows a callflow where the SBC is providing both signaling Figure 12 shows a callflow where the SBC is providing both signaling
and media access control. and media access control.
skipping to change at page 17, line 31 skipping to change at page 17, line 31
|<-----------------------| | |<-----------------------| |
| | | | | |
| Media [Media inspection] Media | | Media [Media inspection] Media |
|<======================>|<======================>| |<======================>|<======================>|
| | | | | |
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.
Some SBCs may rely on the proxy to authenticate the user-agent The identification can be done, for example, already in the
placing the call. After authentication, the SBC modifies the session registration phase. Some SBCs may rely on the proxy to authenticate
descriptors in INVITE and 200 OK messages in a way that the media is the user-agent placing the call. After identification, the SBC
going to flow through SBC itself. When the media starts flowing, the modifies the session descriptors in INVITE and 200 OK messages in a
SBC can inspect whether the callee and caller use the codec(s) that way that the media is going to flow through SBC itself. When the
they had previously agreed on. media starts flowing, the SBC can inspect whether 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- SBC are also used to repair protocol messages generated by not-fully-
standard clients. Operators may wish to support protocol repair, if standard clients. Operators may wish to support protocol repair, if
they want to support as many client as possible. It is noteworthy, they want to support as many clients as possible. It is noteworthy,
that this function affects only the signaling component of SBC, and that this function affects only the signaling component of SBC, and
that protocol repair function is not the same as protocol conversion. 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
Section 3.3.2, also affects protocol repair function.
3.6.3. Examples 3.6.3. Examples
The SBC can, for example, receive the an INVITE message from a not- The SBC can, for example, receive an INVITE message from a relatively
fully-standard client 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
Via: SIP/2.0/UDP u1.example.com:5060;lr=1 Via: SIP/2.0/UDP u1.example.com:5060;lr
From: Caller <sip:caller@one.example.com> From: Caller <sip:caller@one.example.com>
To: Callee <sip:callee@two.example.com> To: Callee <sip:callee@two.example.com>
Call-ID: 18293281@u1.example.com Call-ID: 18293281@u1.example.com
CSeq: 1 INVITE CSeq: 1 INVITE
Contact: sip:caller@u1.example.com Contact: sip:caller@u1.example.com
Figure 13: Request from non-standard client Figure 13: Request from a relatively new client
If the SBC does protocol repair, it can re-write the request line (in If the SBC does protocol repair, it can re-write the 'lr' parameter
this case the UAC did not put the target in the URI and instead put on the Via header field into the form 'lr=true', in order to support
the SBC hostname as the host portion). It could also remove excess some older, non-standard SIP stacks. It could also remove excess
white spaces to make the SIP message more human readable. white spaces to make the SIP message more human readable.
Some other examples of "protocol repair" that have been implemented
in commercially available SBCs include:
o Changing Content-Disposition from "signal" to "session". This was
required for a user agent which sent an incorrect Content-
Disposition header.
o Addition of userinfo to a Contact URI when none was present. This
was required for a softswitch/proxy that would reject requests if
the Contact URI had no user part.
o Addition of a to-tag to provisional or error responses.
o Re-ordering of Contact header values in a REGISTER response. This
was required for a user agent that would take the expires value
from the first Contact header value without matching it against
its Contact value.
o Correction of SDP syntax where the user agent used "annexb=" in
the fmtp attribute instead of the proper "annexb:".
o Correction of signaling errors (convert BYE to CANCEL) for
termination of early sessions.
o Repair of header parameters in 'archaic' or incorrect formats.
Some older stacks assume that parameters are always of the form
NAME=VALUE. For those elements, it is necessary to convert
'lr=true' or 'lr=1' to 'lr' in order to interoperate with several
commercially available stacks and proxies.
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 is used only on the network. This is the case when media encryption is used only on
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
skipping to change at page 20, line 47 skipping to change at page 20, line 9
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 4. Derived Requirements
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 requirements that are derived from the
functions that break the principles of SIP in one way or the other. functions that break the principles of SIP in one way or another.
The derived requirements are: The derived 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 e.g., 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 e.g., by through intermediaries. Currently this is done by modifying
modifying session descriptors, which is against the principles session descriptors, which is against the principles of SIP.
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. Currently this is done by mismatches in SIP messages. This requirement is harder to
modifying SIP messages, which violates e.g., end-to-end fulfill on complex mismatch cases, like the 3GPP/Packet Cable
security. mismatch. Currently this is done by modifying SIP messages,
which violates end-to-end security.
All the above-mentioned requirements are such that they do not have All the above-mentioned requirements are such that they do not have
an existing solution today. Thus, future work is needed in order to an existing solution today. Thus, future work is needed in order to
develop solutions to these requirements. 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. If the IETF decides to develop standard and privacy implications. One major security problem is that many
mechanisms to address those functions, security and privacy-related functions implemented by SBCs (e.g., topology hiding and media
aspects will need to be taken into consideration. traffic shaping) modify SIP messages and their bodies without the
user agents' consent. The result is that the user agents may
interpreted the actions taken by SBC as a MitM attack.
[[Comment.13: I wonder if it is worth classifying the specific type SBCs that place themselves (or another entity) on the media path can
of security problems and assembling them here. The remainder of this be used to eavesdrop conversations. Since, often, user agents cannot
document can then refer to the specific problem a given operational distinguish between the actions of an attacker and those of a SBC,
activity has given today's typically implementation mechanisms. users cannot know whether they are being eavesdropped or a SBC on the
[Alan]]][[Comment.14: My gut feeling is that it would require a lot path is performing some other function.
of work. If you want to do it, go ahead, but at least I don't have
the time to do it. - Jani]] A SBC is a single point of failure form the architectural point of
view. This makes it an attractive target for DoS attacks. The fact
that some functions of SBCs require those SBCs to maintain session
specific information makes the situation even worse. If the SBC
crashes (or is brought down by an attacker), ongoing sessions
experience undetermined behavior.
If the IETF decides to develop standard mechanisms to address the
requirements presented in Section 4, the security and privacy-related
aspects of those mechanisms will, of course, need to be taken into
consideration.
6. IANA Considerations 6. IANA Considerations
This document has no IANA considerations. This document has no IANA considerations.
7. Acknowledgements 7. Acknowledgements
The ad-hoc meeting about SBCs, held on Nov 9th 2004 at Washington DC The ad-hoc meeting about SBCs, held on Nov 9th 2004 at Washington DC
during the 61st IETF meeting, provided valuable input to this during the 61st IETF meeting, provided valuable input to this
document. Special thanks goes also to Sridhar Ramachandran, Gaurav document. Special thanks goes also to Sridhar Ramachandran, Gaurav
skipping to change at page 22, line 19 skipping to change at page 21, line 35
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[2] Peterson, J., "A Privacy Mechanism for the Session Initiation [2] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323, November 2002. Protocol (SIP)", RFC 3323, November 2002.
[3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [3] 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
[4] Handley, M. and V. Jacobson, "SDP: Session Description [4] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP TS 23.228
5.15.0, June 2006.
[5] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998. Protocol", RFC 2327, April 1998.
Authors' Addresses Authors' Addresses
Jani Hautakorpi (editor) Jani Hautakorpi (editor)
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
skipping to change at page 24, line 5 skipping to change at page 23, line 5
Email: ahawrylyshen@ditechnetworks.com Email: ahawrylyshen@ditechnetworks.com
Medhavi Bhatia Medhavi Bhatia
NexTone Communications NexTone Communications
101 Orchard Ridge Drive 101 Orchard Ridge Drive
Gaithersburg, MD 20878 Gaithersburg, MD 20878
US US
Email: mbhatia@nextone.com Email: mbhatia@nextone.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 24, line 29 skipping to change at page 23, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 81 change blocks. 
265 lines changed or deleted 257 lines changed or added

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