idnits 2.17.1 draft-ietf-p2psip-sip-13.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 286 has weird spacing: '...ionType type...' == Line 288 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 (July 21, 2014) is 3564 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) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-Posix' == Outdated reference: A later version (-09) exists of draft-ietf-p2psip-concepts-06 == Outdated reference: A later version (-10) exists of draft-ietf-p2psip-share-03 Summary: 1 error (**), 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: January 22, 2015 Skype 6 E. Rescorla 7 RTFM, Inc. 8 S. Baset 9 H. Schulzrinne 10 Columbia University 11 T. Schmidt, Ed. 12 HAW Hamburg 13 July 21, 2014 15 A SIP Usage for RELOAD 16 draft-ietf-p2psip-sip-13 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 January 22, 2015. 47 Copyright Notice 49 Copyright (c) 2014 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 This document may contain material from IETF Documents or IETF 63 Contributions published or made publicly available before November 64 10, 2008. The person(s) controlling the copyright in some of this 65 material may not have granted the IETF Trust the right to allow 66 modifications of such material outside the IETF Standards Process. 67 Without obtaining an adequate license from the person(s) controlling 68 the copyright in such materials, this document may not be modified 69 outside the IETF Standards Process, and derivative works of it may 70 not be created outside the IETF Standards Process, except to format 71 it for publication as an RFC or to translate it into languages other 72 than English. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 3. Registering AORs in the Overlay . . . . . . . . . . . . . . . 5 79 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 80 3.2. Data Structure . . . . . . . . . . . . . . . . . . . . . 6 81 3.3. Access Control . . . . . . . . . . . . . . . . . . . . . 9 82 3.4. Overlay Configuration Document Extension . . . . . . . . 9 83 4. Looking up an AOR . . . . . . . . . . . . . . . . . . . . . . 10 84 4.1. Finding a Route to an AOR . . . . . . . . . . . . . . . . 10 85 4.2. Resolving an AOR . . . . . . . . . . . . . . . . . . . . 11 86 5. Forming a Direct Connection . . . . . . . . . . . . . . . . . 11 87 5.1. Setting Up a Connection . . . . . . . . . . . . . . . . . 11 88 5.2. Keeping a Connection Alive . . . . . . . . . . . . . . . 12 89 6. Using GRUUs . . . . . . . . . . . . . . . . . . . . . . . . . 12 90 7. SIP-REGISTRATION Kind Definition . . . . . . . . . . . . . . 13 91 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 92 8.1. RELOAD-Specific Issues . . . . . . . . . . . . . . . . . 14 93 8.2. SIP-Specific Issues . . . . . . . . . . . . . . . . . . . 14 94 8.2.1. Fork Explosion . . . . . . . . . . . . . . . . . . . 14 95 8.2.2. Malicious Retargeting . . . . . . . . . . . . . . . . 14 96 8.2.3. Misuse of AORs . . . . . . . . . . . . . . . . . . . 14 97 8.2.4. Privacy Issues . . . . . . . . . . . . . . . . . . . 15 98 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 99 9.1. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . 15 100 9.2. XML Name Space Registration . . . . . . . . . . . . . . . 15 101 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 102 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 103 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 104 11.2. Informative References . . . . . . . . . . . . . . . . . 17 105 Appendix A. Third Party Registration . . . . . . . . . . . . . . 17 106 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 17 107 B.1. Changes since draft-ietf-p2psip-sip-09 . . . . . . . . . 17 108 B.2. Changes since draft-ietf-p2psip-sip-08 . . . . . . . . . 18 109 B.3. Changes since draft-ietf-p2psip-sip-07 . . . . . . . . . 18 110 B.4. Changes since draft-ietf-p2psip-sip-06 . . . . . . . . . 18 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 113 1. Introduction 115 The REsource LOcation And Discovery (RELOAD) [I-D.ietf-p2psip-base] 116 specifies a peer-to-peer (P2P) signaling protocol for the general use 117 on the Internet. This document defines a SIP Usage of RELOAD that 118 allows SIP [RFC3261] user agents (UAs) to establish peer-to-peer SIP 119 (or SIPS) sessions without the requirement for permanent proxy or 120 registration servers, e.g., a fully distributed telephony service. 121 In such a network, the RELOAD overlay itself performs the 122 registration and rendezvous functions ordinarily associated with such 123 servers. 125 The SIP Usage involves two basic functions. 127 Registration: SIP UAs can use the RELOAD data storage functionality 128 to store a mapping from their address-of-record (AOR) to their 129 Node-ID in the overlay, and to retrieve the Node-ID of other UAs. 131 Rendezvous: Once a SIP UA has identified the Node-ID for an AOR it 132 wishes to call, it can use the RELOAD message routing system to 133 set up a direct connection for exchanging SIP messages. 135 Mappings are stored in the SipRegistration Resource Record defined in 136 this document. All operations required to perform a SIP registration 137 or rendezvous are standard RELOAD protocol methods. 139 For example, Bob registers his AOR, "bob@dht.example.com", for his 140 Node-ID "1234". When Alice wants to call Bob, she queries the 141 overlay for "bob@dht.example.com" and receives Node-ID 1234 in 142 return. She then uses the overlay routing to establish a direct 143 connection with Bob and can directly transmit a standard SIP INVITE. 144 In detail, this works along the following steps. 146 1. Bob, operating Node-ID 1234, stores a mapping from his AOR to his 147 Node-ID in the overlay by applying a Store request for 148 "bob@dht.example.com -> 1234". 150 2. Alice, operating Node-ID 5678, decides to call Bob. She retrieves 151 Node-ID "1234" by performing a Fetch request on 152 "bob@dht.example.com". 154 3. Alice uses the overlay to route an AppAttach message to Bob's 155 peer (ID 1234). Bob responds with his own AppAttach and they set 156 up a direct connection, as shown in Figure 1. Note that mutual 157 ICE checks are invoked automatically from AppAttach message 158 exchange. 160 Overlay 161 Alice Peer1 ... PeerN Bob 162 (5678) (1234) 163 ------------------------------------------------- 164 AppAttach -> 165 AppAttach -> 166 AppAttach -> 167 AppAttach -> 168 <- AppAttach 169 <- AppAttach 170 <- AppAttach 171 <- AppAttach 173 <------------------ ICE Checks -----------------> 174 INVITE -----------------------------------------> 175 <--------------------------------------------- OK 176 ACK --------------------------------------------> 177 <------------ ICE Checks for media -------------> 178 <-------------------- RTP ----------------------> 180 Figure 1: Connection setup in P2P SIP using the RELOAD overlay 182 It is important to note that here the only role of RELOAD is to set 183 up the direct SIP connection between Alice and Bob. As soon as the 184 ICE checks complete and the connection is established, ordinary SIP 185 or SIPS is used. In particular, the establishment of the media 186 channel for a phone call happens via the usual SIP mechanisms, and 187 RELOAD is not involved. Media never traverses the overlay. After 188 the successful exchange of SIP messages, call peers run ICE 189 connectivity checks for media. 191 In addition to mappings from AORs to Node-IDs, the SIP Usage also 192 allows mappings from AORs to other AORs. This enables an indirection 193 useful for call forwarding. For instance, if Bob wants his phone 194 calls temporarily forwarded to Charlie, he can store the mapping 195 "bob@dht.example.com -> charlie@dht.example.com". When Alice wants 196 to call Bob, she retrieves this mapping and can then fetch Charlie's 197 AOR to retrieve his Node-ID. These mechanisms are described in 198 Section 3. 200 Alternatively, Globally Routable User Agent URIs (GRUUs) can be used 201 for directly accessing peers. They are handled via a separate 202 mechanism, as described in Section 6. 204 The SIP Usage for RELOAD addresses a fully distributed deployment of 205 session-based services among overlay peers. Two opposite scenarios 206 of deploying P2P SIP services are in the focus of this document: A 207 highly regulated environment of a "single provider" that admits 208 parties using AORs with domains from controlled namespace(s), only, 209 and an open, multi-party infrastructure that liberally allows a 210 registration and rendezvous for various or any domain namespace. It 211 is noteworthy in this context that - in contrast to regular SIP - 212 domain names play no role in routing to a proxy server. Once 213 connectivity to an overlay is given, any name registration can be 214 technically processed. 216 2. Terminology 218 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 219 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 220 document are to be interpreted as described in RFC 2119 [RFC2119]. 222 We use the terminology and definitions from Concepts and Terminology 223 for Peer to Peer SIP [I-D.ietf-p2psip-concepts] and the RELOAD Base 224 Protocol [I-D.ietf-p2psip-base] extensively in this document. 226 In addition, term definitions from SIP [RFC3261] apply to this memo. 227 The term AOR is the SIP "Address of Record" used to identify a user 228 in SIP. For example, alice@example.com could be the AOR for Alice. 229 For the purposes of this specification, an AOR is considered not to 230 include the scheme (e.g sip:) as the AOR needs to match the 231 rfc822Name in the X509v3 certificates. It is worth noting that SIP 232 and SIPS are distinguished in P2PSIP by the Application-ID. 234 3. Registering AORs in the Overlay 235 3.1. Overview 237 In ordinary SIP, a UA registers its AOR and location with a 238 registrar. In RELOAD, this registrar function is provided by the 239 overlay as a whole. To register its location, a RELOAD peer stores a 240 SipRegistration Resource Record under its own AOR using the SIP- 241 REGISTRATION Kind, which is formally defined in Section 7. A RELOAD 242 overlay MAY restrict the storage of AORs. Namespaces (i.e., the 243 right hand side of the AOR) that are supported for registration and 244 lookup can be configured for each RELOAD deployment as described in 245 Section 3.4. 247 As a simple example, consider Alice with AOR "alice@dht.example.org" 248 at Node-ID "1234". She might store the mapping 249 "alice@dht.example.org -> 1234" telling anyone who wants to call her 250 to contact node "1234". 252 RELOAD peers MAY store two kinds of SIP mappings, 254 o from an AOR to a destination list (a single Node-ID is just a 255 trivial destination list), or 257 o from an AOR to another AOR. 259 The meaning of the first kind of mapping is "in order to contact me, 260 form a connection with this peer." The meaning of the second kind of 261 mapping is "in order to contact me, dereference this AOR". The 262 latter allows for forwarding. For instance, if Alice wants her calls 263 to be forwarded to her secretary, Sam, she might insert the following 264 mapping "alice@dht.example.org -> sam@dht.example.org". 266 3.2. Data Structure 268 This section defines the SipRegistration Resource Record as follows: 270 enum { sip_registration_uri(1), sip_registration_route(2), 271 (255) } SipRegistrationType; 273 select (SipRegistration.type) { 274 case sip_registration_uri: 275 opaque uri<0..2^16-1>; 277 case sip_registration_route: 278 opaque contact_prefs<0..2^16-1>; 279 Destination destination_list<0..2^16-1>; 281 /* This type can be extended */ 283 } SipRegistrationData; 285 struct { 286 SipRegistrationType type; 287 uint16 length; 288 SipRegistrationData data; 289 } SipRegistration; 291 The contents of the SipRegistration Resource Record are: 293 type 295 the type of the registration 297 length 299 the length of the rest of the PDU 301 data 303 the registration data 305 o If the registration is of type "sip_registration_uri", then the 306 contents are an opaque string containing the URI. 308 o If the registration is of type "sip_registration_route", then the 309 contents are an opaque string containing the callee's contact 310 preferences and a destination list for the peer. 312 The encoding of contact_prefs - the callee's contact preferences - 313 follows the media feature set syntax of [RFC2533] (see also 314 [RFC2738]). As an example, a voicemail server that is a UA that 315 supports audio and video media types and is not mobile would carry 316 the following feature set description in its contact_prefs attribute: 318 (& (sip.audio=TRUE) 319 (sip.video=TRUE) 320 (sip.actor=msg-taker) 321 (sip.automata=TRUE) 322 (sip.mobility=fixed) 323 (| (sip.methods=INVITE) (sip.methods=BYE) (sip.methods=OPTIONS) 324 (sip.methods=ACK) (sip.methods=CANCEL))) 326 A callee MAY indicate that it prefers contact via a particular SIP 327 scheme - SIP or SIPS - by using one of the following contact_prefs 328 attribute: 330 (sip.schemes=SIP) 331 (sip.schemes=SIPS) 333 RELOAD explicitly supports multiple registrations for a single AOR. 334 The registrations are stored in a Dictionary with Node-IDs as the 335 dictionary keys. Consider, for instance, the case where Alice has 336 two peers: 338 o her desk phone (1234) 340 o her cell phone (5678) 342 Alice might store the following in the overlay at resource 343 "alice@dht.example.com". 345 o A SipRegistration of type "sip_registration_route" with dictionary 346 key "1234" and value "1234". 348 o A SipRegistration of type "sip_registration_route" with dictionary 349 key "5678" and value "5678". 351 Note that this structure explicitly allows one Node-ID to forward to 352 another Node-ID. For instance, Alice could set calls to her desk 353 phone to ring at her cell phone by storing a SipRegistration of type 354 "sip_registration_route" with dictionary key "1234" and value "5678". 356 3.3. Access Control 358 In order to prevent hijacking or other misuse, registrations are 359 subject to access control rules. Two kinds of restrictions apply: 361 o A Store is permitted only for AORs with domain names that fall 362 into the namespaces supported by the RELOAD overlay instance. 364 o Storing requests are performed according to the USER-NODE-MATCH 365 access control policy of RELOAD. 367 Before issuing a Store request to the overlay, any peer SHOULD verify 368 that the AOR of the request is a valid Resource Name with respect to 369 its domain name and the namespaces defined in the overlay 370 configuration document (see Section 3.4). 372 Before a Store is permitted, the storing peer MUST check that: 374 o The AOR of the request is a valid Resource Name with respect to 375 the namespaces defined in the overlay configuration document. 377 o The certificate contains a username that is a SIP AOR which hashes 378 to the Resource-ID it is being stored at. 380 o The certificate contains a Node-ID that is the same as the 381 dictionary key it is being stored at. 383 Note that these rules permit Alice to forward calls to Bob without 384 his permission. However, they do not permit Alice to forward Bob's 385 calls to her. See Section 8.2.2 for additional descriptions. 387 3.4. Overlay Configuration Document Extension 389 The use of a SIP-enabled overlay MAY be restricted to users with AORs 390 from specific domains. When deploying an overlay service, providers 391 can decide about these use case scenarios by defining a set of 392 namespaces for admissible domain names. This section extends the 393 overlay configuration document by defining new elements for patterns 394 that describe a corresponding domain name syntax. 396 A RELOAD overlay can be configured to accept store requests for any 397 AOR, or to apply domain name restrictions. For the latter, an 398 enumeration of admissible domain names including wildcarded name 399 patterns of the following form MAY be configured. 401 Example of Domain Patterns: 402 dht\.example\.com 403 .*\.my\.name 404 In this example, any AOR will be accepted that is either of the form 405 @dht.example.com, or ends with the domain "my.name". When 406 restrictions apply and in the absence of domain patterns, the default 407 behavior is to accept only AORs that exactly match the domain name of 408 the overlay. Otherwise, i.e., when restrictions are not configured 409 (attribute enable not set), the default behavior is to accept any 410 AOR. In the absence of a element, implementors 411 SHOULD assume this default value. Encoding of the domain name 412 complies to the restricted ASCII character set without character 413 escaping as defined in Section 19.1 of [RFC3261]. 415 The element serves as a container for zero to 416 multiple sub-elements. A element MAY be present 417 if the "enable" attribute of its parent element is set to true. Each 418 element defines a pattern for constructing admissible 419 resource names. It is of type xsd:string and interpreted as a 420 regular expression according to "POSIX Extended Regular Expression" 421 (see the specifications in [IEEE-Posix]). 423 The Relax NG Grammar for the AOR Domain Restriction reads: 425 427 namespace sip = "urn:ietf:params:xml:ns:p2p:config-base:sip" 429 431 Kind-parameter &= element sip:domain-restriction { 433 attribute enable { xsd:boolean } 435 437 element pattern { xsd:string }* 438 }? 440 4. Looking up an AOR 442 4.1. Finding a Route to an AOR 444 A RELOAD user, member of an overlay, who wishes to call another user 445 with given AOR SHALL proceed in the following way. 447 AOR is GRUU? If the AOR is a GRUU for this overlay, the callee can 448 be contacted directly as described in Section 6. 450 AOR domain is hosted in overlay? If the domain part of the AOR 451 matches a domain pattern configured in the overlay, the user can 452 continue to resolve the AOR in this overlay. The user MAY choose 453 to query the DNS service records to search for additional support 454 of this domain name. 456 AOR domain not supported by overlay? If the domain part of the AOR 457 is not supported in the current overlay, the user SHOULD query the 458 DNS (or other discovery services at hand) to search for an 459 alternative overlay that services the AOR under request. 460 Alternatively, standard SIP procedures for contacting the callee 461 SHOULD be used. 463 AOR inaccessible? If all of the above contact attempts fail, the 464 call fails. 466 The procedures described above likewise apply when nodes are 467 simultaneously connected to several overlays. 469 4.2. Resolving an AOR 471 A RELOAD user that has discovered a route to an AOR in the current 472 overlay SHALL execute the following steps. 474 1. Perform a Fetch for Kind SIP-REGISTRATION at the Resource-ID 475 corresponding to the AOR. This Fetch SHOULD NOT indicate any 476 dictionary keys, so that it will fetch all the stored values. 478 2. If any of the results of the Fetch are non-GRUU AORs, then repeat 479 step 1 for that AOR. 481 3. Once only GRUUs and destination lists remain, the peer removes 482 duplicate destination lists and GRUUs from the list and initiates 483 SIP or SIPS connections to the appropriate peers as described in 484 the following sections. If there are also external AORs, the 485 peer follows the appropriate procedure for contacting them as 486 well. 488 5. Forming a Direct Connection 490 5.1. Setting Up a Connection 492 Once the peer has translated the AOR into a set of destination lists, 493 it then uses the overlay to route AppAttach messages to each of those 494 peers. The "application" field MUST be either 5060 to indicate SIP 495 or 5061 for using SIPS. If certificate-based authentication is in 496 use, the responding peer MUST present a certificate with a Node-ID 497 matching the terminal entry in the route list. Note that it is 498 possible that the peers already have a RELOAD connection mutually 499 established. This MUST NOT be used for SIP messages unless it is a 500 SIP connection. A previously established SIP connection MAY be used 501 for a new call. 503 Once the AppAttach succeeds, the peer sends plain or (D)TLS encrypted 504 SIP messages over the connection as in normal SIP. A caller MAY 505 choose to contact the callee using SIP or secure SIPS, but SHOULD 506 follow a preference indicated by the callee in its contact_prefs 507 attribute (see Section 3.2). A callee MAY choose to listen on both 508 SIP and SIPS ports and accept calls from either SIP scheme, or select 509 a single one. However, a callee that decides to accept SIPS calls, 510 only, SHOULD indicate its choice by setting the corresponding 511 attribute in its contact_prefs. 513 5.2. Keeping a Connection Alive 515 In many cases, RELOAD connections will traverse NATs and Firewalls 516 that maintain states established from ICE [RFC5245] negotiations. It 517 is the responsiblity of the Peers to provide sufficiently frequent 518 traffic to keep NAT and Firewall states present and the connection 519 alive. Keepalives are a mandatory component of ICE (see Section 10 520 of [RFC5245]) and no further operations are required. Applications 521 that want to assure maintanance of sessions individually need to 522 follow regular SIP means. Accordingly, a SIP Peer MAY apply keep- 523 alive techniques in agreement with its transport binding as defined 524 in Section 3.5 of [RFC5626]. 526 6. Using GRUUs 528 Globally Routable User Agent Uris (GRUUs) [RFC5627] have been 529 designed to allow direct routing without the indirection of a SIP 530 proxy function. The concept is transferred to RELOAD overlays as 531 follows. GRUUs in RELOAD are constructed by embedding a 532 base64-encoded destination list in the gr URI parameter of the GRUU. 533 The base64 encoding is done with the alphabet specified in table 1 of 534 [RFC4648] with the exception that ~ is used in place of =. 536 Example of a RELOAD GRUU: 537 alice@example.com;gr=MDEyMzQ1Njc4OTAxMjM0NTY3ODk~ 539 GRUUs do not require to store data in the Overlay Instance. Rather 540 when a peer needs to route a message to a GRUU in the same P2P 541 overlay, it simply uses the destination list and connects to that 542 peer. Because a GRUU contains a destination list, it MAY have the 543 same contents as a destination list stored elsewhere in the resource 544 dictionary. 546 Anonymous GRUUs [RFC5767] are constructed analogously, but require 547 either that the enrollment server issues a different Node-ID for each 548 anonymous GRUU required, or that a destination list be used that 549 includes a peer that compresses the destination list to stop the 550 Node-ID from being revealed. 552 7. SIP-REGISTRATION Kind Definition 554 This section defines the SIP-REGISTRATION Kind. 556 Name SIP-REGISTRATION 558 Kind IDs The Resource Name for the SIP-REGISTRATION Kind-ID is the 559 AOR of the user. The data stored is a SipRegistration, which can 560 contain either another URI or a destination list to the peer which 561 is acting for the user. 563 Data Model The data model for the SIP-REGISTRATION Kind-ID is 564 dictionary. The dictionary key is the Node-ID of the storing 565 peer. This allows each peer (presumably corresponding to a single 566 device) to store a single route mapping. 568 Access Control USER-NODE-MATCH. Note that this matches the SIP AOR 569 against the rfc822Name in the X509v3 certificate. The rfc822Name 570 does not include the scheme so that the "sip:" prefix needs to be 571 removed from the SIP AOR before matching. 573 Data stored under the SIP-REGISTRATION Kind is of type 574 SipRegistration. This comes in two varieties: 576 sip_registration_uri 578 a URI which the user can be reached at. 580 sip_registration_route 582 a destination list which can be used to reach the user's peer. 584 8. Security Considerations 586 8.1. RELOAD-Specific Issues 588 This Usage for RELOAD does not define new protocol elements or 589 operations. Hence no new threats arrive from message exchanges in 590 RELOAD. 592 This document introduces an AOR domain restriction function that must 593 be surveyed by the storing peer. A misconfigured or malicious peer 594 could cause frequent rejects of illegitimate storing requests. 595 However, domain name control relies on a lightweight pattern matching 596 and can be processed prior to validating certificates. Hence no 597 extra burden is introduced for RELOAD peers beyond loads already 598 present in the base protocol. 600 8.2. SIP-Specific Issues 602 8.2.1. Fork Explosion 604 Because SIP includes a forking capability (the ability to retarget to 605 multiple recipients), fork bombs are a potential DoS concern. 606 However, in the SIP usage of RELOAD, fork bombs are a much lower 607 concern than in a conventional SIP Proxy infrastructure, because the 608 calling party is involved in each retargeting event. It can 609 therefore directly measure the number of forks and throttle at some 610 reasonable number. 612 8.2.2. Malicious Retargeting 614 Another potential DoS attack is for the owner of an attractive AOR to 615 retarget all calls to some victim. This attack is common to SIP and 616 difficult to ameliorate without requiring the target of a SIP 617 registration to authorize all stores. The overhead of that 618 requirement would be excessive and in addition there are good use 619 cases for retargeting to a peer without its explicit cooperation. 621 8.2.3. Misuse of AORs 623 A RELOAD overlay and enrollment service that liberally accept 624 registrations for AORs of domain names unrelated to the overlay 625 instance and without further justification, eventually store presence 626 state for misused AORs. An attacker could hijack names, register a 627 bogus presence and attract calls dedicated to a victim that resides 628 within or outside the Overlay Instance. 630 A hijacking of AORs can be mitigated by restricting the name spaces 631 admissible in the Overlay Instance, or by additional verification 632 actions of the enrollment service. To prevent an (exclusive) routing 633 to a bogus registration, a caller can in addition query the DNS (or 634 other discovery services at hand) to search for an alternative 635 presence of the callee in another overlay or a normal SIP 636 infrastructure. 638 8.2.4. Privacy Issues 640 All RELOAD SIP registration data is public. Methods of providing 641 location and identity privacy are still being studied. Location 642 privacy can be gained from using anonymous GRUUs. 644 9. IANA Considerations 646 9.1. Data Kind-ID 648 IANA shall register the following code point in the "RELOAD Data 649 Kind-ID" Registry (cf., [I-D.ietf-p2psip-base]) to represent the SIP- 650 REGISTRATION Kind, as described in Section 7. [NOTE TO IANA/RFC- 651 EDITOR: Please replace RFC-AAAA with the RFC number for this 652 specification in the following list.] 654 +---------------------+------------+----------+ 655 | Kind | Kind-ID | RFC | 656 +---------------------+------------+----------+ 657 | SIP-REGISTRATION | 1 | RFC-AAAA | 658 +---------------------+------------+----------+ 660 9.2. XML Name Space Registration 662 This document registers the following URI for the config XML 663 namespace in the IETF XML registry defined in [RFC3688] 665 URI: urn:ietf:params:xml:ns:p2p:config-base:sip 667 Registrant Contact: The IESG 669 XML: N/A, the requested URI is an XML namespace 671 10. Acknowledgments 673 This document was generated in parts from initial drafts and 674 discussions in the early specification phase of the P2PSIP base 675 protocol. Significant contributions (in alphabetical order) were 676 from David A. Bryan, James Deverick, Marcin Matuszewski, Jonathan 677 Rosenberg, and Marcia Zangrilli, which is gratefully acknowledged. 679 Additional thanks go to all those who helped with ideas, discussions, 680 and reviews, in particular (in alphabetical order) Michael Chen, Marc 681 Petit-Huguenin, Brian Rosen, and Matthias Waehlisch. 683 11. References 685 11.1. Normative References 687 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 688 Requirement Levels", BCP 14, RFC 2119, March 1997. 690 [I-D.ietf-p2psip-base] 691 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 692 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) 693 Base Protocol", draft-ietf-p2psip-base-26 (work in 694 progress), February 2013. 696 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 697 A., Peterson, J., Sparks, R., Handley, M., and E. 698 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 699 June 2002. 701 [RFC2533] Klyne, G., "A Syntax for Describing Media Feature Sets", 702 RFC 2533, March 1999. 704 [RFC2738] Klyne, G., "Corrections to "A Syntax for Describing Media 705 Feature Sets"", RFC 2738, December 1999. 707 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 708 January 2004. 710 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 711 (ICE): A Protocol for Network Address Translator (NAT) 712 Traversal for Offer/Answer Protocols", RFC 5245, April 713 2010. 715 [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 716 Initiated Connections in the Session Initiation Protocol 717 (SIP)", RFC 5626, October 2009. 719 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 720 Agent URIs (GRUUs) in the Session Initiation Protocol 721 (SIP)", RFC 5627, October 2009. 723 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 724 Encodings", RFC 4648, October 2006. 726 [IEEE-Posix] 727 "IEEE Standard for Information Technology - Portable 728 Operating System Interface (POSIX) - Part 2: Shell and 729 Utilities (Vol. 1)", IEEE Std 1003.2-1992, ISBN 730 1-55937-255-9, January 1993. 732 11.2. Informative References 734 [I-D.ietf-p2psip-concepts] 735 Bryan, D., Matthews, P., Shim, E., Willis, D., and S. 736 Dawkins, "Concepts and Terminology for Peer to Peer SIP", 737 draft-ietf-p2psip-concepts-06 (work in progress), June 738 2014. 740 [RFC5767] Munakata, M., Schubert, S., and T. Ohba, "User-Agent- 741 Driven Privacy Mechanism for SIP", RFC 5767, April 2010. 743 [I-D.ietf-p2psip-share] 744 Knauf, A., Schmidt, T., Hege, G., and M. Waehlisch, "A 745 Usage for Shared Resources in RELOAD (ShaRe)", draft-ietf- 746 p2psip-share-03 (work in progress), March 2014. 748 Appendix A. Third Party Registration 750 In traditional SIP, the mechanism of a third party registration 751 (i.e., an assistant acting for a boss, changing users register a 752 role-based AOR, ...) is defined in Section 10.2 of [RFC3261]. This 753 is a REGISTER which uses the URI of the third-party in its From 754 header and cannot be translated directly into a P2PSIP registration, 755 because only the owner of the certificate can store a SIP- 756 REGISTRATION in a RELOAD overlay. 758 A way to implement third party registration is by using the extended 759 access control mechanism USER-CHAIN-ACL defined in 760 [I-D.ietf-p2psip-share]. Creating a new Kind "SIP-3P-REGISTRATION" 761 that is ruled by USER-CHAIN-ACL allows the owner of the certificate 762 to delegate the right for registration to individual third parties. 763 In this way, original SIP functionality can be regained without 764 weakening the security control of RELOAD. 766 Appendix B. Change Log 768 B.1. Changes since draft-ietf-p2psip-sip-09 770 o Added subsection on keepalive 772 o Updated references 774 B.2. Changes since draft-ietf-p2psip-sip-08 776 o Added the handling of SIPS 778 o Specified use of Posix regular expressions in configuration 779 document 781 o Added IANA registration for namespace 783 o Editorial polishing 785 o Updated and extended references 787 B.3. Changes since draft-ietf-p2psip-sip-07 789 o Cleared open issues 791 o Clarified use cases after WG discussion 793 o Added configuration document extensions for configurable domain 794 names 796 o Specified format of contact_prefs 798 o Clarified routing to AORs 800 o Extended security section 802 o Added Appendix on Third Party Registration 804 o Added IANA code points 806 o Editorial polishing 808 o Updated and extended references 810 B.4. Changes since draft-ietf-p2psip-sip-06 812 o Added Open Issue 814 Authors' Addresses 815 Cullen Jennings 816 Cisco 817 170 West Tasman Drive 818 MS: SJC-21/2 819 San Jose, CA 95134 820 USA 822 Phone: +1 408 421-9990 823 Email: fluffy@cisco.com 825 Bruce B. Lowekamp 826 Skype 827 Palo Alto, CA 828 USA 830 Email: bbl@lowekamp.net 832 Eric Rescorla 833 RTFM, Inc. 834 2064 Edgewood Drive 835 Palo Alto, CA 94303 836 USA 838 Phone: +1 650 678 2350 839 Email: ekr@rtfm.com 841 Salman A. Baset 842 Columbia University 843 1214 Amsterdam Avenue 844 New York, NY 845 USA 847 Email: salman@cs.columbia.edu 849 Henning Schulzrinne 850 Columbia University 851 1214 Amsterdam Avenue 852 New York, NY 853 USA 855 Email: hgs@cs.columbia.edu 856 Thomas C. Schmidt (editor) 857 HAW Hamburg 858 Berliner Tor 7 859 Hamburg 20099 860 Germany 862 Email: schmidt@informatik.haw-hamburg.de