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