idnits 2.17.1 draft-ietf-speermint-architecture-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 abstract seems to contain references ([RFC3261]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 283: '... enumservice as described in [RFC3764], but MAY check for other...' RFC 2119 keyword, line 284: '... originating SSP MAY consult a cache o...' RFC 2119 keyword, line 327: '...arget SSP's domain and MAY forward the...' 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 (March 9, 2010) is 5161 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-ietf-sip-domain-certs-05 == Outdated reference: A later version (-11) exists of draft-ietf-speermint-requirements-09 ** Obsolete normative reference: RFC 3761 (Obsoleted by RFC 6116, RFC 6117) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPEERMINT A. Uzelac, Ed. 3 Internet-Draft Global Crossing 4 Intended status: Informational R. Penno 5 Expires: September 10, 2010 Juniper Networks 6 M. Hammer 7 Cisco Systems 8 D. Malas 9 CableLabs 10 S. Khan 11 Comcast 12 H. Kaplan 13 Acme Packet 14 J. Livingood 15 Comcast 16 D. Schwartz 17 XConnect Global Networks 18 R. Shockey 19 Shockey Consulting 20 March 9, 2010 22 SPEERMINT Peering Architecture 23 draft-ietf-speermint-architecture-10 25 This document may contain material from IETF Documents or IETF 26 Contributions published or made publicly available before November 27 10, 2008. The person(s) controlling the copyright in some of this 28 material may not have granted the IETF Trust the right to allow 29 modifications of such material outside the IETF Standards Process. 30 Without obtaining an adequate license from the person(s) controlling 31 the copyright in such materials, this document may not be modified 32 outside the IETF Standards Process, and derivative works of it may 33 not be created outside the IETF Standards Process, except to format 34 it for publication as an RFC or to translate it into languages other 35 than English. 37 Abstract 39 This document defines a peering architecture for the Session 40 Initation Protocol (SIP) [RFC3261], it's functional components and 41 interfaces. It also describes the steps necessary to establish a 42 session between two peering domains in the context of the functions 43 defined. 45 Status of this Memo 47 This Internet-Draft is submitted to IETF in full conformance with the 48 provisions of BCP 78 and BCP 79. 50 Internet-Drafts are working documents of the Internet Engineering 51 Task Force (IETF), its areas, and its working groups. Note that 52 other groups may also distribute working documents as Internet- 53 Drafts. 55 Internet-Drafts are draft documents valid for a maximum of six months 56 and may be updated, replaced, or obsoleted by other documents at any 57 time. It is inappropriate to use Internet-Drafts as reference 58 material or to cite them other than as "work in progress." 60 The list of current Internet-Drafts can be accessed at 61 http://www.ietf.org/ietf/1id-abstracts.txt. 63 The list of Internet-Draft Shadow Directories can be accessed at 64 http://www.ietf.org/shadow.html. 66 This Internet-Draft will expire on September 10, 2010. 68 Copyright Notice 70 Copyright (c) 2010 IETF Trust and the persons identified as the 71 document authors. All rights reserved. 73 This document is subject to BCP 78 and the IETF Trust's Legal 74 Provisions Relating to IETF Documents 75 (http://trustee.ietf.org/license-info) in effect on the date of 76 publication of this document. Please review these documents 77 carefully, as they describe your rights and restrictions with respect 78 to this document. Code Components extracted from this document must 79 include Simplified BSD License text as described in Section 4.e of 80 the Trust Legal Provisions and are provided without warranty as 81 described in the BSD License. 83 Table of Contents 85 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 86 2. Reference Architecture . . . . . . . . . . . . . . . . . . . . 4 87 3. Procedures of Inter-domain SSP Session Establishment . . . . . 5 88 4. Relationships between functions/elements . . . . . . . . . . . 6 89 5. Recommended SSP Procedures . . . . . . . . . . . . . . . . . . 6 90 5.1. Originating SSP Procedures . . . . . . . . . . . . . . . . 7 91 5.1.1. The Look-Up Function (LUF) . . . . . . . . . . . . . . 7 92 5.1.1.1. Target Address Analysis . . . . . . . . . . . . . 7 93 5.1.1.2. ENUM Lookup . . . . . . . . . . . . . . . . . . . 7 94 5.1.2. Location Routing Function (LRF) . . . . . . . . . . . 8 95 5.1.2.1. DNS resolution . . . . . . . . . . . . . . . . . . 8 96 5.1.2.2. Routing Table . . . . . . . . . . . . . . . . . . 8 97 5.1.2.3. LRF to LRF Routing . . . . . . . . . . . . . . . . 8 98 5.1.3. Signaling Path Border Element (SBE) . . . . . . . . . 8 99 5.1.4. Establishing a Trusted Relationship . . . . . . . . . 9 100 5.1.4.1. IPSec . . . . . . . . . . . . . . . . . . . . . . 9 101 5.1.4.2. Co-Location . . . . . . . . . . . . . . . . . . . 9 102 5.1.4.3. Sending the SIP Request . . . . . . . . . . . . . 9 103 5.2. Target SSP Procedures . . . . . . . . . . . . . . . . . . 9 104 5.2.1. The Ingress SBE . . . . . . . . . . . . . . . . . . . 10 105 5.2.1.1. TLS . . . . . . . . . . . . . . . . . . . . . . . 10 106 5.2.1.2. Receive SIP Requests . . . . . . . . . . . . . . . 10 107 5.3. Data Path Border Element (DBE) . . . . . . . . . . . . . . 10 108 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 109 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 110 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 111 9. Normative References . . . . . . . . . . . . . . . . . . . . . 11 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 114 1. Introduction 116 The objective of this document is to define a reference peering 117 architecture in the context of session peering for multimedia 118 interconnects. In this process, we define the peering reference 119 architecture, its functional components, and peering interface 120 functions from the perspective of a SIP Service provider's (SSP) 121 [RFC5486] network. 123 This architecture allows the interconnection of two SSPs in layer 5 124 peering as defined in the SIP-based session peering requirements 125 [I-D.ietf-speermint-requirements]. 127 Layer 3 peering is outside the scope of this document. Hence, the 128 figures in this document focus on Layer 5 protocol functions and 129 elements. 131 This document uses terminology defined in the Session Peering for 132 Multimedia Interconnect Terminology document [RFC5486]. 134 2. Reference Architecture 136 Figure 1 depicts the architecture and logical functions that form 137 peering between two SSPs. The terms used in the diagram are expanded 138 here for reference: 140 o SBE - Signaling Path Border Element is described in Section 5.1.3 142 o LUF - Look-up Function is described in Section 5.1.1 144 o LRF - Location Routing Function is described in Section 5.1.2 146 o SF - Signaling Function is defined in [RFC5486] 148 o SIP - Session Initiation Protocol is defined in [RFC3261] 150 o DBE - Data Path Border Element is described in Section 5.3 152 o DNS - Domain Name Service is described in Section 5.1.2.1 154 o ENUM - E.164 Number Mapping is described in Section 5.1.1.2 156 o FQDN - Fully Qualified Domain Name 158 o TN DB - Telephone Number Database 159 o IP - IPv4/v6 Address 161 o RTP - Real-time Transport Protocol is defined in [RFC3550] 163 +=============++ ++==============+ 164 || || 165 +-----------+ +-----------+ 166 | SBE | | SBE | 167 | +-----+ | SIP +-----+ | +-----+ | 168 | | LUF |<-|------>|ENUM | | | LUF | | 169 | +-----+ | ENUM |TN DB| | +-----+ | 170 SIP | | +-----+ | | 171 ------>| +-----+ | DNS +-----+ | +-----+ | 172 | | LRF |<-|------>|FQDN | | | LRF | | 173 | +-----+ | |IP | | +-----+ | 174 | +-----+ | SIP +-----+ | +-----+ | 175 | | SF |<-|----------------|->| SF | | 176 | +-----+ | | +-----+ | 177 +-----------+ +-----------+ 178 || || 179 +-----------+ +-----------+ 180 RTP | DBE | RTP | DBE | 181 ------>| |--------------->| | 182 +-----------+ +-----------+ 183 || || 184 SSP1 Network || || SSP2 Network 185 +=============++ ++=============+ 187 Figure 1 189 For further details on the elements and functions described in this 190 figure, please refer to [RFC5486]. 192 3. Procedures of Inter-domain SSP Session Establishment 194 This document assumes that in order for a session to be established 195 from a User Agent (UA) in the Originating SSP's network to a UA in 196 the Target SSP's network the following steps are taken: 198 1. Determine the target SSP via the LUF. (Note: If the target 199 address represents a resource within the originating SSP, the 200 behavior is out-of-scope with respect to this draft.) 202 2. Determine the address of the SF of the target SSP via the LRF. 204 3. Establish the session 206 4. Exchange the media, which could include voice, video, text, etc. 208 5. End the session 210 The originating SSP would likely perform steps 1-4, and the target 211 SSP would likely perform steps 4-5. 213 If the target SSP is also an indirect peer, then steps 1-4 may be 214 repeated. This is reflected in Figure 1 that shows the target SSP 215 with its own peering functions. 217 4. Relationships between functions/elements 219 o An SBE can contain a SF function. 221 o An SF can perform LUF and LRF functions. 223 o As an additional consideration, in current Session Border 224 Controller (SBC) implementations, an SBC can contain an SF, SBE 225 and DBE, and may perform the LUF and LRF functions. 227 o The following functions can communicate as follows, depending upon 228 various real-world implementations: 230 * SF can communicate with LUF, LRF and another SF 232 * LUF can communicate with SF 234 * LRF can communicate with SF 236 5. Recommended SSP Procedures 238 This section describes the functions in more detail and provides some 239 recommendations on the role they would play in an example SIP 240 telephony call scenario. 242 Some of the information in the section is taken from 243 [I-D.ietf-speermint-requirements] and is put here for continuity 244 purposes. 246 5.1. Originating SSP Procedures 248 5.1.1. The Look-Up Function (LUF) 250 Purpose is to determine the SF of the target domain of a given 251 request and optionally develop Session Establishment Data. 253 5.1.1.1. Target Address Analysis 255 When the originating SSP receives a SIP request, it analyzes the 256 target URI to determine whether the call needs to be routed internal 257 or external to its network. 259 If the target address does not represent a resource inside the 260 originating SSP's administrative domain, then the originating SSP 261 performs a Lookup (LUF) to determine the target domain, and then it 262 resolves the call routing data by using Location Routing (LRF). 264 For example, if the request to communicate is for an im: or pres: URI 265 type, the originating SSP follows the procedures in [RFC3861]. If 266 the highest priority supported URI scheme is sip: or sips: the 267 originating SSP skips to SIP DNS resolution. Likewise, if the target 268 address is already a sip: or sips: URI in an external domain, the 269 originating SSP skips to SIP DNS resolution in Section 5.1.2.1 271 If the target address corresponds to a specific E.164 address, the 272 SSP may need to perform some form of number plan mapping according to 273 local policy. For example, in the United States, a dial string 274 beginning "011 44" could be converted to "+44", or in the United 275 Kingdom "00 1" could be converted to "+1". Once the SSP has an E.164 276 address, it can use ENUM. 278 5.1.1.2. ENUM Lookup 280 If an external E.164 address is the target, the originating SSP 281 consults a private or public ENUM server, according to the procedures 282 described in [RFC3761]. The SSP must query for the "E2U+sip" 283 enumservice as described in [RFC3764], but MAY check for other 284 enumservices. The originating SSP MAY consult a cache or alternate 285 representation of the ENUM data rather than actual DNS queries. 286 Also, the SSP may skip actual DNS queries if the target domain is 287 represented as an IPv4/v6 address. 289 If an im: or pres: URI is chosen for based on an "E2U+im" [RFC3861] 290 or "E2U+pres" [RFC3953] enumserver, the SSP follows the procedures 291 for resolving these URIs to URIs for specific protocols such a SIP or 292 XMPP. 294 5.1.2. Location Routing Function (LRF) 296 The LRF of an Originating SSP analyzes the target address and target 297 domain identified by the LUF, and discovers the next hop signaling 298 function (SF) in a peering relationship. The resource to determine 299 the SF of the target domain might be provided by a third-party as in 300 the indirect peering case. The following sections define mechanisms 301 which may be used by the LRF. These are not in any particular order 302 and, importantly, not all of them may be used. 304 5.1.2.1. DNS resolution 306 The originating SSP uses the procedures in [RFC3263] to determine how 307 to contact the target SSP. To summarize the RFC 3263 procedure: 308 unless these are explicitly encoded in the target URI, a transport is 309 chosen using Naming Authority Pointer (NAPTR) records, a port is 310 chosen using SRV records, and an address is chosen using A or AAAA 311 records. 313 When communicating with another SSP, entities compliant to this 314 document should select a TLS-protected transport for communication 315 from the Originating SSP to the target SSP if available. 317 5.1.2.2. Routing Table 319 If there are no End User ENUM records and the Originating SSP cannot 320 discover the carrier-of-record or if the Originating SSP cannot reach 321 the carrier-of-record via SIP peering, the Originating SSP may 322 deliver the call to the PSTN or reject it. Note that the originating 323 SSP may forward the call to another SSP for PSTN gateway termination 324 by prior arrangement using the routing table. 326 If so, the originating SSP rewrites the Request-URI to address the 327 gateway resource in the target SSP's domain and MAY forward the 328 request on to that SSP using the procedures described in the 329 remainder of these steps. 331 5.1.2.3. LRF to LRF Routing 333 Communication between the LRF of two interconnecting SSPs may use DNS 334 or statically provisioned IP Addresses for reachability. Other 335 inputs to determine the path may be code-based routing, method-based 336 routing, Time of day, least cost and/or source-based routing. 338 5.1.3. Signaling Path Border Element (SBE) 340 The purpose of signaling path border element is to perform routing of 341 SIP messages as well as optionally implement security and policies on 342 SIP messages, and to assist in discovery/exchange of parameters to be 343 used by the Media Function (MF). 345 The signaling function performs the routing of SIP messages. The 346 optional termination and re-initiation of calls may be performed by 347 the signaling path Session Border Element (SBE), or other signaling 348 elements. 350 Optionally, the SF of a SBE may perform additional functions such as 351 Session Admission Control, SIP Denial of Service protection, SIP 352 Topology Hiding, SIP header normalization, SIP security, privacy, and 353 encryption. 355 The SF of a SBE can also process SDP payloads for media information 356 such as media type, bandwidth, and type of codec; then, communicate 357 this information to the media function. Signaling function may 358 optionally communicate with the network to pass Layer 3 related 359 policies. 361 5.1.4. Establishing a Trusted Relationship 363 Depending on the security needs and trust relationships between SSPs, 364 different security mechanism can be used to establish SIP calls. 365 These are discussed in the following subsections. 367 5.1.4.1. IPSec 369 In certain deployments the use of IPSec between the signaling 370 functions of the originating and terminating domains can be used as a 371 security mechanism instead of TLS. 373 5.1.4.2. Co-Location 375 In this scenario the SFs are co-located in a physically secure 376 location and/or are members of a segregated network. In this case 377 messages between the originating and terminating SSPs would be sent 378 as clear text. 380 5.1.4.3. Sending the SIP Request 382 Once a trust relationship between the peers is established, the 383 originating SSP sends the request. 385 5.2. Target SSP Procedures 386 5.2.1. The Ingress SBE 388 5.2.1.1. TLS 390 When the target SSP receives a TLS client hello, it responds with its 391 certificate. The Originating SSP certificate should be valid and 392 rooted in a well-known certificate authority. The procedures to 393 authenticate the SSP's originating domain are specified in 394 [I-D.ietf-sip-domain-certs]. 396 The SF of the Target SSP verifies that the Identity header is valid, 397 corresponds to the message, corresponds to the Identity-Info header, 398 and that the domain in the From header corresponds to one of the 399 domains in the TLS client certificate. 401 5.2.1.2. Receive SIP Requests 403 Once a trust relationship is established, the Target SSP is prepared 404 to receive incoming SIP requests. For new requests (dialog forming 405 or not) the receiving SSP verifies if the target (request-URI) is a 406 domain for which it is responsible. For these requests, there should 407 be no remaining Route header field values. For in-dialog requests, 408 the receiving SSP can verify that it corresponds to the top-most 409 Route header field value. 411 The receiving SSP may reject incoming requests due to local policy. 412 When a request is rejected because the originating SSP is not 413 authorized to peer, the receiving SSP should respond with a 403 414 response with the reason phrase "Unsupported Peer". 416 5.3. Data Path Border Element (DBE) 418 The purpose of the DBE [RFC5486] is to perform media related 419 functions such as media transcoding and media security implementation 420 between two SSPs. 422 An Example of this is to transform a voice payload from one codec 423 (e.g., G.711) to another (e.g., Enhanced Variable Rate Codec (EvRC)). 424 Additionally, the MF may perform media relaying, media security, 425 privacy, and encryption. 427 6. Acknowledgments 429 The working group thanks Sohel Khan for his initial architecture 430 draft that helped to initiate work on this draft. 432 Other contributors include Rohan Mahy, Otmar Lendl, Jim McEachern and 433 John Elwell for detailed comments and feedback. 435 7. IANA Considerations 437 This memo includes no request to IANA. 439 8. Security Considerations 441 In all cases, cryptographic-based security should be maintained as an 442 optional requirement between peering providers conditioned on the 443 presence or absence of underlying physical security of SSP 444 connections, e.g. within the same secure physical building. 446 In order to maintain a consistent approach, unique and specialized 447 security requirements common for the majority of peering 448 relationships, should be standardized within the IETF. These 449 standardized methods may enable capabilities such as dynamic peering 450 relationships across publicly maintained interconnections. 452 9. Normative References 454 [I-D.ietf-sip-domain-certs] 455 Gurbani, V., Lawrence, S., and B. Laboratories, "Domain 456 Certificates in the Session Initiation Protocol (SIP)", 457 draft-ietf-sip-domain-certs-05 (work in progress), 458 March 2010. 460 [I-D.ietf-speermint-requirements] 461 Mule, J., "SPEERMINT Requirements for SIP-based Session 462 Peering", draft-ietf-speermint-requirements-09 (work in 463 progress), October 2009. 465 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 466 A., Peterson, J., Sparks, R., Handley, M., and E. 467 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 468 June 2002. 470 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 471 Protocol (SIP): Locating SIP Servers", RFC 3263, 472 June 2002. 474 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 475 Jacobson, "RTP: A Transport Protocol for Real-Time 476 Applications", STD 64, RFC 3550, July 2003. 478 [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform 479 Resource Identifiers (URI) Dynamic Delegation Discovery 480 System (DDDS) Application (ENUM)", RFC 3761, April 2004. 482 [RFC3764] Peterson, J., "enumservice registration for Session 483 Initiation Protocol (SIP) Addresses-of-Record", RFC 3764, 484 April 2004. 486 [RFC3861] Peterson, J., "Address Resolution for Instant Messaging 487 and Presence", RFC 3861, August 2004. 489 [RFC3953] Peterson, J., "Telephone Number Mapping (ENUM) Service 490 Registration for Presence Services", RFC 3953, 491 January 2005. 493 [RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia 494 Interconnect (SPEERMINT) Terminology", RFC 5486, 495 March 2009. 497 Authors' Addresses 499 Adam Uzelac (editor) 500 Global Crossing 501 Rochester, NY 502 US 504 Email: adam.uzelac@globalcrossing.com 506 Reinadlo Penno 507 Juniper Networks 508 Sunnyvale, CA 509 US 511 Email: rpenno@juniper.net 513 Mike Hammer 514 Cisco Systems 515 Herndon, VA 516 US 518 Email: mhammer@cisco.com 519 Daryl Malas 520 CableLabs 521 Louisville, CO 522 US 524 Email: d.malas@cablelabs.com 526 Sohel Khan 527 Comcast 528 Philadelphia, PA 529 US 531 Email: sohel_khan@cable.comcast.com 533 Hadriel Kaplan 534 Acme Packet 535 Burlington, MA 536 US 538 Email: hkaplan@acmepacket.com 540 Jason Livingood 541 Comcast 542 Philadelphia, PA 543 US 545 Email: Jason_Livingood@cable.comcast.com 547 David Schwartz 548 XConnect Global Networks 549 Jerusalem 550 Israel 552 Email: dschwartz@xconnnect.net 554 Richard Shockey 555 Shockey Consulting 556 US 558 Email: Richard@shockey.us