idnits 2.17.1 draft-ietf-speermint-architecture-18.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 17, 2011) is 4814 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 21, 2011 Comcast 6 February 17, 2011 8 Session PEERing for Multimedia INTerconnect Architecture 9 draft-ietf-speermint-architecture-18 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 21, 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) . . . . . . . . . . . . . . 12 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. 470 6.1.3.3. Co-Location 472 In this scenario the SFs are co-located in a physically secure 473 location and/or are members of a segregated network. In this case 474 messages between the originating and terminating SSPs could be sent 475 as clear text (unencrypted). However, even in these semi-trusted co- 476 location facilities, other security or access control mechanisms may 477 be appropriate, such as IP access control lists or other mechanisms. 479 6.1.3.4. Sending the SIP Request 481 Once a trust relationship between the peers is established, the 482 originating (or indirect) SSP sends the request. 484 6.2. Target SSP Procedures 486 This section describes the Target SSP Procedures. 488 6.2.1. TLS 490 The section defines the usage of TLS between two SSPs [RFC5246] 491 [RFC5746] [RFC5878]. When the receiving SSP receives a TLS client 492 hello, it responds with its certificate. The Target SSP certificate 493 should be valid and rooted in a well-known certificate authority. 494 The procedures to authenticate the SSP's originating domain are 495 specified in [RFC5922]. 497 The SF of the Target SSP verifies that the Identity header is valid, 498 corresponds to the message, corresponds to the Identity-Info header, 499 and that the domain in the From header corresponds to one of the 500 domains in the TLS client certificate. 502 As noted above in Section 6.1.3.2, some deployments may utilize IPSec 503 rather than TLS. 505 6.2.2. Receive SIP Requests 507 Once a trust relationship is established, the Target SSP is prepared 508 to receive incoming SIP requests. For new requests (dialog forming 509 or not) the receiving SSP verifies if the target (request-URI) is a 510 domain that for which it is responsible. For these requests, there 511 should be no remaining Route header field values. For in-dialog 512 requests, the receiving SSP can verify that it corresponds to the 513 top-most Route header field value. 515 The receiving SSP may reject incoming requests due to local policy. 516 When a request is rejected because the originating (or indirect) SSP 517 is not authorized to peer, the receiving SSP should respond with a 518 403 response with the reason phrase "Unsupported Peer". 520 6.3. Data Path Border Element (DBE) 522 The purpose of the DBE [RFC5486] is to perform media related 523 functions such as media transcoding and media security implementation 524 between two SSPs. 526 An example of this is to transform a voice payload from one codec 527 (e.g., G.711) to another (e.g., EvRC). Additionally, the MF may 528 perform media relaying, media security [RFC3711], privacy, and 529 encryption. 531 7. Address Space Considerations 533 Peering must occur in a common IP address space, which is defined by 534 the federation, which may be entirely on the public Internet, or some 535 private address space [RFC1918]. The origination or termination 536 networks may or may not entirely be in the same address space. If 537 they are not, then a network address translation (NAT) or similar may 538 be needed before the signaling or media is presented correctly to the 539 federation. The only requirement is that all associated entities 540 across the peering interface are reachable. 542 8. Acknowledgments 544 The working group would like to thank John Elwell, Otmar Lendl, Rohan 545 Mahy, Alexander Mayrhofer, Jim McEachern, Jean-Francois Mule, 546 Jonathan Rosenberg, and Dan Wing for their valuable contributions to 547 various versions of this document. 549 9. IANA Considerations 551 This memo includes no request to IANA. 553 10. Security Considerations 555 The level (or types) of security mechanisms implemented between 556 peering providers is in practice dependent upon on the underlying 557 physical security of SSP connections. This means, as noted in 558 Section 6.1.3.3, whether peering equipment is in a secure facility or 559 not may bear on other types of security mechanisms which may be 560 appropriate. Thus, if two SSPs peered across public Internet links, 561 they are likely to use IPSec or TLS since the link between the two 562 domains should be considered untrusted. 564 Many detailed and highly relevant security requirements for SPEERMINT 565 have been documented in Section 5 of 566 [I-D.ietf-speermint-requirements]. As a result, that document should 567 be considered required reading. 569 Additional and important security considerations have been documented 570 separately in [I-D.ietf-speermint-voipthreats]. This document 571 describes the many relevant security threats to SPEERMINT, as well 572 the relevant countermeasures and security protections which are 573 recommended to combat any potential threats or other risks. This 574 includes a wide range of detailed threats in Section 2 of 575 [I-D.ietf-speermint-voipthreats]. It also includes key requirements 576 in Section 3.1 of [I-D.ietf-speermint-voipthreats], such as the 577 requirement for the LUF and LRF to support mutual authentication for 578 queries, among other requirements which are related to 579 [I-D.ietf-speermint-requirements]. Section 3.2 of 580 [I-D.ietf-speermint-voipthreats] explains how to meet these security 581 requirements, and then Section 4 explores a wide range of suggested 582 countermeasures. 584 11. Contributors 586 Mike Hammer 588 Cisco Systems 590 Herndon, VA - USA 592 Email: mhammer@cisco.com 594 -------------------------------------------------------------- 596 Hadriel Kaplan 598 Acme Packet 600 Burlington, MA - USA 602 Email: hkaplan@acmepacket.com 604 -------------------------------------------------------------- 606 Sohel Khan, Ph.D. 608 Comcast Cable 610 Philadelphia, PA - USA 612 Email: sohel_khan@cable.comcast.com 614 -------------------------------------------------------------- 616 Reinaldo Penno 617 Juniper Networks 619 Sunnyvale, CA - USA 621 Email: rpenno@juniper.net 623 -------------------------------------------------------------- 625 David Schwartz 627 XConnect Global Networks 629 Jerusalem - Israel 631 Email: dschwartz@xconnnect.net 633 -------------------------------------------------------------- 635 Rich Shockey 637 Shockey Consulting 639 USA 641 Email: Richard@shockey.us 643 -------------------------------------------------------------- 645 Adam Uzelac 647 Global Crossing 649 Rochester, NY - USA 651 Email: adam.uzelac@globalcrossing.com 653 12. Change Log 655 NOTE TO RFC EDITOR: PLEASE REMOVE THIS SECTION PRIOR TO PUBLICATION. 657 o 18: Made several changes based on feedback from Adrian Farrel, 658 Bert Wijnen, Dan Romascanu, Avshalom Houri, Russ Housley, Sean 659 Turner, Tim Polk, and Russ Mundy during IESG review. 661 o 17: Misc. updates at the request of Gonzalo, the RAI AD, in order 662 to clear his review and move to the IESG. This included adding 663 terminology from RFC 5486 and expanding the document name. 665 o 16: Yes, one final outdated reference to fix. 667 o 15: Doh! Uploaded the wrong doc to create -14. Trying again. :-) 669 o 14: WGLC ended. Ran final nits check prior to sending proto to 670 the AD and sending the doc to the IESG. Found a few very minor 671 nits, such as capitalization and replacement of an obsoleted RFC, 672 which were corrected per nits tool recommendation. The -14 now 673 moves to the AD and the IESG. 675 o 13: Closed out all remaining tickets, resolved all editorial 676 notes. 678 o 12: Closed out several open issues. Properly XML-ized all 679 references. Updated contributors list. 681 o 11: Quick update to refresh the I-D since it expired, and cleaned 682 up some of the XML for references. A real revision is coming 683 soon. 685 13. References 687 13.1. Normative References 689 [I-D.ietf-speermint-requirements] 690 Mule, J., "Requirements for SIP-based Session Peering", 691 draft-ietf-speermint-requirements-10 (work in progress), 692 October 2010. 694 [I-D.ietf-speermint-voipthreats] 695 Seedorf, J., Niccolini, S., Chen, E., and H. Scholz, 696 "Session Peering for Multimedia Interconnect (SPEERMINT) 697 Security Threats and Suggested Countermeasures", 698 draft-ietf-speermint-voipthreats-07 (work in progress), 699 January 2011. 701 [RFC1035] Mockapetris, P., "Domain names - implementation and 702 specification", STD 13, RFC 1035, November 1987. 704 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 705 E. Lear, "Address Allocation for Private Internets", 706 BCP 5, RFC 1918, February 1996. 708 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 709 A., Peterson, J., Sparks, R., Handley, M., and E. 710 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 711 June 2002. 713 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 714 Protocol (SIP): Locating SIP Servers", RFC 3263, 715 June 2002. 717 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 718 Jacobson, "RTP: A Transport Protocol for Real-Time 719 Applications", STD 64, RFC 3550, July 2003. 721 [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform 722 Resource Identifiers (URI) Dynamic Delegation Discovery 723 System (DDDS) Application (ENUM)", RFC 3761, April 2004. 725 [RFC3764] Peterson, J., "enumservice registration for Session 726 Initiation Protocol (SIP) Addresses-of-Record", RFC 3764, 727 April 2004. 729 [RFC3861] Peterson, J., "Address Resolution for Instant Messaging 730 and Presence", RFC 3861, August 2004. 732 [RFC3953] Peterson, J., "Telephone Number Mapping (ENUM) Service 733 Registration for Presence Services", RFC 3953, 734 January 2005. 736 [RFC5067] Lind, S. and P. Pfautz, "Infrastructure ENUM 737 Requirements", RFC 5067, November 2007. 739 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 740 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 742 [RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia 743 Interconnect (SPEERMINT) Terminology", RFC 5486, 744 March 2009. 746 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 747 "Transport Layer Security (TLS) Renegotiation Indication 748 Extension", RFC 5746, February 2010. 750 [RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, 751 A., and M. Bhatia, "Requirements from Session Initiation 752 Protocol (SIP) Session Border Control (SBC) Deployments", 753 RFC 5853, April 2010. 755 [RFC5878] Brown, M. and R. Housley, "Transport Layer Security (TLS) 756 Authorization Extensions", RFC 5878, May 2010. 758 [RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain 759 Certificates in the Session Initiation Protocol (SIP)", 760 RFC 5922, June 2010. 762 13.2. Informative References 764 [I-D.ietf-speermint-voip-consolidated-usecases] 765 Uzelac, A. and Y. Lee, "VoIP SIP Peering Use Cases", 766 draft-ietf-speermint-voip-consolidated-usecases-18 (work 767 in progress), April 2010. 769 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 770 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 771 RFC 3711, March 2004. 773 Authors' Addresses 775 Daryl Malas (editor) 776 CableLabs 777 Louisville, CO 778 US 780 Email: d.malas@cablelabs.com 782 Jason Livingood (editor) 783 Comcast 784 Philadelphia, PA 785 US 787 Email: Jason_Livingood@cable.comcast.com