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]