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]