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]