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

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

SIPPING Working Group                                       G. Camarillo
Internet-Draft                                             J. Hautakorpi
Expires: August 15, 2005                                        Ericsson
                                                             R. Penfield
                                                             Acme Packet
                                                          A. Hawrylyshen
                                                         Jasomi Networks
                                                       February 14, 2005


       Functionality of Existing Session Border Controller (SBC)
                draft-camarillo-sipping-sbc-funcs-00.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  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 become aware will be disclosed, in accordance with
   RFC 3668.

   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 August 15, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document gives an overview to Session Border Controllers (SBCs)
   and to the functions they perform.  The way how SBCs relate to the
   telecommunication architectures is also presented.  The purpose of



Camarillo, et al.       Expires August 15, 2005                 [Page 1]


Internet-Draft             SBCs Functionality              February 2005


   this document is to help the IETF community understand what
   functionality existing SBCs provide 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 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.  General Information  . . . . . . . . . . . . . . . . . . . . .  3
   3.  Functions of SBCs  . . . . . . . . . . . . . . . . . . . . . .  4
     3.1   Access Control . . . . . . . . . . . . . . . . . . . . . .  4
     3.2   Topology Hiding  . . . . . . . . . . . . . . . . . . . . .  5
     3.3   Traffic Monitoring and Shaping and QoS Marking . . . . . .  6
     3.4   Protocol Repair  . . . . . . . . . . . . . . . . . . . . .  7
     3.5   Protocol/Profile Interworking  . . . . . . . . . . . . . .  7
     3.6   IPv4/IPv6 Interworking . . . . . . . . . . . . . . . . . .  7
     3.7   Transport Protocol Interworking  . . . . . . . . . . . . .  8
     3.8   NAT Traversal  . . . . . . . . . . . . . . . . . . . . . .  8
     3.9   Media Encryption . . . . . . . . . . . . . . . . . . . . .  8
   4.  Typical Deployment Scenarios of SBC  . . . . . . . . . . . . .  9
     4.1   Peering Scenario . . . . . . . . . . . . . . . . . . . . .  9
     4.2   Access Scenario  . . . . . . . . . . . . . . . . . . . . . 10
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   7.  Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . . 11
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   8.1   Normative References . . . . . . . . . . . . . . . . . . . . 11
   8.2   Informational References . . . . . . . . . . . . . . . . . . 11
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
       Intellectual Property and Copyright Statements . . . . . . . . 13



















Camarillo, et al.       Expires August 15, 2005                 [Page 2]


Internet-Draft             SBCs Functionality              February 2005


1.  Introduction

   This document gives an overview to Session Border Controllers (SBCs)
   and to the functions they currently perform.  Many existing SBCs use
   proprietary solution because there is no standard solution for a
   given issue or because the standard solution does not fully meet the
   requirements of network administrators.  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 functionality (or a subset of it) of current and the
   future SBCs.  Working groups may also decide to develop
   recommendations on how to use existing standard mechanisms to provide
   such functionality.

   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., VOIP).  These functions include: a)
   perimeter defense (access control, topology hiding, DoS prevention,
   and detection); b) functionality not available in the endpoints (NAT
   traversal, protocol interworking or repair); and c) network
   management (traffic monitoring, shaping, and QoS).

2.  General Information

   SBCs are in many ways similar to NATs.  They both are placed between
   the two end users but are not under their control.  This can cause
   problems.  Arguably, the most severe impact is that application
   designers often need to take these breakages into account, and that
   in turn makes the application design process more complicated and
   expensive.

   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.

   Although some SBCs only handle signaling, most of them handle both
   signaling and media.  This type of SBC implements some type of
   communication between the components handling the signaling and the
   components handling the media flows.  This communication is internal
   from SBC's point of view.

   Since most SIP-based SBCs handle both signaling and media, and they
   often must modify SDP contained in SIP messages, they are by
   definition B2BUAs.  SBCs have been implemented as B2BUAs in order to



Camarillo, et al.       Expires August 15, 2005                 [Page 3]


Internet-Draft             SBCs Functionality              February 2005


   comply with existing SIP standards.  The transparency of SBC B2BUAs
   can vary based on the functions it performs.  The most transparent
   SBCs simply update the SDP and insert a Record-Route header.
   However, SBCs which have more stringent requirements (like topology
   hiding), will replace the Contact with the SBCs address, and may
   generate a new Call-ID and even create new tags in the From and To
   headers.

                            +-----------------+
                            |       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.  Generally, SBCs are located between
   two networks.  In this document, the terms outer and inner network
   are used for describing these two networks.  In the most typical
   case, signaling is based on SIP [1] messages, the media transport on
   RTP [2], and the internal communications on H.248.

   The internal and external network SBC model is trivially extended to
   cover a many to many deployment scenario, but is sufficient for
   discussing the main classes of deployments.

