idnits 2.17.1 draft-ietf-speermint-architecture-19.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 18, 2011) is 4813 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '4' on line 211 == Outdated reference: A later version (-11) exists of draft-ietf-speermint-requirements-10 == Outdated reference: A later version (-09) exists of draft-ietf-speermint-voipthreats-07 ** Obsolete normative reference: RFC 3761 (Obsoleted by RFC 6116, RFC 6117) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-19) exists of draft-ietf-speermint-voip-consolidated-usecases-18 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPEERMINT D. Malas, Ed. 3 Internet-Draft CableLabs 4 Intended status: Informational J. Livingood, Ed. 5 Expires: August 22, 2011 Comcast 6 February 18, 2011 8 Session PEERing for Multimedia INTerconnect Architecture 9 draft-ietf-speermint-architecture-19 11 Abstract 13 This document defines a peering architecture for the Session 14 Initiation Protocol (SIP), its functional components and interfaces. 15 It also describes the components and the steps necessary to establish 16 a session between two SIP Service Provider (SSP) peering domains. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 22, 2011. 35 Copyright Notice 37 Copyright (c) 2011 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 This document may contain material from IETF Documents or IETF 51 Contributions published or made publicly available before November 52 10, 2008. The person(s) controlling the copyright in some of this 53 material may not have granted the IETF Trust the right to allow 54 modifications of such material outside the IETF Standards Process. 55 Without obtaining an adequate license from the person(s) controlling 56 the copyright in such materials, this document may not be modified 57 outside the IETF Standards Process, and derivative works of it may 58 not be created outside the IETF Standards Process, except to format 59 it for publication as an RFC or to translate it into languages other 60 than English. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. New Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 66 2.1. Session Border Controller (SBC) . . . . . . . . . . . . . 4 67 2.2. Carrier-of-Record . . . . . . . . . . . . . . . . . . . . 5 68 3. Reference Architecture . . . . . . . . . . . . . . . . . . . . 5 69 4. Procedures of Inter-Domain SSP Session Establishment . . . . . 7 70 5. Relationships Between Functions/Elements . . . . . . . . . . . 8 71 6. Recommended SSP Procedures . . . . . . . . . . . . . . . . . . 8 72 6.1. Originating or Indirect SSP Procedures . . . . . . . . . . 8 73 6.1.1. The Look-Up Function (LUF) . . . . . . . . . . . . . . 9 74 6.1.1.1. Target Address Analysis . . . . . . . . . . . . . 9 75 6.1.1.2. ENUM Lookup . . . . . . . . . . . . . . . . . . . 9 76 6.1.2. Location Routing Function (LRF) . . . . . . . . . . . 10 77 6.1.2.1. DNS Resolution . . . . . . . . . . . . . . . . . . 10 78 6.1.2.2. Routing Table . . . . . . . . . . . . . . . . . . 10 79 6.1.2.3. LRF to LRF Routing . . . . . . . . . . . . . . . . 11 80 6.1.3. The Signaling Path Border Element (SBE) . . . . . . . 11 81 6.1.3.1. Establishing a Trusted Relationship . . . . . . . 11 82 6.1.3.2. IPSec . . . . . . . . . . . . . . . . . . . . . . 11 83 6.1.3.3. Co-Location . . . . . . . . . . . . . . . . . . . 11 84 6.1.3.4. Sending the SIP Request . . . . . . . . . . . . . 12 85 6.2. Target SSP Procedures . . . . . . . . . . . . . . . . . . 12 86 6.2.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . 12 87 6.2.2. Receive SIP Requests . . . . . . . . . . . . . . . . . 12 88 6.3. Data Path Border Element (DBE) . . . . . . . . . . . . . . 13 89 7. Address Space Considerations . . . . . . . . . . . . . . . . . 13 90 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 91 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 92 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 93 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 94 12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 15 95 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 96 13.1. Normative References . . . . . . . . . . . . . . . . . . . 16 97 13.2. Informative References . . . . . . . . . . . . . . . . . . 18 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 100 1. Introduction 102 This document defines a reference peering architecture for the 103 Session Initiation Protocol (SIP)[RFC3261], it's functional 104 components and interfaces, in the context of session peering for 105 multimedia interconnects. In this process, we define the peering 106 reference architecture, its functional components, and peering 107 interface functions from the perspective of a SIP Service Provider's 108 (SSP) [RFC5486] network. Thus, it also describes the components and 109 the steps necessary to establish a session between two SSP peering 110 domains. 112 An SSP may also be referred to as an Internet Telephony Service 113 Provider (ITSP). While the terms ITSP and SSP are frequently used 114 interchangeably, this document and other subsequent SIP peering- 115 related documents should use the term SSP. SSP more accurately 116 depicts the use of SIP as the underlying layer 5 signaling protocol. 118 This architecture enables the interconnection of two SSPs in layer 5 119 peering, as defined in the SIP-based session peering requirements 120 [I-D.ietf-speermint-requirements]. 122 Layer 3 peering is outside the scope of this document. Hence, the 123 figures in this document do not show routers so that the focus is on 124 layer 5 protocol aspects. 126 This document uses terminology defined in the Session Peering for 127 Multimedia Interconnect (SPEERMINT) Terminology document [RFC5486]. 128 Apart from normative references included herein, readers may also 129 find [I-D.ietf-speermint-voip-consolidated-usecases] informative. 131 2. New Terminology 133 [RFC5486] is a key reference for the majority of the SPEERMINT- 134 related terminology used in this document. However, some additional 135 new terms are used here as follows in this section. 137 2.1. Session Border Controller (SBC) 139 A Session Border Controller (SBC) is referred to in Section 5. An 140 SBC can contain a Signaling Function (SF), Signaling Path Border 141 Element (SBE) and Data Path Border Element (DBE), and may perform the 142 Look-Up Function (LUF) and Location Routing Function (LRF) functions, 143 as described in Section 3. Whether the SBC performs one or more of 144 these functions is generally speaking dependent upon how a SIP 145 Service Provider (SSP) configures such a network element. In 146 addition, requirements for an SBC can be found in [RFC5853]. 148 2.2. Carrier-of-Record 150 A carrier-of-record, as used in Section 6.1.2.2, is defined in 151 [RFC5067]. That document describes the term to refer to the entity 152 having discretion over the domain and zone content and acting as the 153 registrant for a telephone number, as represented in ENUM. This can 154 be: 156 o the Service Provider to which the E.164 number was allocated for 157 end user assignment, whether by the National Regulatory Authority 158 (NRA) or the International Telecommunication Union (ITU), for 159 instance, a code under "International Networks" (+882) or 160 "Universal Personal Telecommunications (UPT)" (+878) or, 162 o if the number is ported, the service provider to which the number 163 was ported, or 165 o where numbers are assigned directly to end users, the service 166 provider that the end user number assignee has chosen to provide a 167 Public Switched Telephone Network/Public Land Mobile Network 168 (PSTN/ PLMN) point-of-interconnect for the number. 170 It is understood that the definition of carrier-of-record within a 171 given jurisdiction is subject to modification by national 172 authorities. 174 3. Reference Architecture 176 The following figure depicts the architecture and logical functions 177 that form peering between two SSPs. 179 For further details on the elements and functions described in this 180 figure, please refer to [RFC5486]. The following terms, which appear 181 in Figure 1, which are documented in [RFC5486] are reproduced here 182 for simplicity. 184 - Data Path Border Element (DBE): A data path border element (DBE) is 185 located on the administrative border of a domain through which flows 186 the media associated with an inter-domain session. It typically 187 provides media-related functions such as deep packet inspection and 188 modification, media relay, and firewall-traversal support. The DBE 189 may be controlled by the SBE. 191 - E.164 Number Mapping (ENUM): See [RFC3761]. 193 - Fully Qualified Domain Name (FQDN): See Section 5.1 of [RFC1035]. 195 - Location Routing Function (LRF): The Location Routing Function 196 (LRF) determines for the target domain of a given request the 197 location of the SF in that domain, and optionally develops other SED 198 required to route the request to that domain. An example of the LRF 199 may be applied to either example in Section 4.3.3 of [RFC5486]. Once 200 the ENUM response or SIP 302 redirect is received with the 201 destination's SIP URI, the LRF must derive the destination peer's SF 202 from the FQDN in the domain portion of the URI. In some cases, some 203 entity (usually a 3rd party or federation) provides peering 204 assistance to the originating SSP by providing this function. The 205 assisting entity may provide information relating to direct (Section 206 4.2.1 of [RFC5486]) or indirect (Section 4.2.2 of [RFC5486]) peering 207 as necessary. 209 - Look-Up Function (LUF): The Look-Up Function (LUF) determines for a 210 given request the target domain to which the request should be 211 routed. An example of an LUF is an ENUM [4] look-up or a SIP INVITE 212 request to a SIP proxy providing redirect responses for peers. In 213 some cases, some entity (usually a 3rd party or federation) provides 214 peering assistance to the originating SSP by providing this function. 215 The assisting entity may provide information relating to direct 216 (Section 4.2.1 of [RFC5486]) or indirect (Section 4.2.2 of [RFC5486]) 217 peering as necessary. 219 - Real-Time Transport Protocol (RTP): See [RFC3550]. 221 - Session Initiation Protocol (SIP): See [RFC3261]. 223 - Signaling Path Border Element (SBE): A signaling path border 224 element (SBE) is located on the administrative border of a domain 225 through which inter-domain session layer messages will flow. It 226 typically provides signaling functions such as protocol inter-working 227 (for example, H.323 to SIP), identity and topology hiding, and 228 Session Admission Control for a domain. 230 - Signaling Function (SF): The Signaling Function (SF) performs 231 routing of SIP requests for establishing and maintaining calls, and 232 to assist in the discovery or exchange of parameters to be used by 233 the Media Function (MF). The SF is a capability of SIP processing 234 elements such as SIP proxies, SBEs, and user agents. 236 - SIP Service Provider (SSP): A SIP Service Provider (SSP) is an 237 entity that provides session services utilizing SIP signaling to its 238 customers. In the event that the SSP is also a function of the SP, 239 it may also provide media streams to its customers. Such an SSP may 240 additionally be peered with other SSPs. An SSP may also interconnect 241 with the PSTN. 243 +=============++ ++=============+ 244 || || 245 +-----------+ +-----------+ 246 | SBE | +-----+ | SBE | 247 | +-----+ | SIP |Proxy| | +-----+ | 248 | | LUF |<-|------>|ENUM | | | LUF | | 249 | +-----+ | ENUM |TN DB| | +-----+ | 250 SIP | | +-----+ | | 251 ------>| +-----+ | DNS +-----+ | +-----+ | 252 | | LRF |<-|------>|FQDN | | | LRF | | 253 | +-----+ | |IP | | +-----+ | 254 | +-----+ | SIP +-----+ | +-----+ | 255 | | SF |<-|----------------|->| SF | | 256 | +-----+ | | +-----+ | 257 +-----------+ +-----------+ 258 || || 259 +-----------+ +-----------+ 260 RTP | DBE | RTP | DBE | 261 ------>| |--------------->| | 262 +-----------+ +-----------+ 263 || || 264 SSP1 Network || || SSP2 Network 265 +=============++ ++=============+ 267 Reference Architecture 269 Figure 1 271 4. Procedures of Inter-Domain SSP Session Establishment 273 This document assumes that in order for a session to be established 274 from a User Agent (UA) in the originating (or indirect) SSP's network 275 to an UA in the Target SSP's network the following steps are taken: 277 1. Determine the target or indirect SSP via the LUF. (Note: If the 278 target address represents an intra-SSP resource, the behavior is 279 out-of-scope with respect to this draft.) 281 2. Determine the address of the SF of the target SSP via the LRF. 283 3. Establish the session 285 4. Exchange the media, which could include voice, video, text, etc. 287 5. End the session (BYE) 288 The originating or indirect SSP would perform steps 1-4, the target 289 SSP would perform steps 4, and either one can perform step 5. 291 In the case the target SSP changes, then steps 1-4 would be repeated. 292 This is reflected in Figure 1 that shows the target SSP with its own 293 peering functions. 295 5. Relationships Between Functions/Elements 297 Please also refer to Figure 1. 299 o An SBE can contain a Signaling Function (SF). 301 o An SF can perform a Look-Up Function (LUF) and Location Routing 302 Function (LRF). 304 o As an additional consideration, a Session Border Controller, can 305 contain an SF, SBE and DBE, and may act as both an LUF and LRF. 307 o The following functions may communicate as follows in an example 308 SSP network, depending upon various real-world implementations: 310 * SF may communicate with LUF, LRF, SBE and SF 312 * LUF may communicate with SF and SBE 314 * LRF may communicate with SF and SBE 316 6. Recommended SSP Procedures 318 This section describes the functions in more detail and provides some 319 recommendations on the role they would play in a SIP call in a Layer 320 5 peering scenario. 322 Some of the information in the section is taken from 323 [I-D.ietf-speermint-requirements] and is included here for continuity 324 purposes. It is also important to refer to Section 3.2 of 325 [I-D.ietf-speermint-voipthreats], particularly with respect to the 326 use of IPSec and TLS. 328 6.1. Originating or Indirect SSP Procedures 330 This section describes the procedures of the originating or indirect 331 SSP. 333 6.1.1. The Look-Up Function (LUF) 335 The purpose of the LUF is to determine the SF of the target domain of 336 a given request and optionally to develop Session Establishment Data. 337 It is important to note that the LUF may utilize the public e164.arpa 338 ENUM root, as well as one or more private roots. When private roots 339 are used specialized routing rules may be implemented, and these 340 rules may vary depending upon whether an originating or indirect SSP 341 is querying the LUF. 343 6.1.1.1. Target Address Analysis 345 When the originating (or indirect) SSP receives a request to 346 communicate, it analyzes the target URI to determine whether the call 347 needs to be routed internal or external to its network. The analysis 348 method is internal to the SSP; thus, outside the scope of SPEERMINT. 350 If the target address does not represent a resource inside the 351 originating (or indirect) SSP's administrative domain or federation 352 of domains, then the originating (or indirect) SSP performs a Lookup 353 Function (LUF) to determine a target address, and then it resolves 354 the call routing data by using the Location routing Function (LRF). 356 For example, if the request to communicate is for an im: or pres: URI 357 type [RFC3861] [RFC3953], the originating (or indirect) SSP follows 358 the procedures in [RFC3861]. If the highest priority supported URI 359 scheme is sip: or sips: the originating (or indirect) SSP skips to 360 SIP DNS resolution in Section 5.1.3. Likewise, if the target address 361 is already a sip: or sips: URI in an external domain, the originating 362 (or indirect) SSP skips to SIP DNS resolution in Section 6.1.2.1. 363 This may be the case, to use one example, with 364 "sips:bob@biloxi.example.com". 366 If the target address corresponds to a specific E.164 address, the 367 SSP may need to perform some form of number plan mapping according to 368 local policy. For example, in the United States, a dial string 369 beginning "011 44" could be converted to "+44", or in the United 370 Kingdom "00 1" could be converted to "+1". Once the SSP has an E.164 371 address, it can use ENUM. 373 6.1.1.2. ENUM Lookup 375 If an external E.164 address is the target, the originating (or 376 indirect) SSP consults the public "User ENUM" rooted at e164.arpa, 377 according to the procedures described in [RFC3761]. The SSP must 378 query for the "E2U+sip" enumservice as described in [RFC3764], but 379 may check for other enumservices. The originating (or indirect) SSP 380 may consult a cache or alternate representation of the ENUM data 381 rather than actual DNS queries. Also, the SSP may skip actual DNS 382 queries if the originating (or indirect) SSP is sure that the target 383 address country code is not represented in e164.arpa. 385 If an im: or pres: URI is chosen based on an "E2U+im" [RFC3861] or 386 "E2U+pres" [RFC3953] enumserver, the SSP follows the procedures for 387 resolving these URIs to URIs for specific protocols such as SIP or 388 XMPP as described in the previous section. 390 The NAPTR response to the ENUM lookup may be a SIP AoR (such as 391 "sips:bob@example.com") or SIP URI (such as 392 "sips:bob@sbe1.biloxi.example.com"). In the case of when a SIP URI 393 is returned, the originating (or indirect) SSP has sufficient routing 394 information to locate the target SSP. In the case of when a SIP AoR 395 is returned, the SF then uses the LRF to determine the URI for more 396 explicitly locating the target SSP. 398 6.1.2. Location Routing Function (LRF) 400 The LRF of an originating (or indirect) SSP analyzes target address 401 and target domain identified by the LUF, and discovers the next hop 402 signaling function (SF) in a peering relationship. The resource to 403 determine the SF of the target domain might be provided by a third- 404 party as in the assisted-peering case. The following sections define 405 mechanisms which may be used by the LRF. These are not in any 406 particular order and, importantly, not all of them have to be used. 408 6.1.2.1. DNS Resolution 410 The originating (or indirect) SSP uses the procedures in Section 4 of 411 [RFC3263] to determine how to contact the receiving SSP. To 412 summarize the [RFC3263] procedure: unless these are explicitly 413 encoded in the target URI, a transport is chosen using NAPTR records, 414 a port is chosen using SRV records, and an address is chosen using A 415 or AAAA records. 417 When communicating with another SSP, entities compliant to this 418 document should select a TLS-protected transport for communication 419 from the originating (or indirect) SSP to the receiving SSP if 420 available, as described further in Section 6.2.1. 422 6.1.2.2. Routing Table 424 If there are no End User ENUM records and the originating (or 425 indirect) SSP cannot discover the carrier-of-record or if the 426 originating (or indirect) SSP cannot reach the carrier-of-record via 427 SIP peering, the originating (or indirect) SSP may deliver the call 428 to the PSTN or reject it. Note that the originating (or indirect) 429 SSP may forward the call to another SSP for PSTN gateway termination 430 by prior arrangement using the local SIP proxy routing table. 432 If so, the originating (or indirect) SSP rewrites the Request-URI to 433 address the gateway resource in the target SSP's domain and may 434 forward the request on to that SSP using the procedures described in 435 the remainder of these steps. 437 6.1.2.3. LRF to LRF Routing 439 Communications between the LRF of two interconnecting SSPs may use 440 DNS or statically provisioned IP Addresses for reachability. Other 441 inputs to determine the path may be code-based routing, method-based 442 routing, Time of day, least cost and/or source-based routing. 444 6.1.3. The Signaling Path Border Element (SBE) 446 The purpose of signaling function is to perform routing of SIP 447 messages as well as optionally implement security and policies on SIP 448 messages, and to assist in discovery/exchange of parameters to be 449 used by the Media Function (MF). The signaling function performs the 450 routing of SIP messages. The SBE may be a B2BUA or it may act as a 451 SIP proxy. Optionally, an SF may perform additional functions such 452 as Session Admission Control, SIP Denial of Service protection, SIP 453 Topology Hiding, SIP header normalization, SIP security, privacy, and 454 encryption. The SF of an SBE can also process SDP payloads for media 455 information such as media type, bandwidth, and type of codec; then, 456 communicate this information to the media function. 458 6.1.3.1. Establishing a Trusted Relationship 460 Depending on the security needs and trust relationships between SSPs, 461 different security mechanisms can be used to establish SIP calls. 462 These are discussed in the following subsections. 464 6.1.3.2. IPSec 466 In certain deployments the use of IPSec between the signaling 467 functions of the originating and terminating domains can be used as a 468 security mechanism instead of TLS. However, such IPSec use should be 469 the subject of a future document as additional specification is 470 necessary to use IPSec properly and effectively. 472 6.1.3.3. Co-Location 474 In this scenario the SFs are co-located in a physically secure 475 location and/or are members of a segregated network. In this case 476 messages between the originating and terminating SSPs could be sent 477 as clear text (unencrypted). However, even in these semi-trusted co- 478 location facilities, other security or access control mechanisms may 479 be appropriate, such as IP access control lists or other mechanisms. 481 6.1.3.4. Sending the SIP Request 483 Once a trust relationship between the peers is established, the 484 originating (or indirect) SSP sends the request. 486 6.2. Target SSP Procedures 488 This section describes the Target SSP Procedures. 490 6.2.1. TLS 492 The section defines the usage of TLS between two SSPs [RFC5246] 493 [RFC5746] [RFC5878]. When the receiving SSP receives a TLS client 494 hello, it responds with its certificate. The Target SSP certificate 495 should be valid and rooted in a well-known certificate authority. 496 The procedures to authenticate the SSP's originating domain are 497 specified in [RFC5922]. 499 The SF of the Target SSP verifies that the Identity header is valid, 500 corresponds to the message, corresponds to the Identity-Info header, 501 and that the domain in the From header corresponds to one of the 502 domains in the TLS client certificate. 504 As noted above in Section 6.1.3.2, some deployments may utilize IPSec 505 rather than TLS. 507 6.2.2. Receive SIP Requests 509 Once a trust relationship is established, the Target SSP is prepared 510 to receive incoming SIP requests. For new requests (dialog forming 511 or not) the receiving SSP verifies if the target (request-URI) is a 512 domain that for which it is responsible. For these requests, there 513 should be no remaining Route header field values. For in-dialog 514 requests, the receiving SSP can verify that it corresponds to the 515 top-most Route header field value. 517 The receiving SSP may reject incoming requests due to local policy. 518 When a request is rejected because the originating (or indirect) SSP 519 is not authorized to peer, the receiving SSP should respond with a 520 403 response with the reason phrase "Unsupported Peer". 522 6.3. Data Path Border Element (DBE) 524 The purpose of the DBE [RFC5486] is to perform media related 525 functions such as media transcoding and media security implementation 526 between two SSPs. 528 An example of this is to transform a voice payload from one codec 529 (e.g., G.711) to another (e.g., EvRC). Additionally, the MF may 530 perform media relaying, media security [RFC3711], privacy, and 531 encryption. 533 7. Address Space Considerations 535 Peering must occur in a common IP address space, which is defined by 536 the federation, which may be entirely on the public Internet, or some 537 private address space [RFC1918]. The origination or termination 538 networks may or may not entirely be in the same address space. If 539 they are not, then a network address translation (NAT) or similar may 540 be needed before the signaling or media is presented correctly to the 541 federation. The only requirement is that all associated entities 542 across the peering interface are reachable. 544 8. Acknowledgments 546 The working group would like to thank John Elwell, Otmar Lendl, Rohan 547 Mahy, Alexander Mayrhofer, Jim McEachern, Jean-Francois Mule, 548 Jonathan Rosenberg, and Dan Wing for their valuable contributions to 549 various versions of this document. 551 9. IANA Considerations 553 This memo includes no request to IANA. 555 10. Security Considerations 557 The level (or types) of security mechanisms implemented between 558 peering providers is in practice dependent upon on the underlying 559 physical security of SSP connections. This means, as noted in 560 Section 6.1.3.3, whether peering equipment is in a secure facility or 561 not may bear on other types of security mechanisms which may be 562 appropriate. Thus, if two SSPs peered across public Internet links, 563 they are likely to use IPSec or TLS since the link between the two 564 domains should be considered untrusted. 566 Many detailed and highly relevant security requirements for SPEERMINT 567 have been documented in Section 5 of 568 [I-D.ietf-speermint-requirements]. As a result, that document should 569 be considered required reading. 571 Additional and important security considerations have been documented 572 separately in [I-D.ietf-speermint-voipthreats]. This document 573 describes the many relevant security threats to SPEERMINT, as well 574 the relevant countermeasures and security protections which are 575 recommended to combat any potential threats or other risks. This 576 includes a wide range of detailed threats in Section 2 of 577 [I-D.ietf-speermint-voipthreats]. It also includes key requirements 578 in Section 3.1 of [I-D.ietf-speermint-voipthreats], such as the 579 requirement for the LUF and LRF to support mutual authentication for 580 queries, among other requirements which are related to 581 [I-D.ietf-speermint-requirements]. Section 3.2 of 582 [I-D.ietf-speermint-voipthreats] explains how to meet these security 583 requirements, and then Section 4 explores a wide range of suggested 584 countermeasures. 586 11. Contributors 588 Mike Hammer 590 Cisco Systems 592 Herndon, VA - USA 594 Email: mhammer@cisco.com 596 -------------------------------------------------------------- 598 Hadriel Kaplan 600 Acme Packet 602 Burlington, MA - USA 604 Email: hkaplan@acmepacket.com 606 -------------------------------------------------------------- 608 Sohel Khan, Ph.D. 610 Comcast Cable 612 Philadelphia, PA - USA 613 Email: sohel_khan@cable.comcast.com 615 -------------------------------------------------------------- 617 Reinaldo Penno 619 Juniper Networks 621 Sunnyvale, CA - USA 623 Email: rpenno@juniper.net 625 -------------------------------------------------------------- 627 David Schwartz 629 XConnect Global Networks 631 Jerusalem - Israel 633 Email: dschwartz@xconnnect.net 635 -------------------------------------------------------------- 637 Rich Shockey 639 Shockey Consulting 641 USA 643 Email: Richard@shockey.us 645 -------------------------------------------------------------- 647 Adam Uzelac 649 Global Crossing 651 Rochester, NY - USA 653 Email: adam.uzelac@globalcrossing.com 655 12. Change Log 657 NOTE TO RFC EDITOR: PLEASE REMOVE THIS SECTION PRIOR TO PUBLICATION. 659 o 19: Additional change to the IPSec section at Jari Arkko's 660 request. 662 o 18: Made several changes based on feedback from Adrian Farrel, 663 Bert Wijnen, Dan Romascanu, Avshalom Houri, Russ Housley, Sean 664 Turner, Tim Polk, and Russ Mundy during IESG review. 666 o 17: Misc. updates at the request of Gonzalo, the RAI AD, in order 667 to clear his review and move to the IESG. This included adding 668 terminology from RFC 5486 and expanding the document name. 670 o 16: Yes, one final outdated reference to fix. 672 o 15: Doh! Uploaded the wrong doc to create -14. Trying again. :-) 674 o 14: WGLC ended. Ran final nits check prior to sending proto to 675 the AD and sending the doc to the IESG. Found a few very minor 676 nits, such as capitalization and replacement of an obsoleted RFC, 677 which were corrected per nits tool recommendation. The -14 now 678 moves to the AD and the IESG. 680 o 13: Closed out all remaining tickets, resolved all editorial 681 notes. 683 o 12: Closed out several open issues. Properly XML-ized all 684 references. Updated contributors list. 686 o 11: Quick update to refresh the I-D since it expired, and cleaned 687 up some of the XML for references. A real revision is coming 688 soon. 690 13. References 692 13.1. Normative References 694 [I-D.ietf-speermint-requirements] 695 Mule, J., "Requirements for SIP-based Session Peering", 696 draft-ietf-speermint-requirements-10 (work in progress), 697 October 2010. 699 [I-D.ietf-speermint-voipthreats] 700 Seedorf, J., Niccolini, S., Chen, E., and H. Scholz, 701 "Session Peering for Multimedia Interconnect (SPEERMINT) 702 Security Threats and Suggested Countermeasures", 703 draft-ietf-speermint-voipthreats-07 (work in progress), 704 January 2011. 706 [RFC1035] Mockapetris, P., "Domain names - implementation and 707 specification", STD 13, RFC 1035, November 1987. 709 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 710 E. Lear, "Address Allocation for Private Internets", 711 BCP 5, RFC 1918, February 1996. 713 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 714 A., Peterson, J., Sparks, R., Handley, M., and E. 715 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 716 June 2002. 718 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 719 Protocol (SIP): Locating SIP Servers", RFC 3263, 720 June 2002. 722 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 723 Jacobson, "RTP: A Transport Protocol for Real-Time 724 Applications", STD 64, RFC 3550, July 2003. 726 [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform 727 Resource Identifiers (URI) Dynamic Delegation Discovery 728 System (DDDS) Application (ENUM)", RFC 3761, April 2004. 730 [RFC3764] Peterson, J., "enumservice registration for Session 731 Initiation Protocol (SIP) Addresses-of-Record", RFC 3764, 732 April 2004. 734 [RFC3861] Peterson, J., "Address Resolution for Instant Messaging 735 and Presence", RFC 3861, August 2004. 737 [RFC3953] Peterson, J., "Telephone Number Mapping (ENUM) Service 738 Registration for Presence Services", RFC 3953, 739 January 2005. 741 [RFC5067] Lind, S. and P. Pfautz, "Infrastructure ENUM 742 Requirements", RFC 5067, November 2007. 744 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 745 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 747 [RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia 748 Interconnect (SPEERMINT) Terminology", RFC 5486, 749 March 2009. 751 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 752 "Transport Layer Security (TLS) Renegotiation Indication 753 Extension", RFC 5746, February 2010. 755 [RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, 756 A., and M. Bhatia, "Requirements from Session Initiation 757 Protocol (SIP) Session Border Control (SBC) Deployments", 758 RFC 5853, April 2010. 760 [RFC5878] Brown, M. and R. Housley, "Transport Layer Security (TLS) 761 Authorization Extensions", RFC 5878, May 2010. 763 [RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain 764 Certificates in the Session Initiation Protocol (SIP)", 765 RFC 5922, June 2010. 767 13.2. Informative References 769 [I-D.ietf-speermint-voip-consolidated-usecases] 770 Uzelac, A. and Y. Lee, "VoIP SIP Peering Use Cases", 771 draft-ietf-speermint-voip-consolidated-usecases-18 (work 772 in progress), April 2010. 774 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 775 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 776 RFC 3711, March 2004. 778 Authors' Addresses 780 Daryl Malas (editor) 781 CableLabs 782 Louisville, CO 783 US 785 Email: d.malas@cablelabs.com 787 Jason Livingood (editor) 788 Comcast 789 Philadelphia, PA 790 US 792 Email: Jason_Livingood@cable.comcast.com