[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 draft-ietf-sipping-sbc-funcs

SIPPING Working Group                                 J. Hautakorpi, Ed.
Internet-Draft                                              G. Camarillo
Expires: March 30, 2006                                         Ericsson
                                                               M. Bhatia
                                                  NexTone Communications
                                                             R. Penfield
                                                             Acme Packet
                                                          A. Hawrylyshen
                                       Ditech Communications Corporation
                                                      September 26, 2005


   SIP (Session Initiation Protocol)-Unfriendly Functions in Current
                      Communication Architectures
                draft-camarillo-sipping-sbc-funcs-02.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 March 30, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document gives an overview to SIP-unfriendly functions in



Hautakorpi, et al.       Expires March 30, 2006                 [Page 1]


Internet-Draft          SIP-Unfriendly Functions          September 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.  An additional goal of this
   document is to describe how implementing certain functions in certain
   ways breaks SIP and the disadvantages derived from doing so.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Background on SBCs . . . . . . . . . . . . . . . . . . . . . .  3
   3.  SIP-Unfriendly Functions . . . . . . . . . . . . . . . . . . .  4
     3.1.  Topology Hiding  . . . . . . . . . . . . . . . . . . . . .  4
       3.1.1.  General Information  . . . . . . . . . . . . . . . . .  4
       3.1.2.  SIP-Unfriendly Aspect  . . . . . . . . . . . . . . . .  5
       3.1.3.  Concrete Example . . . . . . . . . . . . . . . . . . .  5
     3.2.  Media Traffic Shaping  . . . . . . . . . . . . . . . . . .  6
       3.2.1.  General Information  . . . . . . . . . . . . . . . . .  6
       3.2.2.  SIP-Unfriendly Aspect  . . . . . . . . . . . . . . . .  6
       3.2.3.  Concrete Example . . . . . . . . . . . . . . . . . . .  6
     3.3.  Fixing Capability Mismatches . . . . . . . . . . . . . . .  7
       3.3.1.  General Information  . . . . . . . . . . . . . . . . .  7
       3.3.2.  SIP-Unfriendly Aspect  . . . . . . . . . . . . . . . .  8
       3.3.3.  Concrete Example . . . . . . . . . . . . . . . . . . .  8
     3.4.  NAT Traversal  . . . . . . . . . . . . . . . . . . . . . .  9
       3.4.1.  General Information  . . . . . . . . . . . . . . . . .  9
       3.4.2.  SIP-Unfriendly Aspect  . . . . . . . . . . . . . . . .  9
       3.4.3.  Concrete Example . . . . . . . . . . . . . . . . . . . 10
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     7.2.  Informational References . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
   Intellectual Property and Copyright Statements . . . . . . . . . . 13









Hautakorpi, et al.       Expires March 30, 2006                 [Page 2]


Internet-Draft          SIP-Unfriendly Functions          September 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 March 30, 2006                 [Page 3]


Internet-Draft          SIP-Unfriendly Functions          September 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, explanation on why it breaks SIP, and a concrete example
   from its implementation.  Each section also discusses problems
   specific 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.

   All the examples given in this section are somewhat simplified
   situations from the reality.  Only the relevant header lines from SIP
   and SDP [3] messages are displayed.

3.1.  Topology Hiding

3.1.1.  General Information

   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



Hautakorpi, et al.       Expires March 30, 2006                 [Page 4]


Internet-Draft          SIP-Unfriendly Functions          September 2005


   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.

3.1.2.  SIP-Unfriendly Aspect

   This functionality is SIP-unfriendly, because it breaks end-to-end
   connectivity and modifies the SIP messages without user's explicit
   consent.  User does not have any way of knowing whether the SIP
   messages are modified by the SBC, or is someone performing MitM (Man-
   in-the-Middle) attack.

3.1.3.  Concrete Example

   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., Record-Route and Vie 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.

   Let us imagine the following example scenario: The SBC
   (p4.domain.com) is receiving an INVITE request from the inner
   network, which in this case is an operator network.  The received SIP
   message is:


     INVITE sip:callee@u2.domain.com SIP/2.0
     Contact: sip:caller@u1.example.com
     Record-Route: <sip:p3.middle.com>
     Record-Route: <sip:p2.example.com;lr>
     Record-Route: <sip:p1.example.com;lr>

   Then the SBC performs a topology hiding function.  In this imagined
   situation the SBC removes and stores all existing Record-Route
   headers, and then insert a Record-Route header field with its own
   SIP-URI.  After the topology hiding function, the message looks like:





Hautakorpi, et al.       Expires March 30, 2006                 [Page 5]


Internet-Draft          SIP-Unfriendly Functions          September 2005


     INVITE sip:callee@u2.domain.com SIP/2.0
     Contact: sip:caller@u1.example.com
     Record-Route: <sip:p4.domain.com;lr>

   This is only one example scenario from topology hiding, and SBCs can,
   in some cases, modify also other headers.

3.2.  Media Traffic Shaping

3.2.1.  General Information

   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.

   One possible form of media traffic shaping is that SBCs terminate
   media streams and SIP dialogs by generating BYE requests.  This kind
   of procedure can take place e.g., in a situation where subscriber
   runs out of credits.

3.2.2.  SIP-Unfriendly Aspect

   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
   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).

