idnits 2.17.00 (12 Aug 2021) /tmp/idnits43942/draft-hardie-p2psip-p2p-pointers-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 1 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 9, 2009) is 4814 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC 2119' is mentioned on line 59, but not defined == Unused Reference: 'KeyWords' is defined on line 384, but no explicit reference was found in the text == Unused Reference: 'URI' is defined on line 387, but no explicit reference was found in the text == Unused Reference: 'HTTP' is defined on line 390, but no explicit reference was found in the text == Unused Reference: 'URI-REG' is defined on line 393, but no explicit reference was found in the text == Unused Reference: 'ABNF' is defined on line 396, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (ref. 'HTTP') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 4395 (ref. 'URI-REG') (Obsoleted by RFC 7595) ** Obsolete normative reference: RFC 5226 (ref. 'IANA') (Obsoleted by RFC 8126) Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group T. Hardie 2 Internet-Draft V. Narayanan 3 Expires: September 9, 2009 Qualcomm, Inc. 4 March 9, 2009 6 Intended Status: Experimental 8 Pointers for Peer-to-Peer Overlay Networks, Nodes, or Resources 9 draft-hardie-p2psip-p2p-pointers-01.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on September 6, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 Identifying overlay networks and the resources found within in them 48 presents a number of bootstrapping problems. While those hard 49 problems are under discussion, this draft proposes a small set of 50 URI-based mechanisms which are intended to be generically useful for 51 providing pointers to peer-to-peer overlay networks in web pages, 52 email messages, and other textual media. 54 1. Requirements notation 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 58 this document are to be interpreted as described in [RFC 2119]. 60 2. Introduction 62 This document proposes URI-based mechanisms for providing pointers 63 to peer-to-peer overlay networks and resources. These mechanisms are 64 intended to be useful in textual media (web pages, email messages, 65 etc.). While it is commonly true that peer-to-peer networks avoid 66 external dependencies on the DNS or other infrastructure, these 67 mechanisms are intended to be useful in contexts where that 68 infrastructure is present but no connection to a specific overlay 69 has yet been made. These mechanisms are intended to be useable, in 70 other words, as external pointers to specific overlays, their 71 nodes, and their resources. The same mechanisms may be useful 72 once a connection to a specific overlay has been made, as a 73 generic mechanism for referring to overlay nodes, resources, or 74 other characteristics. 76 3. Overlay pointer URI. 78 A URI scheme specifically for overlay pointers is proposed 79 (as a provisional URI registration) to provide for a direct indicator 80 of the existence and certain core characteristics of an overlay. 81 The use of this scheme requires configuration which associates the 82 scheme with a handler that invokes overlay processing. The 83 possession of this URI does not guarantee that the holder of the 84 URI will be able to enroll in a specific overlay. 86 ^L 88 3.1 Registration template for an overlay URI. 90 URI scheme name. 91 "overlay" is requested 92 Status. 93 provisional 94 URI scheme syntax. 96 overlay-URI = overlay-scheme "://" authority 97 "/"";" otype *( ";" service) 98 ; authority as defined in RFC3986 99 overlay-scheme = "overlay" 100 otype = "otype=" token 101 ;valid tokens are in the "Peer to Peer Overlay 102 ;Network types" IANA registry 103 service="service=" *1ALPHANUM 104 ; While this is free text, this document 105 ; describes an IANA registry "Peer to Peer Overlay 106 ; service types" with a set of well-known 107 ; services. 109 URI scheme semantics. 111 The authority section of the URI contains a hostname or IP 112 address associated with an enrollment server or introducer for 113 the overlay. It may also contain a port on which enrollment 114 services are running. The otype, or overlay type, indicates the 115 registered type for the overlay (e.g., Pastry); these are tokens 116 registered by IANA, in the "Peer to Peer Overlay Network types" 117 registry created by this document. The service parameters (if 118 present), indicate the services that an overlay offers. In the 119 following example: 121 overlay://example.org/;otype=Pastry;service=iana.reload-storage 123 the URI provides a pointer to an enrollment server for an 124 overlay running the Pastry DHT and providing a service of 125 "iana.reloadq-storage". The use of the string "iana." indicates 126 that the specification of the service appears in the IANA 127 registry "Peer to Peer Overlay service types" described 128 later in this document; the field is otherwise free text. 130 Encoding considerations. 131 No special considerations 133 Applications/protocols that use this URI scheme name. 135 Applications which need to provide a protocol pointer to an 136 overlay network's enrollment servers or introducers. 138 ^L 140 Interoperability considerations. 141 None known. 143 Security considerations. 144 As currently constructed, this URI scheme's authority section is 145 expected to contain a hostname or IP address . It would be 146 possible to have SRV records or a DDDS application choose entry 147 points based on the authority's DNS name instead. That would 148 provide a better chance that a DoS attack against a specific 149 introducer or enrollment server could not eliminate the ability 150 of new nodes to join an overlay. It does, however, create 151 another layer of indirection and make the use of an IP address 152 in the authority section problematic; in this instance, the 153 ability of someone controlling the zone to add or update the 154 records associated with a server instance was judged a better 155 fit for the problem space. 157 Contact. 158 Ted Hardie 160 Author/Change controller. 161 Ted Hardie 163 References. 164 draft-hardie-p2psip-p2p-pointers-01.txt 165 RFC 3986 167 ^L 169 4. Overlay node pointer URI. 171 Among the bootstrapping problems presented by peer to peer overlays 172 is the lack of a generic way to represent nodes within an overlay, 173 resources stored at that node or resources stored within the 174 overlay. A URI scheme focused on the node and its resources is 175 proposed here, along with context-dependent ways to use it that 176 allow for it to represent resources stored within an overlay. This 177 URI scheme registration is intended to be provisional. It contains 178 a significant limitation that deserves to be highlighted: although 179 the typical "host" portion of an authority section for a URI allows 180 DNS names, IP addresses, or a registered name, this proposal limits 181 the authority section to registered names which are current node 182 identifiers for a specific overlay. This does not limit the use of 183 ports or other aspects of the usual authority section for a URI. 185 A second point to note is that the absence of an authority section 186 indicates that the resource noted in the query section is somewhere 187 within the overlay, but the URI does not establish at which 188 node-id. Where the URI contains a pointer to the overlay context, 189 this provides a mechanism to give an external reference to a 190 resource within a specific overlay without referencing a node-id. 191 Within the context of a specific overlay, this would allow the 192 overlay client to invoke overlay-specific search mechanisms to 193 establish one or more appropriate node-ids offering the service or 194 hosting the resource (and thus to construct "full" pointer URIs). 196 A basic example of the node-id use is: 198 overlay-node://22301203/?resource=example.iso 200 The authority points to a specific node-id; the query section 201 points to a resource stored at that node. It is, however, valid 202 only within a context that already understands what overlay that 203 node occurs in. In order to create a context that establishes 204 that, this registration re-uses the overlay URI discussed above to 205 set the context. 207 ^L 208 The following examples are presented without percent-encoding to 209 highlight the relation to the sections above, but percent-encoding 210 of the context-setting URIs would be required. See Section 4.1 for 211 the actual syntax. 213 Note that the following lines use \ to indicate that the full URI 214 is carried across two lines. 216 In this example, the context is set with a reference to a specific 217 "overlay" URI: 219 overlay-node://22301203/;context="overlay://enrollment.example.org/\ 220 ;otype=pastry"?resource=example.iso 222 In this example, the context is set with reference to a specific 223 "overlay" URI, but no node ID is given. This is how you would 224 construct a URI for "ICE services, offered within a specific 225 overlay": 227 overlay-node:///;context="overlay://introducer.example.org/;otype\ 228 =pastry"?resource=iana.ICE 230 Note that these examples use "resource=" as a common part of the 231 query string, but that this is a narrative convenience rather than 232 a requirement. Query strings may contain any elements permitted 233 by RFC 3986, and they may omit "resource=". "resource=" is simply 234 a documentation convention, and it might or might not be useful 235 for constructing queries within any specific overlay. 237 ^L 239 5.1 Registration template for an overlay node pointer URI. 241 URI scheme name. 242 "overlay-node" is requested 243 Status. 244 provisional 245 URI scheme syntax. 246 overlay-node-URI = overlay-node-scheme "://" [overlay-authority] 247 "/" [";"" context=" overlay-context-uri] ["?" query] 248 ["#"fragment] 249 ; query and fragment are as defined in rfc 3986 250 overlay-scheme = "overlay-node" 251 overlay-authority= [ userinfo "@" ] reg-name [ ":" port ] 252 ;reg-name is defined in RFC 3986- nb limitation from host 253 overlay-context-uri = overlay-URI 254 ;overlay-URI in draft-hardie-p2psip-p2p-pointers-01.txt 256 otype = "otype=" token 257 ;valid tokens are in the "Peer to Peer 258 ;Overlay Network types" IANA registry 259 service="service=" *1ALPHANUM 261 URI scheme semantics. 262 See section 4 of draft-hardie-p2psip-p2p-pointers-01.txt. 264 Encoding considerations. 265 No special considerations 267 Applications/protocols that use this URI scheme name. 269 Applications which need to provide a protocol pointer to an 270 overlay network node, its resources, or resources stored within 271 a specific overlay network. 273 Interoperability considerations. 274 None known. 276 ^L 278 Security considerations. 280 The authority section contains a node-id valid within a specific 281 overlay. Global context is not required; if present, it is 282 given using the "context" parameter. Where it is not present 283 and the context is incorrect, it is possible that the effort to 284 retrieve a resource will fail or will return incorrect results. 285 Careful naming of resources within an overlay may mitigate this 286 problem, but any security system must be aware that overlay-node 287 URIs without a context parameter have different characteristics 288 from URIs that fit in within a known global context like the 289 DNS. 291 Contact. 292 Ted Hardie 294 Author/Change controller. 295 Ted Hardie 297 References. 298 draft-hardie-p2psip-p2p-pointers-01.txt 299 RFC 3986 301 5. IANA Considerations 303 This document registers two provisional URI schemes and creates two 304 registries. The first URI scheme registration is in section 3.1; 305 the second is in section 4.1. The registry for peer-to-peer 306 overlay network types is in section 5.1, below. The registry for 307 Peer to Peer Overlay service types is in section 5.2, below. 309 5.1 Peer-to-peer overlay network type registry. 311 IANA is requested to create a registry titled "Peer-to-Peer Overlay 312 Network Types". The Registry shall have the following fields: Type 313 Name, Algorithm Type, Record Creator, Record Creator contact, 314 Documentation URI. An example is given below: 316 Type Name: Pastry 317 Algorithm Type: Distributed Hash Table 318 Record Creator: IESG 319 Record Creator contact: iesg@ietf.org 320 Docmentation URI: http://freepastry.org/ 322 ^L 324 The registry is to permit new entries using the "Expert Review" 325 guidelines as described in RFC 5226[IANA]. The Expert Reviewer is 326 requested to pay particular attention to the Algorithm Type field 327 and to limit the creation of new values for that field where the 328 algorithms are variants of a fundamental type. Since the main 329 purpose of the registry is to enable clients to determine their 330 interoperability with a specific mechanism, however, the Expert 331 Reviewer should not limit the creation of new Type Names, except 332 where the documentation provided either clearly indicates full 333 interoperability with an existing Type Name of is of insufficient 334 completeness to make any determination on interoperability. The 335 Record Creator contact field SHOULD contain at least an email 336 address and MAY contain any other contact data desired by the 337 Record Creator. 339 5.2 Peer-to-Peer Ovleray Service Types. 341 IANA is requested to create a registry titled "Peer-to-Peer Overlay 342 Service Types". The Registry shall have the following fields: 343 Service Name, Record Creator, Record Creator contact, and 344 Documentation URI. All registered entries should have the initial 345 string "iana.", as this will be used to distinguished registered 346 from unregistered service types. An example is given below: 348 Service Name: iana.reload-storage 349 Record Creator: IESG 350 Record Creator contact: iesg@ietf.org 351 Docmentation URI: 352 http://www.ietf.org/internet-drafts/draft-ietf-p2psip-base-01.txt 354 The registry is to permit new entries using the "Expert Review" 355 guidelines as described in RFC 5226[IANA]. 357 ^L 359 6. Security Considerations 361 The general security issue here is that providing a pointer signals 362 a point at which the overlay may be touched or resource retrieved; 363 disclosure of that indicates either a point of attack, where a 364 specific resource resides, or both. 366 For overlay networks concerned with chosen location attacks, 367 disclosure of a service or resources at a particular node-id may be 368 problematic, as it might assist the attacker in choosing a location 369 to attack. For an attacker with access to multiple clients or the 370 ability to mint new identities, this is not a large advantage, as 371 the attacker could join the overlay, collect the same information, 372 and then re-join. 374 7. Acknowledgments. 376 Lakshminath Dondeti, Spencer Dawkins, Ned Freed, and Andy Newton 377 provided comments on earlier versions of this document. Saumitra 378 Das provided review of this version. 380 8. References 382 8.1 Normative References 384 [KeyWords] Bradner, S., "Key words for use in RFCs to Indicate 385 Requirement Levels", RFC 2119, BCP 14, March 1997. 387 [URI] Berners-Lee T. et al, "URI Generic Syntax", RFC 3986, STD 66, 388 January 2005. 390 [HTTP] Fielding, R. et al, "Hypertext Transfer Protocol -- 391 HTTP/1.1", RFC 2616 June 1999. 393 [URI-REG] Hansen, T. et al. "Guidelines and Registration Procedures 394 for New URI Schemes", RFC 4395, BCP 115, February 2006. 396 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 397 Specifications: ABNF", RFC 5234, January 2008. 399 [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 400 Considerations Section in RFCs", RFC 5226, May 2008. 402 9.2 Informative References 404 ^L 405 Authors' Addresses 407 Ted Hardie 408 Qualcomm, Inc. 409 Email: hardie@qualcomm.com 411 Vidya Narayanan 412 Qualcomm, Inc. 413 Email: vidyan@qualcomm.com