Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6940

REsource LOcation And Discovery (RELOAD) Base Protocol

Pages: 176
Proposed Standard
Errata
Part 1 of 7 – Pages 1 to 18
None   None   Next

Top   ToC   RFC6940 - Page 1
Internet Engineering Task Force (IETF)                       C. Jennings
Request for Comments: 6940                                         Cisco
Category: Standards Track                               B. Lowekamp, Ed.
ISSN: 2070-1721                                                    Skype
                                                             E. Rescorla
                                                              RTFM, Inc.
                                                                S. Baset
                                                          H. Schulzrinne
                                                     Columbia University
                                                            January 2014


         REsource LOcation And Discovery (RELOAD) Base Protocol

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 specify the Kinds of data that need to be stored for a particular application. RELOAD defines a security model based on a certificate enrollment service that provides unique identities. NAT traversal is a fundamental service of the protocol. RELOAD also allows access from "client" nodes that do not need to route traffic or store data for others. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6940.
Top   ToC   RFC6940 - Page 2
Copyright Notice

   Copyright (c) 2014 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
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 1.1. Basic Setting . . . . . . . . . . . . . . . . . . . . . . 8 1.2. Architecture . . . . . . . . . . . . . . . . . . . . . . 10 1.2.1. Usage Layer . . . . . . . . . . . . . . . . . . . . . 13 1.2.2. Message Transport . . . . . . . . . . . . . . . . . . 13 1.2.3. Storage . . . . . . . . . . . . . . . . . . . . . . . 14 1.2.4. Topology Plug-in . . . . . . . . . . . . . . . . . . 15 1.2.5. Forwarding and Link Management Layer . . . . . . . . 16 1.3. Security . . . . . . . . . . . . . . . . . . . . . . . . 16 1.4. Structure of This Document . . . . . . . . . . . . . . . 17 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 18 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 18 4. Overlay Management Overview . . . . . . . . . . . . . . . . . 21 4.1. Security and Identification . . . . . . . . . . . . . . . 21 4.1.1. Shared-Key Security . . . . . . . . . . . . . . . . . 23 4.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.2.1. Client Routing . . . . . . . . . . . . . . . . . . . 24 4.2.2. Minimum Functionality Requirements for Clients . . . 25 4.3. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 25
Top   ToC   RFC6940 - Page 3
     4.4.  Connectivity Management . . . . . . . . . . . . . . . . .  29
     4.5.  Overlay Algorithm Support . . . . . . . . . . . . . . . .  30
       4.5.1.  Support for Pluggable Overlay Algorithms  . . . . . .  30
       4.5.2.  Joining, Leaving, and Maintenance Overview  . . . . .  30
     4.6.  First-Time Setup  . . . . . . . . . . . . . . . . . . . .  32
       4.6.1.  Initial Configuration . . . . . . . . . . . . . . . .  32
       4.6.2.  Enrollment  . . . . . . . . . . . . . . . . . . . . .  32
       4.6.3.  Diagnostics . . . . . . . . . . . . . . . . . . . . .  33
   5.  Application Support Overview  . . . . . . . . . . . . . . . .  33
     5.1.  Data Storage  . . . . . . . . . . . . . . . . . . . . . .  33
       5.1.1.  Storage Permissions . . . . . . . . . . . . . . . . .  34
       5.1.2.  Replication . . . . . . . . . . . . . . . . . . . . .  35
     5.2.  Usages  . . . . . . . . . . . . . . . . . . . . . . . . .  36
     5.3.  Service Discovery . . . . . . . . . . . . . . . . . . . .  36
     5.4.  Application Connectivity  . . . . . . . . . . . . . . . .  36
   6.  Overlay Management Protocol . . . . . . . . . . . . . . . . .  37
     6.1.  Message Receipt and Forwarding  . . . . . . . . . . . . .  37
       6.1.1.  Responsible ID  . . . . . . . . . . . . . . . . . . .  38
       6.1.2.  Other ID  . . . . . . . . . . . . . . . . . . . . . .  38
       6.1.3.  Opaque ID . . . . . . . . . . . . . . . . . . . . . .  40
     6.2.  Symmetric Recursive Routing . . . . . . . . . . . . . . .  41
       6.2.1.  Request Origination . . . . . . . . . . . . . . . . .  41
       6.2.2.  Response Origination  . . . . . . . . . . . . . . . .  42
     6.3.  Message Structure . . . . . . . . . . . . . . . . . . . .  42
       6.3.1.  Presentation Language . . . . . . . . . . . . . . . .  43
         6.3.1.1.  Common Definitions  . . . . . . . . . . . . . . .  44
       6.3.2.  Forwarding Header . . . . . . . . . . . . . . . . . .  46
         6.3.2.1.  Processing Configuration Sequence Numbers . . . .  49
         6.3.2.2.  Destination and Via Lists . . . . . . . . . . . .  50
         6.3.2.3.  Forwarding Option . . . . . . . . . . . . . . . .  52
       6.3.3.  Message Contents Format . . . . . . . . . . . . . . .  53
         6.3.3.1.  Response Codes and Response Errors  . . . . . . .  54
       6.3.4.  Security Block  . . . . . . . . . . . . . . . . . . .  57
     6.4.  Overlay Topology  . . . . . . . . . . . . . . . . . . . .  60
       6.4.1.  Topology Plug-in Requirements . . . . . . . . . . . .  60
       6.4.2.  Methods and Types for Use by Topology Plug-ins  . . .  61
         6.4.2.1.  Join  . . . . . . . . . . . . . . . . . . . . . .  61
         6.4.2.2.  Leave . . . . . . . . . . . . . . . . . . . . . .  62
         6.4.2.3.  Update  . . . . . . . . . . . . . . . . . . . . .  63
         6.4.2.4.  RouteQuery  . . . . . . . . . . . . . . . . . . .  63
         6.4.2.5.  Probe . . . . . . . . . . . . . . . . . . . . . .  65
     6.5.  Forwarding and Link Management Layer  . . . . . . . . . .  67
       6.5.1.  Attach  . . . . . . . . . . . . . . . . . . . . . . .  67
         6.5.1.1.  Request Definition  . . . . . . . . . . . . . . .  68
         6.5.1.2.  Response Definition . . . . . . . . . . . . . . .  70
         6.5.1.3.  Using ICE with RELOAD . . . . . . . . . . . . . .  71
         6.5.1.4.  Collecting STUN Servers . . . . . . . . . . . . .  71
         6.5.1.5.  Gathering Candidates  . . . . . . . . . . . . . .  72