3.2.3.  Concrete Example

   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



Hautakorpi, et al.       Expires March 30, 2006                 [Page 6]


Internet-Draft          SIP-Unfriendly Functions          September 2005


   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.

   Let us imagine the following example scenario: The SBC is receiving
   an INVITE request from the outer network, which in this case is an
   access network.  The received SIP message contains the following SDP
   session descriptor:


     v=0
     o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
     c=IN IP4 126.16.64.4
     m=audio 49230 RTP/AVP 96 98
     a=rtpmap:96 L8/8000
     a=rtpmap:98 L16/16000/2

   Then the SBC performs a media traffic shaping function.  In this
   imagined situation the SBC rewrites the 'm' line, and removes one 'a'
   line according to some policy.  After the traffic shaping function,
   the session descriptor looks like:


     v=0
     o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
     c=IN IP4 126.16.64.4
     m=audio 49230 RTP/AVP 96
     a=rtpmap:96 L8/8000

   One problem of media traffic shaping is that 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.

3.3.  Fixing Capability Mismatches

3.3.1.  General Information

   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.




Hautakorpi, et al.       Expires March 30, 2006                 [Page 7]


Internet-Draft          SIP-Unfriendly Functions          September 2005


3.3.2.  SIP-Unfriendly Aspect

   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.3.3.  Concrete Example

   Let us imagine the following example scenario: The SBC is receiving
   an INVITE request from the inner network, which in this case is an
   access network using IPv4.  The received SIP message and session
   descriptor is the following:


     INVITE sip:callee@ipv6.domain.com SIP/2.0
     Via: SIP/2.0/UDP 126.16.64.4
     Contact: sip:caller@u1.example.com

     v=0
     o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
     c=IN IP4 126.16.64.4
     m=audio 49230 RTP/AVP 96
     a=rtpmap:96 L8/8000

   Then the SBC performs a capability mismatch fixing function.  In this
   imagined situation the SBC inserts Record-Route and Via headers, and
   rewrites the 'c' line from the sessions descriptor.  After the
   capability mismatch fixing function, the message look like:














Hautakorpi, et al.       Expires March 30, 2006                 [Page 8]


Internet-Draft          SIP-Unfriendly Functions          September 2005


     INVITE sip:callee@ipv6.domain.com SIP/2.0
     Record-Route: <sip:[2001:620:8:801:201:2ff:fe94:8e10];lr>
     Via: <sip:[2001:620:8:801:201:2ff:fe94:8e10];lr>
     Via: SIP/2.0/UDP 126.16.64.4
     Contact: sip:caller@u1.example.com

     v=0
     o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
     c=IN IP6 2001:620:8:801:201:2ff:fe94:8e10
     m=audio 49230 RTP/AVP 96
     a=rtpmap:96 L8/8000

   Now the SBC sends the modified message to the outer network, which
   uses IPv6.

3.4.  NAT Traversal

3.4.1.  General Information

   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.

   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.

3.4.2.  SIP-Unfriendly Aspect

   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



Hautakorpi, et al.       Expires March 30, 2006                 [Page 9]


Internet-Draft          SIP-Unfriendly Functions          September 2005


   registrar.

3.4.3.  Concrete Example

   Let us imagine the following example scenario: The SBC resides
   between the UA and Registrar.  Previously the UA has sent a REGISTER
   request to Registrar, and then the SBC is going to relay the
   following SIP message to UA:


     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

   Then the SBC performs a traversal function.  In this imagined
   situation the SBC rewrites the 'expires' parameter on the Contact
   header field.  After the NAT traversal function, the message look
   like:


     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

   Naturally also other measures needs to be taken in order to enable
   the NAT traversal, but this example illustrated only the mechanism on
   how NAT bindings can be kept alive.


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




Hautakorpi, et al.       Expires March 30, 2006                [Page 10]


Internet-Draft          SIP-Unfriendly Functions          September 2005


   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.

7.2.  Informational References

   [3]  Handley, M. and V. Jacobson, "SDP: Session Description
        Protocol", RFC 2327, April 1998.






























Hautakorpi, et al.       Expires March 30, 2006                [Page 11]


Internet-Draft          SIP-Unfriendly Functions          September 2005


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


   Alan Hawrylyshen
   Ditech Communications Corporation
   310, 602 - 11 Ave SW
   Calgary, Alberta  T2R 1J8
   Canada

   Email: alan@jasomi.com






Hautakorpi, et al.       Expires March 30, 2006                [Page 12]


Internet-Draft          SIP-Unfriendly Functions          September 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 March 30, 2006                [Page 13]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/