Network Working Group T. Hardie Internet-Draft Qualcomm, Inc. Expires: December 9, 2008 June 9, 2008 Intended Status: Informational Pointers for Peer-to-Peer Overlay Networks, Nodes, or Resources draft-hardie-p2psip-p2p-pointers-00.txt 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 The list of Internet-Draft Shadow Directories can be accessed at This Internet-Draft will expire on December 6, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract Discovering 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 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. While the mechanisms described below each meet similar needs, they are not mutually exclusive; it is expected that each will find some useful deployment during the early days of peer-to-peer overlay deployment. 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 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. This is not meant to imply that infrastructure like the global DNS would always be required. IP addresses from a local address realm or resolution services from within another overlay might, for example, be used instead of the global DNS. They may also be used after a connection has been made to a specific overlay to point to particular resources or nodes. 3. A media-type for structured information on overlays. For email, the web, and other textual media which might carry pointers to overlay networks, one basic mechanism for providing pointers would be to use existing protocols and URI schemes to dereference a resource which contains sufficient information to contact an overlay. For this to be effective, a media type which has an organized method for presenting this data is needed. With such a media type, the pointer can be provided using existing URI schemes, e.g. To contact an overlay, a client can use a URI to retrieve the resource. Once it has completed retrieval, the client can use the structured information it contains to access the overlay. A multipart MIME type could also contain this as a body part, so that it could be carried by applications for which multipart MIME is common practice. Below is a registration of an xml-based MIME type intended for this, application/overlay-pointer+xml, along with a namespace registration, and a schema registration in RelaxNG. The schema as set forth below contains only a single top-level container, called "availableOverlayDetails", with the following elements: ianaName (which may optionally note an ianaAlgorithm); enrollmentServerContact (which contains a host, port, and the relevant transport); availableServices (which contains a list of serviceName elements); and a pointerCreationDate. The "ianaName" and "ianaAlgorithm" are intended to be tokens from the registry set out in Section 6.1. A previous version of this draft contained a joinPolicy element, but it has been removed after it was pointed out that its unstructured data type implied human intervention would be needed to interpret the policy. The author would appreciate discussion on the introduction of either a simpler, token-based set of policies (e.g. "open", "authentication required", or "closed") or policies based on an existing structured policy language. 3.1 Registration of media type application/overlay-pointer+xml. Content-type registration for 'application/overlay-pointer+xml' This specification requests the registration of a new MIME type according to the procedures of RFC 4288 [7] and guidelines in RFC 3023 [5]. MIME media type name: application MIME subtype name: overlay-pointer+xml Mandatory parameters: none Optional parameters: charset Indicates the character encoding of enclosed XML. Encoding considerations: Uses XML, which can employ 8-bit characters, depending on the character encoding used. See RFC 3023 [5], Section 3.2. Security considerations: This content type is designed to carry structured information about overlay networks. In cases where that information should be confidential or subject to access control, it should be protected with mechanisms appropriate to the using protocol. Those might include use of a transport which provides confidentiality, object encryption, or some combination. Interoperability considerations: None Published specification: RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this specification.] Applications which use this media type: Applications providing pointers to overlay networks. Additional information: Magic Number: None File Extension: .odd Macintosh file type code: 'TEXT' Personal and email address for further information: Ted Hardie Intended usage: LIMITED USE Author: This specification is related to the work of the P2PSIP working group, but is an individual submission. Change controller: The IESG 3.2 Schema namespace registration. Overlay Pointer Registration URI: urn:ietf:params:xml:ns:overlaypointer1 Registrant Contact: Ted Hardie. XML: BEGIN Overlay Pointer Namespace

Namespace for OverlayPointer


See RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this specification.].

3.3. Schema Registration URI: urn:ietf:params:xml:ns:overlaypointer1 Registrant Contact: Ted Hardie ( Relax NG Schema: namespace xsd:"" namespace if:"" default namespace ns1:"urn:ietf:params:xml:ns:overlaypointer1" ## ## availableOverlayDetails gives machine-readable pointers ## to enrollment servers or introducers for a p2p overlay network ## element availableOverlayDetails { element typeName { attribute ianaName {xsd:token}, attribute ianaAlgorithm {xsd:token}? ## ## See IANA registry "Peer to Peer Overlay Network Types" ## } element enrollmentServerContact { attribute ip-or-name {if:ip-or-name-content} attribute port {xsd:positiveInteger} attribute protocol {xsd:token} ## ## To distinguish UDP/TCP/etc. ports ## }* element availableServices { attribute serviceName {xsd:text}* } element pointerCreationDate {xsd:date} } 4. Overlay pointer URI. The use of an existing protocol to dereference a descriptive document has the advantage that it may use deployed protocols and URI schemes. The obvious disadvantage is that it introduces a layer of indirection and may introduce delay in the beginning of overlay-specific protocol processing or may frustrate the protocol processing where the dereferencing fails. A URI scheme specifically for overlay pointers is proposed (as a provisional URI registration) to provide for a direct indicator. While this may require configuration (associating the URI scheme with a handler that invokes the overlay processing), that configuration avoids the layer of indirection mentioned above. 4.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 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. The service parameters (if present), indicate the services that an overlay offers. In the following example: overlay://;otype=Pastry;service=mass-storage the URI provides a pointer to an enrollment server for an overlay running the Pastry DHT and providing a service of "mass-storage". While it is assumed that some uses of this URI might create agreements for the meaning of specific services (e.g. p2psip might create an "ICE" service), the current registration treats these as free text so that other users can mint new ones as needed. If discussion during the provisional phase indicates the chance of confusion among these is large, a parameter registry would be created as part of the transition from provisional to permanent registration. 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. 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-00.txt RFC 3986 5. 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. 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 methods discussed above to set the context. 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 5.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 reference to a specific overlay-pointer+xml resource: overlay-node://22301203/;context=""\ ?resource=service-instance In this example, the context is set with a reference to a specific "overlay" URI: overlay-node://22301203/;context="overlay://\ ;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://;otype=pastry"\ ?resource=ICE-services 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 *note limitation from host* overlay-context-uri = HTTP-URI | overlay-URI ;HTTP-URI is defined in RFC 2616 ;overlay-URI in draft-hardie-p2psip-p2p-pointers-00.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 5 of draft-hardie-p2psip-p2p-pointers-00.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. 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-00.txt RFC 3986 6. IANA Considerations This document registers a new media type, an XML schema, two provisional URI schemes, and creates a registry for peer to peer overlay types. The media type registration is in section 3.1. The XML schema is in section 3.2. The first URI scheme registration is in section 4.1; the second is in section 5.1. The registry for peer-to-peer overlay network types is in section 6.1, below. 6.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: Docmentation URI: The registry is to permit new entries using the "Expert Review" guidelines as described in RFC 2434[RFC2434]. 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. 7. Security Considerations Security considerations for each of the three methods given above is documented within each method. 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. 8. Acknowledgments. Vidya Narayanan, Lakshminath Dondeti, and Spencer Dawkins commented on early versions of this document. Ned Freed and Andy Newton provided advice on some elements of the XML registration. The work of Ladislav Lhotka in the FlowMon schema was incorporated in the schema in lieu of re-describing ipv4, ipv6, and hostname types. 9. References 9.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 4234, October 2005. [IF] Lohtka, Ladislav "XML Schema of FlowMon Configuration Data and Statistics", 9.2 Informative References Author's Addresses Ted Hardie Qualcomm, Inc. Email: Intellectual Property Statement 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 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 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.