Network Working Group T. Hardie
Internet-Draft Qualcomm, Inc.
Expires: July 27, 2008 January 27, 2008
Intended Status: Informational
Mechanisms for use in pointing to overlay networks, nodes, or resources
draft-hardie-p2poverlay-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
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 July 27, 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.
Hardie Expires July 27, 2008 [Page 1]
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. Overlay description media type.
For email, the web, and other textual media which might carry
pointers to overlay networks, one basic mechanism for providing
pointers is to use existing protocols and URI schemes to
dereference a resource which contains sufficient information to
contact an overlay. For this to be maximally 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. http://example.org/overlay-pointer.odd.
A client can use that URI to retrieve the resource. Once it has
the resource, the client can use the structured information it
contains to access the overlay. A multipart MIME type could also
contain this MIME type, 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 may contain one or more dnsName,
ipv6Address, or ipv4Address elements); availableServices (which
contains a list of serviceName elements); a joinPolicy (which
contains a list of one or more restrictionsImposed); and a
Hardie Expires July 27, 2008 [Page 2]
pointerCreationDate. The "ianaName" and "ianaAlgorithm" are
intended to be tokens from the registry set out in Section 6.1;
most of the rest are either the standard data types for XML
constructs of their type or simply text. Clearly, many other
additions or choices are possible here, and the author expects
robust discussion to inform the final schema.
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'
Hardie Expires July 27, 2008 [Page 3]
Personal and email address for further information: Ted Hardie
hardie@qualcomm.com
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 <iesg@ietf.org>
3.2 Schema namespace registration.
Overlay Pointer Registration
URI: urn:ietf:params:xml:ns:overlaypointer1
Registrant Contact: Ted Hardie.
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Overlay Pointer Namespace</title>
</head>
<body>
<h1>Namespace for OverlayPointer</h1>
<h2>urn:ietf:params:xml:ns:overlaypointer1</h2>
<p>See <a href="[URL of published RFC]">RFCXXXX
[NOTE TO IANA/RFC-EDITOR:
Please replace XXXX with the RFC number of this
specification.]</a>.</p>
</body>
</html>
Hardie Expires July 27, 2008 [Page 4]
3.3. Schema Registration
URI: urn:ietf:params:xml:ns:overlaypointer1
Registrant Contact: Ted Hardie
(hardie@qualcomm.com).
Relax NG Schema:
<?xml version="1.0" encoding="UTF-8"?> <grammar
ns="urn:ietf:params:xml:ns:overlaypointer1"
xmlns="http://relaxng.org/ns/structure/1.0"
xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
<div>
<a:documentation> Overlay Pointer Description
</a:documentation>
<define name="availableOverlayDetails">
element name="availableOverlayDetails"{
element typeName {
attribute ianaName {text},
attribute ianaAlgorithm {text}?
}
element enrollmentServerContact {
attribute dnsName {hostname} |
attribute ipv6Address {text} |
attribute ipv4Address {IP}
}*
element availableServices {
attribute serviceName {text}*
}
element joinPolicy {
attribute restrictionsImposed {text}*
}
element pointerCreationDate {date}
}
</div>
</grammar>
[EDITOR's Note: the "text" type of ipv6Address is a hack, because
IP seemed to be limited to IPv4. A better data type should
clearly be used here. There are also two different forms for
RelaxNG schemas, and input on which one to use as the normative
version is requested.]
Hardie Expires July 27, 2008 [Page 5]
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://enrollment.example.org/;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, a
parameter registry would be created as part of the transition
from provisional to permanent registration.
Hardie Expires July 27, 2008 [Page 6]
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 IPv6 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-p2poverlay-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.
Hardie Expires July 27, 2008 [Page 7]
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 two 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="http://introducer.example.net/example.odd"\
?resource=service-instance
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=ICE-services
Hardie Expires July 27, 2008 [Page 8]
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-p2poverlay-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-p2poverlay-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 <hardie@qualcomm.com>
Author/Change controller.
Ted Hardie <hardie@qualcomm.com>
References.
draft-hardie-p2poverlay-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.
Hardie Expires July 27, 2008 [Page 9]
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: iesg@ietf.org
Docmentation URI: http://freepastry.org/
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.
Hardie Expires July 27, 2008 [Page 10]
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.
9.2 Informative References
Author's Addresses
Ted Hardie
Qualcomm, Inc.
Email: hardie@qualcomm.com
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
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.
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.