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 Author/Change controller. Ted Hardie 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 Author/Change controller. Ted Hardie 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