3.  Functions of SBCs

   This section contains functions and features implemented in existing
   SBCs.  Each section describes a particular function or feature, how
   it is currently implemented, and what is the operators motivation for
   having it.  Each section also discusses the problems associated to
   that particular way of implementing it.  Providing suggestions for
   alternative, architecturally better, ways of implementing each of the
   functions is outside the scope of this document.

3.1  Access Control

   The access control function makes it possible for operators to
   restrict and control who can get access to the inner network.  Access
   control can be based on, for example, IP addresses or SIP identities
   (if the signaling is based on SIP).



Camarillo, et al.       Expires August 15, 2005                 [Page 4]


Internet-Draft             SBCs Functionality              February 2005


   This function is 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.

   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 behaves as a proxy server.  Therefore, it
   does not break any SIP architectural principle.  If access control is
   applied to both the signaling and media, then the SBC behaves as a
   B2BUA.  A key part of media-layer access control is that only media
   for authorized sessions is allowed to pass through the SBC.  In any
   case, since the SBC needs to handle every single message, this
   function has a scalability implications.  In addition, the SBC is a
   single point of failure from the architectural point of view.
   Although, in practice, many current SBCs have redundant
   configuration, which prevents the loss of calls/sessions in the event
   of a failure.

   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.  Some SBCs
   can contact a policy server to determine whether sufficient bandwidth
   is available.

3.2  Topology Hiding

   By using the topology hiding function, operators can restrict the
   amount of information they give out to external parties about the
   structure of their networks.  To perform this function, the SBC
   behaves as a B2BUA (Back-to-Back User Agent) and removes all traces
   of topology information (e.g., Via and Record-Route entries) from
   outgoing messages.

   Since the SBC needs to handle every single message (i.e., it needs to
   rewrite Contact header or add Record-Route), this approach can have
   scalability implications.  Additionally, if the SBC loses state
   (e.g., non-redundant SBC restart for some reason), it will not be
   able to route messages properly.  In this approach, the SBC is a
   single point of failure from the architectural point of view.

   One of the reasons why many operators use topology hiding function is



Camarillo, et al.       Expires August 15, 2005                 [Page 5]