Top   ToC   RFC6940 - Page 4
         6.5.1.6.  Prioritizing Candidates . . . . . . . . . . . . .  72
         6.5.1.7.  Encoding the Attach Message . . . . . . . . . . .  73
         6.5.1.8.  Verifying ICE Support . . . . . . . . . . . . . .  74
         6.5.1.9.  Role Determination  . . . . . . . . . . . . . . .  74
         6.5.1.10. Full ICE  . . . . . . . . . . . . . . . . . . . .  74
         6.5.1.11. No-ICE  . . . . . . . . . . . . . . . . . . . . .  75
         6.5.1.12. Subsequent Offers and Answers . . . . . . . . . .  75
         6.5.1.13. Sending Media . . . . . . . . . . . . . . . . . .  75
         6.5.1.14. Receiving Media . . . . . . . . . . . . . . . . .  75
       6.5.2.  AppAttach . . . . . . . . . . . . . . . . . . . . . .  75
         6.5.2.1.  Request Definition  . . . . . . . . . . . . . . .  76
         6.5.2.2.  Response Definition . . . . . . . . . . . . . . .  77
       6.5.3.  Ping  . . . . . . . . . . . . . . . . . . . . . . . .  77
         6.5.3.1.  Request Definition  . . . . . . . . . . . . . . .  77
         6.5.3.2.  Response Definition . . . . . . . . . . . . . . .  77
       6.5.4.  ConfigUpdate  . . . . . . . . . . . . . . . . . . . .  78
         6.5.4.1.  Request Definition  . . . . . . . . . . . . . . .  78
         6.5.4.2.  Response Definition . . . . . . . . . . . . . . .  79
     6.6.  Overlay Link Layer  . . . . . . . . . . . . . . . . . . .  80
       6.6.1.  Future Overlay Link Protocols . . . . . . . . . . . .  81
         6.6.1.1.  HIP . . . . . . . . . . . . . . . . . . . . . . .  82
         6.6.1.2.  ICE-TCP . . . . . . . . . . . . . . . . . . . . .  82
         6.6.1.3.  Message-Oriented Transports . . . . . . . . . . .  82
         6.6.1.4.  Tunneled Transports . . . . . . . . . . . . . . .  82
       6.6.2.  Framing Header  . . . . . . . . . . . . . . . . . . .  83
       6.6.3.  Simple Reliability  . . . . . . . . . . . . . . . . .  84
         6.6.3.1.  Stop and Wait Sender Algorithm  . . . . . . . . .  85
       6.6.4.  DTLS/UDP with SR  . . . . . . . . . . . . . . . . . .  86
       6.6.5.  TLS/TCP with FH, No-ICE . . . . . . . . . . . . . . .  86
       6.6.6.  DTLS/UDP with SR, No-ICE  . . . . . . . . . . . . . .  87
     6.7.  Fragmentation and Reassembly  . . . . . . . . . . . . . .  87
   7.  Data Storage Protocol . . . . . . . . . . . . . . . . . . . .  88
     7.1.  Data Signature Computation  . . . . . . . . . . . . . . .  90
     7.2.  Data Models . . . . . . . . . . . . . . . . . . . . . . .  91
       7.2.1.  Single Value  . . . . . . . . . . . . . . . . . . . .  91
       7.2.2.  Array . . . . . . . . . . . . . . . . . . . . . . . .  92
       7.2.3.  Dictionary  . . . . . . . . . . . . . . . . . . . . .  92
     7.3.  Access Control Policies . . . . . . . . . . . . . . . . .  93
       7.3.1.  USER-MATCH  . . . . . . . . . . . . . . . . . . . . .  93
       7.3.2.  NODE-MATCH  . . . . . . . . . . . . . . . . . . . . .  93
       7.3.3.  USER-NODE-MATCH . . . . . . . . . . . . . . . . . . .  93
       7.3.4.  NODE-MULTIPLE . . . . . . . . . . . . . . . . . . . .  94
     7.4.  Data Storage Methods  . . . . . . . . . . . . . . . . . .  94
       7.4.1.  Store . . . . . . . . . . . . . . . . . . . . . . . .  94
         7.4.1.1.  Request Definition  . . . . . . . . . . . . . . .  94
         7.4.1.2.  Response Definition . . . . . . . . . . . . . . . 100
         7.4.1.3.  Removing Values . . . . . . . . . . . . . . . . . 101
