idnits 2.17.1 draft-ietf-p2psip-sip-09.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 == Line 279 has weird spacing: '...ionType type...' == Line 281 has weird spacing: '...ionData data...' -- 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 25, 2013) is 4070 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-Posix' == Outdated reference: A later version (-09) exists of draft-ietf-p2psip-concepts-04 == Outdated reference: A later version (-10) exists of draft-ietf-p2psip-share-01 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 P2PSIP C. Jennings 3 Internet-Draft Cisco 4 Intended status: Standards Track B. Lowekamp 5 Expires: August 29, 2013 Skype 6 E. Rescorla 7 RTFM, Inc. 8 S. Baset 9 H. Schulzrinne 10 Columbia University 11 T C. Schmidt, Ed. 12 HAW Hamburg 13 February 25, 2013 15 A SIP Usage for RELOAD 16 draft-ietf-p2psip-sip-09 18 Abstract 20 This document defines a SIP Usage for REsource LOcation And Discovery 21 (RELOAD). The SIP Usage provides the functionality of a SIP proxy or 22 registrar in a fully-distributed system and includes a lookup service 23 for Address of Records (AORs) stored in the overlay. It also defines 24 Globally Routable User Agent Uris (GRUUs) that allow the 25 registrations to map an AOR to a specific node reachable through the 26 overlay. After such initial contact of a peer, the AppAttach method 27 is used to establish a direct connection between nodes through which 28 SIP messages are exchanged. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on August 29, 2013. 47 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 3. Registering AORs in the Overlay . . . . . . . . . . . . . . . 6 78 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6 79 3.2. Data Structure . . . . . . . . . . . . . . . . . . . . . . 7 80 3.3. Access Control . . . . . . . . . . . . . . . . . . . . . . 9 81 3.4. Overlay Configuration Document Extension . . . . . . . . . 9 82 4. Looking up an AOR . . . . . . . . . . . . . . . . . . . . . . 11 83 4.1. Finding a Route to an AOR . . . . . . . . . . . . . . . . 11 84 4.2. Resolving an AOR . . . . . . . . . . . . . . . . . . . . . 11 85 5. Forming a Direct Connection . . . . . . . . . . . . . . . . . 11 86 6. Using GRUUs . . . . . . . . . . . . . . . . . . . . . . . . . 12 87 7. SIP-REGISTRATION Kind Definition . . . . . . . . . . . . . . . 13 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 89 8.1. RELOAD-Specific Issues . . . . . . . . . . . . . . . . . . 13 90 8.2. SIP-Specific Issues . . . . . . . . . . . . . . . . . . . 14 91 8.2.1. Fork Explosion . . . . . . . . . . . . . . . . . . . . 14 92 8.2.2. Malicious Retargeting . . . . . . . . . . . . . . . . 14 93 8.2.3. Misuse of AORs . . . . . . . . . . . . . . . . . . . . 14 94 8.2.4. Privacy Issues . . . . . . . . . . . . . . . . . . . . 14 95 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 96 9.1. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . . 15 97 9.2. XML Name Space Registration . . . . . . . . . . . . . . . 15 98 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 99 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 100 11.1. Normative References . . . . . . . . . . . . . . . . . . . 15 101 11.2. Informative References . . . . . . . . . . . . . . . . . . 16 102 Appendix A. Third Party Registration . . . . . . . . . . . . . . 17 103 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 17 104 B.1. Changes since draft-ietf-p2psip-sip-08 . . . . . . . . . . 17 105 B.2. Changes since draft-ietf-p2psip-sip-07 . . . . . . . . . . 17 106 B.3. Changes since draft-ietf-p2psip-sip-06 . . . . . . . . . . 17 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 109 1. Introduction 111 The REsource LOcation And Discovery (RELOAD) [I-D.ietf-p2psip-base] 112 specifies a peer-to-peer (P2P) signaling protocol for the general use 113 on the Internet. This document defines a SIP Usage of RELOAD that 114 allows SIP [RFC3261] user agents (UAs) to establish peer-to-peer SIP 115 (or SIPS) sessions without the requirement for permanent proxy or 116 registration servers, e.g., a fully distributed telephony service. 117 In such a network, the RELOAD overlay itself performs the 118 registration and rendezvous functions ordinarily associated with such 119 servers. 121 The SIP Usage involves two basic functions. 123 Registration: SIP UAs can use the RELOAD data storage functionality 124 to store a mapping from their address-of-record (AOR) to their 125 Node-ID in the overlay, and to retrieve the Node-ID of other UAs. 126 Rendezvous: Once a SIP UA has identified the Node-ID for an AOR it 127 wishes to call, it can use the RELOAD message routing system to 128 set up a direct connection for exchanging SIP messages. 130 Mappings are stored in the SipRegistration Resource Record defined in 131 this document. All operations required to perform a SIP registration 132 or rendezvous are standard RELOAD protocol methods. 134 For example, Bob registers his AOR, "bob@dht.example.com", for his 135 Node-ID "1234". When Alice wants to call Bob, she queries the 136 overlay for "bob@dht.example.com" and receives Node-ID 1234 in 137 return. She then uses the overlay routing to establish a direct 138 connection with Bob and can directly transmit a standard SIP INVITE. 139 In detail, this works along the following steps. 141 1. Bob, operating Node-ID 1234, stores a mapping from his AOR to his 142 Node-ID in the overlay by applying a Store request for 143 "bob@dht.example.com -> 1234". 144 2. Alice, operating Node-ID 5678, decides to call Bob. She retrieves 145 Node-ID "1234" by performing a Fetch request on 146 "bob@dht.example.com". 147 3. Alice uses the overlay to route an AppAttach message to Bob's 148 peer (ID 1234). Bob responds with his own AppAttach and they set 149 up a direct connection, as shown in Figure 1. Note that mutual 150 ICE checks are invoked automatically from AppAttach message 151 exchange. 153 Overlay 154 Alice Peer1 ... PeerN Bob 155 (5678) (1234) 156 ------------------------------------------------- 157 AppAttach -> 158 AppAttach -> 159 AppAttach -> 160 AppAttach -> 161 <- AppAttach 162 <- AppAttach 163 <- AppAttach 164 <- AppAttach 166 <------------------ ICE Checks -----------------> 167 INVITE -----------------------------------------> 168 <--------------------------------------------- OK 169 ACK --------------------------------------------> 170 <------------ ICE Checks for media -------------> 171 <-------------------- RTP ----------------------> 173 Figure 1: Connection setup in P2P SIP using the RELOAD overlay 175 It is important to note that here the only role of RELOAD is to set 176 up the direct SIP connection between Alice and Bob. As soon as the 177 ICE checks complete and the connection is established, ordinary SIP 178 or SIPS is used. In particular, the establishment of the media 179 channel for a phone call happens via the usual SIP mechanisms, and 180 RELOAD is not involved. Media never traverses the overlay. After 181 the successful exchange of SIP messages, call peers run ICE 182 connectivity checks for media. 184 In addition to mappings from AORs to Node-IDs, the SIP Usage also 185 allows mappings from AORs to other AORs. This enables an indirection 186 useful for call forwarding. For instance, if Bob wants his phone 187 calls temporarily forwarded to Charlie, he can store the mapping 188 "bob@dht.example.com -> charlie@dht.example.com". When Alice wants 189 to call Bob, she retrieves this mapping and can then fetch Charlie's 190 AOR to retrieve his Node-ID. These mechanisms are described in 191 Section 3. 193 Alternatively, Globally Routable User Agent URIs (GRUUs) can be used 194 for directly accessing peers. They are handled via a separate 195 mechanism, as described in Section 6. 197 The SIP Usage for RELOAD addresses a fully distributed deployment of 198 session-based services among overlay peers. Two opposite scenarios 199 of deploying P2P SIP services are in the focus of this document: A 200 highly regulated environment of a "single provider" that admits 201 parties using AORs with domains from controlled namespace(s), only, 202 and an open, multi-party infrastructure that liberally allows a 203 registration and rendezvous for various or any domain namespace. It 204 is noteworthy in this context that - in contrast to regular SIP - 205 domain names play no role in routing to a proxy server. Once 206 connectivity to an overlay is given, any name registration can be 207 technically processed. 209 2. Terminology 211 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 212 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 213 document are to be interpreted as described in RFC 2119 [RFC2119]. 215 We use the terminology and definitions from Concepts and Terminology 216 for Peer to Peer SIP [I-D.ietf-p2psip-concepts] and the RELOAD Base 217 Protocol [I-D.ietf-p2psip-base] extensively in this document. 219 In addition, term definitions from SIP [RFC3261] apply to this memo. 220 The term AOR is the SIP "Address of Record" used to identify a user 221 in SIP. For example, alice@example.com could be the AOR for Alice. 222 For the purposes of this specification, an AOR is considered not to 223 include the scheme (e.g sip:) as the AOR needs to match the 224 rfc822Name in the X509v3 certificates. It is worth noting that SIP 225 and SIPS are distinguished in P2PSIP by the Application-ID. 227 3. Registering AORs in the Overlay 229 3.1. Overview 231 In ordinary SIP, a UA registers its AOR and location with a 232 registrar. In RELOAD, this registrar function is provided by the 233 overlay as a whole. To register its location, a RELOAD peer stores a 234 SipRegistration Resource Record under its own AOR using the SIP- 235 REGISTRATION Kind, which is formally defined in Section 7. A RELOAD 236 overlay MAY restrict the storage of AORs. Namespaces (i.e., the 237 right hand side of the AOR) that are supported for registration and 238 lookup can be configured for each RELOAD deployment as described in 239 Section 3.4. 241 As a simple example, consider Alice with AOR "alice@dht.example.org" 242 at Node-ID "1234". She might store the mapping 243 "alice@dht.example.org -> 1234" telling anyone who wants to call her 244 to contact node "1234". 246 RELOAD peers MAY store two kinds of SIP mappings, 248 o from an AOR to a destination list (a single Node-ID is just a 249 trivial destination list), or 250 o from an AOR to another AOR. 252 The meaning of the first kind of mapping is "in order to contact me, 253 form a connection with this peer." The meaning of the second kind of 254 mapping is "in order to contact me, dereference this AOR". The 255 latter allows for forwarding. For instance, if Alice wants her calls 256 to be forwarded to her secretary, Sam, she might insert the following 257 mapping "alice@dht.example.org -> sam@dht.example.org". 259 3.2. Data Structure 261 This section defines the SipRegistration Resource Record as follows: 263 enum { sip_registration_uri(1), sip_registration_route(2), 264 (255) } SipRegistrationType; 266 select (SipRegistration.type) { 267 case sip_registration_uri: 268 opaque uri<0..2^16-1>; 270 case sip_registration_route: 271 opaque contact_prefs<0..2^16-1>; 272 Destination destination_list<0..2^16-1>; 274 /* This type can be extended */ 276 } SipRegistrationData; 278 struct { 279 SipRegistrationType type; 280 uint16 length; 281 SipRegistrationData data; 282 } SipRegistration; 284 The contents of the SipRegistration Resource Record are: 286 type 287 the type of the registration 289 length 290 the length of the rest of the PDU 292 data 293 the registration data 295 o If the registration is of type "sip_registration_uri", then the 296 contents are an opaque string containing the URI. 297 o If the registration is of type "sip_registration_route", then the 298 contents are an opaque string containing the callee's contact 299 preferences and a destination list for the peer. 301 The encoding of contact_prefs - the callee's contact preferences - 302 follows the media feature set syntax of [RFC2533] (see also 303 [RFC2738]). As an example, a voicemail server that is a UA that 304 supports audio and video media types and is not mobile would carry 305 the following feature set description in its contact_prefs attribute: 307 (& (sip.audio=TRUE) 308 (sip.video=TRUE) 309 (sip.actor=msg-taker) 310 (sip.automata=TRUE) 311 (sip.mobility=fixed) 312 (| (sip.methods=INVITE) (sip.methods=BYE) (sip.methods=OPTIONS) 313 (sip.methods=ACK) (sip.methods=CANCEL))) 315 A callee MAY indicate that it prefers contact via a particular SIP 316 scheme - SIP or SIPS - by using one of the following contact_prefs 317 attribute: 319 (sip.schemes=SIP) 320 (sip.schemes=SIPS) 322 RELOAD explicitly supports multiple registrations for a single AOR. 323 The registrations are stored in a Dictionary with Node-IDs as the 324 dictionary keys. Consider, for instance, the case where Alice has 325 two peers: 327 o her desk phone (1234) 328 o her cell phone (5678) 330 Alice might store the following in the overlay at resource 331 "alice@dht.example.com". 333 o A SipRegistration of type "sip_registration_route" with dictionary 334 key "1234" and value "1234". 335 o A SipRegistration of type "sip_registration_route" with dictionary 336 key "5678" and value "5678". 338 Note that this structure explicitly allows one Node-ID to forward to 339 another Node-ID. For instance, Alice could set calls to her desk 340 phone to ring at her cell phone by storing a SipRegistration of type 341 "sip_registration_route" with dictionary key "1234" and value "5678". 343 3.3. Access Control 345 In order to prevent hijacking or other misuse, registrations are 346 subject to access control rules. Two kinds of restrictions apply: 348 o A Store is permitted only for AORs with domain names that fall 349 into the namespaces supported by the RELOAD overlay instance. 350 o Storing requests are performed according to the USER-NODE-MATCH 351 access control policy of RELOAD. 353 Before issuing a Store request to the overlay, any peer SHOULD verify 354 that the AOR of the request is a valid Resource Name with respect to 355 its domain name and the namespaces defined in the overlay 356 configuration document (see Section 3.4). 358 Before a Store is permitted, the storing peer MUST check that: 360 o The AOR of the request is a valid Resource Name with respect to 361 the namespaces defined in the overlay configuration document. 362 o The certificate contains a username that is a SIP AOR which hashes 363 to the Resource-ID it is being stored at. 364 o The certificate contains a Node-ID that is the same as the 365 dictionary key it is being stored at. 367 Note that these rules permit Alice to forward calls to Bob without 368 his permission. However, they do not permit Alice to forward Bob's 369 calls to her. See Section 8.2.2 for additional descriptions. 371 3.4. Overlay Configuration Document Extension 373 The use of a SIP-enabled overlay MAY be restricted to users with AORs 374 from specific domains. When deploying an overlay service, providers 375 can decide about these use case scenarios by defining a set of 376 namespaces for admissible domain names. This section extends the 377 overlay configuration document by defining new elements for patterns 378 that describe a corresponding domain name syntax. 380 A RELOAD overlay can be configured to accept store requests for any 381 AOR, or to apply domain name restrictions. For the latter, an 382 enumeration of admissible domain names including wildcarded name 383 patterns of the following form MAY be configured. 385 Example of Domain Patterns: 386 dht\.example\.com 387 .*\.my\.name 389 In this example, any AOR will be accepted that is either of the form 390 @dht.example.com, or ends with the domain "my.name". When 391 restrictions apply and in the absence of domain patterns, the default 392 behavior is to accept only AORs that exactly match the domain name of 393 the overlay. Otherwise, i.e., when restrictions are not configured 394 (attribute enable not set), the default behavior is to accept any 395 AOR. In the absence of a element, implementors 396 SHOULD assume this default value. Encoding of the domain name 397 complies to the restricted ASCII character set without character 398 escaping as defined in Section 19.1 of [RFC3261]. 400 The element serves as a container for zero to 401 multiple sub-elements. A element MAY be present 402 if the "enable" attribute of its parent element is set to true. Each 403 element defines a pattern for constructing admissible 404 resource names. It is of type xsd:string and interpreted as a 405 regular expression according to "POSIX Extended Regular Expression" 406 (see the specifications in [IEEE-Posix]). 408 The Relax NG Grammar for the AOR Domain Restriction reads: 410 412 namespace sip = "urn:ietf:params:xml:ns:p2p:config-base:sip" 414 416 Kind-parameter &= element sip:domain-restriction { 418 attribute enable { xsd:boolean } 420 422 element pattern { xsd:string }* 423 }? 425 4. Looking up an AOR 427 4.1. Finding a Route to an AOR 429 A RELOAD user, member of an overlay, who wishes to call another user 430 with given AOR SHALL proceed in the following way. 432 AOR is GRUU? If the AOR is a GRUU for this overlay, the callee can 433 be contacted directly as described in Section 6. 434 AOR domain is hosted in overlay? If the domain part of the AOR 435 matches a domain pattern configured in the overlay, the user can 436 continue to resolve the AOR in this overlay. The user MAY choose 437 to query the DNS service records to search for additional support 438 of this domain name. 439 AOR domain not supported by overlay? If the domain part of the AOR 440 is not supported in the current overlay, the user SHOULD query the 441 DNS (or other discovery services at hand) to search for an 442 alternative overlay that services the AOR under request. 443 Alternatively, standard SIP procedures for contacting the callee 444 SHOULD be used. 445 AOR inaccessible? If all of the above contact attempts fail, the 446 call fails. 448 The procedures described above likewise apply when nodes are 449 simultaneously connected to several overlays. 451 4.2. Resolving an AOR 453 A RELOAD user that has discovered a route to an AOR in the current 454 overlay SHALL execute the following steps. 456 1. Perform a Fetch for Kind SIP-REGISTRATION at the Resource-ID 457 corresponding to the AOR. This Fetch SHOULD NOT indicate any 458 dictionary keys, so that it will fetch all the stored values. 459 2. If any of the results of the Fetch are non-GRUU AORs, then repeat 460 step 1 for that AOR. 461 3. Once only GRUUs and destination lists remain, the peer removes 462 duplicate destination lists and GRUUs from the list and initiates 463 SIP or SIPS connections to the appropriate peers as described in 464 the following sections. If there are also external AORs, the 465 peer follows the appropriate procedure for contacting them as 466 well. 468 5. Forming a Direct Connection 470 Once the peer has translated the AOR into a set of destination lists, 471 it then uses the overlay to route AppAttach messages to each of those 472 peers. The "application" field MUST be either 5060 to indicate SIP 473 or 5061 for using SIPS. If certificate-based authentication is in 474 use, the responding peer MUST present a certificate with a Node-ID 475 matching the terminal entry in the route list. Note that it is 476 possible that the peers already have a RELOAD connection mutually 477 established. This MUST NOT be used for SIP messages unless it is a 478 SIP connection. A previously established SIP connection MAY be used 479 for a new call. 481 Once the AppAttach succeeds, the peer sends plain or (D)TLS encrypted 482 SIP messages over the connection as in normal SIP. A caller MAY 483 choose to contact the callee using SIP or secure SIPS, but SHOULD 484 follow a preference indicated by the callee in its contact_prefs 485 attribute (see Section 3.2). A callee MAY choose to listen on both 486 SIP and SIPS ports and accept calls from either SIP scheme, or select 487 a single one. However, a callee that decides to accept SIPS calls, 488 only, SHOULD indicate its choice by setting the corresponding 489 attribute in its contact_prefs. 491 6. Using GRUUs 493 Globally Routable User Agent Uris (GRUUs) [RFC5627] have been 494 designed to allow direct routing without the indirection of a SIP 495 proxy function. The concept is transferred to RELOAD overlays as 496 follows. GRUUs in RELOAD are constructed by embedding a base64- 497 encoded destination list in the gr URI parameter of the GRUU. The 498 base64 encoding is done with the alphabet specified in table 1 of 499 [RFC4648] with the exception that ~ is used in place of =. 500 Example of a RELOAD GRUU: 501 alice@example.com;gr=MDEyMzQ1Njc4OTAxMjM0NTY3ODk~ 503 GRUUs do not require to store data in the Overlay Instance. Rather 504 when a peer needs to route a message to a GRUU in the same P2P 505 overlay, it simply uses the destination list and connects to that 506 peer. Because a GRUU contains a destination list, it MAY have the 507 same contents as a destination list stored elsewhere in the resource 508 dictionary. 510 Anonymous GRUUs [RFC5767] are constructed analogously, but require 511 either that the enrollment server issues a different Node-ID for each 512 anonymous GRUU required, or that a destination list be used that 513 includes a peer that compresses the destination list to stop the 514 Node-ID from being revealed. 516 7. SIP-REGISTRATION Kind Definition 518 This section defines the SIP-REGISTRATION Kind. 520 Name SIP-REGISTRATION 522 Kind IDs The Resource Name for the SIP-REGISTRATION Kind-ID is the 523 AOR of the user. The data stored is a SipRegistration, which can 524 contain either another URI or a destination list to the peer which 525 is acting for the user. 527 Data Model The data model for the SIP-REGISTRATION Kind-ID is 528 dictionary. The dictionary key is the Node-ID of the storing 529 peer. This allows each peer (presumably corresponding to a single 530 device) to store a single route mapping. 532 Access Control USER-NODE-MATCH. Note that this matches the SIP AOR 533 against the rfc822Name in the X509v3 certificate. The rfc822Name 534 does not include the scheme so that the "sip:" prefix needs to be 535 removed from the SIP AOR before matching. 537 Data stored under the SIP-REGISTRATION Kind is of type 538 SipRegistration. This comes in two varieties: 540 sip_registration_uri 541 a URI which the user can be reached at. 543 sip_registration_route 544 a destination list which can be used to reach the user's peer. 546 8. Security Considerations 548 8.1. RELOAD-Specific Issues 550 This Usage for RELOAD does not define new protocol elements or 551 operations. Hence no new threats arrive from message exchanges in 552 RELOAD. 554 This document introduces an AOR domain restriction function that must 555 be surveyed by the storing peer. A misconfigured or malicious peer 556 could cause frequent rejects of illegitimate storing requests. 557 However, domain name control relies on a lightweight pattern matching 558 and can be processed prior to validating certificates. Hence no 559 extra burden is introduced for RELOAD peers beyond loads already 560 present in the base protocol. 562 8.2. SIP-Specific Issues 564 8.2.1. Fork Explosion 566 Because SIP includes a forking capability (the ability to retarget to 567 multiple recipients), fork bombs are a potential DoS concern. 568 However, in the SIP usage of RELOAD, fork bombs are a much lower 569 concern than in a conventional SIP Proxy infrastructure, because the 570 calling party is involved in each retargeting event. It can 571 therefore directly measure the number of forks and throttle at some 572 reasonable number. 574 8.2.2. Malicious Retargeting 576 Another potential DoS attack is for the owner of an attractive AOR to 577 retarget all calls to some victim. This attack is common to SIP and 578 difficult to ameliorate without requiring the target of a SIP 579 registration to authorize all stores. The overhead of that 580 requirement would be excessive and in addition there are good use 581 cases for retargeting to a peer without its explicit cooperation. 583 8.2.3. Misuse of AORs 585 A RELOAD overlay and enrollment service that liberally accept 586 registrations for AORs of domain names unrelated to the overlay 587 instance and without further justification, eventually store presence 588 state for misused AORs. An attacker could hijack names, register a 589 bogus presence and attract calls dedicated to a victim that resides 590 within or outside the Overlay Instance. 592 A hijacking of AORs can be mitigated by restricting the name spaces 593 admissible in the Overlay Instance, or by additional verification 594 actions of the enrollment service. To prevent an (exclusive) routing 595 to a bogus registration, a caller can in addition query the DNS (or 596 other discovery services at hand) to search for an alternative 597 presence of the callee in another overlay or a normal SIP 598 infrastructure. 600 8.2.4. Privacy Issues 602 All RELOAD SIP registration data is public. Methods of providing 603 location and identity privacy are still being studied. Location 604 privacy can be gained from using anonymous GRUUs. 606 9. IANA Considerations 607 9.1. Data Kind-ID 609 IANA shall register the following code point in the "RELOAD Data 610 Kind-ID" Registry (cf., [I-D.ietf-p2psip-base]) to represent the SIP- 611 REGISTRATION Kind, as described in Section 7. [NOTE TO IANA/ 612 RFC-EDITOR: Please replace RFC-AAAA with the RFC number for this 613 specification in the following list.] 615 +---------------------+------------+----------+ 616 | Kind | Kind-ID | RFC | 617 +---------------------+------------+----------+ 618 | SIP-REGISTRATION | 1 | RFC-AAAA | 619 +---------------------+------------+----------+ 621 9.2. XML Name Space Registration 623 This document registers the following URI for the config XML 624 namespace in the IETF XML registry defined in [RFC3688] 626 URI: urn:ietf:params:xml:ns:p2p:config-base:sip 627 Registrant Contact: The IESG 628 XML: N/A, the requested URI is an XML namespace 630 10. Acknowledgments 632 This document was generated in parts from initial drafts and 633 discussions in the early specification phase of the P2PSIP base 634 protocol. Significant contributions (in alphabetical order) were 635 from David A. Bryan, James Deverick, Marcin Matuszewski, Jonathan 636 Rosenberg, and Marcia Zangrilli, which is gratefully acknowledged. 638 Additional thanks go to all those who helped with ideas, discussions, 639 and reviews, in particular (in alphabetical order) Michael Chen, Marc 640 Petit-Huguenin, Brian Rosen, and Matthias Waehlisch. 642 11. References 644 11.1. Normative References 646 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 647 Requirement Levels", BCP 14, RFC 2119, March 1997. 649 [I-D.ietf-p2psip-base] 650 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 651 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) 652 Base Protocol", draft-ietf-p2psip-base-26 (work in 653 progress), February 2013. 655 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 656 A., Peterson, J., Sparks, R., Handley, M., and E. 657 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 658 June 2002. 660 [RFC2533] Klyne, G., "A Syntax for Describing Media Feature Sets", 661 RFC 2533, March 1999. 663 [RFC2738] Klyne, G., "Corrections to "A Syntax for Describing Media 664 Feature Sets"", RFC 2738, December 1999. 666 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 667 January 2004. 669 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 670 Agent URIs (GRUUs) in the Session Initiation Protocol 671 (SIP)", RFC 5627, October 2009. 673 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 674 Encodings", RFC 4648, October 2006. 676 [IEEE-Posix] 677 "IEEE Standard for Information Technology - Portable 678 Operating System Interface (POSIX) - Part 2: Shell and 679 Utilities (Vol. 1)", IEEE Std 1003.2-1992, ISBN 1-55937- 680 255-9, January 1993. 682 11.2. Informative References 684 [I-D.ietf-p2psip-concepts] 685 Bryan, D., Willis, D., Shim, E., Matthews, P., and S. 686 Dawkins, "Concepts and Terminology for Peer to Peer SIP", 687 draft-ietf-p2psip-concepts-04 (work in progress), 688 October 2011. 690 [RFC5767] Munakata, M., Schubert, S., and T. Ohba, "User-Agent- 691 Driven Privacy Mechanism for SIP", RFC 5767, April 2010. 693 [I-D.ietf-p2psip-share] 694 Knauf, A., Schmidt, T., Hege, G., and M. Waehlisch, "A 695 Usage for Shared Resources in RELOAD (ShaRe)", 696 draft-ietf-p2psip-share-01 (work in progress), 697 February 2013. 699 Appendix A. Third Party Registration 701 In traditional SIP, the mechanism of a third party registration 702 (i.e., an assistant acting for a boss, changing users register a 703 role-based AOR, ...) is defined in Section 10.2 of [RFC3261]. This 704 is a REGISTER which uses the URI of the third-party in its From 705 header and cannot be translated directly into a P2PSIP registration, 706 because only the owner of the certificate can store a SIP- 707 REGISTRATION in a RELOAD overlay. 709 A way to implement third party registration is by using the extended 710 access control mechanism USER-CHAIN-ACL defined in 711 [I-D.ietf-p2psip-share]. Creating a new Kind "SIP-3P-REGISTRATION" 712 that is ruled by USER-CHAIN-ACL allows the owner of the certificate 713 to delegate the right for registration to individual third parties. 714 In this way, original SIP functionality can be regained without 715 weakening the security control of RELOAD. 717 Appendix B. Change Log 719 B.1. Changes since draft-ietf-p2psip-sip-08 721 o Added the handling of SIPS 722 o Specified use of Posix regular expressions in configuration 723 document 724 o Added IANA registration for namespace 725 o Editorial polishing 726 o Updated and extended references 728 B.2. Changes since draft-ietf-p2psip-sip-07 730 o Cleared open issues 731 o Clarified use cases after WG discussion 732 o Added configuration document extensions for configurable domain 733 names 734 o Specified format of contact_prefs 735 o Clarified routing to AORs 736 o Extended security section 737 o Added Appendix on Third Party Registration 738 o Added IANA code points 739 o Editorial polishing 740 o Updated and extended references 742 B.3. Changes since draft-ietf-p2psip-sip-06 743 o Added Open Issue 745 Authors' Addresses 747 Cullen Jennings 748 Cisco 749 170 West Tasman Drive 750 MS: SJC-21/2 751 San Jose, CA 95134 752 USA 754 Phone: +1 408 421-9990 755 Email: fluffy@cisco.com 757 Bruce B. Lowekamp 758 Skype 759 Palo Alto, CA 760 USA 762 Email: bbl@lowekamp.net 764 Eric Rescorla 765 RTFM, Inc. 766 2064 Edgewood Drive 767 Palo Alto, CA 94303 768 USA 770 Phone: +1 650 678 2350 771 Email: ekr@rtfm.com 773 Salman A. Baset 774 Columbia University 775 1214 Amsterdam Avenue 776 New York, NY 777 USA 779 Email: salman@cs.columbia.edu 780 Henning Schulzrinne 781 Columbia University 782 1214 Amsterdam Avenue 783 New York, NY 784 USA 786 Email: hgs@cs.columbia.edu 788 Thomas C. Schmidt (editor) 789 HAW Hamburg 790 Berliner Tor 7 791 Hamburg 20099 792 Germany 794 Email: schmidt@informatik.haw-hamburg.de