idnits 2.17.1 draft-ietf-p2psip-sip-21.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 292 has weird spacing: '...ionType type...' == Line 294 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 (April 27, 2016) is 2915 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 (-10) exists of draft-ietf-p2psip-share-08 Summary: 1 error (**), 0 flaws (~~), 4 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: October 29, 2016 Skype 6 E. Rescorla 7 RTFM, Inc. 8 S. Baset 9 H. Schulzrinne 10 Columbia University 11 T. Schmidt, Ed. 12 HAW Hamburg 13 April 27, 2016 15 A SIP Usage for RELOAD 16 draft-ietf-p2psip-sip-21 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 RELOAD AppAttach 27 method is used to establish a direct connection between nodes through 28 which 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 October 29, 2016. 47 Copyright Notice 49 Copyright (c) 2016 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 . . . . . . . . . . . . . . . 6 79 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 80 3.2. Data Structure . . . . . . . . . . . . . . . . . . . . . 6 81 3.3. Access Control . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . 15 96 8.2.3. Misuse of AORs . . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . 16 101 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 102 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 103 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 104 11.2. Informative References . . . . . . . . . . . . . . . . . 18 105 Appendix A. Third Party Registration . . . . . . . . . . . . . . 18 106 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 18 107 B.1. Changes since draft-ietf-p2psip-sip-09 . . . . . . . . . 19 108 B.2. Changes since draft-ietf-p2psip-sip-08 . . . . . . . . . 19 109 B.3. Changes since draft-ietf-p2psip-sip-07 . . . . . . . . . 19 110 B.4. Changes since draft-ietf-p2psip-sip-06 . . . . . . . . . 19 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 113 1. Introduction 115 REsource LOcation And Discovery (RELOAD) [RFC6940] specifies a peer- 116 to-peer (P2P) signaling protocol for the general use on the Internet. 117 This document defines a SIP Usage of RELOAD that allows SIP [RFC3261] 118 user agents (UAs) to establish peer-to-peer SIP (or SIPS) sessions 119 without the requirement for permanent proxy or registration servers, 120 e.g., a fully distributed telephony service. This service 121 transparently supports SIP addressing including telephone numbers. 122 In such a network, the RELOAD overlay itself performs the 123 registration and rendezvous functions ordinarily associated with such 124 servers. 126 The SIP Usage involves two basic functions. 128 Registration: SIP UAs can use the RELOAD data storage functionality 129 to store a mapping from their address-of-record (AOR) to their 130 Node-ID in the overlay, and to retrieve the Node-ID of other UAs. 132 Rendezvous: Once a SIP UA has identified the Node-ID for an AOR it 133 wishes to call, it can use the RELOAD message routing system to 134 set up a direct connection for exchanging SIP messages. 136 Mappings are stored in the SipRegistration Resource Record defined in 137 this document. All operations required to perform a SIP registration 138 or rendezvous are standard RELOAD protocol methods. 140 For example, Bob registers his AOR, "bob@dht.example.com", for his 141 Node-ID "1234". When Alice wants to call Bob, she queries the 142 overlay for "bob@dht.example.com" and receives Node-ID "1234" in 143 return. She then uses the overlay routing to establish a direct 144 connection with Bob and can directly transmit a standard SIP INVITE. 145 In detail, this works along the following steps. 147 1. Bob, operating Node-ID "1234", stores a mapping from his AOR to 148 his Node-ID in the overlay by applying a Store request for 149 "bob@dht.example.com -> 1234". 151 2. Alice, operating Node-ID "5678", decides to call Bob. She 152 retrieves Node-ID "1234" by performing a Fetch request on 153 "bob@dht.example.com". 155 3. Alice uses the overlay to route an AppAttach message to Bob's 156 peer (ID "1234"). Bob responds with his own AppAttach and they 157 set up a direct connection, as shown in Figure 1. Note that 158 mutual Interactive Connectivity Establishment (ICE) checks are 159 invoked automatically from AppAttach message exchange. 161 Overlay 162 Alice Peer1 ... PeerN Bob 163 (5678) (1234) 164 ------------------------------------------------- 165 AppAttach -> 166 AppAttach -> 167 AppAttach -> 168 AppAttach -> 169 <- AppAttach 170 <- AppAttach 171 <- AppAttach 172 <- AppAttach 174 <------------------ ICE Checks -----------------> 175 INVITE -----------------------------------------> 176 <--------------------------------------------- OK 177 ACK --------------------------------------------> 178 <------------ ICE Checks for media -------------> 179 <-------------------- RTP ----------------------> 181 Figure 1: Connection setup in P2P SIP using the RELOAD overlay 183 It is important to note that here the only role of RELOAD is to set 184 up the direct SIP connection between Alice and Bob. As soon as the 185 ICE checks complete and the connection is established, ordinary SIP 186 or SIPS is used. In particular, the establishment of the media 187 channel for a phone call happens via the usual SIP mechanisms, and 188 RELOAD is not involved. Media never traverses the overlay. After 189 the successful exchange of SIP messages, call peers run ICE 190 connectivity checks for media. 192 In addition to mappings from AORs to Node-IDs, the SIP Usage also 193 allows mappings from AORs to other AORs. This enables an indirection 194 useful for call forwarding. For instance, if Bob wants his phone 195 calls temporarily forwarded to Charlie, he can store the mapping 196 "bob@dht.example.com -> charlie@dht.example.com". When Alice wants 197 to call Bob, she retrieves this mapping and can then fetch Charlie's 198 AOR to retrieve his Node-ID. These mechanisms are described in 199 Section 3. 201 Alternatively, Globally Routable User Agent URIs (GRUUs) [RFC5627] 202 can be used for directly accessing peers. They are handled via a 203 separate mechanism, as described in Section 6. 205 The SIP Usage for RELOAD addresses a fully distributed deployment of 206 session-based services among overlay peers. This RELOAD usage may be 207 relevant in a variety of environments, including a highly regulated 208 environment of a "single provider" that admits parties using AORs 209 with domains from controlled namespace(s) only, or an open, multi- 210 party infrastructure that liberally allows a registration and 211 rendezvous for various or any domain namespace. It is noteworthy in 212 this context that - in contrast to regular SIP - domain names play no 213 role in routing to a proxy server. Once connectivity to an overlay 214 is given, any name registration can be 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 [RFC6940] 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 [RFC5280]. It is worth noting 232 that SIP and SIPS are distinguished in P2PSIP by the Application-ID. 234 3. Registering AORs in the Overlay 236 3.1. Overview 238 In ordinary SIP, a UA registers the user's AOR and its network 239 location with a registrar. In RELOAD, this registrar function is 240 provided by the overlay as a whole. To register its location, a 241 RELOAD peer stores a SipRegistration Resource Record under its own 242 AOR using the SIP-REGISTRATION Kind, which is formally defined in 243 Section 7. Note that the registration lifetime known from the 244 regular SIP REGISTER method is inherited from the lifetime attribute 245 of the basic RELOAD StoredData structure (see Section 7 in 246 [RFC6940]). 248 A RELOAD overlay MAY restrict the storage of AORs. Namespaces (i.e., 249 the right hand side of the AOR) that are supported for registration 250 and lookup can be configured for each RELOAD deployment as described 251 in Section 3.4. 253 As a simple example, consider Alice with AOR "alice@dht.example.org" 254 at Node-ID "1234". She might store the mapping 255 "alice@dht.example.org -> 1234" telling anyone who wants to call her 256 to contact node "1234". 258 RELOAD peers can store two kinds of SIP mappings, 260 o from an AOR to a destination list (a single Node-ID is just a 261 trivial destination list), or 263 o from an AOR to another AOR. 265 The meaning of the first kind of mapping is "in order to contact me, 266 form a connection with this peer." The meaning of the second kind of 267 mapping is "in order to contact me, dereference this AOR". The 268 latter allows for forwarding. For instance, if Alice wants her calls 269 to be forwarded to her secretary, Sam, she might insert the following 270 mapping "alice@dht.example.org -> sam@dht.example.org". 272 3.2. Data Structure 274 This section defines the SipRegistration Resource Record as follows: 276 enum { sip_registration_uri(1), sip_registration_route(2), 277 (255) } SipRegistrationType; 279 select (SipRegistration.type) { 280 case sip_registration_uri: 281 opaque uri<0..2^16-1>; 283 case sip_registration_route: 284 opaque contact_prefs<0..2^16-1>; 285 Destination destination_list<0..2^16-1>; 287 /* This type can be extended */ 289 } SipRegistrationData; 291 struct { 292 SipRegistrationType type; 293 uint16 length; 294 SipRegistrationData data; 295 } SipRegistration; 297 The contents of the SipRegistration Resource Record are: 299 type 301 the type of the registration 303 length 305 the length of the rest of the PDU 307 data 309 the registration data 311 o If the registration is of type "sip_registration_uri", then the 312 contents are an opaque string containing the AOR. 314 o If the registration is of type "sip_registration_route", then the 315 contents are an opaque string containing the registrant's contact 316 preferences and a destination list for the peer. 318 The callee expresses its capabilities within the contact preferences 319 as specified in [RFC3840]. It encodes a media feature set comprised 320 of its capabilities as a contact predicate, i.e., a string of feature 321 parameters that appear as part of the Contact header field. Feature 322 parameters are derived from the media feature set syntax of [RFC2533] 323 (see also [RFC2738]) as described in [RFC3840]. 325 This encoding covers all SIP User Agent capabilities, as defined in 326 [RFC3840] and registered in the SIP feature tag registration tree. 327 In particular, a callee can indicate that it prefers contact via a 328 particular SIP scheme - SIP or SIPS - by using one of the following 329 contact_prefs attribute: 331 (sip.schemes=SIP) 332 (sip.schemes=SIPS) 334 RELOAD explicitly supports multiple registrations for a single AOR. 335 The registrations are stored in a Dictionary with Node-IDs as the 336 dictionary keys. Consider, for instance, the case where Alice has 337 two peers: 339 o her desk phone (1234) 341 o her cell phone (5678) 343 Alice might store the following in the overlay at resource 344 "alice@dht.example.com". 346 o A SipRegistration of type "sip_registration_route" with dictionary 347 key "1234" and value "1234". 349 o A SipRegistration of type "sip_registration_route" with dictionary 350 key "5678" and value "5678". 352 Note that this structure explicitly allows one Node-ID to forward to 353 another Node-ID. For instance, Alice could set calls to her desk 354 phone to ring at her cell phone by storing a SipRegistration of type 355 "sip_registration_route" with dictionary key "1234" and value "5678". 357 3.3. Access Control 359 In order to prevent hijacking or other misuse, registrations are 360 subject to access control rules. Two kinds of restrictions apply: 362 o A Store is permitted only for AORs with domain names that fall 363 into the namespaces supported by the RELOAD overlay instance. 365 o Storing requests are performed according to the USER-NODE-MATCH 366 access control policy of RELOAD. 368 Before issuing a Store request to the overlay, any peer SHOULD verify 369 that the AOR of the request is a valid Resource Name with respect to 370 its domain name and the namespaces defined in the overlay 371 configuration document (see Section 3.4). 373 Before a Store is permitted, the storing peer MUST check that: 375 o The AOR of the request is a valid Resource Name with respect to 376 the namespaces defined in the overlay configuration document. 378 o The certificate contains a username that is a SIP AOR which hashes 379 to the Resource-ID it is being stored at. 381 o The certificate contains a Node-ID that is the same as the 382 dictionary key it is being stored at. 384 If any of these checks fail, the request MUST be rejected with an 385 Error_Forbidden error. 387 Note that these rules permit Alice to forward calls to Bob without 388 his permission. However, they do not permit Alice to forward Bob's 389 calls to her. See Section 8.2.2 for additional descriptions. 391 3.4. Overlay Configuration Document Extension 393 The use of a SIP-enabled overlay MAY be restricted to users with AORs 394 from specific domains. When deploying an overlay service, providers 395 can decide about these use case scenarios by defining a set of 396 namespaces for admissible domain names. This section extends the 397 overlay configuration document by defining new elements for patterns 398 that describe a corresponding domain name syntax. 400 A RELOAD overlay can be configured to accept store requests for any 401 AOR, or to apply domain name restrictions. To apply restrictions, 402 the overlay configuration document needs to contain a element. The element serves as a 404 container for zero to multiple sub-elements. A 405 element MAY be present if the "enable" attribute of its parent 406 element is set to true. Each element defines a pattern for 407 constructing admissible resource names. It is of type xsd:string and 408 interpreted as a regular expression according to "POSIX Extended 409 Regular Expression" (see the specifications in [IEEE-Posix]). 411 Encoding of the domain name complies to the restricted ASCII 412 character set without character escaping as defined in Section 19.1 413 of [RFC3261]. 415 Inclusion of a element in an overlay 416 configuration document is OPTIONAL. If the element is not included, 417 the default behavior is to accept any AOR. If the element is 418 included and the "enable" attribute is not set or set to false, the 419 overlay MUST only accept AORs that match the domain name of the 420 overlay. If the element is included and the "enable" attribute is 421 set to true, the overlay MUST only accept AORs that match patterns 422 specified in the element. 424 Example of Domain Patterns: 425 dht\.example\.com 426 .*\.my\.example 428 In this example, any AOR will be accepted that is either of the form 429 @dht.example.com, or ends with the domain "my.example". 431 The Relax NG Grammar for the AOR Domain Restriction reads: 433 # AOR DOMAIN RESTRICTION URN SUB-NAMESPACE 435 namespace sip = "urn:ietf:params:xml:ns:p2p:config-base:sip" 437 # AOR DOMAIN RESTRICTION ELEMENT 439 Kind-parameter &= element sip:domain-restriction { 441 attribute enable { xsd:boolean } 443 # PATTERN ELEMENT 445 element sip:pattern { xsd:string }* 446 }? 448 4. Looking up an AOR 450 4.1. Finding a Route to an AOR 452 A RELOAD user, member of an overlay, who wishes to call another user 453 with given AOR SHALL proceed in the following way. 455 AOR is GRUU? If the AOR is a GRUU for this overlay, the callee can 456 be contacted directly as described in Section 6. 458 AOR domain is hosted in overlay? If the domain part of the AOR 459 matches a domain pattern configured in the overlay, the user can 460 continue to resolve the AOR in this overlay. The user MAY choose 461 to query the DNS service records to search for additional support 462 of this domain name. 464 AOR domain not supported by overlay? If the domain part of the AOR 465 is not supported in the current overlay, the user might query the 466 DNS (or other discovery services at hand) to search for an 467 alternative overlay that services the AOR under request. 468 Alternatively, standard SIP procedures for contacting the callee 469 might be used. 471 AOR inaccessible? If all of the above contact attempts fail, the 472 call fails. 474 The procedures described above likewise apply when nodes are 475 simultaneously connected to several overlays. 477 4.2. Resolving an AOR 479 A RELOAD user that has discovered a route to an AOR in the current 480 overlay SHALL execute the following steps. 482 1. Perform a Fetch for Kind SIP-REGISTRATION at the Resource-ID 483 corresponding to the AOR. This Fetch SHOULD NOT indicate any 484 dictionary keys, so that it will fetch all the stored values. 486 2. If any of the results of the Fetch are non-GRUU AORs, then repeat 487 step 1 for that AOR. 489 3. Once only GRUUs and destination lists remain, the peer removes 490 duplicate destination lists and GRUUs from the list and initiates 491 SIP or SIPS connections to the appropriate peers as described in 492 the following sections. If there are also external AORs, the 493 peer follows the appropriate procedure for contacting them as 494 well. 496 5. Forming a Direct Connection 498 5.1. Setting Up a Connection 500 Once the peer has translated the AOR into a set of destination lists, 501 it then uses the overlay to route AppAttach messages to each of those 502 peers. The "application" field MUST be either 5060 to indicate SIP 503 or 5061 for using SIPS. If certificate-based authentication is in 504 use, the responding peer MUST present a certificate with a Node-ID 505 matching the terminal entry in the destination list. Otherwise, the 506 connection MUST NOT be used and MUST be closed. Note that it is 507 possible that the peers already have a RELOAD connection mutually 508 established. This MUST NOT be used for SIP messages unless it is a 509 SIP connection. A previously established SIP connection MAY be used 510 for a new call. 512 Once the AppAttach succeeds, the peer sends plain or (D)TLS encrypted 513 SIP messages over the connection as in normal SIP. A caller MAY 514 choose to contact the callee using SIP or SIPS, but SHOULD follow a 515 preference indicated by the callee in its contact_prefs attribute 516 (see Section 3.2). A callee MAY choose to listen on both SIP and 517 SIPS ports and accept calls from either SIP scheme, or select a 518 single one. However, a callee that decides to accept SIPS calls, 519 only, SHOULD indicate its choice by setting the corresponding 520 attribute in its contact_prefs. It is noteworthy that according to 521 [RFC6940] all overlay links are built on (D)TLS secured transport. 522 While hop-wise encrypted paths do not prevent the use of plain SIP, 523 SIPS requires protection of all links that may include client links 524 (if present) and endpoint certificates. 526 SIP messages carry the SIP URIs of actual overlay endpoints (e.g., 527 "sip:alice@dht.example.com") in the Via and Contact headers, while 528 the communication continues via the RELOAD connection. However, a UA 529 can redirect its communication path by setting an alternate Contact 530 header field like in ordinary SIP. 532 5.2. Keeping a Connection Alive 534 In many cases, RELOAD connections will traverse NATs and Firewalls 535 that maintain states established from ICE [RFC5245] negotiations. It 536 is the responsibility of the Peers to provide sufficiently frequent 537 traffic to keep NAT and Firewall states present and the connection 538 alive. Keepalives are a mandatory component of ICE (see Section 10 539 of [RFC5245]) and no further operations are required. Applications 540 that want to assure maintenance of sessions individually need to 541 follow regular SIP means. Accordingly, a SIP Peer MAY apply keep- 542 alive techniques in agreement with its transport binding as defined 543 in Section 3.5 of [RFC5626]. 545 6. Using GRUUs 547 Globally Routable User Agent URIs (GRUUs) [RFC5627] have been 548 designed to allow direct routing to a specific UA instance without 549 the need for dereferencing by a domain-specific SIP proxy function. 550 The concept is transferred to RELOAD overlays as follows. GRUUs in 551 RELOAD are constructed by embedding a base64-encoded destination list 552 in the "gr" URI parameter of the GRUU. The base64 encoding is done 553 with the alphabet specified in table 1 of [RFC4648] with the 554 exception that ~ is used in place of =. 556 Example of a RELOAD GRUU: 557 alice@example.com;gr=MDEyMzQ1Njc4OTAxMjM0NTY3ODk~ 559 GRUUs do not require to store data in the Overlay Instance. Rather 560 when a peer needs to route a message to a GRUU in the same P2P 561 overlay, it simply uses the destination list and connects to that 562 peer. Because a GRUU contains a destination list, it can have the 563 same contents as a destination list stored elsewhere in the resource 564 dictionary. 566 Anonymous GRUUs [RFC5767] are constructed analogously, but require 567 either that the enrollment server issues a different Node-ID for each 568 anonymous GRUU required, or that a destination list be used that 569 includes a peer that compresses the destination list to stop the 570 Node-ID from being revealed. 572 7. SIP-REGISTRATION Kind Definition 574 This section defines the SIP-REGISTRATION Kind. 576 Name SIP-REGISTRATION 578 Kind IDs The Resource Name for the SIP-REGISTRATION Kind-ID is the 579 AOR of the user as specified in Section 2. The data stored is a 580 SipRegistration, which can contain either another URI or a 581 destination list to the peer which is acting for the user. 583 Data Model The data model for the SIP-REGISTRATION Kind-ID is 584 dictionary. The dictionary key is the Node-ID of the storing 585 peer. This allows each peer (presumably corresponding to a single 586 device) to store a single route mapping. 588 Access Control USER-NODE-MATCH. Note that this matches the SIP AOR 589 against the rfc822Name in the X509v3 certificate. The rfc822Name 590 does not include the scheme so that the "sip:" prefix needs to be 591 removed from the SIP AOR before matching. Escaped characters ('%' 592 encoding) in the SIP AOR also need to be decoded prior to matching 593 (see [RFC3986]). 595 Data stored under the SIP-REGISTRATION Kind is of type 596 SipRegistration. This comes in two varieties: 598 sip_registration_uri 600 a URI which the user can be reached at. 602 sip_registration_route 604 a destination list which can be used to reach the user's peer. 606 8. Security Considerations 608 8.1. RELOAD-Specific Issues 610 This Usage for RELOAD does not define new protocol elements or 611 operations. Hence no new threats arrive from message exchanges in 612 RELOAD. 614 This document introduces an AOR domain restriction function that must 615 be surveyed by the storing peer. A misconfigured or malicious peer 616 could cause frequent rejects of illegitimate storing requests. 617 However, domain name control relies on a lightweight pattern matching 618 and can be processed prior to validating certificates. Hence no 619 extra burden is introduced for RELOAD peers beyond loads already 620 present in the base protocol. 622 8.2. SIP-Specific Issues 624 8.2.1. Fork Explosion 626 Because SIP includes a forking capability (the ability to retarget to 627 multiple recipients), fork bombs (i.e., attacks using SIP forking to 628 amplify the effect on the intended victims) are a potential DoS 629 concern. However, in the SIP usage of RELOAD, fork bombs are a much 630 lower concern than in a conventional SIP Proxy infrastructure, 631 because the calling party is involved in each retargeting event. It 632 can therefore directly measure the number of forks and throttle at 633 some reasonable number. 635 8.2.2. Malicious Retargeting 637 Another potential DoS attack is for the owner of an attractive AOR to 638 retarget all calls to some victim. This attack is common to SIP and 639 difficult to ameliorate without requiring the target of a SIP 640 registration to authorize all stores. The overhead of that 641 requirement would be excessive and in addition there are good use 642 cases for retargeting to a peer without its explicit cooperation. 644 8.2.3. Misuse of AORs 646 A RELOAD overlay and enrollment service that liberally accept 647 registrations for AORs of domain names unrelated to the overlay 648 instance and without further authorisation, eventually store presence 649 state for misused AORs. An attacker could hijack names, register a 650 bogus presence and attract calls dedicated to a victim that resides 651 within or outside the Overlay Instance. 653 A hijacking of AORs can be mitigated by restricting the name spaces 654 admissible in the Overlay Instance, or by additional verification 655 actions of the enrollment service. To prevent an (exclusive) routing 656 to a bogus registration, a caller can in addition query the DNS (or 657 other discovery services at hand) to search for an alternative 658 presence of the callee in another overlay or a normal SIP 659 infrastructure. 661 8.2.4. Privacy Issues 663 All RELOAD SIP registration data is visible to all nodes in the 664 overlay. Location privacy can be gained from using anonymous GRUUs. 665 Methods of providing anonymity or deploying pseudonyms exist, but are 666 beyond the scope of this document. 668 9. IANA Considerations 670 9.1. Data Kind-ID 672 IANA shall register the following code point in the "RELOAD Data 673 Kind-ID" Registry (cf., [RFC6940]) to represent the SIP-REGISTRATION 674 Kind, as described in Section 7. [NOTE TO IANA/RFC-EDITOR: Please 675 replace RFC-AAAA with the RFC number for this specification in the 676 following list.] 678 +---------------------+------------+----------+ 679 | Kind | Kind-ID | RFC | 680 +---------------------+------------+----------+ 681 | SIP-REGISTRATION | 1 | RFC-AAAA | 682 +---------------------+------------+----------+ 684 9.2. XML Name Space Registration 686 This document registers the following URI for the config XML 687 namespace in the IETF XML registry defined in [RFC3688] 689 URI: urn:ietf:params:xml:ns:p2p:config-base:sip 691 Registrant Contact: The IESG 693 XML: N/A, the requested URI is an XML namespace 695 10. Acknowledgments 697 This document was generated in parts from initial drafts and 698 discussions in the early specification phase of the P2PSIP base 699 protocol. Significant contributions (in alphabetical order) were 700 from David A. Bryan, James Deverick, Marcin Matuszewski, Jonathan 701 Rosenberg, and Marcia Zangrilli, which is gratefully acknowledged. 703 Additional thanks go to all those who helped with ideas, discussions, 704 and reviews, in particular (in alphabetical order) Roland Bless, 705 Michael Chen, Alissa Cooper, Marc Petit-Huguenin, Brian Rosen, Meral 706 Shirazipour, and Matthias Waehlisch. 708 11. References 710 11.1. Normative References 712 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 713 Requirement Levels", BCP 14, RFC 2119, 714 DOI 10.17487/RFC2119, March 1997, 715 . 717 [RFC6940] Jennings, C., Lowekamp, B., Ed., Rescorla, E., Baset, S., 718 and H. Schulzrinne, "REsource LOcation And Discovery 719 (RELOAD) Base Protocol", RFC 6940, DOI 10.17487/RFC6940, 720 January 2014, . 722 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 723 A., Peterson, J., Sparks, R., Handley, M., and E. 724 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 725 DOI 10.17487/RFC3261, June 2002, 726 . 728 [RFC2533] Klyne, G., "A Syntax for Describing Media Feature Sets", 729 RFC 2533, DOI 10.17487/RFC2533, March 1999, 730 . 732 [RFC2738] Klyne, G., "Corrections to "A Syntax for Describing Media 733 Feature Sets"", RFC 2738, DOI 10.17487/RFC2738, December 734 1999, . 736 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 737 DOI 10.17487/RFC3688, January 2004, 738 . 740 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 741 "Indicating User Agent Capabilities in the Session 742 Initiation Protocol (SIP)", RFC 3840, 743 DOI 10.17487/RFC3840, August 2004, 744 . 746 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 747 Resource Identifier (URI): Generic Syntax", STD 66, 748 RFC 3986, DOI 10.17487/RFC3986, January 2005, 749 . 751 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 752 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 753 . 755 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 756 (ICE): A Protocol for Network Address Translator (NAT) 757 Traversal for Offer/Answer Protocols", RFC 5245, 758 DOI 10.17487/RFC5245, April 2010, 759 . 761 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 762 Housley, R., and W. Polk, "Internet X.509 Public Key 763 Infrastructure Certificate and Certificate Revocation List 764 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 765 . 767 [RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., 768 "Managing Client-Initiated Connections in the Session 769 Initiation Protocol (SIP)", RFC 5626, 770 DOI 10.17487/RFC5626, October 2009, 771 . 773 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 774 Agent URIs (GRUUs) in the Session Initiation Protocol 775 (SIP)", RFC 5627, DOI 10.17487/RFC5627, October 2009, 776 . 778 [IEEE-Posix] 779 "IEEE Standard for Information Technology - Portable 780 Operating System Interface (POSIX) - Part 2: Shell and 781 Utilities (Vol. 1)", IEEE Std 1003.2-1992, ISBN 782 1-55937-255-9, January 1993. 784 11.2. Informative References 786 [I-D.ietf-p2psip-concepts] 787 Bryan, D., Matthews, P., Shim, E., Willis, D., and S. 788 Dawkins, "Concepts and Terminology for Peer to Peer SIP", 789 draft-ietf-p2psip-concepts-09 (work in progress), April 790 2016. 792 [RFC5767] Munakata, M., Schubert, S., and T. Ohba, "User-Agent- 793 Driven Privacy Mechanism for SIP", RFC 5767, 794 DOI 10.17487/RFC5767, April 2010, 795 . 797 [I-D.ietf-p2psip-share] 798 Knauf, A., Schmidt, T., Hege, G., and M. Waehlisch, "A 799 Usage for Shared Resources in RELOAD (ShaRe)", draft-ietf- 800 p2psip-share-08 (work in progress), March 2016. 802 Appendix A. Third Party Registration 804 In traditional SIP, the mechanism of a third party registration 805 (i.e., an assistant acting for a boss, changing users register a 806 role-based AOR, ...) is defined in Section 10.2 of [RFC3261]. This 807 is a REGISTER which uses the URI of the third-party in its From 808 header and cannot be translated directly into a P2PSIP registration, 809 because only the owner of the certificate can store a SIP- 810 REGISTRATION in a RELOAD overlay. 812 A way to implement third party registration is by using the extended 813 access control mechanism USER-CHAIN-ACL defined in 814 [I-D.ietf-p2psip-share]. Creating a new Kind "SIP-3P-REGISTRATION" 815 that is ruled by USER-CHAIN-ACL allows the owner of the certificate 816 to delegate the right for registration to individual third parties. 817 In this way, original SIP functionality can be regained without 818 weakening the security control of RELOAD. 820 Appendix B. Change Log 821 B.1. Changes since draft-ietf-p2psip-sip-09 823 o Added subsection on keepalive 825 o Updated references 827 B.2. Changes since draft-ietf-p2psip-sip-08 829 o Added the handling of SIPS 831 o Specified use of Posix regular expressions in configuration 832 document 834 o Added IANA registration for namespace 836 o Editorial polishing 838 o Updated and extended references 840 B.3. Changes since draft-ietf-p2psip-sip-07 842 o Cleared open issues 844 o Clarified use cases after WG discussion 846 o Added configuration document extensions for configurable domain 847 names 849 o Specified format of contact_prefs 851 o Clarified routing to AORs 853 o Extended security section 855 o Added Appendix on Third Party Registration 857 o Added IANA code points 859 o Editorial polishing 861 o Updated and extended references 863 B.4. Changes since draft-ietf-p2psip-sip-06 865 o Added Open Issue 867 Authors' Addresses 869 Cullen Jennings 870 Cisco 871 170 West Tasman Drive 872 MS: SJC-21/2 873 San Jose, CA 95134 874 USA 876 Phone: +1 408 421-9990 877 Email: fluffy@cisco.com 879 Bruce B. Lowekamp 880 Skype 881 Palo Alto, CA 882 USA 884 Email: bbl@lowekamp.net 886 Eric Rescorla 887 RTFM, Inc. 888 2064 Edgewood Drive 889 Palo Alto, CA 94303 890 USA 892 Phone: +1 650 678 2350 893 Email: ekr@rtfm.com 895 Salman A. Baset 896 Columbia University 897 1214 Amsterdam Avenue 898 New York, NY 899 USA 901 Email: salman@cs.columbia.edu 903 Henning Schulzrinne 904 Columbia University 905 1214 Amsterdam Avenue 906 New York, NY 907 USA 909 Email: hgs@cs.columbia.edu 910 Thomas C. Schmidt (editor) 911 HAW Hamburg 912 Berliner Tor 7 913 Hamburg 20099 914 Germany 916 Email: t.schmidt@haw-hamburg.de