Network Working Group T. Hardie
Internet-Draft V. Narayanan
Expires: September 9, 2009 Qualcomm, Inc.
March 9, 2009
Intended Status: Experimental
Pointers for Peer-to-Peer Overlay Networks, Nodes, or Resources
draft-hardie-p2psip-p2p-pointers-01.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 September 6, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Hardie & Narayanan Expires September 9, 2009 [Page 1]
Internet-Draft Pointers for Peer-to-Peer Overlay Networks March 2009
Abstract
Identifying overlay networks and the resources found within in them
presents a number of bootstrapping problems. While those hard
problems are under discussion, this draft proposes a small set of
URI-based mechanisms which are intended to be generically useful for
providing pointers to peer-to-peer overlay networks in web pages,
email messages, and other textual media.
1. Requirements notation
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 [RFC 2119].
2. Introduction
This document proposes URI-based mechanisms for providing pointers
to peer-to-peer overlay networks and resources. These mechanisms are
intended to be useful in textual media (web pages, email messages,
etc.). While it is commonly true that peer-to-peer networks avoid
external dependencies on the DNS or other infrastructure, these
mechanisms are intended to be useful in contexts where that
infrastructure is present but no connection to a specific overlay
has yet been made. These mechanisms are intended to be useable, in
other words, as external pointers to specific overlays, their
nodes, and their resources. The same mechanisms may be useful
once a connection to a specific overlay has been made, as a
generic mechanism for referring to overlay nodes, resources, or
other characteristics.
3. Overlay pointer URI.
A URI scheme specifically for overlay pointers is proposed
(as a provisional URI registration) to provide for a direct indicator
of the existence and certain core characteristics of an overlay.
The use of this scheme requires configuration which associates the
scheme with a handler that invokes overlay processing. The
possession of this URI does not guarantee that the holder of the
URI will be able to enroll in a specific overlay.
Hardie & Narayanan Expires September 9, 2009 [Page 2]
^L
Internet-Draft Pointers for Peer-to-Peer Overlay Networks March 2009
3.1 Registration template for an overlay URI.
URI scheme name.
"overlay" is requested
Status.
provisional
URI scheme syntax.
overlay-URI = overlay-scheme "://" authority
"/"";" otype *( ";" service)
; authority as defined in RFC3986
overlay-scheme = "overlay"
otype = "otype=" token
;valid tokens are in the "Peer to Peer Overlay
;Network types" IANA registry
service="service=" *1ALPHANUM
; While this is free text, this document
; describes an IANA registry "Peer to Peer Overlay
; service types" with a set of well-known
; services.
URI scheme semantics.
The authority section of the URI contains a hostname or IP
address associated with an enrollment server or introducer for
the overlay. It may also contain a port on which enrollment
services are running. The otype, or overlay type, indicates the
registered type for the overlay (e.g., Pastry); these are tokens
registered by IANA, in the "Peer to Peer Overlay Network types"
registry created by this document. The service parameters (if
present), indicate the services that an overlay offers. In the
following example:
overlay://example.org/;otype=Pastry;service=iana.reload-storage
the URI provides a pointer to an enrollment server for an
overlay running the Pastry DHT and providing a service of
"iana.reloadq-storage". The use of the string "iana." indicates
that the specification of the service appears in the IANA
registry "Peer to Peer Overlay service types" described
later in this document; the field is otherwise free text.
Encoding considerations.
No special considerations
Applications/protocols that use this URI scheme name.
Applications which need to provide a protocol pointer to an
overlay network's enrollment servers or introducers.
Hardie & Narayanan Expires September 9, 2009 [Page 3]
^L
Internet-Draft Pointers for Peer-to-Peer Overlay Networks March 2009
Interoperability considerations.
None known.
Security considerations.
As currently constructed, this URI scheme's authority section is
expected to contain a hostname or IP address . It would be
possible to have SRV records or a DDDS application choose entry
points based on the authority's DNS name instead. That would
provide a better chance that a DoS attack against a specific
introducer or enrollment server could not eliminate the ability
of new nodes to join an overlay. It does, however, create
another layer of indirection and make the use of an IP address
in the authority section problematic; in this instance, the
ability of someone controlling the zone to add or update the
records associated with a server instance was judged a better
fit for the problem space.
Contact.
Ted Hardie <hardie@qualcomm.com>
Author/Change controller.
Ted Hardie <hardie@qualcomm.com>
References.
draft-hardie-p2psip-p2p-pointers-01.txt
RFC 3986
Hardie & Narayanan Expires September 9, 2009 [Page 4]
^L
Internet-Draft Pointers for Peer-to-Peer Overlay Networks March 2009
4. Overlay node pointer URI.
Among the bootstrapping problems presented by peer to peer overlays
is the lack of a generic way to represent nodes within an overlay,
resources stored at that node or resources stored within the
overlay. A URI scheme focused on the node and its resources is
proposed here, along with context-dependent ways to use it that
allow for it to represent resources stored within an overlay. This
URI scheme registration is intended to be provisional. It contains
a significant limitation that deserves to be highlighted: although
the typical "host" portion of an authority section for a URI allows
DNS names, IP addresses, or a registered name, this proposal limits
the authority section to registered names which are current node
identifiers for a specific overlay. This does not limit the use of
ports or other aspects of the usual authority section for a URI.
A second point to note is that the absence of an authority section
indicates that the resource noted in the query section is somewhere
within the overlay, but the URI does not establish at which
node-id. Where the URI contains a pointer to the overlay context,
this provides a mechanism to give an external reference to a
resource within a specific overlay without referencing a node-id.
Within the context of a specific overlay, this would allow the
overlay client to invoke overlay-specific search mechanisms to
establish one or more appropriate node-ids offering the service or
hosting the resource (and thus to construct "full" pointer URIs).
A basic example of the node-id use is:
overlay-node://22301203/?resource=example.iso
The authority points to a specific node-id; the query section
points to a resource stored at that node. It is, however, valid
only within a context that already understands what overlay that
node occurs in. In order to create a context that establishes
that, this registration re-uses the overlay URI discussed above to
set the context.
Hardie & Narayanan Expires September 9, 2009 [Page 5]
^L
Internet-Draft Pointers for Peer-to-Peer Overlay Networks March 2009
The following examples are presented without percent-encoding to
highlight the relation to the sections above, but percent-encoding
of the context-setting URIs would be required. See Section 4.1 for
the actual syntax.
Note that the following lines use \ to indicate that the full URI
is carried across two lines.
In this example, the context is set with a reference to a specific
"overlay" URI:
overlay-node://22301203/;context="overlay://enrollment.example.org/\
;otype=pastry"?resource=example.iso
In this example, the context is set with reference to a specific
"overlay" URI, but no node ID is given. This is how you would
construct a URI for "ICE services, offered within a specific
overlay":
overlay-node:///;context="overlay://introducer.example.org/;otype\
=pastry"?resource=iana.ICE
Note that these examples use "resource=" as a common part of the
query string, but that this is a narrative convenience rather than
a requirement. Query strings may contain any elements permitted
by RFC 3986, and they may omit "resource=". "resource=" is simply
a documentation convention, and it might or might not be useful
for constructing queries within any specific overlay.
Hardie & Narayanan Expires September 9, 2009 [Page 6]
^L
Internet-Draft Pointers for Peer-to-Peer Overlay Networks March 2009
5.1 Registration template for an overlay node pointer URI.
URI scheme name.
"overlay-node" is requested
Status.
provisional
URI scheme syntax.
overlay-node-URI = overlay-node-scheme "://" [overlay-authority]
"/" [";"" context=" overlay-context-uri] ["?" query]
["#"fragment]
; query and fragment are as defined in rfc 3986
overlay-scheme = "overlay-node"
overlay-authority= [ userinfo "@" ] reg-name [ ":" port ]
;reg-name is defined in RFC 3986- nb limitation from host
overlay-context-uri = overlay-URI
;overlay-URI in draft-hardie-p2psip-p2p-pointers-01.txt
otype = "otype=" token
;valid tokens are in the "Peer to Peer
;Overlay Network types" IANA registry
service="service=" *1ALPHANUM
URI scheme semantics.
See section 4 of draft-hardie-p2psip-p2p-pointers-01.txt.
Encoding considerations.
No special considerations
Applications/protocols that use this URI scheme name.
Applications which need to provide a protocol pointer to an
overlay network node, its resources, or resources stored within
a specific overlay network.
Interoperability considerations.
None known.
Hardie & Narayanan Expires September 9, 2009 [Page 7]
^L
Internet-Draft Pointers for Peer-to-Peer Overlay Networks March 2009
Security considerations.
The authority section contains a node-id valid within a specific
overlay. Global context is not required; if present, it is
given using the "context" parameter. Where it is not present
and the context is incorrect, it is possible that the effort to
retrieve a resource will fail or will return incorrect results.
Careful naming of resources within an overlay may mitigate this
problem, but any security system must be aware that overlay-node
URIs without a context parameter have different characteristics
from URIs that fit in within a known global context like the
DNS.
Contact.
Ted Hardie <hardie@qualcomm.com>
Author/Change controller.
Ted Hardie <hardie@qualcomm.com>
References.
draft-hardie-p2psip-p2p-pointers-01.txt
RFC 3986
5. IANA Considerations
This document registers two provisional URI schemes and creates two
registries. The first URI scheme registration is in section 3.1;
the second is in section 4.1. The registry for peer-to-peer
overlay network types is in section 5.1, below. The registry for
Peer to Peer Overlay service types is in section 5.2, below.
5.1 Peer-to-peer overlay network type registry.
IANA is requested to create a registry titled "Peer-to-Peer Overlay
Network Types". The Registry shall have the following fields: Type
Name, Algorithm Type, Record Creator, Record Creator contact,
Documentation URI. An example is given below:
Type Name: Pastry
Algorithm Type: Distributed Hash Table
Record Creator: IESG
Record Creator contact: iesg@ietf.org
Docmentation URI: http://freepastry.org/
Hardie & Narayanan Expires September 9, 2009 [Page 8]
^L
Internet-Draft Pointers for Peer-to-Peer Overlay Networks March 2009
The registry is to permit new entries using the "Expert Review"
guidelines as described in RFC 5226[IANA]. The Expert Reviewer is
requested to pay particular attention to the Algorithm Type field
and to limit the creation of new values for that field where the
algorithms are variants of a fundamental type. Since the main
purpose of the registry is to enable clients to determine their
interoperability with a specific mechanism, however, the Expert
Reviewer should not limit the creation of new Type Names, except
where the documentation provided either clearly indicates full
interoperability with an existing Type Name of is of insufficient
completeness to make any determination on interoperability. The
Record Creator contact field SHOULD contain at least an email
address and MAY contain any other contact data desired by the
Record Creator.
5.2 Peer-to-Peer Ovleray Service Types.
IANA is requested to create a registry titled "Peer-to-Peer Overlay
Service Types". The Registry shall have the following fields:
Service Name, Record Creator, Record Creator contact, and
Documentation URI. All registered entries should have the initial
string "iana.", as this will be used to distinguished registered
from unregistered service types. An example is given below:
Service Name: iana.reload-storage
Record Creator: IESG
Record Creator contact: iesg@ietf.org
Docmentation URI:
http://www.ietf.org/internet-drafts/draft-ietf-p2psip-base-01.txt
The registry is to permit new entries using the "Expert Review"
guidelines as described in RFC 5226[IANA].
Hardie & Narayanan Expires September 9, 2009 [Page 9]
^L
Internet-Draft Pointers for Peer-to-Peer Overlay Networks March 2009
6. Security Considerations
The general security issue here is that providing a pointer signals
a point at which the overlay may be touched or resource retrieved;
disclosure of that indicates either a point of attack, where a
specific resource resides, or both.
For overlay networks concerned with chosen location attacks,
disclosure of a service or resources at a particular node-id may be
problematic, as it might assist the attacker in choosing a location
to attack. For an attacker with access to multiple clients or the
ability to mint new identities, this is not a large advantage, as
the attacker could join the overlay, collect the same information,
and then re-join.
7. Acknowledgments.
Lakshminath Dondeti, Spencer Dawkins, Ned Freed, and Andy Newton
provided comments on earlier versions of this document. Saumitra
Das provided review of this version.
8. References
8.1 Normative References
[KeyWords] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[URI] Berners-Lee T. et al, "URI Generic Syntax", RFC 3986, STD 66,
January 2005.
[HTTP] Fielding, R. et al, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616 June 1999.
[URI-REG] Hansen, T. et al. "Guidelines and Registration Procedures
for New URI Schemes", RFC 4395, BCP 115, February 2006.
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 5234, January 2008.
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 5226, May 2008.
9.2 Informative References
Hardie & Narayanan Expires September 9, 2009 [Page 10]
^L
Internet-Draft Pointers for Peer-to-Peer Overlay Networks March 2009
Authors' Addresses
Ted Hardie
Qualcomm, Inc.
Email: hardie@qualcomm.com
Vidya Narayanan
Qualcomm, Inc.
Email: vidyan@qualcomm.com