Top   ToC   RFC6940 - Page 5
       7.4.2.  Fetch . . . . . . . . . . . . . . . . . . . . . . . . 102
         7.4.2.1.  Request Definition  . . . . . . . . . . . . . . . 102
         7.4.2.2.  Response Definition . . . . . . . . . . . . . . . 104
       7.4.3.  Stat  . . . . . . . . . . . . . . . . . . . . . . . . 105
         7.4.3.1.  Request Definition  . . . . . . . . . . . . . . . 105
         7.4.3.2.  Response Definition . . . . . . . . . . . . . . . 106
       7.4.4.  Find  . . . . . . . . . . . . . . . . . . . . . . . . 107
         7.4.4.1.  Request Definition  . . . . . . . . . . . . . . . 108
         7.4.4.2.  Response Definition . . . . . . . . . . . . . . . 108
       7.4.5.  Defining New Kinds  . . . . . . . . . . . . . . . . . 109
   8.  Certificate Store Usage . . . . . . . . . . . . . . . . . . . 110
   9.  TURN Server Usage . . . . . . . . . . . . . . . . . . . . . . 110
   10. Chord Algorithm . . . . . . . . . . . . . . . . . . . . . . . 112
     10.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . 113
     10.2.  Hash Function  . . . . . . . . . . . . . . . . . . . . . 114
     10.3.  Routing  . . . . . . . . . . . . . . . . . . . . . . . . 114
     10.4.  Redundancy . . . . . . . . . . . . . . . . . . . . . . . 114
     10.5.  Joining  . . . . . . . . . . . . . . . . . . . . . . . . 115
     10.6.  Routing Attaches . . . . . . . . . . . . . . . . . . . . 116
     10.7.  Updates  . . . . . . . . . . . . . . . . . . . . . . . . 117
       10.7.1.  Handling Neighbor Failures . . . . . . . . . . . . . 118
       10.7.2.  Handling Finger Table Entry Failure  . . . . . . . . 119
       10.7.3.  Receiving Updates  . . . . . . . . . . . . . . . . . 119
       10.7.4.  Stabilization  . . . . . . . . . . . . . . . . . . . 120
         10.7.4.1.  Updating the Neighbor Table  . . . . . . . . . . 120
         10.7.4.2.  Refreshing the Finger Table  . . . . . . . . . . 121
         10.7.4.3.  Adjusting Finger Table Size  . . . . . . . . . . 122
         10.7.4.4.  Detecting Partitioning . . . . . . . . . . . . . 122
     10.8.  Route Query  . . . . . . . . . . . . . . . . . . . . . . 123
     10.9.  Leaving  . . . . . . . . . . . . . . . . . . . . . . . . 123
   11. Enrollment and Bootstrap  . . . . . . . . . . . . . . . . . . 124
     11.1.  Overlay Configuration  . . . . . . . . . . . . . . . . . 124
       11.1.1.  RELAX NG Grammar . . . . . . . . . . . . . . . . . . 132
     11.2.  Discovery through Configuration Server . . . . . . . . . 134
     11.3.  Credentials  . . . . . . . . . . . . . . . . . . . . . . 135
       11.3.1.  Self-Generated Credentials . . . . . . . . . . . . . 137
     11.4.  Contacting a Bootstrap Node  . . . . . . . . . . . . . . 138
   12. Message Flow Example  . . . . . . . . . . . . . . . . . . . . 138
   13. Security Considerations . . . . . . . . . . . . . . . . . . . 144
     13.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . 144
     13.2.  Attacks on P2P Overlays  . . . . . . . . . . . . . . . . 145
     13.3.  Certificate-Based Security . . . . . . . . . . . . . . . 145
     13.4.  Shared-Secret Security . . . . . . . . . . . . . . . . . 147
     13.5.  Storage Security . . . . . . . . . . . . . . . . . . . . 147
       13.5.1.  Authorization  . . . . . . . . . . . . . . . . . . . 147
       13.5.2.  Distributed Quota  . . . . . . . . . . . . . . . . . 148
       13.5.3.  Correctness  . . . . . . . . . . . . . . . . . . . . 148
       13.5.4.  Residual Attacks . . . . . . . . . . . . . . . . . . 149
