RFC 6940
REsource LOcation And Discovery (RELOAD) Base Protocol
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 ProtocolAbstract
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.
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
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
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
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
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
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
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.
+--------+ +--------+ +--------+
| 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.
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.
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.
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.
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.
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
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.
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:
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.
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)
