One document matched: draft-camarillo-sipping-sbc-funcs-01.txt
Differences from draft-camarillo-sipping-sbc-funcs-00.txt
SIPPING Working Group J. Hautakorpi, Ed.
Internet-Draft G. Camarillo
Expires: January 19, 2006 Ericsson
M. Bhatia
NexTone Communications
R. Penfield
Acme Packet
A. Hawrylyshen
Ditech Communications Corporation
July 18, 2005
SIP (Session Initiation Protocol)-Unfriendly Functions in Current
Communication Architectures
draft-camarillo-sipping-sbc-funcs-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 19, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document gives an overview to SIP-unfriendly functions in
Hautakorpi, et al. Expires January 19, 2006 [Page 1]
Internet-Draft SIP-Unfriendly Functions July 2005
current communication architectures. These functions are generally
implemented in SBCs (Session Border Controllers). The purpose of
this document is to help the IETF community understand what SIP-
unfriendly functions can be found in existing networks so that the
appropriate working groups can decide whether or not new standard
solutions need to be developed to provide such functionality (or a
subset of it) in a standard, SIP-friendly way. Working groups may
also develop recommendations on how to use existing standard
mechanisms to provide such functionality.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background on SBCs . . . . . . . . . . . . . . . . . . . . . . 3
3. SIP-Unfriendly Functions . . . . . . . . . . . . . . . . . . . 4
3.1 Topology Hiding . . . . . . . . . . . . . . . . . . . . . 4
3.2 Media Traffic Shaping . . . . . . . . . . . . . . . . . . 5
3.3 Fixing Capability Mismatches . . . . . . . . . . . . . . . 6
3.4 NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1 Normative References . . . . . . . . . . . . . . . . . . . 7
7.2 Informational References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . 10
Hautakorpi, et al. Expires January 19, 2006 [Page 2]
Internet-Draft SIP-Unfriendly Functions July 2005
1. Introduction
This document gives an overview to SIP [1] unfriendly functions in
current communication architectures. These functions are generally
implemented in Session Border Controllers (SBCs). The reason for
this is that network policies are typically enforced at the edge of
the network, and SBCs are typically located there.
Of course, a typical SBC does not only implement SIP-unfriendly
functions. They usually implement a set of functions, some of which
are perfectly legal from the SIP point of view. However, this
document focuses on those functions that break SIP somehow.
Many existing SBCs use proprietary solutions because there is no
standard solution for a given issue or because the standard solution
does not fully meet the requirements of the network operator. This
document is intended to be taken as input by the IETF so that the
appropriate working groups can decide whether or not new standard
solutions need to be developed to provide the same functionality (or
a subset of it) in a SIP-friendly way. Working groups may also
decide to develop recommendations on how to use existing standard
mechanisms to provide such functionality.
2. Background on SBCs
The term SBC is pretty vague, 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.
Even though many SBCs currently break things like end-to-end security
and can impact feature negotiations, there is clearly a market for
them. Network operators need many of the features current SBCs
provide and many times there are no standard mechanisms available to
provide them in a better way.
SIP-based SBCs typically handle both signaling and media, and often
modify the session descriptions contained in SIP messages.
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.
Hautakorpi, et al. Expires January 19, 2006 [Page 3]
Internet-Draft SIP-Unfriendly Functions July 2005
+-----------------+
| SBC |
[signaling] | +-----------+ |
<------------|->| signaling |<-|---------->
outer | +-----------+ | inner
network | | | network
| +-----------+ |
<------------|->| media |<-|---------->
[media] | +-----------+ |
+-----------------+
Figure 1: SBC architecture
Figure 1 shows the logical architecture of an SBC, which includes a
signaling and a media component. Typically SBCs are located between
two networks. In this document, the terms outer and inner network
are used for describing these two networks.
There are two typical deployment scenarios where SBCs are used. The
first one of them is a peering scenario, where the SBC is located
between different-operators' networks. The second deployment
scenario is an access scenario, where the SBC is located between the
access network and the operator's network.
3. SIP-Unfriendly Functions
This section examines SIP-unfriendly functions that are used in
current communication networks. Each subsection describes a
particular function or feature, what is the operator's motivation for
having it, how it is currently implemented, and why it breaks SIP.
Each section also discusses the problems associated to that
particular way of implementing it. Providing suggestions for
alternative, more SIP-friendly ways of implementing each of the
functions is outside the scope of this document.
3.1 Topology Hiding
Topology hiding consists of limiting the amount of topology
information given to external parties. Operators want to have 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 or because they
may use other carriers for certain traffic and do not want their
customers to be aware of it. 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.
Hautakorpi, et al. Expires January 19, 2006 [Page 4]
Internet-Draft SIP-Unfriendly Functions July 2005
The current way of implementing topology 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.
Like a regular proxy server that inserts a Record-Route entry, the
SBC handles every single message of a given SIP dialog. However,
unlike the proxy server, if the SBC loses state (e.g., the SBC
restarts for some reason), it will not be able to route messages
properly. For example, if the SBC removes Via entries from a request
and then restarts losing state, the SBC will not be able to route
responses to that request.
3.2 Media Traffic Shaping
Media traffic shaping is the act of controlling media traffic.
Operators have several reasons for having this functionality.
Operators want to control the traffic they carry on their network.
Traffic shaping helps them create different kinds of billing models
(e.g., video telephony can be priced differently than voice-only
calls). Additionally, traffic shaping can be used to implement
intercept capabilities (e.g., lawful intercept).
Some operators do not actually want to reshape the traffic, but only
to monitor it. However, the SIP techniques needed for monitoring
media traffic are the same as for reshaping media traffic.
Currently, traffic shaping is 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 in both directions.
An example of traffic shaping is codec restriction. The SBC
restricts the codec set negotiated in offer/answer [2] exchange
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.
Note SBCs can terminate media streams and SIP dialogs for a number of
different reasons (e.g., in a situation where the subscriber runs out
of credits or when a user agent loses radio coverage).
The current way of implementing traffic shaping has some SIP-
unfriendly aspects. The SBC needs to access and modify the session
descriptions (i.e., offers and answers) exchanged between the user
Hautakorpi, et al. Expires January 19, 2006 [Page 5]
Internet-Draft SIP-Unfriendly Functions July 2005
agents. Consequently, this approach does not work if user agents
encrypt or integrity-protect their message bodies end-to-end. User
agents do not have any way to distinguish the SBC actions from an
attack by a MitM (Man-in-the-Middle).
Furthermore, the SBC needs to understand the session description
protocol and all the 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, it is not
enough with upgrading the user agents; SBCs in the network need also
to be upgraded. This fact may slow down service innovation.
Additionally, the SBC may need to generate requests on its own (e.g.,
a BYE request to terminate a SIP dialog). This does not work when
end-to-end authentication is in use.
3.3 Fixing Capability Mismatches
SBCs fixing capability mismatches enable communications between user
agents with different capabilities. For example, user agents that
support different IP versions, different codecs, or that are in
different address realms.
SBCs fixing capability mismatches insert a media element in the media
path using the procedures described in Section 3.2. Therefore, these
SBCs have the same problems as SBCs performing traffic shaping: the
SBC modifies SIP messages without explicit consent from any of the
user agents. This breaks end-to-end security and extension
negotiation.
Additionally, SBCs may make wrong assumptions about the capabilities
of the user agents. When this happens, user agents with compatible
capabilities may end up communicating via the SBC instead of doing it
directly between them (e.g., the SBC assumes that a dual-stack user
agent only supports IPv6).
3.4 NAT Traversal
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. 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.
Hautakorpi, et al. Expires January 19, 2006 [Page 6]
Internet-Draft SIP-Unfriendly Functions July 2005
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.
Operators implement this functionality in an SBC instead of in the
registrar because the SBC is supposed to have more information about
the access the user agent is using. Additionally, distributing this
functionality helps offload the registrar.
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.
4. Security Considerations
Many of the functions this document describes have important security
and privacy implications. If the IETF decides to develop standard
mechanisms to address those functions, security and privacy-related
aspects will need to be taken into consideration.
5. IANA Considerations
This document has no IANA considerations.
6. Acknowledgements
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. Special thanks goes also to Sridhar Ramachandran, Gaurav
Kulshreshtha, and to Rakendu Devdhar.
7. References
7.1 Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[2] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
Hautakorpi, et al. Expires January 19, 2006 [Page 7]
Internet-Draft SIP-Unfriendly Functions July 2005
7.2 Informational References
Authors' Addresses
Jani Hautakorpi (editor)
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: Jani.Hautakorpi@ericsson.com
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: Gonzalo.Camarillo@ericsson.com
Medhavi Bhatia
NexTone Communications
101 Orchard Ridge Drive
Gaithersburg, MD 20878
US
Email: mbhatia@nextone.com
Robert F. Penfield
Acme Packet
71 Third Avenue
Burlington, MA 01803
US
Email: bpenfield@acmepacket.com
Hautakorpi, et al. Expires January 19, 2006 [Page 8]
Internet-Draft SIP-Unfriendly Functions July 2005
Alan Hawrylyshen
Ditech Communications Corporation
310, 602 - 11 Ave SW
Calgary, Alberta T2R 1J8
Canada
Email: alan@jasomi.com
Hautakorpi, et al. Expires January 19, 2006 [Page 9]
Internet-Draft SIP-Unfriendly Functions July 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
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 (2005). 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
Funding for the RFC Editor function is currently provided by the
Internet Society.
Hautakorpi, et al. Expires January 19, 2006 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-23 15:17:17 |