Top   ToC   RFC6940 - Page 6
     13.6.  Routing Security . . . . . . . . . . . . . . . . . . . . 149
       13.6.1.  Background . . . . . . . . . . . . . . . . . . . . . 150
       13.6.2.  Admissions Control . . . . . . . . . . . . . . . . . 150
       13.6.3.  Peer Identification and Authentication . . . . . . . 151
       13.6.4.  Protecting the Signaling . . . . . . . . . . . . . . 151
       13.6.5.  Routing Loops and DoS Attacks  . . . . . . . . . . . 152
       13.6.6.  Residual Attacks . . . . . . . . . . . . . . . . . . 152
   14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 153
     14.1.  Well-Known URI Registration  . . . . . . . . . . . . . . 153
     14.2.  Port Registrations . . . . . . . . . . . . . . . . . . . 153
     14.3.  Overlay Algorithm Types  . . . . . . . . . . . . . . . . 154
     14.4.  Access Control Policies  . . . . . . . . . . . . . . . . 154
     14.5.  Application-ID . . . . . . . . . . . . . . . . . . . . . 155
     14.6.  Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . 155
     14.7.  Data Model . . . . . . . . . . . . . . . . . . . . . . . 156
     14.8.  Message Codes  . . . . . . . . . . . . . . . . . . . . . 156
     14.9.  Error Codes  . . . . . . . . . . . . . . . . . . . . . . 158
     14.10. Overlay Link Types . . . . . . . . . . . . . . . . . . . 159
     14.11. Overlay Link Protocols . . . . . . . . . . . . . . . . . 159
     14.12. Forwarding Options . . . . . . . . . . . . . . . . . . . 160
     14.13. Probe Information Types  . . . . . . . . . . . . . . . . 160
     14.14. Message Extensions . . . . . . . . . . . . . . . . . . . 161
     14.15. Reload URI Scheme  . . . . . . . . . . . . . . . . . . . 161
       14.15.1.  URI Registration  . . . . . . . . . . . . . . . . . 162
     14.16. Media Type Registration  . . . . . . . . . . . . . . . . 162
     14.17. XML Namespace Registration . . . . . . . . . . . . . . . 163
       14.17.1.  Config URL  . . . . . . . . . . . . . . . . . . . . 164
       14.17.2.  Config Chord URL  . . . . . . . . . . . . . . . . . 164
   15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 164
   16. References  . . . . . . . . . . . . . . . . . . . . . . . . . 165
     16.1.  Normative References . . . . . . . . . . . . . . . . . . 165
     16.2.  Informative References . . . . . . . . . . . . . . . . . 167
   Appendix A.  Routing Alternatives . . . . . . . . . . . . . . . . 171
     A.1.  Iterative vs. Recursive . . . . . . . . . . . . . . . . . 171
     A.2.  Symmetric vs. Forward Response  . . . . . . . . . . . . . 171
     A.3.  Direct Response . . . . . . . . . . . . . . . . . . . . . 172
     A.4.  Relay Peers . . . . . . . . . . . . . . . . . . . . . . . 173
     A.5.  Symmetric Route Stability . . . . . . . . . . . . . . . . 173
   Appendix B.  Why Clients? . . . . . . . . . . . . . . . . . . . . 174
     B.1.  Why Not Only Peers? . . . . . . . . . . . . . . . . . . . 174
     B.2.  Clients as Application-Level Agents . . . . . . . . . . . 175
Top   ToC   RFC6940 - Page 7

1. Introduction

