One document matched: draft-ietf-sipping-sbc-funcs-04.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc strict="yes"?>
<?rfc symrefs="no"?>
<?rfc sortrefs="yes"?>
<?rfc comments="no"?>
<?rfc inline="no"?>
<!-- LocalWords: xref PPR PPA SAA RTA RTR LIR LIA CDATA
-->
<rfc ipr="full3978" docName="draft-ietf-sipping-sbc-funcs-04.txt" category="info">
<front>
<title abbrev="Requirements from SBC Deployments">
<!-- Functionality of Existing Session Border Controllers (SBCs) --> Requirements from SIP
(Session Initiation Protocol) Session Border Control Deployments </title>
<author initials="J." surname="Hautakorpi" fullname="Jani Hautakorpi" role="editor">
<organization>Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<code>02420</code>
<city>Jorvas</city>
<country>Finland</country>
</postal>
<email>Jani.Hautakorpi@ericsson.com</email>
</address>
</author>
<author initials="G." surname="Camarillo" fullname="Gonzalo Camarillo">
<organization>Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<code>02420</code>
<city>Jorvas</city>
<country>Finland</country>
</postal>
<email>Gonzalo.Camarillo@ericsson.com</email>
</address>
</author>
<author initials="R.F." surname="Penfield" fullname="Robert F. Penfield">
<organization>Acme Packet</organization>
<address>
<postal>
<street>71 Third Avenue</street>
<code>01803</code>
<city>Burlington</city>
<region>MA</region>
<country>US</country>
</postal>
<email>bpenfield@acmepacket.com</email>
</address>
</author>
<author fullname="Alan Hawrylyshen" initials="A." surname="Hawrylyshen">
<organization>Ditech Networks Inc.</organization>
<address>
<postal>
<street>Suite 200, 1167 Kensington Cres NW</street>
<city>Calgary</city>
<region>Alberta</region>
<code>T2N 1X7</code>
<country>Canada</country>
</postal>
<email>ahawrylyshen@ditechnetworks.com</email>
</address>
</author>
<author initials="M." surname="Bhatia" fullname="Medhavi Bhatia">
<organization>3CLogic</organization>
<address>
<postal>
<street>9700 Great Seneca Hwy.</street>
<code>20850</code>
<city>Rockville</city>
<region>MD</region>
<country>US</country>
</postal>
<email>mbhatia@3clogic.com</email>
</address>
</author>
<date day="21" month="December" year="2007"/>
<area>Real-Time Applications and Infrastructure</area>
<workgroup>SIPPING Working Group</workgroup>
<keyword>SBC</keyword>
<keyword>SIP</keyword>
<abstract>
<t> This document describes functions implemented in Session Initiation Protocol (SIP)
intermediaries known as Session Border Controllers (SBCs). The goal of this document is to
describe the commonly provided functions of SBCs. A special focus is given to those
practices that are viewed to be in conflict with SIP architectural principles. This document
also explores the underlying requirements of network operators that have led to the use of
these functions and practices in order to identify protocol requirements and determine
whether those requirements are satisfied by existing specifications or additional standards
work is required.</t>
</abstract>
</front>
<middle>
<!--
Changed comment separators to be syntactically valid, please
do NOT change back to format with no spaces
-->
<!-- ################################### -->
<section title="Introduction" anchor="sec-intro">
<t> In the past few years there has been a rapid adoption of the Session Initiation Protocol
(SIP) <xref target="RFC3261"/> and deployment of SIP-based communications networks. This has
often outpaced the development and implementation of protocol specifications to meet
network operator requirements. This has led to the development of proprietary solutions.
Often, these proprietary solutions are implemented in network intermediaries known in the
marketplace as Session Border Controllers (SBCs) because they typically are deployed at the
border between two networks. The reason for this is that network policies are typically
enforced at the edge of the network.</t>
<t> Even though many SBCs currently behave badly in a sense that they break end-to-end
security and impact feature negotiations, there is clearly a market for them. Network
operators need many of the features current SBCs provide and often there are no standard
mechanisms available to provide them.</t>
<t> The purpose of this document is to describe functions implemented in SBCs. A special focus
is given to those practices that are conflicting with SIP architectural principles in some
way. The document also explores the underlying requirements of network operators that have
led to the use of these functions and practices in order to identify protocol requirements
and determine whether those requirements are satisfied by existing specifications or
additional standards work is required.</t>
</section>
<!-- ################################### -->
<section title="Background on SBCs" anchor="sec-info">
<t> The term SBC is relatively non-specific, since it is not standardized or defined anywhere.
Nodes that may be referred to as SBCs but do not implement SIP are outside the scope of this
document.</t>
<t> SBCs usually sit between two service provider networks in a peering environment, or
between an access network and a backbone network to provide service to residential and/or
enterprise customers. They provide a variety of functions to enable or enhance session-based
multi-media services (e.g., Voice over IP). These functions include: a) perimeter defense
(access control, topology hiding, and DoS prevention and detection); b) functionality not
available in the endpoints (NAT traversal, protocol interworking or repair); and c) network
management (traffic monitoring, management, and QoS). Some of these functions may also get
integrated into other SIP elements (like pre-paid platforms, 3GPP P-CSCF <xref
target="3GPP.23.228"/>, 3GPP I-CSCF, etc).</t>
<t> SIP-based SBCs typically handle both signaling and media and can implement behavior which
is equivalent to a "privacy service" (as described in<xref target="RFC3323"/>) performing
both Header Privacy and Session Privacy). SBCs often modify certain SIP headers and message
bodies that proxies are not allowed to modify. Consequently, they are, by definition, B2BUAs
(Back-to-Back User Agents). The transparency of these B2BUAs varies depending on the
functions they perform. For example, some SBCs modify the session description carried in the
message and insert a Record-Route entry. Other SBCs replace the value of the Contact header
field with the SBCs address, and generate a new Call-ID and new To and From tags.</t>
<figure title="SBC architecture" anchor="fig-SBC_placing">
<artwork><![CDATA[
+-----------------+
| SBC |
[signaling] | +-----------+ |
<------------|->| signaling |<-|---------->
outer | +-----------+ | inner
network | | | network
| +-----------+ |
<------------|->| media |<-|---------->
[media] | +-----------+ |
+-----------------+
]]></artwork>
</figure>
<t>
<xref target="fig-SBC_placing"/> shows the logical architecture of an SBC, which includes a
signaling and a media component. In this document, the terms outer and inner network are
used for describing these two networks.</t>
<!-- ################################### -->
<section title="Peering Scenario" anchor="sec-info-peering">
<t> A typical peering scenario involves two network operators who exchange traffic with each
other. For example, in a toll bypass application, a gateway in operator A's network sends
an INVITE that is routed to the softswitch (proxy) in operator B's network. The proxy
responds with a redirect (3xx) message back to the originating gateway that points to the
appropriate terminating gateway in operator B's network. The originating gateway then
sends the INVITE to the terminating gateway.</t>
<figure title="Peering with SBC" anchor="fig-SBC_peering">
<artwork><![CDATA[
Operator A . Operator B
.
. 2) INVITE
+-----+ . /--------------->+-----+
| SSA | . / 3) 3xx (redir.) | SSB |
+-----+ . / /---------------+-----+
. / /
+-----+ 1) INVITE +-----+--/ / +-----+
|GW-A1|---------------->| SBC |<---/ 4) INVITE |GW-B1|
+-----+ +-----+---------------------->+-----+
.
+-----+ . +-----+
|GW-A2| . |GW-B2|
+-----+ . +-----+
]]></artwork>
</figure>
<t>
<xref target="fig-SBC_peering"/> illustrates the peering arrangement with an SBC where
Operator A is the outer network, and Operator B is the inner network. Operator B can use
the SBC, for example, to control access to its network, protect its gateways and
softswitches from unauthorized use and DoS attacks, and monitor the signaling and media
traffic. It also simplifies network management by minimizing the number ACL (Access
Control List) entries in the gateways. The gateways do not need to be exposed to the peer
network, and they can restrict access (both media and signaling) to the SBCs. The SBC
helps ensure that only media from sessions the SBC authorizes will reach the gateway.</t>
</section>
<!-- ################################### -->
<section title="Access Scenario" anchor="sec-info-access">
<t> In an access scenario, presented in <xref target="fig-SBC_access"/>, the SBC is placed
at the border between the access network (outer network) and the operator's network (inner
network) to control access to the operator's network, protect its components (media servers,
application servers, gateways, etc.) from unauthorized use and DoS attacks, and monitor
the signaling and media traffic. Also, since the SBC is call stateful, it may provide
access control functions to prevent over subscription of the access links. Endpoints are
configured with the SBC as their outbound proxy address. The SBC routes requests to one or
more proxies in the operator network.</t>
<figure title="Access scenario with SBC" anchor="fig-SBC_access">
<artwork><![CDATA[
Access Network Operator Network
+-----+
| UA1 |<---------\
+-----+ \
\
+-----+ \------->+-----+ +-------+
| UA2 |<-------------------->| SBC |<----->| proxy |<-- -
+-----+ /--->+-----+ +-------+
/
+-----+ +-----+ /
| UA3 +---+ NAT |<---/
+-----+ +-----+
]]></artwork>
</figure>
<t> The SBC may be hosted in the access network (e.g,. this is common when the access
network is an enterprise network), or in the operator network (e.g., this is common when
the access network is a residential or small business network).</t>
<t> Some endpoints may be behind enterprise or residential NATs. In cases where the access
network is a private network, the SBC is the NAT for all traffic. The proxy usually does
authentication and/or authorization for registrations and outbound calls. The SBC modifies
the REGISTER request so that subsequent requests to the registered address-of-record are
routed to the SBC. This is done either with a Path header, or by modifying the Contact to
point at the SBC.</t>
<t> 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.</t>
</section>
</section>
<!-- ################################### -->
<section title="Functions of SBCs" anchor="sec-func">
<t> This section lists those functions that are used in SBC deployments in current
communication networks. Each subsection describes a particular function or feature, the
operators' requirements for having it, explanation of any impact to the end-to-end SIP
architecture, and a concrete implementation example. Each section also discusses potential
concerns specific to that particular implementation technique. Suggestions for alternative
implementation techniques that may be more architecturally compatible with SIP are outside
the scope of this document.</t>
<t> All the examples given in this section are simplified; only the relevant header lines from
SIP and SDP <xref target="RFC4566"/> messages are displayed.</t>
<!-- ################################### -->
<section title="Topology Hiding" anchor="sec-func-topology">
<!-- ################################### -->
<section title="General Information and Requirements" anchor="sec-func-topology-info">
<t> Topology hiding consists of limiting the amount of topology information given to
external parties. Operators have a requirement for this functionality because they do
not want the IP addresses of their equipment (proxies, gateways, application servers,
etc) to be exposed to outside parties. This may be because they do not want to expose
their equipment to DoS (Denial of Service) attacks, they may use other carriers for
certain traffic and do not want their customers to be aware of it or they may want to
hide their internal network architecture from competitors or partners. In some
environments, the operator's customers may wish to hide the addresses of their equipment
or the SIP messages may contain private, non-routable addresses.</t>
<t> The most common form of topology hiding is the application of header privacy (see
Section 5.1 of <xref target="RFC3323"/>), which involves stripping Via and Record-Route
headers, replacing the Contact header, and even changing Call-IDs. However, in
deployments which use IP addresses instead of domain names in headers that cannot be
removed (e.g. From and To headers), the SBC may replace these IP addresses with its own
IP address or domain name.</t>
</section>
<!-- ################################### -->
<section title="Architectural Issues" anchor="sec-func-topology-arch-issue">
<t> 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 subscriber consent and could potentially
modify or remove information about the user's privacy, security requirements and higher
layer 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 actions from a Man-In-The-Middle
(MitM) attack.</t>
<t> Topology hiding function does not work well with Authenticated Identity Management <xref
target="RFC4474"/>. The Authenticated Identity Management mechanism is based on a hash
value that is calculated from parts of From, To, Call-Id, CSeq, Date, and Contact header
fields plus from the whole message body. If the authentication service is not provided
by the SBC itself, the modification of the forementioned header fields and the message
body is in violation of <xref target="RFC4474"/>. Some forms of topology hiding are in
violation, because they are e.g., replacing the Contact header of a SIP message.</t>
<!--
<t> Modification of IP addresses in Uniform Resource Identifiers (URIs) within SIP headers
can lead to application failures if these URIs are communicated to other SIP servers
outside the current dialog. These 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 SBC, it
has the opportunity to restore the original IP address. On the other hand, if the REFER
or NOTIFY message returns to the original network through a different SBC that does not
have access to the address mapping, the recipient of the message will not see the
original address. This may cause the application function to fail.</t>
-->
</section>
<!-- ################################### -->
<section title="Example" anchor="sec-func-topology-example">
<t> 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 of topology information (e.g.,
Via and Record-Route entries) from outgoing messages.</t>
<t> Imagine the following example scenario: The SBC (p4.domain.example.com) receives
an INVITE request from the inner network, which in this case is an operator network. The
received SIP message is shown in <xref target="pre-topo-hide"/>.</t>
<figure title="INVITE Request Prior to Topology Hiding" anchor="pre-topo-hide">
<artwork><![CDATA[
INVITE sip:callee@u2.domain.example.com SIP/2.0
Via: SIP/2.0/UDP p3.middle.example.com;branch=z9hG4bK48jq9w9174131.1
Via: SIP/2.0/UDP p2.example.com;branch=z9hG4bK18an6i9234172.1
Via: SIP/2.0/UDP p1.example.com;branch=z9hG4bK39bn2e5239289.1
Via: SIP/2.0/UDP u1.example.com;branch=z9hG4bK92fj4u7283927.1
Contact: sip:caller@u1.example.com
Record-Route: <sip:p3.middle.example.com>
Record-Route: <sip:p2.example.com;lr>
Record-Route: <sip:p1.example.com;lr>
]]></artwork>
</figure>
<t> Then the SBC performs a topology hiding function. In this scenario, the SBC removes
and stores all existing Via and Record-Route headers, and then inserts a Via and
Record-Route header fields with its own SIP URI. After the topology hiding function, the
message could appear as shown in <xref target="post-topo-hide"/>.</t>
<figure title="INVITE Request After Topology Hiding" anchor="post-topo-hide">
<artwork><![CDATA[
INVITE sip:callee@u2.domain.example.com SIP/2.0
Via: SIP/2.0/UDP p4.domain.example.com;branch=z9hG4bK92es3w1230129.1
Contact: sip:caller@u1.example.com
Record-Route: <sip:p4.domain.example.com;lr>
]]></artwork>
</figure>
<t> Like a regular proxy server that inserts a Record-Route entry, the SBC handles every
single message of a given SIP dialog. If the SBC loses state (e.g., the SBC restarts for
some reason), it may not be able to route messages properly. For example, if the SBC
removes <spanx style="verb">Via</spanx> entries from a request and then restarts, thus
losing state, the SBC may not be able to route responses to that request; depending on
the information that was lost when the SBC restarted.</t>
<t> This is only one example of topology hiding. In some cases, SBCs may modify other
headers, including the Contact header field values. The header fields containing
identity information is listed in Section 4.1 of <xref target="RFC3323"/>. Since the
publication of <xref target="RFC3323"/>, the following header fields containing identity
information have been defined: <spanx style="verb">P-Asserted-Identity</spanx>, <spanx
style="verb">Referred-By</spanx>, <spanx style="verb">Identity</spanx>, and <spanx
style="verb">Identity-Info</spanx>.</t>
<!--
draft-munakata-sip-privacy-guideline-01 lists the following, additional headers that
carry identity information (draft-ietf-sip-ua-privacy-00 did not really have a list of
identity containing headers):
P-Asserted-Identity (RFC3325)
Referred-By (RFC3892)
Identity (RFC4474)
Identity-Info (RFC4474)
-->
</section>
</section>
<!-- ################################### -->
<section title="Media Traffic Management" anchor="sec-func-shape">
<!-- ################################### -->
<section title="General Information and Requirements" anchor="sec-func-shape-info">
<t> Media traffic management is the function of controlling media traffic. Network operators
may require this functionality in order to control the traffic being carried on their
network on behalf of their subscribers. Traffic management helps the creation of different
kinds of billing models (e.g., video telephony can be priced differently to voice-only
calls) and it also makes it possible for operators to enforce the usage of selected
codecs. Additionally, traffic management can be used to implement intercept capabilities
where required to support audit or legal obligations.</t>
<t> Since the media path is independent of the signaling path, the media may not traverse
through the operator's network unless the SBC modifies the session description. By
modifying the session description the SBC can force the media to be sent through a media
relay which may be co-located with the SBC. This kind of traffic management can be done,
for example, to ensure a certain QoS (Quality of Service) level.</t>
<t> Some operators do not want to manage the traffic (e.g., allowing only certain
codecs), but only to monitor it for collecting statistics and making sure that they are
able to meet any business service level agreements with their subscribers and/or
partners. The protocol techniques needed for monitoring media traffic are the same as
for managing media traffic.</t>
<t> SBCs on the media path are also capable of dealing with the "lost BYE" issue if either
endpoint dies in the middle of the session. The SBC can detect that the media has
stopped flowing and issue a BYE to both sides to cleanup any state in other intermediate
elements and the endpoints.</t>
<t> One possible form of media traffic management is that SBCs terminate media streams and
SIP dialogs by generating BYE requests. This kind of procedure can take place, for
example, in a situation where subscriber runs out of credits. Media management is needed
for ensuring that the subscriber cannot just ignore the BYE request generated by the SBC
and continue their media sessions.</t>
</section>
<!-- ################################### -->
<section title="Architectural Issues" anchor="sec-func-shape-arch-issue">
<t> Implementing traffic management in this manner requires the SBC to access and modify
the session descriptions (i.e., offers and answers) exchanged between the user-agents.
Consequently, this approach does not work if user-agents encrypt or integrity-protect
their message bodies end-to-end. Again, messages are modified without subscriber
consent, and user-agents do not have any way to distinguish the SBC actions from an
attack by a MitM. Furthermore, this is in violation of <xref target="RFC4474"/>, see
<xref target="sec-func-topology-arch-issue"/>.</t>
<t>Media traffic management function also hinders innovations. The reason for the
hinderance is that in many cases SBCs need to be able to support new ways of
communicating (e.g., extensions to the SDP protocol) before new services can be taken
into use, and that slows down the adoption of innovations.</t>
<t>In this application, the SBC may originate messages that the user may not be able to
authenticate as coming from the dialog peer or the SIP Registrar/Proxy.</t>
</section>
<!-- ################################### -->
<section title="Example" anchor="sec-func-shape-example">
<t> Traffic management may be performed in the following way: The SBC behaves as a B2BUA
and inserts itself, or some other entity under the operator's control, in the media
path. In practice, the SBC modifies the session descriptions carried in the SIP
messages. As a result, the SBC receives media from one user-agent and relays it to the
other user-agent and performs the identical operation with media traveling in the
reverse direction.</t>
<t> As mentioned in <xref target="sec-func-shape-info"/>, codec restriction is a form of
traffic management. The SBC restricts the codec set negotiated in the offer/answer
exchange <xref target="RFC3264"/> between the user-agents. After modifying the session
descriptions, the SBC can check whether or not the media stream corresponds to what was
negotiated in the offer/answer exchange. If it differs, the SBC has the ability to
terminate the media stream or take other appropriate (configured) actions (e.g. raise an
alarm).</t>
<t>Consider the following example scenario: The SBC receives an INVITE request from
the outer network, which in this case is an access network. The received SIP message
contains the SDP session descriptor shown in <xref target="pre-media-shape"/>.</t>
<figure anchor="pre-media-shape" title="Request Prior to Media Management">
<artwork><![CDATA[
v=0
o=mhandley 2890844526 2890842807 IN IP4 192.0.2.4
c=IN IP4 192.0.2.4
m=audio 49230 RTP/AVP 96 98
a=rtpmap:96 L8/8000
a=rtpmap:98 L16/16000/2
]]></artwork>
</figure>
<t> In this example, the SBC performs the media traffic management function by rewriting
the 'm' line, and removing one 'a' line according to some (external) policy. <xref
target="post-media-shape"/> shows the session description after the traffic management
function.</t>
<figure title="Request Body After Media Management" anchor="post-media-shape">
<artwork><![CDATA[
v=0
o=mhandley 2890844526 2890842807 IN IP4 192.0.2.4
c=IN IP4 192.0.2.4
m=audio 49230 RTP/AVP 96
a=rtpmap:96 L8/8000
]]></artwork>
</figure>
<t> Media traffic management has a problem where the SBC needs to understand the session
description protocol and all extensions used by the user-agents. This means that in
order to use a new extension (e.g., an extension to implement a new service) or a new
session description protocol, SBCs in the network may need to be upgraded in conjunction
with the endpoints. It is noteworthy that similar problem, but with header fields,
applies to, for example, topology hiding function, see <xref
target="sec-func-topology"/>. Certain extensions that do not require active manipulation
of the session descriptors to facilitate traffic management will be able to be deployed
without upgrading existing SBCs, depending on the degree of transparency the SBC
implementation affords. In cases requiring an SBC modification to support the new
protocol features, the rate of service deployment may be affected.</t>
</section>
</section>
<!-- ################################### -->
<section title="Fixing Capability Mismatches" anchor="sec-func-mismatch">
<!-- ################################### -->
<section title="General Information and Requirements" anchor="sec-func-mismatch-info">
<t> SBCs fixing capability mismatches enable communications between user-agents with
different capabilities or extensions. For example, user-agents on networks which
implement SIP differently (for example 3GPP or Packet Cable etc) or those that support
different IP versions, different codecs, or that are in different address realms.
Operators have a requirement and a strong motivation for performing capability mismatch
fixing, so that they can provide transparent communication across different domains. In
some cases different SIP extensions or methods to implement the same SIP application
(like monitoring session liveness, call history/diversion etc) may also be interworked
through the SBC.</t>
</section>
<!-- ################################### -->
<section title="Architectural Issues" anchor="sec-func-mismatch-arch-issue">
<t> SBCs fixing capability mismatches insert a media element in the media path using the
procedures described in <xref target="sec-func-shape"/>. Therefore, these SBCs have the
same concerns as SBCs performing traffic management: the SBC modifies SIP messages
without explicit consent from any of the user-agents. This may break end-to-end security
and application extensions negotiation.</t>
<t> The capability mismatch fixing is a fragile function in the long term. The number of
incompatibilities built into various network elements is increasing the fragility and
complexity over time. This might lead to a situation where SBCs need to be able to
handle a large number of capability mismatches in parallel.</t>
</section>
<!-- ################################### -->
<section title="Example" anchor="sec-func-mismatch-example">
<t> Consider the following example scenario where the inner network is an access network
using IPv4 and the outer network is using IPv6. The SBC receives an INVITE request with
a session description from the access network:</t>
<figure title="Request Prior to Capabilities Match" anchor="pre-caps-match">
<artwork><![CDATA[
INVITE sip:callee@ipv6.domain.example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4
Contact: sip:caller@u1.example.com
v=0
o=mhandley 2890844526 2890842807 IN IP4 192.0.2.4
c=IN IP4 192.0.2.4
m=audio 49230 RTP/AVP 96
a=rtpmap:96 L8/8000
]]></artwork>
</figure>
<t> Then the SBC performs a capability mismatch fixing function. In this scenario
the SBC inserts Record-Route and Via headers, and rewrites the 'c' line from the
sessions descriptor. <xref target="post-caps-match"/> shows the request after the
capability mismatch adjustment.</t>
<figure anchor="post-caps-match" title="Request After Capability Match">
<artwork><![CDATA[
INVITE sip:callee@ipv6.domain.com SIP/2.0
Record-Route: <sip:[2001:DB8::801:201:2ff:fe94:8e10];lr>
Via: SIP/2.0/UDP sip:[2001:DB8::801:201:2ff:fe94:8e10]
Via: SIP/2.0/UDP 192.0.2.4
Contact: sip:caller@u1.example.com
v=0
o=mhandley 2890844526 2890842807 IN IP4 192.0.2.4
c=IN IP6 2001:DB8::801:201:2ff:fe94:8e10
m=audio 49230 RTP/AVP 96
a=rtpmap:96 L8/8000
]]></artwork>
</figure>
<t> This message is then sent by the SBC to the onward IPv6 network.</t>
</section>
</section>
<!-- ################################### -->
<section title="Maintaining SIP-related NAT Bindings" anchor="sec-func-nats">
<!-- ################################### -->
<section title="General Information and Requirements" anchor="sec-func-nats-info">
<t> NAT traversal in this instance refers to the specific message modifications required
to assist a user-agent in maintaining SIP and media connectivity when there is a NAT
device located between a user-agent and a proxy/registrar and, possibly, any other
user-agent. </t>
<t> An SBC performing a NAT (Network Address Translator) traversal function for a user
agent behind a NAT sits between the user-agent and the registrar of the domain. NATs are
widely deployed in various access networks today, so operators have a requirement to
support it. When the registrar receives a REGISTER request from the user-agent and
responds with a 200 (OK) response, the SBC modifies such a response decreasing the
validity of the registration (i.e., the registration expires sooner). This forces the
user-agent to send a new REGISTER to refresh the registration sooner that it would have
done on receiving the original response from the registrar. The REGISTER requests sent
by the user-agent refresh the binding of the NAT before the binding expires.</t>
<t> Note that the SBC does not need to relay all the REGISTER requests received from the
user-agent to the registrar. The SBC can generate responses to REGISTER requests
received before the registration is about to expire at the registrar. Moreover, the SBC
needs to deregister the user-agent if this fails to refresh its registration in time,
even if the registration at the registrar would still be valid.</t>
<t> Operators implement this functionality in an SBC instead of in the registrar for
several reasons: (i) preventing packets from unregistered users to prevent chances of
DoS attack, (ii) prioritization and/or re-routing of traffic (based on user or service,
like E911) as it enters the network, and (iii) performing a load balancing function or
reducing the load on other network equipment.</t>
<t> SBCs can also force traffic to go through a media relay for NAT traversal purposes (more
about media traffic management in <xref target="sec-func-shape"/>). A typical call has
media streams to two directions. Even though SBCs can force media streams from both
directions to go through a media relay, in some cases it is enough to relay only the
media from one direction (e.g., in a scenario where only other endpoint is behind a
NAT).</t>
</section>
<!-- ################################### -->
<section title="Architectural Issues" anchor="sec-func-nats-arch-issue">
<t> This approach to NAT traversal does not work when end-to-end confidentiality or
integrity-protection is used. The SBC would be seen as a MitM modifying the messages
between the user-agent and the registrar.</t>
<t> There is also a problem related to the method how SBCs choose the value for the
validity of a registration period. This value should be as high as possible, but it
still needs to be low enough to maintain the NAT binding. Typically SBCs do not have any
deterministic method for choosing a suitable value. </t>
</section>
<!-- ################################### -->
<section title="Example" anchor="sec-func-nats-example">
<t> Consider the following example scenario: The SBC resides between the UA and Registrar.
Previously the UA has sent a REGISTER request to Registrar, and the SBC receives the
registration response shown in <xref target="pre-nats"/>. </t>
<figure anchor="pre-nats" title="Response Prior to NAT Maintenance Function">
<artwork><![CDATA[
SIP/2.0 200 OK
From: Bob <sip:bob@biloxi.example.com>;tag=a73kszlfl
To: Bob <sip:bob@biloxi.example.com>;tag=34095828jh
CSeq: 1 REGISTER
Contact: <sips:bob@client.biloxi.example.com>;expires=3600
]]></artwork>
</figure>
<t> When performing the NAT traversal function, the SBC may re-write the expiry time to
coax the UA to re-register prior to the intermediating NAT deciding to close the
pinhole. <xref target="post-nats"/> shows a possible modification of the response from
<xref target="pre-nats"/>. </t>
<figure title="Manipulated Response for NAT Traversal" anchor="post-nats">
<artwork><![CDATA[
SIP/2.0 200 OK
From: Bob <sip:bob@biloxi.example.com>;tag=a73kszlfl
To: Bob <sip:bob@biloxi.example.com>;tag=34095828jh
CSeq: 1 REGISTER
Contact: <sips:bob@client.biloxi.example.com>;expires=60
]]></artwork>
</figure>
<t> Naturally also other measures need to be taken in order to enable the NAT traversal,
but this example illustrates only one mechanism for preserving the SIP related NAT
bindings.</t>
</section>
</section>
<!-- ################################### -->
<section title="Access Control" anchor="sec-func-access">
<!-- ################################### -->
<section title="General Information and Requirements" anchor="sec-func-access-info">
<t> Network operators may wish to control what kind of signaling and media traffic their
network carries. There is strong motivation and a requirement to do access control on
the edge of an operator's network. Access control can be based on, for example,
link-layer identifiers, IP addresses or SIP identities.</t>
<t> This function can be implemented by protecting the inner network with firewalls and
configuring them so that they only accept SIP traffic from the SBC. This way, all the
SIP traffic entering the inner network needs to be routed though the SBC, which only
routes messages from authorized parties or traffic that meets a specific policy that is
expressed in the SBC administratively.</t>
<t> Access control can be applied either only to the signaling, or to both the signaling
and media. If it is applied only to the signaling, then the SBC might behave as a proxy
server. If access control is applied to both the signaling and media, then the SBC
behaves in a similar manner as explained in <xref target="sec-func-shape"/>. A key part
of media-layer access control is that only media for authorized sessions is allowed to
pass through the SBC and/or associated media relay devices.</t>
<t> In environments where there is limited bandwidth on the access links, the SBC can
compute the potential bandwidth usage by examining the codecs present in SDP offers and
answers. With this information, the SBC can reject sessions before the available
bandwidth is exhausted to allow existing sessions to maintain acceptable quality of
service. Otherwise, the link could become over subscribed and all sessions would
experience a deterioration in quality of service. SBCs may contact a policy server to
determine whether sufficient bandwidth is available on a per-session basis.</t>
</section>
<!-- ################################### -->
<section title="Architectural Issues" anchor="sec-func-access-arch-issue">
<t>Since the SBC needs to handle all SIP messages, this function has scalability
implications. In addition, the SBC is a single point of failure from an architectural
point of view. Although, in practice, many current SBCs have the capability to support
redundant configuration, which prevents the loss of calls and/or sessions in the event
of a failure on a single node.</t>
<t> If access control is performed only on behalf of signaling, then the SBC is compatible
with general SIP architectural principles, but if it is performed for signaling and for
media, then there are similar problems as described in <xref
target="sec-func-shape-arch-issue"/>.</t>
</section>
<!-- ################################### -->
<section title="Example" anchor="sec-func-access-example">
<t>
<xref target="pre-access-flow"/> shows a callflow where the SBC is providing both
signaling and media access control (ACKs omitted for brevity).</t>
<figure title="Example Access Callflow" anchor="pre-access-flow">
<artwork><![CDATA[
caller SBC callee
| | |
| Identify the caller | |
|<- - - - - - - - - - - >| |
| | |
| INVITE + SDP | |
|----------------------->| |
| [Modify the SDP] |
| | INVITE + modified SDP |
| |----------------------->|
| | |
| | 200 OK + SDP |
| |<-----------------------|
| [Modify the SDP] |
| | |
| 200 OK + modified SDP | |
|<-----------------------| |
| | |
| Media [Media inspection] Media |
|<======================>|<======================>|
| | |
]]></artwork>
</figure>
<!-- This kind of authentication is used e.g. in IMS (2 x REGISTER > IPsec) -->
<t> In this scenario, the SBC first identifies the caller, so it can determine whether or
not to give signaling access for the caller. This might be achieved using information
gathered during registration, or by other means. Some SBCs may rely on the proxy to
authenticate the user-agent placing the call. After identification, the SBC modifies the
session descriptors in INVITE and 200 OK messages in a way that the media is going to
flow through the SBC itself. When the media starts flowing, the SBC can inspect whether the
callee and caller use the codec(s) that they had previously agreed on.</t>
</section>
</section>
<!-- ################################### -->
<section title="Protocol Repair" anchor="sec-func-repair">
<!-- ################################### -->
<section title="General Information and Requirements" anchor="sec-func-repair-info">
<t> SBCs are also used to repair protocol messages generated by not-fully-standard clients.
Operators may wish to support protocol repair, if they want to support as many
clients as possible. It is noteworthy, that this function affects only the signaling
component of an SBC, and that protocol repair function is not the same as protocol
conversion.</t>
<t> </t>
</section>
<!-- ################################### -->
<section title="Architectural Issues" anchor="sec-func-repair-arch-issue">
<t> In most cases, this function can be seen as being compatible with SIP architectural
principles, and it does not violate the end-to-end model of SIP. The SBC repairing
protocol messages behaves as a proxy server that is liberal in what it accepts and
strict in what it sends.</t>
<t> A similar problem related to increasing complexity, as explained in <xref
target="sec-func-mismatch-arch-issue"/>, also affects protocol repair function.</t>
</section>
<!-- ################################### -->
<section title="Examples" anchor="sec-func-repair-example">
<t> The SBC can, for example, receive an INVITE message from a relatively new SIP UA as
illustrated in <xref target="pre-repair"/>.</t>
<figure title="Request from a relatively new client" anchor="pre-repair">
<artwork><![CDATA[
INVITE sip:callee@sbchost.example.com
Via: SIP/2.0/UDP u1.example.com:5060;lr
From: Caller <sip:caller@one.example.com>
To: Callee <sip:callee@two.example.com>
Call-ID: 18293281@u1.example.com
CSeq: 1 INVITE
Contact: sip:caller@u1.example.com
]]></artwork>
</figure>
<t> If the SBC does protocol repair, it can re-write the 'lr' parameter on the Via header
field into the form 'lr=true', in order to support some older, non-standard SIP stacks.
It could also remove excess white spaces to make the SIP message more human
readable.</t>
<!-- ########### Removed due to comments from Francois Audet & Michael Procter #########
<t> Some other examples of "protocol repair" that have been implemented in
commercially available SBCs include:</t>
<t>
<list style="symbols">
<t> Changing Content-Disposition from "signal" to "session". This was required for a
user-agent which sent an incorrect Content-Disposition header. </t>
<t> 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.
</t>
<t> Addition of a to-tag to provisional or error responses. </t>
<t> 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. </t>
<t> Correction of SDP syntax where the user-agent used "annexb=" in the fmtp attribute
instead of the proper "annexb:". </t>
<t> Correction of signaling errors (convert BYE to CANCEL) for termination of early
sessions. </t>
<t> 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. </t>
</list>
</t>
############# -->
</section>
</section>
<!-- ################################### -->
<section title="Media Encryption" anchor="sec-func-medenc">
<!-- ################################### -->
<section title="General Information and Requirements" anchor="sec-func-medenc-info">
<t> 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 access network (outer
network) side and the media is carried unencrypted in the inner network. Operators may
have an obligation to provide the ability to do legal interception, while they still
want to give their customers the ability to encrypt media in the access network. This
leads to a situation where operators have a requirement to perform media encryption
function.</t>
</section>
<!-- ################################### -->
<section title="Architectural Issues" anchor="sec-func-medenc-arch-issue">
<t> While performing a media encryption function, SBCs need to be able to inject either
themselves, or some other entity to the media path. It must be noted that this kind of
behavior is the same as a classical MitM attack. Due to this, the SBCs have the same
architectural issues as explained in <xref target="sec-func-shape"/>.</t>
</section>
<!-- ################################### -->
<section title="Example" anchor="sec-func-medenc-example">
<t>
<xref target="medenc-callflow"/> shows an example where the SBC is performing media
encryption related functions (ACKs omitted for brevity).</t>
<figure title="Media Encryption Example" anchor="medenc-callflow">
<artwork><![CDATA[
caller SBC#1 SBC#2 callee
| | | |
| INVITE + SDP | | |
|------------------->| | |
| [Modify the SDP] | |
| | | |
| | INVITE + mod. SDP | |
| |------------------->| |
| | [Modify the SDP] |
| | | |
| | | INVITE + mod. SDP |
| | |------------------->|
| | | |
| | | 200 OK + SDP |
| | |<-------------------|
| | [Modify the SDP] |
| | | |
| | 200 OK + mod. SDP | |
| |<-------------------| |
| [Modify the SDP] | |
| | | |
| 200 OK + mod. SDP | | |
|<-------------------| | |
| | | |
| Encrypted | Plain | Encrypted |
| media [enc./dec.] media [enc./dec.] media |
|<==================>|<- - - - - - - - ->|<==================>|
| | | |
]]></artwork>
</figure>
<t> First the UAC sends an INVITE request , and the first SBC modifies the session
descriptor in a way that it injects itself to the media path. The same happens in the
second SBC. Then the UAS replies with a 200 OK response, the SBCs inject themselves in
the returning media path. After signaling the media start flowing, and both SBCs are
performing media encryption and decryption.</t>
</section>
</section>
</section>
<!-- ################################### -->
<section title="Derived Requirements for Future SIP Standardization Work"
anchor="proto-requirements">
<!--
<t> TODO: enumerate protocol requirements based on network operator requirements and identify
which are satisfied by existing work and which may require new work.</t>
-->
<t>Some of the functions listed in this document are more SIP-unfriendly than others. This
list of requirements is derived from the functions that break the principles of SIP in
one way or another. The derived requirements are:</t>
<t><list style="format Req-%d:">
<t>There should be a SIP-friendly way to hide network topology information. Currently this is
done by stripping and replacing header fields, which is against the principles of SIP.</t>
<t>There should be a SIP-friendly way to direct media traffic through intermediaries.
Currently this is done without user consent by modifying session descriptors, which is
against the principles of SIP.</t>
<t>There should be a SIP-friendly way to fix capability mismatches in SIP messages. This
requirement is harder to fulfill on complex mismatch cases, like the 3GPP/Packet Cable
mismatch. Currently this is done by modifying SIP messages, which violates end-to-end
security.</t>
</list></t>
<t>Req-1 and Req-3 does not have an exiting solution today. There is ongoing work in the
IETF for addressing Req-2, such as SIP session policies, Traversal Using Relays around NAT
(TURN), and Interactive Connectivity Establishment (ICE). Nonetheless, future work is needed
in order to develop solutions to these requirements.</t>
<!-- I didn't add references to SIP session policies, TURN, and ICE, because they are still
on a draft-stage -->
</section>
<!-- ################################### -->
<section title="Security Considerations" anchor="sec-security">
<t> Many of the functions this document describes have important security and privacy
implications. One major security problem is that many functions implemented by SBCs (e.g.,
topology hiding and media traffic management) modify SIP messages and their bodies without the
user agents' consent. The result is that the user agents may interpret the actions taken
by an SBC as a MitM attack.</t>
<t> SBCs that place themselves (or another entity) on the media path can be used to eavesdrop
on conversations. Since, often, user agents cannot distinguish between the actions of an
attacker and those of an SBC, users cannot know whether they are being eavesdropped or an SBC
on the path is performing some other function. </t>
<t> An SBC is a single point of failure from the architectural point of view. This makes it an
attractive target for DoS attacks. The fact that some functions of SBCs require those SBCs
to maintain session specific information makes the situation even worse. If the SBC crashes
(or is brought down by an attacker), ongoing sessions experience undetermined behavior.</t>
<t> If the IETF decides to develop standard mechanisms to address the requirements presented
in <xref target="proto-requirements"/>, the security and privacy-related aspects of those
mechanisms will, of course, need to be taken into consideration.</t>
</section>
<!-- ################################### -->
<section title="IANA Considerations" anchor="sec-iana">
<t> This document has no IANA considerations.</t>
</section>
<!-- ################################### -->
<section title="Acknowledgements" anchor="sec-acks">
<t> The ad-hoc meeting about SBCs, held on Nov 9th 2004 at Washington DC during the 61st IETF
meeting, provided valuable input to this document. Authors would also like to thank Sridhar
Ramachandran, Gaurav Kulshreshtha, and Rakendu Devdhar. Reviewers Spencer Dawkins and
Francois Audet also deserve special thanks.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.3261"?>
<?rfc include="reference.RFC.3323"?>
<?rfc include="reference.RFC.3264"?>
<?rfc include="reference.RFC.4474"?>
</references>
<references title="Informational References">
<?rfc include="reference.RFC.4566"?>
<?rfc include="reference.3GPP.23.228"?>
</references>
</back>
</rfc>
<!-- LocalWords: xref PPR PPA SAA RTA RTR LIR LIA CDATA
-->
| PAFTECH AB 2003-2026 | 2026-04-24 02:58:17 |