Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6940

REsource LOcation And Discovery (RELOAD) Base Protocol

Pages: 176
Proposed Standard
Errata
Part 7 of 7 – Pages 153 to 176
First   Prev   None

Top   ToC   RFC6940 - Page 153   prevText

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 | +-----------------------------+-------------------------------------+
Top   ToC   RFC6940 - Page 154

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.
Top   ToC   RFC6940 - Page 155

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 | +---------------------+------------+-----------+
Top   ToC   RFC6940 - Page 156

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:
Top   ToC   RFC6940 - Page 157
   +-------------------------------------+----------------+-----------+
   | 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 |
   +-------------------------------------+----------------+-----------+
Top   ToC   RFC6940 - Page 158
   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.
Top   ToC   RFC6940 - Page 159

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.
Top   ToC   RFC6940 - Page 160

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.
Top   ToC   RFC6940 - Page 161

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).
Top   ToC   RFC6940 - Page 162
   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
Top   ToC   RFC6940 - Page 163
   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: IESG

14.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].
Top   ToC   RFC6940 - Page 164

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 namespaces

14.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 namespaces

15. 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.
Top   ToC   RFC6940 - Page 165

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.
Top   ToC   RFC6940 - Page 166
   [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.
Top   ToC   RFC6940 - Page 167
   [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.
Top   ToC   RFC6940 - Page 168
   [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.
Top   ToC   RFC6940 - Page 169
   [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.
Top   ToC   RFC6940 - Page 170
   [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>.
Top   ToC   RFC6940 - Page 171

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].
Top   ToC   RFC6940 - Page 172
   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
Top   ToC   RFC6940 - Page 173
      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.
Top   ToC   RFC6940 - Page 174
   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
Top   ToC   RFC6940 - Page 175
   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.
Top   ToC   RFC6940 - Page 176

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