This document defines REsource LOcation And Discovery (RELOAD), a peer-to-peer (P2P) signaling protocol for use on the Internet. RELOAD provides a generic, self-organizing overlay network service, allowing nodes to route messages to other nodes and to store and retrieve data in the overlay. RELOAD provides several features that are critical for a successful P2P protocol for the Internet: Security Framework: A P2P network will often be established among a set of peers that do not trust each other. RELOAD leverages a central enrollment server to provide credentials for each peer, which can then be used to authenticate each operation. This greatly reduces the possible attack surface. Usage Model: RELOAD is designed to support a variety of applications, including P2P multimedia communications with the Session Initiation Protocol (SIP) [SIP-RELOAD]. RELOAD allows the definition of new application usages, each of which can define its own data types, along with the rules for their use. This allows RELOAD to be used with new applications through a simple documentation process that supplies the details for each application. NAT Traversal: RELOAD is designed to function in environments where many, if not most, of the nodes are behind NATs or firewalls. Operations for NAT traversal are part of the base design, including using Interactive Connectivity Establishment (ICE) [RFC5245] to establish new RELOAD or application protocol connections. Optimized Routing: The very nature of overlay algorithms introduces a requirement that peers participating in the P2P network route requests on behalf of other peers in the network. This introduces a load on those other peers in the form of bandwidth and processing power. RELOAD has been defined with a simple, lightweight forwarding header, thus minimizing the amount of effort for intermediate peers. Pluggable Overlay Algorithms: RELOAD has been designed with an abstract interface to the overlay layer to simplify implementing a variety of structured (e.g., distributed hash tables (DHTs)) and unstructured overlay algorithms. The idea here is that RELOAD provides a generic structure that can fit most types of overlay topologies (ring, hyperspace, etc.). To instantiate an actual network, you combine RELOAD with a specific overlay algorithm, which defines how to construct the overlay topology and route messages efficiently within it. This specification also defines
Top   ToC   RFC6940 - Page 8
      how RELOAD is used with the Chord-based [Chord] DHT algorithm,
      which is mandatory to implement.  Specifying a default "mandatory-
      to-implement" overlay algorithm promotes interoperability, while
      extensibility allows selection of overlay algorithms optimized for
      a particular application.

   Support for Clients:  RELOAD clients differ from RELOAD peers
      primarily in that they do not store information on behalf of other
      nodes in the overlay.  Rather, they use the overlay only to locate
      users and resources, as well as to store information and to
      contact other nodes.

   These properties were designed specifically to meet the requirements
   for a P2P protocol to support SIP.  This document defines the base
   protocol for the distributed storage and location service, as well as
   critical usage for NAT traversal.  The SIP Usage itself is described
   separately in [SIP-RELOAD].  RELOAD is not limited to usage by SIP
   and could serve as a tool for supporting other P2P applications with
   similar needs.

1.1. Basic Setting

In this section, we provide a brief overview of the operational setting for RELOAD. A RELOAD Overlay Instance consists of a set of nodes arranged in a partly connected graph. Each node in the overlay is assigned a numeric Node-ID for the lifetime of the node, which, together with the specific overlay algorithm in use, determines its position in the graph and the set of nodes it connects to. The Node-ID is also tightly coupled to the certificate (see Section 13.3). The figure below shows a trivial example which isn't drawn from any particular overlay algorithm, but was chosen for convenience of representation.
Top   ToC   RFC6940 - Page 9
      +--------+              +--------+              +--------+
      | Node 10|--------------| Node 20|--------------| Node 30|
      +--------+              +--------+              +--------+
          |                       |                       |
          |                       |                       |
      +--------+              +--------+              +--------+
      | Node 40|--------------| Node 50|--------------| Node 60|
      +--------+              +--------+              +--------+
          |                       |                       |
          |                       |                       |
      +--------+              +--------+              +--------+
      | Node 70|--------------| Node 80|--------------| Node 90|
      +--------+              +--------+              +--------+
                                  |
                                  |
                              +--------+
                              | Node 85|
                              |(Client)|
                              +--------+

   Because the graph is not fully connected, when a node wants to send a
   message to another node, it may need to route it through the network.
   For instance, Node 10 can talk directly to nodes 20 and 40, but not
   to Node 70.  In order to send a message to Node 70, it would first
   send it to Node 40, with instructions to pass it along to Node 70.
   Different overlay algorithms will have different connectivity graphs,
   but the general idea behind all of them is to allow any node in the
   graph to efficiently reach every other node within a small number of
   hops.

   The RELOAD network is not only a messaging network.  It is also a
   storage network, albeit one designed for small-scale transient
   storage rather than for bulk storage of large objects.  Records are
   stored under numeric addresses, called Resource-IDs, which occupy the
   same space as node identifiers.  Peers are responsible for storing
   the data associated with some set of addresses, as determined by
   their Node-ID.  For instance, we might say that every peer is
   responsible for storing any data value which has an address less than
   or equal to its own Node-ID, but greater than the next lowest
   Node-ID.  Thus, Node 20 would be responsible for storing values
   11-20.

   RELOAD also supports clients.  These are nodes which have Node-IDs
   but do not participate in routing or storage.  For instance, in the
   figure above, Node 85 is a client.  It can route to the rest of the
   RELOAD network via Node 80, but no other node will route through it,
   and Node 90 is still responsible for addresses in the range [81..90].
   We refer to non-client nodes as peers.
