--- 1/draft-ietf-p2psip-base-23.txt 2013-01-19 22:50:55.695708928 +0100
+++ 2/draft-ietf-p2psip-base-24.txt 2013-01-19 22:50:55.999708762 +0100
@@ -1,35 +1,35 @@
P2PSIP C. Jennings
Internet-Draft Cisco
Intended status: Standards Track B. Lowekamp, Ed.
-Expires: May 9, 2013 Skype
+Expires: July 23, 2013 Skype
E. Rescorla
RTFM, Inc.
S. Baset
H. Schulzrinne
Columbia University
- November 05, 2012
+ January 19, 2013
REsource LOcation And Discovery (RELOAD) Base Protocol
- draft-ietf-p2psip-base-23
+ draft-ietf-p2psip-base-24
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 must be stored for a particular
+ specify the kinds of data that needs 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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
@@ -37,25 +37,25 @@
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
- This Internet-Draft will expire on May 9, 2013.
+ This Internet-Draft will expire on July 23, 2013.
Copyright Notice
- Copyright (c) 2012 IETF Trust and the persons identified as the
+ Copyright (c) 2013 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
@@ -70,225 +70,225 @@
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 . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1. Basic Setting . . . . . . . . . . . . . . . . . . . . . 9
- 1.2. Architecture . . . . . . . . . . . . . . . . . . . . . . 10
+ 1.2. Architecture . . . . . . . . . . . . . . . . . . . . . . 11
1.2.1. Usage Layer . . . . . . . . . . . . . . . . . . . . 13
1.2.2. Message Transport . . . . . . . . . . . . . . . . . 14
1.2.3. Storage . . . . . . . . . . . . . . . . . . . . . . 15
1.2.4. Topology Plugin . . . . . . . . . . . . . . . . . . 16
1.2.5. Forwarding and Link Management Layer . . . . . . . . 16
1.3. Security . . . . . . . . . . . . . . . . . . . . . . . . 17
1.4. Structure of This Document . . . . . . . . . . . . . . . 18
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 18
3. Overlay Management Overview . . . . . . . . . . . . . . . . . 21
- 3.1. Security and Identification . . . . . . . . . . . . . . 21
+ 3.1. Security and Identification . . . . . . . . . . . . . . 22
3.1.1. Shared-Key Security . . . . . . . . . . . . . . . . 23
- 3.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . 23
+ 3.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.1. Client Routing . . . . . . . . . . . . . . . . . . . 24
- 3.2.2. Minimum Functionality Requirements for Clients . . . 24
- 3.3. Routing . . . . . . . . . . . . . . . . . . . . . . . . 25
- 3.4. Connectivity Management . . . . . . . . . . . . . . . . 28
- 3.5. Overlay Algorithm Support . . . . . . . . . . . . . . . 28
- 3.5.1. Support for Pluggable Overlay Algorithms . . . . . . 29
- 3.5.2. Joining, Leaving, and Maintenance Overview . . . . . 29
- 3.6. First-Time Setup . . . . . . . . . . . . . . . . . . . . 30
- 3.6.1. Initial Configuration . . . . . . . . . . . . . . . 31
- 3.6.2. Enrollment . . . . . . . . . . . . . . . . . . . . . 31
- 3.6.3. Diagnostics . . . . . . . . . . . . . . . . . . . . 31
- 4. RFC 2119 Terminology . . . . . . . . . . . . . . . . . . . . 31
- 5. Application Support Overview . . . . . . . . . . . . . . . . 31
- 5.1. Data Storage . . . . . . . . . . . . . . . . . . . . . . 32
- 5.1.1. Storage Permissions . . . . . . . . . . . . . . . . 33
- 5.1.2. Replication . . . . . . . . . . . . . . . . . . . . 34
- 5.2. Usages . . . . . . . . . . . . . . . . . . . . . . . . . 34
- 5.3. Service Discovery . . . . . . . . . . . . . . . . . . . 35
- 5.4. Application Connectivity . . . . . . . . . . . . . . . . 35
- 6. Overlay Management Protocol . . . . . . . . . . . . . . . . . 35
- 6.1. Message Receipt and Forwarding . . . . . . . . . . . . . 36
- 6.1.1. Responsible ID . . . . . . . . . . . . . . . . . . . 36
- 6.1.2. Other ID . . . . . . . . . . . . . . . . . . . . . . 37
- 6.1.3. Opaque ID . . . . . . . . . . . . . . . . . . . . . 39
- 6.2. Symmetric Recursive Routing . . . . . . . . . . . . . . 39
- 6.2.1. Request Origination . . . . . . . . . . . . . . . . 39
- 6.2.2. Response Origination . . . . . . . . . . . . . . . . 40
- 6.3. Message Structure . . . . . . . . . . . . . . . . . . . 40
- 6.3.1. Presentation Language . . . . . . . . . . . . . . . 41
- 6.3.1.1. Common Definitions . . . . . . . . . . . . . . . 42
- 6.3.2. Forwarding Header . . . . . . . . . . . . . . . . . 44
- 6.3.2.1. Processing Configuration Sequence Numbers . . . . 46
- 6.3.2.2. Destination and Via Lists . . . . . . . . . . . . 47
- 6.3.2.3. Forwarding Option . . . . . . . . . . . . . . . . 49
- 6.3.3. Message Contents Format . . . . . . . . . . . . . . 50
- 6.3.3.1. Response Codes and Response Errors . . . . . . . 51
- 6.3.4. Security Block . . . . . . . . . . . . . . . . . . . 53
- 6.4. Overlay Topology . . . . . . . . . . . . . . . . . . . . 57
- 6.4.1. Topology Plugin Requirements . . . . . . . . . . . . 57
- 6.4.2. Methods and types for use by topology plugins . . . 58
- 6.4.2.1. Join . . . . . . . . . . . . . . . . . . . . . . 58
- 6.4.2.2. Leave . . . . . . . . . . . . . . . . . . . . . . 59
- 6.4.2.3. Update . . . . . . . . . . . . . . . . . . . . . 59
- 6.4.2.4. RouteQuery . . . . . . . . . . . . . . . . . . . 60
- 6.4.2.5. Probe . . . . . . . . . . . . . . . . . . . . . . 61
- 6.5. Forwarding and Link Management Layer . . . . . . . . . . 63
- 6.5.1. Attach . . . . . . . . . . . . . . . . . . . . . . . 63
- 6.5.1.1. Request Definition . . . . . . . . . . . . . . . 64
- 6.5.1.2. Response Definition . . . . . . . . . . . . . . . 67
- 6.5.1.3. Using ICE With RELOAD . . . . . . . . . . . . . . 68
- 6.5.1.4. Collecting STUN Servers . . . . . . . . . . . . . 68
- 6.5.1.5. Gathering Candidates . . . . . . . . . . . . . . 69
- 6.5.1.6. Prioritizing Candidates . . . . . . . . . . . . . 69
- 6.5.1.7. Encoding the Attach Message . . . . . . . . . . . 70
- 6.5.1.8. Verifying ICE Support . . . . . . . . . . . . . . 70
- 6.5.1.9. Role Determination . . . . . . . . . . . . . . . 71
- 6.5.1.10. Full ICE . . . . . . . . . . . . . . . . . . . . 71
- 6.5.1.11. No-ICE . . . . . . . . . . . . . . . . . . . . . 71
- 6.5.1.12. Subsequent Offers and Answers . . . . . . . . . . 72
- 6.5.1.13. Sending Media . . . . . . . . . . . . . . . . . . 72
- 6.5.1.14. Receiving Media . . . . . . . . . . . . . . . . . 72
- 6.5.2. AppAttach . . . . . . . . . . . . . . . . . . . . . 72
- 6.5.2.1. Request Definition . . . . . . . . . . . . . . . 72
- 6.5.2.2. Response Definition . . . . . . . . . . . . . . . 73
- 6.5.3. Ping . . . . . . . . . . . . . . . . . . . . . . . . 74
- 6.5.3.1. Request Definition . . . . . . . . . . . . . . . 74
- 6.5.3.2. Response Definition . . . . . . . . . . . . . . . 74
- 6.5.4. ConfigUpdate . . . . . . . . . . . . . . . . . . . . 75
- 6.5.4.1. Request Definition . . . . . . . . . . . . . . . 75
- 6.5.4.2. Response Definition . . . . . . . . . . . . . . . 76
- 6.6. Overlay Link Layer . . . . . . . . . . . . . . . . . . . 76
- 6.6.1. Future Overlay Link Protocols . . . . . . . . . . . 78
- 6.6.1.1. HIP . . . . . . . . . . . . . . . . . . . . . . . 78
- 6.6.1.2. ICE-TCP . . . . . . . . . . . . . . . . . . . . . 79
- 6.6.1.3. Message-oriented Transports . . . . . . . . . . . 79
- 6.6.1.4. Tunneled Transports . . . . . . . . . . . . . . . 79
- 6.6.2. Framing Header . . . . . . . . . . . . . . . . . . . 79
- 6.6.3. Simple Reliability . . . . . . . . . . . . . . . . . 81
- 6.6.3.1. Stop and Wait Sender Algorithm . . . . . . . . . 82
+ 3.2.2. Minimum Functionality Requirements for Clients . . . 25
+ 3.3. Routing . . . . . . . . . . . . . . . . . . . . . . . . 26
+ 3.4. Connectivity Management . . . . . . . . . . . . . . . . 29
+ 3.5. Overlay Algorithm Support . . . . . . . . . . . . . . . 30
+ 3.5.1. Support for Pluggable Overlay Algorithms . . . . . . 30
+ 3.5.2. Joining, Leaving, and Maintenance Overview . . . . . 30
+ 3.6. First-Time Setup . . . . . . . . . . . . . . . . . . . . 31
+ 3.6.1. Initial Configuration . . . . . . . . . . . . . . . 32
+ 3.6.2. Enrollment . . . . . . . . . . . . . . . . . . . . . 32
+ 3.6.3. Diagnostics . . . . . . . . . . . . . . . . . . . . 32
+ 4. Application Support Overview . . . . . . . . . . . . . . . . 32
+ 4.1. Data Storage . . . . . . . . . . . . . . . . . . . . . . 33
+ 4.1.1. Storage Permissions . . . . . . . . . . . . . . . . 34
+ 4.1.2. Replication . . . . . . . . . . . . . . . . . . . . 35
+ 4.2. Usages . . . . . . . . . . . . . . . . . . . . . . . . . 35
+ 4.3. Service Discovery . . . . . . . . . . . . . . . . . . . 36
+ 4.4. Application Connectivity . . . . . . . . . . . . . . . . 36
+ 5. RFC 2119 Terminology . . . . . . . . . . . . . . . . . . . . 36
+ 6. Overlay Management Protocol . . . . . . . . . . . . . . . . . 37
+ 6.1. Message Receipt and Forwarding . . . . . . . . . . . . . 37
+ 6.1.1. Responsible ID . . . . . . . . . . . . . . . . . . . 37
+ 6.1.2. Other ID . . . . . . . . . . . . . . . . . . . . . . 38
+ 6.1.3. Opaque ID . . . . . . . . . . . . . . . . . . . . . 40
+ 6.2. Symmetric Recursive Routing . . . . . . . . . . . . . . 40
+ 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 . . . . . . . . . . . . . . . 43
+ 6.3.2. Forwarding Header . . . . . . . . . . . . . . . . . 46
+ 6.3.2.1. Processing Configuration Sequence Numbers . . . . 48
+ 6.3.2.2. Destination and Via Lists . . . . . . . . . . . . 49
+ 6.3.2.3. Forwarding Option . . . . . . . . . . . . . . . . 51
+ 6.3.3. Message Contents Format . . . . . . . . . . . . . . 52
+ 6.3.3.1. Response Codes and Response Errors . . . . . . . 54
+ 6.3.4. Security Block . . . . . . . . . . . . . . . . . . . 56
+ 6.4. Overlay Topology . . . . . . . . . . . . . . . . . . . . 60
+ 6.4.1. Topology Plugin Requirements . . . . . . . . . . . . 60
+ 6.4.2. Methods and types for use by topology plugins . . . 61
+ 6.4.2.1. Join . . . . . . . . . . . . . . . . . . . . . . 61
+ 6.4.2.2. Leave . . . . . . . . . . . . . . . . . . . . . . 62
+ 6.4.2.3. Update . . . . . . . . . . . . . . . . . . . . . 62
+ 6.4.2.4. RouteQuery . . . . . . . . . . . . . . . . . . . 63
+ 6.4.2.5. Probe . . . . . . . . . . . . . . . . . . . . . . 64
+ 6.5. Forwarding and Link Management Layer . . . . . . . . . . 66
+ 6.5.1. Attach . . . . . . . . . . . . . . . . . . . . . . . 66
+ 6.5.1.1. Request Definition . . . . . . . . . . . . . . . 67
+ 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 . . . . . . . . . . . . . . 73
+ 6.5.1.9. Role Determination . . . . . . . . . . . . . . . 74
+ 6.5.1.10. Full ICE . . . . . . . . . . . . . . . . . . . . 74
+ 6.5.1.11. No-ICE . . . . . . . . . . . . . . . . . . . . . 74
+ 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 . . . . . . . . . . . . . . . 75
+ 6.5.2.2. Response Definition . . . . . . . . . . . . . . . 76
+ 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 . . . . . . . . . . . . . . . . . . . 79
+ 6.6.1. Future Overlay Link Protocols . . . . . . . . . . . 81
+ 6.6.1.1. HIP . . . . . . . . . . . . . . . . . . . . . . . 81
+ 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 . . . . . . . . . . . . . . . . . . . 82
+ 6.6.3. Simple Reliability . . . . . . . . . . . . . . . . . 84
+ 6.6.3.1. Stop and Wait Sender Algorithm . . . . . . . . . 85
- 6.6.4. DTLS/UDP with SR . . . . . . . . . . . . . . . . . . 83
- 6.6.5. TLS/TCP with FH, No-ICE . . . . . . . . . . . . . . 83
- 6.6.6. DTLS/UDP with SR, No-ICE . . . . . . . . . . . . . . 83
- 6.7. Fragmentation and Reassembly . . . . . . . . . . . . . . 84
- 7. Data Storage Protocol . . . . . . . . . . . . . . . . . . . . 85
- 7.1. Data Signature Computation . . . . . . . . . . . . . . . 86
- 7.2. Data Models . . . . . . . . . . . . . . . . . . . . . . 87
- 7.2.1. Single Value . . . . . . . . . . . . . . . . . . . . 88
- 7.2.2. Array . . . . . . . . . . . . . . . . . . . . . . . 88
- 7.2.3. Dictionary . . . . . . . . . . . . . . . . . . . . . 89
- 7.3. Access Control Policies . . . . . . . . . . . . . . . . 89
- 7.3.1. USER-MATCH . . . . . . . . . . . . . . . . . . . . . 90
- 7.3.2. NODE-MATCH . . . . . . . . . . . . . . . . . . . . . 90
- 7.3.3. USER-NODE-MATCH . . . . . . . . . . . . . . . . . . 90
- 7.3.4. NODE-MULTIPLE . . . . . . . . . . . . . . . . . . . 90
- 7.4. Data Storage Methods . . . . . . . . . . . . . . . . . . 91
- 7.4.1. Store . . . . . . . . . . . . . . . . . . . . . . . 91
- 7.4.1.1. Request Definition . . . . . . . . . . . . . . . 91
- 7.4.1.2. Response Definition . . . . . . . . . . . . . . . 95
- 7.4.1.3. Removing Values . . . . . . . . . . . . . . . . . 97
- 7.4.2. Fetch . . . . . . . . . . . . . . . . . . . . . . . 97
- 7.4.2.1. Request Definition . . . . . . . . . . . . . . . 98
- 7.4.2.2. Response Definition . . . . . . . . . . . . . . . 100
- 7.4.3. Stat . . . . . . . . . . . . . . . . . . . . . . . . 101
- 7.4.3.1. Request Definition . . . . . . . . . . . . . . . 101
- 7.4.3.2. Response Definition . . . . . . . . . . . . . . . 101
- 7.4.4. Find . . . . . . . . . . . . . . . . . . . . . . . . 103
- 7.4.4.1. Request Definition . . . . . . . . . . . . . . . 103
- 7.4.4.2. Response Definition . . . . . . . . . . . . . . . 104
- 7.4.5. Defining New Kinds . . . . . . . . . . . . . . . . . 105
- 8. Certificate Store Usage . . . . . . . . . . . . . . . . . . . 105
- 9. TURN Server Usage . . . . . . . . . . . . . . . . . . . . . . 106
- 10. Chord Algorithm . . . . . . . . . . . . . . . . . . . . . . . 108
- 10.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 109
- 10.2. Hash Function . . . . . . . . . . . . . . . . . . . . . 109
- 10.3. Routing . . . . . . . . . . . . . . . . . . . . . . . . 110
- 10.4. Redundancy . . . . . . . . . . . . . . . . . . . . . . . 110
- 10.5. Joining . . . . . . . . . . . . . . . . . . . . . . . . 110
- 10.6. Routing Attaches . . . . . . . . . . . . . . . . . . . . 112
- 10.7. Updates . . . . . . . . . . . . . . . . . . . . . . . . 112
- 10.7.1. Handling Neighbor Failures . . . . . . . . . . . . . 113
- 10.7.2. Handling Finger Table Entry Failure . . . . . . . . 114
- 10.7.3. Receiving Updates . . . . . . . . . . . . . . . . . 114
- 10.7.4. Stabilization . . . . . . . . . . . . . . . . . . . 115
- 10.7.4.1. Updating neighbor table . . . . . . . . . . . . . 115
- 10.7.4.2. Refreshing finger table . . . . . . . . . . . . . 116
- 10.7.4.3. Adjusting finger table size . . . . . . . . . . . 116
- 10.7.4.4. Detecting partitioning . . . . . . . . . . . . . 117
+ 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 . . . . . . . . . . . . . . 86
+ 6.7. Fragmentation and Reassembly . . . . . . . . . . . . . . 87
+ 7. Data Storage Protocol . . . . . . . . . . . . . . . . . . . . 88
+ 7.1. Data Signature Computation . . . . . . . . . . . . . . . 89
+ 7.2. Data Models . . . . . . . . . . . . . . . . . . . . . . 90
+ 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 . . . . . . . . . . . . . . . 99
+ 7.4.1.3. Removing Values . . . . . . . . . . . . . . . . . 101
+ 7.4.2. Fetch . . . . . . . . . . . . . . . . . . . . . . . 101
+ 7.4.2.1. Request Definition . . . . . . . . . . . . . . . 102
+ 7.4.2.2. Response Definition . . . . . . . . . . . . . . . 103
+ 7.4.3. Stat . . . . . . . . . . . . . . . . . . . . . . . . 105
+ 7.4.3.1. Request Definition . . . . . . . . . . . . . . . 105
+ 7.4.3.2. Response Definition . . . . . . . . . . . . . . . 105
+ 7.4.4. Find . . . . . . . . . . . . . . . . . . . . . . . . 107
+ 7.4.4.1. Request Definition . . . . . . . . . . . . . . . 107
+ 7.4.4.2. Response Definition . . . . . . . . . . . . . . . 108
+ 7.4.5. Defining New Kinds . . . . . . . . . . . . . . . . . 109
+ 8. Certificate Store Usage . . . . . . . . . . . . . . . . . . . 109
+ 9. TURN Server Usage . . . . . . . . . . . . . . . . . . . . . . 110
+ 10. Chord Algorithm . . . . . . . . . . . . . . . . . . . . . . . 112
+ 10.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 113
+ 10.2. Hash Function . . . . . . . . . . . . . . . . . . . . . 113
+ 10.3. Routing . . . . . . . . . . . . . . . . . . . . . . . . 114
+ 10.4. Redundancy . . . . . . . . . . . . . . . . . . . . . . . 114
+ 10.5. Joining . . . . . . . . . . . . . . . . . . . . . . . . 114
+ 10.6. Routing Attaches . . . . . . . . . . . . . . . . . . . . 115
+ 10.7. Updates . . . . . . . . . . . . . . . . . . . . . . . . 116
+ 10.7.1. Handling Neighbor Failures . . . . . . . . . . . . . 117
+ 10.7.2. Handling Finger Table Entry Failure . . . . . . . . 118
+ 10.7.3. Receiving Updates . . . . . . . . . . . . . . . . . 118
+ 10.7.4. Stabilization . . . . . . . . . . . . . . . . . . . 119
+ 10.7.4.1. Updating neighbor table . . . . . . . . . . . . . 119
+ 10.7.4.2. Refreshing finger table . . . . . . . . . . . . . 120
+ 10.7.4.3. Adjusting finger table size . . . . . . . . . . . 120
+ 10.7.4.4. Detecting partitioning . . . . . . . . . . . . . 121
- 10.8. Route query . . . . . . . . . . . . . . . . . . . . . . 117
- 10.9. Leaving . . . . . . . . . . . . . . . . . . . . . . . . 118
- 11. Enrollment and Bootstrap . . . . . . . . . . . . . . . . . . 119
- 11.1. Overlay Configuration . . . . . . . . . . . . . . . . . 119
- 11.1.1. Relax NG Grammar . . . . . . . . . . . . . . . . . . 126
- 11.2. Discovery Through Configuration Server . . . . . . . . . 128
- 11.3. Credentials . . . . . . . . . . . . . . . . . . . . . . 129
- 11.3.1. Self-Generated Credentials . . . . . . . . . . . . . 130
- 11.4. Searching for a Bootstrap Node . . . . . . . . . . . . . 131
- 11.5. Contacting a Bootstrap Node . . . . . . . . . . . . . . 131
- 12. Message Flow Example . . . . . . . . . . . . . . . . . . . . 132
- 13. Security Considerations . . . . . . . . . . . . . . . . . . . 138
- 13.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 138
- 13.2. Attacks on P2P Overlays . . . . . . . . . . . . . . . . 139
- 13.3. Certificate-based Security . . . . . . . . . . . . . . . 139
- 13.4. Shared-Secret Security . . . . . . . . . . . . . . . . . 140
- 13.5. Storage Security . . . . . . . . . . . . . . . . . . . . 141
- 13.5.1. Authorization . . . . . . . . . . . . . . . . . . . 141
- 13.5.2. Distributed Quota . . . . . . . . . . . . . . . . . 142
- 13.5.3. Correctness . . . . . . . . . . . . . . . . . . . . 142
- 13.5.4. Residual Attacks . . . . . . . . . . . . . . . . . . 142
- 13.6. Routing Security . . . . . . . . . . . . . . . . . . . . 143
- 13.6.1. Background . . . . . . . . . . . . . . . . . . . . . 143
- 13.6.2. Admissions Control . . . . . . . . . . . . . . . . . 144
- 13.6.3. Peer Identification and Authentication . . . . . . . 144
- 13.6.4. Protecting the Signaling . . . . . . . . . . . . . . 145
- 13.6.5. Routing Loops and Dos Attacks . . . . . . . . . . . 145
- 13.6.6. Residual Attacks . . . . . . . . . . . . . . . . . . 145
- 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 146
- 14.1. Well-Known URI Registration . . . . . . . . . . . . . . 146
- 14.2. Port Registrations . . . . . . . . . . . . . . . . . . . 146
- 14.3. Overlay Algorithm Types . . . . . . . . . . . . . . . . 147
- 14.4. Access Control Policies . . . . . . . . . . . . . . . . 147
- 14.5. Application-ID . . . . . . . . . . . . . . . . . . . . . 148
- 14.6. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . 148
- 14.7. Data Model . . . . . . . . . . . . . . . . . . . . . . . 149
- 14.8. Message Codes . . . . . . . . . . . . . . . . . . . . . 149
- 14.9. Error Codes . . . . . . . . . . . . . . . . . . . . . . 151
- 14.10. Overlay Link Types . . . . . . . . . . . . . . . . . . . 151
- 14.11. Overlay Link Protocols . . . . . . . . . . . . . . . . . 152
- 14.12. Forwarding Options . . . . . . . . . . . . . . . . . . . 152
- 14.13. Probe Information Types . . . . . . . . . . . . . . . . 153
- 14.14. Message Extensions . . . . . . . . . . . . . . . . . . . 153
- 14.15. reload URI Scheme . . . . . . . . . . . . . . . . . . . 153
- 14.15.1. URI Registration . . . . . . . . . . . . . . . . . . 154
- 14.16. Media Type Registration . . . . . . . . . . . . . . . . 155
- 14.17. XML Name Space Registration . . . . . . . . . . . . . . 156
- 14.17.1. Config URL . . . . . . . . . . . . . . . . . . . . . 156
- 14.17.2. Config Chord URL . . . . . . . . . . . . . . . . . . 156
- 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 156
- 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 157
- 16.1. Normative References . . . . . . . . . . . . . . . . . . 157
- 16.2. Informative References . . . . . . . . . . . . . . . . . 159
- Appendix A. Routing Alternatives . . . . . . . . . . . . . . . . 162
- A.1. Iterative vs Recursive . . . . . . . . . . . . . . . . . 162
- A.2. Symmetric vs Forward response . . . . . . . . . . . . . 163
- A.3. Direct Response . . . . . . . . . . . . . . . . . . . . 163
- A.4. Relay Peers . . . . . . . . . . . . . . . . . . . . . . 164
- A.5. Symmetric Route Stability . . . . . . . . . . . . . . . 165
- Appendix B. Why Clients? . . . . . . . . . . . . . . . . . . . . 165
- B.1. Why Not Only Peers? . . . . . . . . . . . . . . . . . . 165
- B.2. Clients as Application-Level Agents . . . . . . . . . . 166
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 166
+ 10.8. Route query . . . . . . . . . . . . . . . . . . . . . . 121
+ 10.9. Leaving . . . . . . . . . . . . . . . . . . . . . . . . 122
+ 11. Enrollment and Bootstrap . . . . . . . . . . . . . . . . . . 123
+ 11.1. Overlay Configuration . . . . . . . . . . . . . . . . . 123
+ 11.1.1. RELAX NG Grammar . . . . . . . . . . . . . . . . . . 130
+ 11.2. Discovery Through Configuration Server . . . . . . . . . 133
+ 11.3. Credentials . . . . . . . . . . . . . . . . . . . . . . 133
+ 11.3.1. Self-Generated Credentials . . . . . . . . . . . . . 135
+ 11.4. Contacting a Bootstrap Node . . . . . . . . . . . . . . 136
+ 12. Message Flow Example . . . . . . . . . . . . . . . . . . . . 136
+ 13. Security Considerations . . . . . . . . . . . . . . . . . . . 143
+ 13.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 143
+ 13.2. Attacks on P2P Overlays . . . . . . . . . . . . . . . . 144
+ 13.3. Certificate-based Security . . . . . . . . . . . . . . . 144
+ 13.4. Shared-Secret Security . . . . . . . . . . . . . . . . . 145
+ 13.5. Storage Security . . . . . . . . . . . . . . . . . . . . 146
+ 13.5.1. Authorization . . . . . . . . . . . . . . . . . . . 146
+ 13.5.2. Distributed Quota . . . . . . . . . . . . . . . . . 147
+ 13.5.3. Correctness . . . . . . . . . . . . . . . . . . . . 147
+ 13.5.4. Residual Attacks . . . . . . . . . . . . . . . . . . 147
+ 13.6. Routing Security . . . . . . . . . . . . . . . . . . . . 148
+ 13.6.1. Background . . . . . . . . . . . . . . . . . . . . . 148
+ 13.6.2. Admissions Control . . . . . . . . . . . . . . . . . 149
+ 13.6.3. Peer Identification and Authentication . . . . . . . 149
+ 13.6.4. Protecting the Signaling . . . . . . . . . . . . . . 150
+ 13.6.5. Routing Loops and Dos Attacks . . . . . . . . . . . 150
+ 13.6.6. Residual Attacks . . . . . . . . . . . . . . . . . . 151
+ 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 151
+ 14.1. Well-Known URI Registration . . . . . . . . . . . . . . 151
+ 14.2. Port Registrations . . . . . . . . . . . . . . . . . . . 152
+ 14.3. Overlay Algorithm Types . . . . . . . . . . . . . . . . 152
+ 14.4. Access Control Policies . . . . . . . . . . . . . . . . 152
+ 14.5. Application-ID . . . . . . . . . . . . . . . . . . . . . 153
+ 14.6. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . 153
+ 14.7. Data Model . . . . . . . . . . . . . . . . . . . . . . . 154
+ 14.8. Message Codes . . . . . . . . . . . . . . . . . . . . . 154
+ 14.9. Error Codes . . . . . . . . . . . . . . . . . . . . . . 156
+ 14.10. Overlay Link Types . . . . . . . . . . . . . . . . . . . 156
+ 14.11. Overlay Link Protocols . . . . . . . . . . . . . . . . . 157
+ 14.12. Forwarding Options . . . . . . . . . . . . . . . . . . . 157
+ 14.13. Probe Information Types . . . . . . . . . . . . . . . . 158
+ 14.14. Message Extensions . . . . . . . . . . . . . . . . . . . 158
+ 14.15. reload URI Scheme . . . . . . . . . . . . . . . . . . . 159
+ 14.15.1. URI Registration . . . . . . . . . . . . . . . . . . 160
+ 14.16. Media Type Registration . . . . . . . . . . . . . . . . 160
+ 14.17. XML Name Space Registration . . . . . . . . . . . . . . 161
+ 14.17.1. Config URL . . . . . . . . . . . . . . . . . . . . . 162
+ 14.17.2. Config Chord URL . . . . . . . . . . . . . . . . . . 162
+
+ 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 162
+ 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 163
+ 16.1. Normative References . . . . . . . . . . . . . . . . . . 163
+ 16.2. Informative References . . . . . . . . . . . . . . . . . 165
+ Appendix A. Routing Alternatives . . . . . . . . . . . . . . . . 168
+ A.1. Iterative vs Recursive . . . . . . . . . . . . . . . . . 168
+ A.2. Symmetric vs Forward response . . . . . . . . . . . . . 169
+ A.3. Direct Response . . . . . . . . . . . . . . . . . . . . 169
+ A.4. Relay Peers . . . . . . . . . . . . . . . . . . . . . . 170
+ A.5. Symmetric Route Stability . . . . . . . . . . . . . . . 171
+ Appendix B. Why Clients? . . . . . . . . . . . . . . . . . . . . 172
+ B.1. Why Not Only Peers? . . . . . . . . . . . . . . . . . . 172
+ B.2. Clients as Application-Level Agents . . . . . . . . . . 172
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 173
1. Introduction
This document defines REsource LOcation And Discovery (RELOAD), a
peer-to-peer (P2P) signaling protocol for use on the Internet. It
provides a generic, self-organizing overlay network service, allowing
nodes to 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:
@@ -303,64 +303,72 @@
Session Initiation Protocol [I-D.ietf-p2psip-sip]. 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 ICE to establish new RELOAD or application
- protocol connections.
+ including using Interactive Connectivity Establishment (ICE)
+ [RFC5245] to establish new RELOAD or application protocol
+ connections.
- High Performance 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 required by intermediate peers.
+ 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) and
unstructured overlay algorithms. The idea here is that RELOAD
- provides a generic structure that should fit most types of overlay
+ 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 DHT algorithm, which is
- mandatory to implement. Specifying a default "must implement"
- overlay algorithm promotes interoperability, while extensibility
- allows selection of overlay algorithms optimized for a particular
- application.
+ how RELOAD is used with the Chord [Chord] based 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, but only use the overlay to locate users and
+ resources as well as store information.
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 usages for NAT traversal and security. The SIP Usage itself
- is described separately in [I-D.ietf-p2psip-sip]. RELOAD is not
- limited to usage by SIP and could serve as a tool for supporting
- other P2P applications with similar needs.
+ critical usage for NAT traversal. The SIP Usage itself is described
+ separately in [I-D.ietf-p2psip-sip]. 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 which, together with the specific
- overlay algorithm in use, determines its position in the graph and
- the set of nodes it connects to. The figure below shows a trivial
- example which isn't drawn from any particular overlay algorithm, but
- was chosen for convenience of representation.
+ 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|
+--------+ +--------+ +--------+
| | |
@@ -379,29 +387,29 @@
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 storage rather
- than for bulk storage of large objects. Records are stored under
- numeric addresses 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.
+ storage network, albeit one designed for small-scale transient
+ storage rather than for bulk storage of large objects. Records are
+ stored under numeric addresses 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 all addresses between 81-90. We
refer to non-client nodes as peers.
Other applications (for instance, SIP) can be defined on top of
RELOAD and use these two basic RELOAD services to provide their own
@@ -429,23 +437,25 @@
| | Topology |
| | Plugin |
| +-------------------+
| ^
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; 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
@@ -454,50 +464,53 @@
Storage: The Storage component is responsible for processing
messages relating to the storage and retrieval of data. It talks
directly to the Topology Plugin to manage data replication and
migration, and it talks to the Message Transport component to send
and receive messages.
Topology Plugin: The Topology Plugin is responsible for implementing
the specific overlay algorithm being used. It uses the Message
Transport component to send and receive overlay management
- messages, to the Storage component to manage data replication, and
- directly to the Forwarding Layer to control hop-by-hop message
- forwarding. This component closely parallels conventional routing
+ 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.
+ overlay algorithms. The topology plugin 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 across NATs using ICE.
Overlay Link Layer: Responsible for actually transporting traffic
- directly between nodes. Each such protocol includes the
- appropriate provisions for per-hop framing or hop-by-hop ACKs
- required by unreliable transports. TLS [RFC5246] and DTLS
- [RFC6347] are the currently defined "link layer" protocols used by
- RELOAD for hop-by-hop communication. New protocols can be
- defined, as described in Section 6.6.1 and Section 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.
+ directly between nodes. TLS [RFC5246] and DTLS [RFC6347] are the
+ currently defined "link layer" protocols used by RELOAD for hop-
+ by-hop communication. Each such protocol includes the appropriate
+ provisions for per-hop framing or hop-by-hop ACKs needed by
+ unreliable underlying transports. New protocols can be defined,
+ as described in Section 6.6.1 and Section 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, this figure
parallels the architecture with each layer's role from an overlay
perspective and implementation layer in the internet:
- | Internet Model |
- Real | Equivalent | Reload
- Internet | in Overlay | Architecture
+ Internet | Internet Model |
+ Model | Equivalent | Reload
+ | in Overlay | Architecture
-------------+-----------------+------------------------------------
| | +-------+ +-------+
| Application | | SIP | | XMPP | ...
| | | Usage | | Usage |
| | +-------+ +-------+
| | ----------------------------------
| |+------------------+ +---------+
| Transport || Message |<--->| Storage |
| || Transport | +---------+
| |+------------------+ ^
@@ -577,24 +590,25 @@
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), although as RELOAD supports
- different overlay algorithms (including non-DHT overlay algorithms)
- that calculate keys in different ways, the actual interface must
- accept Resource Names rather than actual keys.
+ 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.
Stability of the underlying network supporting the overlay (the
Internet) and congestion control between overlay neighbors, which
exchange routing updates and data replicas in addition to forwarding
end-to-end messages, is handled by the Forwarding and Link Management
layer described below.
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.
@@ -621,21 +635,21 @@
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 Plugin when the Resource-IDs for which it is
responsible change, and the Storage component is then responsible for
- migrating resources to other peers, as required.
+ migrating resources to other peers.
1.2.4. Topology Plugin
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 Plugin so that each overlay
can select an appropriate overlay algorithm that relies on the common
RELOAD core protocols and code.
The Topology Plugin is responsible for maintaining the overlay
@@ -656,36 +670,36 @@
migration requests as appropriate, in order to ensure that other
peers have whatever resources they are now responsible for. The
Topology Plugin 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 Plugin. This
- Layer establishes and maintains the network connections as required
- by the Topology Plugin. 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
+ Layer establishes and maintains the network connections as needed by
+ the Topology Plugin. 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 relationship between this layer and the Message
- Transport Layer is similar to the relationship between link-level
- congestion control and retransmission in modern wireless networks is
- to Internet transport protocols.
+ transactions. This layer is to the Message Transport Layer as link-
+ level congestion control and retransmission in modern wireless
+ networks is to Internet transport protocols.
This layer provides a generic interface that allows the topology
plugin to control the overlay and resource operations and messages.
+
Since 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 (neighbors) as a
Routing Table. The Topology Plugin actually owns the Routing Table,
and forwarding decisions are made by querying the Topology Plugin 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
@@ -682,21 +696,21 @@
Since 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 (neighbors) as a
Routing Table. The Topology Plugin actually owns the Routing Table,
and forwarding decisions are made by querying the Topology Plugin 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 forwarding along each hop. This header aids reliability
+ 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
@@ -731,158 +747,191 @@
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 2 provides definitions of terms used in this document.
o Section 3 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
+ o Section 4 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 Usage that is fundamental
- to RELOAD security.
+ o Section 8 defines the Certificate Store Usages.
o Section 9 defines the TURN Server Usage needed to locate TURN
servers for NAT traversal.
o Section 10 defines a specific Topology Plugin using 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. Terminology
Terms used in this document are defined inline when used and are also
- defined below for reference.
-
- DHT: A distributed hash table. A DHT is an abstract hash table
- service realized by storing the contents of the hash table across
- a set of peers.
-
- Overlay Algorithm: An overlay algorithm defines the rules for
- determining which peers in an overlay store a particular piece of
- data and for determining a topology of interconnections amongst
- peers in order to find a piece of data.
+ defined below for reference. The definitions in this section use
+ terminology and concepts that are not explained until later in the
+ specification.
- Overlay Instance: A specific overlay algorithm and the collection of
- peers that are collaborating to provide read and write access to
- it. There can be any number of overlay instances running in an IP
- network at a time, and each operates in isolation of the others.
+ Admitting Peer: A Peer in the Overlay which helps the Joining Node
+ join the Overlay.
- Peer: A host that is participating in the overlay. Peers are
- responsible for holding some portion of the data that has been
- stored in the overlay and also route messages on behalf of other
- hosts as required by the Overlay Algorithm.
+ Bootstrap Node: A network node used by Joining Nodes to help locate
+ the Admitting Peer.
Client: A host that is able to store data in and retrieve data from
the overlay but which is not participating in routing or data
storage for the overlay.
+ Configuration Document: An XML document containing all the Overlay
+ Parameters for one overlay instance.
+
+ Connection Table: The set of nodes to which a node is directly
+ connected, which include nodes that are not yet available for
+ routing.
+
+ Destination List: A list of Node-IDs, Resource-ID and Opaque IDs
+ through which a message is to be routed, in strict order. A
+ single Node-ID, Resource-ID or Opaque ID is a trivial form of
+ destination list. When multiple Node-IDs are specified, a
+ Destination List is a loose source route. The list is reduced
+ hop-by-hop, does not include the source but includes the
+ destination.
+
+ DHT: A distributed hash table. A DHT is an abstract hash table
+ service realized by storing the contents of the hash table across
+ a set of peers.
+
+ ID: A generic term for any kind of identifiers in an Overlay. This
+ document specifies an ID as being a Application-ID, Kind-ID ,
+ Node-ID, Transaction ID, component ID, response ID, Resource-ID,
+ or an Opaque ID.
+
+ Joining Node: A node that is attempting to become a Peer in a
+ particular Overlay.
+
Kind: A Kind defines a particular type of data that can be stored in
the overlay. Applications define new Kinds to store the data they
use. Each Kind is identified with a unique integer called a
Kind-ID.
- Node: We use the term "Node" to refer to a host that may be either a
- Peer or a Client. Because RELOAD uses the same protocol for both
- clients and peers, much of the text applies equally to both.
+ Kind-ID: A unique 32 bit value identifying a Kind. Kind-IDs are
+ either private or allocated by IANA (see Section 14.6).
+
+ Maximum Request Lifetime: The maximum time a request will wait for a
+ response; it defaults to 15 seconds.
+
+ Node: The term "Node" is used to refer to a host that may be either
+ a Peer or a Client. Because RELOAD uses the same protocol for
+ both clients and peers, much of the text applies equally to both.
Therefore we use "Node" when the text applies to both Clients and
Peers and the more specific term (i.e. client or peer) when the
text applies only to Clients or only to Peers.
- Node-ID: A fixed-length value that uniquely identifies a node.
- Node-IDs of all 0s and all 1s are reserved and are invalid Node-
- IDs. A value of zero is not used in the wire protocol but can be
- used to indicate an invalid node in implementations and APIs. The
- Node-ID of all 1s is used on the wire protocol as a wildcard.
+ Node-ID: A value of fixed but configurable length that uniquely
+ identifies a node. Node-IDs of all 0s and all 1s are reserved and
+ are invalid Node-IDs. A value of zero is not used in the wire
+ protocol but can be used to indicate an invalid node in
+ implementations and APIs. The Node-ID of all 1s is used on the
+ wire protocol as a wildcard.
- Joining Peer: A node that is attempting to become a Peer in a
- particular Overlay.
+ Overlay Algorithm: An overlay algorithm defines the rules for
+ determining which peers in an overlay store a particular piece of
+ data and for determining a topology of interconnections amongst
+ peers in order to find a piece of data.
- Admitting Peer: A Peer in the Overlay which helps the Joining Peer
- join the Overlay.
+ Overlay Instance: A specific overlay algorithm and the collection of
+ peers that are collaborating to provide read and write access to
+ it. There can be any number of overlay instances running in an IP
+ network at a time, and each operates in isolation of the others.
- Bootstrap Node: A network node used by Joining Peers to help locate
- the Admitting Peer.
+ Overlay Parameters: A set of values that are shared between all
+ nodes in an overlay. The overlay parameters are distributed in an
+ XML document called the Configuration Document.
- Peer Admission: The act of admitting a peer (the "Joining Peer" )
+ Peer: A host that is participating in the overlay. Peers are
+ responsible for holding some portion of the data that has been
+ stored in the overlay and also route messages on behalf of other
+ hosts as needed by the Overlay Algorithm.
+
+ Peer Admission: The act of admitting a node (the "Joining Node")
into an Overlay. After the admission process is over, the joining
- peer is a fully-functional peer of the overlay. During the
- admission process, the joining peer may need to present
+ node is a fully-functional peer of the overlay. During the
+ admission process, the joining node may need to present
credentials to prove that it has sufficient authority to join the
overlay.
- Resource: An object or group of objects associated with a string
- identifier. See "Resource Name" below.
-
- Resource Name: The potentially human readable name by which a
- resource is identified. In unstructured P2P networks, the
- resource name is sometimes used directly as a Resource-ID. In
- structured P2P networks the resource name is typically mapped into
- a Resource-ID by using the string as the input to hash function.
- Structured and unstructured P2P networks are described in
- [RFC5694]. A SIP resource, for example, is often identified by
- its AOR which is an example of a Resource Name.
+ Resource: An object or group of objects stored in a P2P network.
Resource-ID: A value that identifies some resources and which is
used as a key for storing and retrieving the resource. Often this
is not human friendly/readable. One way to generate a Resource-ID
is by applying a mapping function to some other unique name (e.g.,
user name or service name) for the resource. The Resource-ID is
used by the distributed database algorithm to determine the peer
or peers that are responsible for storing the data for the
overlay. In structured P2P networks, Resource-IDs are generally
fixed length and are formed by hashing the resource name. In
unstructured networks, resource names may be used directly as
Resource-IDs and may be variable lengths.
- Connection Table: The set of nodes to which a node is directly
- connected. This includes nodes with which Attach handshakes have
- been done but which have not sent any Updates.
+ Resource Name: The name by which a resource is identified. In
+ unstructured P2P networks, the resource name is sometimes used
+ directly as a Resource-ID. In structured P2P networks the
+ resource name is typically mapped into a Resource-ID by using the
+ string as the input to hash function. Structured and unstructured
+ P2P networks are described in [RFC5694]. A SIP resource, for
+ example, is often identified by its AOR which is an example of a
+ Resource Name.
- Routing Table: The set of peers which a node can use to route
- overlay messages. In general, these peers will all be on the
- connection table but not vice versa, because some peers will have
- Attached but not sent updates. Peers may send messages directly
- to peers that are in the connection table but may only route
- messages to other peers through peers that are in the routing
- table.
+ Responsible Peer: The peer that is responsible for a specific
+ resource, as defined by the plugin algorithm.
- Destination List: A list of IDs through which a message is to be
- routed, in strict order. A single Node-ID or a Resource-ID is a
- trivial form of destination list. When multiple Node-IDs are
- specified (no more than one Resource-ID is permitted, and it MUST
- be the last entry) a Destination List is a loose source route.
+ Routing Table: The set of directly connected peers which a node can
+ use to forward overlay messages. In normal operation, these peers
+ will all be on the connection table but not vice versa, because
+ some peers may not yet be available for routing. Peers may send
+ messages directly to peers that are in their connection tables but
+ may only forward messages to peers that are not in their
+ connection table through peers that are in the routing table.
- Usage: A usage is an application that wishes to use the overlay for
- some purpose. Each application wishing to use the overlay defines
- a set of data Kinds that it wishes to use. The SIP usage defines
- the location data Kind.
+ Successor Replacement Hold-Down Time: The amount of time to wait
+ before starting replication when a new successor is found; it
+ defaults to 30 seconds.
Transaction ID: A randomly chosen identifier selected by the
originator of a request and used to correlate requests and
responses.
- The term "maximum request lifetime" is the maximum time a request
- will wait for a response; it defaults to 15 seconds. The term
- "successor replacement hold-down time" is the amount of time to wait
- before starting replication when a new successor is found; it
- defaults to 30 seconds.
+ Usage: An usage is the definition of a set of data structures (data
+ Kinds) that an application wants to store in the overlay. An
+ usage may also define a set of network protocols (application IDs)
+ that can be used over direct connections between nodes. E.g. the
+ SIP usage defines a SIP registration data Kind that contains
+ information on how to reach a SIP endpoint and two application IDs
+ corresponding to the SIP and SIPS protocols.
+
+ User: A user is a physical person identified by the certificates
+ assigned to them.
+
+ User Name: A name identifying a user of the overlay, typically used
+ as a Resource Name, or as a label on a Resource that identifies
+ the user owning the resource.
3. Overlay Management Overview
The most basic function of RELOAD is as a generic overlay network.
+
Nodes need to be able to join the overlay, form connections to other
nodes, and route messages through the overlay to nodes to which they
are not directly connected. This section provides an overview of the
mechanisms that perform these functions.
3.1. Security and Identification
The overlay parameters are specified in a configuration document.
Because the parameters include security critical information such as
the certificate signing trust anchors, the configuration document
@@ -879,40 +928,40 @@
Nodes need to be able to join the overlay, form connections to other
nodes, and route messages through the overlay to nodes to which they
are not directly connected. This section provides an overview of the
mechanisms that perform these functions.
3.1. Security and Identification
The overlay parameters are specified in a configuration document.
Because the parameters include security critical information such as
the certificate signing trust anchors, the configuration document
- must be retrieved securely. The initial configuration document is
- either initially fetched over HTTPS or manually provisioned;
+ needs to be retrieved securely. The initial configuration document
+ is either initially fetched over HTTPS or manually provisioned;
subsequent configuration document updates are received either by
periodically refreshing from the configuration server, or, more
commonly, by being flood filled through the overlay, which allows for
fast propagation once an update is pushed. In the latter case,
updates are via digital signatures tracing back to the initial
configuration document.
Every node in the RELOAD overlay is identified by a Node-ID. The
Node-ID is used for three major purposes:
o To address the node itself.
- o To determine its position in the overlay topology when the overlay
- is structured.
+ o To determine its position in the overlay topology (if the overlay
+ is structured; topology plugins do not need to be structured).
o To determine the set of resources for which the node is
responsible.
- Each node has a certificate [RFC5280] containing this Node-ID, which
- is unique within an overlay instance.
+ Each node has a certificate [RFC5280] containing this Node-ID in a
+ subjectAltName extension, which is unique within an overlay instance.
The certificate serves multiple purposes:
o It entitles the user to store data at specific locations in the
Overlay Instance. Each data Kind defines the specific rules for
determining which certificates can access each Resource-ID/Kind-ID
pair. For instance, some Kinds might allow anyone to write at a
given location, whereas others might restrict writes to the owner
of a single certificate.
o It entitles the user to operate a node that has a Node-ID found in
@@ -934,45 +984,47 @@
and Node-ID and puts them in a certificate for the user. All peers
in a particular Overlay Instance have the enrollment server as a
trust anchor and so can verify any other peer's certificate.
In some settings, a group of users want to set up an overlay network
but are not concerned about attack by other users in the network.
For instance, users on a LAN might want to set up a short term ad hoc
network without going to the trouble of setting up an enrollment
server. RELOAD supports the use of self-generated, self-signed
certificates. When self-signed certificates are used, the node also
- generates its own Node-ID and username. The Node-ID is computed as a
- digest of the public key, to prevent Node-ID theft. Note that the
+ generates its own Node-ID and user name. The Node-ID is computed as
+ a digest of the public key, to prevent Node-ID theft. Note that the
relevant cryptographic property for the digest is preimage
- resistance. Collision-resistance is not required since an attacker
- who can create two nodes with the same Node-ID but different public
- key obtains no advantage. This model is still subject to a number of
+ resistance. Collision-resistance is not needed since an attacker who
+ can create two nodes with the same Node-ID but different public key
+ obtains no advantage. This model is still subject to a number of
known attacks (most notably Sybil attacks [Sybil]) and can only be
safely used in closed networks where users are mutually trusting.
Another drawback of this approach is that user's data is then tied to
their keys, so if a key is changed any data stored under their
- Node-ID must then be re-stored. This is not an issue for centrally-
+ Node-ID needs to be re-stored. This is not an issue for centrally-
issued Node-IDs provided that the CA re-issues the same Node-ID when
a new certificate is generated.
- The general principle here is that the security mechanisms (TLS and
- message signatures) are always used, even if the certificates are
- self-signed. This allows for a single set of code paths in the
- systems with the only difference being whether certificate
- verification is required to chain to a single root of trust.
+ The general principle here is that the security mechanisms (TLS at
+ the data link layer and message signatures at the message transport
+ layer) are always used, even if the certificates are self-signed.
+ This allows for a single set of code paths in the systems with the
+ only difference being whether certificate verification is used to
+ chain to a single root of trust.
3.1.1. Shared-Key Security
RELOAD also provides an admission control system based on shared
keys. In this model, the peers all share a single key which is used
- to authenticate the peer-to-peer connections via TLS-PSK/TLS-SRP.
+ to authenticate the peer-to-peer connections via TLS-PSK [RFC4279] or
+ TLS-SRP [RFC5054].
3.2. Clients
RELOAD defines a single protocol that is used both as the peer
protocol and as the client protocol for the overlay. This simplifies
implementation, particularly for devices that may act in either role,
and allows clients to inject messages directly into the overlay.
We use the term "peer" to identify a node in the overlay that routes
messages for nodes other than those to which it is directly
@@ -983,120 +1035,121 @@
RELOAD's client support allows nodes that are not participating in
the overlay as peers to utilize the same implementation and to
benefit from the same security mechanisms as the peers. Clients
possess and use certificates that authorize the user to store data at
certain locations in the overlay. The Node-ID in the certificate is
used to identify the particular client as a member of the overlay and
to authenticate its messages.
In RELOAD, unlike some other designs, clients are not a first-class
- entity. From the perspective of a peer, a client is simply a node
- which has not yet sent any Updates or Joins. It might never do so
- (if it's a client) or it might eventually do so (if it's just a node
- that's taking a long time to join). The routing and storage rules
- for RELOAD provide for correct behavior by peers regardless of
- whether other nodes attached to them are clients or peers. Of
- course, a client implementation must know that it intends to be a
- client, but this localizes complexity only to that node.
+ entity. From the perspective of a peer, a client is a node that has
+ connected to the overlay, but has not yet taken steps to insert
+ itself into the overlay topology. It might never do so (if it's a
+ client) or it might eventually do so (if it's just a node that's
+ taking a long time to join). The routing and storage rules for
+ RELOAD provide for correct behavior by peers regardless of whether
+ other nodes attached to them are clients or peers. Of course, a
+ client implementation needs to know that it intends to be a client,
+ but this localizes complexity only to that node.
For more discussion of the motivation for RELOAD's client support,
see Appendix B.
3.2.1. Client Routing
Clients may insert themselves in the overlay in two ways:
o Establish a connection to the peer responsible for the client's
Node-ID in the overlay. Then requests may be sent from/to the
client using its Node-ID in the same manner as if it were a peer,
because the responsible peer in the overlay will handle the final
- step of routing to the client. This may require a TURN relay in
- cases where NATs or firewalls prevent a client from forming a
- direct connections with its responsible peer. Note that clients
- that choose this option need to process Update messages from the
- peer. Those updates can indicate that the peer no longer is
- responsible for the Client's Node-ID. The client would then need
- to form a connection to the appropriate peer. Failure to do so
- will result in the client no longer receiving messages.
+ step of routing to the client. This may require a TURN [RFC5766]
+ relay in cases where NATs or firewalls prevent a client from
+ forming a direct connection with its responsible peer. Note that
+ clients that choose this option need to process Update messages
+ from the peer. Those updates can indicate that the peer no longer
+ is responsible for the Client's Node-ID. The client would then
+ need to form a connection to the appropriate peer. Failure to do
+ so will result in the client no longer receiving messages.
o Establish a connection with an arbitrary peer in the overlay
(perhaps based on network proximity or an inability to establish a
direct connection with the responsible peer). In this case, the
- client will rely on RELOAD's Destination List feature to ensure
- reachability. The client can initiate requests, and any node in
- the overlay that knows the Destination List to its current
- location can reach it, but the client is not directly reachable
- using only its Node-ID. If the client is to receive incoming
- requests from other members of the overlay, the Destination List
- required to reach it must be learnable via other mechanisms, such
- as being stored in the overlay by a usage. A client connected
- this way using a certificate with only a single Node-ID MAY
- proceed to use the connection without performing an Attach. A
- client wishing to connect using this mechanism with a certificate
- with multiple Node-IDs can use a Ping to probe the Node-ID of the
- node to which it is connected before doing the Attach.
+ client will rely on RELOAD's Destination List (Section 6.3.2.2)
+ feature to ensure reachability. The client can initiate requests,
+ and any node in the overlay that knows the Destination List to its
+ current location can reach it, but the client is not directly
+ reachable using only its Node-ID. If the client is to receive
+ incoming requests from other members of the overlay, the
+ Destination List needed to reach the client needs to be learnable
+ via other mechanisms, such as being stored in the overlay by a
+ usage. A client connected this way using a certificate with only
+ a single Node-ID can proceed to use the connection without
+ performing an Attach. A client wishing to connect using this
+ mechanism with a certificate with multiple Node-IDs can use a Ping
+ (Section 6.5.3) to probe the Node-ID of the node to which it is
+ connected before doing the Attach (Section 6.5.1).
3.2.2. Minimum Functionality Requirements for Clients
A node may act as a client simply because it does not have the
- resources or even an implementation of the topology plugin required
- to act as a peer in the overlay. In order to exchange RELOAD
- messages with a peer, a client MUST meet a minimum level of
- functionality. Such a client MUST:
+ capacity, or even an implementation of the topology plugin defined in
+ Section 6.4.1, needed to act as a peer in the overlay. In order to
+ exchange RELOAD messages with a peer, a client needs to meet a
+ minimum level of functionality. Such a client will:
o Implement RELOAD's connection-management operations that are used
to establish the connection with the peer.
o Implement RELOAD's data retrieval methods (with client
functionality).
o Be able to calculate Resource-IDs used by the overlay.
-
- o Possess security credentials required by the overlay it is
+ o Possess security credentials needed by the overlay it is
implementing.
A client speaks the same protocol as the peers, knows how to
calculate Resource-IDs, and signs its requests in the same manner as
peers. While a client does not necessarily require a full
implementation of the overlay algorithm, calculating the Resource-ID
requires an implementation of the appropriate algorithm for the
overlay.
3.3. Routing
This section will discuss the capabilities of RELOAD's routing layer,
the protocol features used to implement them, and a brief overview of
how they are used. Appendix A discusses some alternative designs and
the tradeoffs that would be necessary to support them.
RELOAD's routing provides the following capabilities:
Resource-based routing: RELOAD supports routing messages based
- soley on the name of the resource. Such messages are delivered to
- a node that is responsible for that resource. Both structured and
- unstructured overlays are supported, so the route may not be
+ solely on the name of the resource. Such messages are delivered
+ to a node that is responsible for that resource. Both structured
+ and unstructured overlays are supported, so the route may not be
deterministic for all Topology Plugins.
+
Node-based routing: RELOAD supports routing messages to a specific
node in the overlay.
+
Clients: RELOAD supports requests from and to clients that do not
participate in overlay routing, located via either of the
mechanisms described above.
- Bridging overlays: Similar to how a Destination List is used to
- reach a client attached via an arbitrary peer, RELOAD can route
- messages between two different overlays by building a destination
- list that includes a peer (or client) with connectivity to both
- networks.
+
NAT Traversal: RELOAD supports establishing and using connections
between nodes separated by one or more NATs, including locating
peers behind NATs for those overlays allowing/requiring it.
+
Low state: RELOAD's routing algorithms do not require significant
state (i.e., state linear or greater in the number of outstanding
messages that have passed through it) to be stored on intermediate
peers.
+
Routability in unstable topologies: Overlay topology changes
constantly in an overlay of moderate size due to the failure of
individual nodes and links in the system. RELOAD's routing allows
peers to re-route messages when a failure is detected, and replies
can be returned to the requesting node as long as the peers that
originally forwarded the successful request do not fail before the
response is returned.
RELOAD's routing utilizes three basic mechanisms:
@@ -1097,39 +1150,45 @@
can be returned to the requesting node as long as the peers that
originally forwarded the successful request do not fail before the
response is returned.
RELOAD's routing utilizes three basic mechanisms:
Destination Lists: While in principle it is possible to just
inject a message into the overlay with a single Node-ID as the
destination, RELOAD provides a source routing capability in the
form of "Destination Lists". A Destination List provides a list
- of the nodes through which a message must flow in order (i.e., it
- is loose source routed). The minimal destination list contains
- just a single value.
+ of the nodes through which a message flows in order (i.e., it is
+ loose source routed). The minimal destination list contains just
+ a single value.
+
Via Lists: In order to allow responses to follow the same path as
requests, each message also contains a "Via List", which is
appended to by each node a message traverses. This via list can
then be inverted and used as a destination list for the response.
+
RouteQuery: The RouteQuery method allows a node to query a peer
for the next hop it will use to route a message. This method is
- useful for diagnostics and for iterative routing.
+ useful for diagnostics and for iterative routing (see
+ Section 6.4.2.4).
The basic routing mechanism used by RELOAD is Symmetric Recursive.
We will first describe symmetric recursive routing and then discuss
its advantages in terms of the requirements discussed above.
Symmetric recursive routing requires that a request message follow a
path through the overlay to the destination: each peer forwards the
message closer to its destination. The return path of the response
- is then the same path followed in reverse. For example, a message
+ is then the same path followed in reverse. If there is a failure on
+ the reverse path caused by topology change since the request was
+ sent, this will be handled by the end-to-end retransmission of the
+ response as described in Section 6.2.1. For example, a message
following a route from A to Z through B and X:
A B X Z
-------------------------------
---------->
Dest=Z
---------->
Via=A
Dest=Z
@@ -1145,21 +1204,21 @@
Dest=A
Note that the preceding Figure does not indicate whether A is a
client or peer: A forwards its request to B and the response is
returned to A in the same manner regardless of A's role in the
overlay.
This figure shows use of full via lists by intermediate peers B and
X. However, if B and/or X are willing to store state, then they may
elect to truncate the lists, save that information internally (keyed
- by the transaction id), and return the response message along the
+ by the transaction ID), and return the response message along the
path from which it was received when the response is received. This
option requires greater state to be stored on intermediate peers but
saves a small amount of bandwidth and reduces the need for modifying
the message en route. Selection of this mode of operation is a
choice for the individual peer; the techniques are interoperable even
on a single message. The figure below shows B using full via lists
but X truncating them to X1 and saving the state internally.
A B X Z
-------------------------------
@@ -1173,74 +1232,82 @@
Via=X1
Dest=Z
<----------
Dest=X,X1
<----------
Dest=B,A
<----------
Dest=A
- As before, when B receives the message, he creates a via list
+ As before, when B receives the message, B creates a via list
consisting of [A]. However, instead of sending [A, B], X creates an
opaque ID X1 which maps internally to [A, B] (perhaps by being an
encryption of [A, B] and forwards to Z with only X1 as the via list.
When the response arrives at X, it maps X1 back to [A, B] and then
inverts it to produce the new destination list [B, A] and routes it
to B.
- RELOAD also supports a basic Iterative routing mode (where the
+ RELOAD also supports a basic Iterative "routing" mode (where the
intermediate peers merely return a response indicating the next hop,
but do not actually forward the message to that next hop themselves).
- Iterative routing is implemented using the RouteQuery method, which
- requests this behavior. Note that iterative routing is selected only
- by the initiating node.
+ Iterative "routing" is implemented using the RouteQuery method, which
+ requests this behavior. Note that iterative "routing" is selected
+ only by the initiating node.
3.4. Connectivity Management
In order to provide efficient routing, a peer needs to maintain a set
of direct connections to other peers in the Overlay Instance. Due to
the presence of NATs, these connections often cannot be formed
directly. Instead, we use the Attach request to establish a
- connection. Attach uses ICE [RFC5245] to establish the connection.
- It is assumed that the reader is familiar with ICE.
+ connection. Attach uses Interactive Connectivity Establishment (ICE)
+ [RFC5245] to establish the connection. It is assumed that the reader
+ is familiar with ICE.
- Say that peer A wishes to form a direct connection to peer B. It
- gathers ICE candidates and packages them up in an Attach request
+ Say that peer A wishes to form a direct connection to peer B, either
+ to join the overlay or to add more connections in its routing table.
+ It gathers ICE candidates and packages them up in an Attach request
which it sends to B through usual overlay routing procedures. B does
its own candidate gathering and sends back a response with its
candidates. A and B then do ICE connectivity checks on the candidate
pairs. The result is a connection between A and B. At this point, A
- and B can add each other to their routing tables and send messages
- directly between themselves without going through other overlay
- peers.
+ and B MAY send messages directly between themselves without going
+ through other overlay peers. In other words, A and B are on each
+ other's connection tables. They MAY then execute an Update process,
+ resulting in additions to each other's routing tables, and become
+ able to route messages through each other to other overlay nodes
There are two cases where Attach is not used. The first is when a
peer is joining the overlay and is not connected to any peers. In
order to support this case, some small number of "bootstrap nodes"
typically need to be publicly accessible so that new peers can
directly connect to them. Section 11 contains more detail on this.
The second case is when a client connects to a peer at an arbitrary
IP address, rather than to its responsible peer, as described in the
second bullet point of Section 3.2.1.
In general, a peer needs to maintain connections to all of the peers
near it in the Overlay Instance and to enough other peers to have
- efficient routing (the details depend on the specific overlay). If a
- peer cannot form a connection to some other peer, this isn't
- necessarily a disaster; overlays can route correctly even without
- fully connected links. However, a peer should try to maintain the
- specified link set and if it detects that it has fewer direct
- connections, should form more as required. This also implies that
- peers need to periodically verify that the connected peers are still
- alive and if not try to reform the connection or form an alternate
- one.
+ efficient routing (the details, e.g. on what "enough" or "near"
+ means, depend on the specific overlay). If a peer cannot form a
+ connection to some other peer, this is not necessarily a disaster;
+ overlays can route correctly even without fully connected links.
+ However, a peer needs to try to maintain the specified routing table
+ defined by the topology plugin algorithm and needs to form new
+ connections if it detects that it has fewer direct connections that
+ the specified by the algorithm. This also implies that peers, in
+ accord with the topology plugin algorithm, need to periodically
+ verify that the connected peers are still alive and if not try to
+ reform the connection or form an alternate one. See Section 10.7.4.3
+ for an example on how a specific overlay algorithm implements these
+ constraints.
3.5. Overlay Algorithm Support
The Topology Plugin allows RELOAD to support a variety of overlay
algorithms. This specification defines a DHT based on Chord, which
is mandatory to implement, but the base RELOAD protocol is designed
to support a variety of overlay algorithms. The information needed
to implement this DHT is fully contained in this specification but it
is easier to understand if you are familiar with Chord [Chord] based
DHTs. A nice tutorial can be found at [wikiChord].
@@ -1251,36 +1318,36 @@
and Leave. However, the contents of those messages, when they are
sent, and their precise semantics are specified by the actual overlay
algorithm, which is specified by configuration for all nodes in the
overlay, and thus known to nodes prior to their attempting to join
the overlay. RELOAD merely provides a framework of commonly-needed
methods that provides uniformity of notation (and ease of debugging)
for a variety of overlay algorithms.
3.5.2. Joining, Leaving, and Maintenance Overview
- When a new peer wishes to join the Overlay Instance, it MUST have a
+ When a new peer wishes to join the Overlay Instance, it will need a
Node-ID that it is allowed to use and a set of credentials which
- match that Node-ID. When an enrollment server is used that Node-ID
- will be in the certificate the node received from the enrollment
- server. The details of the joining procedure are defined by the
- overlay algorithm, but the general steps for joining an Overlay
- Instance are:
+ match that Node-ID. When an enrollment server is used, the Node-ID
+ used is the Node-ID found in the certificate received from the
+ enrollment server. The details of the joining procedure are defined
+ by the overlay algorithm, but the general steps for joining an
+ Overlay Instance are:
o Forming connections to some other peers.
o Acquiring the data values this peer is responsible for storing.
o Informing the other peers which were previously responsible for
that data that this peer has taken over responsibility.
The first thing the peer needs to do is to form a connection to some
"bootstrap node". Because this is the first connection the peer
- makes, these nodes MUST have public IP addresses so that they can be
+ makes, these nodes will need public IP addresses so that they can be
connected to directly. Once a peer has connected to one or more
bootstrap nodes, it can form connections in the usual way by routing
Attach messages through the overlay to other nodes. Once a peer has
connected to the overlay for the first time, it can cache the set of
past adjacencies which have public IP address and attempt to use them
as future bootstrap nodes. Note that this requires some notion of
which addresses are likely to be public as discussed in Section 9.
Once a peer has connected to a bootstrap node, it then needs to take
up its appropriate place in the overlay. This requires two major
@@ -1292,114 +1358,111 @@
o Getting a copy of the data it is now responsible for storing and
assuming responsibility for that data.
The second operation is performed by contacting the Admitting Peer
(AP), the node which is currently responsible for that section of the
overlay.
The details of this operation depend mostly on the overlay algorithm
involved, but a typical case would be:
- 1. JP (Joining Peer) sends a Join request to AP (Admitting Peer)
+ 1. JN (Joining Node) sends a Join request to AP (Admitting Peer)
announcing its intention to join.
2. AP sends a Join response.
- 3. AP does a sequence of Stores to JP to give it the data it will
+ 3. AP does a sequence of Stores to JN to give it the data it will
need.
- 4. AP does Updates to JP and to other peers to tell it about its own
- routing table. At this point, both JP and AP consider JP
+ 4. AP does Updates to JN and to other peers to tell it about its own
+ routing table. At this point, both JN and AP consider JN
responsible for some section of the Overlay Instance.
- 5. JP makes its own connections to the appropriate peers in the
+ 5. JN makes its own connections to the appropriate peers in the
Overlay Instance.
- After this process is completed, JP is a full member of the Overlay
+ After this process is completed, JN is a full member of the Overlay
Instance and can process Store/Fetch requests.
Note that the first node is a special case. When ordinary nodes
cannot form connections to the bootstrap nodes, then they are not
part of the overlay. However, the first node in the overlay can
obviously not connect to other nodes. In order to support this case,
- potential first nodes (which must also serve as bootstrap nodes
- initially) must somehow be instructed (perhaps by configuration
- settings) that they are the entire overlay, rather than not part of
- it.
+ potential first nodes (which can also serve as bootstrap nodes
+ initially) need to somehow be instructed that they are the entire
+ overlay, rather than not part of it. (e.g. by comparing their IP
+ address to the bootstrap IP addresses in the configuration file)
Note that clients do not perform either of these operations.
3.6. First-Time Setup
Previous sections addressed how RELOAD works once a node has
connected. This section provides an overview of how users get
connected to the overlay for the first time. RELOAD is designed so
that users can start with the name of the overlay they wish to join
- and perhaps a username and password, and leverage that into having a
- working peer with minimal user intervention. This helps avoid the
- problems that have been experienced with conventional SIP clients
- where users are required to manually configure a large number of
+ and perhaps an account name and password, and leverage that into
+ having a working peer with minimal user intervention. This helps
+ avoid the problems that have been experienced with conventional SIP
+ clients where users need to manually configure a large number of
settings.
3.6.1. Initial Configuration
In the first phase of the process, the user starts out with the name
of the overlay and uses this to download an initial set of overlay
- configuration parameters. The node does a DNS SRV lookup on the
- overlay name to get the address of a configuration server. It can
- then connect to this server with HTTPS [RFC2818] to download a
+ configuration parameters. The node does a DNS SRV [RFC2782] lookup
+ on the overlay name to get the address of a configuration server. It
+ can then connect to this server with HTTPS [RFC2818] to download a
configuration document which contains the basic overlay configuration
parameters as well as a set of bootstrap nodes which can be used to
- join the overlay. The expected domain name for HTTPS is the name of
- the overlay.
+ join the overlay. The details of the relations between names in the
+ HTTPS certificates, and the overlay names are described in
+ Section 11.2.
If a node already has the valid configuration document that it
received by some out of band method, this step can be skipped. Note
- that that out of band method must provide authentication and
+ that that out of band method needs to provide authentication and
integrity, because the configuration document contains the trust
- anchors for the system.
+ anchors used by the overlay.
3.6.2. Enrollment
If the overlay is using centralized enrollment, then a user needs to
acquire a certificate before joining the overlay. The certificate
attests both to the user's name within the overlay and to the Node-
IDs which they are permitted to operate. In that case, the
configuration document will contain the address of an enrollment
- server which can be used to obtain such a certificate. The
- enrollment server may (and probably will) require some sort of
- username and password before issuing the certificate. The enrollment
- server's ability to restrict attackers' access to certificates in the
- overlay is one of the cornerstones of RELOAD's security.
+ server which can be used to obtain such a certificate, and will also
+ contain the trust anchor, so this document must be retrieved securely
+ (see Section 11.2). The enrollment server may (and probably will)
+ require some sort of account name for the user and password before
+ issuing the certificate. The enrollment server's ability to ensure
+ attackers can not get a large number of certificates for the overlay
+ is one of the cornerstones of RELOAD's security.
3.6.3. Diagnostics
Significant advice around managing a RELOAD overlay and extensions
for diagnostics are described in [I-D.ietf-p2psip-diagnostics].
-4. RFC 2119 Terminology
-
- 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].
-
-5. Application Support Overview
+4. Application Support Overview
RELOAD is not intended to be used alone, but rather as a substrate
for other applications. These applications can use RELOAD for a
variety of purposes:
o To store data in the overlay and retrieve data stored by other
nodes.
o As a discovery mechanism for services such as TURN.
o To form direct connections which can be used to transmit
application-level messages without using the overlay.
This section provides an overview of these services.
-5.1. Data Storage
+4.1. Data Storage
RELOAD provides operations to Store and Fetch data. Each location in
the Overlay Instance is referenced by a Resource-ID. However, each
location may contain data elements corresponding to multiple Kinds
(e.g., certificate, SIP registration). Similarly, there may be
multiple elements of a given Kind, as shown below:
+--------------------------------+
| Resource-ID |
| |
@@ -1436,64 +1499,70 @@
array: Many values can be stored and addressed by a numeric index.
dictionary: The values stored are indexed by a key. Often this key
is one of the values from the certificate of the peer sending the
Store request.
In order to protect stored data from tampering, by other nodes, each
stored value is individually digitally signed by the node which
created it. When a value is retrieved, the digital signature can be
- verified to detect tampering.
+ verified to detect tampering. If the certificate used to sign the
+ stored value expires, it can no longer be retrieved (though may not
+ be immediately garbage collected by the storing node) and the
+ creating node will need to store it again if it desires that stored
+ value to continue to be available.
-5.1.1. Storage Permissions
+4.1.1. Storage Permissions
A major issue in peer-to-peer storage networks is minimizing the
burden of becoming a peer, and in particular minimizing the amount of
- data which any peer is required to store for other nodes. RELOAD
+ data which any peer needs to to store for other nodes. RELOAD
addresses this issue by only allowing any given node to store data at
a small number of locations in the overlay, with those locations
being determined by the node's certificate. When a peer uses a Store
request to place data at a location authorized by its certificate, it
signs that data with the private key that corresponds to its
certificate. Then the peer responsible for storing the data is able
to verify that the peer issuing the request is authorized to make
that request. Each data Kind defines the exact rules for determining
what certificate is appropriate.
The most natural rule is that a certificate authorizes a user to
store data keyed with their user name X. Thus, only a user with a
certificate for "alice@example.org" could write to that location in
- the overlay. However, other usages can define any rules they choose,
- including publicly writable values.
+ the overlay (see Section 11.3). However, other usages can define any
+ rules they choose, including publicly writable values.
The digital signature over the data serves two purposes. First, it
allows the peer responsible for storing the data to verify that this
Store is authorized. Second, it provides integrity for the data.
The signature is saved along with the data value (or values) so that
any reader can verify the integrity of the data. Of course, the
responsible peer can "lose" the value but it cannot undetectably
modify it.
The size requirements of the data being stored in the overlay are
variable. For instance, a SIP AOR and voicemail differ widely in the
storage size. RELOAD leaves it to the Usage and overlay
configuration to limit size imbalance of various Kinds.
-5.1.2. Replication
+4.1.2. Replication
Replication in P2P overlays can be used to provide:
persistence: if the responsible peer crashes and/or if the storing
peer leaves the overlay
+
security: to guard against DoS attacks by the responsible peer or
routing attacks to that responsible peer
+
load balancing: to balance the load of queries for popular
resources.
A variety of schemes are used in P2P overlays to achieve some of
these goals. Common techniques include replicating on neighbors of
the responsible peer, randomly locating replicas around the overlay,
or replicating along the path to the responsible peer.
The core RELOAD specification does not specify a particular
replication strategy. Instead, the first level of replication
@@ -1493,106 +1562,104 @@
A variety of schemes are used in P2P overlays to achieve some of
these goals. Common techniques include replicating on neighbors of
the responsible peer, randomly locating replicas around the overlay,
or replicating along the path to the responsible peer.
The core RELOAD specification does not specify a particular
replication strategy. Instead, the first level of replication
strategies are determined by the overlay algorithm, which can base
the replication strategy on its particular topology. For example,
Chord places replicas on successor peers, which will take over
- responsibility should the responsible peer fail [Chord].
+ responsibility if the responsible peer fail [Chord].
If additional replication is needed, for example if data persistence
is particularly important for a particular usage, then that usage may
specify additional replication, such as implementing random
replications by inserting a different well known constant into the
Resource Name used to store each replicated copy of the resource.
Such replication strategies can be added independent of the
underlying algorithm, and their usage can be determined based on the
needs of the particular usage.
-5.2. Usages
+4.2. Usages
By itself, the distributed storage layer just provides infrastructure
on which applications are built. In order to do anything useful, a
- usage must be defined. Each Usage needs to specify several things:
+ usage needs to be defined. Each Usage needs to specify several
+ things:
- o Registers Kind-ID code points for any Kinds that the Usage
- defines.
- o Defines the data structure for each of the Kinds.
- o Defines access control rules for each of the Kinds.
- o Defines how the Resource Name is hashed to form the Resource-ID
- where each Kind is stored.
- o Describes how values will be merged after a network partition.
- Unless otherwise specified, the default merging rule is to act as
- if all the values that need to be merged were stored and as if the
- order they were stored in corresponds to the stored time values
- associated with (and carried in) their values. Because the stored
- time values are those associated with the peer which did the
- writing, clock skew is generally not an issue. If two nodes are
- on different partitions, write to the same location, and have
- clock skew, this can create merge conflicts. However because
- RELOAD deliberately segregates storage so that data from different
- users and peers is stored in different locations, and a single
- peer will typically only be in a single network partition, this
- case will generally not arise.
+ o Register Kind-ID code points for any Kinds that the Usage defines
+ (Section 14.6).
+ o Defines the data structure for each of the Kinds (the value member
+ in Section 7.2). If the data structure contains character string,
+ conversion rules between characters and the binary storage need to
+ be specified.
+ o Define access control rules for each of the Kinds (Section 7.3).
+ o Define how the Resource Name is used to form the Resource-ID where
+ each Kind is stored.
+ o Describe how values will be merged when a network partition is
+ being healed.
The Kinds defined by a usage may also be applied to other usages.
However, a need for different parameters, such as different size
limits, would imply the need to create a new Kind.
-5.3. Service Discovery
+4.3. Service Discovery
RELOAD does not currently define a generic service discovery
algorithm as part of the base protocol, although a simplistic TURN-
specific discovery mechanism is provided. A variety of service
discovery algorithms can be implemented as extensions to the base
protocol, such as the service discovery algorithm ReDIR
[opendht-sigcomm05] or [I-D.ietf-p2psip-service-discovery].
-5.4. Application Connectivity
+4.4. Application Connectivity
- There is no requirement that a RELOAD usage must use RELOAD's
+ There is no requirement that a RELOAD usage needs to use RELOAD's
primitives for establishing its own communication if it already
possesses its own means of establishing connections. For example,
one could design a RELOAD-based resource discovery protocol which
used HTTP to retrieve the actual data.
For more common situations, however, it is the overlay itself -
rather than an external authority such as DNS - which is used to
establish a connection. RELOAD provides connectivity to applications
using the AppAttach method. For example, if a P2PSIP node wishes to
establish a SIP dialog with another P2PSIP node, it will use
AppAttach to establish a direct connection with the other node. This
new connection is separate from the peer protocol connection. It is
a dedicated UDP or TCP flow used only for the SIP dialog.
+5. RFC 2119 Terminology
+
+ 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].
+
6. Overlay Management Protocol
This section defines the basic protocols used to create, maintain,
and use the RELOAD overlay network. We start by defining the basic
concept of how message destinations are interpreted when routing
messages. We then describe the symmetric recursive routing model,
which is RELOAD's default routing algorithm. We then define the
message structure and then finally define the messages used to join
and maintain the overlay.
6.1. Message Receipt and Forwarding
When a node receives a message, it first examines the overlay,
version, and other header fields to determine whether the message is
- one it can process. If any of these are incorrect (e.g., the message
- is for an overlay in which the peer does not participate) it is an
- error and the message MUST be discarded. The peer SHOULD generate an
- appropriate error but local policy can override this and cause the
- messages to be silently dropped.
+ one it can process. If any of these are incorrect, as defined in
+ Section 6.3.2, it is an error and the message MUST be discarded. The
+ peer SHOULD generate an appropriate error but local policy can
+ override this and cause the messages to be silently dropped.
Once the peer has determined that the message is correctly formatted
(note that this does not include signature checking on intermediate
nodes as the message may be fragmented) it examines the first entry
on the destination list. There are three possible cases here:
o The first entry on the destination list is an ID for which the
peer is responsible. A peer is always responsible for the
wildcard Node-ID. Handling of this case is described in
Section 6.1.1.
@@ -1609,86 +1676,95 @@
6.1.1. Responsible ID
If the first entry on the destination list is an ID for which the
peer is responsible, there are several (mutually exclusive) sub-cases
to consider.
o If the entry is a Resource-ID, then it MUST be the only entry on
the destination list. If there are other entries, the message
MUST be silently dropped. Otherwise, the message is destined for
- this node and it verify the signature and pass it up to the upper
- layers.
+ this node so it MUST verify the signature as described in
+ Section 7.1 and MUST pass it up to the upper layers. "Upper
+ layers" is used here to mean the components above the "Overlay
+ Link Service Boundary" line in the figure in Section 1.2.
o If the entry is a Node-ID which equals this node's Node-ID, then
the message is destined for this node. If this is the only entry
on the destination list, the message is destined for this node and
so the node passes it up to the upper layers. Otherwise the node
removes the entry from the destination list and repeats the
routing process with the next entry on the destination list. If
the message is a response and list compression was used, then the
node first modifies the destination list to reinsert the saved
state, e.g., by unpacking any opaque IDS.
- o If the entry is the wildcard Node-ID, the message is destined for
- this node and it passes it up to the upper layers.
+ o If the entry is the wildcard Node-ID (all "1"s), the message is
+ destined for this node and it passes it up to the upper layers. A
+ message with a wildcard Node-ID as first entry is never forwarded
+ and is consumed locally.
o If the entry is a Node-ID which is not equal to this node, then
the node MUST drop the message silently unless the Node-ID
corresponds to a node which is directly connected to this node
- (i.e., a client). In the later case, it MUST forward the message
+ (i.e., a client). In the latter case, it MUST forward the message
to the destination node as described in the next section.
Note that this implies that in order to address a message to "the
peer that controls region X", a sender sends to Resource-ID X, not
Node-ID X.
6.1.2. Other ID
- If neither of the other three cases applies, then the peer MUST
- forward the message towards the first entry on the destination list.
- This means that it MUST select one of the peers to which it is
- connected and which is likely to be responsible for the first entry
- on the destination list. If the first entry on the destination list
- is in the peer's connection table, then it SHOULD forward the message
- to that peer directly. Otherwise, the peer consults the routing
- table to forward the message.
+ If the first entry in the destination list is neither an opaque ID
+ nor an ID the peer is responsible for, then the peer MUST forward the
+ message towards this entry. This means that it MUST select one of
+ the peers to which it is connected and which is most likely to be
+ responsible (according to the topology plugin) for the first entry on
+ the destination list. For the CHORD-RELOAD topology, the routing to
+ the most likely responsible node is explained in Section 10.3. If
+ the first entry on the destination list is in the peer's connection
+ table, then it MUST forward the message to that peer directly.
+ Otherwise, the peer consults the routing table to forward the
+ message.
Any intermediate peer which forwards a RELOAD request MUST ensure
that if it receives a response to that message the response can be
routed back through the set of nodes through which the request
- passed. There are two major ways of accomplishing this:
+ passed. The peer selects one of these approaches:
o The peer can add an entry to the via list in the forwarding header
- that will enable it to determine the correct node.
+ that will enable it to determine the correct node. This is done
+ by appending to the via list the Node-ID of the node that sent the
+ request to this node.
o The peer can keep per-transaction state which will allow it to
determine the correct node.
As an example of the first strategy, consider an example with nodes
A, B, C, D and E. If node D receives a message from node C with via
list [A, B], then D would forward to the next node E with via list
[A, B, C]. Now, if E wants to respond to the message, it reverses
the via list to produce the destination list, resulting in [D, C, B,
A]. When D forwards the response to C, the destination list will
contain [C, B, A].
As an example of the second strategy, if node D receives a message
- from node C with transaction ID X and via list [A, B], it could store
-
- [X, C] in its state database and forward the message with the via
- list unchanged. When D receives the response, it consults its state
- database for transaction id X, determines that the request came from
- C, and forwards the response to C.
+ from node C with transaction ID X (as assigned by A) and via list [A,
+ B], it could store [X, C] in its state database and forward the
+ message with the via list unchanged. When D receives the response,
+ it consults its state database for transaction ID X, determines that
+ the request came from C, and forwards the response to C.
Intermediate peers which modify the via list are not required to
simply add entries. The only requirement is that the peer MUST be
able to reconstruct the correct destination list on the return route.
RELOAD provides explicit support for this functionality in the form
- of opaque IDs, which can replace any number of via list entries. For
- instance, in the above example, Node D might send E a via list
+ of opaque IDs, which can replace any number of via list entries.
+
+ For instance, in the above example, Node D might send E a via list
containing only the opaque ID I. E would then use the destination
list [D, I] to send its return message. When D processes this
destination list, it would detect that I is a opaque ID, recover the
via list [A, B, C], and reverse that to produce the correct
destination list [C, B, A] before sending it to C. This feature is
called List Compression. Possibilities for a opaque ID include a
compressed version of the original via list or an index into a state
database containing the original via list, but the details are a
local matter.
@@ -1694,108 +1770,111 @@
No matter what mechanism for storing via list state is used, if an
intermediate peer exits the overlay, then on the return trip the
message cannot be forwarded and will be dropped. The ordinary
timeout and retransmission mechanisms provide stability over this
type of failure.
Note that if an intermediate peer retains per-transaction state
instead of modifying the via list, it needs some mechanism for timing
out that state, otherwise its state database will grow without bound.
+
Whatever algorithm is used, unless a FORWARD_CRITICAL forwarding
- option or overlay configuration option explicitly indicates this
- state is not needed, the state MUST be maintained for at least the
- value of the overlay-reliability-timer configuration parameter and
- MAY be kept longer. Future extension, such as [I-D.ietf-p2psip-rpr],
- may define mechanisms for determining when this state does not need
- to be retained.
+ option (Section 6.3.2.3) or overlay configuration option explicitly
+ indicates this state is not needed, the state MUST be maintained for
+ at least the value of the overlay-reliability-timer configuration
+ parameter and MAY be kept longer. Future extension, such as
+ [I-D.ietf-p2psip-rpr], may define mechanisms for determining when
+ this state does not need to be retained.
- None of the above mechanisms are required for responses, since there
- is no need to ensure that subsequent requests follow the same path.
+ There is no requirement to ensure that a request issued after the
+ receipt of a response follows the same path as the response. As a
+ consequence, there is no requirement to use either of the mechanisms
+ described above (via list or state retention) when processing a
+ response message.
- To be precise on the responsibility of the intermediate node, suppose
- that an intermediate node, A, receives a message from node B with via
- list [X, Y, Z]. Node A MUST implement an algorithm that ensures that
- A returns a response to this request to node B with the destination
- list [B, Z, Y, X], provided that the node to which A forwards the
- request follows the same contract. Node A normally learns the
- Node-ID B is using via an Attach, but a node using a certificate with
- a single Node-ID MAY elect to not send an Attach (see Section 3.2.1
- bullet 2). If a node with a certificate with multiple Node-IDs
- attempts to route a message other than a Ping or Attach through a
- node without performing an Attach, the receiving node MUST reject the
- request with an Error_Forbidden error. The node MUST implement
- support for returning responses to a Ping or Attach request made by a
- joining node Attaching to its responsible peer.
+ An intermediate node receiving a request from another node MUST
+ return a response to this request with a destination list equal to
+ the concatenation of the Node-ID of the node that sent the request
+ with the via list in the request. The intermediate node normally
+ learns the Node-ID the other node is using via an Attach, but a node
+ using a certificate with a single Node-ID MAY elect to not send an
+ Attach (see Section 3.2.1 bullet 2). If a node with a certificate
+ with multiple Node-IDs attempts to route a message other than a Ping
+ or Attach through a node without performing an Attach, the receiving
+ node MUST reject the request with an Error_Forbidden error. The node
+ MUST implement support for returning responses to a Ping or Attach
+ request made by a joining node Attaching to its responsible peer.
6.1.3. Opaque ID
If the first entry in the destination list is an opaque ID (e.g., a
compressed via list), the peer MUST replace that entry with the
original via list that it replaced and then re-examine the
destination list to determine which of the three cases in Section 6.1
now applies.
6.2. Symmetric Recursive Routing
This Section defines RELOAD's Symmetric Recursive Routing (SRR)
algorithm, which is the default algorithm used by nodes to route
messages through the overlay. All implementations MUST implement
this routing algorithm. An overlay MAY be configured to use
alternative routing algorithms, and alternative routing algorithms
MAY be selected on a per-message basis. I.e., a node in an overlay
- which supports SRR and routing algorithm RPR [I-D.ietf-p2psip-rpr]
- might use SRR some of the time and RPR some of the time.
+ which supports SRR and some other routing algorithm called XXX might
+ use SRR some of the time and XXX some of the time.
6.2.1. Request Origination
In order to originate a message to a given Node-ID or Resource-ID, a
- node constructs an appropriate destination list. The simplest such
- destination list is a single entry containing the Node-ID or
- Resource-ID. The resulting message uses the normal overlay routing
- mechanisms to forward the message to that destination. The node can
- also construct a more complicated destination list for source
- routing.
+ node MUST construct an appropriate destination list. The simplest
+ such destination list is a single entry containing the Node-ID or
+ Resource-ID. The resulting message MUST use the normal overlay
+ routing mechanisms to forward the message to that destination. The
+ node MAY also construct a more complicated destination list for
+ source routing.
Once the message is constructed, the node sends the message to some
adjacent peer. If the first entry on the destination list is
directly connected, then the message MUST be routed down that
connection. Otherwise, the topology plugin MUST be consulted to
determine the appropriate next hop.
Parallel requests for a resource are a common solution to improve
reliability in the face of churn or of subversive peers. Parallel
searches for usage-specified replicas are managed by the usage layer,
for instance by having the usage store data at multiple Resource-IDs
with the requesting node sending requests to each of those Resource-
IDs. However, a single request MAY also be routed through multiple
adjacent peers, even when known to be sub-optimal, to improve
reliability [vulnerabilities-acsac04]. Such parallel searches MAY be
specified by the topology plugin, in which case it would return
multiple next hops and the request would be routed to all of them.
- Because messages may be lost in transit through the overlay, RELOAD
+ Because messages can be lost in transit through the overlay, RELOAD
incorporates an end-to-end reliability mechanism. When an
originating node transmits a request it MUST set a timer to the
current overlay-reliability-timer. If a response has not been
- received when the timer fires, the request is retransmitted with the
- same transaction identifier. The request MAY be retransmitted up to
- 4 times (for a total of 5 messages). After the timer for the fifth
- transmission fires, the message SHALL be considered to have failed.
- Note that this retransmission procedure is not followed by
- intermediate nodes. They follow the hop-by-hop reliability procedure
- described in Section 6.6.3.
+ received when the timer fires, the request MUST be retransmitted with
+ the same transaction identifier. The request MAY be retransmitted up
+ to 4 times (for a total of 5 messages). After the timer for the
+ fifth transmission fires, the message MUST be considered to have
+ failed. Although the originating node will be doing both end-to-end
+ and hop-by-hop retransmissions, the end-by-end retransmission
+ procedure is not followed by intermediate nodes. They follow the
+ hop-by-hop reliability procedure described in Section 6.6.3.
The above algorithm can result in multiple requests being delivered
to a node. Receiving nodes MUST generate semantically equivalent
responses to retransmissions of the same request (this can be
- determined by transaction id) if the request is received within the
+ determined by transaction ID) if the request is received within the
maximum request lifetime (15 seconds). For some requests (e.g.,
Fetch) this can be accomplished merely by processing the request
again. For other requests, (e.g., Store) it may be necessary to
maintain state for the duration of the request lifetime.
6.2.2. Response Origination
When a peer sends a response to a request using this routing
algorithm, it MUST construct the destination list by reversing the
order of the entries on the via list. This has the result that the
@@ -1822,32 +1901,32 @@
+-------------------------+
| Security Block |
+-------------------------+
The contents of these parts are as follows:
Forwarding Header: Each message has a generic header which is used
to forward the message between peers and to its final destination.
This header is the only information that an intermediate peer
(i.e., one that is not the target of a message) needs to examine.
+ Section 6.3.2 describes the format of this part.
Message Contents: The message being delivered between the peers.
From the perspective of the forwarding layer, the contents are
opaque, however, they are interpreted by the higher layers.
+ Section 6.3.3 describes the format of this part.
Security Block: A security block containing certificates and a
digital signature over the "Message Contents" section. Note that
this signature can be computed without parsing the message
contents. All messages MUST be signed by their originator.
-
- The following sections describe the format of each part of the
- message.
+ Section 6.3.4 describes the format of this part.
6.3.1. Presentation Language
The structures defined in this document are defined using a C-like
syntax based on the presentation language used to define TLS
[RFC5246]. Advantages of this style include:
o It is familiar enough looking that most readers can grasp it
quickly.
o The ability to define nested structures allows a separation
@@ -1853,33 +1932,43 @@
o The ability to define nested structures allows a separation
between high-level and low-level message structures.
o It has a straightforward wire encoding that allows quick
implementation, but the structures can be comprehended without
knowing the encoding.
o The ability to mechanically compile encoders and decoders.
Several idiosyncrasies of this language are worth noting.
o All lengths are denoted in bytes, not objects.
-
o Variable length values are denoted like arrays with angle
brackets.
o "select" is used to indicate variant structures.
For instance, "uint16 array<0..2^8-2>;" represents up to 254 bytes
which corresponds to up to 127 values of two bytes (16 bits) each.
+ A repetitive structure member shares a common notation with a member
+ containing a variable length block of data. The latter always starts
+ with "opaque" whereas the former does not. For instance the
+ following denotes a variable block of data:
+
+ opaque data<0..2^32-1>;
+
+ whereas the following denotes a list of 0, 1 or more instances of the
+ Name element:
+
+ Name names<0..2^32-1>;
+
6.3.1.1. Common Definitions
- The following definitions are used throughout RELOAD and so are
- defined here. They also provide a convenient introduction to how to
- read the presentation language.
+ This section provides an introduction to the presentation language
+ used throughout RELOAD.
An enum represents an enumerated type. The values associated with
each possibility are represented in parentheses and the maximum value
is represented as a nameless value, for purposes of describing the
width of the containing integral type. For instance, Boolean
represents a true or false:
enum { false (0), true(1), (255) } Boolean;
A boolean value is either a 1 or a 0. The max value of 255 indicates
@@ -1909,21 +1998,21 @@
"FOO" would be encoded as: 03 46 4f 4f. Note the < range > syntax
defines a variable length element that does include the length of the
element in the on the wire encoding. The number of bytes to encode
the length on the wire is derived by range; i.e., it is the minimum
number of bytes which can encode the largest range value.
A more complicated example is IpAddressPort, which represents a
network address and can be used to carry either an IPv6 or IPv4
address:
- enum { reservedAddr(0), ipv4_address(1), ipv6_address(2),
+ enum { invalidAddressType(0), ipv4_address(1), ipv6_address(2),
(255) } AddressType;
struct {
uint32 addr;
uint16 port;
} IPv4AddrPort;
struct {
uint128 addr;
uint16 port;
@@ -2000,24 +2090,26 @@
relo_token: The first four bytes identify this message as a RELOAD
message. This field MUST contain the value 0xd2454c4f (the string
'RELO' with the high bit of the first byte set).
overlay: The 32 bit checksum/hash of the overlay being used. This
MUST be formed by taking the lower 32 bits of the SHA-1 [RFC3174]
hash of the overlay name. The purpose of this field is to allow
nodes to participate in multiple overlays and to detect accidental
misconfiguration. This is not a security critical function. The
overlay name MUST consist of a sequence of characters what would
- be allowable as a DNS name.
+ be allowable as a DNS name. Specifically, as it is used in a DNS
+ lookup, it will need to be compliant with the grammar for the
+ domain as specified in section 2.3.1 of [RFC1035] .
configuration_sequence: The sequence number of the configuration
- file.
+ file. See Section 6.3.2.1 for details
version: The version of the RELOAD protocol being used. This is a
fixed point integer between 0.1 and 25.4. This document describes
version 1.0, with a value of 0x0a. [Note: Pre-RFC versions used
version number 0.1]. Nodes MUST reject messages with other
versions.
ttl: An 8 bit field indicating the number of iterations, or hops, a
message can experience before it is discarded. The TTL value MUST
be decremented by one at every hop along the route the message
@@ -2040,21 +2132,21 @@
length: The count in bytes of the size of the message, including the
header.
transaction_id: A unique 64 bit number that identifies this
transaction and also allows receivers to disambiguate transactions
which are otherwise identical. In order to provide a high
probability that transaction IDs are unique, they MUST be randomly
generated. Responses use the same Transaction ID as the request
they correspond to. Transaction IDs are also used for fragment
- reassembly.
+ reassembly. See Section 6.7 for details.
max_response_length: The maximum size in bytes of a response. Used
by requesting nodes to avoid receiving (unexpected) very large
responses. If this value is non-zero, responding peers MUST check
that any response would not exceed it and if so generate an
"Error_Incompatible_with_Overlay" value. This value SHOULD be set
to zero for responses.
via_list_length: The length of the via list in bytes. Note that in
this field and the following two length fields we depart from the
@@ -2062,62 +2154,64 @@
precede the value in order to make it easier for hardware decoding
engines to quickly determine the length of the header.
destination_list_length: The length of the destination list in
bytes.
options_length: The length of the header options in bytes.
via_list: The via_list contains the sequence of destinations through
which the message has passed. The via_list starts out empty and
- grows as the message traverses each peer.
+ grows as the message traverses each peer. In stateless cases, the
+ previous hop that the message is from is appended to the via list
+ as specified in Section 6.1.2.
destination_list: The destination_list contains a sequence of
destinations which the message should pass through. The
destination list is constructed by the message originator. The
first element in the destination list is where the message goes
next. The list shrinks as the message traverses each listed peer.
options: Contains a series of ForwardingOption entries. See
Section 6.3.2.3.
6.3.2.1. Processing Configuration Sequence Numbers
In order to be part of the overlay, a node MUST have a copy of the
overlay configuration document. In order to allow for configuration
- document changes, each version of the configuration document has a
- sequence number which is monotonically increasing mod 65535. Because
- the sequence number may in principle wrap, greater than or less than
- are interpreted by modulo arithmetic as in TCP.
+ document changes, each version of the configuration document MUST
+ contain a sequence number which MUST be monotonically increasing mod
+ 65535. Because the sequence number may in principle wrap, greater
+ than or less than are interpreted by modulo arithmetic as in TCP.
When a destination node receives a request, it MUST check that the
configuration_sequence field is equal to its own configuration
sequence number. If they do not match, it MUST generate an error,
either Error_Config_Too_Old or Error_Config_Too_New. In addition, if
the configuration file in the request is too old, it MUST generate a
ConfigUpdate message to update the requesting node. This allows new
configuration documents to propagate quickly throughout the system.
The one exception to this rule is that if the configuration_sequence
- field is equal to 0xffff, and the message type is ConfigUpdate, then
+ field is equal to 65535, and the message type is ConfigUpdate, then
the message MUST be accepted regardless of the receiving node's
configuration sequence number. Since 65535 is a special value, peers
sending a new configuration when the configuration sequence is
currently 65534 MUST set the configuration sequence number to 0 when
they send out a new configuration.
6.3.2.2. Destination and Via Lists
The destination list and via list are sequences of Destination
values:
- enum { reserved(0), node(1), resource(2), opaque_id_type(3),
- /* 128-255 not allowed */ (255) }
+ enum { invalidDestinationType(0), node(1), resource(2),
+ opaque_id_type(3), /* 128-255 not allowed */ (255) }
DestinationType;
select (destination_type) {
case node:
NodeId node_id;
case resource:
ResourceId resource_id;
case opaque_id_type:
@@ -2127,30 +2221,29 @@
} DestinationData;
struct {
DestinationType type;
uint8 length;
DestinationData destination_data;
} Destination;
struct {
uint16 opaque_id; /* top bit MUST be 1 */
-
} Destination;
- If a destination structure has its first bit set to 1, then it is a
- 16 bit integer. If the first bit is not set, then it is a structure
- starting with DestinationType. If it is a 16 bit integer, it is
- treated as if it were a full structure with a DestinationType of
- opaque_id_type and a opaque_id that was 2 bytes long with the value
- of the 16 bit integer. When the destination structure is not a 16
- bit integer, it is the TLV structure with the following contents:
+ If the destination structure is a 16 bit integer, then the first bit
+ MUST be set to 1 and it MUST be treated as if it were a full
+ structure with a DestinationType of opaque_id_type and a opaque_id
+ that was 2 bytes long with the value of the 16 bit integer. If the
+ destination structure is starting with DestinationType, then the
+ first bit MUST be set to 0 and it is using the TLV structure with the
+ following contents:
type
The type of the DestinationData Payload Data Unit (PDU). This may
be one of "node", "resource", or "opaque_id_type".
length
The length of the destination_data.
destination_data
The destination value itself, which is an encoded DestinationData
@@ -2177,85 +2270,88 @@
The Resource-ID of the resource which is desired. This type MUST
only appear in the final location of a destination list and MUST
NOT appear in a via list. It is meaningless to try to route
through a resource.
One possible encoding of the 16 bit integer version as an opaque
identifier is to encode an index into a connection table. To avoid
misrouting responses in the event a response is delayed and the
connection table entry has changed, the identifier SHOULD be split
between an index and a generation counter for that index. At
- startup, the generation counters should be initialized to random
- values. An implementation could use 12 bits for the connection table
+ startup, the generation counters SHOULD be initialized to random
+ values. An implementation MAY use 12 bits for the connection table
index and 3 bits for the generation counter. (Note that this does
not suggest a 4096 entry connection table for every peer, only the
ability to encode for a larger connection table.) When a connection
table slot is used for a new connection, the generation counter is
incremented (with wrapping). Connection table slots are used on a
rotating basis to maximize the time interval between uses of the same
slot for different connections. When routing a message to an entry
in the destination list encoding a connection table entry, the peer
- confirms that the generation counter matches the current generation
- counter of that index before forwarding the message. If it does not
- match, the message is silently dropped.
+ MUST confirm that the generation counter matches the current
+ generation counter of that index before forwarding the message. If
+ it does not match, the message MUST be silently dropped.
6.3.2.3. Forwarding Option
The Forwarding header can be extended with forwarding header options,
- which are a series of ForwardingOptions structures:
+ which are a series of ForwardingOption structures:
- enum { reservedForwarding(0), (255) }
+ enum { invalidForwardingOptionType(0), (255) }
ForwardingOptionType;
struct {
ForwardingOptionType type;
uint8 flags;
uint16 length;
select (type) {
/* This type may be extended */
};
} ForwardingOption;
Each ForwardingOption consists of the following values:
type
The type of the option. This structure allows for unknown options
types.
- length
- The length of the rest of the structure.
-
flags
Three flags are defined FORWARD_CRITICAL(0x01),
DESTINATION_CRITICAL(0x02), and RESPONSE_COPY(0x04). These flags
MUST NOT be set in a response. If the FORWARD_CRITICAL flag is
set, any peer that would forward the message but does not
understand this options MUST reject the request with an
Error_Unsupported_Forwarding_Option error response. If the
DESTINATION_CRITICAL flag is set, any node that generates a
response to the message but does not understand the forwarding
option MUST reject the request with an
Error_Unsupported_Forwarding_Option error response. If the
RESPONSE_COPY flag is set, any node generating a response MUST
copy the option from the request to the response except that the
RESPONSE_COPY, FORWARD_CRITICAL and DESTINATION_CRITICAL flags
MUST be cleared.
+ length
+ The length of the rest of the structure. Note that a 0 length may
+ be reasonable if the mere presence of the option is meaningful and
+ no value is required.
+
option
The option value.
6.3.3. Message Contents Format
The second major part of a RELOAD message is the contents part, which
is defined by MessageContents:
- enum { reservedMessagesExtension(0), (2^16-1) } MessageExtensionType;
+ enum { invalidMessageExtensionType(0),
+ (2^16-1) } MessageExtensionType;
struct {
MessageExtensionType type;
Boolean critical;
opaque extension_contents<0..2^32-1>;
} MessageExtension;
struct {
uint16 message_code;
opaque message_body<0..2^32-1>;
@@ -2269,28 +2365,32 @@
broken up as follows.
0 Reserved
1 .. 0x7fff Requests and responses. These code points are always
paired, with requests being odd and the corresponding response
being the request code plus 1. Thus, "probe_request" (the
Probe request) has value 1 and "probe_answer" (the Probe
response) has value 2
+ 0x8000 .. 0xfffe Reserved
+
0xffff Error
The message codes are defined in Section 14.8
+
message_body
The message body itself, represented as a variable-length string
of bytes. The bytes themselves are dependent on the code value.
See the sections describing the various RELOAD methods (Join,
Update, Attach, Store, Fetch, etc.) for the definitions of the
payload contents.
+
extensions
Extensions to the message. Currently no extensions are defined,
but new extensions can be defined by the process described in
Section 14.14.
All extensions have the following form:
type
The extension type.
@@ -2288,59 +2388,76 @@
Extensions to the message. Currently no extensions are defined,
but new extensions can be defined by the process described in
Section 14.14.
All extensions have the following form:
type
The extension type.
critical
- Whether this extension must be understood in order to process the
- message. If critical = True and the recipient does not understand
- the message, it MUST generate an Error_Unknown_Extension error.
- If critical = False, the recipient MAY choose to process the
- message even if it does not understand the extension.
+ Whether this extension needs to be understood in order to process
+ the message. If critical = True and the recipient does not
+ understand the message, it MUST generate an
+ Error_Unknown_Extension error. If critical = False, the recipient
+ MAY choose to process the message even if it does not understand
+ the extension.
extension_contents
The contents of the extension (extension-dependent).
+ The subsections in Section 6.4.2, Section 6.5 and Section 7 describe
+ structures that are inserted inside the message_body member,
+ depending on the value of the message_code value. For example a
+ message_code value of join_req means that the structure named JoinReq
+ is inserted inside message_body. This document does not contain a
+ mapping between message_code values and structure names as the
+ conversion between the two is obvious.
+
+ Similarly this document uses the name of the structure without the
+ "Req" or "Ans" suffix to mean the execution of a transaction
+ comprised of the matching request and answer. For example when the
+ text says "perform an Attach", it must be understood as performing a
+ transaction composed of an AttachReq and an AttachAns.
+
6.3.3.1. Response Codes and Response Errors
- A node processing a request returns its status in the message_code
- field. If the request was a success, then the message code is the
- response code that matches the request (i.e., the next code up). The
- response payload is then as defined in the request/response
- descriptions.
+ A node processing a request MUST return its status in the
+ message_code field. If the request was a success, then the message
+ code MUST be set to the response code that matches the request (i.e.,
+ the next code up). The response payload is then as defined in the
+ request/response descriptions.
- If the request has failed, then the message code is set to 0xffff
- (error) and the payload MUST be an error_response message, as shown
- below.
+ If the request has failed, then the message code MUST be set to
+ 0xffff (error) and the payload MUST be an error_response message, as
+ shown below.
When the message code is 0xffff, the payload MUST be an
ErrorResponse.
public struct {
uint16 error_code;
opaque error_info<0..2^16-1>;
} ErrorResponse;
The contents of this structure are as follows:
error_code
A numeric error code indicating the error that occurred.
error_info
An optional arbitrary byte string. Unless otherwise specified,
this will be a UTF-8 text string providing further information
about what went wrong. Developers are encouraged to put enough
- diagnostic information to be useful in error_info.
+ diagnostic information to be useful in error_info. The specific
+ text to be used and any relevant language or encoding thereof is
+ left to the implementation.
The following error code values are defined. The numeric values for
these are defined in Section 14.9.
Error_Forbidden: The requesting node does not have permission to
make this request.
Error_Not_Found: The resource or node cannot be found or does not
exist.
@@ -2388,20 +2505,28 @@
See Section 6.5.1.2.
Error_Unknown_Extension: A destination node received a request with
an unknown extension.
Error_Invalid_Message: Something about this message is invalid but
it doesn't fit the other error codes. When this message is sent,
implementations SHOULD provide some meaningful description in
error_info to aid in debugging.
+ Error_Exp_A: For the purposes of experimentation. Not meant for
+ vendor specific use of any sort and MUST NOT be used for
+ operational deployments.
+
+ Error_Exp_B: For the purposes of experimentation. Not meant for
+ vendor specific use of any sort and MUST NOT be used for
+ operational deployments.
+
6.3.4. Security Block
The third part of a RELOAD message is the security block. The
security block is represented by a SecurityBlock structure:
struct {
CertificateType type;
opaque certificate<0..2^16-1>;
} GenericCertificate;
@@ -2420,50 +2545,46 @@
The certificates bucket SHOULD contain all the certificates necessary
to verify every signature in both the message and the internal
message objects, except for those certificates in a root-cert element
of the current configuration file. This is the only location in the
message which contains certificates, thus allowing for only a single
copy of each certificate to be sent. In systems that have an
alternative certificate distribution mechanism, some certificates MAY
be omitted. However, unless an alternative mechanism for immediately
generating certificates, such as shared secret security
- (Section 13.4) is used, it is strongly RECOMMENDED that implementors
- include all referenced certificates, otherwise there is the
- possibility that messages may not be immediately verifiable because
- certificates must first be retrieved.
+ (Section 13.4) is used, implementors MUST include all referenced
+ certificates.
NOTE TO IMPLEMENTERS: This requirement implies that a peer storing
- data is obligated to retain certificates for the data it holds
- regardless of whether it is responsible for or actually holding the
- certificates for the Certificate Store usage.
+ data is obligated to retain certificates for the data it holds.
Each certificate is represented by a GenericCertificate structure,
which has the following contents:
type
The type of the certificate, as defined in [RFC6091]. Only the
use of X.509 certificates is defined in this document.
certificate
The encoded version of the certificate. For X.509 certificates,
it is the DER form.
The signature is computed over the payload and parts of the
- forwarding header. The payload, in case of a Store, may contain an
- additional signature computed over a StoreReq structure. All
- signatures are formatted using the Signature element. This element
- is also used in other contexts where signatures are needed. The
- input structure to the signature computation varies depending on the
- data element being signed.
+ forwarding header. In case of a Store the payload MUST contain an
+ additional signature computed as described in Section 7.1. All
+ signatures MUST be formatted using the Signature element. This
+ element is also used in other contexts where signatures are needed.
+ The input structure to the signature computation MAY vary depending
+ on the data element being signed.
- enum { reservedSignerIdentity(0),
+ enum { invalidSignerIdentityType(0),
cert_hash(1), cert_hash_node_id(2),
none(3)
(255) } SignerIdentityType;
struct {
select (identity_type) {
case cert_hash;
HashAlgorithm hash_alg; // From TLS
opaque certificate_hash<0..2^8-1>;
@@ -2483,33 +2604,37 @@
uint16 length;
SignerIdentityValue identity[SignerIdentity.length];
} SignerIdentity;
struct {
SignatureAndHashAlgorithm algorithm; // From TLS
SignerIdentity identity;
opaque signature_value<0..2^16-1>;
} Signature;
- The signature construct contains the following values:
+ The Signature construct contains the following values:
algorithm
The signature algorithm in use. The algorithm definitions are
found in the IANA TLS SignatureAlgorithm and HashAlgorithm
Registries. All implementations MUST support RSASSA-PKCS1-v1_5
[RFC3447] signatures with SHA-256 hashes.
identity
- The identity used to form the signature.
+ The identity, as defined in the two paragraphes following this
+ list, used to form the signature.
signature_value
The value of the signature.
+ Note that storage operations allow for special values of algorithm
+ and identity. See Store Request Definition (Section 7.4.1.1) and
+ Fetch Response Definition (Section 7.4.2.2).
There are two permitted identity formats, one for a certificate with
only one Node-ID and one for a certificate with multiple Node-IDs.
In the first case, the cert_hash type MUST be used. The hash_alg
field is used to indicate the algorithm used to produce the hash.
The certificate_hash contains the hash of the certificate object
(i.e., the DER-encoded certificate).
In the second case, the cert_hash_node_id type MUST be used. The
hash_alg is as in cert_hash but the cert_hash_node_id is computed
@@ -2522,31 +2647,33 @@
over:
overlay || transaction_id || MessageContents || SignerIdentity
where overlay and transaction_id come from the forwarding header and
|| indicates concatenation.
The input to signatures over data values is different, and is
described in Section 7.1.
- All RELOAD messages MUST be signed. Upon receipt (and fragment
- reassembly if needed) the destination node MUST verify the signature
- and the authorizing certificate. If the signature fails, the
- implementation SHOULD simply drop the message and MUST not process
- it. This check provides a minimal level of assurance that the
- sending node is a valid part of the overlay as well as cryptographic
- authentication of the sending node. In addition, responses MUST be
- checked as follows by the requesting node:
+ All RELOAD messages MUST be signed. Intermediate nodes do not verify
+ signatures. Upon receipt (and fragment reassembly if needed) the
+ destination node MUST verify the signature and the authorizing
+ certificate. If the signature fails, the implementation SHOULD
+ simply drop the message and MUST NOT process it. This check provides
+ a minimal level of assurance that the sending node is a valid part of
+ the overlay as well as cryptographic authentication of the sending
+ node. In addition, responses MUST be checked as follows by the
+ requesting node:
1. The response to a message sent to a specific Node-ID MUST have
been sent by that Node-ID.
+
2. The response to a message sent to a Resource-ID MUST have been
sent by a Node-ID which is as close to or closer to the target
Resource-ID than any node in the requesting node's neighbor
table.
The second condition serves as a primitive check for responses from
wildly wrong nodes but is not a complete check. Note that in periods
of churn, it is possible for the requesting node to obtain a closer
neighbor while the request is outstanding. This will cause the
response to be rejected and the request to be retransmitted.
@@ -2550,31 +2677,30 @@
of churn, it is possible for the requesting node to obtain a closer
neighbor while the request is outstanding. This will cause the
response to be rejected and the request to be retransmitted.
In addition, some methods (especially Store) have additional
authentication requirements, which are described in the sections
covering those methods.
6.4. Overlay Topology
- As discussed in previous sections, RELOAD does not itself implement
- any overlay topology. Rather, it relies on Topology Plugins, which
- allow a variety of overlay algorithms to be used while maintaining
- the same RELOAD core. This section describes the requirements for
+ As discussed in previous sections RELOAD defines a default overlay
+ topology (CHORD-RELOAD) but allows for other topologies through the
+ use of Topology Plugins. This section describes the requirements for
new topology plugins and the methods that RELOAD provides for overlay
topology maintenance.
6.4.1. Topology Plugin Requirements
- When specifying a new overlay algorithm, at least the following need
- to be described:
+ When specifying a new overlay algorithm, at least the following MUST
+ be described:
o Joining procedures, including the contents of the Join message.
o Stabilization procedures, including the contents of the Update
message, the frequency of topology probes and keepalives, and the
mechanism used to detect when peers have disconnected.
o Exit procedures, including the contents of the Leave message.
o The length of the Resource-IDs. For DHTs, the hash algorithm to
compute the hash of an identifier.
o The procedures that peers use to route messages.
o The replication strategy used to ensure data redundancy.
@@ -2609,33 +2735,33 @@
The minimal JoinReq contains only the Node-ID which the sending peer
wishes to assume. Overlay algorithms MAY specify other data to
appear in this request. Receivers of the JoinReq MUST verify that
the joining_peer_id field matches the Node-ID used to sign the
message and if not MUST reject the message with an Error_Forbidden
error.
Because joins may only be executed between nodes which are directly
adjacent, receiving peers MUST verify that any JoinReq they receive
arrives from a transport channel that is bound to the Node-ID to be
- assumed by the joining peer.) This also prevents replay attacks
+ assumed by the joining node. This also prevents replay attacks
provided that DTLS anti-replay is used.
If the request succeeds, the responding peer responds with a JoinAns
message, as defined below:
struct {
opaque overlay_specific_data<0..2^16-1>;
} JoinAns;
If the request succeeds, the responding peer MUST follow up by
executing the right sequence of Stores and Updates to transfer the
- appropriate section of the overlay space to the joining peer. In
+ appropriate section of the overlay space to the joining node. In
addition, overlay algorithms MAY define data to appear in the
response payload that provides additional info.
Joining nodes MUST verify that the signature on the JoinAns message
matches the expected target (i.e., the adjacency over which they are
joining.) If not, they MUST discard the message.
In general, nodes which cannot form connections SHOULD report an
error to the user. However, implementations MUST provide some
mechanism whereby nodes can determine that they are potentially the
@@ -2748,34 +2874,33 @@
Other data as appropriate for the overlay.
6.4.2.4.2. Response Definition
A response to a successful RouteQueryReq request is a RouteQueryAns
message. This is completely overlay specific.
6.4.2.5. Probe
Probe provides primitive "exploration" services: it allows a node to
- determine which resources another node is responsible for; and it
- allows some discovery services using multicast, anycast, or
- broadcast. A probe can be addressed to a specific Node-ID, or the
- peer controlling a given location (by using a Resource-ID). In
- either case, the target Node-IDs respond with a simple response
- containing some status information.
+ determine which resources another node is responsible for. A probe
+ can be addressed to a specific Node-ID, or the peer controlling a
+ given location (by using a Resource-ID). In either case, the target
+ Node-IDs respond with a simple response containing some status
+ information.
6.4.2.5.1. Request Definition
The ProbeReq message contains a list (potentially empty) of the
pieces of status information that the requester would like the
responder to provide.
- enum { reservedProbeInformation(0), responsible_set(1),
+ enum { invalidProbeInformationType(0), responsible_set(1),
num_resources(2), uptime(3), (255) }
ProbeInformationType;
struct {
ProbeInformationType requested_info<0..2^8-1>;
} ProbeReq;
The currently defined values for ProbeInformation are:
responsible_set
@@ -2880,25 +3007,26 @@
becoming a peer (using Join and Update), to prevent half-open states
where a node has started to form connections but is not really ready
to act as a peer. Thus, clients (unlike peers) can simply Attach
without sending Join or Update.
6.5.1.1. Request Definition
An Attach request message contains the requesting node ICE connection
parameters formatted into a binary structure.
- enum { reservedOverlayLink(0), DTLS-UDP-SR(1),
+ enum { invalidOverlayLinkType(0), DTLS-UDP-SR(1),
DTLS-UDP-SR-NO-ICE(3), TLS-TCP-FH-NO-ICE(4),
(255) } OverlayLinkType;
- enum { reservedCand(0), host(1), srflx(2), prflx(3), relay(4),
+ enum { invalidCandType(0),
+ host(1), srflx(2), prflx(3), relay(4),
(255) } CandType;
struct {
opaque name<0..2^16-1>;
opaque value<0..2^16-1>;
} IceExtension;
struct {
IpAddressPort addr_port;
OverlayLinkType overlay_link;
@@ -2943,46 +3072,46 @@
send_update
Has the same meaning as the send_update field in RouteQueryReq.
Each ICE candidate is represented as an IceCandidate structure, which
is a direct translation of the information from the ICE string
structures, with the exception of the component ID. Since there is
only one component, it is always 1, and thus left out of the
structure. The remaining values are specified as follows:
addr_port
- corresponds to the connection-address and port productions.
+ corresponds to the ICE connection-address and port productions.
overlay_link
- corresponds to the OverlayLinkType production, Overlay Link
+ corresponds to the ICE transport production, Overlay Link
protocols used with No-ICE MUST specify "No-ICE" in their
description. Future overlay link values can be added by defining
new OverlayLinkType values in the IANA registry in Section 14.10.
Future extensions to the encapsulation or framing that provide for
backward compatibility with that specified by a previously defined
OverlayLinkType values MUST use that previous value.
OverlayLinkType protocols are defined in Section 6.6
A single AttachReqAns MUST NOT include both candidates whose
OverlayLinkType protocols use ICE (the default) and candidates
that specify "No-ICE".
foundation
- corresponds to the foundation production.
+ corresponds to the ICE foundation production.
priority
- corresponds to the priority production.
+ corresponds to the ICE priority production.
type
- corresponds to the cand-type production.
+ corresponds to the ICE cand-type production.
rel_addr_port
- corresponds to the rel-addr and rel-port productions. Only
+ corresponds to the ICE rel-addr and rel-port productions. Only
present for types "relay", "srflx" and "prflx".
extensions
ICE extensions. The name and value fields correspond to binary
translations of the equivalent fields in the ICE extensions.
These values should be generated using the procedures described in
Section 6.5.1.3.
6.5.1.2. Response Definition
@@ -3101,39 +3230,39 @@
whether or not these Overlay Link protocols can be used. An overlay
MUST be either all ICE or all No-ICE.
No-ICE will not work in all of the scenarios where ICE would work,
but in some cases, particularly those with no NATs or firewalls, it
will work.
6.5.1.6. Prioritizing Candidates
However, standardization of additional protocols for use with ICE is
- expected, including TCP [RFC6544] and protocols such as SCTP and
- DCCP. UDP encapsulations for SCTP and DCCP would expand the
- available Overlay Link protocols available for RELOAD. When
- additional protocols are available, the following prioritization is
- RECOMMENDED:
+ expected, including TCP [RFC6544] and protocols such as SCTP
+ [RFC4960] and DCCP [RFC4340]. UDP encapsulations for SCTP and DCCP
+ would expand the available Overlay Link protocols available for
+ RELOAD. When additional protocols are available, the following
+ prioritization is RECOMMENDED:
o Highest priority is assigned to protocols that offer well-
understood congestion and flow control without head of line
blocking. For example, SCTP without message ordering, DCCP, or
those protocols encapsulated using UDP.
o Second highest priority is assigned to protocols that offer well-
understood congestion and flow control but have head of line
blocking such as TCP.
o Lowest priority is assigned to protocols encapsulated over UDP
that do not implement well-established congestion control
algorithms. The DTLS/UDP with SR overlay link protocol is an
example of such a protocol.
- Head of line blocking is undesireable in an Overlay Link protocol
+ Head of line blocking is undesirable in an Overlay Link protocol
because the messages carried on a RELOAD link are independent, rather
than stream-oriented. Therefore, if message N on a link is lost,
delaying message N+1 on that same link until N is successfully
retransmitted does nothing other than increase the latency for the
transaction of message N+1 as they are unrelated to each other.
Therefore, while the high quality, performance, and availability of
modern TCP implementations makes them very attractive, their
performance as an Overlay Link protocol is not optimal.
6.5.1.7. Encoding the Attach Message
@@ -3306,22 +3435,21 @@
IceCandidate candidates<0..2^16-1>;
} AppAttachAns;
The meaning of the fields is the same as in the AppAttachReq.
6.5.3. Ping
Ping is used to test connectivity along a path. A ping can be
addressed to a specific Node-ID, to the peer controlling a given
- location (by using a Resource-ID), or to the broadcast Node-ID
- (2^128-1).
+ location (by using a Resource-ID) or to the wildcard Node-ID.
6.5.3.1. Request Definition
struct {
opaque<0..2^16-1> padding;
} PingReq;
The Ping request is empty of meaningful contents. However, it may
contain up to 65535 bytes of padding to facilitate the discovery of
overlay maximum packet sizes.
@@ -3350,21 +3478,21 @@
The ConfigUpdate method is used to push updated configuration data
across the overlay. Whenever a node detects that another node has
old configuration data, it MUST generate a ConfigUpdate request. The
ConfigUpdate request allows updating of two kinds of data: the
configuration data (Section 6.3.2.1) and the Kind information
(Section 7.4.1.1).
6.5.4.1. Request Definition
- enum { reservedConfigUpdate(0), config(1), kind(2), (255) }
+ enum { invalidConfigUpdateType(0), config(1), kind(2), (255) }
ConfigUpdateType;
typedef uint32 KindId;
typedef opaque KindDescription<0..2^16-1>;
struct {
ConfigUpdateType type;
uint32 length;
select (type) {
@@ -3416,43 +3544,45 @@
(i.e., it is signed by a different signer), then it should be
rejected with "Error_Forbidden". This should not happen in correctly
functioning overlays.
If the update is acceptable, then the node MUST reconfigure itself to
match the new information. This may include adding permissions for
new Kinds, deleting old Kinds, or even, in extreme circumstances,
exiting and reentering the overlay, if, for instance, the DHT
algorithm has changed.
- If an implementation receives repeated ConfigUpdates which it cannot
- verify with sequence numbers substantially in advance of its own
- configuration document, it SHOULD contact the configuration server to
- get the latest configuration file in order to avoid permanent
- breakage. The details of this are left up to the implementation.
+ If an implementation misses enough ConfigUpdates which include key
+ changes, it is possible that it will no longer be able to verify new
+ valid ConfigUpdates. In that case, the only available recovery
+ mechanism is to attempt to retrieve a new configuration document,
+ typically by the mechanisms it would use for initial bootstrapping.
+ It is up to implementors whether or how to decide to employ this sort
+ of recovery mechanism.
The response for ConfigUpdate is empty.
6.6. Overlay Link Layer
RELOAD can use multiple Overlay Link protocols to send its messages.
Because ICE is used to establish connections (see Section 6.5.1.3),
RELOAD nodes are able to detect which Overlay Link protocols are
offered by other nodes and establish connections between them. Any
link protocol needs to be able to establish a secure, authenticated
connection and to provide data origin authentication and message
integrity for individual data elements. RELOAD currently supports
three Overlay Link protocols:
o DTLS [RFC6347] over UDP with Simple Reliability (SR)
- (OverlayLinkType=DTLS-UDP-SR
+ (OverlayLinkType=DTLS-UDP-SR)
o TLS [RFC5246] over TCP with Framing Header, No-ICE
- (OverlayLinkType=TLS-TCP-FH-NO-ICE
+ (OverlayLinkType=TLS-TCP-FH-NO-ICE)
o DTLS [RFC6347] over UDP with SR, No-ICE (OverlayLinkType=DTLS-UDP-
SR-NO-ICE)
Note that although UDP does not properly have "connections", both TLS
and DTLS have a handshake which establishes a similar, stateful
association, and we simply refer to these as "connections" for the
purposes of this document.
If a peer receives a message that is larger than value of max-
message-size defined in the overlay configuration, the peer SHOULD
@@ -3460,27 +3590,28 @@
session from which the message was received. Note that this error
can be sent and the session closed before receiving the complete
message. If the forwarding header is larger than the max-message-
size, the receiver SHOULD close the TLS or DTLS session without
sending an error.
The Framing Header (FH) is used to frame messages and provide timing
when used on a reliable stream-based transport protocol. Simple
Reliability (SR) makes use of the FH to provide congestion control
and semi-reliability when using unreliable message-oriented transport
- protocols. We will first define each of these algorithms, then
- define overlay link protocols that use them.
+ protocols. We will first define each of these algorithms in
+ Section 6.6.2 and Section 6.6.3, then define overlay link protocols
+ that use them in Section 6.6.4, Section 6.6.5 and Section 6.6.6.
Note: We expect future Overlay Link protocols to define replacements
for all components of these protocols, including the framing header.
- These protocols have been chosen for simplicity of implementation and
- reasonable performance.
+ These three protocols have been chosen for simplicity of
+ implementation and reasonable performance.
Note to implementers: There are inherent tradeoffs in utilizing
short timeouts to determine when a link has failed. To balance the
tradeoffs, an implementation SHOULD quickly act to remove entries
from the routing table when there is reason to suspect the link has
failed. For example, in a Chord derived overlay algorithm, a closer
finger table entry could be substituted for an entry in the finger
table that has experienced a timeout. That entry can be restored if
it proves to resume functioning, or replaced at some point in the
future if necessary. End-to-end retransmissions will handle any lost
@@ -3702,23 +3833,23 @@
Retransmissions continue until a response is received, or until a
total of 5 requests have been sent or there has been a hard ICMP
error [RFC1122] or a TLS alert. The sender knows a response was
received when it receives an ACK with a sequence number that
indicates it is a response to one of the transmissions of this
messages. For example, assuming an RTO of 500 ms, requests would be
sent at times 0 ms, 500 ms, 1500 ms, 3500 ms, and 7500 ms. If all
retransmissions for a message fail, then the sending node SHOULD
close the connection routing the message.
- To determine when a link may be failing without waiting for the final
- timeout, observe when no ACKs have been received for an entire RTO
- interval, and then wait for three retransmissions to occur beyond
+ To determine when a link might be failing without waiting for the
+ final timeout, observe when no ACKs have been received for an entire
+ RTO interval, and then wait for three retransmissions to occur beyond
that point. If no ACKs have been received by the time the third
retransmission occurs, it is RECOMMENDED that the link be removed
from the routing table. The link MAY be restored to the routing
table if ACKs resume before the connection is closed, as described
above.
A sender MUST wait 10ms between receipt of an ACK and transmission of
the next message.
6.6.4. DTLS/UDP with SR
@@ -3783,22 +3914,22 @@
addresses the reliability issues of relying on IP-layer
fragmentation. However, Ping can be used to allow e2e PMTU discovery
to be implemented if desired.
Upon receipt of a fragmented message by the intended peer, the peer
holds the fragments in a holding buffer until the entire message has
been received. The message is then reassembled into a single message
and processed. In order to mitigate denial of service attacks,
receivers SHOULD time out incomplete fragments after maximum request
lifetime (15 seconds). Note this time was derived from looking at
- the end to end retransmission time and saving fragments long enough
- for the full end to end retransmissions to take place. Ideally the
+ the end-to-end retransmission time and saving fragments long enough
+ for the full end-to-end retransmissions to take place. Ideally the
receiver would have enough buffer space to deal with as many
fragments as can arrive in the maximum request lifetime. However, if
the receiver runs out of buffer space to reassemble the messages it
MUST drop the message.
The fragment field of the forwarding header is used to encode
fragmentation information. The offset is the number of bytes between
the end of the forwarding header and the start of the data. The
first fragment therefore has an offset of 0. The last fragment
indicator MUST be appropriately set. If the message is not
@@ -3852,23 +3983,23 @@
generate a Error_Data_Too_Old error. This prevents rollback
attacks. The node SHOULD make a best-effort attempt to use a
correct clock to determine this number, however, the protocol does
not require synchronized clocks: the receiving peer uses the
storage time in the previous store, not its own clock. Clock
values are used so that when clocks are generally synchronized,
data may be stored in a single transaction, rather than querying
for the value of a counter before the actual store.
If a node attempting to store new data in response to a user
request (rather than as an overlay maintenance operation such as
- occurs during unpartitioning) is rejected with an
- Error_Data_Too_Old error, the node MAY elect to perform its store
- using a storage_time that increments the value used with the
+ occurs when healing the overlay from a partition) is rejected with
+ an Error_Data_Too_Old error, the node MAY elect to perform its
+ store using a storage_time that increments the value used with the
previous store. This situation may occur when the clocks of nodes
storing to this location are not properly synchronized.
lifetime
The validity period for the data, in seconds, starting from the
time the peer receives the StoreReq.
value
The data value itself, as described in Section 7.2.
@@ -3911,27 +4042,32 @@
StoredDataValue
The contents of the stored data value, as described in the
previous sections.
SignerIdentity
The signer identity as defined in Section 6.3.4.
Once the signature has been computed, the signature is represented
using a signature element, as described in Section 6.3.4.
- Note that there is no necessarily relationship between the validity
+ Note that there is no necessary relationship between the validity
window of a certificate and the expiry of the data it is
authenticating. When signatures are verified, the current time MUST
- be compared to the certificate validity period. However, it is
- permitted to have a value signed which expires after a certificate's
- validity period (though this will likely cause verification failure
- at some future time.)
+ be compared to the certificate validity period. Stored data MAY be
+ set to expire after the signing certificate's validity period. Such
+ signatures are not considered valid after the signing certificate
+ expires. Implementations may garbage collect such data at their
+ convenience, either purging it automatically (perhaps by setting the
+ upper bound on data storage to the lifetime of the signing
+ certificate) or by simply leaving it in-place until it expires
+ naturally and relying on users of that data to notice the expired
+ signing certificate.
7.2. Data Models
The protocol currently defines the following data models:
o single value
o array
o dictionary
These are represented with the StoredDataValue structure. The actual
@@ -4193,21 +4328,21 @@
the generation counter against the current value. Replica Stores
MUST NOT use a generation counter of 0.
o The storage time values are greater than that of any value which
would be replaced by this Store.
o The size and number of the stored values is consistent with the
limits specified in the overlay configuration.
o If the data is signed with identity_type set to "none" and/or
SignatureAndHashAlgorithm values set to {0, 0} ("anonymous" and
"none"), the StoreReq MUST be rejected with an Error_forbidden
error. Only synthesized data returned by the storage can use
- these values
+ these values (see Section 7.4.2.2)
If all these checks succeed, the peer MUST attempt to store the data
values. For non-replica stores, if the store succeeds and the data
is changed, then the peer MUST increase the generation counter by at
least one. If there are multiple stored values in a single
StoreKindData, it is permissible for the peer to increase the
generation counter by only 1 for the entire Kind-ID, or by 1 or more
than one for each value. Accordingly, all stored data values MUST
have a generation counter of 1 or greater. 0 is used in the Store
request to indicate that the generation counter should be ignored for
@@ -4225,20 +4360,33 @@
the difference between the current local time and T.
Unless otherwise specified by the usage, if a peer attempts to store
data previously stored by another node (e.g., for replicas or
topology shifts) and that store fails with either an
Error_Generation_Counter_Too_Low or an Error_Data_Too_Old error, the
peer MUST fetch the newer data from the peer generating the error and
use that to replace its own copy. This rule allows resynchronization
after partitions heal.
+ When a network partition is being healed and unless otherwise
+ specified, the default merging rule is to act as if all the values
+ that need to be merged were stored and as if the order they were
+ stored in corresponds to the stored time values associated with (and
+ carried in) their values. Because the stored time values are those
+ associated with the peer which did the writing, clock skew is
+ generally not an issue. If two nodes are on different partitions,
+ write to the same location, and have clock skew, this can create
+ merge conflicts. However because RELOAD deliberately segregates
+ storage so that data from different users and peers is stored in
+ different locations, and a single peer will typically only be in a
+ single network partition, this case will generally not arise.
+
The properties of stores for each data model are as follows:
Single-value:
A store of a new single-value element creates the element if it
does not exist and overwrites any existing value with the new
value.
Array:
A store of an array entry replaces (or inserts) the given value at
the location specified by the index. Because arrays are sparse, a
@@ -4470,25 +4618,20 @@
o If the data model is dictionary then the specifier contains a list
of the dictionary keys being requested. If no keys are specified,
than this is a wildcard fetch and all key-value pairs are
returned.
The generation counter is used to indicate the requester's expected
state of the storing peer. If the generation counter in the request
matches the stored counter, then the storing peer returns a response
with no StoredData values.
- Note that because the certificate for a user is typically stored at
- the same location as any data stored for that user, a requesting node
- that does not already have the user's certificate should request the
- certificate in the Fetch as an optimization.
-
7.4.2.2. Response Definition
The response to a successful Fetch request is a FetchAns message
containing the data requested by the requester.
struct {
KindId kind;
uint64 generation;
StoredData values<0..2^32-1>;
} FetchKindResponse;
@@ -4646,21 +4789,21 @@
The hash algorithm used to perform the digest of the value.
hash_value
A digest using hash_algorithm on the value field of the DataValue
including its 4 leading length bytes.
7.4.4. Find
The Find request can be used to explore the Overlay Instance. A Find
request for a Resource-ID R and a Kind-ID T retrieves the Resource-ID
- (if any) of the resource of kind T known to the target peer which is
+ (if any) of the resource of Kind T known to the target peer which is
closest to R. This method can be used to walk the Overlay Instance by
iteratively fetching R_n+1=nearest(1 + R_n).
7.4.4.1. Request Definition
The FindReq message contains a Resource-ID and a series of Kind-IDs
identifying the resource the peer is interested in.
struct {
ResourceId resource;
@@ -4673,45 +4816,45 @@
resource
The desired Resource-ID
kinds
The desired Kind-IDs. Each value MUST only appear once, and if
not the request MUST be rejected with an error.
7.4.4.2. Response Definition
A response to a successful Find request is a FindAns message
- containing the closest Resource-ID on the peer for each kind
+ containing the closest Resource-ID on the peer for each Kind
specified in the request.
struct {
KindId kind;
ResourceId closest;
} FindKindData;
struct {
FindKindData results<0..2^16-1>;
} FindAns;
If the processing peer is not responsible for the specified
Resource-ID, it SHOULD return an Error_Not_Found error code.
For each Kind-ID in the request the response MUST contain a
FindKindData indicating the closest Resource-ID for that Kind-ID,
- unless the kind is not allowed to be used with Find in which case a
+ unless the Kind is not allowed to be used with Find in which case a
FindKindData for that Kind-ID MUST NOT be included in the response.
If a Kind-ID is not known, then the corresponding Resource-ID MUST be
0. Note that different Kind-IDs may have different closest Resource-
IDs.
The response is simply a series of FindKindData elements, one per
- kind, concatenated end-to-end. The contents of each element are:
+ Kind, concatenated end-to-end. The contents of each element are:
kind
The Kind-ID.
closest
The closest Resource-ID to the specified Resource-ID. This is 0
if no Resource-ID is known.
Note that the response does not contain the contents of the data
stored at these Resource-IDs. If the requester wants this, it must
@@ -4739,41 +4882,38 @@
configuration documents.
While each Kind needs to define what data model is used for its data,
that does not mean that it must define new data models. Where
practical, Kinds should use the existing data models. The intention
is that the basic data model set be sufficient for most applications/
usages.
8. Certificate Store Usage
- The Certificate Store usage allows a peer to store its certificate in
- the overlay, thus avoiding the need to send a certificate in each
- message.
+ The Certificate Store usage allows a node to store its certificate in
+ the overlay.
- A user/peer MUST store its certificate at Resource-IDs derived from
+ A user/node MUST store its certificate at Resource-IDs derived from
two Resource Names:
o The user name in the certificate.
-
o The Node-ID in the certificate.
- Note that in the second case the certificate is not stored at the
- peer's Node-ID but rather at a hash of the peer's Node-ID. The
+ Note that in the second case the certificate for a peer is not stored
+ at the its Node-ID but rather at a hash of its Node-ID. The
intention here (as is common throughout RELOAD) is to avoid making a
peer responsible for its own data.
- A peer MUST ensure that the user's certificates are stored in the
- Overlay Instance. New certificates are stored at the end of the
- list. This structure allows users to store an old and a new
- certificate that both have the same Node-ID, which allows for
- migration of certificates when they are renewed.
+ New certificates are stored at the end of the list. This structure
+ allows users to store an old and a new certificate that both have the
+ same Node-ID, which allows for migration of certificates when they
+ are renewed.
This usage defines the following Kinds:
Name: CERTIFICATE_BY_NODE
Data Model: The data model for CERTIFICATE_BY_NODE data is array.
Access Control: NODE-MATCH.
Name: CERTIFICATE_BY_USER
@@ -4844,23 +4983,22 @@
Peers MAY find other servers by selecting a random Resource-ID and
then doing a Find request for the appropriate Kind-ID with that
Resource-ID. The Find request gets routed to a random peer based on
the Resource-ID. If that peer knows of any servers, they will be
returned. The returned response may be empty if the peer does not
know of any servers, in which case the process gets repeated with
some other random Resource-ID. As long as the ratio of servers
relative to peers is not too low, this approach will result in
finding a server relatively quickly.
- NOTE TO IMPLEMENTERS: As the access control for this usage is not
- CERTIFICATE_BY_NODE or CERTIFICATE_BY_USER, the certificates used by
- TurnServer entries need to be retained as described in Section 6.3.4.
+ Note to implementers: The certificates used by TurnServer entries
+ need to be retained as described in Section 6.3.4.
10. Chord Algorithm
This algorithm is assigned the name CHORD-RELOAD to indicate it is an
adaptation of the basic Chord based DHT algorithm.
This algorithm differs from the originally presented Chord algorithm
[Chord]. It has been updated based on more recent research results
and implementation experiences, and to adapt it to the RELOAD
protocol. A short list of differences:
@@ -4895,62 +5033,62 @@
o This algorithm allows the use of either reactive or periodic
recovery. The original Chord paper used periodic recovery.
Reactive recovery provides better performance in small overlays,
but is believed to be unstable in large (>1000) overlays with high
levels of churn [handling-churn-usenix04]. The overlay
configuration file specifies a "chord-reactive" element that
indicates whether reactive recovery should be used.
10.1. Overview
- The algorithm described here is a modified version of the Chord
- algorithm. In Chord (and in the algorithm described here), nodes are
- arranged in a ring with node n being adjacent to nodes n-1 and n+1,
- with all arithmetic being done modulo 2^{k}, where k is the length of
- the Node-ID in bits, so that node 2^{k} - 1 is directly before node
- 0.
+ The algorithm described here, CHORD-RELOAD, is a modified version of
+ the Chord algorithm. In Chord (and in the algorithm described here),
+ nodes are arranged in a ring with node n being adjacent to nodes n-1
+ and n+1, with all arithmetic being done modulo 2^{k}, where k is the
+ length of the Node-ID in bits, so that node 2^{k} - 1 is directly
+ before node 0.
Each peer keeps track of a finger table and a neighbor table. The
neighbor table contains at least the three peers before and after
this peer in the DHT ring. There may not be three entries in all
cases such as small rings or while the ring topology is changing.
The first entry in the finger table contains the peer half-way around
the ring from this peer; the second entry contains the peer that is
1/4 of the way around; the third entry contains the peer that is
- 1/8th of the way around, and so on. Fundamentally, the chord DHT can
+ 1/8th of the way around, and so on. Fundamentally, the Chord DHT can
be thought of a doubly-linked list formed by knowing the successors
and predecessor peers in the neighbor table, sorted by the Node-ID.
As long as the successor peers are correct, the DHT will return the
correct result. The pointers to the prior peers are kept to enable
the insertion of new peers into the list structure. Keeping multiple
predecessor and successor pointers makes it possible to maintain the
integrity of the data structure even when consecutive peers
- simultaneously fail. The finger table forms a skip list, so that
- entries in the linked list can be found in O(log(N)) time instead of
- the typical O(N) time that a linked list would provide where N
- represents the number of nodes in the DHT.
+ simultaneously fail. The finger table forms a skip
+ list[wikiSkiplist], so that entries in the linked list can be found
+ in O(log(N)) time instead of the typical O(N) time that a linked list
+ would provide where N represents the number of nodes in the DHT.
The neighbor and finger table entries contain logical Node-IDs as
values but the actual mapping of an IP level addressing information
to reach that Node-ID is kept in the connection table.
A peer, x, is responsible for a particular Resource-ID k if k is less
than or equal to x and k is greater than p, where p is the Node-ID of
the previous peer in the neighbor table. Care must be taken when
computing to note that all math is modulo 2^128.
10.2. Hash Function
For this Chord based topology plugin, the size of the Resource-ID is
128 bits. The hash of a Resource-ID MUST be computed using SHA-1
- [RFC3174] then truncating the SHA-1 result to the most significant
- 128 bits.
+ [RFC3174] then the SHA-1 result MUST be truncated to the most
+ significant 128 bits.
10.3. Routing
The routing table is conceptually the union of the neighbor table and
the finger table.
If a peer is not responsible for a Resource-ID k, but is directly
connected to a node with Node-ID k, then it MUST route the message to
that node. Otherwise, it MUST route the request to the peer in the
routing table that has the largest Node-ID that is in the interval
@@ -4976,88 +5114,87 @@
Managing replicas as the overlay changes is described in
Section 10.7.3.
The sequential replicas used in this overlay algorithm protect
against peer failure but not against malicious peers. Additional
replication from the Usage is required to protect resources from such
attacks, as discussed in Section 13.5.4.
10.5. Joining
- The join process for a joining party (JP) with Node-ID n is as
+ The join process for a Joining Node (JN) with Node-ID n is as
follows.
- 1. JP MUST connect to its chosen bootstrap node.
- 2. JP SHOULD send an Attach request to the admitting peer (AP) for
+ 1. JN MUST connect to its chosen bootstrap node.
+ 2. JN SHOULD send an Attach request to the admitting peer (AP) for
Node-ID n. The "send_update" flag can be used to acquire the
routing table for AP.
-
- 3. JP SHOULD send Attach requests to initiate connections to each of
+ 3. JN SHOULD send Attach requests to initiate connections to each of
the peers in the neighbor table as well as to the desired finger
table entries. Note that this does not populate their routing
- tables, but only their connection tables, so JP will not get
+ tables, but only their connection tables, so JN will not get
messages that it is expected to route to other nodes.
- 4. JP MUST enter all the peers it has successfully contacted into
+ 4. JN MUST enter all the peers it has successfully contacted into
its routing table.
- 5. JP MUST send a Join to AP. The AP sends the response to the
+ 5. JN MUST send a Join to AP. The AP MUST send the response to the
Join.
- 6. AP MUST do a series of Store requests to JP to store the data
- that JP will be responsible for.
- 7. AP MUST send JP an Update explicitly labeling JP as its
- predecessor. At this point, JP is part of the ring and
+ 6. AP MUST do a series of Store requests to JN to store the data
+ that JN will be responsible for.
+ 7. AP MUST send JN an Update explicitly labeling JN as its
+ predecessor. At this point, JN is part of the ring and
responsible for a section of the overlay. AP MAY now forget any
- data which is assigned to JP and not AP. AP SHOULD not forget
+ data which is assigned to JN and not AP. AP SHOULD NOT forget
any data where AP is the replica set for the data.
8. The AP MUST send an Update to all of its neighbors with the new
- values of its neighbor set (including JP).
- 9. The JP MUST send Updates to all the peers in its neighbor table.
+ values of its neighbor set (including JN).
+ 9. The JN MUST send Updates to all the peers in its neighbor table.
- If JP sends an Attach to AP with send_update, it immediately knows
- most of its expected neighbors from AP's routing table update and can
+ If JN sends an Attach to AP with send_update, it immediately knows
+ most of its expected neighbors from AP's routing table update and MAY
directly connect to them. This is the RECOMMENDED procedure.
- If for some reason JP does not get AP's routing table, it can still
- populate its neighbor table incrementally. It sends a Ping directed
- at Resource-ID n+1 (directly after its own Resource-ID). This allows
- it to discover its own successor. Call that node p0. It then sends
- a ping to p0+1 to discover its successor (p1). This process can be
- repeated to discover as many successors as desired. The values for
- the two peers before p will be found at a later stage when n receives
- an Update. An alternate procedure is to send Attaches to those nodes
- rather than pings, which forms the connections immediately but may be
- slower if the nodes need to collect ICE candidates, thus reducing
- parallelism.
+ If for some reason JN does not get AP's routing table, it MAY still
+ populate its neighbor table incrementally. It SHOULD send a Ping
+ directed at Resource-ID n+1 (directly after its own Resource-ID).
+ This allows it to discover its own successor. Call that node p0. It
+ then SHOULD send a ping to p0+1 to discover its successor (p1). This
+ process MAY be repeated to discover as many successors as desired.
+ The values for the two peers before p will be found at a later stage
+ when n receives an Update. An alternate procedure is to send
+ Attaches to those nodes rather than pings, which forms the
+ connections immediately but may be slower if the nodes need to
+ collect ICE candidates, thus reducing parallelism.
- In order to set up its i'th finger table entry, JP simply sends an
+ In order to set up its i'th finger table entry, JN MUST send an
Attach to peer n+2^(128-i). This will be routed to a peer in
approximately the right location around the ring. (Note the first
entry in the finger table has i=1 and not i=0 in this formulation).
- The joining peer MUST NOT send any Update message placing itself in
+ The joining node MUST NOT send any Update message placing itself in
the overlay until it has successfully completed an Attach with each
peer that should be in its neighbor table.
10.6. Routing Attaches
When a peer needs to Attach to a new peer in its neighbor table, it
MUST source-route the Attach request through the peer from which it
learned the new peer's Node-ID. Source-routing these requests allows
the overlay to recover from instability.
All other Attach requests, such as those for new finger table
entries, are routed conventionally through the overlay.
10.7. Updates
An Update for this DHT is defined as
- enum { reserved(0),
+ enum { invalidChordUpdateType(0),
peer_ready(1), neighbors(2), full(3), (255) }
ChordUpdateType;
struct {
uint32 uptime;
ChordUpdateType type;
select (type){
case peer_ready: /* Empty */
;
@@ -5108,62 +5245,65 @@
The successor set of the Updating peer.
fingers
The finger table of the Updating peer, in numerically ascending
order.
A peer MUST maintain an association (via Attach) to every member of
its neighbor set. A peer MUST attempt to maintain at least three
predecessors and three successors, even though this will not be
possible if the ring is very small. It is RECOMMENDED that O(log(N))
- predecessors and successors be maintained in the neighbor set.
+ predecessors and successors be maintained in the neighbor set. There
+ are many ways to estimate N, some of which are discussed in
+ [I-D.ietf-p2psip-self-tuning].
10.7.1. Handling Neighbor Failures
Every time a connection to a peer in the neighbor table is lost (as
determined by connectivity pings or the failure of some request), the
peer MUST remove the entry from its neighbor table and replace it
with the best match it has from the other peers in its routing table.
- If using reactive recovery, it then sends an immediate Update to all
+ If using reactive recovery, it MUST send an immediate Update to all
nodes in its Neighbor Table. The update will contain all the Node-
IDs of the current entries of the table (after the failed one has
been removed). Note that when replacing a successor the peer SHOULD
delay the creation of new replicas for successor replacement hold-
down time (30 seconds) after removing the failed entry from its
neighbor table in order to allow a triggered update to inform it of a
better match for its neighbor table.
If the neighbor failure affects the peer's range of responsible IDs,
then the Update MUST be sent to all nodes in its Connection Table.
A peer MAY attempt to reestablish connectivity with a lost neighbor
either by waiting additional time to see if connectivity returns or
by actively routing a new Attach to the lost peer. Details for these
- procedures are beyond the scope of this document. In no event does
- an attempt to reestablish connectivity with a lost neighbor allow the
- peer to remain in the neighbor table. Such a peer is returned to the
- neighbor table once connectivity is reestablished.
+ procedures are beyond the scope of this document. In the case of an
+ attempt to reestablish connectivity with a lost neighbor, the peer
+ MUST be removed from the neighbor table. Such a peer is returned to
+ the neighbor table once connectivity is reestablished.
If connectivity is lost to all successor peers in the neighbor table,
- then this peer should behave as if it is joining the network and use
- Pings to find a peer and send it a Join. If connectivity is lost to
- all the peers in the finger table, this peer should assume that it
- has been disconnected from the rest of the network, and it should
+ then this peer SHOULD behave as if it is joining the network and MUST
+ use Pings to find a peer and send it a Join. If connectivity is lost
+ to all the peers in the finger table, this peer SHOULD assume that it
+ has been disconnected from the rest of the network, and it SHOULD
periodically try to join the DHT.
10.7.2. Handling Finger Table Entry Failure
If a finger table entry is found to have failed, all references to
- the failed peer are removed from the finger table and replaced with
- the closest preceding peer from the finger table or neighbor table.
+ the failed peer MUST be removed from the finger table and replaced
+ with the closest preceding peer from the finger table or neighbor
+ table.
- If using reactive recovery, the peer initiates a search for a new
+ If using reactive recovery, the peer MUST initiate a search for a new
finger table entry as described below.
10.7.3. Receiving Updates
When a peer, x, receives an Update request, it examines the Node-IDs
in the UpdateReq and at its neighbor table and decides if this
UpdateReq would change its neighbor table. This is done by taking
the set of peers currently in the neighbor table and comparing them
to the peers in the update request. There are two major cases:
@@ -5174,21 +5314,21 @@
neighbor table.
In the first case, no change is needed.
In the second case, x MUST attempt to Attach to the new peers and if
it is successful it MUST adjust its neighbor set accordingly. Note
that it can maintain the now inferior peers as neighbors, but it MUST
remember the closer ones.
After any Pings and Attaches are done, if the neighbor table changes
- and the peer is using reactive recovery, the peer sends an Update
+ and the peer is using reactive recovery, the peer MUST send an Update
request to each member of its Connection Table. These Update
requests are what end up filling in the predecessor/successor tables
of peers that this peer is a neighbor to. A peer MUST NOT enter
itself in its successor or predecessor table and instead should leave
the entries empty.
If peer x is responsible for a Resource-ID R, and x discovers that
the replica set for R (the next two nodes in its successor set) has
changed, it MUST send a Store for any data associated with R to any
new node in the replica set. It SHOULD NOT delete data from peers
@@ -5272,59 +5412,57 @@
to discover more fingers to grow the size of the table to 16. The
value 16 was chosen to ensure high odds of a node maintaining
connectivity to the overlay even with strange network partitions.
For many overlays, 16 finger table entries will be enough, but as an
overlay grows very large, more than 16 entries may be required in the
finger table for efficient routing. An implementation SHOULD be
capable of increasing the number of entries in the finger table to
128 entries.
- Note to implementers: Although log(N) entries are all that are
- required for optimal performance, careful implementation of
- stabilization will result in no additional traffic being generated
- when maintaining a finger table larger than log(N) entries.
- Implementers are encouraged to make use of RouteQuery and algorithms
- for determining where new finger table entries may be found.
- Complete details of possible implementations are outside the scope of
- this specification.
+ Although log(N) entries are all that are required for optimal
+ performance, careful implementation of stabilization will result in
+ no additional traffic being generated when maintaining a finger table
+ larger than log(N) entries. Implementers are encouraged to make use
+ of RouteQuery and algorithms for determining where new finger table
+ entries may be found. Complete details of possible implementations
+ are outside the scope of this specification.
A simple approach to sizing the finger table is to ensure the finger
table is large enough to contain at least the final successor in the
peer's neighbor table.
10.7.4.4. Detecting partitioning
To detect that a partitioning has occurred and to heal the overlay, a
peer P MUST periodically repeat the discovery process used in the
initial join for the overlay to locate an appropriate bootstrap node,
- B. P should then send a Ping for its own Node-ID routed through B. If
+ B. P SHOULD then send a Ping for its own Node-ID routed through B. If
a response is received from a peer S', which is not P's successor,
- then the overlay is partitioned and P should send an Attach to S'
+ then the overlay is partitioned and P SHOULD send an Attach to S'
routed through B, followed by an Update sent to S'. (Note that S'
may not be in P's neighbor table once the overlay is healed, but the
connection will allow S' to discover appropriate neighbor entries for
itself via its own stabilization.)
Future specifications may describe alternative mechanisms for
determining when to repeat the discovery process.
10.8. Route query
- For this topology plugin, the RouteQueryReq contains no additional
+ For CHORD-RELOAD, the RouteQueryReq contains no additional
information. The RouteQueryAns contains the single Node-ID of the
next peer to which the responding peer would have routed the request
message in recursive routing:
struct {
NodeId next_peer;
-
} ChordRouteQueryAns;
The contents of this structure are as follows:
next_peer
The peer to which the responding peer would route the message in
order to deliver it to the destination listed in the request.
If the requester has set the send_update flag, the responder SHOULD
initiate an Update immediately after sending the RouteQueryAns.
@@ -5329,21 +5467,21 @@
If the requester has set the send_update flag, the responder SHOULD
initiate an Update immediately after sending the RouteQueryAns.
10.9. Leaving
To support extensions, such as [I-D.ietf-p2psip-self-tuning], Peers
SHOULD send a Leave request to all members of their neighbor table
prior to exiting the Overlay Instance. The overlay_specific_data
field MUST contain the ChordLeaveData structure defined below:
- enum { reserved(0),
+ enum { invalidChordLeaveType(0),
from_succ(1), from_pred(2), (255) }
ChordLeaveType;
struct {
ChordLeaveType type;
select (type) {
case from_succ:
NodeId successors<0..2^16-1>;
@@ -5364,22 +5502,22 @@
If the type of the request is 'from_succ', the contents will be:
successors
The sender's successor list.
If the type of the request is 'from_pred', the contents will be:
predecessors
The sender's predecessor list.
- Any peer which receives a Leave for a peer n in its neighbor set
- follows procedures as if it had detected a peer failure as described
+ Any peer which receives a Leave for a peer n in its neighbor set MUST
+ follow procedures as if it had detected a peer failure as described
in Section 10.7.1.
11. Enrollment and Bootstrap
The section defines the format of the configuration data as well the
process to join a new overlay.
11.1. Overlay Configuration
This specification defines a new content type "application/
@@ -5415,22 +5553,20 @@
YmFkIGNlcnQK
https://example.org
https://example.net
false
20
-
-
false
false
400
30
true
password
4000
30
3000
@@ -5483,113 +5617,133 @@
VGhpcyBpcyBub3QgcmlnaHQhCg==
The file MUST be a well formed XML document and it SHOULD contain an
encoding declaration in the XML declaration. The file MUST use the
UTF-8 character encoding. The namespace for the elements defined in
this specification is urn:ietf:params:xml:ns:p2p:config-base and
urn:ietf:params:xml:ns:p2p:config-chord".
- The file can contain multiple "configuration" elements where each one
+ Note that elements or attributes that are defined as type xsd:boolean
+ in the RELAX NG schema (Section 11.1.1) have two lexical
+ representations, "1" or "true" for the concept true and "0" or
+ "false" for the concept false. Whitespace and case processing
+ follows the rules of [OASIS.relax_ng] and XML Schema Datatypes
+
+ [W3C.REC-xmlschema-2-20041028] .
+
+ The file MAY contain multiple "configuration" elements where each one
contains the configuration information for a different overlay. Each
- configuration element may be followed by signature elements that
+ configuration element MAY be followed by signature elements that
provides a signature over the preceding configuration element. Each
configuration element has the following attributes:
- instance-name: name of the overlay
+ instance-name: the name of the overlay (referred to as "overlay
+ name" in this specification)
+
expiration: time in the future at which this overlay configuration
is no longer valid. The node SHOULD retrieve a new copy of the
configuration at a randomly selected time that is before the
expiration time. Note that if the certificates expire before a
new configuration is retried, the node will not be able to
validate the configuration file. All times MUST be in UTC.
+
sequence: a monotonically increasing sequence number between 0 and
2^16-2
Inside each overlay element, the following elements can occur:
topology-plugin This element defines the overlay algorithm being
used. If missing the default is "CHORD-RELOAD".
+
node-id-length This element contains the length of a NodeId
(NodeIdLength) in bytes. This value MUST be between 16 (128 bits)
and 20 (160 bits). If this element is not present, the default of
16 is used.
+
root-cert This element contains a base-64 encoded X.509v3
certificate that is a root trust anchor used to sign all
certificates in this overlay. There can be more than one root-
cert element.
+
enrollment-server This element contains the URL at which the
enrollment server can be reached in a "url" element. This URL
MUST be of type "https:". More than one enrollment-server element
- may be present. Note that there is no necessary relationship
+ MAY be present. Note that there is no necessary relationship
between the overlay name/configuration server name and the
enrollment server name.
+
self-signed-permitted This element indicates whether self-signed
certificates are permitted. If it is set to "true", then self-
signed certificates are allowed, in which case the enrollment-
- server and root-cert elements may be absent. Otherwise, it SHOULD
+ server and root-cert elements MAY be absent. Otherwise, it SHOULD
be absent, but MAY be set to "false". This element also contains
an attribute "digest" which indicates the digest to be used to
compute the Node-ID. Valid values for this parameter are "sha1"
and "sha256" representing SHA-1 [RFC3174] and SHA-256 [RFC6234]
respectively. Implementations MUST support both of these
algorithms.
+
bootstrap-node This element represents the address of one of the
bootstrap nodes. It has an attribute called "address" that
represents the IP address (either IPv4 or IPv6, since they can be
distinguished) and an optional attribute called "port" that
represents the port and defaults to 6084. The IPv6 address is in
typical hexadecimal form using standard period and colon
separators as specified in [RFC5952]. More than one bootstrap-
- peer element may be present.
+ node element MAY be present.
+
turn-density This element is a positive integer that represents the
approximate reciprocal of density of nodes that can act as TURN
servers. For example, if 5% of the nodes can act as TURN servers,
this would be set to 20. If it is not present, the default value
is 1. If there are no TURN servers in the overlay, it is set to
zero.
- multicast-bootstrap This element represents the address of a
- multicast, broadcast, or anycast address and port that may be used
- for bootstrap. Nodes SHOULD listen on the address. It has an
- attribute called "address" that represents the IP address and an
- optional attribute called "port" that represents the port and
- defaults to 6084. More than one "multicast-bootstrap" element may
- be present.
+
clients-permitted This element represents whether clients are
- permitted or whether all nodes must be peers. If it is set to
- "true" or absent, this indicates that clients are permitted. If
- it is set to "false" then nodes are not allowed to remain clients
- after the initial join. There is currently no way for the overlay
- to enforce this.
- no-ice This element represents whether nodes are required to use
+ permitted or whether all nodes must be peers. If clients are
+ permitted, the element MUST be set to "true" or absent. If the
+ nodes are not allowed to remain clients after the initial join,
+ the element MUST be set to "false". There is currently no way for
+ the overlay to enforce this.
+
+ no-ice This element represents whether nodes are REQUIRED to use
the "No-ICE" Overlay Link protocols in this overlay. If it is
absent, it is treated as if it were set to "false".
- chord-update-interval The update frequency for the Chord-reload
+
+ chord-update-interval The update frequency for the CHORD-RELOAD
topology plugin (see Section 10).
- chord-ping-interval The ping frequency for the Chord-reload
+
+ chord-ping-interval The ping frequency for the CHORD-RELOAD
topology plugin (see Section 10).
- chord-reactive Whether reactive recovery should be used for this
+
+ chord-reactive Whether reactive recovery SHOULD be used for this
overlay. Set to "true" or "false". Default if missing is "true".
(see Section 10).
+
shared-secret If shared secret mode is used, this contains the
shared secret. The security guarantee here is that any agent
which is able to access the configuration document (presumably
protected by some sort of HTTP access control or network topology)
is able to recover the shared secret and hence join the overlay.
+
max-message-size Maximum size in bytes of any message in the
overlay. If this value is not present, the default is 5000.
+
initial-ttl Initial default TTL (time to live, see Section 6.3.2)
for messages. If this value is not present, the default is 100.
+
overlay-reliability-timer Default value for the end-to-end
retransmission timer for messages, in milliseconds. If not
present, the default value is 3000.
+
overlay-link-protocol Indicates a permissible overlay link protocol
(see Section 6.6.1 for requirements for such protocols). An
arbitrary number of these elements may appear. If none appear,
then this implies the default value, "TLS", which refers to the
use of TLS and DTLS. If one or more elements appear, then no
default value applies.
kind-signer This contains a single Node-ID in hexadecimal and
indicates that the certificate with this Node-ID is allowed to
sign Kinds. Identifying kind-signer by Node-ID instead of
@@ -5588,111 +5742,121 @@
arbitrary number of these elements may appear. If none appear,
then this implies the default value, "TLS", which refers to the
use of TLS and DTLS. If one or more elements appear, then no
default value applies.
kind-signer This contains a single Node-ID in hexadecimal and
indicates that the certificate with this Node-ID is allowed to
sign Kinds. Identifying kind-signer by Node-ID instead of
certificate allows the use of short lived certificates without
constantly having to provide an updated configuration file.
+
configuration-signer This contains a single Node-ID in hexadecimal
and indicates that the certificate with this Node-ID is allowed to
sign configurations for this instance-name. Identifying the
signer by Node-ID instead of certificate allows the use of short
lived certificates without constantly having to provide an updated
configuration file.
+
bad-node This contains a single Node-ID in hexadecimal and
indicates that the certificate with this Node-ID MUST NOT be
considered valid. This allows certificate revocation. An
arbitrary number of these elements can be provided. Note that
because certificates may expire, bad-node entries need only be
present for the lifetime of the certificate. Technically
speaking, bad Node-IDs may be reused once their certificates have
expired, the requirement for Node-IDs to be pseudo randomly
generated gives this event a vanishing probability.
+
mandatory-extension This element contains the name of an XML
namespace that a node joining the overlay MUST support. The
presence of a mandatory-extension element does not require the
extension to be used in the current configuration file, but can
indicate that it may be used in the future. Note that the
namespace is case-sensitive, as specified in [w3c-xml-namespaces]
- Section 2.3. More than one mandatory-extension element may be
+ Section 2.3. More than one mandatory-extension element MAY be
present.
- Inside each configuration element, the required-kinds element can
- also occur. This element indicates the Kinds that members must
+ Inside each configuration element, the required-kinds element MAY
+ also occur. This element indicates the Kinds that members MUST
support and contains multiple kind-block elements that each define a
single Kind that MUST be supported by nodes in the overlay. Each
kind-block consists of a single kind element and a kind-signature.
The kind element defines the Kind. The kind-signature is the
signature computed over the kind element.
- Each kind has either an id attribute or a name attribute. The name
- attribute is a string representing the Kind (the name registered to
- IANA) while the id is an integer Kind-ID allocated out of private
- space.
+ Each kind element has either an id attribute or a name attribute.
+ The name attribute is a string representing the Kind (the name
+ registered to IANA) while the id is an integer Kind-ID allocated out
+ of private space.
- In addition, the kind element contains the following elements:
+ In addition, the kind element MUST contain the following elements:
max-count: the maximum number of values which members of the overlay
must support.
data-model: the data model to be used.
+
max-size: the maximum size of individual values.
+
access-control: the access control model to be used.
- max-node-multiple: This is optional and only used when the access
- control is NODE-MULTIPLE. This indicates the maximum value for
- the i counter. This is an integer greater than 0.
+
+ The kind element MAY also contain the following element:
+ max-node-multiple: if the access control is NODE-MULTIPLE, this
+ element MUST be included. This indicates the maximum value for
+ the i counter. It MUST be an integer greater than 0.
All of the non optional values MUST be provided. If the Kind is
registered with IANA, the data-model and access-control elements MUST
match those in the Kind registration, and clients MUST ignore them in
favor of the IANA versions. Multiple kind-block elements MAY be
present.
The kind-block element also MUST contain a "kind-signature" element.
- This signature is computed across the kind from the beginning of the
- first < of the kind to the end of the last > of the kind in the same
- way as the signature element described later in this section.
+ This signature is computed across the kind element from the beginning
+ of the first < of the kind element to the end of the last > of the
+ kind element in the same way as the signature element described later
+ in this section. kind-block elements MUST be signed by a node listed
+ in the kind-signers block of the current configuration. Receivers
+ MUST verify the signature prior to accepting a kind-block.
- The configuration element needs to be treated as a binary blob that
+ The configuration element MUST be treated as a binary blob that
cannot be changed - including any whitespace changes - or the
- signature will break. The signature is computed by taking each
+ signature will break. The signature MUST be computed by taking each
configuration element and starting from, and including, the first <
at the start of up to and including the > in
- and treating this as a binary blob that is signed
- using the standard SecurityBlock defined in Section 6.3.4. The
- SecurityBlock is base 64 encoded using the base64 alphabet from
- [RFC4648] and put in the signature element following the
+ and treating this as a binary blob that MUST be
+ signed using the standard SecurityBlock defined in Section 6.3.4.
+ The SecurityBlock MUST be base 64 encoded using the base64 alphabet
+ from [RFC4648] and MUST be put in the signature element following the
configuration object in the configuration file. Any configuration
file MUST be signed by one of the configuration-signer elements from
the previous extant configuration. Recipients MUST verify the
signature prior to accepting the configuration file.
When a node receives a new configuration file, it MUST change its
configuration to meet the new requirements. This may require the
node to exit the DHT and re-join. If a node is not capable of
supporting the new requirements, it MUST exit the overlay. If some
information about a particular Kind changes from what the node
previously knew about the Kind (for example the max size), the new
information in the configuration files overrides any previously
learned information. If any Kind data was signed by a node that is
- no longer allowed to sign kinds, that Kind MUST be discarded along
+ no longer allowed to sign Kinds, that Kind MUST be discarded along
with any stored information of that Kind. Note that forcing an
avalanche restart of the overlay with a configuration change that
requires re-joining the overlay may result in serious performance
problems, including total collapse of the network if configuration
parameters are not properly considered. Such an event may be
necessary in case of a compromised CA or similar problem, but for
large overlays should be avoided in almost all circumstances.
-11.1.1. Relax NG Grammar
+11.1.1. RELAX NG Grammar
The grammar for the configuration data is:
namespace chord = "urn:ietf:params:xml:ns:p2p:config-chord"
namespace local = ""
default namespace p2pcf = "urn:ietf:params:xml:ns:p2p:config-base"
namespace rng = "http://relaxng.org/ns/structure/1.0"
anything =
(element * { anything }
@@ -5747,25 +5911,21 @@
element self-signed-permitted {
attribute digest { self-signed-digest-type },
xsd:boolean
}?
self-signed-digest-type |= "sha1"
self-signed-digest-type |= xsd:string # signature digest extensions
parameter &= element bootstrap-node {
attribute address { xsd:string },
attribute port { xsd:int }?
- }*
- parameter &= element multicast-bootstrap {
- attribute address { xsd:string },
- attribute port { xsd:int }?
}*
kind-block = element kind-block {
element kind {
( attribute name { kind-names }
| attribute id { xsd:unsignedInt } ),
kind-parameter
} &
element kind-signature {
attribute algorithm { signature-algorithm-type }?,
@@ -5801,172 +5961,175 @@
topology-plugin-type |= "CHORD-RELOAD"
parameter &= element chord:chord-ping-interval { xsd:int }?
parameter &= element chord:chord-update-interval { xsd:int }?
parameter &= element chord:chord-reactive { xsd:boolean }?
11.2. Discovery Through Configuration Server
When a node first enrolls in a new overlay, it starts with a
discovery process to find a configuration server.
- The node MAY start by determining the overlay name. This value is
- provided by the user or some other out of band provisioning
+ The node MAY start by determining the overlay name. This value MUST
+ be provided by the user or some other out of band provisioning
mechanism. The out of band mechanisms MAY also provide an optional
URL for the configuration server. If a URL for the configuration
server is not provided, the node MUST do a DNS SRV query using a
Service name of "reload-config" and a protocol of TCP to find a
configuration server and form the URL by appending a path of "/.well-
known/reload-config" to the overlay name. This uses the "well known
URI" framework defined in [RFC5785]. For example, if the overlay
name was example.com, the URL would be
"https://example.com/.well-known/reload-config".
Once an address and URL for the configuration server is determined,
- the peer MUST form an HTTPS connection to that IP address. The
- certificate MUST match the overlay name as described in [RFC2818].
- Then the node MUST fetch a new copy of the configuration file. To do
- this, the peer performs a GET to the URL. The result of the HTTP GET
- is an XML configuration file described above, which MUST replace any
- previously learned configuration file for this overlay.
+ the peer MUST form an HTTPS connection to that IP address. If an
+ optional URL for the configuration server was provided, the
+ certificate MUST match the domain name from the URL as described in
+ [RFC2818]; otherwise the certificate MUST match the overlay name as
+ described in [RFC2818]. If the HTTPS certificates passes the name
+ matching, the node MUST fetch a new copy of the configuration file.
+ To do this, the peer performs a GET to the URL. The result of the
+ HTTP GET is an XML configuration file described above. If the XML is
+ not valid, or the instance-name attribute of the overlay-element in
+ the XML does not match the overlay name, this configurations file
+ SHOULD be discarded. Otherwise, the new configuration MUST replace
+ any previously learned configuration file for this overlay.
- For overlays that do not use a configuration server, nodes need to
+ For overlays that do not use a configuration server, nodes MUST
obtain the configuration information needed to join the overlay
- through some out of band approach such an XML configuration file sent
- over email.
+ through some out of band approach such as an XML configuration file
+ sent over email.
11.3. Credentials
If the configuration document contains a enrollment-server element,
- credentials are required to join the Overlay Instance. A peer which
+ credentials are REQUIRED to join the Overlay Instance. A peer which
does not yet have credentials MUST contact the enrollment server to
acquire them.
RELOAD defines its own trivial certificate request protocol. We
would have liked to have used an existing protocol but were concerned
about the implementation burden of even the simplest of those
protocols, such as [RFC5272] and [RFC5273]. The objective was to
have a protocol which could be easily implemented in a Web server
which the operator did not control (e.g., in a hosted service) and
was compatible with the existing certificate handling tooling as used
with the Web certificate infrastructure. This means accepting bare
PKCS#10 requests and returning a single bare X.509 certificate.
Although the MIME types for these objects are defined, none of the
existing protocols support exactly this model.
- The certificate request protocol is performed over HTTPS. The
- request is an HTTP POST with the parameters encoded as described in
- [RFC2388] and the following properties:
+ The certificate request protocol MUST be performed over HTTPS. The
+ server certificate MUST match the overlay name as described in
+ [RFC2818]. The request MUST be an HTTP POST with the parameters
+ encoded as described in [RFC2388] and the following properties:
- o If authentication is required, there is an form parameter of
- "password" and "username" containing the user's name and password
- in the clear (hence the need for HTTPS)
- o If more than one Node-ID is required, there is an form parameter
- of "nodeids" containing the number of Node-IDs required.
+ o If authentication is required, there MUST be form parameters of
+ "password" and "username" containing the user's account name and
+ password in the clear (hence the need for HTTPS). The username
+ and password strings MUST be UTF-8 strings compared as binary
+ objects. Applications using RELOAD SHOULD define any needed
+ string preparation as per [RFC4013] or its successor documents.
+ o If more than one Node-ID is required, there MUST be a form
+ parameter of "nodeids" containing the number of Node-IDs required.
o There MUST be a form parameter of "csr" with a content type of
- "application/pkcs10", as defined in [RFC2311].
+ "application/pkcs10", as defined in [RFC2311] that contains the
+ certificate signing request (CSR).
o The Accept header MUST contain the type "application/pkix-cert",
indicating the type that is expected in the response.
The enrollment server MUST authenticate the request using the
- provided user name and password. The reason for using the RFC 2388
- "multipart/form-data" encoding is so that the password parameter will
- not be encoded in the URL to reduce the chance of accidental leakage
- of the password. If the authentication succeeds and the requested
- user name is acceptable, the server generates and returns a
- certificate for the certificate signing request in the "csr"
- parameter of the request. The SubjectAltName field in the
- certificate contains the following values:
+ provided account name and password. The reason for using the RFC
+ 2388 "multipart/form-data" encoding is so that the password parameter
+ will not be encoded in the URL to reduce the chance of accidental
+ leakage of the password. If the authentication succeeds and the
+ requested user name in the CSR is acceptable, the server MUST
+ generate and return a certificate for the CSR in the "csr" parameter
+ of the request. The SubjectAltName field in the certificate MUST
+ contain the following values:
o One or more Node-IDs which MUST be cryptographically random
[RFC4086]. Each MUST be chosen by the enrollment server in such a
way that they are unpredictable to the requesting user. E.g., the
user MUST NOT be informed of potential (random) Node-IDs prior to
authenticating. Each is placed in the subjectAltName using the
uniformResourceIdentifier type and MUST contain RELOAD URIs as
described in Section 14.15 and MUST contain a Destination list
with a single entry of type "node_id". The enrollment server
SHOULD maintain a mapping of users to Node-IDs and if the same
user returns (e.g., to have their certificate re-issued) return
the same Node-IDs, thus avoiding the need for implementations to
re-store all their data when their certificates expire.
- o A single name this user is allowed to use in the overlay, using
- type rfc822Name. Enrollment servers SHOULD take care to only
- allow legal characters in the name (e.g., no embedded NULs),
- rather than simply accepting any name provided by the user.
- The certificate is returned as type "application/pkix-cert" as
+ o A single name (the "user name") that this user is allowed to use
+ in the overlay, using type rfc822Name. Enrollment servers SHOULD
+ take care to only allow legal characters in the name (e.g., no
+ embedded NULs), rather than simply accepting any name provided by
+ the user. In some usages, the right-hand-side of the user name
+ will match the overlay name, but there is no requirement for this
+ match in this specification. Applications using this
+ specification MAY define such a requirement, or MAY otherwise
+ limit the allowed range of allowed user names.
+
+ The certificate MUST be returned as type "application/pkix-cert" as
defined in [RFC2585], with an HTTP status code of 200 OK.
- Certificate processing errors should result in a HTTP return code of
+ Certificate processing errors SHOULD result in a HTTP return code of
403 "Forbidden" along with a body of type "text/plain" and body that
consists of one of the tokens defined in the following list:
- failed_authentication The user name and password combination was not
- correct.
+ failed_authentication The account name and password combination used
+ in the HTTPS request was not valid.
- username_not_available The requested userName for the certificate
- was not acceptable.
+ username_not_available The requested user name in the CSR was not
+ acceptable.
Node-IDs_not_available The number of Node-IDs requested was not
acceptable.
- bad_CSR There was a problem with the CSR.
+ bad_CSR There was some other problem with the CSR.
If the client receives an unknown token in the body, it SHOULD treat
it as a failure for an unknown reason.
The client MUST check that the certificate returned chains back to
one of the certificates received in the "root-cert" list of the
overlay configuration data (including PKIX BasicConstraints checks.)
The node then reads the certificate to find the Node-ID it can use.
11.3.1. Self-Generated Credentials
If the "self-signed-permitted" element is present in the
configuration and set to "true", then a node MUST generate its own
self-signed certificate to join the overlay. The self-signed
certificate MAY contain any user name of the users choice.
For self-signed certificate containing only one Node-ID, the Node-ID
MUST be computed by applying the digest specified in the self-signed-
permitted element to the DER representation of the user's public key
(more specifically the subjectPublicKeyInfo) and taking the high
- order bits. For self-signed certficates containing multiple Node-
+ order bits. For self-signed certificates containing multiple Node-
IDs, the index of the Node-ID (from 1 to the number of Node-IDs
needed) must be prepended as a 4 bytes big endian integer to the DER
representation of the user's public key and taking the high order
bits. When accepting a self-signed certificate, nodes MUST check
that the Node-ID and public keys match. This prevents Node-ID theft.
Once the node has constructed a self-signed certificate, it MAY join
- the overlay. Before storing its certificate in the overlay
- (Section 8) it SHOULD look to see if the user name is already taken
- and if so choose another user name. Note that this only provides
- protection against accidental name collisions. Name theft is still
- possible. If protection against name theft is desired, then the
- enrollment service must be used.
-
-11.4. Searching for a Bootstrap Node
-
- If no cached bootstrap nodes are available and the configuration file
- has an multicast-bootstrap element, then the node SHOULD send a Ping
- request over UDP to the address and port found to each multicast-
- bootstrap element found in the configuration document. This MAY be a
- multicast, broadcast, or anycast address. The Ping should use the
- wildcard Node-ID as the destination Node-ID.
-
- The responder node that receives the Ping request SHOULD check that
- the overlay name is correct and that the requester peer sending the
- request has appropriate credentials for the overlay before responding
- to the Ping request even if the response is only an error.
+ the overlay. It MUST store its certificate in the overlay
+ (Section 8) but SHOULD look to see if the user name is already taken
+ before and if so choose another user name. Note that this only
+ provides protection against accidental name collisions. Name theft
+ is still possible. If protection against name theft is desired, then
+ the enrollment service MUST be used.
-11.5. Contacting a Bootstrap Node
+11.4. Contacting a Bootstrap Node
In order to join the overlay, the joining node MUST contact a node in
the overlay. Typically this means contacting the bootstrap nodes,
since they are reachable by the local peer or have public IP
addresses. If the joining node has cached a list of peers it has
previously been connected with in this overlay, as an optimization it
MAY attempt to use one or more of them as bootstrap nodes before
falling back to the bootstrap nodes listed in the configuration file.
When contacting a bootstrap node, the joining node MUST first form
@@ -5982,163 +6145,171 @@
After a node has successfully joined the overlay network, it will
have direct connections to several peers. Some MAY be added to the
cached bootstrap nodes list and used in future boots. Peers that are
not directly connected MUST NOT be cached. The suggested number of
peers to cache is 10. Algorithms for determining which peers to
cache are beyond the scope of this specification.
12. Message Flow Example
The following abbreviations are used in the message flow diagrams:
- JP = joining peer, AP = admitting peer, NP = next peer after the AP,
+ JN = joining node, AP = admitting peer, NP = next peer after the AP,
NNP = next next peer which is the peer after NP, PP = previous peer
before the AP, PPP = previous previous peer which is the peer before
the PP, BP = bootstrap peer.
- In the following example, we assume that JP has formed a connection
- to one of the bootstrap nodes. JP then sends an Attach through that
- peer to a resource ID of itself (JP). It gets routed to the
- admitting peer (AP) because JP is not yet part of the overlay. When
- AP responds, JP and AP use ICE to set up a connection and then set up
- DTLS. Once AP has connected to JP, AP sends to JP an Update to
+ In the following example, we assume that JN has formed a connection
+ to one of the bootstrap nodes. JN then sends an Attach through that
+ peer to a resource ID of itself (JN). It gets routed to the
+ admitting peer (AP) because JN is not yet part of the overlay. When
+ AP responds, JN and AP use ICE to set up a connection and then set up
+ DTLS. Once AP has connected to JN, AP sends to JN an Update to
populate its Routing Table. The following example shows the Update
happening after the DTLS connection is formed but it could also
happen before in which case the Update would often be routed through
other nodes.
- JP PPP PP AP NP NNP BP
+ JN PPP PP AP NP NNP BP
| | | | | | |
| | | | | | |
| | | | | | |
- |Attach Dest=JP | | | | |
+ |Attach Dest=JN | | | | |
|---------------------------------------------------------->|
| | | | | | |
| | | | | | |
- | | |Attach Dest=JP | | |
+ | | |Attach Dest=JN | | |
| | |<--------------------------------------|
| | | | | | |
| | | | | | |
- | | |Attach Dest=JP | | |
+ | | |Attach Dest=JN | | |
| | |-------->| | | |
| | | | | | |
| | | | | | |
| | |AttachAns | | |
| | |<--------| | | |
| | | | | | |
| | | | | | |
| | |AttachAns | | |
| | |-------------------------------------->|
| | | | | | |
| | | | | | |
|AttachAns | | | | |
|<----------------------------------------------------------|
| | | | | | |
+ |ICE | | | | | |
+ |<===========================>| | | |
| | | | | | |
|TLS | | | | | |
- |.............................| | | |
+ |<...........................>| | | |
| | | | | | |
| | | | | | |
| | | | | | |
|Update | | | | | |
|<----------------------------| | | |
| | | | | | |
| | | | | | |
|UpdateAns| | | | | |
|---------------------------->| | | |
| | | | | | |
| | | | | | |
| | | | | | |
- The JP then forms connections to the appropriate neighbors, such as
+ Figure 1
+
+ The JN then forms connections to the appropriate neighbors, such as
NP, by sending an Attach which gets routed via other nodes. When NP
- responds, JP and NP use ICE and DTLS to set up a connection.
+ responds, JN and NP use ICE and DTLS to set up a connection.
- JP PPP PP AP NP NNP BP
+ JN PPP PP AP NP NNP BP
| | | | | | |
| | | | | | |
| | | | | | |
|Attach NP | | | | |
|---------------------------->| | | |
| | | | | | |
| | | | | | |
| | | |Attach NP| | |
| | | |-------->| | |
| | | | | | |
| | | | | | |
| | | |AttachAns| | |
| | | |<--------| | |
| | | | | | |
| | | | | | |
|AttachAns | | | | |
|<----------------------------| | | |
| | | | | | |
| | | | | | |
- |Attach | | | | | |
- |-------------------------------------->| | |
+ |ICE | | | | | |
+ |<=====================================>| | |
| | | | | | |
| | | | | | |
|TLS | | | | | |
- |.......................................| | |
+ |<.....................................>| | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
- JP also needs to populate its finger table (for the Chord based DHT).
+ Figure 2
+
+ JN also needs to populate its finger table (for the Chord based DHT).
It issues an Attach to a variety of locations around the overlay.
The diagram below shows it sending an Attach halfway around the Chord
- ring to the JP + 2^127.
+ ring to the JN + 2^127.
- JP NP XX TP
+ JN NP XX TP
| | | |
| | | |
| | | |
- |Attach JP+2<<126 | |
+ |Attach JN+2<<126 | |
|-------->| | |
| | | |
| | | |
- | |Attach JP+2<<126 |
+ | |Attach JN+2<<126 |
| |-------->| |
| | | |
| | | |
- | | |Attach JP+2<<126
+ | | |Attach JN+2<<126
| | |-------->|
| | | |
| | | |
| | |AttachAns|
| | |<--------|
| | | |
| | | |
| |AttachAns| |
| |<--------| |
| | | |
| | | |
|AttachAns| | |
|<--------| | |
| | | |
+ |ICE | | |
+ |<===========================>|
| | | |
|TLS | | |
- |.............................|
- | | | |
- | | | |
+ |<...........................>|
| | | |
| | | |
- Once JP has a reasonable set of connections, it is ready to take its
+ Figure 3
+
+ Once JN has a reasonable set of connections, it is ready to take its
place in the DHT. It does this by sending a Join to AP. AP does a
- series of Store requests to JP to store the data that JP will be
- responsible for. AP then sends JP an Update explicitly labeling JP
- as its predecessor. At this point, JP is part of the ring and
+ series of Store requests to JN to store the data that JN will be
+ responsible for. AP then sends JN an Update explicitly labeling JN
+ as its predecessor. At this point, JN is part of the ring and
responsible for a section of the overlay. AP can now forget any data
- which is assigned to JP and not AP.
+ which is assigned to JN and not AP.
- JP PPP PP AP NP NNP BP
+ JN PPP PP AP NP NNP BP
| | | | | | |
| | | | | | |
| | | | | | |
|JoinReq | | | | | |
|---------------------------->| | | |
| | | | | | |
| | | | | | |
|JoinAns | | | | | |
|<----------------------------| | | |
| | | | | | |
@@ -6163,28 +6334,30 @@
|<----------------------------| | | |
| | | | | | |
| | | | | | |
|UpdateAns| | | | | |
|---------------------------->| | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
- In Chord, JP's neighbor table needs to contain its own predecessors.
+ Figure 4
+
+ In Chord, JN's neighbor table needs to contain its own predecessors.
It couldn't connect to them previously because it did not yet know
their addresses. However, now that it has received an Update from
- AP, it has AP's predecessors, which are also its own, so it sends
- Attaches to them. Below it is shown connecting to AP's closest
- predecessor, PP.
+ AP, as in the previous diagram, it has AP's predecessors, which are
+ also its own, so it sends Attaches to them. Below it is shown
+ connecting only to AP's closest predecessor, PP.
- JP PPP PP AP NP NNP BP
+ JN PPP PP AP NP NNP BP
| | | | | | |
| | | | | | |
| | | | | | |
|Attach Dest=PP | | | | |
|---------------------------->| | | |
| | | | | | |
| | | | | | |
| | |Attach Dest=PP | | |
| | |<--------| | | |
| | | | | | |
@@ -6218,41 +6391,44 @@
| | | | | | |
| | | | | | |
|UpdateReq| | | | | |
|-------------------------------------->| | |
| | | | | | |
| | | | | | |
|UpdateAns| | | | | |
|<--------------------------------------| | |
| | | | | | |
| | | | | | |
+ Figure 5
- Finally, now that JP has a copy of all the data and is ready to route
+ Finally, now that JN has a copy of all the data and is ready to route
messages and receive requests, it sends Updates to everyone in its
Routing Table to tell them it is ready to go. Below, it is shown
sending such an update to TP.
- JP NP XX TP
+ JN NP XX TP
| | | |
| | | |
| | | |
|Update | | |
|---------------------------->|
| | | |
| | | |
|UpdateAns| | |
|<----------------------------|
| | | |
| | | |
| | | |
| | | |
+ Figure 6
+
13. Security Considerations
13.1. Overview
RELOAD provides a generic storage service, albeit one designed to be
useful for P2PSIP. In this section we discuss security issues that
are likely to be relevant to any usage of RELOAD. More background
information can be found in [RFC5765].
In any Overlay Instance, any given user depends on a number of peers
@@ -6282,54 +6458,54 @@
P2P overlays are subject to attacks by subversive nodes that may
attempt to disrupt routing, corrupt or remove user registrations, or
eavesdrop on signaling. The certificate-based security algorithms we
describe in this specification are intended to protect overlay
routing and user registration information in RELOAD messages.
To protect the signaling from attackers pretending to be valid nodes
(or nodes other than themselves), the first requirement is to ensure
that all messages are received from authorized members of the
- overlay. For this reason, RELOAD transports all messages over a
+ overlay. For this reason, RELOAD MUST transport all messages over a
secure channel (TLS and DTLS are defined in this document) which
provides message integrity and authentication of the directly
- communicating peer. In addition, messages and data are digitally
+ communicating peer. In addition, messages and data MUST be digitally
signed with the sender's private key, providing end-to-end security
for communications.
13.3. Certificate-based Security
This specification stores users' registrations and possibly other
data in an overlay network. This requires a solution to securing
this data as well as securing, as well as possible, the routing in
the overlay. Both types of security are based on requiring that
every entity in the system (whether user or peer) authenticate
cryptographically using an asymmetric key pair tied to a certificate.
When a user enrolls in the Overlay Instance, they request or are
assigned a unique name, such as "alice@dht.example.net". These names
- are unique and are meant to be chosen and used by humans much like a
- SIP Address of Record (AOR) or an email address. The user is also
- assigned one or more Node-IDs by the central enrollment authority.
- Both the name and the Node-IDs are placed in the certificate, along
- with the user's public key.
+ MUST be unique and are meant to be chosen and used by humans much
+ like a SIP Address of Record (AOR) or an email address. The user
+ MUST also be assigned one or more Node-IDs by the central enrollment
+ authority. Both the name and the Node-IDs are placed in the
+ certificate, along with the user's public key.
Each certificate enables an entity to act in two sorts of roles:
o As a user, storing data at specific Resource-IDs in the Overlay
Instance corresponding to the user name.
o As a overlay peer with the Node-ID(s) listed in the certificate.
Note that since only users of this Overlay Instance need to validate
a certificate, this usage does not require a global PKI. Instead,
- certificates are signed by a central enrollment authority which acts
- as the certificate authority for the Overlay Instance. This
+ certificates MUST be signed by a central enrollment authority which
+ acts as the certificate authority for the Overlay Instance. This
authority signs each node's certificate. Because each node possesses
the CA's certificate (which they receive on enrollment) they can
verify the certificates of the other entities in the overlay without
further communication. Because the certificates contain the user/
node's public key, communications from the user/node can be verified
in turn.
If self-signed certificates are used, then the security provided is
significantly decreased, since attackers can mount Sybil attacks. In
addition, attackers cannot trust the user names in certificates
@@ -6340,42 +6516,41 @@
are trusted. Some additional security can be provided by using the
shared secret admission control scheme as well.
Because all stored data is signed by the owner of the data the
storing node can verify that the storer is authorized to perform a
store at that Resource-ID and also allow any consumer of the data to
verify the provenance and integrity of the data when it retrieves it.
Note that RELOAD does not itself provide a revocation/status
mechanism (though certificates may of course include OCSP responder
- information). Thus, certificate lifetimes should be chosen to
+ information). Thus, certificate lifetimes SHOULD be chosen to
balance the compromise window versus the cost of certificate renewal.
Because RELOAD is already designed to operate in the face of some
fraction of malicious nodes, this form of compromise is not fatal.
All implementations MUST implement certificate-based security.
13.4. Shared-Secret Security
RELOAD also supports a shared secret admission control scheme that
relies on a single key that is shared among all members of the
overlay. It is appropriate for small groups that wish to form a
private network without complexity. In shared secret mode, all the
- peers share a single symmetric key which is used to key TLS-PSK
- [RFC4279] or TLS-SRP [RFC5054] mode. A peer which does not know the
- key cannot form TLS connections with any other peer and therefore
- cannot join the overlay.
+ peers MUST share a single symmetric key which is used to key TLS-PSK
+ or TLS-SRP mode. A peer which does not know the key cannot form TLS
+ connections with any other peer and therefore cannot join the
+ overlay.
One natural approach to a shared-secret scheme is to use a user-
entered password as the key. The difficulty with this is that in
TLS-PSK mode, such keys are very susceptible to dictionary attacks.
-
If passwords are used as the source of shared-keys, then TLS-SRP is a
superior choice because it is not subject to dictionary attacks.
13.5. Storage Security
When certificate-based security is used in RELOAD, any given
Resource-ID/Kind-ID pair is bound to some small set of certificates.
In order to write data, the writer must prove possession of the
private key for one of those certificates. Moreover, all data is
stored, signed with the same private key that was used to authorize
@@ -6378,27 +6553,27 @@
Resource-ID/Kind-ID pair is bound to some small set of certificates.
In order to write data, the writer must prove possession of the
private key for one of those certificates. Moreover, all data is
stored, signed with the same private key that was used to authorize
the storage. This set of rules makes questions of authorization and
data integrity - which have historically been thorny for overlays -
relatively simple.
13.5.1. Authorization
- When a node wants to store some value, it first digitally signs the
- value with its own private key. It then sends a Store request that
- contains both the value and the signature towards the storing peer
- (which is defined by the Resource Name construction algorithm for
- that particular Kind of value).
+ When a node wants to store some value, it MUST first digitally sign
+ the value with its own private key. It then sends a Store request
+ that contains both the value and the signature towards the storing
+ peer (which is defined by the Resource Name construction algorithm
+ for that particular Kind of value).
- When the storing peer receives the request, it must determine whether
+ When the storing peer receives the request, it MUST determine whether
the storing node is authorized to store at this Resource-ID/Kind-ID
pair. Determining this requires comparing the user's identity to the
requirements of the access control model (see Section 7.3). If it
satisfies those requirements the user is authorized to write, pending
quota checks as described in the next section.
For example, consider the certificate with the following properties:
User name: alice@dht.example.com
Node-ID: 013456789abcdef
@@ -6438,26 +6613,26 @@
13.5.3. Correctness
Because each stored value is signed, it is trivial for any retrieving
node to verify the integrity of the stored value. Some more care
needs to be taken to prevent version rollback attacks. Rollback
attacks on storage are prevented by the use of store times and
lifetime values in each store. A lifetime represents the latest time
at which the data is valid and thus limits (though does not
completely prevent) the ability of the storing node to perform a
rollback attack on retrievers. In order to prevent a rollback attack
- at the time of the Store request, we require that storage times be
- monotonically increasing. Storing peers MUST reject Store requests
- with storage times smaller than or equal to those they are currently
- storing. In addition, a fetching node which receives a data value
- with a storage time older than the result of the previous fetch knows
- a rollback has occurred.
+ at the time of the Store request, it is REQUIRED that storage times
+ be monotonically increasing. Storing peers MUST reject Store
+ requests with storage times smaller than or equal to those they are
+ currently storing. In addition, a fetching node which receives a
+ data value with a storage time older than the result of the previous
+ fetch knows a rollback has occurred.
13.5.4. Residual Attacks
The mechanisms described here provides a high degree of security, but
some attacks remain possible. Most simply, it is possible for
storing peers to refuse to store a value (i.e., reject any request).
In addition, a storing peer can deny knowledge of values which it has
previously accepted. To some extent these attacks can be ameliorated
by attempting to store to/retrieve from replicas, but a retrieving
node does not know whether it should try this or not, since there is
@@ -6511,39 +6686,39 @@
certificate-based admission control.
13.6.2. Admissions Control
Admission to a RELOAD Overlay Instance is controlled by requiring
that each peer have a certificate containing its Node-ID. The
requirement to have a certificate is enforced by using certificate-
based mutual authentication on each connection. (Note: the
following only applies when self-signed certificates are not used.)
Whenever a peer connects to another peer, each side automatically
- checks that the other has a suitable certificate. These Node-IDs are
- randomly assigned by the central enrollment server. This has two
- benefits:
+ checks that the other has a suitable certificate. These Node-IDs
+ MUST be randomly assigned by the central enrollment server. This has
+ two benefits:
o It allows the enrollment server to limit the number of Node-IDs
issued to any individual user.
o It prevents the attacker from choosing specific Node-IDs.
The first property allows protection against Sybil attacks (provided
the enrollment server uses strict rate limiting policies). The
second property deters but does not completely prevent Eclipse
attacks. Because an Eclipse attacker must impersonate peers on the
- other side of the attacker, he must have a certificate for suitable
- Node-IDs, which requires him to repeatedly query the enrollment
- server for new certificates, which will match only by chance. From
- the attacker's perspective, the difficulty is that if he only has a
- small number of certificates, the region of the Overlay Instance he
- is impersonating appears to be very sparsely populated by comparison
- to the victim's local region.
+ other side of the attacker, the attacker must have a certificate for
+ suitable Node-IDs, which requires him to repeatedly query the
+ enrollment server for new certificates, which will match only by
+ chance. From the attacker's perspective, the difficulty is that if
+ the attacker only has a small number of certificates, the region of
+ the Overlay Instance he is impersonating appears to be very sparsely
+ populated by comparison to the victim's local region.
13.6.3. Peer Identification and Authentication
In general, whenever a peer engages in overlay activity that might
affect the routing table it must establish its identity. This
happens in two ways. First, whenever a peer establishes a direct
connection to another peer it authenticates via certificate-based
mutual authentication. All messages between peers are sent over this
protected channel and therefore the peers can verify the data origin
of the last hop peer for requests and responses without further
@@ -6664,22 +6839,23 @@
| Port Number | 6084 |
| Service Name | reload-config |
| Description | Peer to Peer Infrastructure |
| | Configuration |
+-----------------------------+-------------------------------------+
14.3. Overlay Algorithm Types
IANA SHALL create a "RELOAD Overlay Algorithm Type" Registry.
Entries in this registry are strings denoting the names of overlay
- algorithms. The registration policy for this registry is RFC 5226
- IETF Review. The initial contents of this registry are:
+ algorithms as described in Section 11.1. The registration policy for
+ this registry is RFC 5226 IETF Review. The initial contents of this
+ registry are:
+----------------+----------+
| Algorithm Name | RFC |
+----------------+----------+
| CHORD-RELOAD | RFC-AAAA |
| EXP-OVERLAY | RFC-AAAA |
+----------------+----------+
The value EXP-OVERLAY has been made available for the purposes of
experimentation. This value is not meant for vendor specific use of
@@ -6703,64 +6879,65 @@
| EXP-MATCH | RFC-AAAA |
+-----------------+----------+
The value EXP-MATCH has been made available for the purposes of
experimentation. This value is not meant for vendor specific use of
any sort and it MUST NOT be used for operational deployments.
14.5. Application-ID
IANA SHALL create a "RELOAD Application-ID" Registry. Entries in
- this registry are 16-bit integers denoting application Kinds. Code
- points in the range 0x0001 to 0x7fff SHALL be registered via RFC 5226
- Standards Action. Code points in the range 0x8000 to 0xf000 SHALL be
- registered via RFC 5226 Expert Review. Code points in the range
- 0xf001 to 0xfffe are reserved for private use. The initial contents
- of this registry are:
+ this registry are 16-bit integers denoting application-ids as
+ described in Section 6.5.2. Code points in the range 0x0001 to
+ 0x7fff SHALL be registered via RFC 5226 Standards Action. Code
+ points in the range 0x8000 to 0xf000 SHALL be registered via RFC 5226
+ Expert Review. Code points in the range 0xf001 to 0xfffe are
+ reserved for private use. The initial contents of this registry are:
+-------------+----------------+-------------------------------+
| Application | Application-ID | Specification |
+-------------+----------------+-------------------------------+
| INVALID | 0 | RFC-AAAA |
| SIP | 5060 | Reserved for use by SIP Usage |
| SIP | 5061 | Reserved for use by SIP Usage |
| Reserved | 0xffff | RFC-AAAA |
+-------------+----------------+-------------------------------+
14.6. Data Kind-ID
IANA SHALL create a "RELOAD Data Kind-ID" Registry. Entries in this
registry are 32-bit integers denoting data Kinds, as described in
- Section 5.2. Code points in the range 0x00000001 to 0x7fffffff SHALL
+ Section 4.2. Code points in the range 0x00000001 to 0x7fffffff SHALL
be registered via RFC 5226 Standards Action. Code points in the
range 0x8000000 to 0xf0000000 SHALL be registered via RFC 5226 Expert
Review. Code points in the range 0xf0000001 to 0xfffffffe are
reserved for private use via the Kind description mechanism described
in Section 11. The initial contents of this registry are:
+---------------------+------------+----------+
| Kind | Kind-ID | RFC |
+---------------------+------------+----------+
| INVALID | 0 | RFC-AAAA |
| TURN-SERVICE | 2 | RFC-AAAA |
| CERTIFICATE_BY_NODE | 3 | RFC-AAAA |
| CERTIFICATE_BY_USER | 16 | RFC-AAAA |
| Reserved | 0x7fffffff | RFC-AAAA |
| Reserved | 0xfffffffe | RFC-AAAA |
+---------------------+------------+----------+
14.7. Data Model
IANA SHALL create a "RELOAD Data Model" Registry. Entries in this
- registry denoting data models, as described in Section 7.2. Code
- points in this registry SHALL be registered via RFC 5226 Standards
- Action. The initial contents of this registry are:
+ registry are strings denoting data models, as described in
+ Section 7.2. Code points in this registry SHALL be registered via
+ RFC 5226 Standards Action. The initial contents of this registry
+ are:
+------------+----------+
| Data Model | RFC |
+------------+----------+
| INVALID | RFC-AAAA |
| SINGLE | RFC-AAAA |
| ARRAY | RFC-AAAA |
| DICTIONARY | RFC-AAAA |
| EXP-DATA | RFC-AAAA |
| RESERVED | RFC-AAAA |
@@ -6773,21 +6950,21 @@
14.8. Message Codes
IANA SHALL create a "RELOAD Message Code" Registry. Entries in this
registry are 16-bit integers denoting method codes as described in
Section 6.3.3. These codes SHALL be registered via RFC 5226
Standards Action. The initial contents of this registry are:
+---------------------------------+----------------+----------+
| Message Code Name | Code Value | RFC |
+---------------------------------+----------------+----------+
- | invalid | 0 | RFC-AAAA |
+ | invalidMessageCode | 0 | RFC-AAAA |
| probe_req | 1 | RFC-AAAA |
| probe_ans | 2 | RFC-AAAA |
| attach_req | 3 | RFC-AAAA |
| attach_ans | 4 | RFC-AAAA |
| unused | 5 | |
| unused | 6 | |
| store_req | 7 | RFC-AAAA |
| store_ans | 8 | RFC-AAAA |
| fetch_req | 9 | RFC-AAAA |
| fetch_ans | 10 | RFC-AAAA |
@@ -6824,28 +7001,28 @@
+---------------------------------+----------------+----------+
The values exp_a_req, exp_a_ans, exp_b_req, and exp_b_ans have been
made available for the purposes of experimentation. These values are
not meant for vendor specific use of any sort and MUST NOT be used
for operational deployments.
14.9. Error Codes
IANA SHALL create a "RELOAD Error Code" Registry. Entries in this
- registry are 16-bit integers denoting error codes. New entries SHALL
- be defined via RFC 5226 Standards Action. The initial contents of
- this registry are:
+ registry are 16-bit integers denoting error codes as described in
+ Section 6.3.3.1. New entries SHALL be defined via RFC 5226 Standards
+ Action. The initial contents of this registry are:
+-------------------------------------+----------------+----------+
| Error Code Name | Code Value | RFC |
+-------------------------------------+----------------+----------+
- | invalid | 0 | RFC-AAAA |
+ | invalidErrorCode | 0 | RFC-AAAA |
| Unused | 1 | RFC-AAAA |
| Error_Forbidden | 2 | RFC-AAAA |
| Error_Not_Found | 3 | RFC-AAAA |
| Error_Request_Timeout | 4 | RFC-AAAA |
| Error_Generation_Counter_Too_Low | 5 | RFC-AAAA |
| Error_Incompatible_with_Overlay | 6 | RFC-AAAA |
| Error_Unsupported_Forwarding_Option | 7 | RFC-AAAA |
| Error_Data_Too_Large | 8 | RFC-AAAA |
| Error_Data_Too_Old | 9 | RFC-AAAA |
| Error_TTL_Exceeded | 10 | RFC-AAAA |
@@ -6863,122 +7040,126 @@
+-------------------------------------+----------------+----------+
The values Error_Exp_A and Error_Exp_B have been made available for
the purposes of experimentation. These values are not meant for
vendor specific use of any sort and MUST NOT be used for operational
deployments.
14.10. Overlay Link Types
IANA SHALL create a "RELOAD Overlay Link Registry". For more
- information on the link types defeind here, see Section 6.6. New
+ information on the link types defined here, see Section 6.6. New
entries SHALL be defined via RFC 5226 Standards Action. This
registry SHALL be initially populated with the following values:
+--------------------+------+---------------+
| Protocol | Code | Specification |
+--------------------+------+---------------+
- | reserved | 0 | RFC-AAAA |
+ | INVALID-PROTOCOL | 0 | RFC-AAAA |
| DTLS-UDP-SR | 1 | RFC-AAAA |
| DTLS-UDP-SR-NO-ICE | 3 | RFC-AAAA |
| TLS-TCP-FH-NO-ICE | 4 | RFC-AAAA |
| EXP-LINK | 5 | RFC-AAAA |
| reserved | 255 | RFC-AAAA |
+--------------------+------+---------------+
The value EXP-LINK has been made available for the purposes of
experimentation. This 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 SHALL create an "Overlay Link Protocol Registry". Entries in
- this registry SHALL be defined via RFC 5226 Standards Action. This
- registry SHALL be initially populated with the following valuse:
+ this registry are strings denoting protocols as described in
+ Section 11.1 and SHALL be defined via RFC 5226 Standards Action.
+ This registry SHALL be initially populated with the following values:
+---------------+---------------+
| Link Protocol | Specification |
+---------------+---------------+
| TLS | RFC-AAAA |
| EXP-PROTOCOL | RFC-AAAA |
+---------------+---------------+
The value EXP-PROTOCOL has been made available for the purposes of
experimentation. This value is not meant for vendor specific use of
any sort and it MUST NOT be used for operational deployments.
14.12. Forwarding Options
IANA SHALL create a "Forwarding Option Registry". Entries in this
- registry between 1 and 127 SHALL be defined via RFC 5226 Standards
- Action. Entries in this registry between 128 and 254 SHALL be
- defined via RFC 5226 Specification Required. This registry SHALL be
- initially populated with the following values:
+ registry are 8-bit integer denoting options as described in
+ Section 6.3.2.3. Values between 1 and 127 SHALL be defined via RFC
+ 5226 Standards Action. Entries in this registry between 128 and 254
+ SHALL be defined via RFC 5226 Specification Required. This registry
+ SHALL be initially populated with the following values:
- +-------------------+------+---------------+
+ +-------------------------+------+---------------+
| Forwarding Option | Code | Specification |
- +-------------------+------+---------------+
- | invalid | 0 | RFC-AAAA |
+ +-------------------------+------+---------------+
+ | invalidForwardingOption | 0 | RFC-AAAA |
| exp-forward | 1 | RFC-AAAA |
| reserved | 255 | RFC-AAAA |
- +-------------------+------+---------------+
+ +-------------------------+------+---------------+
The value exp-forward has been made available for the purposes of
experimentation. This 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 SHALL create a "RELOAD Probe Information Type Registry".
- Entries in this registry SHALL be defined via RFC 5226 Standards
- Action. This registry SHALL be initially populated with the
- following values:
+ Entries are 8-bit integers denoting types as described in
+ Section 6.4.2.5.1 and SHALL be defined via RFC 5226 Standards Action.
+ This registry SHALL be initially populated with the following values:
- +-----------------+------+---------------+
+ +--------------------+------+---------------+
| Probe Option | Code | Specification |
- +-----------------+------+---------------+
- | invalid | 0 | RFC-AAAA |
+ +--------------------+------+---------------+
+ | invalidProbeOption | 0 | RFC-AAAA |
| responsible_set | 1 | RFC-AAAA |
| num_resources | 2 | RFC-AAAA |
| uptime | 3 | RFC-AAAA |
| exp-probe | 4 | RFC-AAAA |
| reserved | 255 | RFC-AAAA |
- +-----------------+------+---------------+
+ +--------------------+------+---------------+
The value exp-probe has been made available for the purposes of
experimentation. This value is not meant for vendor specific use of
any sort and it MUST NOT be used for operational deployments.
14.14. Message Extensions
IANA SHALL create a "RELOAD Extensions Registry". Entries in this
- registry SHALL be defined via RFC 5226 Specification Required. This
- registry SHALL be initially populated with the following values:
+ registry are 8-bit integers denoting extensions as described in
+ Section 6.3.3 and SHALL be defined via RFC 5226 Specification
+ Required. This registry SHALL be initially populated with the
+ following values:
- +-----------------+--------+---------------+
+ +-----------------------------+--------+---------------+
| Extensions Name | Code | Specification |
- +-----------------+--------+---------------+
- | invalid | 0 | RFC-AAAA |
+ +-----------------------------+--------+---------------+
+ | invalidMessageExtensionType | 0 | RFC-AAAA |
| exp-ext | 1 | RFC-AAAA |
| reserved | 0xFFFF | RFC-AAAA |
- +-----------------+--------+---------------+
+ +-----------------------------+--------+---------------+
The value exp-ext has been made available for the purposes of
experimentation. This 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.
+ o A peer, e.g. as used in a certificate (see Section 11.3).
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
@@ -7055,37 +7244,37 @@
consideration beyond those identified for application/xml in
[RFC3023].
Published specification: RFC-AAAA
Applications that use this media type: The type is used to configure
the peer to peer overlay networks defined in RFC-AAAA.
Additional information: The syntax for this media type is specified
in Section 11.1 of RFC-AAAA. The contents MUST be valid XML
- compliant with the relax NG grammar specified in RFC-AAAA and use the
+ compliant with the RELAX NG grammar specified in RFC-AAAA and 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
+ Jennings
Intended usage: COMMON
Restrictions on usage: None
- Author: Cullen Jennings
+ Author: Cullen Jennings
Change controller: IESG
14.17. XML Name Space Registration
This document registers two URIs for the config and config-chord XML
namespaces in the IETF XML registry defined in [RFC3688].
14.17.1. Config URL
@@ -7122,38 +7311,47 @@
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, and David Bryan. Special thanks to
Marc Petit-Huguenin who provided an amazing amount of detailed
review.
-16. References
+ Dean Willis and Marc Petit-Huguenin help resolve and provided text to
+ fix many comments received during IESG review.
+16. References
16.1. Normative References
+ [OASIS.relax_ng]
+ Bray, T. and M. Murata, "RELAX NG Specification".
+
[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.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
@@ -7213,42 +7411,48 @@
[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,
+ .
+
[w3c-xml-namespaces]
Bray, T., Hollander, D., Layman, A., Tobin, R., and Henry
S. , "Namespaces in XML 1.0 (Third Edition)".
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.
[Eclipse] Singh, A., Ngan, T., Druschel, T., and D. Wallach,
"Eclipse Attacks on Overlay Networks: Threats and
Defenses", INFOCOM 2006, April 2006.
[I-D.ietf-hip-reload-instance]
Keranen, A., Camarillo, G., and J. Maenpaa, "Host Identity
Protocol-Based Overlay Networking Environment (HIP BONE)
Instance Specification for REsource LOcation And Discovery
- (RELOAD)", draft-ietf-hip-reload-instance-05 (work in
- progress), April 2012.
+ (RELOAD)", draft-ietf-hip-reload-instance-06 (work in
+ progress), November 2012.
[I-D.ietf-p2psip-diagnostics]
Song, H., Jiang, X., Even, R., and D. Bryan, "P2PSIP
Overlay Diagnostics", draft-ietf-p2psip-diagnostics-09
(work in progress), August 2012.
[I-D.ietf-p2psip-rpr]
Zong, N., Jiang, X., Even, R., and Y. Zhang, "An extension
to RELOAD to support Relay Peer Routing",
draft-ietf-p2psip-rpr-03 (work in progress), October 2012.
@@ -7259,45 +7463,58 @@
And Discovery (RELOAD)", draft-ietf-p2psip-self-tuning-06
(work in progress), July 2012.
[I-D.ietf-p2psip-service-discovery]
Maenpaa, J. and G. Camarillo, "Service Discovery Usage for
REsource LOcation And Discovery (RELOAD)",
draft-ietf-p2psip-service-discovery-06 (work in progress),
October 2012.
[I-D.ietf-p2psip-sip]
- Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
- H. Schulzrinne, "A SIP Usage for RELOAD",
- draft-ietf-p2psip-sip-07 (work in progress), January 2012.
+ Jennings, C., Lowekamp, B., Rescorla, E., Baset, S.,
+ Schulzrinne, H., and T. Schmidt, "A SIP Usage for RELOAD",
+ draft-ietf-p2psip-sip-08 (work in progress),
+ December 2012.
+
+ [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.
@@ -7365,20 +7582,27 @@
[vulnerabilities-acsac04]
Srivatsa, M. and L. Liu, "Vulnerabilities and Security
Threats in Structured Peer-to-Peer Systems: A Quantitative
Analysis", ACSAC 2004.
[wikiChord]
Wikipedia, "Chord (peer-to-peer)",
.
+ [wikiKBR] Wikipedia, "Key-based routing",
+ .
+
+ [wikiSkiplist]
+ Wikipedia, "Skip list",
+ .
+
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
@@ -7573,25 +7798,24 @@
Application-level support for clients is defined by a usage. A usage
offering support for application-level clients should specify how the
security of the system is maintained when the data is moved between
the application and RELOAD layers.
Authors' Addresses
Cullen Jennings
Cisco
170 West Tasman Drive
- MS: SJC-21/2
+ MS: SJC-30/2
San Jose, CA 95134
USA
- Phone: +1 408 421-9990
Email: fluffy@cisco.com
Bruce B. Lowekamp (editor)
Skype
Palo Alto, CA
USA
Email: bbl@lowekamp.net
Eric Rescorla