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

Versions: 00 01

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


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/