Top   ToC   RFC6940 - Page 10
   Other applications (for instance, SIP) can be defined on top of
   RELOAD and can use these two basic RELOAD services to provide their
   own services.

1.2. Architecture

RELOAD is fundamentally an overlay network. The following figure shows the layered RELOAD architecture. Application +-------+ +-------+ | SIP | | XMPP | ... | Usage | | Usage | +-------+ +-------+ ------------------------------------ Messaging Service Boundary +------------------+ +---------+ | Message |<--->| Storage | | Transport | +---------+ +------------------+ ^ ^ ^ | | v v | +-------------------+ | | Topology | | | Plug-in | | +-------------------+ | ^ v v +------------------+ | Forwarding & | | Link Management | +------------------+ ------------------------------------ Overlay Link Service Boundary +-------+ +-------+ |TLS | |DTLS | ... |Overlay| |Overlay| |Link | |Link | +-------+ +-------+ The major components of RELOAD are: Usage Layer: Each application defines a RELOAD Usage, which is a set of data Kinds and behaviors which describe how to use the services provided by RELOAD. These usages all talk to RELOAD through a common Message Transport Service.
Top   ToC   RFC6940 - Page 11
   Message Transport:  Handles end-to-end reliability, manages request
      state for the usages, and forwards Store and Fetch operations to
      the Storage component.  It delivers message responses to the
      component initiating the request.

   Storage:  The Storage component is responsible for processing
      messages relating to the storage and retrieval of data.  It talks
      directly to the Topology Plug-in to manage data replication and
      migration, and it talks to the Message Transport component to send
      and receive messages.

   Topology Plug-in:  The Topology Plug-in is responsible for
      implementing the specific overlay algorithm being used.  It uses
      the Message Transport component to send and receive overlay
      management messages, the Storage component to manage data
      replication, and the Forwarding Layer to control hop-by-hop
      message forwarding.  This component superficially parallels
      conventional routing algorithms, but is more tightly coupled to
      the Forwarding Layer, because there is no single "Routing Table"
      equivalent used by all overlay algorithms.  The Topology Plug-in
      has two functions: constructing the local forwarding instructions
      and selecting the operational topology (i.e., creating links by
      sending overlay management messages).

   Forwarding and Link Management Layer:  Stores and implements the
      Routing Table by providing packet forwarding services between
      nodes.  It also handles establishing new links between nodes,
      including setting up connections for overlay links across NATs
      using ICE.

   Overlay Link Layer:  Responsible for actually transporting traffic
      directly between nodes.  Transport Layer Security (TLS) [RFC5246]
      and Datagram Transport Layer Security (DTLS) [RFC6347] are the
      currently defined "overlay link layer" protocols used by RELOAD
      for hop-by-hop communication.  Each such protocol includes the
      appropriate provisions for per-hop framing and hop-by-hop ACKs
      needed by unreliable underlying transports.  New protocols can be
      defined, as described in Sections 6.6.1 and 11.1.  As this
      document defines only TLS and DTLS, we use those terms throughout
      the remainder of the document with the understanding that some
      future specification may add new overlay link layers.
Top   ToC   RFC6940 - Page 12
   To further clarify the roles of the various layers, the following
   figure parallels the architecture with each layer's role from an
   overlay perspective and implementation layer in the Internet:

    Internet    | Internet Model  |
    Model       |   Equivalent    |          Reload
                |   in Overlay    |       Architecture
   -------------+-----------------+------------------------------------
                |                 |    +-------+  +-------+
                |  Application    |    | SIP   |  | XMPP  |  ...
                |                 |    | Usage |  | Usage |
                |                 |    +-------+  +-------+
                |                 |  ----------------------------------
                |                 |+------------------+     +---------+
                |   Transport     ||     Message      |<--->| Storage |
                |                 ||    Transport     |     +---------+
                |                 |+------------------+           ^
                |                 |       ^       ^               |
                |                 |       |       v               v
   Application  |                 |       |     +-------------------+
                |   (Routing)     |       |     |     Topology      |
                |                 |       |     |     Plug-in       |
                |                 |       |     +-------------------+
                |                 |       |         ^
                |                 |       v         v
                |    Network      |    +------------------+
                |                 |    |  Forwarding &    |
                |                 |    | Link Management  |
                |                 |    +------------------+
                |                 |  ----------------------------------
   Transport    |      Link       |     +-------+  +------+
                |                 |     |TLS    |  |DTLS  |  ...
                |                 |     +-------+  +------+
   -------------+-----------------+------------------------------------
     Network    |
                |
       Link     |

   In addition to the above components, nodes may communicate with a
   central provisioning infrastructure (not shown) to get configuration
   information, authentication credentials, and the initial set of nodes
   to communicate with to join the overlay.
