One document matched: draft-camarillo-sipping-sbc-funcs-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 01:45:57 |