P2PSIP G. Garcia Internet-Draft Telefonica I+D Intended status: Standards Track October 22, 2007 Expires: April 24, 2008 P2PSIP bootstrapping using DNS-SD draft-garcia-p2psip-dns-sd-bootstrapping-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 24, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document describes a DNS-based bootstrap mechanism to discover the initial peer or peers needed to join a P2PSIP Overlay. The document specifies the use of DNS Service Discovery (DNS-SD) and the format of the required resource records to support the discovery of P2PSIP peers. This mechanism can be applied in scenarios with DNS servers or combined with multicast DNS to fulfill different proposed P2PSIP use cases. Garcia Expires April 24, 2008 [Page 1] Internet-Draft P2PSIP bootstrapping using DNS-SD October 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Why DNS? . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Description . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Domain . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Service Identifier . . . . . . . . . . . . . . . . . . . . 6 2.3. Instance Identifier . . . . . . . . . . . . . . . . . . . 6 2.4. TXT Record fields . . . . . . . . . . . . . . . . . . . . 6 2.5. Other use cases beyond peer discovery . . . . . . . . . . 7 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Garcia Expires April 24, 2008 [Page 2] Internet-Draft P2PSIP bootstrapping using DNS-SD October 2007 1. Introduction A P2PSIP Overlay [I-D.ietf-p2psip-concepts] is a collection of peers working together to provide the location service needed to establish SIP [RFC3261] sessions between endpoints. In order to join this overlay, a peer needs to discover other peer or peers before starting the joining process; this discovery is what it is called the bootstrap process. [I-D.ietf-p2psip-concepts] enumerates different procedures to locate a bootstrap peer, namely: remembering peers found in previous executions, manual configuration, multicast discovery, or using a centalized server. This document addresses the last two procedures, describing an approach for the bootstrapping in a P2PSIP Overlay based on DNS- Service Discovery (DSN-SD) [I-D.cheshire-dnsext-dns-sd]. According to the terminology defined in [I-D.ietf-p2psip-concepts] this document describes the use of DNS [RFC1035] servers as P2PSIP Bootstrapping servers to find P2PSIP Admitting peers, and also the use of multicast-DNS to find P2PSIP Admitting peers without the need of a P2PSIP Bootstrapping server. DNS-based Service Discovery specifies conventions for how existing DNS resource record types can be used to discover instances of a desired service. For the P2PSIP bootstrapping use case described in this document, the service to be discovered is a P2PSIP peer. DNS-SD does not change the DNS arquitecture or protocol but defines the use and syntax of SRV, PTR and TXT records for this service discovery application. Multicast DNS (mDNS) [I-D.cheshire-dnsext-multicastdns] can be combined with DNS-SD to allow sending DNS queries via multicast to avoid the necessity of any specific infrastructure. This solution provides support for scenarios without connectivity to any centralized DNS server. P2PSIP working group is currently specifying the P2PSIP peer protocol. The bootstrap mechanism specified here is independent of the peer protocol and can be defined in parallel and applied to any proposal. In the context of this draft the protocol identifier is named as "p2psip" because the final protocol is under discussion, but the identifier should reflect the name of the finally selected protocol (for example p2pp). Regarding the related work in the P2PSIP group, [I-D.matthews-p2psip-bootstrap-mechanisms] describes other bootstrap mechanism making use of SIP, and other drafts have already mentioned DNS/DNS-SD as a candidate solution [I-D.ietf-p2psip-concepts] [I-D.bryan-p2psip-reload] Garcia Expires April 24, 2008 [Page 3] Internet-Draft P2PSIP bootstrapping using DNS-SD October 2007 [I-D.jennings-p2psip-asp] [I-D.hautakorpi-p2psip-hip]. 1.1. Why DNS? There are other protocols that could be suitable for the discovery of P2PSIP peers such as HTTP [RFC2616], SIP [RFC3261], SLP [RFC2165] or SSDP [spec.SSDP]. The selection of a DNS-based approach over those ones is based on these points: o DNS provides support for different P2PSIP use cases: scenarios where connectivity to a centralized infrastructure is available and scenarios where multicast-DNS is available. o It's a lightweight protocol. o DNS infrastructure is widely deployed, probed and available. o Most of the end user equipment already include DNS protocol implementations. o DNS/DNS-SD is already used in the SIP ecosystem [RFC3263] [I-D.lee-sip-dns-sd-uris]. 1.2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Description DNS-SD specifies the use of PTR records as an indirection mechanism to enumerate the service instances registered for a specific service type in a domain. A DNS-SD client sends a PTR query for the name " . " to obtain the service instances that are named following the structure " . . " [I-D.cheshire-dnsext-dns-sd]. After the discovery of an instance using those PTR records, the host name and port number for that specific service instance are provided by a SRV record [RFC2782], and additional information can be provided by a TXT record [RFC1035]. The following example shows some PTR, SRV and TXT DNS records to illustrate the concept: Garcia Expires April 24, 2008 [Page 4] Internet-Draft P2PSIP bootstrapping using DNS-SD October 2007 _p2psip._udp.example.com. PTR ABCDEF._p2psip._udp.example.com. _p2psip._udp.example.com. PTR 123456._p2psip._udp.example.com. ABCDEF._p2psip._udp.example.com. TXT txtvers=1 peerid=AABBCCDDEEFF overlayid=example.com algorithm=chord ABCDEF._p2psip._udp.example.com. SRV 0 0 7080 bootstrap1.example.com. A peer willing to join an overlay with name "example.com" will send a PTR query for the name "_p2psip._udp.example.com" to obtain the service instances registered for the "p2psip" service type in the domain "example.com" ("ABCDEF._p2psip._udp.example.com." and "123456._p2psip._udp.example.com."). After this, the joining peer will select randomly one of those instances and will ask for the associated TXT record to obtain additional attributes. If the service instance is considered a valid bootstrap peer, the joining peer will finally ask for a SRV record to obtain the host name and port (in this example bootstrap1.example.com and 7080) and initiate the joining process. A peer has two alternatives to send the DNS-SD queries: using a DNS server or using mDNS. They are not incompatible and can be used in parallel. A possible approach is to first try the server mechanism, and try the multicast mechanism only if the first one did not returned any valid result. 2.1. Domain The portion of the Service Instance Name contains the DNS domain name where the service instance is registered that can be a conventional subdomain such as "example.com." or "local." if mDNS is used. This field is tied to the P2PSIP Overlay Name [I-D.ietf-p2psip-concepts]. In case of querying a DNS server, the domain used in the PTR query MUST be the Overlay Name corresponding to the overlay that the peer is willing to join (appending the trailing "." if it is not included in the Overlay Name). In case of using mDNS the domain will be "local." and the selection of a peer belonging to the desired overlay MUST be done based on the overlayid attribute included in the TXT record as defined in Section 2.4. This behaviour requires that P2PSIP Overlay Names must be valid domain names. In the example shown in Section 2 the Domain portion is Garcia Expires April 24, 2008 [Page 5] Internet-Draft P2PSIP bootstrapping using DNS-SD October 2007 "example.com". 2.2. Service Identifier The portion of the Service Instance Name consists of a pair of DNS labels following the established convention for SRV records [RFC2782], namely: the first label of the pair is the Application Protocol Name, and the second label is either "_tcp" or "_udp", depending on the transport protocol used by the application. The Application Protocol Name MUST be "_p2psip". [To be changed when the final P2PSIP Peer Protocol will be selected] The service MUST be published as "_p2psip._tcp" and/or "_p2psip._udp" depending on the supported transport protocols in the P2PSIP Peer Protocol. A client requesting instances of this service can start querying for the default transport protocol according to the Peer Protocol (for example "_p2psip._udp") or querying for both in parallel ("_p2psip._udp" and "_p2psip._tcp"). In the example shown in Section 2 the Service Identifier portion is "_p2psip._udp". 2.3. Instance Identifier The portion is a DNS label, containing UTF-8-encoded text, limited to 63 octets in length [I-D.cheshire-dnsext-dns-sd]. The recommendation of using a user-friendly name is not important in this context because the results are not intended to be shown to the users. The portion MUST be filled with the first 30 bytes of the P2PSIP Peer-ID [I-D.ietf-p2psip-concepts] encoded as hexadecimal. If the size of the P2PSIP Peer-ID is bigger than 30 bytes, the first 30 bytes MUST be used. In the example shown in Section 2 the Instance Identifier portion is "ABCDEF" for the first instance and "123456" for the second one. 2.4. TXT Record fields DNS-SD requires to provide TXT records for the service instances. A TXT record includes name/value pairs to store additional information about the named service instance. Each attribute is encoded in the form "name=value", where the name is a case-insensitive string and the value is opaque binary data, and the total length is 0-255 bytes [I-D.cheshire-dnsext-dns-sd]. Garcia Expires April 24, 2008 [Page 6] Internet-Draft P2PSIP bootstrapping using DNS-SD October 2007 The attributes specified in this document for the P2PSIP peer discovery are: txtvers peerid overlayid algorithm The "txtvers" attribute MUST be "txtvers=1" and MUST be the first attribute in the TXT record. The "peerid" attribute is used to include the P2PSIP Peer-ID as a binary value. This attribute is only REQUIRED if the P2PSIP Peer-ID did not fit in the Instance Identifier as described in Section 2.3. The "overlayid" attribute is used to include the P2PSIP Overlay Name. The format of this value is the same used for any DNS subdomain excluding the trailing ".". This attribute is only REQUIRED in case of using multicast DNS and MAY be empty to indicate a default overlay. This attribute SHOULD NOT be included when DNS servers are used. The "algorithm" attribute is used to specify the distributed database algorithm [I-D.ietf-p2psip-concepts] employed by this P2PSIP Overlay. [Format/Values: To be Defined] This algorithm parameter could be also provided by the bootstrap peer as proposed in [I-D.baset-p2psip-p2pp] or by the enrollmeent server as proposed in [I-D.jennings-p2psip-asp]. Including it in the TXT records allows discarding quickly overlays using unsupported algorithms, and offers support for scenarios where no enrollment server is available. The algorithm attribute could include up to two comma-separated algorithms to be used as an algorithm migration procedure. Additional attributes specifying other overlay configuration parameters could be included in future versions of this specification. Vendor-specific extensions should be given names of the form "keyname.company.com=value", using a domain name legitimately registered to the person or organization creating the vendor-specific key [I-D.cheshire-dnsext-dns-sd]. Attributes to include security credentials could be added, but they are excluded in this version to keep low the size of the TXT records as recommended in [I-D.cheshire-dnsext-dns-sd]. 2.5. Other use cases beyond peer discovery In addition to the P2PSIP peer discovery, the described procedure also provides these additional features: Garcia Expires April 24, 2008 [Page 7] Internet-Draft P2PSIP bootstrapping using DNS-SD October 2007 o P2PSIP Overlay Names discovery in multicast-enabled scenarios, using the overlayid attribute included in the TXT records. o P2PSIP Overlay parameters configuration. In addition to the algorithm attribute, the TXT record could include additional overlay configuration parameters (such as the identifiers size or the hashing algorithm). [To be Elaborated]. 3. Security Considerations In multicast DNS environments any endpoint can advertise a P2PSIP service without any restriction. A malicious node could potentially block the access to the overlay advertising the service and simulating a misbehaving overlay later. This specification doesn't define any security mechanism to check the credentials of the discovered peers, delegating that responsability to the P2PSIP Peer Protocol that will be used to join the overlay after the bootstrap process. If the Peer Protocol does not include any security mechanism either, the application should warn about the lack of security in this overlay using some kind of visual notification. 4. IANA Considerations [I-D.cheshire-dnsext-dns-sd], Section 19, proposes an IANA allocation policy to assign unique application protocol names. Until the proposal is adopted and in force, Section 19 points to [WWW.DnsSdServiceTypes] for instruction on how to register a unique service type name for DNS-SD. The final P2PSIP Peer Protocol name should be registered as a service type according to the instructions ("p2psip" is used in this document as a generic name until the P2PSIP Peer Protocol will be selected). 5. Acknowledgements The author thanks the review and comments from Santiago Prieto, Jesse Kaijen and, Jose Manuel Grosso. 6. References Garcia Expires April 24, 2008 [Page 8] Internet-Draft P2PSIP bootstrapping using DNS-SD October 2007 6.1. Normative References [I-D.cheshire-dnsext-dns-sd] Krochmal, M. and S. Cheshire, "DNS-Based Service Discovery", draft-cheshire-dnsext-dns-sd-04 (work in progress), August 2006. [I-D.cheshire-dnsext-multicastdns] Cheshire, S. and M. Krochmal, "Multicast DNS", draft-cheshire-dnsext-multicastdns-06 (work in progress), August 2006. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [WWW.DnsSdServiceTypes] "http://www.dns-sd.org/ServiceTypes.html". 6.2. Informative References [I-D.baset-p2psip-p2pp] Baset, S. and H. Johnston, "Peer-to-Peer Protocol (P2PP)", july 2007. [I-D.bryan-p2psip-reload] Bryan, D., Zangrilli, M., and B. Lowekamp, "REsource LOcation And Discovery (RELOAD)", july 2007. [I-D.draft-bryan-p2psip-usecases] Bryan, D., Shim, E., and B. Lowekamp, "Use Cases for Peer- to-Peer Session Initiation Protocol (P2P SIP)", july 2007. [I-D.hautakorpi-p2psip-hip] Hautakorpi, J. and J. Koskela, "Utilizing HIP (Host Identity Protocol) for P2PSIP (Peer-to-peer Session Initiation Protocol)", july 2007. [I-D.ietf-p2psip-concepts] Bryan, D., "Concepts and Terminology for Peer to Peer SIP", draft-ietf-p2psip-concepts-00 (work in progress), July 2007. Garcia Expires April 24, 2008 [Page 9] Internet-Draft P2PSIP bootstrapping using DNS-SD October 2007 [I-D.jennings-p2psip-asp] Jennings, C., Rosenberg, J., and E. Rescola, "Address Settlement by Peer to Peer", july 2007. [I-D.lee-sip-dns-sd-uris] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", february 2000. [I-D.matthews-p2psip-bootstrap-mechanisms] Cooper, E., Johnston, A., and P. Matthews, "Bootstrap Mechanisms for P2PSIP", february 2007. [RFC2165] Veizades, J., Guttman, E., Perkins, C., and S. Kaplan, "Service Location Protocol", RFC 2165, June 1997. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. [spec.SSDP] "Simple Service Discovery Protocol". Author's Address Gustavo Garcia Telefonica I+D Emilio Vargas Madrid, Madrid Spain Phone: +34 913129826 Email: ggb@tid.es Garcia Expires April 24, 2008 [Page 10] Internet-Draft P2PSIP bootstrapping using DNS-SD October 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Garcia Expires April 24, 2008 [Page 11]