Top   ToC   RFC6940 - Page 13

1.2.1. Usage Layer

The top layer, called the Usage Layer, has application usages, such as the SIP Registration Usage [SIP-RELOAD], that use the abstract Message Transport Service provided by RELOAD. The goal of this layer is to implement application-specific usages of the generic overlay services provided by RELOAD. The Usage defines how a specific application maps its data into something that can be stored in the overlay, where to store the data, how to secure the data, and finally how applications can retrieve and use the data. The architecture diagram shows both a SIP Usage and an XMPP Usage. A single application may require multiple usages; for example, a voicemail feature in a softphone application that stores links to the messages in the overlay would require a different usage than the type of rendezvous service of XMPP or SIP. A usage may define multiple Kinds of data that are stored in the overlay and may also rely on Kinds originally defined by other usages. Because the security and storage policies for each Kind are dictated by the usage defining the Kind, the usages may be coupled with the Storage component to provide security policy enforcement and to implement appropriate storage strategies according to the needs of the usage. The exact implementation of such an interface is outside the scope of this specification.

1.2.2. Message Transport

The Message Transport component provides a generic message routing service for the overlay. The Message Transport layer is responsible for end-to-end message transactions. Each peer is identified by its location in the overlay, as determined by its Node-ID. A component that is a client of the Message Transport can perform two basic functions: o Send a message to a given peer specified by Node-ID or to the peer responsible for a particular Resource-ID. o Receive messages that other peers sent to a Node-ID or Resource-ID for which the receiving peer is responsible. All usages rely on the Message Transport component to send and receive messages from peers. For instance, when a usage wants to store data, it does so by sending Store requests. Note that the Storage component and the Topology Plug-in are themselves clients of the Message Transport, because they need to send and receive messages from other peers.
Top   ToC   RFC6940 - Page 14
   The Message Transport Service is responsible for end-to-end
   reliability, which is accomplished by timer-based retransmissions.
   Unlike the Internet transport layer, however, this layer does not
   provide congestion control.  RELOAD is a request-response protocol,
   with no more than two pairs of request-response messages used in
   typical transactions between pairs of nodes; therefore, there are no
   opportunities to observe and react to end-to-end congestion.  As with
   all Internet applications, implementers are strongly discouraged from
   writing applications that react to loss by immediately retrying the
   transaction.

   The Message Transport Service is similar to those described as
   providing "key-based routing" (KBR) [wikiKBR], although as RELOAD
   supports different overlay algorithms (including non-DHT overlay
   algorithms) that calculate keys (storage indices, not encryption
   keys) in different ways, the actual interface needs to accept
   Resource Names rather than actual keys.

   The Forwarding and Link Management layers are responsible for
   maintaining the overlay in the face of changes in the available nodes
   and underlying network supporting the overlay (the Internet).  They
   also handle congestion control between overlay neighbors, and
   exchange routing updates and data replicas in addition to forwarding
   end-to-end messages.

   Real-world experience has shown that a fixed timeout for the end-to-
   end retransmission timer is sufficient for practical overlay
   networks.  This timer is adjustable via the overlay configuration.
   As the overlay configuration can be rapidly updated, this value could
   be dynamically adjusted at coarse time scales, although algorithms
   for determining how to accomplish this are beyond the scope of this
   specification.  In many cases, however, other means of improving
   network performance, such as having the Topology Plug-in remove lossy
   links from use in overlay routing or reducing the overall hop count
   of end-to-end paths, will be more effective than simply increasing
   the retransmission timer.

1.2.3. Storage

One of the major functions of RELOAD is storage of data, that is, allowing nodes to store data in the overlay and to retrieve data stored by other nodes or by themselves. The Storage component is responsible for processing data storage and retrieval messages. For instance, the Storage component might receive a Store request for a given resource from the Message Transport. It would then query the appropriate usage before storing the data value(s) in its local data store and sending a response to the Message Transport for delivery to the requesting node. Typically, these messages will come from other
Top   ToC   RFC6940 - Page 15
   nodes, but depending on the overlay topology, a node might be
   responsible for storing data for itself as well, especially if the
   overlay is small.

   A peer's Node-ID determines the set of resources that it will be
   responsible for storing.  However, the exact mapping between these is
   determined by the overlay algorithm in use.  The Storage component
   will only receive a Store request from the Message Transport if this
   peer is responsible for that Resource-ID.  The Storage component is
   notified by the Topology Plug-in when the Resource-IDs for which it
   is responsible change, and the Storage component is then responsible
   for migrating resources to other peers.

1.2.4. Topology Plug-in

