speermint B. Rosen Internet-Draft NeuStar Intended status: Standards Track November 13, 2006 Expires: May 17, 2007 Best Current Practices for Session Peering on the Internet by Carriers through Federationsr draft-rosen-speermint-peeringbcp-v1-00.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 May 17, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo defines a first version Best Current Practice for peering among a federation of voice or other multimedia service providers Rosen Expires May 17, 2007 [Page 1] Internet-Draft BCP for Peering Through Federations November 2006 Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Addressing and Routing . . . . . . . . . . . . . . . . . . 4 2.2. Connectivity . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Security (Accountability) . . . . . . . . . . . . . . . . 5 2.4. Quality . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.5. Protocol Mediation . . . . . . . . . . . . . . . . . . . . 6 2.6. Model . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Responsibilities of Federations . . . . . . . . . . . . . . . 6 3.1. Federation Static Policies . . . . . . . . . . . . . . . . 6 3.1.1. Membership . . . . . . . . . . . . . . . . . . . . . . 7 3.1.2. Identity . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.3. Media Exchange . . . . . . . . . . . . . . . . . . . . 7 3.1.4. Capacity Controls . . . . . . . . . . . . . . . . . . 7 3.1.5. Protocol Specification . . . . . . . . . . . . . . . . 7 3.1.6. CODEC choices . . . . . . . . . . . . . . . . . . . . 8 3.1.7. Billing . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Layer 3 interconnection . . . . . . . . . . . . . . . . . 8 3.3. Layer 5 interconnection . . . . . . . . . . . . . . . . . 8 3.4. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.5. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 9 3.6. Transcode . . . . . . . . . . . . . . . . . . . . . . . . 9 3.7. Capacity Controls . . . . . . . . . . . . . . . . . . . . 9 3.8. Protocol Mediation . . . . . . . . . . . . . . . . . . . . 9 4. Responsibilities of peers . . . . . . . . . . . . . . . . . . 9 4.1. Conformance to Policies . . . . . . . . . . . . . . . . . 9 4.2. Identity . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3. Transcode . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Normative References . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Rosen Expires May 17, 2007 [Page 2] Internet-Draft BCP for Peering Through Federations November 2006 1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. It is assumed that the reader is familiar with the terminology and acronyms defined in [RFC3261] 2. Overview The SIP standard [RFC3261] models much of its protocol operations on familiar Internet applications such as email and the web. For example, SIP clients contact remote domains by resolving SIP URIs which are, like email addresses, composed of a username and domain name portion. As is the case with email, a client need not have any pre-association with a remote domain in order to initiate a session with a user in that domain. The security of SIP is designed to counter the sorts of threats that arise on the Internet - threats based on eavesdropping, packet spoofing, impersonation of identity, and the like. Endpoints must assume responsibility for most of these security functions. Like email and the web, SIP assumes that the Internet end-to-end model applies: that is, that entities using SIP have unimpeded connectivity to one another. There are however operational models in which the assumptions of traditional Internet applications do not hold up. The end-to-end reachability of user agents is commonly obstructed by network-layer impediments like network address translators (NATs) or firewalls. Many SIP user agents, and SIP deployments, utilize telephone numbers rather than email-like SIP URIs, which introduces requirements for a new resolution process in the routing of requests. Some SIP service providers are also uncomfortable leaving the management of security to user agents, for a variety of reasons. To a voice service provider that leverages SIP in a commercial offering, these concerns are all basic issues of usability. Most SIP user agents today have dial pads, and users are accustomed to the use of telephone numbers of voice applications. Without a transparent and automatic NAT traversal function such as ICE (which in turn relies on STUN and TURN services), SIP calls on the public Internet may face serious problems establishing media paths. Users similarly cannot be burdened with understanding and supporting security functions. Solving these concerns also motivates voice service providers to establish formal peering relationships with one another. Peering Rosen Expires May 17, 2007 [Page 3] Internet-Draft BCP for Peering Through Federations November 2006 represents an agreement between parties to permit the exchange of traffic, generally in accordance with some pre-established policy. Without agreement between two VSP domains, for example, on how telephone numbers are resolved, it is impractical for users in different domains to call one another. Security, and in particular authorization, is perhaps the most fundamental reason for peering. The email model, while quite successful, has a very widespread problem with undesirable traffic (namely spam), and a comparable problem for SIP could be quite harmful to commercial offerings. Peering agreements would allow providers to trace accountable sources of undesired traffic and to make appropriate authorization decisions based on traffic sources. Peering at the session layer can occur on a bilateral basis or a multilateral basis, where the latter generally takes the form of a federation (typically in an "assisted" peering configuration). At lower layers of the Internet architecture, there are also various forms of bilateral and multilateral connections which are established between Internet service providers; the more service providers require interconnection, however, the less attractive bilateral connections become, if only because the cost of constructing physical links between networks becomes unwieldy. While it might seem that there is no similar difficulty with the establishment of bilateral peering at the session layer, there are a number of reasons why voice service providers might want to minimize the number of connections they establish to peer networks: for example, to reduce load on gateways (SBCs and IPSec gateways), or to simplify authorization or routing decisions by delegating that responsibility to network elements operated by the federation. Moreover, if there are media-based applications which need to be made available to the federation as a whole, a point of lower layer interconnection, such as a traditional layer 3 interexchange point, is an ideal place to stage them. Any such applications like transcoders and media relays would best be situated in a layer 3 point of interconnection. The following sections detail some of the functions that might be performed at a peering point and briefly explain how they benefit from being deployed in a federation environment. 2.1. Addressing and Routing Several forms of private directories are useful in a peering context. Aside from the widely-attested need to translate telephone numbers into an identifier that can be routed on the Internet (typically via ENUM or an ENUM-like mechanisms), there is a further need in a peering environment to manage points of egress and ingress on the Rosen Expires May 17, 2007 [Page 4] Internet-Draft BCP for Peering Through Federations November 2006 networks of peers. While this can take the form of a conventional DNS lookup, such a lookup could return IP addresses that are only routable within a peering point, thereby restricting their access to the federation. 2.2. Connectivity Most NAT traversal schemes, such as TURN, require the availability of a relay that is reachable by both parties in a call. A peering point is a natural place to stage such a relay precisely because its position in the network is unlikely to introduce additional latency in the media by lengthening the call path. 2.3. Security (Accountability) SIP can be used in constrained environments, effectively closed IP networks, where the threats that are quite plausible on the public Internet become very unlikely - especially environments that are based on traditional telephone networks. In those closed environments the use of the baseline SIP security mechanisms may seem very unattractive. Some form of transitive trust is typically viewed as sufficient in this sort of environment. The use of network-layer security gateways that connect individual networks to a closed peering point VLAN would be one example of how this might operate. Certain application-layer functions can assist with the establishment of transitive trust and the management of service provider authorization based on that trust. For example, mechanisms like RFC3325 or RFC4474, which provide assurance of the identity of the originator of a SIP request, can be performed by a SIP proxy server resident in the peering point. Note that especially when telephone number translations are centrally managed by the federation, providing identity functions for Caller-ID typical must also be managed by the federation. 2.4. Quality The use of protocols to establish quality of service across a traffic path in an IP network is quite controversial, especially when tied to a real-time application like voice over IP. Traffic engineering, management of quality across a particular link, is more common and generally less complex than resource reservation on a per-call basis. Moreover, the extremely large deployments of certain VoIP applications on the public Internet which lack any per-call resource reservation have created a great deal of skepticism about the need to incur any significant expense to assure quality. Layer 3 peering points are general points of optimal quality in the Rosen Expires May 17, 2007 [Page 5] Internet-Draft BCP for Peering Through Federations November 2006 network from a latency and bandwidth perspective, and accordingly they are likely to be the best place to stage any network-based mechanism which would help to assure call quality. 2.5. Protocol Mediation [[ unsure if we'd want to talk about different SIP "variants" and the normalization of SIP signaling, this is just a placeholder entry ]] 2.6. Model Directories NAT SIP +---+ +---+ +---+ +---+ 3325 | | | | | | | | +---+ +---+ +---+ +---+ 4474 | | | | | | | | Peering +--+------+------+------+--------- Point | Applications --- | Peered / \ | Network ---------| +--------+ //\ / // -+- // | // | / | Peered | Network | Peered Network 3. Responsibilities of Federations 3.1. Federation Static Policies Federations must establish explicit policies on at least the following matters. Such policies may be in in the form of a contract or other agreement between the federation and peers, a web page, or other prominant mechanism. In some cases, the federation MAY explicity permit or prohibit parts of the policy described to be a matter for bilateral agreements within the federation. In this version of the BCP, we provide no standardized way to express this form of policy. Rosen Expires May 17, 2007 [Page 6] Internet-Draft BCP for Peering Through Federations November 2006 3.1.1. Membership The Federation MUST specify who is allowed to peer at the federation, and how the peers are made known to one another. The policy MUST include a statement of whether indirect (i.e. transit) peers are permitted. 3.1.2. Identity The Federation MUST specify the requirements on peers to identify users. The Federation MAY permit [RFC3325] asserted identity. The Federation SHOULD permit [RFC4474] Identity. Federations supporting RFC4474 MUST specify the CA(s) permitted to issue certificates of the authentication service (which MAY be operated by the Federation). The Federation policy MUST specify the date maximum descrepancy period, The policy MUST specify what is permitted in the display name of the From: header, and what mechanisms peers must have to control such content. 3.1.3. Media Exchange The Federation MUST specify mechanisms for the interchange of media among the peers. This MUST include mechanisms for NAT traversal. 3.1.4. Capacity Controls The Federation MUST specify policy to control the traffic sent to and recieved by peers. The policy SHOULD include limits on the maximum number of active calls, maximum number of calls/messages per specified unit time and the aggregate media bandwidth. Specifications for both aggregate traffic to/from the federation as well as limits between two peers MAY be specified. The Federation MAY specify policy for individual ingress/egress elements as well as total traffic to/from a peer. Federations MAY permit peers to specify and/or form bilateral agreements on the limits. This version of the BCP does not specify mechanisms for dynamic discovery or modification of such policies. 3.1.5. Protocol Specification The Federation MUST specify details of the (SIP) signaling messages that peers must conform to. Such specification SHOULD include minimal extensions that MUST be supported, and what options MUST be supported, MUST NOT be supported or MAY be supported. This specification SHOULD include a description of the services that are expected to be supported across the Federation, and the signaling Rosen Expires May 17, 2007 [Page 7] Internet-Draft BCP for Peering Through Federations November 2006 associated with such services. 3.1.6. CODEC choices The federation defines a codec policy to which all peers must adhere which would include designation of one or more mandatory to deploy codec and/or local transcode capability for each supported media type (audio, video, text) so that all calls can successfully complete offer/answer exchange. Consideration should be given in specifying mandatory-to-deploy codecs to include at least one that has minimal degradation of signal fidelity when two transcodes are required to achieve actual end to end compatibility. 3.1.7. Billing The Federation MUST specify what charging mechanisms for the exchange of traffic it permits, and any support for such practices (e.g. CDR production) it provides. Where the Federation provides explicit billing arrangements, such arrangements must be described, including currency choices. 3.2. Layer 3 interconnection The federation MUST specify and/or provide the mechanism by which peers exchange packets at the TCP/IP layer. This may involve addrressing issues (if not using public IP addresses), and VPN or other tunneling mechanisms. The federation MUST detail the processes by which peers establish, text and maintain their TCP/IP connections. 3.3. Layer 5 interconnection The Federation MUST provide a mechanism for discovery and addressability of multiple ingress elements (proxy servers, SBCs or B2BUAs) from multiple egress elements to allow exchange of signaling between the peers. Where multiple ingress elements are permitted, the Federation must specify how origination peers select one of the ingress elements, and how termination peers may control such selection mechanisms. This version of the BCP does not define automatic load sharing or overload recovery mechanisms. 3.4. Routing The Federation MUST specify the mechanism by which peers discover routing information for the exchange of traffic. Routing mechanisms MUST permit any peer to discover how to route to any other peer's subscribers (or, in the case of a transit peer, the indirect peer's subscribers) based on the Address of Record. Where transit peers are permitted, the Federation MUST either prohibit two or more transit Rosen Expires May 17, 2007 [Page 8] Internet-Draft BCP for Peering Through Federations November 2006 peers from providing access from the same indirect peer (requiring the indirect peer to choose which transit peer represents it at the Federation), or provide provide mechanisms allow an origination network to choose from more than one transit peer who provides transit to the indirect peer. For interoperability reason's, each Federation MUST support at least a Federation supplied ENUM query interface where the Federation supports TN based addressing. If the ENUM data is not in the public DNS tree, the Federation MUST support a provisioning mechanism for a peer to supply it's TNs for peering The Federation SHOULD provide mechanisms for peers to change their routing information dynamically. The change mechanism SHOULD have reasonable ways to bound the time from the initiation of the change to it's effectivity for all peers in the Federation 3.5. NAT Traversal The Federation MAY provide facilities to assist NAT traversal, including STUN and TURN servers. 3.6. Transcode A Federation MAY provide transcode capability. If it does, it MUST specify the mechanism by which peers engage it's transcoder service. 3.7. Capacity Controls A Federation MAY provide mechanisms to monitor and/or limit capacity. This may take the form of mechanisms to determine and report traffic (active calls, calls/messages per unit time, media bandwidth) as well as mechanisms to limit traffic to federation/peer policy. 3.8. Protocol Mediation A Federation MAY provide protocol mediation services to peers which would ameliorate protocol specification limits described in Section 3.1.5 4. Responsibilities of peers 4.1. Conformance to Policies Peers MUST adhere to the policies of the Federation Rosen Expires May 17, 2007 [Page 9] Internet-Draft BCP for Peering Through Federations November 2006 4.2. Identity Each peer must make certain the identity of the originating and terminating endpoints are reliably marked. If [RFC3325] is permitted by the Federation, the peer MUST restrict access to its services to its subscribers, provide a reliable authentication mechanism to identify them, and assert P-A-I with the actual TN for that endpoint. The peer MUST NOT allow endpoints to assert their own P-A-I unless the peer checks the validity of the assertion. If the Federation permits [RFC4474] identity, the peer MUST operate an authorization service or make a 3rd party service available to its subscribers that meet the policy of the Federation. The certificate of the authorization service MUST be signed by a CA authorized by the Federation. The peer SHOULD operate a verification service to validate Identity assertions in traffic recieved from the Federation. 4.3. Transcode Where the peer permits endpoints to offer a codec list that does not contain a codec on the federation mandatory-to-deploy list, the peer must provide transcode capability to at least one of the codecs on the federations list for each type of media. The trancoder should be transparent to another federation peer; the offer/answer from the peer should include a codec on the federation's list, with no action required by the other side to engage the transcoder (unless it has its own, equivalent transcode issue), 5. Security Considerations [RFC3261]. 6. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] 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. [RFC3325] 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. Rosen Expires May 17, 2007 [Page 10] Internet-Draft BCP for Peering Through Federations November 2006 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006. Author's Address Brian Rosen NeuStar 470 Conrad Dr Mars, PA 16046 US Phone: +1 724 382 1051 Email: brian.rosen@neustar.biz Rosen Expires May 17, 2007 [Page 11] Internet-Draft BCP for Peering Through Federations November 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). 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. 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Rosen Expires May 17, 2007 [Page 12]