idnits 2.17.00 (12 Aug 2021) /tmp/idnits49003/draft-rosen-speermint-peeringbcp-v1-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 486. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 497. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 504. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 510. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 13, 2006) is 5661 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 3325 ** Obsolete normative reference: RFC 4474 (Obsoleted by RFC 8224) Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 speermint B. Rosen 3 Internet-Draft NeuStar 4 Intended status: Standards Track November 13, 2006 5 Expires: May 17, 2007 7 Best Current Practices for Session Peering on the Internet by Carriers 8 through Federationsr 9 draft-rosen-speermint-peeringbcp-v1-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 17, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This memo defines a first version Best Current Practice for peering 43 among a federation of voice or other multimedia service providers 45 Table of Contents 47 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2.1. Addressing and Routing . . . . . . . . . . . . . . . . . . 4 50 2.2. Connectivity . . . . . . . . . . . . . . . . . . . . . . . 5 51 2.3. Security (Accountability) . . . . . . . . . . . . . . . . 5 52 2.4. Quality . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 2.5. Protocol Mediation . . . . . . . . . . . . . . . . . . . . 6 54 2.6. Model . . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 3. Responsibilities of Federations . . . . . . . . . . . . . . . 6 56 3.1. Federation Static Policies . . . . . . . . . . . . . . . . 6 57 3.1.1. Membership . . . . . . . . . . . . . . . . . . . . . . 7 58 3.1.2. Identity . . . . . . . . . . . . . . . . . . . . . . . 7 59 3.1.3. Media Exchange . . . . . . . . . . . . . . . . . . . . 7 60 3.1.4. Capacity Controls . . . . . . . . . . . . . . . . . . 7 61 3.1.5. Protocol Specification . . . . . . . . . . . . . . . . 7 62 3.1.6. CODEC choices . . . . . . . . . . . . . . . . . . . . 8 63 3.1.7. Billing . . . . . . . . . . . . . . . . . . . . . . . 8 64 3.2. Layer 3 interconnection . . . . . . . . . . . . . . . . . 8 65 3.3. Layer 5 interconnection . . . . . . . . . . . . . . . . . 8 66 3.4. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 3.5. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 9 68 3.6. Transcode . . . . . . . . . . . . . . . . . . . . . . . . 9 69 3.7. Capacity Controls . . . . . . . . . . . . . . . . . . . . 9 70 3.8. Protocol Mediation . . . . . . . . . . . . . . . . . . . . 9 71 4. Responsibilities of peers . . . . . . . . . . . . . . . . . . 9 72 4.1. Conformance to Policies . . . . . . . . . . . . . . . . . 9 73 4.2. Identity . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 4.3. Transcode . . . . . . . . . . . . . . . . . . . . . . . . 10 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 76 6. Normative References . . . . . . . . . . . . . . . . . . . . . 10 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 Intellectual Property and Copyright Statements . . . . . . . . . . 12 80 1. Terminology 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in [RFC2119]. 86 It is assumed that the reader is familiar with the terminology and 87 acronyms defined in [RFC3261] 89 2. Overview 91 The SIP standard [RFC3261] models much of its protocol operations on 92 familiar Internet applications such as email and the web. For 93 example, SIP clients contact remote domains by resolving SIP URIs 94 which are, like email addresses, composed of a username and domain 95 name portion. As is the case with email, a client need not have any 96 pre-association with a remote domain in order to initiate a session 97 with a user in that domain. The security of SIP is designed to 98 counter the sorts of threats that arise on the Internet - threats 99 based on eavesdropping, packet spoofing, impersonation of identity, 100 and the like. Endpoints must assume responsibility for most of these 101 security functions. Like email and the web, SIP assumes that the 102 Internet end-to-end model applies: that is, that entities using SIP 103 have unimpeded connectivity to one another. 105 There are however operational models in which the assumptions of 106 traditional Internet applications do not hold up. The end-to-end 107 reachability of user agents is commonly obstructed by network-layer 108 impediments like network address translators (NATs) or firewalls. 109 Many SIP user agents, and SIP deployments, utilize telephone numbers 110 rather than email-like SIP URIs, which introduces requirements for a 111 new resolution process in the routing of requests. Some SIP service 112 providers are also uncomfortable leaving the management of security 113 to user agents, for a variety of reasons. 115 To a voice service provider that leverages SIP in a commercial 116 offering, these concerns are all basic issues of usability. Most SIP 117 user agents today have dial pads, and users are accustomed to the use 118 of telephone numbers of voice applications. Without a transparent 119 and automatic NAT traversal function such as ICE (which in turn 120 relies on STUN and TURN services), SIP calls on the public Internet 121 may face serious problems establishing media paths. Users similarly 122 cannot be burdened with understanding and supporting security 123 functions. 125 Solving these concerns also motivates voice service providers to 126 establish formal peering relationships with one another. Peering 127 represents an agreement between parties to permit the exchange of 128 traffic, generally in accordance with some pre-established policy. 129 Without agreement between two VSP domains, for example, on how 130 telephone numbers are resolved, it is impractical for users in 131 different domains to call one another. Security, and in particular 132 authorization, is perhaps the most fundamental reason for peering. 133 The email model, while quite successful, has a very widespread 134 problem with undesirable traffic (namely spam), and a comparable 135 problem for SIP could be quite harmful to commercial offerings. 136 Peering agreements would allow providers to trace accountable sources 137 of undesired traffic and to make appropriate authorization decisions 138 based on traffic sources. 140 Peering at the session layer can occur on a bilateral basis or a 141 multilateral basis, where the latter generally takes the form of a 142 federation (typically in an "assisted" peering configuration). At 143 lower layers of the Internet architecture, there are also various 144 forms of bilateral and multilateral connections which are established 145 between Internet service providers; the more service providers 146 require interconnection, however, the less attractive bilateral 147 connections become, if only because the cost of constructing physical 148 links between networks becomes unwieldy. While it might seem that 149 there is no similar difficulty with the establishment of bilateral 150 peering at the session layer, there are a number of reasons why voice 151 service providers might want to minimize the number of connections 152 they establish to peer networks: for example, to reduce load on 153 gateways (SBCs and IPSec gateways), or to simplify authorization or 154 routing decisions by delegating that responsibility to network 155 elements operated by the federation. 157 Moreover, if there are media-based applications which need to be made 158 available to the federation as a whole, a point of lower layer 159 interconnection, such as a traditional layer 3 interexchange point, 160 is an ideal place to stage them. Any such applications like 161 transcoders and media relays would best be situated in a layer 3 162 point of interconnection. 164 The following sections detail some of the functions that might be 165 performed at a peering point and briefly explain how they benefit 166 from being deployed in a federation environment. 168 2.1. Addressing and Routing 170 Several forms of private directories are useful in a peering context. 171 Aside from the widely-attested need to translate telephone numbers 172 into an identifier that can be routed on the Internet (typically via 173 ENUM or an ENUM-like mechanisms), there is a further need in a 174 peering environment to manage points of egress and ingress on the 175 networks of peers. While this can take the form of a conventional 176 DNS lookup, such a lookup could return IP addresses that are only 177 routable within a peering point, thereby restricting their access to 178 the federation. 180 2.2. Connectivity 182 Most NAT traversal schemes, such as TURN, require the availability of 183 a relay that is reachable by both parties in a call. A peering point 184 is a natural place to stage such a relay precisely because its 185 position in the network is unlikely to introduce additional latency 186 in the media by lengthening the call path. 188 2.3. Security (Accountability) 190 SIP can be used in constrained environments, effectively closed IP 191 networks, where the threats that are quite plausible on the public 192 Internet become very unlikely - especially environments that are 193 based on traditional telephone networks. In those closed 194 environments the use of the baseline SIP security mechanisms may seem 195 very unattractive. Some form of transitive trust is typically viewed 196 as sufficient in this sort of environment. The use of network-layer 197 security gateways that connect individual networks to a closed 198 peering point VLAN would be one example of how this might operate. 200 Certain application-layer functions can assist with the establishment 201 of transitive trust and the management of service provider 202 authorization based on that trust. For example, mechanisms like 203 RFC3325 or RFC4474, which provide assurance of the identity of the 204 originator of a SIP request, can be performed by a SIP proxy server 205 resident in the peering point. Note that especially when telephone 206 number translations are centrally managed by the federation, 207 providing identity functions for Caller-ID typical must also be 208 managed by the federation. 210 2.4. Quality 212 The use of protocols to establish quality of service across a traffic 213 path in an IP network is quite controversial, especially when tied to 214 a real-time application like voice over IP. Traffic engineering, 215 management of quality across a particular link, is more common and 216 generally less complex than resource reservation on a per-call basis. 217 Moreover, the extremely large deployments of certain VoIP 218 applications on the public Internet which lack any per-call resource 219 reservation have created a great deal of skepticism about the need to 220 incur any significant expense to assure quality. 222 Layer 3 peering points are general points of optimal quality in the 223 network from a latency and bandwidth perspective, and accordingly 224 they are likely to be the best place to stage any network-based 225 mechanism which would help to assure call quality. 227 2.5. Protocol Mediation 229 [[ unsure if we'd want to talk about different SIP "variants" and the 230 normalization of SIP signaling, this is just a placeholder entry ]] 232 2.6. Model 234 Directories NAT SIP 235 +---+ +---+ +---+ +---+ 3325 236 | | | | | | | | 237 +---+ +---+ +---+ +---+ 4474 238 | | | | 239 | | | | 240 Peering +--+------+------+------+--------- 241 Point | Applications 242 --- | 243 Peered / \ | 244 Network ---------| +--------+ 245 //\ / 246 // -+- 247 // | 248 // | 249 / | 250 Peered | 251 Network | 253 Peered 254 Network 256 3. Responsibilities of Federations 258 3.1. Federation Static Policies 260 Federations must establish explicit policies on at least the 261 following matters. Such policies may be in in the form of a contract 262 or other agreement between the federation and peers, a web page, or 263 other prominant mechanism. In some cases, the federation MAY 264 explicity permit or prohibit parts of the policy described to be a 265 matter for bilateral agreements within the federation. In this 266 version of the BCP, we provide no standardized way to express this 267 form of policy. 269 3.1.1. Membership 271 The Federation MUST specify who is allowed to peer at the federation, 272 and how the peers are made known to one another. The policy MUST 273 include a statement of whether indirect (i.e. transit) peers are 274 permitted. 276 3.1.2. Identity 278 The Federation MUST specify the requirements on peers to identify 279 users. The Federation MAY permit [RFC3325] asserted identity. The 280 Federation SHOULD permit [RFC4474] Identity. Federations supporting 281 RFC4474 MUST specify the CA(s) permitted to issue certificates of the 282 authentication service (which MAY be operated by the Federation). 283 The Federation policy MUST specify the date maximum descrepancy 284 period, The policy MUST specify what is permitted in the display name 285 of the From: header, and what mechanisms peers must have to control 286 such content. 288 3.1.3. Media Exchange 290 The Federation MUST specify mechanisms for the interchange of media 291 among the peers. This MUST include mechanisms for NAT traversal. 293 3.1.4. Capacity Controls 295 The Federation MUST specify policy to control the traffic sent to and 296 recieved by peers. The policy SHOULD include limits on the maximum 297 number of active calls, maximum number of calls/messages per 298 specified unit time and the aggregate media bandwidth. 299 Specifications for both aggregate traffic to/from the federation as 300 well as limits between two peers MAY be specified. 302 The Federation MAY specify policy for individual ingress/egress 303 elements as well as total traffic to/from a peer. 305 Federations MAY permit peers to specify and/or form bilateral 306 agreements on the limits. This version of the BCP does not specify 307 mechanisms for dynamic discovery or modification of such policies. 309 3.1.5. Protocol Specification 311 The Federation MUST specify details of the (SIP) signaling messages 312 that peers must conform to. Such specification SHOULD include 313 minimal extensions that MUST be supported, and what options MUST be 314 supported, MUST NOT be supported or MAY be supported. This 315 specification SHOULD include a description of the services that are 316 expected to be supported across the Federation, and the signaling 317 associated with such services. 319 3.1.6. CODEC choices 321 The federation defines a codec policy to which all peers must adhere 322 which would include designation of one or more mandatory to deploy 323 codec and/or local transcode capability for each supported media type 324 (audio, video, text) so that all calls can successfully complete 325 offer/answer exchange. Consideration should be given in specifying 326 mandatory-to-deploy codecs to include at least one that has minimal 327 degradation of signal fidelity when two transcodes are required to 328 achieve actual end to end compatibility. 330 3.1.7. Billing 332 The Federation MUST specify what charging mechanisms for the exchange 333 of traffic it permits, and any support for such practices (e.g. CDR 334 production) it provides. Where the Federation provides explicit 335 billing arrangements, such arrangements must be described, including 336 currency choices. 338 3.2. Layer 3 interconnection 340 The federation MUST specify and/or provide the mechanism by which 341 peers exchange packets at the TCP/IP layer. This may involve 342 addrressing issues (if not using public IP addresses), and VPN or 343 other tunneling mechanisms. The federation MUST detail the processes 344 by which peers establish, text and maintain their TCP/IP connections. 346 3.3. Layer 5 interconnection 348 The Federation MUST provide a mechanism for discovery and 349 addressability of multiple ingress elements (proxy servers, SBCs or 350 B2BUAs) from multiple egress elements to allow exchange of signaling 351 between the peers. Where multiple ingress elements are permitted, 352 the Federation must specify how origination peers select one of the 353 ingress elements, and how termination peers may control such 354 selection mechanisms. This version of the BCP does not define 355 automatic load sharing or overload recovery mechanisms. 357 3.4. Routing 359 The Federation MUST specify the mechanism by which peers discover 360 routing information for the exchange of traffic. Routing mechanisms 361 MUST permit any peer to discover how to route to any other peer's 362 subscribers (or, in the case of a transit peer, the indirect peer's 363 subscribers) based on the Address of Record. Where transit peers are 364 permitted, the Federation MUST either prohibit two or more transit 365 peers from providing access from the same indirect peer (requiring 366 the indirect peer to choose which transit peer represents it at the 367 Federation), or provide provide mechanisms allow an origination 368 network to choose from more than one transit peer who provides 369 transit to the indirect peer. 371 For interoperability reason's, each Federation MUST support at least 372 a Federation supplied ENUM query interface where the Federation 373 supports TN based addressing. If the ENUM data is not in the public 374 DNS tree, the Federation MUST support a provisioning mechanism for a 375 peer to supply it's TNs for peering 377 The Federation SHOULD provide mechanisms for peers to change their 378 routing information dynamically. The change mechanism SHOULD have 379 reasonable ways to bound the time from the initiation of the change 380 to it's effectivity for all peers in the Federation 382 3.5. NAT Traversal 384 The Federation MAY provide facilities to assist NAT traversal, 385 including STUN and TURN servers. 387 3.6. Transcode 389 A Federation MAY provide transcode capability. If it does, it MUST 390 specify the mechanism by which peers engage it's transcoder service. 392 3.7. Capacity Controls 394 A Federation MAY provide mechanisms to monitor and/or limit capacity. 395 This may take the form of mechanisms to determine and report traffic 396 (active calls, calls/messages per unit time, media bandwidth) as well 397 as mechanisms to limit traffic to federation/peer policy. 399 3.8. Protocol Mediation 401 A Federation MAY provide protocol mediation services to peers which 402 would ameliorate protocol specification limits described in 403 Section 3.1.5 405 4. Responsibilities of peers 407 4.1. Conformance to Policies 409 Peers MUST adhere to the policies of the Federation 411 4.2. Identity 413 Each peer must make certain the identity of the originating and 414 terminating endpoints are reliably marked. If [RFC3325] is permitted 415 by the Federation, the peer MUST restrict access to its services to 416 its subscribers, provide a reliable authentication mechanism to 417 identify them, and assert P-A-I with the actual TN for that endpoint. 418 The peer MUST NOT allow endpoints to assert their own P-A-I unless 419 the peer checks the validity of the assertion. If the Federation 420 permits [RFC4474] identity, the peer MUST operate an authorization 421 service or make a 3rd party service available to its subscribers that 422 meet the policy of the Federation. The certificate of the 423 authorization service MUST be signed by a CA authorized by the 424 Federation. The peer SHOULD operate a verification service to 425 validate Identity assertions in traffic recieved from the Federation. 427 4.3. Transcode 429 Where the peer permits endpoints to offer a codec list that does not 430 contain a codec on the federation mandatory-to-deploy list, the peer 431 must provide transcode capability to at least one of the codecs on 432 the federations list for each type of media. The trancoder should be 433 transparent to another federation peer; the offer/answer from the 434 peer should include a codec on the federation's list, with no action 435 required by the other side to engage the transcoder (unless it has 436 its own, equivalent transcode issue), 438 5. Security Considerations 440 [RFC3261]. 442 6. Normative References 444 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 445 Requirement Levels", BCP 14, RFC 2119, March 1997. 447 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 448 A., Peterson, J., Sparks, R., Handley, M., and E. 449 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 450 June 2002. 452 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 453 Extensions to the Session Initiation Protocol (SIP) for 454 Asserted Identity within Trusted Networks", RFC 3325, 455 November 2002. 457 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 458 Authenticated Identity Management in the Session 459 Initiation Protocol (SIP)", RFC 4474, August 2006. 461 Author's Address 463 Brian Rosen 464 NeuStar 465 470 Conrad Dr 466 Mars, PA 16046 467 US 469 Phone: +1 724 382 1051 470 Email: brian.rosen@neustar.biz 472 Full Copyright Statement 474 Copyright (C) The Internet Society (2006). 476 This document is subject to the rights, licenses and restrictions 477 contained in BCP 78, and except as set forth therein, the authors 478 retain all their rights. 480 This document and the information contained herein are provided on an 481 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 482 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 483 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 484 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 485 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 486 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 488 Intellectual Property 490 The IETF takes no position regarding the validity or scope of any 491 Intellectual Property Rights or other rights that might be claimed to 492 pertain to the implementation or use of the technology described in 493 this document or the extent to which any license under such rights 494 might or might not be available; nor does it represent that it has 495 made any independent effort to identify any such rights. Information 496 on the procedures with respect to rights in RFC documents can be 497 found in BCP 78 and BCP 79. 499 Copies of IPR disclosures made to the IETF Secretariat and any 500 assurances of licenses to be made available, or the result of an 501 attempt made to obtain a general license or permission for the use of 502 such proprietary rights by implementers or users of this 503 specification can be obtained from the IETF on-line IPR repository at 504 http://www.ietf.org/ipr. 506 The IETF invites any interested party to bring to its attention any 507 copyrights, patents or patent applications, or other proprietary 508 rights that may cover technology that may be required to implement 509 this standard. Please address the information to the IETF at 510 ietf-ipr@ietf.org. 512 Acknowledgment 514 Funding for the RFC Editor function is provided by the IETF 515 Administrative Support Activity (IASA).