idnits 2.17.1 draft-hardie-p2poverlay-pointers-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 587. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 558. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 565. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 571. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 9) being 84 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** There are 5 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (January 27, 2008) is 5928 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 2119' is mentioned on line 56, but not defined -- Looks like a reference, but probably isn't: '7' on line 116 -- Looks like a reference, but probably isn't: '5' on line 131 == Missing Reference: 'RFC2434' is mentioned on line 486, but not defined ** Obsolete undefined reference: RFC 2434 (Obsoleted by RFC 5226) == Unused Reference: 'KeyWords' is defined on line 526, but no explicit reference was found in the text == Unused Reference: 'URI' is defined on line 529, but no explicit reference was found in the text == Unused Reference: 'HTTP' is defined on line 532, but no explicit reference was found in the text == Unused Reference: 'URI-REG' is defined on line 535, but no explicit reference was found in the text == Unused Reference: 'ABNF' is defined on line 538, 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 4234 (ref. 'ABNF') (Obsoleted by RFC 5234) Summary: 7 errors (**), 0 flaws (~~), 10 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group T. Hardie 2 Internet-Draft Qualcomm, Inc. 3 Expires: July 27, 2008 January 27, 2008 4 Intended Status: Informational 6 Mechanisms for use in pointing to overlay networks, nodes, or resources 7 draft-hardie-p2poverlay-pointers-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of 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 July 27, 2008. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2008). 38 Abstract 40 Discovering overlay networks and the resources found within in them 41 presents a number of bootstrapping problems. While those hard 42 problems are under discussion, this draft proposes a small set of 43 mechanisms which are intended to be generically useful for 44 providing pointers to peer-to-peer overlay networks in web pages, 45 email messages, and other textual media. While the mechanisms 46 described below each meet similar needs, they are not mutually 47 exclusive; it is expected that each will find some useful 48 deployment during the early days of peer-to-peer overlay 49 deployment. 51 1. Requirements notation 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 55 this document are to be interpreted as described in [RFC 2119]. 57 2. Introduction 59 This document proposes mechanisms for providing pointers to 60 peer-to-peer overlay networks and resources. These mechanisms are 61 intended to be useful in textual media (web pages, email messages, 62 etc.). While it is commonly true that peer-to-peer networks avoid 63 external dependencies on the DNS or other infrastructure, these 64 mechanisms are intended to be useful in contexts where that 65 infrastructure is present but no connection to a specific overlay 66 has yet been made. These mechanisms are intended to be useable, in 67 other words, as external pointers to specific overlays, their 68 nodes, and their resources. 70 This is not meant to imply that infrastructure like the global DNS 71 would always be required. IP addresses from a local address realm 72 or resolution services from within another overlay might, for 73 example, be used instead of the global DNS. They may also be used 74 after a connection has been made to a specific overlay to point to 75 particular resources or nodes. 77 3. Overlay description media type. 79 For email, the web, and other textual media which might carry 80 pointers to overlay networks, one basic mechanism for providing 81 pointers is to use existing protocols and URI schemes to 82 dereference a resource which contains sufficient information to 83 contact an overlay. For this to be maximally effective, a media 84 type which has an organized method for presenting this data is 85 needed. With such a media type, the pointer can be provided using 86 existing URI schemes, e.g. http://example.org/overlay-pointer.odd. 87 A client can use that URI to retrieve the resource. Once it has 88 the resource, the client can use the structured information it 89 contains to access the overlay. A multipart MIME type could also 90 contain this MIME type, so that it could be carried by applications 91 for which multipart MIME is common practice. Below is a 92 registration of an xml-based MIME type intended for this, 93 application/overlay-pointer+xml, along with a namespace 94 registration, and a schema registration in RelaxNG. 96 The schema as set forth below contains only a single top-level 97 container, called "availableOverlayDetails", with the following 98 elements: ianaName (which may optionally note an ianaAlgorithm); 99 enrollmentServerContact (which may contain one or more dnsName, 100 ipv6Address, or ipv4Address elements); availableServices (which 101 contains a list of serviceName elements); a joinPolicy (which 102 contains a list of one or more restrictionsImposed); and a 104 pointerCreationDate. The "ianaName" and "ianaAlgorithm" are 105 intended to be tokens from the registry set out in Section 6.1; 106 most of the rest are either the standard data types for XML 107 constructs of their type or simply text. Clearly, many other 108 additions or choices are possible here, and the author expects 109 robust discussion to inform the final schema. 111 3.1 Registration of media type application/overlay-pointer+xml. 113 Content-type registration for 'application/overlay-pointer+xml' 115 This specification requests the registration of a new MIME type 116 according to the procedures of RFC 4288 [7] and guidelines in RFC 117 3023 [5]. 119 MIME media type name: application 121 MIME subtype name: overlay-pointer+xml 123 Mandatory parameters: none 125 Optional parameters: charset 127 Indicates the character encoding of enclosed XML. 129 Encoding considerations: Uses XML, which can employ 8-bit 130 characters, depending on the character encoding used. See RFC 131 3023 [5], Section 3.2. 133 Security considerations: This content type is designed to carry 134 structured information about overlay networks. In cases where 135 that information should be confidential or subject to access 136 control, it should be protected with mechanisms appropriate to 137 the using protocol. Those might include use of a transport 138 which provides confidentiality, object encryption, or some 139 combination. 141 Interoperability considerations: None 143 Published specification: RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please 144 replace XXXX with the RFC number of this specification.] 146 Applications which use this media type: Applications providing 147 pointers to overlay networks. 149 Additional information: 151 Magic Number: None 153 File Extension: .odd 155 Macintosh file type code: 'TEXT' 157 Personal and email address for further information: Ted Hardie 158 hardie@qualcomm.com 160 Intended usage: LIMITED USE 162 Author: 164 This specification is related to the work of the P2PSIP working 165 group, but is an individual submission. 167 Change controller: 169 The IESG 171 3.2 Schema namespace registration. 173 Overlay Pointer Registration 175 URI: urn:ietf:params:xml:ns:overlaypointer1 177 Registrant Contact: Ted Hardie. 179 XML: 181 BEGIN 182 183 185 186 187 189 Overlay Pointer Namespace 190 191 192