RELOAD is explicitly designed to work with a variety of overlay algorithms. In order to facilitate this, the overlay algorithm implementation is provided by a Topology Plug-in so that each overlay can select an appropriate overlay algorithm that relies on the common RELOAD core protocols and code. The Topology Plug-in is responsible for maintaining the overlay algorithm Routing Table, which is consulted by the Forwarding and Link Management Layer before routing a message. When connections are made or broken, the Forwarding and Link Management Layer notifies the Topology Plug-in, which adjusts the Routing Table as appropriate. The Topology Plug-in will also instruct the Forwarding and Link Management Layer to form new connections as dictated by the requirements of the overlay algorithm Topology. The Topology Plug-in issues periodic update requests through Message Transport to maintain and update its Routing Table. As peers enter and leave, resources may be stored on different peers, so the Topology Plug-in also keeps track of which peers are responsible for which resources. As peers join and leave, the Topology Plug-in instructs the Storage component to issue resource migration requests as appropriate, in order to ensure that other peers have whatever resources they are now responsible for. The Topology Plug-in is also responsible for providing for redundant data storage to protect against loss of information in the event of a peer failure and to protect against compromised or subversive peers.
Top   ToC   RFC6940 - Page 16

1.2.5. Forwarding and Link Management Layer

The Forwarding and Link Management Layer is responsible for getting a message to the next peer, as determined by the Topology Plug-in. This layer establishes and maintains the network connections as needed by the Topology Plug-in. This layer is also responsible for setting up connections to other peers through NATs and firewalls using ICE, and it can elect to forward traffic using relays for NAT and firewall traversal. Congestion control is implemented at this layer to protect the Internet paths used to form the link in the overlay. Additionally, retransmission is performed to improve the reliability of end-to-end transactions. The relation of this layer to the Message Transport Layer can be likened to the relation of the link-level congestion control and retransmission in modern wireless networks ` to Internet transport protocols. This layer provides a generic interface that allows the Topology Plug-in to control the overlay and resource operations and messages. Because each overlay algorithm is defined and functions differently, we generically refer to the table of other peers that the overlay algorithm maintains and uses to route requests as a Routing Table. The Topology Plug-in actually owns the Routing Table, and forwarding decisions are made by querying the Topology Plug-in for the next hop for a particular Node-ID or Resource-ID. If this node is the destination of the message, the message is delivered to the Message Transport. This layer also utilizes a framing header to encapsulate messages as they are forwarded along each hop. This header aids reliability congestion control, flow control, etc. It has meaning only in the context of that individual link. The Forwarding and Link Management Layer sits on top of the Overlay Link Layer protocols that carry the actual traffic. This specification defines how to use DTLS and TLS protocols to carry RELOAD messages.

1.3. Security

RELOAD's security model is based on each node having one or more public key certificates. In general, these certificates will be assigned by a central server, which also assigns Node-IDs, although self-signed certificates can be used in closed networks. These credentials can be leveraged to provide communications security for RELOAD messages. RELOAD provides communications security at three levels:
Top   ToC   RFC6940 - Page 17
   Connection level:  Connections between nodes are secured with TLS,
      DTLS, or potentially some to-be-defined future protocol.

   Message level:  Each RELOAD message is signed.

   Object Level:  Stored objects are signed by the creating node.

   These three levels of security work together to allow nodes to verify
   the origin and correctness of data they receive from other nodes,
   even in the face of malicious activity by other nodes in the overlay.
   RELOAD also provides access control built on top of these
   communications security features.  Because the peer responsible for
   storing a piece of data can validate the signature on the data being
   stored, it can determine whether or not a given operation is
   permitted.

   RELOAD also provides an optional shared-secret-based admission
   control feature using shared secrets and TLS pre-shared keys (PSK) or
   TLS Secure Remote Password (SRP).  In order to form a TLS connection
   to any node in the overlay, a new node needs to know the shared
   overlay key, thus restricting access to authorized users only.  This
   feature is used together with certificate-based access control, not
   as a replacement for it.  It is typically used when self-signed
   certificates are being used but would generally not be used when the
   certificates were all signed by an enrollment server.

1.4. Structure of This Document

The remainder of this document is structured as follows. o Section 3 provides definitions of terms used in this document. o Section 4 provides an overview of the mechanisms used to establish and maintain the overlay. o Section 5 provides an overview of the mechanism RELOAD provides to support other applications. o Section 6 defines the protocol messages that RELOAD uses to establish and maintain the overlay. o Section 7 defines the protocol messages that are used to store and retrieve data using RELOAD. o Section 8 defines the Certificate Store Usages. o Section 9 defines the TURN Server Usage needed to locate TURN (Traversal Using Relays around NAT) servers for NAT traversal.
Top   ToC   RFC6940 - Page 18
   o  Section 10 defines a specific Topology Plug-in using a Chord-based
      algorithm.

   o  Section 11 defines the mechanisms that new RELOAD nodes use to
      join the overlay for the first time.

   o  Section 12 provides an extended example.

2. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].


(page 18 continued on part 2)

Next Section