[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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
   "<Service> . <Domain>" to obtain the service instances that are named
   following the structure "<Instance> . <Service> . <Domain>"
   [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 <Domain> 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 <Service> 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 <Instance> 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 <Instance> 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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/