idnits 2.17.1 draft-garcia-p2psip-dns-sd-bootstrapping-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 455. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 466. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 473. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 479. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 22, 2007) is 6025 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.draft-bryan-p2psip-usecases' is defined on line 384, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-cheshire-dnsext-dns-sd-04 == Outdated reference: A later version (-15) exists of draft-cheshire-dnsext-multicastdns-06 -- No information found for draft-bryan-p2psip-reload - is the name correct? -- No information found for draft-hautakorpi-p2psip-hip - is the name correct? == Outdated reference: A later version (-09) exists of draft-ietf-p2psip-concepts-00 -- No information found for draft-jennings-p2psip-asp - is the name correct? -- No information found for draft-lee-sip-dns-sd-uris - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 P2PSIP G. Garcia 3 Internet-Draft Telefonica I+D 4 Intended status: Standards Track October 22, 2007 5 Expires: April 24, 2008 7 P2PSIP bootstrapping using DNS-SD 8 draft-garcia-p2psip-dns-sd-bootstrapping-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 24, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document describes a DNS-based bootstrap mechanism to discover 42 the initial peer or peers needed to join a P2PSIP Overlay. The 43 document specifies the use of DNS Service Discovery (DNS-SD) and the 44 format of the required resource records to support the discovery of 45 P2PSIP peers. This mechanism can be applied in scenarios with DNS 46 servers or combined with multicast DNS to fulfill different proposed 47 P2PSIP use cases. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Why DNS? . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 54 2. Description . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2.1. Domain . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 2.2. Service Identifier . . . . . . . . . . . . . . . . . . . . 6 57 2.3. Instance Identifier . . . . . . . . . . . . . . . . . . . 6 58 2.4. TXT Record fields . . . . . . . . . . . . . . . . . . . . 6 59 2.5. Other use cases beyond peer discovery . . . . . . . . . . 7 60 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 61 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 62 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 63 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 65 6.2. Informative References . . . . . . . . . . . . . . . . . . 9 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 Intellectual Property and Copyright Statements . . . . . . . . . . 11 69 1. Introduction 71 A P2PSIP Overlay [I-D.ietf-p2psip-concepts] is a collection of peers 72 working together to provide the location service needed to establish 73 SIP [RFC3261] sessions between endpoints. In order to join this 74 overlay, a peer needs to discover other peer or peers before starting 75 the joining process; this discovery is what it is called the 76 bootstrap process. 78 [I-D.ietf-p2psip-concepts] enumerates different procedures to locate 79 a bootstrap peer, namely: remembering peers found in previous 80 executions, manual configuration, multicast discovery, or using a 81 centalized server. 83 This document addresses the last two procedures, describing an 84 approach for the bootstrapping in a P2PSIP Overlay based on DNS- 85 Service Discovery (DSN-SD) [I-D.cheshire-dnsext-dns-sd]. According 86 to the terminology defined in [I-D.ietf-p2psip-concepts] this 87 document describes the use of DNS [RFC1035] servers as P2PSIP 88 Bootstrapping servers to find P2PSIP Admitting peers, and also the 89 use of multicast-DNS to find P2PSIP Admitting peers without the need 90 of a P2PSIP Bootstrapping server. 92 DNS-based Service Discovery specifies conventions for how existing 93 DNS resource record types can be used to discover instances of a 94 desired service. For the P2PSIP bootstrapping use case described in 95 this document, the service to be discovered is a P2PSIP peer. DNS-SD 96 does not change the DNS arquitecture or protocol but defines the use 97 and syntax of SRV, PTR and TXT records for this service discovery 98 application. 100 Multicast DNS (mDNS) [I-D.cheshire-dnsext-multicastdns] can be 101 combined with DNS-SD to allow sending DNS queries via multicast to 102 avoid the necessity of any specific infrastructure. This solution 103 provides support for scenarios without connectivity to any 104 centralized DNS server. 106 P2PSIP working group is currently specifying the P2PSIP peer 107 protocol. The bootstrap mechanism specified here is independent of 108 the peer protocol and can be defined in parallel and applied to any 109 proposal. In the context of this draft the protocol identifier is 110 named as "p2psip" because the final protocol is under discussion, but 111 the identifier should reflect the name of the finally selected 112 protocol (for example p2pp). Regarding the related work in the 113 P2PSIP group, [I-D.matthews-p2psip-bootstrap-mechanisms] describes 114 other bootstrap mechanism making use of SIP, and other drafts have 115 already mentioned DNS/DNS-SD as a candidate solution 116 [I-D.ietf-p2psip-concepts] [I-D.bryan-p2psip-reload] 118 [I-D.jennings-p2psip-asp] [I-D.hautakorpi-p2psip-hip]. 120 1.1. Why DNS? 122 There are other protocols that could be suitable for the discovery of 123 P2PSIP peers such as HTTP [RFC2616], SIP [RFC3261], SLP [RFC2165] or 124 SSDP [spec.SSDP]. The selection of a DNS-based approach over those 125 ones is based on these points: 127 o DNS provides support for different P2PSIP use cases: scenarios 128 where connectivity to a centralized infrastructure is available 129 and scenarios where multicast-DNS is available. 131 o It's a lightweight protocol. 133 o DNS infrastructure is widely deployed, probed and available. 135 o Most of the end user equipment already include DNS protocol 136 implementations. 138 o DNS/DNS-SD is already used in the SIP ecosystem [RFC3263] 139 [I-D.lee-sip-dns-sd-uris]. 141 1.2. Requirements Language 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [RFC2119]. 147 2. Description 149 DNS-SD specifies the use of PTR records as an indirection mechanism 150 to enumerate the service instances registered for a specific service 151 type in a domain. A DNS-SD client sends a PTR query for the name 152 " . " to obtain the service instances that are named 153 following the structure " . . " 154 [I-D.cheshire-dnsext-dns-sd]. 156 After the discovery of an instance using those PTR records, the host 157 name and port number for that specific service instance are provided 158 by a SRV record [RFC2782], and additional information can be provided 159 by a TXT record [RFC1035]. 161 The following example shows some PTR, SRV and TXT DNS records to 162 illustrate the concept: 164 _p2psip._udp.example.com. PTR ABCDEF._p2psip._udp.example.com. 165 _p2psip._udp.example.com. PTR 123456._p2psip._udp.example.com. 167 ABCDEF._p2psip._udp.example.com. 168 TXT txtvers=1 peerid=AABBCCDDEEFF 169 overlayid=example.com algorithm=chord 171 ABCDEF._p2psip._udp.example.com. 172 SRV 0 0 7080 bootstrap1.example.com. 174 A peer willing to join an overlay with name "example.com" will send a 175 PTR query for the name "_p2psip._udp.example.com" to obtain the 176 service instances registered for the "p2psip" service type in the 177 domain "example.com" ("ABCDEF._p2psip._udp.example.com." and 178 "123456._p2psip._udp.example.com."). After this, the joining peer 179 will select randomly one of those instances and will ask for the 180 associated TXT record to obtain additional attributes. If the 181 service instance is considered a valid bootstrap peer, the joining 182 peer will finally ask for a SRV record to obtain the host name and 183 port (in this example bootstrap1.example.com and 7080) and initiate 184 the joining process. 186 A peer has two alternatives to send the DNS-SD queries: using a DNS 187 server or using mDNS. They are not incompatible and can be used in 188 parallel. A possible approach is to first try the server mechanism, 189 and try the multicast mechanism only if the first one did not 190 returned any valid result. 192 2.1. Domain 194 The portion of the Service Instance Name contains the DNS 195 domain name where the service instance is registered that can be a 196 conventional subdomain such as "example.com." or "local." if mDNS is 197 used. 199 This field is tied to the P2PSIP Overlay Name 200 [I-D.ietf-p2psip-concepts]. In case of querying a DNS server, the 201 domain used in the PTR query MUST be the Overlay Name corresponding 202 to the overlay that the peer is willing to join (appending the 203 trailing "." if it is not included in the Overlay Name). In case of 204 using mDNS the domain will be "local." and the selection of a peer 205 belonging to the desired overlay MUST be done based on the overlayid 206 attribute included in the TXT record as defined in Section 2.4. 208 This behaviour requires that P2PSIP Overlay Names must be valid 209 domain names. 211 In the example shown in Section 2 the Domain portion is 212 "example.com". 214 2.2. Service Identifier 216 The portion of the Service Instance Name consists of a pair 217 of DNS labels following the established convention for SRV records 218 [RFC2782], namely: the first label of the pair is the Application 219 Protocol Name, and the second label is either "_tcp" or "_udp", 220 depending on the transport protocol used by the application. 222 The Application Protocol Name MUST be "_p2psip". [To be changed when 223 the final P2PSIP Peer Protocol will be selected] 225 The service MUST be published as "_p2psip._tcp" and/or "_p2psip._udp" 226 depending on the supported transport protocols in the P2PSIP Peer 227 Protocol. A client requesting instances of this service can start 228 querying for the default transport protocol according to the Peer 229 Protocol (for example "_p2psip._udp") or querying for both in 230 parallel ("_p2psip._udp" and "_p2psip._tcp"). 232 In the example shown in Section 2 the Service Identifier portion is 233 "_p2psip._udp". 235 2.3. Instance Identifier 237 The portion is a DNS label, containing UTF-8-encoded text, 238 limited to 63 octets in length [I-D.cheshire-dnsext-dns-sd]. The 239 recommendation of using a user-friendly name is not important in this 240 context because the results are not intended to be shown to the 241 users. 243 The portion MUST be filled with the first 30 bytes of the 244 P2PSIP Peer-ID [I-D.ietf-p2psip-concepts] encoded as hexadecimal. If 245 the size of the P2PSIP Peer-ID is bigger than 30 bytes, the first 30 246 bytes MUST be used. 248 In the example shown in Section 2 the Instance Identifier portion is 249 "ABCDEF" for the first instance and "123456" for the second one. 251 2.4. TXT Record fields 253 DNS-SD requires to provide TXT records for the service instances. A 254 TXT record includes name/value pairs to store additional information 255 about the named service instance. Each attribute is encoded in the 256 form "name=value", where the name is a case-insensitive string and 257 the value is opaque binary data, and the total length is 0-255 bytes 258 [I-D.cheshire-dnsext-dns-sd]. 260 The attributes specified in this document for the P2PSIP peer 261 discovery are: 263 txtvers 264 peerid 265 overlayid 266 algorithm 268 The "txtvers" attribute MUST be "txtvers=1" and MUST be the first 269 attribute in the TXT record. 271 The "peerid" attribute is used to include the P2PSIP Peer-ID as a 272 binary value. This attribute is only REQUIRED if the P2PSIP Peer-ID 273 did not fit in the Instance Identifier as described in Section 2.3. 275 The "overlayid" attribute is used to include the P2PSIP Overlay Name. 276 The format of this value is the same used for any DNS subdomain 277 excluding the trailing ".". This attribute is only REQUIRED in case 278 of using multicast DNS and MAY be empty to indicate a default 279 overlay. This attribute SHOULD NOT be included when DNS servers are 280 used. 282 The "algorithm" attribute is used to specify the distributed database 283 algorithm [I-D.ietf-p2psip-concepts] employed by this P2PSIP Overlay. 284 [Format/Values: To be Defined] This algorithm parameter could be also 285 provided by the bootstrap peer as proposed in [I-D.baset-p2psip-p2pp] 286 or by the enrollmeent server as proposed in 287 [I-D.jennings-p2psip-asp]. Including it in the TXT records allows 288 discarding quickly overlays using unsupported algorithms, and offers 289 support for scenarios where no enrollment server is available. The 290 algorithm attribute could include up to two comma-separated 291 algorithms to be used as an algorithm migration procedure. 293 Additional attributes specifying other overlay configuration 294 parameters could be included in future versions of this 295 specification. Vendor-specific extensions should be given names of 296 the form "keyname.company.com=value", using a domain name 297 legitimately registered to the person or organization creating the 298 vendor-specific key [I-D.cheshire-dnsext-dns-sd]. 300 Attributes to include security credentials could be added, but they 301 are excluded in this version to keep low the size of the TXT records 302 as recommended in [I-D.cheshire-dnsext-dns-sd]. 304 2.5. Other use cases beyond peer discovery 306 In addition to the P2PSIP peer discovery, the described procedure 307 also provides these additional features: 309 o P2PSIP Overlay Names discovery in multicast-enabled 310 scenarios, using the overlayid attribute included in the TXT 311 records. 313 o P2PSIP Overlay parameters configuration. In addition to the 314 algorithm attribute, the TXT record could include additional 315 overlay configuration parameters (such as the identifiers 316 size or the hashing algorithm). [To be Elaborated]. 318 3. Security Considerations 320 In multicast DNS environments any endpoint can advertise a P2PSIP 321 service without any restriction. A malicious node could potentially 322 block the access to the overlay advertising the service and 323 simulating a misbehaving overlay later. This specification doesn't 324 define any security mechanism to check the credentials of the 325 discovered peers, delegating that responsability to the P2PSIP Peer 326 Protocol that will be used to join the overlay after the bootstrap 327 process. If the Peer Protocol does not include any security 328 mechanism either, the application should warn about the lack of 329 security in this overlay using some kind of visual notification. 331 4. IANA Considerations 333 [I-D.cheshire-dnsext-dns-sd], Section 19, proposes an IANA allocation 334 policy to assign unique application protocol names. Until the 335 proposal is adopted and in force, Section 19 points to 336 [WWW.DnsSdServiceTypes] for instruction on how to register a unique 337 service type name for DNS-SD. 339 The final P2PSIP Peer Protocol name should be registered as a service 340 type according to the instructions ("p2psip" is used in this document 341 as a generic name until the P2PSIP Peer Protocol will be selected). 343 5. Acknowledgements 345 The author thanks the review and comments from Santiago Prieto, Jesse 346 Kaijen and, Jose Manuel Grosso. 348 6. References 349 6.1. Normative References 351 [I-D.cheshire-dnsext-dns-sd] 352 Krochmal, M. and S. Cheshire, "DNS-Based Service 353 Discovery", draft-cheshire-dnsext-dns-sd-04 (work in 354 progress), August 2006. 356 [I-D.cheshire-dnsext-multicastdns] 357 Cheshire, S. and M. Krochmal, "Multicast DNS", 358 draft-cheshire-dnsext-multicastdns-06 (work in progress), 359 August 2006. 361 [RFC1035] Mockapetris, P., "Domain names - implementation and 362 specification", STD 13, RFC 1035, November 1987. 364 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 365 Requirement Levels", BCP 14, RFC 2119, March 1997. 367 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 368 specifying the location of services (DNS SRV)", RFC 2782, 369 February 2000. 371 [WWW.DnsSdServiceTypes] 372 "http://www.dns-sd.org/ServiceTypes.html". 374 6.2. Informative References 376 [I-D.baset-p2psip-p2pp] 377 Baset, S. and H. Johnston, "Peer-to-Peer Protocol (P2PP)", 378 july 2007. 380 [I-D.bryan-p2psip-reload] 381 Bryan, D., Zangrilli, M., and B. Lowekamp, "REsource 382 LOcation And Discovery (RELOAD)", july 2007. 384 [I-D.draft-bryan-p2psip-usecases] 385 Bryan, D., Shim, E., and B. Lowekamp, "Use Cases for Peer- 386 to-Peer Session Initiation Protocol (P2P SIP)", july 2007. 388 [I-D.hautakorpi-p2psip-hip] 389 Hautakorpi, J. and J. Koskela, "Utilizing HIP (Host 390 Identity Protocol) for P2PSIP (Peer-to-peer Session 391 Initiation Protocol)", july 2007. 393 [I-D.ietf-p2psip-concepts] 394 Bryan, D., "Concepts and Terminology for Peer to Peer 395 SIP", draft-ietf-p2psip-concepts-00 (work in progress), 396 July 2007. 398 [I-D.jennings-p2psip-asp] 399 Jennings, C., Rosenberg, J., and E. Rescola, "Address 400 Settlement by Peer to Peer", july 2007. 402 [I-D.lee-sip-dns-sd-uris] 403 Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 404 specifying the location of services (DNS SRV)", 405 february 2000. 407 [I-D.matthews-p2psip-bootstrap-mechanisms] 408 Cooper, E., Johnston, A., and P. Matthews, "Bootstrap 409 Mechanisms for P2PSIP", february 2007. 411 [RFC2165] Veizades, J., Guttman, E., Perkins, C., and S. Kaplan, 412 "Service Location Protocol", RFC 2165, June 1997. 414 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 415 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 416 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 418 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 419 A., Peterson, J., Sparks, R., Handley, M., and E. 420 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 421 June 2002. 423 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 424 Protocol (SIP): Locating SIP Servers", RFC 3263, 425 June 2002. 427 [spec.SSDP] 428 "Simple Service Discovery Protocol". 430 Author's Address 432 Gustavo Garcia 433 Telefonica I+D 434 Emilio Vargas 435 Madrid, Madrid 436 Spain 438 Phone: +34 913129826 439 Email: ggb@tid.es 441 Full Copyright Statement 443 Copyright (C) The IETF Trust (2007). 445 This document is subject to the rights, licenses and restrictions 446 contained in BCP 78, and except as set forth therein, the authors 447 retain all their rights. 449 This document and the information contained herein are provided on an 450 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 451 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 452 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 453 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 454 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 455 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 457 Intellectual Property 459 The IETF takes no position regarding the validity or scope of any 460 Intellectual Property Rights or other rights that might be claimed to 461 pertain to the implementation or use of the technology described in 462 this document or the extent to which any license under such rights 463 might or might not be available; nor does it represent that it has 464 made any independent effort to identify any such rights. Information 465 on the procedures with respect to rights in RFC documents can be 466 found in BCP 78 and BCP 79. 468 Copies of IPR disclosures made to the IETF Secretariat and any 469 assurances of licenses to be made available, or the result of an 470 attempt made to obtain a general license or permission for the use of 471 such proprietary rights by implementers or users of this 472 specification can be obtained from the IETF on-line IPR repository at 473 http://www.ietf.org/ipr. 475 The IETF invites any interested party to bring to its attention any 476 copyrights, patents or patent applications, or other proprietary 477 rights that may cover technology that may be required to implement 478 this standard. Please address the information to the IETF at 479 ietf-ipr@ietf.org. 481 Acknowledgment 483 Funding for the RFC Editor function is provided by the IETF 484 Administrative Support Activity (IASA).