Internet DRAFT - draft-bhatia-sipping-sbc
draft-bhatia-sipping-sbc
SIPPING M. Bhatia
Internet-Draft S. Ramachandran
Expires: August 1, 2005 G. Kulshreshtha
R. Devdhar
NexTone Communications
January 28, 2005
SIP Session Border Control Requirements
draft-bhatia-sipping-sbc-00
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 1, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Typical policy implemented at network border deals with security and
enforcement of service level agreements at the network level. For
multimedia sessions, such policy can be applied not only at higher
layers but can be provided in a more granular and extended fashion.
Bhatia, et al. Expires August 1, 2005 [Page 1]
Internet-Draft SIP SBC January 2005
A Session Border Control (SBC) entity is a network intermediary
located at the administrative boundary of the network for policy
enforcement on multimedia sessions. The focus of this document is
the SIP specific requirements for SBCs. This document does not
specify any architectural requirments for SBCs. Architectures such
as specified in [1] may be used.
Bhatia, et al. Expires August 1, 2005 [Page 2]
Internet-Draft SIP SBC January 2005
1. Introduction
A Session Border Control (SBC) entity is a network intermediary which
is located at the administrative boundary of a network for enforcing
policy on multimedia sessions. Session policy may be defined to
manage security, service level agreements, network device resources,
network bandwidth, interworking and protocol interoperability between
networks. Typical border elements for policy enforcement include
Network Address Translators (NATs), firewalls and routers. NATs
provide only network policy enforcement. Application Layer Gateways
(ALGs) may be combined with such border elements to provide some
degree of policy control. The difference between an SBC and an ALG
is that the former is visible to peer servers or hosts and terminates
as well as originates session legs for an end to end session very
much like a SIP proxy. An SBC entity also provides advanced
functions not provided by an ALG combined with a NAT, firewall or
router e.g. interoperability, management of network resources and
bandwidth.
The policy enforced on a network border usually depends on a lot of
things. For example, if administrative control is different in two
peering networks, chances are that security policy will be enforced
at the border. If traffic sources are varied, interoperability is a
likely candidate. A border may simply involve different QoS
mechanisms on either side which means that service level agreements
and traffic management will be important.
Bhatia, et al. Expires August 1, 2005 [Page 3]
Internet-Draft SIP SBC January 2005
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in [15] and indicate requirement levels for compliant
implementations.
Bhatia, et al. Expires August 1, 2005 [Page 4]
Internet-Draft SIP SBC January 2005
3. Definitions
The term SBC in this document is assumed to mean a SIP SBC and the
term SBC policy refers to policy configured on the SBC. Also, the
terms SBC and SBC Entity are used interchangeably in this document.
An SBC Network is a network on which the SBC Policy applies (similar
to "internal network" in the case of NATs). An External Network is a
network to which the SBC is connected but does not apply the SBC
Policy. In general, an SBC may be connected to multiple SBC Networks
and External Networks. A single network may also function as the SBC
Network for multiple SBCs. For simplicity, in this document we will
assume that an SBC is connected to a single SBC Network and an
External Network. The general many-to-may architectures can be
derived from this simpler model.
Bhatia, et al. Expires August 1, 2005 [Page 5]
Internet-Draft SIP SBC January 2005
4. Applications
It is worthwhile to summarize the some of the deployment scenarios
leading to the requirements in this document. One of the common
scenarios is termed "voip peering" in the industry. In the VoIP
peering model, SBCs act as the interconnecting devices between two
VoIP providers. Each provider uses an SBC to connect to multiple
peer networks. The provider network in this case is an example of an
SBC Network. The peer network is the External Network for the
provider's SBC. Since each provider uses its own SBC, we get SBCs
interconnected to each other on the peer links. Another scenario is
a broadband service provider who uses an SBC to enforce policy in its
core network. Edge networks may be directly connected to the
provider's SBC in this case. These edge networks are the External
Networks while the provider network is the SBC Network.
Bhatia, et al. Expires August 1, 2005 [Page 6]
Internet-Draft SIP SBC January 2005
5. Session Border Control Requirements
5.1 Security of the SBC Network
Security is a typical border requirement when administrative control
changes. In this case, the SBC entity MUST provide security for the
SBC Network. We list the SIP specific requirements below.
5.1.1 Topology and IP address Hiding (THIG)
Topology Hiding (THIG) is achieved by hiding any topological
information in packets coming from the SBC Network. An SBC MUST
provide the THIG function when securing the SBC Network. In SIP,
topology information is present in SIP headers, like the Via and
Record Route headers.
The requirements for THIG on SIP sessions are as follows:
1. Via header list MUST be restricted for SIP Requests going to the
External Network
2. Record-Route Headers MUST be restricted for SIP Requests and
Responses going to the External Network.
3. Route Headers MUST be restricted for Requests going to the
External Network.
4. Service-Route [4] Headers MUST be restricted for SIP Responses
going to the External Network.
There are two methods to achieve topology hiding for SIP headers.
o Removing the header. For example, the Via header list may be
removed and a new one re-inserted.
o Using header encryption. In this approach, the SBC can perform
loop detection by decrypting the headers. Additionally, less
state information needs to be stored. For example, if there are
three Via headers for a request which is applicable for THIG, the
three headers are encrypted as encrypted-token@mydomain and
inserted as the second Via header (top being ours) with the
following extra parameter: tokenized-by=mydomain.
IP address hiding deals with obfuscating IP addresses of one network
from the other. For SIP sessions, this implies that IP addresses
present in signaling as well as media MUST be changed. We summarize
the requirements for SIP sessions below:
1. The SBC MAY need to inspect and change the message body for SIP
messages.
2. The SBC MUST act as an RTP translator when acting as an
intermediary for session media containing RTP [3].
Bhatia, et al. Expires August 1, 2005 [Page 7]
Internet-Draft SIP SBC January 2005
3. The SBC MAY need to modify SIP headers as long as they do not
have any affect on user identity as identified later in this
document e.g. Contact and From.
4. The SBC MUST support a NAT traversal mechanism when doing session
media level IP address hiding. [6]
5. The SBC MUST support [8]
5.1.2 Security and Encryption
Security and Encryption can be applied to session signaling as well
as media. An SBC must provide security and encryption mechanisms at
the signaling level and may provide them at the media level too. The
SBC provides a hop-by-hop security model wherever it provides
security for the session. End users in sessions may negotiate
end-to-end media encryption through the SBC using mechanisms such as
[10].
The requirements for SIP sessions are as follows:
1. The SBC MUST support a hop-by-hop security model at the SIP
session signaling level using protocols like TLS or IPSec.
2. Negotiations of these mechanisms MAY be supported using
mechanisms based on [9] in specific networks.
5.1.3 Privacy and Identity
If the SBC provides security policy for the SBC Network, it can also
provide privacy services [11] for other proxies in the SBC Network.
The SBC MUST be able to insert/delete/relay P-Asserted-Identity
headers in requests and responses as described in [11]. The network
of trust is assumed to be the SBC Network.
The SBC SHOULD also authenticate identity for session requests
targeted towards the SBC Network. However, since the SBC may modify
SIP headers and bodies as messages pass through, it may interfere
with mechanisms specified in [7] and [12]. Other SBC actions which
will affect identity are as follows:
o The CSeq header may not be relayed by an SBC from the UAC to the
UAS. If the AIB contains this header encrypted, then passing the
AIB to the UAS may not work as desired.
o The SBC may also generate unsolicited requests and it may be
desirable to insert a third party AIB in the message. It is
unclear how this will work and probably needs some extensions to
the mechanisms in [12].
Bhatia, et al. Expires August 1, 2005 [Page 8]
Internet-Draft SIP SBC January 2005
5.2 Management of Service Level Agreements
5.2.1 Call/Bandwidth Admission Control (CAC)
Call Admission Control can be achieved by tracking resource usage in
the SBC Network. Resources may be bandwidth, TCP/IP connections etc.
For SIP Sessions it MAY be necessaryfor the SBC to inspect SIP
bodies.
5.2.2 Traffic Management
Traffic management is a general term used to describe monitoring,
shaping, policing and segmentation of traffic. The SBC MAY provide
traffic management for the SBC Network. The general requirements for
SIP sessions are as follows:
1. The SBC MAY act as a QoS enabled proxy [13] for the SBC Network.
2. The SBC MAY also use preconditions [14] for QoS reservations in
the External Network.
3. The SBC MUST act as an RTP Translator [3] when it needs to mark
session media packets in the SBC Network
4. The SBC MAY need to inspect and change the message body for SIP
messages going towards the SBC Network.
5.3 Interworking and Protocol Harmonization
In case the traffic destined towards the SBC Network is coming from
more than one source and/or device from different vendors using
different protocols or protocol variations, some kind of
"harmonization" may be required. The SBC MAY provide this
harmonization. The requirements for SIP are as follows:
1. Addition of new headers in SIP requests and responses
2. Deletion of headers in SIP requests and responses
3. Manipulation of header parameters
4. Automatic response generation to SIP requests
5. New request generation (unsolicited), similar to UA behavior
5.4 Transcoding
A service provider may transcode session media coming towards the SBC
Network because of two reasons. First, the devices within the
network may have some capability limitations requiring this. Second,
transcoding may be required for controlling bandwidth according to
SLAs. The calling or the caller user agents may invoke transcoding
resources in their local networks or the transcoding service may be
provided by the SBC. The requirement for SIP in the latter scenario
is simply that the SBC MAY need to inspect and modify the SIP
Bhatia, et al. Expires August 1, 2005 [Page 9]
Internet-Draft SIP SBC January 2005
message body for requests and responses.
Bhatia, et al. Expires August 1, 2005 [Page 10]
Internet-Draft SIP SBC January 2005
6. SIP Classification of the SBC
[2] describes the following set of SIP Entities:
1. SIP Server
* Registrar
* Proxy Server
+ Call Stateful Proxy
+ Transaction Stateful Proxy
+ Stateless Proxy
2. User Agent Server (UAS)
3. User Agent Client (UAC)
4. User Agent (An entity which can simultaneously act as a UAC and
UAS)
5. Back-To-Back User Agent (An entity composed of the UAS and UAC
which acts as a UAC to determine how to answer an incoming
request on the UAS).
Depending on implementation, an SBC could be a SIP Stateful Proxy or
a SIP Back-To-Back User Agent.
7. References
[1] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R. and A.
Sastry, "The COPS (Common Open Policy Service) Protocol",
RFC 2748, January 2000.
[2] 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.
[3] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications",
RFC 3550, July 2003.
[4] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP)
Extension Header Field for Service Route Discovery During
Registration", RFC 3608, October 2003.
[5] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "Simple
Traversal of User Datagram Protocol (UDP) Through Network
Address Translators (NATs)", RFC 3489, March 2003.
[6] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
Methodology for Network Address Translator (NAT) Traversal for
Multimedia Session Establishment Protocols",
I-D draft-ietf-mmusic-ice-03, October 2005.
Bhatia, et al. Expires August 1, 2005 [Page 11]
Internet-Draft SIP SBC January 2005
[7] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
I-D draft-ietf-sip-identity-03, September 2004.
[8] Rosenberg, J. and H. Schulzrinne, "An Extension to the Session
Initiation Protocol (SIP) for Symmetric Response Routing",
RFC 3581, August 2003.
[9] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A. and T.
Haukka, "Security Mechanism Agreement for the Session
Initiation Protocol (SIP)", RFC 3329, January 2003 .
[10] Baugher, M., McGrew, D., Naslund, M., Carrara, E. and Norrman,
K., "The Secure Real-time Transport Protocol (SRTP)", RFC 3711,
March 2004.
[11] Jennings, C., Peterson, J. and M. Watson, "Private Extensions
to the Session Initiation Protocol (SIP) for Asserted Identity
within Trusted Networks", RFC 3325, November 2002.
[12] Peterson, J., "Session Initiation Protocol (SIP) Authenticated
Identity Body (AIB) Format", RFC 3893, September 2004.
[13] Marshall, W., "Private Session Initiation Protocol (SIP)
Extensions for Media Authorization", RFC 3313, January 2003.
[14] Camarillo, G., Marshall, W. and J. Rosenberg, "Integration of
Resource Management and Session Initiation Protocol (SIP)",
RFC 3312, October 2002.
[15] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
Authors' Addresses
Medhavi Bhatia
NexTone Communications
101 Orchard Ridge Drive
Gaithersburg, MD 20878
US
Phone: +1 240 912 1300
Email: mbhatia@nextone.com
URI: http://www.nextone.com/
Bhatia, et al. Expires August 1, 2005 [Page 12]
Internet-Draft SIP SBC January 2005
Sridhar Ramachandran
NexTone Communications
101 Orchard Ridge Drive
Gaithersburg, MD 20878
US
Phone: +1 240 912 1300
Email: sridhar@nextone.com
URI: http://www.nextone.com/
Gaurav Kulshreshtha
NexTone Communications
101 Orchard Ridge Drive
Gaithersburg, MD 20878
US
Phone: +1 240 912 1300
Email: gkul@nextone.com
URI: http://www.nextone.com/
Rakendu Devdhar
NexTone Communications
101 Orchard Ridge Drive
Gaithersburg, MD 20878
US
Phone: +1 240 912 1300
Email: rdevdhar@nextone.com
URI: http://www.nextone.com/
Bhatia, et al. Expires August 1, 2005 [Page 13]
Internet-Draft SIP SBC January 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.
Bhatia, et al. Expires August 1, 2005 [Page 14]
