RFC 6940
REsource LOcation And Discovery (RELOAD) Base Protocol
14. IANA Considerations
This section contains the new code points registered by this document.14.1. Well-Known URI Registration
IANA has registered a "well-known URI" as described in [RFC5785]: +----------------------------+----------------------+ | URI suffix: | reload-config | | Change controller: | IETF <iesg@ietf.org> | | Specification document(s): | RFC 6940 | | Related information: | None | +----------------------------+----------------------+14.2. Port Registrations
IANA has already allocated a TCP port for the main peer-to-peer protocol. This port had the name p2psip-enroll and the port number of 6084. Per this document, IANA has updated this registration to change the service name to reload-config. IANA has made the following port registration: +-----------------------------+-------------------------------------+ | Registration Technical | IETF Chair <chair@ietf.org> | | Contact | | | Registration Owner | IETF <iesg@ietf.org> | | Transport Protocol | TCP | | Port Number | 6084 | | Service Name | reload-config | | Description | Peer-to-Peer Infrastructure | | | Configuration | +-----------------------------+-------------------------------------+
14.3. Overlay Algorithm Types
IANA has created a "RELOAD Overlay Algorithm Types" Registry. Entries in this registry are strings denoting the names of overlay algorithms, as described in Section 11.1 of [RFC6940]. The registration policy for this registry is "IETF Review" [RFC522]. The initial contents of this registry are: +----------------+-----------+ | Algorithm Name | Reference | +----------------+-----------+ | CHORD-RELOAD | RFC 6940 | | EXP-OVERLAY | RFC 6940 | +----------------+-----------+ The value EXP-OVERLAY has been made available for the purposes of experimentation. This value is not meant for vendor-specific use of any sort, and it MUST NOT be used for operational deployments.14.4. Access Control Policies
IANA has created a "RELOAD Access Control Policies" Registry. Entries in this registry are strings denoting access control policies, as described in Section 7.3 of [RFC6940]. New entries in this registry SHALL be registered via Standards Action [RFC5226]. The initial contents of this registry are: +-----------------+-----------+ | Access Policy | Reference | +-----------------+-----------+ | USER-MATCH | RFC 6940 | | NODE-MATCH | RFC 6940 | | USER-NODE-MATCH | RFC 6940 | | NODE-MULTIPLE | RFC 6940 | | EXP-MATCH | RFC 6940 | +-----------------+-----------+ The value EXP-MATCH has been made available for the purposes of experimentation. This value is not meant for vendor-specific use of any sort, and it MUST NOT be used for operational deployments.
14.5. Application-ID
IANA has created a "RELOAD Application-ID" Registry. Entries in this registry are 16-bit integers denoting Application-IDs, as described in Section 6.5.2 of [RFC6940]. Code points in the range 1 to 32767 SHALL be registered via Standards Action [RFC5226]. Code points in the range 32768 to 61440 SHALL be registered via Expert Review [RFC5226]. Code points in the range 61441 to 65534 are reserved for private use. The initial contents of this registry are: +-------------+----------------+-------------------------------+ | Application | Application-ID | Specification | +-------------+----------------+-------------------------------+ | INVALID | 0 | RFC 6940 | | SIP | 5060 | Reserved for use by SIP Usage | | SIP | 5061 | Reserved for use by SIP Usage | | Reserved | 65535 | RFC 6940 | +-------------+----------------+-------------------------------+14.6. Data Kind-ID
IANA has created a "RELOAD Data Kind-ID" registry. Entries in this registry are 32-bit integers denoting data Kinds, as described in Section 5.2 of [RFC6940]. Code points in the range 0x00000001 to 0x7FFFFFFF SHALL be registered via Standards Action [RFC5226]. Code points in the range 0x8000000 to 0xF0000000 SHALL be registered via Expert Review [RFC5226]. Code points in the range 0xF0000001 to 0xFFFFFFFE are reserved for private use via the Kind description mechanism described in Section 11 of [RFC6940]. The initial contents of this registry are: +---------------------+------------+-----------+ | Kind | Kind-ID | Reference | +---------------------+------------+-----------+ | INVALID | 0x0 | RFC 6940 | | TURN-SERVICE | 0x2 | RFC 6940 | | CERTIFICATE_BY_NODE | 0x3 | RFC 6940 | | CERTIFICATE_BY_USER | 0x10 | RFC 6940 | | Reserved | 0x7fffffff | RFC 6940 | | Reserved | 0xfffffffe | RFC 6940 | +---------------------+------------+-----------+
14.7. Data Model
IANA has created a "RELOAD Data Model" registry. Entries in this registry are strings denoting data models, as described in Section 7.2 of [RFC6940]. New entries in this registry SHALL be registered via Standards Action [RFC5226]. The initial contents of this registry are: +------------+-----------+ | Data Model | Reference | +------------+-----------+ | INVALID | RFC 6940 | | SINGLE | RFC 6940 | | ARRAY | RFC 6940 | | DICTIONARY | RFC 6940 | | EXP-DATA | RFC 6940 | | RESERVED | RFC 6940 | +------------+-----------+ The value EXP-DATA has been made available for the purposes of experimentation. This value is not meant for vendor-specific use of any sort, and it MUST NOT be used for operational deployments.14.8. Message Codes
IANA has created a "RELOAD Message Codes" registry. Entries in this registry are 16-bit integers denoting method codes, as described in Section 6.3.3 of [RFC6940]. These codes SHALL be registered via Standards Action [RFC5226]. The initial contents of this registry are:
+-------------------------------------+----------------+-----------+ | Message Code Name | Code Value | Reference | +-------------------------------------+----------------+-----------+ | invalidMessageCode | 0x0 | RFC 6940 | | probe_req | 0x1 | RFC 6940 | | probe_ans | 0x2 | RFC 6940 | | attach_req | 0x3 | RFC 6940 | | attach_ans | 0x4 | RFC 6940 | | Unassigned | 0x5 | | | Unassigned | 0x6 | | | store_req | 0x7 | RFC 6940 | | store_ans | 0x8 | RFC 6940 | | fetch_req | 0x9 | RFC 6940 | | fetch_ans | 0xA | RFC 6940 | | Unassigned (was remove_req) | 0xB | RFC 6940 | | Unassigned (was remove_ans) | 0xC | RFC 6940 | | find_req | 0xD | RFC 6940 | | find_ans | 0xE | RFC 6940 | | join_req | 0xF | RFC 6940 | | join_ans | 0x10 | RFC 6940 | | leave_req | 0x11 | RFC 6940 | | leave_ans | 0x12 | RFC 6940 | | update_req | 0x13 | RFC 6940 | | update_ans | 0x14 | RFC 6940 | | route_query_req | 0x15 | RFC 6940 | | route_query_ans | 0x16 | RFC 6940 | | ping_req | 0x17 | RFC 6940 | | ping_ans | 0x18 | RFC 6940 | | stat_req | 0x19 | RFC 6940 | | stat_ans | 0x1A | RFC 6940 | | Unassigned (was attachlite_req) | 0x1B | RFC 6940 | | Unassigned (was attachlite_ans) | 0x1C | RFC 6940 | | app_attach_req | 0x1D | RFC 6940 | | app_attach_ans | 0x1E | RFC 6940 | | Unassigned (was app_attachlite_req) | 0x1F | RFC 6940 | | Unassigned (was app_attachlite_ans) | 0x20 | RFC 6940 | | config_update_req | 0x21 | RFC 6940 | | config_update_ans | 0x22 | RFC 6940 | | exp_a_req | 0x23 | RFC 6940 | | exp_a_ans | 0x24 | RFC 6940 | | exp_b_req | 0x25 | RFC 6940 | | exp_b_ans | 0x26 | RFC 6940 | | Reserved | 0x8000..0xFFFE | RFC 6940 | | error | 0xFFFF | RFC 6940 | +-------------------------------------+----------------+-----------+
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 they MUST NOT be used for operational deployments.14.9. Error Codes
IANA has created a "RELOAD Error Code" registry. Entries in this registry are 16-bit integers denoting error codes, as described in Section 6.3.3.1 of [RFC6940]. New entries SHALL be defined via Standards Action [RFC5226]. The initial contents of this registry are: +-------------------------------------+----------------+-----------+ | Error Code Name | Code Value | Reference | +-------------------------------------+----------------+-----------+ | invalidErrorCode | 0x0 | RFC 6940 | | Unassigned | 0x1 | | | Error_Forbidden | 0x2 | RFC 6940 | | Error_Not_Found | 0x3 | RFC 6940 | | Error_Request_Timeout | 0x4 | RFC 6940 | | Error_Generation_Counter_Too_Low | 0x5 | RFC 6940 | | Error_Incompatible_with_Overlay | 0x6 | RFC 6940 | | Error_Unsupported_Forwarding_Option | 0x7 | RFC 6940 | | Error_Data_Too_Large | 0x8 | RFC 6940 | | Error_Data_Too_Old | 0x9 | RFC 6940 | | Error_TTL_Exceeded | 0xA | RFC 6940 | | Error_Message_Too_Large | 0xB | RFC 6940 | | Error_Unknown_Kind | 0xC | RFC 6940 | | Error_Unknown_Extension | 0xD | RFC 6940 | | Error_Response_Too_Large | 0xE | RFC 6940 | | Error_Config_Too_Old | 0xF | RFC 6940 | | Error_Config_Too_New | 0x10 | RFC 6940 | | Error_In_Progress | 0x11 | RFC 6940 | | Error_Exp_A | 0x12 | RFC 6940 | | Error_Exp_B | 0x13 | RFC 6940 | | Error_Invalid_Message | 0x14 | RFC 6940 | | Reserved | 0x8000..0xFFFE | RFC 6940 | +-------------------------------------+----------------+-----------+ 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 they MUST NOT be used for operational deployments.
14.10. Overlay Link Types
IANA has created a "RELOAD Overlay Link Registry". Entries in this registry are 8-bit integers, as described in Section 6.5.1.1 of [RFC6940]. For more information on the link types defined here, see Section 6.6 of [RFC6940]. New entries SHALL be defined via Standards Action [RFC5226]. This registry has been initially populated with the following values: +--------------------+------+-----------+ | Protocol | Code | Reference | +--------------------+------+-----------+ | INVALID-PROTOCOL | 0 | RFC 6940 | | DTLS-UDP-SR | 1 | RFC 6940 | | DTLS-UDP-SR-NO-ICE | 3 | RFC 6940 | | TLS-TCP-FH-NO-ICE | 4 | RFC 6940 | | EXP-LINK | 5 | RFC 6940 | | Reserved | 255 | RFC 6940 | +--------------------+------+-----------+ The value EXP-LINK has been made available for the purposes of experimentation. This value is not meant for vendor-specific use of any sort, and it MUST NOT be used for operational deployments.14.11. Overlay Link Protocols
IANA has created a "RELOAD Overlay Link Protocol Registry". Entries in this registry are strings denoting protocols as described in Section 11.1 of this document and SHALL be defined via Standards Action [RFC5226]. This registry has been initially populated with the following values: +---------------+-----------+ | Link Protocol | Reference | +---------------+-----------+ | TLS | RFC 6940 | | EXP-PROTOCOL | RFC 6940 | +---------------+-----------+ The value EXP-PROTOCOL has been made available for the purposes of experimentation. This value is not meant for vendor-specific use of any sort, and it MUST NOT be used for operational deployments.
14.12. Forwarding Options
IANA has created a "RELOAD Forwarding Option Registry". Entries in this registry are 8-bit integers denoting options, as described in Section 6.3.2.3 of [RFC6940]. Values between 1 and 127 SHALL be defined via Standards Action [RFC5226]. Entries in this registry between 128 and 254 SHALL be defined via Specification Required [RFC5226]. This registry has been initially populated with the following values: +-------------------------+------+-----------+ | Forwarding Option | Code | Reference | +-------------------------+------+-----------+ | invalidForwardingOption | 0 | RFC 6940 | | exp-forward | 1 | RFC 6940 | | Reserved | 255 | RFC 6940 | +-------------------------+------+-----------+ The value exp-forward has been made available for the purposes of experimentation. This value is not meant for vendor-specific use of any sort, and it MUST NOT be used for operational deployments.14.13. Probe Information Types
IANA has created a "RELOAD Probe Information Type Registry". Entries are 8-bit integers denoting types as described in Section 6.4.2.5.1 of [RFC6940] and SHALL be defined via Standards Action [RFC5226]. This registry has been initially populated with the following values: +--------------------+------+-----------+ | Probe Option | Code | Reference | +--------------------+------+-----------+ | invalidProbeOption | 0 | RFC 6940 | | responsible_set | 1 | RFC 6940 | | num_resources | 2 | RFC 6940 | | uptime | 3 | RFC 6940 | | exp-probe | 4 | RFC 6940 | | Reserved | 255 | RFC 6940 | +--------------------+------+-----------+ The value exp-probe has been made available for the purposes of experimentation. This value is not meant for vendor-specific use of any sort, and it MUST NOT be used for operational deployments.
14.14. Message Extensions
IANA has created a "RELOAD Extensions Registry". Entries in this registry are 8-bit integers denoting extensions as described in Section 6.3.3 of [RFC6940] and SHALL be defined via Specification Required [RFC5226]. This registry has been initially populated with the following values: +-----------------------------+--------+-----------+ | Extensions Name | Code | Reference | +-----------------------------+--------+-----------+ | invalidMessageExtensionType | 0x0 | RFC 6940 | | exp-ext | 0x1 | RFC 6940 | | Reserved | 0xFFFF | RFC 6940 | +-----------------------------+--------+-----------+ The value exp-ext has been made available for the purposes of experimentation. This value is not meant for vendor-specific use of any sort, and it MUST NOT be used for operational deployments.14.15. Reload URI Scheme
This section describes the scheme for a reload URI, which can be used to refer to either: o A peer, e.g., as used in a certificate (see Section 11.3 of [RFC6940]). 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 [RFC4395] per the following ABNF syntax: RELOAD-URI = "reload://" destination "@" overlay "/" [specifier] destination = 1*HEXDIG overlay = reg-name specifier = 1*HEXDIG The definitions of these productions are as follows: destination A hexadecimal-encoded Destination List object (i.e., multiple concatenated Destination objects with no length prefix prior to the object as a whole).
overlay
The name of the overlay.
specifier
A hexadecimal-encoded StoredDataSpecifier indicating the data
element.
If no specifier is present, this URI addresses the peer which can be
reached via the indicated Destination List at the indicated overlay
name. If a specifier is present, the URI addresses the data value.
14.15.1. URI Registration
The following summarizes the information necessary to register the
reload URI.
URI Scheme Name: reload
Status: permanent
URI Scheme Syntax: see Section 14.15 of RFC 6940
URI Scheme Semantics: The reload URI is intended to be used as a
reference to a RELOAD peer or resource.
Encoding Considerations: The reload URI is not intended to be human-
readable text, so it is encoded entirely in US-ASCII.
Applications/protocols that Use this URI Scheme: The RELOAD protocol
described in RFC 6940.
Interoperability Considerations: See RFC 6940.
Security Considerations: See RFC 6940
Contact: Cullen Jennings <fluffy@cisco.com>
Author/Change Controller: IESG
References: RFC 6940
14.16. Media Type Registration
Type Name: application
Subtype Name: p2p-overlay+xml
Required Parameters: none
Optional Parameters: none Encoding Considerations: Must be binary encoded. Security Considerations: This media type is typically not used to transport information that needs to be kept confidential. However, there are cases where it is integrity of the information is important. For these cases, using a digital signature is RECOMMENDED. One way of doing this is specified in RFC 6940. In the case when the media includes a shared-secret element, the contents of the file MUST be kept confidential or else anyone who can see the shared secret can affect the RELOAD overlay network. Interoperability Considerations: No known interoperability consideration beyond those identified for application/xml in [RFC3023]. Published Specification: RFC 6940 Applications that Use this Media Type: The type is used to configure the peer-to-peer overlay networks defined in RFC 6940. Additional Information: The syntax for this media type is specified in Section 11.1 of [RFC6940]. The contents MUST be valid XML that is compliant with the RELAX NG grammar specified in RFC 6940 and that use the UTF-8[RFC3629] character encoding. Magic Number(s): none File Extension(s): relo Macintosh File Type Code(s): none Person & Email Address to Contact for Further Information: Cullen Jennings <fluffy@cisco.com> Intended Usage: COMMON Restrictions on Usage: None Author: Cullen Jennings <fluffy@cisco.com> Change Controller: IESG14.17. XML Namespace Registration
This document registers two URIs for the config and config-chord XML namespaces in the IETF XML registry defined in [RFC3688].
14.17.1. Config URL
URI: urn:ietf:params:xml:ns:p2p:config-base Registrant Contact: IESG. XML: N/A, the requested URIs are XML namespaces14.17.2. Config Chord URL
URI: urn:ietf:params:xml:ns:p2p:config-chord Registrant Contact: The IESG. XML: N/A, the requested URIs are XML namespaces15. Acknowledgments
This specification is a merge of the "REsource LOcation And Discovery (RELOAD)" document by David A. Bryan, Marcia Zangrilli, and Bruce B. Lowekamp; the "Address Settlement by Peer to Peer" document by Cullen Jennings, Jonathan Rosenberg, and Eric Rescorla; the "Security Extensions for RELOAD" document by Bruce B. Lowekamp and James Deverick; the "A Chord-based DHT for Resource Lookup in P2PSIP" by Marcia Zangrilli and David A. Bryan; and the Peer-to-Peer Protocol (P2PP) document by Salman A. Baset, Henning Schulzrinne, and Marcin Matuszewski. Thanks to the authors of [RFC5389] for text included from that document. Vidya Narayanan provided many comments and improvements. The ideas and text for the Chord-specific extension data to the Leave mechanisms were provided by Jouni Maenpaa, Gonzalo Camarillo, and Jani Hautakorpi. Thanks to the many people who contributed, including Ted Hardie, Michael Chen, Dan York, Das Saumitra, Lyndsay Campbell, Brian Rosen, David Bryan, Dave Craig, and Julian Cain. Extensive last call comments were provided by Jouni Maenpaa, Roni Even, Gonzalo Camarillo, Ari Keranen, John Buford, Michael Chen, Frederic-Philippe Met, Mary Barnes, Roland Bless, David Bryan, and Polina Goltsman. Special thanks to Marc Petit-Huguenin, who provided an amazing amount of detailed review. Dean Willis and Marc Petit-Huguenin helped resolve and provided text to fix many comments received during the IESG review.
16. References
16.1. Normative References
[OASIS.relax_ng] Bray, T. and M. Murata, "RELAX NG Specification", December 2001. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2388] Masinter, L., "Returning Values from Forms: multipart/ form-data", RFC 2388, August 1998. [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, May 1999. [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001. [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001. [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002. [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005. [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 35, RFC 4395, February 2006. [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, June 2008. [RFC5273] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC): Transport Protocols", RFC 5273, June 2008. [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008. [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010. [RFC6091] Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys for Transport Layer Security (TLS) Authentication", RFC 6091, February 2011.
[RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, June 2011. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012. [W3C.REC-xmlschema-2-20041028] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-2-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>. [w3c-xml-namespaces] Bray, T., Hollander, D., Layman, A., Tobin, R., and University of Edinburgh and W3C, "Namespaces in XML 1.0 (Third Edition)", December 2008.16.2. Informative References
[Chord] Stoica, I., Morris, R., Liben-Nowell, D., Karger, D., Kaashoek, M., Dabek, F., and H. Balakrishnan, "Chord: A Scalable Peer-to-peer Lookup Protocol for Internet Applications", IEEE/ACM Transactions on Networking Volume 11, Issue 1, 17-32, Feb 2003, 2001. [DHT-RELOAD] Maenpaa, J. and G. Camarillo, "A Self-tuning Distributed Hash Table (DHT) for REsource LOcation And Discovery (RELOAD)", Work in Progress, August 2013. [Eclipse] Singh, A., Ngan, T., Druschel, T., and D. Wallach, "Eclipse Attacks on Overlay Networks: Threats and Defenses", INFOCOM 2006, April 2006. [P2P-DIAGNOSTICS] Song, H., Jiang, X., Even, R., and D. Bryan, "P2P Overlay Diagnostics", Work in Progress, August 2013. [P2PSIP-RELAY] Zong, N., Jiang, X., Even, R., and Y. Zhang, "An extension to RELOAD to support Relay Peer Routing", Work in Progress, October 2013.
[REDIR-RELOAD] Maenpaa, J. and G. Camarillo, "Service Discovery Usage for REsource LOcation And Discovery (RELOAD)", Work in Progress, August 2013. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [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. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005. [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005. [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006. [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007. [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, "Using the Secure Remote Password (SRP) Protocol for TLS Authentication", RFC 5054, November 2007. [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, December 2007. [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. [RFC5694] Camarillo, G., Ed., and IAB, "Peer-to-Peer (P2P) Architecture: Definition, Taxonomies, Examples, and Applicability", RFC 5694, November 2009. [RFC5765] Schulzrinne, H., Marocco, E., and E. Ivov, "Security Issues and Solutions in Peer-to-Peer Systems for Realtime Communications", RFC 5765, February 2010. [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, April 2010. [RFC6079] Camarillo, G., Nikander, P., Hautakorpi, J., Keranen, A., and A. Johnston, "HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment (BONE)", RFC 6079, January 2011. [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, "TCP Candidates with Interactive Connectivity Establishment (ICE)", RFC 6544, March 2012. [RFC7086] Keranen, A., Camarillo, G., and J. Maenpaa, "Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD)", RFC 7086, January 2014. [SIP-RELOAD] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., Schulzrinne, H., and T. Schmidt, "A SIP Usage for RELOAD", Work in Progress, July 2013. [Sybil] Douceur, J., "The Sybil Attack", IPTPS 02, March 2002. [UnixTime] Wikipedia, "Unix Time", 2013, <http://en.wikipedia.org/w/ index.php?title=Unix_time&oldid=551527446>. [bryan-design-hotp2p08] Bryan, D., Lowekamp, B., and M. Zangrilli, "The Design of a Versatile, Secure P2PSIP Communications Architecture for the Public Internet", Hot-P2P'08, 2008.
[handling-churn-usenix04] Rhea, S., Geels, D., Roscoe, T., and J. Kubiatowicz, "Handling Churn in a DHT", In Proc. of the USENIX Annual Technical Conference June 2004 USENIX 2004, 2004. [lookups-churn-p2p06] Wu, D., Tian, Y., and K. Ng, "Analytical Study on Improving DHT Lookup Performance under Churn", IEEE P2P'06, 2006. [minimizing-churn-sigcomm06] Godfrey, P., Shenker, S., and I. Stoica, "Minimizing Churn in Distributed Systems", SIGCOMM 2006, 2006. [non-transitive-dhts-worlds05] Freedman, M., Lakshminarayanan, K., Rhea, S., and I. Stoica, "Non-Transitive Connectivity and DHTs", WORLDS'05, 2005. [opendht-sigcomm05] Rhea, S., Godfrey, B., Karp, B., Kubiatowicz, J., Ratnasamy, S., Shenker, S., Stoica, I., and H. Yu, "OpenDHT: A Public DHT and its Uses", SIGCOMM'05, 2005. [vulnerabilities-acsac04] Srivatsa, M. and L. Liu, "Vulnerabilities and Security Threats in Structured Peer-to-Peer Systems: A Quantitative Analysis", ACSAC 2004, 2004. [wikiChord] Wikipedia, "Chord (peer-to-peer)", 2013, <http://en.wikipedia.org/w/ index.php?title=Chord_%28peer-to-peer%29&oldid=549516287>. [wikiKBR] Wikipedia, "Key-based routing", 2013, <en.wikipedia.org/w/ index.php?title=Key-based_routing&oldid=543850833>. [wikiSkiplist] Wikipedia, "Skip list", 2013, <http://en.wikipedia.org/w/ index.php?title=Skip_list&oldid=551304213>.
Appendix A. Routing Alternatives
Significant discussion has been focused on the selection of a routing algorithm for P2PSIP. This section discusses the motivations for selecting symmetric recursive routing for RELOAD and describes the extensions that would be required to support additional routing algorithms.A.1. Iterative vs. Recursive
Iterative routing has a number of advantages. It is easier to debug, consumes fewer resources on intermediate peers, and allows the querying peer to identify and route around misbehaving peers [non-transitive-dhts-worlds05]. However, in the presence of NATs, iterative routing is intolerably expensive, because a new connection must be established for each hop (using ICE) [bryan-design-hotp2p08]. Iterative routing is supported through the RouteQuery mechanism and is primarily intended for debugging. It also allows the querying peer to evaluate the routing decisions made by the peers at each hop, consider alternatives, and perhaps detect at what point the forwarding path fails.A.2. Symmetric vs. Forward Response
An alternative to the symmetric recursive routing method used by RELOAD is forward-only routing, where the response is routed to the requester as if it were a new message initiated by the responder. (In the previous example, Z sends the response to A as if it were sending a request.) Forward-only routing requires no state in either the message or intermediate peers. The drawback of forward-only routing is that it does not work when the overlay is unstable. For example, if A is in the process of joining the overlay and is sending a Join request to Z, it is not yet reachable via forward-only routing. Even if it is established in the overlay, if network failures produce temporary instability, A may not be reachable (and may be trying to stabilize its network connectivity via Attach messages). Furthermore, forward-only responses are less likely to reach the querying peer than symmetric recursive ones are, because the forward path is more likely to have a failed peer than is the request path (which was just tested to route the request) [non-transitive-dhts-worlds05].
An extension to RELOAD that supports forward-only routing but relies on symmetric responses as a fallback would be possible, but due to the complexities of determining when to use forward-only routing and when to fallback to symmetric routing, we have chosen not to include it as an option at this point.A.3. Direct Response
Another routing option is direct response routing, in which the response is returned directly to the querying node. In the previous example, if A encodes its IP address in the request, then Z can simply deliver the response directly to A. In the absence of NATs or other connectivity issues, this is the optimal routing technique. The challenge of implementing direct response routing is the presence of NATs. There are a number of complexities that must be addressed. In this discussion, we will continue our assumption that A issued the request and Z is generating the response. o The IP address listed by A may be unreachable, either due to NAT or firewall rules. Therefore, a direct response technique must fallback to symmetric response [non-transitive-dhts-worlds05]. The hop-by-hop ACKs used by RELOAD allow Z to determine when A has received the message (and the TLS negotiation will provide earlier confirmation that A is reachable), but this fallback requires a timeout that will increase the response latency whenever A is not reachable from Z. o Whenever A is behind a NAT it, will have multiple candidate IP addresses, each of which must be advertised to ensure connectivity. Therefore, Z will need to attempt multiple connections to deliver the response. o One (or all) of A's candidate addresses may route from Z to a different device on the Internet. In the worst case, these nodes may actually be running RELOAD on the same port. Therefore, it is absolutely necessary to establish a secure connection to authenticate A before delivering the response. This step diminishes the efficiency of direct response routing, because multiple round-trips are required before the message can be delivered. o If A is behind a NAT and does not have a connection already established with Z, there are only two ways the direct response will work. The first is that A and Z must both be behind the same NAT, in which case the NAT is not involved. In the more common case, when Z is outside A's NAT, the response will be received only if A's NAT implements endpoint-independent filtering. As the
choice of filtering mode conflates application transparency with
security [RFC4787] and no clear recommendation is available, the
prevalence of this feature in future devices remains unclear.
An extension to RELOAD that supports direct response routing but
relies on symmetric responses as a fallback would be possible, but
due to the complexities of determining when to use direct response
routing and when to fallback to symmetric routing, and the reduced
performance for responses to peers behind restrictive NATs, we have
chosen not to include it as an option at this point.
A.4. Relay Peers
[P2PSIP-RELAY] has proposed implementing a form of direct response by
having A identify a peer, Q, that will be directly reachable by any
other peer. A uses Attach to establish a connection with Q and
advertises Q's IP address in the request sent to Z. Z sends the
response to Q, which relays it to A. This then reduces the latency
to two hops, and Z is negotiating a secure connection to Q.
This technique relies on the relative population of nodes such as A
that require relay peers and peers such as Q that are capable of
serving as a relay peer. It also requires nodes to be able to
identify which category they are in. This identification problem has
turned out to be hard to solve and is still an open area of
exploration.
An extension to RELOAD that supports relay peers is possible, but due
to the complexities of implementing such an alternative, we have not
added such a feature to RELOAD at this point.
A concept similar to relay peers, essentially choosing a relay peer
at random, has previously been suggested to solve problems of pair-
wise non-transitivity [non-transitive-dhts-worlds05], but
deterministic filtering provided by NATs makes random relay peers no
more likely to work than the responding peer.
A.5. Symmetric Route Stability
A common concern about symmetric recursive routing has been that one
or more peers along the request path may fail before the response is
received. The significance of this problem essentially depends on
the response latency of the overlay. An overlay that produces slow
responses will be vulnerable to churn, whereas responses that are
delivered very quickly are vulnerable only to failures that occur
over that small interval.
The other aspect of this issue is whether the request itself can be successfully delivered. Assuming typical connection maintenance intervals, the time period between the last maintenance and the request being sent will be orders of magnitude greater than the delay between the request being forwarded and the response being received. Therefore, if the path was stable enough to be available to route the request, it is almost certainly going to remain available to route the response. An overlay that is unstable enough to suffer this type of failure frequently is unlikely to be able to support reliable functionality regardless of the routing mechanism. However, regardless of the 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. 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. o The overlay algorithm may dictate specific requirements for peer selection. These may include participating in the overlay to determine trustworthiness, controlling the number of peers in the overlay to reduce overly long routing paths, and ensuring minimum application uptime before a node can join as a peer. The ultimate criteria for a node to become a peer are determined by the overlay algorithm and specific deployment. A node acting as a client that has a full implementation of RELOAD and the appropriate overlay algorithm is capable of locating its responsible peer in the overlay and using Attach to establish a direct connection to that peer. In that way, it may elect to be reachable under either of the
routing approaches listed above. Particularly for overlay algorithms that elect nodes to serve as peers based on trustworthiness or population, the overlay algorithm may require such a client to locate itself at a particular place in the overlay.B.2. Clients as Application-Level Agents
SIP defines an extensive protocol for registration and security between a client and its registrar/proxy server(s). Any SIP device can act as a client of a RELOAD-based P2PSIP overlay if it contacts a peer that implements the server-side functionality required by the SIP protocol. In this case, the peer would be acting as if it were the user's peer and would need the appropriate credentials for that user. Application-level support for clients is defined by a usage. A usage offering support for application-level clients should specify how the security of the system is maintained when the data is moved between the application and RELOAD layers.
Authors' Addresses
Cullen Jennings Cisco 400 3rd Avenue SW, Suite 350 Calgary Canada EMail: fluffy@cisco.com Bruce B. Lowekamp (editor) Skype Palo Alto, CA USA EMail: bbl@lowekamp.net Eric Rescorla RTFM, Inc. 2064 Edgewood Drive Palo Alto, CA 94303 USA Phone: +1 650 678 2350 EMail: ekr@rtfm.com Salman A. Baset Columbia University 1214 Amsterdam Avenue New York, NY USA EMail: salman@cs.columbia.edu Henning Schulzrinne Columbia University 1214 Amsterdam Avenue New York, NY USA EMail: hgs@cs.columbia.edu