Namespace for OverlayPointer

193

urn:ietf:params:xml:ns:overlaypointer1

194

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

198 199 201 3.3. Schema Registration 203 URI: urn:ietf:params:xml:ns:overlaypointer1 205 Registrant Contact: Ted Hardie 206 (hardie@qualcomm.com). 208 Relax NG Schema: 210 215
216 Overlay Pointer Description 218 219 221 element name="availableOverlayDetails"{ 222 element typeName { 223 attribute ianaName {text}, 224 attribute ianaAlgorithm {text}? 225 } 226 element enrollmentServerContact { 227 attribute dnsName {hostname} | 228 attribute ipv6Address {text} | 229 attribute ipv4Address {IP} 230 }* 231 element availableServices { 232 attribute serviceName {text}* 233 } 234 element joinPolicy { 235 attribute restrictionsImposed {text}* 236 } 237 element pointerCreationDate {date} 239 } 240
241 243 [EDITOR's Note: the "text" type of ipv6Address is a hack, because 244 IP seemed to be limited to IPv4. A better data type should 245 clearly be used here. There are also two different forms for 246 RelaxNG schemas, and input on which one to use as the normative 247 version is requested.] 249 4. Overlay pointer URI. 251 The use of an existing protocol to dereference a descriptive 252 document has the advantage that it may use deployed protocols and 253 URI schemes. The obvious disadvantage is that it introduces a 254 layer of indirection and may introduce delay in the beginning of 255 overlay-specific protocol processing or may frustrate the protocol 256 processing where the dereferencing fails. A URI scheme 257 specifically for overlay pointers is proposed (as a provisional URI 258 registration) to provide for a direct indicator. While this may 259 require configuration (associating the URI scheme with a handler 260 that invokes the overlay processing), that configuration avoids the 261 layer of indirection mentioned above. 263 4.1 Registration template for an overlay URI. 265 URI scheme name. 266 "overlay" is requested 267 Status. 268 provisional 269 URI scheme syntax. 271 overlay-URI = overlay-scheme "://" authority 272 "/"";" otype *( ";" service) 273 ; authority as defined in RFC3986 274 overlay-scheme = "overlay" 275 otype = "otype=" token 276 ;valid tokens are in the "Peer to Peer Overlay 277 ;Network types" IANA registry 278 service="service=" *1ALPHANUM 280 URI scheme semantics. 282 The authority section of the URI contains a hostname or IP 283 address associated with an enrollment server or introducer for 284 the overlay. It may also contain a port on which enrollment 285 services are running. The otype, or overlay type, indicates the 286 registered type for the overlay (e.g., Pastry); these are tokens 287 registered by IANA, in the "Peer to Peer Overlay Network types" 288 registry. The service parameters (if present), indicate the 289 services that an overlay offers. In the following example: 291 overlay://enrollment.example.org/;otype=Pastry;service=mass-storage 293 the URI provides a pointer to an enrollment server for an 294 overlay running the Pastry DHT and providing a service of 295 "mass-storage". While it is assumed that some uses of this URI 296 might create agreements for the meaning of specific services 297 (e.g. p2psip might create an "ICE" service), the current 298 registration treats these as free text so that other users can 299 mint new ones as needed. If discussion during the provisional 300 phase indicates the chance of confusion among these, a 301 parameter registry would be created as part of the transition 302 from provisional to permanent registration. 304 Encoding considerations. 305 No special considerations 307 Applications/protocols that use this URI scheme name. 309 Applications which need to provide a protocol pointer to an 310 overlay network's enrollment servers or introducers. 312 Interoperability considerations. 313 None known. 315 Security considerations. 316 As currently constructed, this URI scheme's authority section is 317 expected to contain a hostname or IPv6 address . It would be 318 possible to have SRV records or a DDDS application choose entry 319 points based on the authority's DNS name instead. That would 320 provide a better chance that a DoS attack against a specific 321 introducer or enrollment server could not eliminate the ability 322 of new nodes to join an overlay. It does, however, create 323 another layer of indirection and make the use of an IP address 324 in the authority section problematic; in this instance, the 325 ability of someone controlling the zone to add or update the 326 records associated with a server instance was judged a better 327 fit for the problem space. 329 Contact. 330 Ted Hardie 332 Author/Change controller. 333 Ted Hardie 335 References. 336 draft-hardie-p2poverlay-pointers-00.txt 337 RFC 3986 339 5. Overlay node pointer URI. 341 Among the bootstrapping problems presented by peer to peer overlays 342 is the lack of a generic way to represent nodes within an overlay, 343 resources stored at that node or resources stored within the 344 overlay. A URI scheme focused on the node and its resources is 345 proposed here, along with context-dependent ways to use it that 346 allow for it to represent resources stored within an overlay. This 347 URI scheme registration is intended to be provisional. It contains 348 a significant limitation that deserves to be highlighted: although 349 the typical "host" portion of an authority section for a URI allows 350 DNS names, IP addresses, or a registered name, this proposal limits 351 the authority section to registered names which are current node 352 identifiers for a specific overlay. 354 A second point to note is that the absence of an authority section 355 indicates that the resource noted in the query section is somewhere 356 within the overlay, but the URI does not establish at which 357 node-id. Where the URI contains a pointer to the overlay context, 358 this provides a mechanism to give an external reference to a 359 resource within a specific overlay without referencing a node-id. 360 Within the context of a specific overlay, this would allow the 361 overlay client to invoke overlay-specific search mechanisms to 362 establish one or more appropriate node-ids offering the service or 363 hosting the resource (and thus to construct "full" pointer URIs). 365 A basic example of the node-id use is: 367 overlay-node://22301203/?resource=example.iso 369 The authority points to a specific node-id; the query section 370 points to a resource stored at that node. It is, however, valid 371 only within a context that already understands what overlay that 372 node occurs in. In order to create a context that establishes 373 that, this registration re-uses the methods discussed above to set 374 the context. 376 The following two examples are presented without percent-encoding 377 to highlight the relation to the sections above, but 378 percent-encoding of the context-setting URIs would be required. See 379 Section 5.1 for the actual syntax. 381 Note that the following lines use \ to indicate that the full URI 382 is carried across two lines. In this example, the context is set 383 with reference to a specific overlay-pointer+xml resource: 385 overlay-node://22301203/;context="http://introducer.example.net/example.odd"\ 386 ?resource=service-instance 388 In this example, the context is set with a reference to a specific 389 "overlay" URI: 391 overlay-node://22301203/;context="overlay://enrollment.example.org/\ 392 ;otype=pastry"\ 393 ?resource=example.iso 395 In this example, the context is set with reference to a specific 396 "overlay" URI, but no node ID is given. This is how you would 397 construct a URI for "ICE services, offered within a specific 398 overlay": 400 overlay-node:///;context="overlay://introducer.example.org/;otype=pastry"\ 401 ?resource=ICE-services 403 5.1 Registration template for an overlay node pointer URI. 405 URI scheme name. 406 "overlay-node" is requested 407 Status. 408 provisional 409 URI scheme syntax. 410 overlay-node-URI = overlay-node-scheme "://" [overlay-authority] 411 "/" [";"" context=" overlay-context-uri] ["?" query] ["#"fragment] 412 ; query and fragment are as defined in rfc 3986 413 overlay-scheme = "overlay-node" 414 overlay-authority= [ userinfo "@" ] reg-name [ ":" port ] 415 ;reg-name is defined in RFC 3986 *note limitation from host* 416 overlay-context-uri = HTTP-URI | overlay-URI 417 ;HTTP-URI is defined in RFC 2616 418 ;overlay-URI in draft-hardie-p2poverlay-pointers-00.txt 420 otype = "otype=" token 421 ;valid tokens are in the "Peer to Peer 422 ;Overlay Network types" IANA registry 423 service="service=" *1ALPHANUM 425 URI scheme semantics. 426 See section 5 of draft-hardie-p2poverlay-pointers-00.txt. 428 Encoding considerations. 429 No special considerations 431 Applications/protocols that use this URI scheme name. 433 Applications which need to provide a protocol pointer to an 434 overlay network node, its resources, or resources stored within 435 a specific overlay network. 437 Interoperability considerations. 438 None known. 440 Security considerations. 442 The authority section contains a node-id valid within a specific 443 overlay. Global context is not required; if present, it is 444 given using the "context" parameter. Where it is not present 445 and the context is incorrect, it is possible that the effort to 446 retrieve a resource will fail or will return incorrect results. 447 Careful naming of resources within an overlay may mitigate this 448 problem, but any security system must be aware that overlay-node 449 URIs without a context parameter have different characteristics 450 from URIs that fit in within a known global context like the 451 DNS. 453 Contact. 454 Ted Hardie 456 Author/Change controller. 457 Ted Hardie 459 References. 460 draft-hardie-p2poverlay-pointers-00.txt 461 RFC 3986 463 6. IANA Considerations 465 This document registers a new media type, an XML schema, two 466 provisional URI schemes, and creates a registry for peer to peer 467 overlay types. The media type registration is in section 3.1. The 468 XML schema is in section 3.2. The first URI scheme registration is 469 in section 4.1; the second is in section 5.1. The registry for 470 peer-to-peer overlay network types is in section 6.1, below. 472 6.1 Peer-to-peer overlay network type registry. 474 IANA is requested to create a registry titled "Peer-to-Peer Overlay 475 Network Types". The Registry shall have the following fields: Type 476 Name, Algorithm Type, Record Creator, Record Creator contact, 477 Documentation URI. An example is given below: 479 Type Name: Pastry 480 Algorithm Type: Distributed Hash Table 481 Record Creator: IESG 482 Record Creator contact: iesg@ietf.org 483 Docmentation URI: http://freepastry.org/ 485 The registry is to permit new entries using the "Expert Review" 486 guidelines as described in RFC 2434[RFC2434]. The Expert Reviewer 487 is requested to pay particular attention to the Algorithm Type 488 field and to limit the creation of new values for that field where 489 the algorithms are variants of a fundamental type. Since the main 490 purpose of the registry is to enable clients to determine their 491 interoperability with a specific mechanism, however, the Expert 492 Reviewer should not limit the creation of new Type Names, except 493 where the documentation provided either clearly indicates full 494 interoperability with an existing Type Name of is of insufficient 495 completeness to make any determination on interoperability. The 496 Record Creator contact field SHOULD contain at least an email 497 address and MAY contain any other contact data desired by the 498 Record Creator. 500 7. Security Considerations 502 Security considerations for each of the three methods given above 503 is documented within each method. The general security issue here 504 is that providing a pointer signals a point at which the overlay 505 may be touched or resource retrieved; disclosure of that indicates 506 either a point of attack, where a specific resource resides, or 507 both. 509 For overlay networks concerned with chosen location attacks, 510 disclosure of a service or resources at a particular node-id may be 511 problematic, as it might assist the attacker in choosing a location 512 to attack. For an attacker with access to multiple clients or the 513 ability to mint new identities, this is not a large advantage, as 514 the attacker could join the overlay, collect the same information, 515 and then re-join. 517 8. Acknowledgments. 519 Vidya Narayanan, Lakshminath Dondeti, and Spencer Dawkins 520 commented on early versions of this document. 522 9. References 524 9.1 Normative References 526 [KeyWords] Bradner, S., "Key words for use in RFCs to Indicate 527 Requirement Levels", RFC 2119, BCP 14, March 1997. 529 [URI] Berners-Lee T. et al, "URI Generic Syntax", RFC 3986, STD 66, 530 January 2005. 532 [HTTP] Fielding, R. et al, "Hypertext Transfer Protocol -- 533 HTTP/1.1", RFC 2616 June 1999. 535 [URI-REG] Hansen, T. et al. "Guidelines and Registration Procedures 536 for New URI Schemes", RFC 4395, BCP 115, February 2006. 538 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 539 Specifications: ABNF", RFC 4234, October 2005. 541 9.2 Informative References 543 Author's Addresses 545 Ted Hardie 546 Qualcomm, Inc. 547 Email: hardie@qualcomm.com 549 Intellectual Property Statement 551 The IETF takes no position regarding the validity or scope of any 552 Intellectual Property Rights or other rights that might be claimed to 553 pertain to the implementation or use of the technology described in 554 this document or the extent to which any license under such rights 555 might or might not be available; nor does it represent that it has 556 made any independent effort to identify any such rights. Information 557 on the procedures with respect to rights in RFC documents can be 558 found in BCP 78 and BCP 79. 560 Copies of IPR disclosures made to the IETF Secretariat and any 561 assurances of licenses to be made available, or the result of an 562 attempt made to obtain a general license or permission for the use of 563 such proprietary rights by implementers or users of this 564 specification can be obtained from the IETF on-line IPR repository at 565 http://www.ietf.org/ipr. 567 The IETF invites any interested party to bring to its attention any 568 copyrights, patents or patent applications, or other proprietary 569 rights that may cover technology that may be required to implement 570 this standard. Please address the information to the IETF at 571 ietf-ipr@ietf.org. 573 Full Copyright Statement 575 Copyright (C) The IETF Trust (2008). 577 This document is subject to the rights, licenses and restrictions 578 contained in BCP 78, and except as set forth therein, the authors 579 retain all their rights. 581 This document and the information contained herein are provided on an 582 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 583 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 584 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 585 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 586 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 587 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 589 Acknowledgment 591 Funding for the RFC Editor function is currently provided by the 592 Internet Society.