Internet-Draft             SBCs Functionality              February 2005


   that they do not want the IP addresses of any of their equipment
   (proxies, gateways, application server's, etc) to be exposed to
   outside parties.  This may be because they do not want to invite DoS
   attacks on there equipment, or they may use other carriers for
   certain traffic and do not want their customers to be aware that they
   use these other carriers.  In some environments, the operator's
   customer may wish to hide the addresses of their equipment, or the
   SIP messages may contain private, or non-routable addresses.

3.3  Traffic Monitoring and Shaping and QoS Marking

   Operators want to know the characteristics of media traffic is run in
   their network.  To perform traffic monitoring, the SBC behaves as a
   B2BUA and inserts itself, or some other entity that is under the
   operator's control, in the media path.  In practice, SBCs enforce
   this media path selection by modifying the SDP messages.  This media
   path enforcement is required in the situations, where the normal IP
   routing would not send the media through the operator's network.  The
   SBC receives media from one user agent and relays it to the other in
   both directions.  Note that some types of lawful interception include
   performing traffic monitoring.

   Monitoring of the traffic can be used for SLA auditing and compliance
   testing and aggregation of quality metrics for a particular network
   or peering pair.

   Besides monitoring the traffic, operators often want to shape it.
   One of the functions the SBC performs consists of checking whether or
   not the media stream corresponds with what was negotiated on the
   signaling channel.  If it differs, then the SBC has the ability to
   terminate the media stream.  Media stream can also be terminated for
   a number of other reasons, e.g., in a situation where the subscriber
   runs out of credits.  This media stream/session termination can be
   done by removing all session data from SBC and by sending BYE request
   to both directions.

   The SBC can also perform QoS (Quality of Service) marking (e.g.,
   DiffServ marking at the edge of the network).  The SBC inserts itself
   in the path on a same way as it does to perform traffic monitoring.

   SBCs may also be used to determine if a call should be admitted to a
   particular network, based on the current utilization and load on that
   network.  Since the SBC can refuse to setup a session, this very
   high-level control of network utilization can assist in avoiding
   scenarios where the additional load represented by the new sessions
   degrades the perceived quality, or actual QoS metrics for existing
   sessions.




Camarillo, et al.       Expires August 15, 2005                 [Page 6]


Internet-Draft             SBCs Functionality              February 2005


   As a variation on traffic shaping, an SBC may decide to restrict the
   CODEC set under negotiation to enforce administrative policy about
   CODEC usage.  This might be for bandwidth utilization reasons or to
   ensure monitoring or intercept capabilities.

   This approach has some problems.  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 their message bodies end-to-end.  Furthermore, this
   approach breaks end-to-end integrity protection because the user
   agents do not have any way to distinguish the SBC actions from a
   attack by a man-in-the-middle.

3.4  Protocol Repair

   SBC are also used to repair protocol messages generated by
   not-fully-standard clients.  This function affects mainly the
   signaling component of SBC.  In any case, it must be noted that the
   protocol repair function does not mean protocol conversion.

   The SBC repairing protocol messages behaves as a proxy server that is
   liberal in what it receives and strict in what it sends.  In
   principle, such an SBC does not break any architectural principle of
   SIP.

3.5  Protocol/Profile Interworking

   Some SBCs do conversion between signaling protocol.  Currently, the
   only implemented protocol conversion is done between the H.323 and
   SIP.  It is also possible to do interworking between different SIP
   profiles.  This kind of SIP profile interworking can be done e.g.,
   between the IMS network and internet.

   Protocol/profile interworking functions require quite a lot of
   processing resources, so they introduce scalability problems.  They
   also demand that session level state is kept in SBCs.

3.6  IPv4/IPv6 Interworking

   SBCs are used to perform IPv4/IPv6 conversions at the edges of
   networks.  This feature makes it possible to use different IP
   versions on the outer network (e.g., access network) and on the inner
   network.  The importance of this functionality is currently
   emphasized because networks are adopting IPv6 in an asynchronous
   fashion.

   SBCs performing IPv4/IPv6 conversions on the media path use the same
   techniques as SBCs performing traffic monitoring and shaping, and



Camarillo, et al.       Expires August 15, 2005                 [Page 7]


Internet-Draft             SBCs Functionality              February 2005


   therefore, have the same set of problems associated with them.

3.7  Transport Protocol Interworking

   SBCs are used to perform transport protocol conversions at
   administrative network boundaries.  This feature makes it possible to
   use less advanced implementations in a SIP services network where
   they might otherwise not interoperate as expected.  For example, an
   older gateway device may only support SIP over UDP, but core elements
   in the SIP network that communicate with the gateway do not support
   UDP.  Additional examples include a situation where it is desired to
   use TLS in the external network, but TCP in the internal network (for
   auditing and/or accountability requirements).

   SBCs that are acting solely in this capacity are compatible in
   principle with SIP's end-to-end architecture and should not introduce
   any incompatibilities.

3.8  NAT Traversal

   SBCs are used to perform NAT (Network Address Translator) traversal.
   This feature makes it possible to use different address realms on the
   outer network (e.g., access network) and on the inner network.  NAT
   traversal can be done to both the signaling and media traffic.  This
   function is desired by many operators, because, currently, the fixed
   access networks contain a large amount of NATs.

   SBCs performing NAT traversal on the media path use the same
   techniques as SBCs performing traffic monitoring and shaping, and
   therefore, have the same set of problems associated to them.

   Some of the current SBCs can detect, on some probability, the NAT
   devices by using different mechanisms.  After the NAT detection, the
   SBCs are starting the NAT traversal function.  There are two
   scenarios for NAT traversal.  One in which the SBC is the NAT, and
   one where the SBC supports the traversal of NATs in the access
   network.  In both cases, the SBC will act as a B2BUA and an RTP
   relay.  Many SBCs support what is known as "Hosted NAT Traversal"
   which allows endpoints behind NATs which do not support NAT traversal
   mechanisms such as STUN or ICE, to use the operator's VOIP network.

3.9  Media Encryption

   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.




Camarillo, et al.       Expires August 15, 2005                 [Page 8]


Internet-Draft             SBCs Functionality              February 2005


   SBCs performing media encryption use the same techniques as SBCs
   performing traffic monitoring and shaping, and therefore, have the
   same set of problems associated to them.  Additionally, if the
   encryption / decryption is performed for every session, this approach
   has scalability implications.

4.  Typical Deployment Scenarios of SBC

   SBCs are already in use on deployed networks.  This section describes
   the most typical ones from those scenarios, where SBCs are currently
   used.  It is good to keep in mind that also somewhat more complex
   scenarios exist, e.g., the ones where there are multiple SBCs in the
   path.

4.1  Peering Scenario

   A typical peering scenario involves two network operators who want to
   exchange traffic with each other.  If SBCs are not used, then the
   typical call flow is the following.  First the gateway in network A
   will send INVITE to the softswitch (proxy) in network B.  That proxy
   will send 3xx redirect message back to the originating gateway.  The
   3xx redirect message points out the appropriate gateway in network B.
   Now the originating gateway will send another INVITE to it.  As a
   summary, it can be said that the gateway in network A needs to send
   two INVITEs, and entities in network B does not have any kind of
   protection against security threats.

         Operator A           .                Operator B
                              .
                              .                2) INVITE
      +-----+                 .            /--------------->+-----+
      | SSA |                 .           / 3) 3xx (redir.) | SSB |
      +-----+                 .          /  /---------------+-----+
                              .         /  /
      +-----+  1) INVITE      +-----+--/  /                 +-----+
      |GW-A1|---------------->| SBC |<---/     4) INVITE    |GW-B1|
      +-----+                 +-----+---------------------->+-----+
                              .
      +-----+                 .                             +-----+
      |GW-A2|                 .                             |GW-B2|
      +-----+                 .                             +-----+

                       Figure 2: Peering with SBC

   Figure Figure 2 illustrates the same peering arrangement with a SBC.
   Operator B will use the SBC 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



