SIPPING Working Group J. Hautakorpi, Ed. Internet-Draft G. Camarillo Expires: January 19, 2006 Ericsson M. Bhatia NexTone Communications R. Penfield Acme Packet A. Hawrylyshen Ditech Communications Corporation July 18, 2005 SIP (Session Initiation Protocol)-Unfriendly Functions in Current Communication Architectures draft-camarillo-sipping-sbc-funcs-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 19, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document gives an overview to SIP-unfriendly functions in Hautakorpi, et al. Expires January 19, 2006 [Page 1] Internet-Draft SIP-Unfriendly Functions July 2005 current communication architectures. These functions are generally implemented in SBCs (Session Border Controllers). The purpose of this document is to help the IETF community understand what SIP- unfriendly functions can be found in existing networks so that the appropriate working groups can decide whether or not new standard solutions need to be developed to provide such functionality (or a subset of it) in a standard, SIP-friendly way. Working groups may also develop recommendations on how to use existing standard mechanisms to provide such functionality. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background on SBCs . . . . . . . . . . . . . . . . . . . . . . 3 3. SIP-Unfriendly Functions . . . . . . . . . . . . . . . . . . . 4 3.1 Topology Hiding . . . . . . . . . . . . . . . . . . . . . 4 3.2 Media Traffic Shaping . . . . . . . . . . . . . . . . . . 5 3.3 Fixing Capability Mismatches . . . . . . . . . . . . . . . 6 3.4 NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1 Normative References . . . . . . . . . . . . . . . . . . . 7 7.2 Informational References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . 10 Hautakorpi, et al. Expires January 19, 2006 [Page 2] Internet-Draft SIP-Unfriendly Functions July 2005 1. Introduction This document gives an overview to SIP [1] unfriendly functions in current communication architectures. These functions are generally implemented in Session Border Controllers (SBCs). The reason for this is that network policies are typically enforced at the edge of the network, and SBCs are typically located there. Of course, a typical SBC does not only implement SIP-unfriendly functions. They usually implement a set of functions, some of which are perfectly legal from the SIP point of view. However, this document focuses on those functions that break SIP somehow. Many existing SBCs use proprietary solutions because there is no standard solution for a given issue or because the standard solution does not fully meet the requirements of the network operator. This document is intended to be taken as input by the IETF so that the appropriate working groups can decide whether or not new standard solutions need to be developed to provide the same functionality (or a subset of it) in a SIP-friendly way. Working groups may also decide to develop recommendations on how to use existing standard mechanisms to provide such functionality. 2. Background on SBCs The term SBC is pretty vague, since it is not standardized or defined anywhere. Nodes that may be referred to as SBCs but do not implement SIP are outside the scope of this document. Even though many SBCs currently break things like end-to-end security and can impact feature negotiations, there is clearly a market for them. Network operators need many of the features current SBCs provide and many times there are no standard mechanisms available to provide them in a better way. SIP-based SBCs typically handle both signaling and media, and often modify the session descriptions contained in SIP messages. Consequently, they are, by definition, B2BUAs (Back-to-Back User Agents). The transparency of these B2BUAs varies depending on the functions they perform. For example, some SBCs modify the session description carried in the message and insert a Record-Route entry. Other SBCs replace the value of the Contact header field with the SBCs address, and generate a new Call-ID and new To and From tags. Hautakorpi, et al. Expires January 19, 2006 [Page 3] Internet-Draft SIP-Unfriendly Functions July 2005 +-----------------+ | SBC | [signaling] | +-----------+ | <------------|->| signaling |<-|----------> outer | +-----------+ | inner network | | | network | +-----------+ | <------------|->| media |<-|----------> [media] | +-----------+ | +-----------------+ Figure 1: SBC architecture Figure 1 shows the logical architecture of an SBC, which includes a signaling and a media component. Typically SBCs are located between two networks. In this document, the terms outer and inner network are used for describing these two networks. There are two typical deployment scenarios where SBCs are used. The first one of them is a peering scenario, where the SBC is located between different-operators' networks. The second deployment scenario is an access scenario, where the SBC is located between the access network and the operator's network. 3. SIP-Unfriendly Functions This section examines SIP-unfriendly functions that are used in current communication networks. Each subsection describes a particular function or feature, what is the operator's motivation for having it, how it is currently implemented, and why it breaks SIP. Each section also discusses the problems associated to that particular way of implementing it. Providing suggestions for alternative, more SIP-friendly ways of implementing each of the functions is outside the scope of this document. 3.1 Topology Hiding Topology hiding consists of limiting the amount of topology information given to external parties. Operators want to have this functionality because they do not want the IP addresses of their equipment (proxies, gateways, application servers, etc) to be exposed to outside parties. This may be because they do not want to expose their equipment to DoS (Denial of Service) attacks or because they may use other carriers for certain traffic and do not want their customers to be aware of it. In some environments, the operator's customers may wish to hide the addresses of their equipment or the SIP messages may contain private, non-routable addresses. Hautakorpi, et al. Expires January 19, 2006 [Page 4] Internet-Draft SIP-Unfriendly Functions July 2005 The current way of implementing topology consists of having an SBC act as a B2BUA (Back-to-Back User Agents) and remove all traces of topology information (e.g., Via and Record-Route entries) from outgoing messages. Like a regular proxy server that inserts a Record-Route entry, the SBC handles every single message of a given SIP dialog. However, unlike the proxy server, if the SBC loses state (e.g., the SBC restarts for some reason), it will not be able to route messages properly. For example, if the SBC removes Via entries from a request and then restarts losing state, the SBC will not be able to route responses to that request. 3.2 Media Traffic Shaping Media traffic shaping is the act of controlling media traffic. Operators have several reasons for having this functionality. Operators want to control the traffic they carry on their network. Traffic shaping helps them create different kinds of billing models (e.g., video telephony can be priced differently than voice-only calls). Additionally, traffic shaping can be used to implement intercept capabilities (e.g., lawful intercept). Some operators do not actually want to reshape the traffic, but only to monitor it. However, the SIP techniques needed for monitoring media traffic are the same as for reshaping media traffic. Currently, traffic shaping is performed in the following way. The SBC behaves as a B2BUA and inserts itself, or some other entity under the operator's control, in the media path. In practice, the SBC modifies the session descriptions carried in the SIP messages. As a result, the SBC receives media from one user agent and relays it to the other in both directions. An example of traffic shaping is codec restriction. The SBC restricts the codec set negotiated in offer/answer [2] exchange between the user agents. After modifying the session descriptions, the SBC can check whether or not the media stream corresponds to what was negotiated in the offer/answer exchange. If it differs, the SBC has the ability to terminate the media stream. Note SBCs can terminate media streams and SIP dialogs for a number of different reasons (e.g., in a situation where the subscriber runs out of credits or when a user agent loses radio coverage). The current way of implementing traffic shaping has some SIP- unfriendly aspects. The SBC needs to access and modify the session descriptions (i.e., offers and answers) exchanged between the user Hautakorpi, et al. Expires January 19, 2006 [Page 5] Internet-Draft SIP-Unfriendly Functions July 2005 agents. Consequently, this approach does not work if user agents encrypt or integrity-protect their message bodies end-to-end. User agents do not have any way to distinguish the SBC actions from an attack by a MitM (Man-in-the-Middle). Furthermore, the SBC needs to understand the session description protocol and all the extensions used by the user agents. This means that in order to use a new extension (e.g., an extension to implement a new service) or a new session description protocol, it is not enough with upgrading the user agents; SBCs in the network need also to be upgraded. This fact may slow down service innovation. Additionally, the SBC may need to generate requests on its own (e.g., a BYE request to terminate a SIP dialog). This does not work when end-to-end authentication is in use. 3.3 Fixing Capability Mismatches SBCs fixing capability mismatches enable communications between user agents with different capabilities. For example, user agents that support different IP versions, different codecs, or that are in different address realms. SBCs fixing capability mismatches insert a media element in the media path using the procedures described in Section 3.2. Therefore, these SBCs have the same problems as SBCs performing traffic shaping: the SBC modifies SIP messages without explicit consent from any of the user agents. This breaks end-to-end security and extension negotiation. Additionally, SBCs may make wrong assumptions about the capabilities of the user agents. When this happens, user agents with compatible capabilities may end up communicating via the SBC instead of doing it directly between them (e.g., the SBC assumes that a dual-stack user agent only supports IPv6). 3.4 NAT Traversal An SBC performing a NAT (Network Address Translator) traversal function for a user agent behind a NAT sits between the user agent and the registrar of the domain. When the registrar receives a REGISTER request from the user agent and responds with a 200 (OK) response, the SBC modifies such a response decreasing the validity of the registration (i.e., the registration expires sooner). This forces the user agent to send a new REGISTER to refresh the registration sooner that it would have done on receiving the original response from the registrar. The REGISTER requests sent by the user agent refresh the binding of the NAT before the binding expires. Hautakorpi, et al. Expires January 19, 2006 [Page 6] Internet-Draft SIP-Unfriendly Functions July 2005 Note that the SBC does not need to relay all the REGISTER requests received from the user agent to the registrar. The SBC can generate responses to REGISTER requests received before the registration is about to expire at the registrar. Moreover, the SBC needs to deregister the user agent if this fails to refresh its registration in time, even if the registration at the registrar would still be valid. Operators implement this functionality in an SBC instead of in the registrar because the SBC is supposed to have more information about the access the user agent is using. Additionally, distributing this functionality helps offload the registrar. This approach to NAT traversal does not work when end-to-end confidentiality or integrity-protection is used. The SBC would be seen as a MitM modifying the messages between the user agent and the registrar. 4. Security Considerations Many of the functions this document describes have important security and privacy implications. If the IETF decides to develop standard mechanisms to address those functions, security and privacy-related aspects will need to be taken into consideration. 5. IANA Considerations This document has no IANA considerations. 6. Acknowledgements The ad-hoc meeting about SBCs, held on Nov 9th 2004 at Washington DC during the 61st IETF meeting, provided valuable input to this document. Special thanks goes also to Sridhar Ramachandran, Gaurav Kulshreshtha, and to Rakendu Devdhar. 7. References 7.1 Normative References [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [2] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. Hautakorpi, et al. Expires January 19, 2006 [Page 7] Internet-Draft SIP-Unfriendly Functions July 2005 7.2 Informational References Authors' Addresses Jani Hautakorpi (editor) Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: Jani.Hautakorpi@ericsson.com Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: Gonzalo.Camarillo@ericsson.com Medhavi Bhatia NexTone Communications 101 Orchard Ridge Drive Gaithersburg, MD 20878 US Email: mbhatia@nextone.com Robert F. Penfield Acme Packet 71 Third Avenue Burlington, MA 01803 US Email: bpenfield@acmepacket.com Hautakorpi, et al. Expires January 19, 2006 [Page 8] Internet-Draft SIP-Unfriendly Functions July 2005 Alan Hawrylyshen Ditech Communications Corporation 310, 602 - 11 Ave SW Calgary, Alberta T2R 1J8 Canada Email: alan@jasomi.com Hautakorpi, et al. Expires January 19, 2006 [Page 9] Internet-Draft SIP-Unfriendly Functions July 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Hautakorpi, et al. Expires January 19, 2006 [Page 10]