--- 1/draft-ietf-p2psip-base-17.txt 2011-08-04 20:16:12.000000000 +0200 +++ 2/draft-ietf-p2psip-base-18.txt 2011-08-04 20:16:12.000000000 +0200 @@ -1,24 +1,24 @@ P2PSIP C. Jennings Internet-Draft Cisco Intended status: Standards Track B. Lowekamp, Ed. -Expires: January 12, 2012 Skype +Expires: February 4, 2012 Skype E. Rescorla RTFM, Inc. S. Baset H. Schulzrinne Columbia University - July 11, 2011 + August 3, 2011 REsource LOcation And Discovery (RELOAD) Base Protocol - draft-ietf-p2psip-base-17 + draft-ietf-p2psip-base-18 Abstract This specification defines REsource LOcation And Discovery (RELOAD), a peer-to-peer (P2P) signaling protocol for use on the Internet. A P2P signaling protocol provides its clients with an abstract storage and messaging service between a set of cooperating peers that form the overlay network. RELOAD is designed to support a P2P Session Initiation Protocol (P2PSIP) network, but can be utilized by other applications with similar requirements by defining new usages that @@ -37,21 +37,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on January 12, 2012. + This Internet-Draft will expire on February 4, 2012. Copyright Notice Copyright (c) 2011 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -244,46 +244,46 @@ 12.6.4. Protecting the Signaling . . . . . . . . . . . . . . 140 12.6.5. Residual Attacks . . . . . . . . . . . . . . . . . . 140 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 141 13.1. Well-Known URI Registration . . . . . . . . . . . . . . 141 13.2. Port Registrations . . . . . . . . . . . . . . . . . . . 141 13.3. Overlay Algorithm Types . . . . . . . . . . . . . . . . 142 13.4. Access Control Policies . . . . . . . . . . . . . . . . 142 13.5. Application-ID . . . . . . . . . . . . . . . . . . . . . 142 13.6. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . 143 13.7. Data Model . . . . . . . . . . . . . . . . . . . . . . . 143 - 13.8. Message Codes . . . . . . . . . . . . . . . . . . . . . 143 - 13.9. Error Codes . . . . . . . . . . . . . . . . . . . . . . 144 - 13.10. Overlay Link Types . . . . . . . . . . . . . . . . . . . 145 - 13.11. Overlay Link Protocols . . . . . . . . . . . . . . . . . 145 - 13.12. Forwarding Options . . . . . . . . . . . . . . . . . . . 146 - 13.13. Probe Information Types . . . . . . . . . . . . . . . . 146 - 13.14. Message Extensions . . . . . . . . . . . . . . . . . . . 146 - 13.15. reload URI Scheme . . . . . . . . . . . . . . . . . . . 147 - 13.15.1. URI Registration . . . . . . . . . . . . . . . . . . 147 - 13.16. Media Type Registration . . . . . . . . . . . . . . . . 148 - 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 149 - 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 150 - 15.1. Normative References . . . . . . . . . . . . . . . . . . 150 - 15.2. Informative References . . . . . . . . . . . . . . . . . 151 - Appendix A. Routing Alternatives . . . . . . . . . . . . . . . . 154 - A.1. Iterative vs Recursive . . . . . . . . . . . . . . . . . 155 - A.2. Symmetric vs Forward response . . . . . . . . . . . . . 155 - A.3. Direct Response . . . . . . . . . . . . . . . . . . . . 155 - A.4. Relay Peers . . . . . . . . . . . . . . . . . . . . . . 157 - A.5. Symmetric Route Stability . . . . . . . . . . . . . . . 157 - Appendix B. Why Clients? . . . . . . . . . . . . . . . . . . . . 158 - B.1. Why Not Only Peers? . . . . . . . . . . . . . . . . . . 158 - B.2. Clients as Application-Level Agents . . . . . . . . . . 158 - Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 159 - C.1. Changes since draft-ietf-p2psip-reload-13 . . . . . . . 159 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 159 + 13.8. Message Codes . . . . . . . . . . . . . . . . . . . . . 144 + 13.9. Error Codes . . . . . . . . . . . . . . . . . . . . . . 146 + 13.10. Overlay Link Types . . . . . . . . . . . . . . . . . . . 146 + 13.11. Overlay Link Protocols . . . . . . . . . . . . . . . . . 147 + 13.12. Forwarding Options . . . . . . . . . . . . . . . . . . . 147 + 13.13. Probe Information Types . . . . . . . . . . . . . . . . 148 + 13.14. Message Extensions . . . . . . . . . . . . . . . . . . . 148 + 13.15. reload URI Scheme . . . . . . . . . . . . . . . . . . . 148 + 13.15.1. URI Registration . . . . . . . . . . . . . . . . . . 149 + 13.16. Media Type Registration . . . . . . . . . . . . . . . . 150 + 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 151 + 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 152 + 15.1. Normative References . . . . . . . . . . . . . . . . . . 152 + 15.2. Informative References . . . . . . . . . . . . . . . . . 153 + Appendix A. Routing Alternatives . . . . . . . . . . . . . . . . 156 + A.1. Iterative vs Recursive . . . . . . . . . . . . . . . . . 156 + A.2. Symmetric vs Forward response . . . . . . . . . . . . . 157 + A.3. Direct Response . . . . . . . . . . . . . . . . . . . . 157 + A.4. Relay Peers . . . . . . . . . . . . . . . . . . . . . . 158 + A.5. Symmetric Route Stability . . . . . . . . . . . . . . . 159 + Appendix B. Why Clients? . . . . . . . . . . . . . . . . . . . . 160 + B.1. Why Not Only Peers? . . . . . . . . . . . . . . . . . . 160 + B.2. Clients as Application-Level Agents . . . . . . . . . . 160 + Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 161 + C.1. Changes since draft-ietf-p2psip-reload-13 . . . . . . . 161 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 161 1. Introduction This document defines REsource LOcation And Discovery (RELOAD), a peer-to-peer (P2P) signaling protocol for use on the Internet. It provides a generic, self-organizing overlay network service, allowing nodes to efficiently route messages to other nodes and to efficiently store and retrieve data in the overlay. RELOAD provides several features that are critical for a successful P2P protocol for the Internet: @@ -2272,27 +2272,36 @@ The contents of this structure are: certificates A bucket of certificates. signature A signature over the message contents. The certificates bucket SHOULD contain all the certificates necessary to verify every signature in both the message and the internal - message objects. This is the only location in the message which - contains certificates, thus allowing for only a single copy of each - certificate to be sent. In systems which have some alternate - certificate distribution mechanism, some certificates MAY be omitted. - However, implementors should note that this creates the possibility - that messages may not be immediately verifiable because certificates - must first be retrieved. + message objects, except for those certificates in a root-cert element + of the current configuration file. This is the only location in the + message which contains certificates, thus allowing for only a single + copy of each certificate to be sent. In systems that have an + alternative certificate distribution mechanism, some certificates MAY + be omitted. However, unless an alternative mechanism for immediately + generating certifcates, such as shared secret security (Section 12.4) + is used, it is strongly RECOMMENDED that implementors include all + referenced certificates, otherwise there is the possibility that + messages may not be immediately verifiable because certificates must + first be retrieved. + + NOTE TO IMPLEMENTERS: This requirement implies that a peer storing + data is obligated to retain certificates for the data it holds + regardless of whether it is responsible for or actually holding the + certificates for the Certificate Store usage. Each certificate is represented by a GenericCertificate structure, which has the following contents: type The type of the certificate, as defined in [RFC6091]. Only the use of X.509 certificates is defined in this draft. certificate The encoded version of the certificate. For X.509 certificates, @@ -4615,20 +4624,24 @@ Peers can find other servers by selecting a random Resource-ID and then doing a Find request for the appropriate Kind-ID with that Resource-ID. The Find request gets routed to a random peer based on the Resource-ID. If that peer knows of any servers, they will be returned. The returned response may be empty if the peer does not know of any servers, in which case the process gets repeated with some other random Resource-ID. As long as the ratio of servers relative to peers is not too low, this approach will result in finding a server relatively quickly. + NOTE TO IMPLEMENTERS: As the access control for this usage is not + CERTIFICATE_BY_NODE or CERTIFICATE_BY_USER, the certificates used by + TurnServer entries need to be retained as described in Section 5.3.4. + 9. Chord Algorithm This algorithm is assigned the name chord-reload to indicate it is an adaptation of the basic Chord based DHT algorithm. This algorithm differs from the originally presented Chord algorithm [Chord]. It has been updated based on more recent research results and implementation experiences, and to adapt it to the RELOAD protocol. A short list of differences: @@ -5247,21 +5260,21 @@ provides a signature over the preceding configuration element. Each configuration element has the following attributes: instance-name: name of the overlay expiration: time in the future at which this overlay configuration is no longer valid. The node SHOULD retrieve a new copy of the configuration at a randomly selected time that is before the expiration time. Note that if the certificates expire before a new configuration is retried, the node will not be able to validate the configuration file. - sequence: a monotonically increasing sequence number between 1 and + sequence: a monotonically increasing sequence number between 0 and 2^16-2 Inside each overlay element, the following elements can occur: topology-plugin This element defines the overlay algorithm being used. If missing the default is "CHORD-RELOAD". node-id-length This element contains the length of a NodeId (NodeIdLength) in bytes. This value MUST be between 16 (128 bits) and 20 (160 bits). If this element is not present, the default of 16 is used. @@ -6361,39 +6374,49 @@ IANA SHALL create a "RELOAD Overlay Algorithm Type" Registry. Entries in this registry are strings denoting the names of overlay algorithms. The registration policy for this registry is RFC 5226 IETF Review. The initial contents of this registry are: +----------------+----------+ | Algorithm Name | RFC | +----------------+----------+ | CHORD-RELOAD | RFC-AAAA | + | EXP-OVERLAY | RFC-AAAA | +----------------+----------+ + The value EXP-OVERLAY has been made available for the purposes of + experimentation. This values is not meant for vendor specific use of + any sort and it MUST NOT be used for operational deployments. + 13.4. Access Control Policies IANA SHALL create a "RELOAD Access Control Policy" Registry. Entries in this registry are strings denoting access control policies, as described in Section 6.3. New entries in this registry SHALL be registered via RFC 5226 Standards Action. The initial contents of this registry are: +-----------------+----------+ | Access Policy | RFC | +-----------------+----------+ | USER-MATCH | RFC-AAAA | | NODE-MATCH | RFC-AAAA | | USER-NODE-MATCH | RFC-AAAA | | NODE-MULTIPLE | RFC-AAAA | + | EXP-MATCH | RFC-AAAA | +-----------------+----------+ + The value EXP-MATCH has been made available for the purposes of + experimentation. This values is not meant for vendor specific use of + any sort and it MUST NOT be used for operational deployments. + 13.5. Application-ID IANA SHALL create a "RELOAD Application-ID" Registry. Entries in this registry are 16-bit integers denoting application kinds. Code points in the range 0x0001 to 0x7fff SHALL be registered via RFC 5226 Standards Action. Code points in the range 0x8000 to 0xf000 SHALL be registered via RFC 5226 Expert Review. Code points in the range 0xf001 to 0xfffe are reserved for private use. The initial contents of this registry are: @@ -6435,23 +6458,28 @@ points in this registry SHALL be registered via RFC 5226 Standards Action. The initial contents of this registry are: +------------+----------+ | Data Model | RFC | +------------+----------+ | INVALID | RFC-AAAA | | SINGLE | RFC-AAAA | | ARRAY | RFC-AAAA | | DICTIONARY | RFC-AAAA | + | EXP-DATA | RFC-AAAA | | RESERVED | RFC-AAAA | +------------+----------+ + The value EXP-DATA has been made available for the purposes of + experimentation. This values is not meant for vendor specific use of + any sort and it MUST NOT be used for operational deployments. + 13.8. Message Codes IANA SHALL create a "RELOAD Message Code" Registry. Entries in this registry are 16-bit integers denoting method codes as described in Section 5.3.3. These codes SHALL be registered via RFC 5226 Standards Action. The initial contents of this registry are: +---------------------------------+----------------+----------+ | Message Code Name | Code Value | RFC | +---------------------------------+----------------+----------+ @@ -6483,24 +6511,33 @@ | stat_req | 25 | RFC-AAAA | | stat_ans | 26 | RFC-AAAA | | unused (was attachlite_req) | 27 | RFC-AAAA | | unused (was attachlite_ans) | 28 | RFC-AAAA | | app_attach_req | 29 | RFC-AAAA | | app_attach_ans | 30 | RFC-AAAA | | unused (was app_attachlite_req) | 31 | RFC-AAAA | | unused (was app_attachlite_ans) | 32 | RFC-AAAA | | config_update_req | 33 | RFC-AAAA | | config_update_ans | 34 | RFC-AAAA | + | exp_a_req | 35 | RFC-AAAA | + | exp_a_ans | 36 | RFC-AAAA | + | exp_b_req | 37 | RFC-AAAA | + | exp_b_ans | 38 | RFC-AAAA | | reserved | 0x8000..0xfffe | RFC-AAAA | | error | 0xffff | RFC-AAAA | +---------------------------------+----------------+----------+ + The values exp_a_req, exp_a_ans, exp_b_req, and exp_b_ans have been + made available for the purposes of experimentation. These values are + not meant for vendor specific use of any sort and MUST NOT be used + for operational deployments. + 13.9. Error Codes IANA SHALL create a "RELOAD Error Code" Registry. Entries in this registry are 16-bit integers denoting error codes. New entries SHALL be defined via RFC 5226 Standards Action. The initial contents of this registry are: +-------------------------------------+----------------+----------+ | Error Code Name | Code Value | RFC | +-------------------------------------+----------------+----------+ @@ -6515,91 +6552,128 @@ | Error_Data_Too_Large | 8 | RFC-AAAA | | Error_Data_Too_Old | 9 | RFC-AAAA | | Error_TTL_Exceeded | 10 | RFC-AAAA | | Error_Message_Too_Large | 11 | RFC-AAAA | | Error_Unknown_Kind | 12 | RFC-AAAA | | Error_Unknown_Extension | 13 | RFC-AAAA | | Error_Response_Too_Large | 14 | RFC-AAAA | | Error_Config_Too_Old | 15 | RFC-AAAA | | Error_Config_Too_New | 16 | RFC-AAAA | | Error_In_Progress | 17 | RFC-AAAA | + | Error_Exp_A | 18 | RFC-AAAA | + | Error_Exp_B | 19 | RFC-AAAA | | reserved | 0x8000..0xfffe | RFC-AAAA | +-------------------------------------+----------------+----------+ + The values Error_Exp_A and Error_Exp_B have been made available for + the purposes of experimentation. These values are not meant for + vendor specific use of any sort and MUST NOT be used for operational + deployments. + 13.10. Overlay Link Types IANA shall create a "RELOAD Overlay Link." New entries SHALL be defined via RFC 5226 Standards Action. This registry SHALL be initially populated with the following values: +--------------------+------+---------------+ | Protocol | Code | Specification | +--------------------+------+---------------+ | reserved | 0 | RFC-AAAA | | DTLS-UDP-SR | 1 | RFC-AAAA | | DTLS-UDP-SR-NO-ICE | 3 | RFC-AAAA | | TLS-TCP-FH-NO-ICE | 4 | RFC-AAAA | + | EXP-LINK | 5 | RFC-AAAA | | reserved | 255 | RFC-AAAA | +--------------------+------+---------------+ + The value EXP-LINK has been made available for the purposes of + experimentation. This values is not meant for vendor specific use of + any sort and it MUST NOT be used for operational deployments. + 13.11. Overlay Link Protocols IANA shall create an "Overlay Link Protocol Registry". Entries in this registry SHALL be defined via RFC 5226 Standards Action. This - registry SHALL be initially populated with the following value: - "TLS". + registry SHALL be initially populated with the following valuse: + + +---------------+---------------+ + | Link Protocol | Specification | + +---------------+---------------+ + | TLS | RFC-AAAA | + | EXP-PROTOCOL | RFC-AAAA | + +---------------+---------------+ + + The value EXP-PROTOCOL has been made available for the purposes of + experimentation. This values is not meant for vendor specific use of + any sort and it MUST NOT be used for operational deployments. 13.12. Forwarding Options IANA shall create a "Forwarding Option Registry". Entries in this registry between 1 and 127 SHALL be defined via RFC 5226 Standards Action. Entries in this registry between 128 and 254 SHALL be defined via RFC 5226 Specification Required. This registry SHALL be initially populated with the following values: +-------------------+------+---------------+ | Forwarding Option | Code | Specification | +-------------------+------+---------------+ | invalid | 0 | RFC-AAAA | + | exp-forward | 1 | RFC-AAAA | | reserved | 255 | RFC-AAAA | +-------------------+------+---------------+ + The value exp-forward has been made available for the purposes of + experimentation. This values is not meant for vendor specific use of + any sort and it MUST NOT be used for operational deployments. + 13.13. Probe Information Types IANA shall create a "RELOAD Probe Information Type Registry". Entries in this registry SHALL be defined via RFC 5226 Standards Action. This registry SHALL be initially populated with the following values: +-----------------+------+---------------+ | Probe Option | Code | Specification | +-----------------+------+---------------+ | invalid | 0 | RFC-AAAA | | responsible_set | 1 | RFC-AAAA | | num_resources | 2 | RFC-AAAA | | uptime | 3 | RFC-AAAA | + | exp-probe | 4 | RFC-AAAA | | reserved | 255 | RFC-AAAA | +-----------------+------+---------------+ + The value exp-probe has been made available for the purposes of + experimentation. This values is not meant for vendor specific use of + any sort and it MUST NOT be used for operational deployments. + 13.14. Message Extensions IANA shall create a "RELOAD Extensions Registry". Entries in this registry SHALL be defined via RFC 5226 Specification Required. This registry SHALL be initially populated with the following values: +-----------------+--------+---------------+ | Extensions Name | Code | Specification | +-----------------+--------+---------------+ | invalid | 0 | RFC-AAAA | + | exp-ext | 1 | RFC-AAAA | | reserved | 0xFFFF | RFC-AAAA | +-----------------+--------+---------------+ + The value exp-ext has been made available for the purposes of + experimentation. This values is not meant for vendor specific use of + any sort and it MUST NOT be used for operational deployments. + 13.15. reload URI Scheme This section describes the scheme for a reload URI, which can be used to refer to either: o A peer. o A resource inside a peer. The reload URI is defined using a subset of the URI schema specified in Appendix A of RFC 3986 [RFC3986] and the associated URI Guidelines @@ -6862,26 +6936,20 @@ Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, "A SIP Usage for RELOAD", draft-ietf-p2psip-sip-06 (work in progress), July 2011. [I-D.jiang-p2psip-relay] Jiang, X., Zong, N., Even, R., and Y. Zhang, "An extension to RELOAD to support Direct Response and Relay Peer routing", draft-jiang-p2psip-relay-05 (work in progress), March 2011. - [I-D.pascual-p2psip-clients] - Pascual, V., Matuszewski, M., Shim, E., Zhang, H., and S. - Yongchao, "P2PSIP Clients", - draft-pascual-p2psip-clients-01 (work in progress), - February 2008. - [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [RFC2311] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and L. Repka, "S/MIME Version 2 Message Specification", RFC 2311, March 1998. [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. @@ -7118,23 +7186,22 @@ stability of the return path, studies show that in the event of high churn, iterative routing is a better solution to ensure request completion [lookups-churn-p2p06] [non-transitive-dhts-worlds05] Finally, because RELOAD retries the end-to-end request, that retry will address the issues of churn that remain. Appendix B. Why Clients? There are a wide variety of reasons a node may act as a client rather - than as a peer [I-D.pascual-p2psip-clients]. This section outlines - some of those scenarios and how the client's behavior changes based - on its capabilities. + than as a peer. This section outlines some of those scenarios and + how the client's behavior changes based on its capabilities. B.1. Why Not Only Peers? For a number of reasons, a particular node may be forced to act as a client even though it is willing to act as a peer. These include: o The node does not have appropriate network connectivity, typically because it has a low-bandwidth network connection. o The node may not have sufficient resources, such as computing power, storage space, or battery power.