Camarillo, et al.       Expires August 15, 2005                 [Page 9]


Internet-Draft             SBCs Functionality              February 2005


   network management by minimizing the number ACL 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 guarantees that only media from valid sessions
   will reach the gateway.

4.2  Access Scenario

   In an access scenario, presented in Figure 3, the SBC is placed at
   the border between the access network and the operator's backbone
   network to control access to the backbone network, protect its
   components (media servers, application servers, gateways, etc.) from
   unauthorized use and DoS attacks, and monitor the signaling and media
   traffic.  Also, as a part of access control, since the SBC is call
   stateful, it can 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
   backbone.

        Access Network             .    Operator Backbone
                                   .
      +-----+                      .
      | UA1 |<---------\           .
      +-----+           \          .
                         \         .
      +-----+             \------->+-----+       +-------+
      | UA2 |<-------------------->| SBC |<----->| proxy |<-- -
      +-----+                 /--->+-----+       +-------+
                             /     .
      +-----+   +-----+     /      .
      | UA3 +---+ NAT |<---/       .
      +-----+   +-----+            .

                   Figure 3: Access scenario with SBC

   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 VOIP traffic.  The proxy usually does authentication/
   authorization for registrations and outbound calls.  The SBC does
   modify the REGISTER request so that subsequent requests to the
   registered address-of-record is routed to the SBC.  This is done
   either with a Path header, or by modifying the Contact to point at
   the SBC.

   SBCs are also capable of dealing with the "lost BYE" issue in this
   kind of scenario, supposing that the they are on the media path.  If
   the endpoint dies in the middle of the session, then the SBC can
   detect that the media has stopped flowing and issue a BYE to the both



Camarillo, et al.       Expires August 15, 2005                [Page 10]


Internet-Draft             SBCs Functionality              February 2005


   sides to cleanup the state in the network.

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

6.  IANA Considerations

   This document has no IANA considerations.

7.  Acknowledges

   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.

8.  References

8.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]  Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
        "RTP: A Transport Protocol for Real-Time Applications", STD 64,
        RFC 3550, July 2003.

8.2  Informational References


Authors' Addresses

   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   EMail: Gonzalo.Camarillo@ericsson.com








Camarillo, et al.       Expires August 15, 2005                [Page 11]


Internet-Draft             SBCs Functionality              February 2005


   Jani Hautakorpi
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   EMail: Jani.Hautakorpi@ericsson.com


   Robert F. Penfield
   Acme Packet
   71 Third Avenue
   Burlington, MA  01803
   US

   EMail: bpenfield@acmepacket.com


   Alan Hawrylyshen
   Jasomi Networks
   310, 602 - 11 Ave SW
   Calgary, Alberta  T2R 1J8
   Canada

   Phone: +1.866.617.8647
   EMail: alan@jasomi.com

























Camarillo, et al.       Expires August 15, 2005                [Page 12]


Internet-Draft             SBCs Functionality              February 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.




Camarillo, et al.       Expires August 15, 2005                [Page 13]


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