draft-ietf-p2psip-base-18.txt   draft-ietf-p2psip-base-19.txt 
P2PSIP C. Jennings P2PSIP C. Jennings
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track B. Lowekamp, Ed. Intended status: Standards Track B. Lowekamp, Ed.
Expires: February 4, 2012 Skype Expires: May 1, 2012 Skype
E. Rescorla E. Rescorla
RTFM, Inc. RTFM, Inc.
S. Baset S. Baset
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
August 3, 2011 October 29, 2011
REsource LOcation And Discovery (RELOAD) Base Protocol REsource LOcation And Discovery (RELOAD) Base Protocol
draft-ietf-p2psip-base-18 draft-ietf-p2psip-base-19
Abstract Abstract
NOTE: This version address some, but not all, of the comments
received during IESG review. The authors are still working on
addressing many more of the comments but as the draft deadline for
IETF 82 arrives, this represents the modification made so far.
This specification defines REsource LOcation And Discovery (RELOAD), This specification defines REsource LOcation And Discovery (RELOAD),
a peer-to-peer (P2P) signaling protocol for use on the Internet. A a peer-to-peer (P2P) signaling protocol for use on the Internet. A
P2P signaling protocol provides its clients with an abstract storage P2P signaling protocol provides its clients with an abstract storage
and messaging service between a set of cooperating peers that form and messaging service between a set of cooperating peers that form
the overlay network. RELOAD is designed to support a P2P Session the overlay network. RELOAD is designed to support a P2P Session
Initiation Protocol (P2PSIP) network, but can be utilized by other Initiation Protocol (P2PSIP) network, but can be utilized by other
applications with similar requirements by defining new usages that 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 must be stored for a particular
application. RELOAD defines a security model based on a certificate application. RELOAD defines a security model based on a certificate
enrollment service that provides unique identities. NAT traversal is enrollment service that provides unique identities. NAT traversal is
skipping to change at page 1, line 48 skipping to change at page 2, line 7
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 4, 2012. This Internet-Draft will expire on May 1, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 12 skipping to change at page 3, line 12
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1. Basic Setting . . . . . . . . . . . . . . . . . . . . . 9 1.1. Basic Setting . . . . . . . . . . . . . . . . . . . . . 9
1.2. Architecture . . . . . . . . . . . . . . . . . . . . . . 10 1.2. Architecture . . . . . . . . . . . . . . . . . . . . . . 10
1.2.1. Usage Layer . . . . . . . . . . . . . . . . . . . . 13 1.2.1. Usage Layer . . . . . . . . . . . . . . . . . . . . 13
1.2.2. Message Transport . . . . . . . . . . . . . . . . . 14 1.2.2. Message Transport . . . . . . . . . . . . . . . . . 14
1.2.3. Storage . . . . . . . . . . . . . . . . . . . . . . 14 1.2.3. Storage . . . . . . . . . . . . . . . . . . . . . . 15
1.2.4. Topology Plugin . . . . . . . . . . . . . . . . . . 15 1.2.4. Topology Plugin . . . . . . . . . . . . . . . . . . 15
1.2.5. Forwarding and Link Management Layer . . . . . . . . 15 1.2.5. Forwarding and Link Management Layer . . . . . . . . 16
1.3. Security . . . . . . . . . . . . . . . . . . . . . . . . 16 1.3. Security . . . . . . . . . . . . . . . . . . . . . . . . 17
1.4. Structure of This Document . . . . . . . . . . . . . . . 17 1.4. Structure of This Document . . . . . . . . . . . . . . . 18
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 17 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 18
3. Overlay Management Overview . . . . . . . . . . . . . . . . . 20 3. Overlay Management Overview . . . . . . . . . . . . . . . . . 21
3.1. Security and Identification . . . . . . . . . . . . . . 20 3.1. Security and Identification . . . . . . . . . . . . . . 21
3.1.1. Shared-Key Security . . . . . . . . . . . . . . . . 21 3.1.1. Shared-Key Security . . . . . . . . . . . . . . . . 22
3.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . 21 3.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.1. Client Routing . . . . . . . . . . . . . . . . . . . 22 3.2.1. Client Routing . . . . . . . . . . . . . . . . . . . 23
3.2.2. Minimum Functionality Requirements for Clients . . . 23 3.2.2. Minimum Functionality Requirements for Clients . . . 24
3.3. Routing . . . . . . . . . . . . . . . . . . . . . . . . 23 3.3. Routing . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4. Connectivity Management . . . . . . . . . . . . . . . . 26 3.4. Connectivity Management . . . . . . . . . . . . . . . . 27
3.5. Overlay Algorithm Support . . . . . . . . . . . . . . . 27 3.5. Overlay Algorithm Support . . . . . . . . . . . . . . . 28
3.5.1. Support for Pluggable Overlay Algorithms . . . . . . 27 3.5.1. Support for Pluggable Overlay Algorithms . . . . . . 28
3.5.2. Joining, Leaving, and Maintenance Overview . . . . . 27 3.5.2. Joining, Leaving, and Maintenance Overview . . . . . 28
3.6. First-Time Setup . . . . . . . . . . . . . . . . . . . . 29 3.6. First-Time Setup . . . . . . . . . . . . . . . . . . . . 30
3.6.1. Initial Configuration . . . . . . . . . . . . . . . 29 3.6.1. Initial Configuration . . . . . . . . . . . . . . . 30
3.6.2. Enrollment . . . . . . . . . . . . . . . . . . . . . 29 3.6.2. Enrollment . . . . . . . . . . . . . . . . . . . . . 30
4. Application Support Overview . . . . . . . . . . . . . . . . 29 4. Application Support Overview . . . . . . . . . . . . . . . . 31
4.1. Data Storage . . . . . . . . . . . . . . . . . . . . . . 30 4.1. Data Storage . . . . . . . . . . . . . . . . . . . . . . 31
4.1.1. Storage Permissions . . . . . . . . . . . . . . . . 31 4.1.1. Storage Permissions . . . . . . . . . . . . . . . . 32
4.1.2. Replication . . . . . . . . . . . . . . . . . . . . 32 4.1.2. Replication . . . . . . . . . . . . . . . . . . . . 33
4.2. Usages . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.2. Usages . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3. Service Discovery . . . . . . . . . . . . . . . . . . . 33 4.3. Service Discovery . . . . . . . . . . . . . . . . . . . 34
4.4. Application Connectivity . . . . . . . . . . . . . . . . 33 4.4. Application Connectivity . . . . . . . . . . . . . . . . 34
5. Overlay Management Protocol . . . . . . . . . . . . . . . . . 33 5. Overlay Management Protocol . . . . . . . . . . . . . . . . . 35
5.1. Message Receipt and Forwarding . . . . . . . . . . . . . 34 5.1. Message Receipt and Forwarding . . . . . . . . . . . . . 35
5.1.1. Responsible ID . . . . . . . . . . . . . . . . . . . 34 5.1.1. Responsible ID . . . . . . . . . . . . . . . . . . . 35
5.1.2. Other ID . . . . . . . . . . . . . . . . . . . . . . 35 5.1.2. Other ID . . . . . . . . . . . . . . . . . . . . . . 36
5.1.3. Private ID . . . . . . . . . . . . . . . . . . . . . 37 5.1.3. Private ID . . . . . . . . . . . . . . . . . . . . . 38
5.2. Symmetric Recursive Routing . . . . . . . . . . . . . . 37 5.2. Symmetric Recursive Routing . . . . . . . . . . . . . . 38
5.2.1. Request Origination . . . . . . . . . . . . . . . . 37 5.2.1. Request Origination . . . . . . . . . . . . . . . . 38
5.2.2. Response Origination . . . . . . . . . . . . . . . . 38 5.2.2. Response Origination . . . . . . . . . . . . . . . . 39
5.3. Message Structure . . . . . . . . . . . . . . . . . . . 38 5.3. Message Structure . . . . . . . . . . . . . . . . . . . 39
5.3.1. Presentation Language . . . . . . . . . . . . . . . 39 5.3.1. Presentation Language . . . . . . . . . . . . . . . 40
5.3.1.1. Common Definitions . . . . . . . . . . . . . . . 39 5.3.1.1. Common Definitions . . . . . . . . . . . . . . . 41
5.3.2. Forwarding Header . . . . . . . . . . . . . . . . . 42 5.3.2. Forwarding Header . . . . . . . . . . . . . . . . . 43
5.3.2.1. Processing Configuration Sequence Numbers . . . . 44 5.3.2.1. Processing Configuration Sequence Numbers . . . . 45
5.3.2.2. Destination and Via Lists . . . . . . . . . . . . 45 5.3.2.2. Destination and Via Lists . . . . . . . . . . . . 46
5.3.2.3. Forwarding Options . . . . . . . . . . . . . . . 47 5.3.2.3. Forwarding Options . . . . . . . . . . . . . . . 48
5.3.3. Message Contents Format . . . . . . . . . . . . . . 48 5.3.3. Message Contents Format . . . . . . . . . . . . . . 49
5.3.3.1. Response Codes and Response Errors . . . . . . . 49 5.3.3.1. Response Codes and Response Errors . . . . . . . 50
5.3.4. Security Block . . . . . . . . . . . . . . . . . . . 51 5.3.4. Security Block . . . . . . . . . . . . . . . . . . . 52
5.4. Overlay Topology . . . . . . . . . . . . . . . . . . . . 55 5.4. Overlay Topology . . . . . . . . . . . . . . . . . . . . 56
5.4.1. Topology Plugin Requirements . . . . . . . . . . . . 55 5.4.1. Topology Plugin Requirements . . . . . . . . . . . . 56
5.4.2. Methods and types for use by topology plugins . . . 55 5.4.2. Methods and types for use by topology plugins . . . 56
5.4.2.1. Join . . . . . . . . . . . . . . . . . . . . . . 55 5.4.2.1. Join . . . . . . . . . . . . . . . . . . . . . . 56
5.4.2.2. Leave . . . . . . . . . . . . . . . . . . . . . . 56 5.4.2.2. Leave . . . . . . . . . . . . . . . . . . . . . . 58
5.4.2.3. Update . . . . . . . . . . . . . . . . . . . . . 57 5.4.2.3. Update . . . . . . . . . . . . . . . . . . . . . 58
5.4.2.4. RouteQuery . . . . . . . . . . . . . . . . . . . 57 5.4.2.4. RouteQuery . . . . . . . . . . . . . . . . . . . 59
5.4.2.5. Probe . . . . . . . . . . . . . . . . . . . . . . 58 5.4.2.5. Probe . . . . . . . . . . . . . . . . . . . . . . 60
5.5. Forwarding and Link Management Layer . . . . . . . . . . 60 5.5. Forwarding and Link Management Layer . . . . . . . . . . 62
5.5.1. Attach . . . . . . . . . . . . . . . . . . . . . . . 61 5.5.1. Attach . . . . . . . . . . . . . . . . . . . . . . . 62
5.5.1.1. Request Definition . . . . . . . . . . . . . . . 61 5.5.1.1. Request Definition . . . . . . . . . . . . . . . 63
5.5.1.2. Response Definition . . . . . . . . . . . . . . . 64 5.5.1.2. Response Definition . . . . . . . . . . . . . . . 66
5.5.1.3. Using ICE With RELOAD . . . . . . . . . . . . . . 65 5.5.1.3. Using ICE With RELOAD . . . . . . . . . . . . . . 67
5.5.1.4. Collecting STUN Servers . . . . . . . . . . . . . 65 5.5.1.4. Collecting STUN Servers . . . . . . . . . . . . . 67
5.5.1.5. Gathering Candidates . . . . . . . . . . . . . . 66 5.5.1.5. Gathering Candidates . . . . . . . . . . . . . . 68
5.5.1.6. Prioritizing Candidates . . . . . . . . . . . . . 66 5.5.1.6. Prioritizing Candidates . . . . . . . . . . . . . 68
5.5.1.7. Encoding the Attach Message . . . . . . . . . . . 67 5.5.1.7. Encoding the Attach Message . . . . . . . . . . . 69
5.5.1.8. Verifying ICE Support . . . . . . . . . . . . . . 67 5.5.1.8. Verifying ICE Support . . . . . . . . . . . . . . 69
5.5.1.9. Role Determination . . . . . . . . . . . . . . . 67 5.5.1.9. Role Determination . . . . . . . . . . . . . . . 70
5.5.1.10. Full ICE . . . . . . . . . . . . . . . . . . . . 68 5.5.1.10. Full ICE . . . . . . . . . . . . . . . . . . . . 70
5.5.1.11. No-ICE . . . . . . . . . . . . . . . . . . . . . 68 5.5.1.11. No-ICE . . . . . . . . . . . . . . . . . . . . . 70
5.5.1.12. Subsequent Offers and Answers . . . . . . . . . . 68 5.5.1.12. Subsequent Offers and Answers . . . . . . . . . . 71
5.5.1.13. Sending Media . . . . . . . . . . . . . . . . . . 69 5.5.1.13. Sending Media . . . . . . . . . . . . . . . . . . 71
5.5.1.14. Receiving Media . . . . . . . . . . . . . . . . . 69 5.5.1.14. Receiving Media . . . . . . . . . . . . . . . . . 71
5.5.2. AppAttach . . . . . . . . . . . . . . . . . . . . . 69 5.5.2. AppAttach . . . . . . . . . . . . . . . . . . . . . 71
5.5.2.1. Request Definition . . . . . . . . . . . . . . . 69 5.5.2.1. Request Definition . . . . . . . . . . . . . . . 71
5.5.2.2. Response Definition . . . . . . . . . . . . . . . 70 5.5.2.2. Response Definition . . . . . . . . . . . . . . . 72
5.5.3. Ping . . . . . . . . . . . . . . . . . . . . . . . . 70 5.5.3. Ping . . . . . . . . . . . . . . . . . . . . . . . . 73
5.5.3.1. Request Definition . . . . . . . . . . . . . . . 71 5.5.3.1. Request Definition . . . . . . . . . . . . . . . 73
5.5.3.2. Response Definition . . . . . . . . . . . . . . . 71 5.5.3.2. Response Definition . . . . . . . . . . . . . . . 73
5.5.4. ConfigUpdate . . . . . . . . . . . . . . . . . . . . 71 5.5.4. ConfigUpdate . . . . . . . . . . . . . . . . . . . . 74
5.5.4.1. Request Definition . . . . . . . . . . . . . . . 72 5.5.4.1. Request Definition . . . . . . . . . . . . . . . 74
5.5.4.2. Response Definition . . . . . . . . . . . . . . . 72 5.5.4.2. Response Definition . . . . . . . . . . . . . . . 75
5.6. Overlay Link Layer . . . . . . . . . . . . . . . . . . . 73 5.6. Overlay Link Layer . . . . . . . . . . . . . . . . . . . 75
5.6.1. Future Overlay Link Protocols . . . . . . . . . . . 74 5.6.1. Future Overlay Link Protocols . . . . . . . . . . . 77
5.6.1.1. HIP . . . . . . . . . . . . . . . . . . . . . . . 75 5.6.1.1. HIP . . . . . . . . . . . . . . . . . . . . . . . 77
5.6.1.2. ICE-TCP . . . . . . . . . . . . . . . . . . . . . 75 5.6.1.2. ICE-TCP . . . . . . . . . . . . . . . . . . . . . 77
5.6.1.3. Message-oriented Transports . . . . . . . . . . . 75 5.6.1.3. Message-oriented Transports . . . . . . . . . . . 78
5.6.1.4. Tunneled Transports . . . . . . . . . . . . . . . 75 5.6.1.4. Tunneled Transports . . . . . . . . . . . . . . . 78
5.6.2. Framing Header . . . . . . . . . . . . . . . . . . . 76 5.6.2. Framing Header . . . . . . . . . . . . . . . . . . . 78
5.6.3. Simple Reliability . . . . . . . . . . . . . . . . . 77 5.6.3. Simple Reliability . . . . . . . . . . . . . . . . . 80
5.6.3.1. Retransmission and Flow Control . . . . . . . . . 78 5.6.3.1. Stop and Wait Sender Algorithm . . . . . . . . . 80
5.6.4. DTLS/UDP with SR . . . . . . . . . . . . . . . . . . 79 5.6.4. DTLS/UDP with SR . . . . . . . . . . . . . . . . . . 81
5.6.5. TLS/TCP with FH, No-ICE . . . . . . . . . . . . . . 79 5.6.5. TLS/TCP with FH, No-ICE . . . . . . . . . . . . . . 82
5.6.6. DTLS/UDP with SR, No-ICE . . . . . . . . . . . . . . 80 5.6.6. DTLS/UDP with SR, No-ICE . . . . . . . . . . . . . . 82
5.7. Fragmentation and Reassembly . . . . . . . . . . . . . . 80 5.7. Fragmentation and Reassembly . . . . . . . . . . . . . . 82
6. Data Storage Protocol . . . . . . . . . . . . . . . . . . . . 81 6. Data Storage Protocol . . . . . . . . . . . . . . . . . . . . 83
6.1. Data Signature Computation . . . . . . . . . . . . . . . 82 6.1. Data Signature Computation . . . . . . . . . . . . . . . 85
6.2. Data Models . . . . . . . . . . . . . . . . . . . . . . 83 6.2. Data Models . . . . . . . . . . . . . . . . . . . . . . 86
6.2.1. Single Value . . . . . . . . . . . . . . . . . . . . 84 6.2.1. Single Value . . . . . . . . . . . . . . . . . . . . 86
6.2.2. Array . . . . . . . . . . . . . . . . . . . . . . . 84 6.2.2. Array . . . . . . . . . . . . . . . . . . . . . . . 87
6.2.3. Dictionary . . . . . . . . . . . . . . . . . . . . . 85 6.2.3. Dictionary . . . . . . . . . . . . . . . . . . . . . 87
6.3. Access Control Policies . . . . . . . . . . . . . . . . 85 6.3. Access Control Policies . . . . . . . . . . . . . . . . 88
6.3.1. USER-MATCH . . . . . . . . . . . . . . . . . . . . . 86 6.3.1. USER-MATCH . . . . . . . . . . . . . . . . . . . . . 88
6.3.2. NODE-MATCH . . . . . . . . . . . . . . . . . . . . . 86 6.3.2. NODE-MATCH . . . . . . . . . . . . . . . . . . . . . 88
6.3.3. USER-NODE-MATCH . . . . . . . . . . . . . . . . . . 86 6.3.3. USER-NODE-MATCH . . . . . . . . . . . . . . . . . . 89
6.3.4. NODE-MULTIPLE . . . . . . . . . . . . . . . . . . . 86 6.3.4. NODE-MULTIPLE . . . . . . . . . . . . . . . . . . . 89
6.4. Data Storage Methods . . . . . . . . . . . . . . . . . . 87 6.4. Data Storage Methods . . . . . . . . . . . . . . . . . . 89
6.4.1. Store . . . . . . . . . . . . . . . . . . . . . . . 87 6.4.1. Store . . . . . . . . . . . . . . . . . . . . . . . 89
6.4.1.1. Request Definition . . . . . . . . . . . . . . . 87 6.4.1.1. Request Definition . . . . . . . . . . . . . . . 89
6.4.1.2. Response Definition . . . . . . . . . . . . . . . 91 6.4.1.2. Response Definition . . . . . . . . . . . . . . . 94
6.4.1.3. Removing Values . . . . . . . . . . . . . . . . . 93 6.4.1.3. Removing Values . . . . . . . . . . . . . . . . . 95
6.4.2. Fetch . . . . . . . . . . . . . . . . . . . . . . . 93 6.4.2. Fetch . . . . . . . . . . . . . . . . . . . . . . . 96
6.4.2.1. Request Definition . . . . . . . . . . . . . . . 94 6.4.2.1. Request Definition . . . . . . . . . . . . . . . 96
6.4.2.2. Response Definition . . . . . . . . . . . . . . . 96 6.4.2.2. Response Definition . . . . . . . . . . . . . . . 98
6.4.3. Stat . . . . . . . . . . . . . . . . . . . . . . . . 97 6.4.3. Stat . . . . . . . . . . . . . . . . . . . . . . . . 99
6.4.3.1. Request Definition . . . . . . . . . . . . . . . 97 6.4.3.1. Request Definition . . . . . . . . . . . . . . . 99
6.4.3.2. Response Definition . . . . . . . . . . . . . . . 97 6.4.3.2. Response Definition . . . . . . . . . . . . . . . 100
6.4.4. Find . . . . . . . . . . . . . . . . . . . . . . . . 99 6.4.4. Find . . . . . . . . . . . . . . . . . . . . . . . . 102
6.4.4.1. Request Definition . . . . . . . . . . . . . . . 99 6.4.4.1. Request Definition . . . . . . . . . . . . . . . 102
6.4.4.2. Response Definition . . . . . . . . . . . . . . . 100 6.4.4.2. Response Definition . . . . . . . . . . . . . . . 103
6.4.5. Defining New Kinds . . . . . . . . . . . . . . . . . 101 6.4.5. Defining New Kinds . . . . . . . . . . . . . . . . . 104
7. Certificate Store Usage . . . . . . . . . . . . . . . . . . . 101 7. Certificate Store Usage . . . . . . . . . . . . . . . . . . . 104
8. TURN Server Usage . . . . . . . . . . . . . . . . . . . . . . 102 8. TURN Server Usage . . . . . . . . . . . . . . . . . . . . . . 105
9. Chord Algorithm . . . . . . . . . . . . . . . . . . . . . . . 104 9. Chord Algorithm . . . . . . . . . . . . . . . . . . . . . . . 107
9.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 105 9.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 108
9.2. Hash Function . . . . . . . . . . . . . . . . . . . . . 105 9.2. Hash Function . . . . . . . . . . . . . . . . . . . . . 108
9.3. Routing . . . . . . . . . . . . . . . . . . . . . . . . 105 9.3. Routing . . . . . . . . . . . . . . . . . . . . . . . . 108
9.4. Redundancy . . . . . . . . . . . . . . . . . . . . . . . 106 9.4. Redundancy . . . . . . . . . . . . . . . . . . . . . . . 109
9.5. Joining . . . . . . . . . . . . . . . . . . . . . . . . 106 9.5. Joining . . . . . . . . . . . . . . . . . . . . . . . . 109
9.6. Routing Attaches . . . . . . . . . . . . . . . . . . . . 107 9.6. Routing Attaches . . . . . . . . . . . . . . . . . . . . 110
9.7. Updates . . . . . . . . . . . . . . . . . . . . . . . . 107 9.7. Updates . . . . . . . . . . . . . . . . . . . . . . . . 110
9.7.1. Handling Neighbor Failures . . . . . . . . . . . . . 109 9.7.1. Handling Neighbor Failures . . . . . . . . . . . . . 112
9.7.2. Handling Finger Table Entry Failure . . . . . . . . 110 9.7.2. Handling Finger Table Entry Failure . . . . . . . . 113
9.7.3. Receiving Updates . . . . . . . . . . . . . . . . . 110 9.7.3. Receiving Updates . . . . . . . . . . . . . . . . . 113
9.7.4. Stabilization . . . . . . . . . . . . . . . . . . . 111 9.7.4. Stabilization . . . . . . . . . . . . . . . . . . . 114
9.7.4.1. Updating neighbor table . . . . . . . . . . . . . 111 9.7.4.1. Updating neighbor table . . . . . . . . . . . . . 114
9.7.4.2. Refreshing finger table . . . . . . . . . . . . . 111 9.7.4.2. Refreshing finger table . . . . . . . . . . . . . 114
9.7.4.3. Adjusting finger table size . . . . . . . . . . . 112 9.7.4.3. Adjusting finger table size . . . . . . . . . . . 115
9.7.4.4. Detecting partitioning . . . . . . . . . . . . . 113 9.7.4.4. Detecting partitioning . . . . . . . . . . . . . 116
9.8. Route query . . . . . . . . . . . . . . . . . . . . . . 113 9.8. Route query . . . . . . . . . . . . . . . . . . . . . . 116
9.9. Leaving . . . . . . . . . . . . . . . . . . . . . . . . 114 9.9. Leaving . . . . . . . . . . . . . . . . . . . . . . . . 117
10. Enrollment and Bootstrap . . . . . . . . . . . . . . . . . . 115 10. Enrollment and Bootstrap . . . . . . . . . . . . . . . . . . 118
10.1. Overlay Configuration . . . . . . . . . . . . . . . . . 115 10.1. Overlay Configuration . . . . . . . . . . . . . . . . . 118
10.1.1. Relax NG Grammar . . . . . . . . . . . . . . . . . . 121 10.1.1. Relax NG Grammar . . . . . . . . . . . . . . . . . . 124
10.2. Discovery Through Configuration Server . . . . . . . . . 123 10.2. Discovery Through Configuration Server . . . . . . . . . 127
10.3. Credentials . . . . . . . . . . . . . . . . . . . . . . 124 10.3. Credentials . . . . . . . . . . . . . . . . . . . . . . 127
10.3.1. Self-Generated Credentials . . . . . . . . . . . . . 125 10.3.1. Self-Generated Credentials . . . . . . . . . . . . . 128
10.4. Searching for a Bootstrap Node . . . . . . . . . . . . . 126 10.4. Searching for a Bootstrap Node . . . . . . . . . . . . . 129
10.5. Contacting a Bootstrap Node . . . . . . . . . . . . . . 126 10.5. Contacting a Bootstrap Node . . . . . . . . . . . . . . 129
11. Message Flow Example . . . . . . . . . . . . . . . . . . . . 127 11. Message Flow Example . . . . . . . . . . . . . . . . . . . . 130
12. Security Considerations . . . . . . . . . . . . . . . . . . . 133 12. Security Considerations . . . . . . . . . . . . . . . . . . . 136
12.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 133 12.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 136
12.2. Attacks on P2P Overlays . . . . . . . . . . . . . . . . 134 12.2. Attacks on P2P Overlays . . . . . . . . . . . . . . . . 137
12.3. Certificate-based Security . . . . . . . . . . . . . . . 134 12.3. Certificate-based Security . . . . . . . . . . . . . . . 137
12.4. Shared-Secret Security . . . . . . . . . . . . . . . . . 135 12.4. Shared-Secret Security . . . . . . . . . . . . . . . . . 138
12.5. Storage Security . . . . . . . . . . . . . . . . . . . . 136 12.5. Storage Security . . . . . . . . . . . . . . . . . . . . 139
12.5.1. Authorization . . . . . . . . . . . . . . . . . . . 136 12.5.1. Authorization . . . . . . . . . . . . . . . . . . . 139
12.5.2. Distributed Quota . . . . . . . . . . . . . . . . . 137 12.5.2. Distributed Quota . . . . . . . . . . . . . . . . . 140
12.5.3. Correctness . . . . . . . . . . . . . . . . . . . . 137 12.5.3. Correctness . . . . . . . . . . . . . . . . . . . . 140
12.5.4. Residual Attacks . . . . . . . . . . . . . . . . . . 137 12.5.4. Residual Attacks . . . . . . . . . . . . . . . . . . 140
12.6. Routing Security . . . . . . . . . . . . . . . . . . . . 138 12.6. Routing Security . . . . . . . . . . . . . . . . . . . . 141
12.6.1. Background . . . . . . . . . . . . . . . . . . . . . 138 12.6.1. Background . . . . . . . . . . . . . . . . . . . . . 141
12.6.2. Admissions Control . . . . . . . . . . . . . . . . . 139 12.6.2. Admissions Control . . . . . . . . . . . . . . . . . 142
12.6.3. Peer Identification and Authentication . . . . . . . 139 12.6.3. Peer Identification and Authentication . . . . . . . 142
12.6.4. Protecting the Signaling . . . . . . . . . . . . . . 140 12.6.4. Protecting the Signaling . . . . . . . . . . . . . . 143
12.6.5. Residual Attacks . . . . . . . . . . . . . . . . . . 140 12.6.5. Residual Attacks . . . . . . . . . . . . . . . . . . 143
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 141 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 144
13.1. Well-Known URI Registration . . . . . . . . . . . . . . 141 13.1. Well-Known URI Registration . . . . . . . . . . . . . . 144
13.2. Port Registrations . . . . . . . . . . . . . . . . . . . 141 13.2. Port Registrations . . . . . . . . . . . . . . . . . . . 144
13.3. Overlay Algorithm Types . . . . . . . . . . . . . . . . 142 13.3. Overlay Algorithm Types . . . . . . . . . . . . . . . . 145
13.4. Access Control Policies . . . . . . . . . . . . . . . . 142 13.4. Access Control Policies . . . . . . . . . . . . . . . . 145
13.5. Application-ID . . . . . . . . . . . . . . . . . . . . . 142 13.5. Application-ID . . . . . . . . . . . . . . . . . . . . . 145
13.6. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . 143 13.6. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . 146
13.7. Data Model . . . . . . . . . . . . . . . . . . . . . . . 143 13.7. Data Model . . . . . . . . . . . . . . . . . . . . . . . 146
13.8. Message Codes . . . . . . . . . . . . . . . . . . . . . 144 13.8. Message Codes . . . . . . . . . . . . . . . . . . . . . 147
13.9. Error Codes . . . . . . . . . . . . . . . . . . . . . . 146 13.9. Error Codes . . . . . . . . . . . . . . . . . . . . . . 149
13.10. Overlay Link Types . . . . . . . . . . . . . . . . . . . 146 13.10. Overlay Link Types . . . . . . . . . . . . . . . . . . . 149
13.11. Overlay Link Protocols . . . . . . . . . . . . . . . . . 147 13.11. Overlay Link Protocols . . . . . . . . . . . . . . . . . 150
13.12. Forwarding Options . . . . . . . . . . . . . . . . . . . 147 13.12. Forwarding Options . . . . . . . . . . . . . . . . . . . 150
13.13. Probe Information Types . . . . . . . . . . . . . . . . 148 13.13. Probe Information Types . . . . . . . . . . . . . . . . 151
13.14. Message Extensions . . . . . . . . . . . . . . . . . . . 148 13.14. Message Extensions . . . . . . . . . . . . . . . . . . . 151
13.15. reload URI Scheme . . . . . . . . . . . . . . . . . . . 148 13.15. reload URI Scheme . . . . . . . . . . . . . . . . . . . 151
13.15.1. URI Registration . . . . . . . . . . . . . . . . . . 149 13.15.1. URI Registration . . . . . . . . . . . . . . . . . . 152
13.16. Media Type Registration . . . . . . . . . . . . . . . . 150 13.16. Media Type Registration . . . . . . . . . . . . . . . . 153
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 151 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 154
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 152 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 155
15.1. Normative References . . . . . . . . . . . . . . . . . . 152 15.1. Normative References . . . . . . . . . . . . . . . . . . 155
15.2. Informative References . . . . . . . . . . . . . . . . . 153 15.2. Informative References . . . . . . . . . . . . . . . . . 156
Appendix A. Routing Alternatives . . . . . . . . . . . . . . . . 156 Appendix A. Routing Alternatives . . . . . . . . . . . . . . . . 159
A.1. Iterative vs Recursive . . . . . . . . . . . . . . . . . 156 A.1. Iterative vs Recursive . . . . . . . . . . . . . . . . . 160
A.2. Symmetric vs Forward response . . . . . . . . . . . . . 157 A.2. Symmetric vs Forward response . . . . . . . . . . . . . 160
A.3. Direct Response . . . . . . . . . . . . . . . . . . . . 157 A.3. Direct Response . . . . . . . . . . . . . . . . . . . . 160
A.4. Relay Peers . . . . . . . . . . . . . . . . . . . . . . 158 A.4. Relay Peers . . . . . . . . . . . . . . . . . . . . . . 162
A.5. Symmetric Route Stability . . . . . . . . . . . . . . . 159 A.5. Symmetric Route Stability . . . . . . . . . . . . . . . 162
Appendix B. Why Clients? . . . . . . . . . . . . . . . . . . . . 160 Appendix B. Why Clients? . . . . . . . . . . . . . . . . . . . . 163
B.1. Why Not Only Peers? . . . . . . . . . . . . . . . . . . 160 B.1. Why Not Only Peers? . . . . . . . . . . . . . . . . . . 163
B.2. Clients as Application-Level Agents . . . . . . . . . . 160 B.2. Clients as Application-Level Agents . . . . . . . . . . 163
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 161 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 164
C.1. Changes since draft-ietf-p2psip-reload-13 . . . . . . . 161
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 161
1. Introduction 1. Introduction
This document defines REsource LOcation And Discovery (RELOAD), a This document defines REsource LOcation And Discovery (RELOAD), a
peer-to-peer (P2P) signaling protocol for use on the Internet. It peer-to-peer (P2P) signaling protocol for use on the Internet. It
provides a generic, self-organizing overlay network service, allowing provides a generic, self-organizing overlay network service, allowing
nodes to efficiently route messages to other nodes and to efficiently nodes to efficiently route messages to other nodes and to efficiently
store and retrieve data in the overlay. RELOAD provides several store and retrieve data in the overlay. RELOAD provides several
features that are critical for a successful P2P protocol for the features that are critical for a successful P2P protocol for the
Internet: Internet:
skipping to change at page 9, line 18 skipping to change at page 9, line 18
protocol for the distributed storage and location service, as well as protocol for the distributed storage and location service, as well as
critical usages for NAT traversal and security. The SIP Usage itself critical usages for NAT traversal and security. The SIP Usage itself
is described separately in [I-D.ietf-p2psip-sip]. RELOAD is not 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 limited to usage by SIP and could serve as a tool for supporting
other P2P applications with similar needs. other P2P applications with similar needs.
1.1. Basic Setting 1.1. Basic Setting
In this section, we provide a brief overview of the operational In this section, we provide a brief overview of the operational
setting for RELOAD. A RELOAD Overlay Instance consists of a set of setting for RELOAD. A RELOAD Overlay Instance consists of a set of
nodes arranged in a connected graph. Each node in the overlay is nodes arranged in a partly connected graph. Each node in the overlay
assigned a numeric Node-ID which, together with the specific overlay is assigned a numeric Node-ID which, together with the specific
algorithm in use, determines its position in the graph and the set of overlay algorithm in use, determines its position in the graph and
nodes it connects to. The figure below shows a trivial example which the set of nodes it connects to. The figure below shows a trivial
isn't drawn from any particular overlay algorithm, but was chosen for example which isn't drawn from any particular overlay algorithm, but
convenience of representation. was chosen for convenience of representation.
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| Node 10|--------------| Node 20|--------------| Node 30| | Node 10|--------------| Node 20|--------------| Node 30|
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| | | | | |
| | | | | |
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| Node 40|--------------| Node 50|--------------| Node 60| | Node 40|--------------| Node 50|--------------| Node 60|
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| | | | | |
skipping to change at page 10, line 8 skipping to change at page 10, line 8
message to another node, it may need to route it through the network. 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 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 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. send it to Node 40 with instructions to pass it along to Node 70.
Different overlay algorithms will have different connectivity graphs, Different overlay algorithms will have different connectivity graphs,
but the general idea behind all of them is to allow any node in the 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 graph to efficiently reach every other node within a small number of
hops. hops.
The RELOAD network is not only a messaging network. It is also a The RELOAD network is not only a messaging network. It is also a
storage network. Records are stored under numeric addresses which storage network, albeit one designed for small-scale storage rather
occupy the same space as node identifiers. Peers are responsible for than for bulk storage of large objects. Records are stored under
storing the data associated with some set of addresses as determined numeric addresses which occupy the same space as node identifiers.
by their Node-ID. For instance, we might say that every peer is Peers are responsible for storing the data associated with some set
responsible for storing any data value which has an address less than of addresses as determined by their Node-ID. For instance, we might
or equal to its own Node-ID, but greater than the next lowest say that every peer is responsible for storing any data value which
Node-ID. Thus, Node-20 would be responsible for storing values has an address less than or equal to its own Node-ID, but greater
11-20. 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 RELOAD also supports clients. These are nodes which have Node-IDs
but do not participate in routing or storage. For instance, in the 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 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 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 and Node 90 is still responsible for all addresses between 81-90. We
refer to non-client nodes as peers. refer to non-client nodes as peers.
Other applications (for instance, SIP) can be defined on top of Other applications (for instance, SIP) can be defined on top of
RELOAD and use these two basic RELOAD services to provide their own RELOAD and use these two basic RELOAD services to provide their own
skipping to change at page 11, line 36 skipping to change at page 11, line 36
| Link Management | | Link Management |
+------------------+ +------------------+
------------------------------------ Overlay Link Service Boundary ------------------------------------ Overlay Link Service Boundary
+-------+ +------+ +-------+ +------+
|TLS | |DTLS | ... |TLS | |DTLS | ...
+-------+ +------+ +-------+ +------+
The major components of RELOAD are: The major components of RELOAD are:
Usage Layer: Each application defines a RELOAD usage; a set of data Usage Layer: Each application defines a RELOAD usage; a set of data
kinds and behaviors which describe how to use the services Kinds and behaviors which describe how to use the services
provided by RELOAD. These usages all talk to RELOAD through a provided by RELOAD. These usages all talk to RELOAD through a
common Message Transport Service. common Message Transport Service.
Message Transport: Handles end-to-end reliability, manages request Message Transport: Handles end-to-end reliability, manages request
state for the usages, and forwards Store and Fetch operations to state for the usages, and forwards Store and Fetch operations to
the Storage component. Delivers message responses to the the Storage component. Delivers message responses to the
component initiating the request. component initiating the request.
Storage: The Storage component is responsible for processing Storage: The Storage component is responsible for processing
messages relating to the storage and retrieval of data. It talks messages relating to the storage and retrieval of data. It talks
skipping to change at page 14, line 4 skipping to change at page 14, line 4
abstract Message Transport Service provided by RELOAD. The goal of abstract Message Transport Service provided by RELOAD. The goal of
this layer is to implement application-specific usages of the generic this layer is to implement application-specific usages of the generic
overlay services provided by RELOAD. The usage defines how a overlay services provided by RELOAD. The usage defines how a
specific application maps its data into something that can be stored specific application maps its data into something that can be stored
in the overlay, where to store the data, how to secure the data, and in the overlay, where to store the data, how to secure the data, and
finally how applications can retrieve and use the data. finally how applications can retrieve and use the data.
The architecture diagram shows both a SIP usage and an XMPP usage. A The architecture diagram shows both a SIP usage and an XMPP usage. A
single application may require multiple usages; for example a single application may require multiple usages; for example a
softphone application may also require a voicemail usage. A usage softphone application may also require a voicemail usage. A usage
may define multiple kinds of data that are stored in the overlay and may define multiple Kinds of data that are stored in the overlay and
may also rely on kinds originally defined by other usages. may also rely on Kinds originally defined by other usages.
Because the security and storage policies for each kind are dictated Because the security and storage policies for each Kind are dictated
by the usage defining the kind, the usages may be coupled with the by the usage defining the Kind, the usages may be coupled with the
Storage component to provide security policy enforcement and to Storage component to provide security policy enforcement and to
implement appropriate storage strategies according to the needs of implement appropriate storage strategies according to the needs of
the usage. The exact implementation of such an interface is outside the usage. The exact implementation of such an interface is outside
the scope of this specification. the scope of this specification.
1.2.2. Message Transport 1.2.2. Message Transport
The Message Transport component provides a generic message routing The Message Transport component provides a generic message routing
service for the overlay. The Message Transport layer is responsible service for the overlay. The Message Transport layer is responsible
for end-to-end message transactions, including retransmissions. Each for end-to-end message transactions. Each peer is identified by its
peer is identified by its location in the overlay as determined by location in the overlay as determined by its Node-ID. A component
its Node-ID. A component that is a client of the Message Transport that is a client of the Message Transport can perform two basic
can perform two basic functions: functions:
o Send a message to a given peer specified by Node-ID or to the peer o Send a message to a given peer specified by Node-ID or to the peer
responsible for a particular Resource-ID. responsible for a particular Resource-ID.
o Receive messages that other peers sent to a Node-ID or Resource-ID o Receive messages that other peers sent to a Node-ID or Resource-ID
for which the receiving peer is responsible. for which the receiving peer is responsible.
All usages rely on the Message Transport component to send and All usages rely on the Message Transport component to send and
receive messages from peers. For instance, when a usage wants to receive messages from peers. For instance, when a usage wants to
store data, it does so by sending Store requests. Note that the store data, it does so by sending Store requests. Note that the
Storage component and the Topology Plugin are themselves clients of Storage component and the Topology Plugin are themselves clients of
the Message Transport, because they need to send and receive messages the Message Transport, because they need to send and receive messages
from other peers. from other peers.
The Message Transport Service is responsible for end-to-end
reliability, accomplished by timer-based retransmissions. Unlike the
Internet transport layer, however, this layer does not provide
congestion control. RELOAD is a request-response protocol, with no
more than two pairs of request-response messages used in typical
transactions between pairs of nodes, therefore there are no
opportunities to observe and react to end-to-end congestion. As with
all Internet applications, implementers are strongly discouraged from
writing applications that react to loss by immediately retrying the
transaction.
The Message Transport Service is similar to those described as The Message Transport Service is similar to those described as
providing "Key based routing" (KBR), although as RELOAD supports providing "Key based routing" (KBR), although as RELOAD supports
different overlay algorithms (including non-DHT overlay algorithms) different overlay algorithms (including non-DHT overlay algorithms)
that calculate keys in different ways, the actual interface must that calculate keys in different ways, the actual interface must
accept Resource Names rather than actual keys. 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.
As the overlay configuration can be rapidly updated, this value could
be dynamically adjusted at coarse time scales, although algorithms
for determining how to accomplish this are beyond the scope of this
specification. In many cases, however, more appropriate means of
improving network performance, such as the Topology Plugin removing
lossy links from use in overlay routing or reducing the overall hop-
count of end-to-end paths will be more effective than simply
increasing the retransmission timer.
1.2.3. Storage 1.2.3. Storage
One of the major functions of RELOAD is to allow nodes to store data One of the major functions of RELOAD is to allow nodes to store data
in the overlay and to retrieve data stored by other nodes or by in the overlay and to retrieve data stored by other nodes or by
themselves. The Storage component is responsible for processing data themselves. The Storage component is responsible for processing data
storage and retrieval messages. For instance, the Storage component storage and retrieval messages. For instance, the Storage component
might receive a Store request for a given resource from the Message might receive a Store request for a given resource from the Message
Transport. It would then query the appropriate usage before storing Transport. It would then query the appropriate usage before storing
the data value(s) in its local data store and sending a response to the data value(s) in its local data store and sending a response to
the Message Transport for delivery to the requesting node. the Message Transport for delivery to the requesting node.
skipping to change at page 16, line 7 skipping to change at page 16, line 36
1.2.5. Forwarding and Link Management Layer 1.2.5. Forwarding and Link Management Layer
The Forwarding and Link Management Layer is responsible for getting a The Forwarding and Link Management Layer is responsible for getting a
message to the next peer, as determined by the Topology Plugin. This message to the next peer, as determined by the Topology Plugin. This
Layer establishes and maintains the network connections as required Layer establishes and maintains the network connections as required
by the Topology Plugin. This layer is also responsible for setting by the Topology Plugin. This layer is also responsible for setting
up connections to other peers through NATs and firewalls using ICE, up connections to other peers through NATs and firewalls using ICE,
and it can elect to forward traffic using relays for NAT and firewall and it can elect to forward traffic using relays for NAT and firewall
traversal. 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.
This layer provides a generic interface that allows the topology This layer provides a generic interface that allows the topology
plugin to control the overlay and resource operations and messages. plugin to control the overlay and resource operations and messages.
Since each overlay algorithm is defined and functions differently, we Since each overlay algorithm is defined and functions differently, we
generically refer to the table of other peers that the overlay generically refer to the table of other peers that the overlay
algorithm maintains and uses to route requests (neighbors) as a algorithm maintains and uses to route requests (neighbors) as a
Routing Table. The Topology Plugin actually owns the Routing Table, Routing Table. The Topology Plugin actually owns the Routing Table,
and forwarding decisions are made by querying the Topology Plugin for 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 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 is the destination of the message, the message is delivered to the
Message Transport. Message Transport.
skipping to change at page 18, line 24 skipping to change at page 19, line 14
Peer: A host that is participating in the overlay. Peers are Peer: A host that is participating in the overlay. Peers are
responsible for holding some portion of the data that has been responsible for holding some portion of the data that has been
stored in the overlay and also route messages on behalf of other stored in the overlay and also route messages on behalf of other
hosts as required by the Overlay Algorithm. hosts as required by the Overlay Algorithm.
Client: A host that is able to store data in and retrieve data from 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 the overlay but which is not participating in routing or data
storage for the overlay. storage for the overlay.
Kind: A kind defines a particular type of data that can be stored in 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 the overlay. Applications define new Kinds to store the data they
use. Each Kind is identified with a unique integer called a use. Each Kind is identified with a unique integer called a
Kind-ID. Kind-ID.
Node: We use the term "Node" to refer to a host that may be either a 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 Peer or a Client. Because RELOAD uses the same protocol for both
clients and peers, much of the text applies equally to both. clients and peers, much of the text applies equally to both.
Therefore we use "Node" when the text applies to both Clients and 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 Peers and the more specific term (i.e. client or peer) when the
text applies only to Clients or only to Peers. text applies only to Clients or only to Peers.
skipping to change at page 19, line 5 skipping to change at page 19, line 38
IDs. A value of zero is not used in the wire protocol but can be 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 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 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 Joining Peer: A node that is attempting to become a Peer in a
particular Overlay.. particular Overlay..
Admitting Peer: A Peer in the Overlay which helps the Joining Peer Admitting Peer: A Peer in the Overlay which helps the Joining Peer
join the Overlay. join the Overlay.
Bootstrap Node: A network node used by Joining Peers to help Nlocate Bootstrap Node: A network node used by Joining Peers to help locate
the Admitting Peer. the Admitting Peer.
Peer Admission: The act of admitting a peer (the "Joining Peer" ) Peer Admission: The act of admitting a peer (the "Joining Peer" )
into an Overlay. After the admission process is over, the joining into an Overlay. After the admission process is over, the joining
peer is a fully-functional peer of the overlay. During the peer is a fully-functional peer of the overlay. During the
admission process, the joining peer may need to present admission process, the joining peer may need to present
credentials to prove that it has sufficient authority to join the credentials to prove that it has sufficient authority to join the
overlay. overlay.
Resource: An object or group of objects associated with a string Resource: An object or group of objects associated with a string
skipping to change at page 20, line 6 skipping to change at page 20, line 42
Routing Table: The set of peers which a node can use to route Routing Table: The set of peers which a node can use to route
overlay messages. In general, these peers will all be on the overlay messages. In general, these peers will all be on the
connection table but not vice versa, because some peers will have connection table but not vice versa, because some peers will have
Attached but not sent updates. Peers may send messages directly Attached but not sent updates. Peers may send messages directly
to peers that are in the connection table but may only route to peers that are in the connection table but may only route
messages to other peers through peers that are in the routing messages to other peers through peers that are in the routing
table. table.
Destination List: A list of IDs through which a message is to be Destination List: A list of IDs through which a message is to be
routed. A single Node-ID is a trivial form of destination list. routed. 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.
Usage: A usage is an application that wishes to use the overlay for Usage: A usage is an application that wishes to use the overlay for
some purpose. Each application wishing to use the overlay defines some purpose. Each application wishing to use the overlay defines
a set of data kinds that it wishes to use. The SIP usage defines a set of data Kinds that it wishes to use. The SIP usage defines
the location data kind. the location data Kind.
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 The term "maximum request lifetime" is the maximum time a request
will wait for a response; it defaults to 15 seconds. The term will wait for a response; it defaults to 15 seconds. The term
"successor replacement hold-down time" is the amount of time to wait "successor replacement hold-down time" is the amount of time to wait
before starting replication when a new successor is found; it before starting replication when a new successor is found; it
defaults to 30 seconds. defaults to 30 seconds.
3. Overlay Management Overview 3. Overlay Management Overview
The most basic function of RELOAD is as a generic overlay network. The most basic function of RELOAD is as a generic overlay network.
skipping to change at page 20, line 44 skipping to change at page 21, line 40
is structured. is structured.
o To determine the set of resources for which the node is o To determine the set of resources for which the node is
responsible. responsible.
Each node has a certificate [RFC5280] containing a Node-ID, which is Each node has a certificate [RFC5280] containing a Node-ID, which is
unique within an overlay instance. unique within an overlay instance.
The certificate serves multiple purposes: The certificate serves multiple purposes:
o It entitles the user to store data at specific locations in the o It entitles the user to store data at specific locations in the
Overlay Instance. Each data kind defines the specific rules for Overlay Instance. Each data Kind defines the specific rules for
determining which certificates can access each Resource-ID/Kind-ID determining which certificates can access each Resource-ID/Kind-ID
pair. For instance, some kinds might allow anyone to write at a pair. For instance, some Kinds might allow anyone to write at a
given location, whereas others might restrict writes to the owner given location, whereas others might restrict writes to the owner
of a single certificate. of a single certificate.
o It entitles the user to operate a node that has a Node-ID found in o It entitles the user to operate a node that has a Node-ID found in
the certificate. When the node forms a connection to another the certificate. When the node forms a connection to another
peer, it uses this certificate so that a node connecting to it peer, it uses this certificate so that a node connecting to it
knows it is connected to the correct node (technically: a (D)TLS knows it is connected to the correct node (technically: a (D)TLS
association with client authentication is formed.) In addition, association with client authentication is formed.) In addition,
the node can sign messages, thus providing integrity and the node can sign messages, thus providing integrity and
authentication for messages which are sent from the node. authentication for messages which are sent from the node.
o It entitles the user to use the user name found in the o It entitles the user to use the user name found in the
certificate. certificate.
skipping to change at page 21, line 32 skipping to change at page 22, line 25
in a particular Overlay Instance have the enrollment server as a in a particular Overlay Instance have the enrollment server as a
trust anchor and so can verify any other peer's certificate. 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 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. 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 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 network without going to the trouble of setting up an enrollment
server. RELOAD supports the use of self-generated, self-signed server. RELOAD supports the use of self-generated, self-signed
certificates. When self-signed certificates are used, the node also certificates. When self-signed certificates are used, the node also
generates its own Node-ID and username. The Node-ID is computed as a generates its own Node-ID and username. The Node-ID is computed as a
digest of the public key, to prevent Node-ID theft; however this digest of the public key, to prevent Node-ID theft. Note that the
model is still subject to a number of known attacks (most notably relevant cryptographic property for the digest is preimage
Sybil attacks [Sybil]) and can only be safely used in closed networks resistance. Collision-resistance is not required since an attacker
where users are mutually trusting. 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-
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 The general principle here is that the security mechanisms (TLS and
message signatures) are always used, even if the certificates are message signatures) are always used, even if the certificates are
self-signed. This allows for a single set of code paths in the self-signed. This allows for a single set of code paths in the
systems with the only difference being whether certificate systems with the only difference being whether certificate
verification is required to chain to a single root of trust. verification is required to chain to a single root of trust.
3.1.1. Shared-Key Security 3.1.1. Shared-Key Security
RELOAD also provides an admission control system based on shared RELOAD also provides an admission control system based on shared
skipping to change at page 22, line 9 skipping to change at page 23, line 14
3.2. Clients 3.2. Clients
RELOAD defines a single protocol that is used both as the peer RELOAD defines a single protocol that is used both as the peer
protocol and as the client protocol for the overlay. This simplifies protocol and as the client protocol for the overlay. This simplifies
implementation, particularly for devices that may act in either role, implementation, particularly for devices that may act in either role,
and allows clients to inject messages directly into the overlay. and allows clients to inject messages directly into the overlay.
We use the term "peer" to identify a node in the overlay that routes 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 messages for nodes other than those to which it is directly
connected. Peers typically also have storage responsibilities. We connected. Peers also have storage responsibilities. We use the
use the term "client" to refer to nodes that do not have routing or term "client" to refer to nodes that do not have routing or storage
storage responsibilities. When text applies to both peers and responsibilities. When text applies to both peers and clients, we
clients, we will simply refer such devices as "nodes." will simply refer to such devices as "nodes."
RELOAD's client support allows nodes that are not participating in RELOAD's client support allows nodes that are not participating in
the overlay as peers to utilize the same implementation and to the overlay as peers to utilize the same implementation and to
benefit from the same security mechanisms as the peers. Clients benefit from the same security mechanisms as the peers. Clients
possess and use certificates that authorize the user to store data at possess and use certificates that authorize the user to store data at
certain locations in the overlay. The Node-ID in the certificate is 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 used to identify the particular client as a member of the overlay and
to authenticate its messages. to authenticate its messages.
In RELOAD, unlike some other designs, clients are not a first-class In RELOAD, unlike some other designs, clients are not a first-class
skipping to change at page 23, line 19 skipping to change at page 24, line 21
reachability. The client can initiate requests, and any node in reachability. The client can initiate requests, and any node in
the overlay that knows the Destination List to its current the overlay that knows the Destination List to its current
location can reach it, but the client is not directly reachable location can reach it, but the client is not directly reachable
using only its Node-ID. If the client is to receive incoming using only its Node-ID. If the client is to receive incoming
requests from other members of the overlay, the Destination List requests from other members of the overlay, the Destination List
required to reach it must be learnable via other mechanisms, such required to reach it must be learnable via other mechanisms, such
as being stored in the overlay by a usage. A client connected as being stored in the overlay by a usage. A client connected
this way using a certificate with only a single Node-ID MAY this way using a certificate with only a single Node-ID MAY
proceed to use the connection without performing an Attach. A proceed to use the connection without performing an Attach. A
client wishing to connect using this mechanism with a certificate client wishing to connect using this mechanism with a certificate
with multiple Node-IDs MUST perform an Attach after using Ping to with multiple Node-IDs can use a Ping to probe the Node-ID of the
probe the Node-ID of the node to which it is connected. node to which it is connected before doing the Attach.
3.2.2. Minimum Functionality Requirements for Clients 3.2.2. Minimum Functionality Requirements for Clients
A node may act as a client simply because it does not have the A node may act as a client simply because it does not have the
resources or even an implementation of the topology plugin required resources or even an implementation of the topology plugin required
to act as a peer in the overlay. In order to exchange RELOAD 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 messages with a peer, a client must meet a minimum level of
functionality. Such a client must: functionality. Such a client must:
o Implement RELOAD's connection-management operations that are used o Implement RELOAD's connection-management operations that are used
skipping to change at page 23, line 47 skipping to change at page 24, line 49
A client speaks the same protocol as the peers, knows how to A client speaks the same protocol as the peers, knows how to
calculate Resource-IDs, and signs its requests in the same manner as calculate Resource-IDs, and signs its requests in the same manner as
peers. While a client does not necessarily require a full peers. While a client does not necessarily require a full
implementation of the overlay algorithm, calculating the Resource-ID implementation of the overlay algorithm, calculating the Resource-ID
requires an implementation of the appropriate algorithm for the requires an implementation of the appropriate algorithm for the
overlay. overlay.
3.3. Routing 3.3. Routing
This section will discuss the requirements RELOAD's routing This section will discuss the capabilities of RELOAD's routing layer,
capabilities were designed to meet, then describe the routing the protocol features used to implement them, and a brief overview of
features in the protocol, and then provide a brief overview of how how they are used. Appendix A discusses some alternative designs and
they are used. Appendix A discusses some alternative designs and the the tradeoffs that would be necessary to support them.
tradeoffs that would be necessary to support them.
RELOAD's routing capabilities must meet the following requirements: RELOAD's routing provides the following capabilities:
NAT Traversal: RELOAD must support establishing and using Resource-based routing: RELOAD supports routing messages based
connections between nodes separated by one or more NATs, including soley on the name of the resource. Such messages are delivered to
locating peers behind NATs for those overlays allowing/requiring a node that is responsible for that resource. Both structured and
it. unstructured overlays are supported, so the route may not be
Clients: RELOAD must support requests from and to clients that do deterministic for all Topology Plugins.
not participate in overlay routing. Node-based routing: RELOAD supports routing messages to a specific
Client promotion: RELOAD must support clients that become peers at a node in the overlay.
later point as determined by the overlay algorithm and deployment. Clients: RELOAD supports requests from and to clients that do not
Low state: RELOAD's routing algorithms must not require participate in overlay routing, located via either of the
significant state to be stored on intermediate peers. mechanisms described above.
Return routability in unstable topologies: At some points in Bridging overlays: Similar to how a Destination List is used to
times, different nodes may have inconsistent information about the reach a client attached via an arbitrary peer, RELOAD can route
connectivity of the routing graph. In all cases, the response to messages between two different overlays by building a destination
a request needs to delivered to the node that sent the request and list that includes a peer (or client) with connectivity to both
not to some other node. 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 provides three mechanisms designed to assist in RELOAD's routing utilizes three basic mechanisms:
meeting these needs:
Destination Lists: While in principle it is possible to just Destination Lists: While in principle it is possible to just
inject a message into the overlay with a bare Node-ID as the inject a message into the overlay with a bare Node-ID as the
destination, RELOAD provides a source routing capability in the destination, RELOAD provides a source routing capability in the
form of "Destination Lists". A "Destination List provides a list form of "Destination Lists". A "Destination List provides a list
of the nodes through which a message must flow. of the nodes through which a message must flow.
Via Lists: In order to allow responses to follow the same path as Via Lists: In order to allow responses to follow the same path as
requests, each message also contains a "Via List", which is added requests, each message also contains a "Via List", which is added
to by each node a message traverses. This via list can then be to by each node a message traverses. This via list can then be
inverted and used as a destination list for the response. inverted and used as a destination list for the response.
skipping to change at page 25, line 14 skipping to change at page 26, line 28
A B X Z A B X Z
------------------------------- -------------------------------
----------> ---------->
Dest=Z Dest=Z
----------> ---------->
Via=A Via=A
Dest=Z Dest=Z
----------> ---------->
Via=A, B Via=A,B
Dest=Z Dest=Z
<---------- <----------
Dest=X, B, A Dest=X,B,A
<---------- <----------
Dest=B, A Dest=B,A
<---------- <----------
Dest=A Dest=A
Note that the preceding Figure does not indicate whether A is 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 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 returned to A in the same manner regardless of A's role in the
overlay. overlay.
This figure shows use of full via-lists by intermediate peers B and 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 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 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
skipping to change at page 26, line 14 skipping to change at page 27, line 16
A B X Z A B X Z
------------------------------- -------------------------------
----------> ---------->
Dest=Z Dest=Z
----------> ---------->
Via=A Via=A
Dest=Z Dest=Z
----------> ---------->
Dest=Z, X1 Via=X1
Dest=Z
<---------- <----------
Dest=X,X1 Dest=X,X1
<---------- <----------
Dest=B, A Dest=B,A
<---------- <----------
Dest=A Dest=A
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, intermediate peers merely return a response indicating the next hop,
but do not actually forward the message to that next hop themselves). but do not actually forward the message to that next hop themselves).
Iterative routing is implemented using the RouteQuery method, which Iterative routing is implemented using the RouteQuery method, which
requests this behavior. Note that iterative routing is selected only requests this behavior. Note that iterative routing is selected only
by the initiating node. by the initiating node.
3.4. Connectivity Management 3.4. Connectivity Management
skipping to change at page 30, line 17 skipping to change at page 31, line 23
o As a discovery mechanism for services such as TURN. o As a discovery mechanism for services such as TURN.
o To form direct connections which can be used to transmit o To form direct connections which can be used to transmit
application-level messages without using the overlay. application-level messages without using the overlay.
This section provides an overview of these services. This section provides an overview of these services.
4.1. Data Storage 4.1. Data Storage
RELOAD provides operations to Store and Fetch data. Each location in RELOAD provides operations to Store and Fetch data. Each location in
the Overlay Instance is referenced by a Resource-ID. However, each the Overlay Instance is referenced by a Resource-ID. However, each
location may contain data elements corresponding to multiple kinds location may contain data elements corresponding to multiple Kinds
(e.g., certificate, SIP registration). Similarly, there may be (e.g., certificate, SIP registration). Similarly, there may be
multiple elements of a given kind, as shown below: multiple elements of a given Kind, as shown below:
+--------------------------------+ +--------------------------------+
| Resource-ID | | Resource-ID |
| | | |
| +------------+ +------------+ | | +------------+ +------------+ |
| | Kind 1 | | Kind 2 | | | | Kind 1 | | Kind 2 | |
| | | | | | | | | | | |
| | +--------+ | | +--------+ | | | | +--------+ | | +--------+ | |
| | | Value | | | | Value | | | | | | Value | | | | Value | | |
| | +--------+ | | +--------+ | | | | +--------+ | | +--------+ | |
skipping to change at page 30, line 41 skipping to change at page 31, line 47
| | +--------+ | | +--------+ | | | | +--------+ | | +--------+ | |
| | | Value | | | | Value | | | | | | Value | | | | Value | | |
| | +--------+ | | +--------+ | | | | +--------+ | | +--------+ | |
| | | +------------+ | | | | +------------+ |
| | +--------+ | | | | +--------+ | |
| | | Value | | | | | | Value | | |
| | +--------+ | | | | +--------+ | |
| +------------+ | | +------------+ |
+--------------------------------+ +--------------------------------+
Each kind is identified by a Kind-ID, which is a code point either Each Kind is identified by a Kind-ID, which is a code point either
assigned by IANA or allocated out of a private range. As part of the assigned by IANA or allocated out of a private range. As part of the
kind definition, protocol designers may define constraints, such as Kind definition, protocol designers may define constraints, such as
limits on size, on the values which may be stored. For many kinds, limits on size, on the values which may be stored. For many Kinds,
the set may be restricted to a single value; some sets may be allowed the set may be restricted to a single value; some sets may be allowed
to contain multiple identical items while others may only have unique to contain multiple identical items while others may only have unique
items. Note that a kind may be employed by multiple usages and new items. Note that a Kind may be employed by multiple usages and new
usages are encouraged to use previously defined kinds where possible. usages are encouraged to use previously defined Kinds where possible.
We define the following data models in this document, though other We define the following data models in this document, though other
usages can define their own structures: usages can define their own structures:
single value: There can be at most one item in the set and any value single value: There can be at most one item in the set and any value
overwrites the previous item. overwrites the previous item.
array: Many values can be stored and addressed by a numeric index. array: Many values can be stored and addressed by a numeric index.
dictionary: The values stored are indexed by a key. Often this key 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 is one of the values from the certificate of the peer sending the
skipping to change at page 31, line 31 skipping to change at page 32, line 35
A major issue in peer-to-peer storage networks is minimizing the A major issue in peer-to-peer storage networks is minimizing the
burden of becoming a peer, and in particular minimizing the amount of 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 is required to store for other nodes. RELOAD
addresses this issue by only allowing any given node to store data at addresses this issue by only allowing any given node to store data at
a small number of locations in the overlay, with those locations a small number of locations in the overlay, with those locations
being determined by the node's certificate. When a peer uses a Store 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 request to place data at a location authorized by its certificate, it
signs that data with the private key that corresponds to its signs that data with the private key that corresponds to its
certificate. Then the peer responsible for storing the data is able certificate. Then the peer responsible for storing the data is able
to verify that the peer issuing the request is authorized to make to verify that the peer issuing the request is authorized to make
that request. Each data kind defines the exact rules for determining that request. Each data Kind defines the exact rules for determining
what certificate is appropriate. what certificate is appropriate.
The most natural rule is that a certificate authorizes a user to The most natural rule is that a certificate authorizes a user to
store data keyed with their user name X. This rule is used for all store data keyed with their user name X. This rule is used for all
the kinds defined in this specification. Thus, only a user with a the Kinds defined in this specification. Thus, only a user with a
certificate for "alice@example.org" could write to that location in certificate for "alice@example.org" could write to that location in
the overlay. However, other usages can define any rules they choose, the overlay. However, other usages can define any rules they choose,
including publicly writable values. including publicly writable values.
The digital signature over the data serves two purposes. First, it The digital signature over the data serves two purposes. First, it
allows the peer responsible for storing the data to verify that this allows the peer responsible for storing the data to verify that this
Store is authorized. Second, it provides integrity for the data. Store is authorized. Second, it provides integrity for the data.
The signature is saved along with the data value (or values) so that 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 any reader can verify the integrity of the data. Of course, the
responsible peer can "lose" the value but it cannot undetectably responsible peer can "lose" the value but it cannot undetectably
modify it. modify it.
The size requirements of the data being stored in the overlay are The size requirements of the data being stored in the overlay are
variable. For instance, a SIP AOR and voicemail differ widely in the variable. For instance, a SIP AOR and voicemail differ widely in the
storage size. RELOAD leaves it to the Usage and overlay storage size. RELOAD leaves it to the Usage and overlay
configuration to limit size imbalance of various kinds. configuration to limit size imbalance of various Kinds.
4.1.2. Replication 4.1.2. Replication
Replication in P2P overlays can be used to provide: Replication in P2P overlays can be used to provide:
persistence: if the responsible peer crashes and/or if the storing persistence: if the responsible peer crashes and/or if the storing
peer leaves the overlay peer leaves the overlay
security: to guard against DoS attacks by the responsible peer or security: to guard against DoS attacks by the responsible peer or
routing attacks to that responsible peer routing attacks to that responsible peer
load balancing: to balance the load of queries for popular load balancing: to balance the load of queries for popular
skipping to change at page 32, line 44 skipping to change at page 33, line 49
Such replication strategies can be added independent of the Such replication strategies can be added independent of the
underlying algorithm, and their usage can be determined based on the underlying algorithm, and their usage can be determined based on the
needs of the particular usage. needs of the particular usage.
4.2. Usages 4.2. Usages
By itself, the distributed storage layer just provides infrastructure By itself, the distributed storage layer just provides infrastructure
on which applications are built. In order to do anything useful, a on which applications are built. In order to do anything useful, a
usage must be defined. Each Usage needs to specify several things: usage must be defined. Each Usage needs to specify several things:
o Registers Kind-ID code points for any kinds that the Usage o Registers Kind-ID code points for any Kinds that the Usage
defines. 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 formed that is hashed to form the
Resource-ID where each kind is stored.
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 formed that is hashed to form the
Resource-ID where each Kind is stored.
o Describes how values will be merged after a network partition. o Describes how values will be merged after a network partition.
Unless otherwise specified, the default merging rule is to act as 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 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 order they were stored in corresponds to the stored time values
associated with (and carried in) their values. Because the stored associated with (and carried in) their values. Because the stored
time values are those associated with the peer which did the time values are those associated with the peer which did the
writing, clock skew is generally not an issue. If two nodes are writing, clock skew is generally not an issue. If two nodes are
on different partitions, write to the same location, and have on different partitions, write to the same location, and have
clock skew, this can create merge conflicts. However because clock skew, this can create merge conflicts. However because
RELOAD deliberately segregates storage so that data from different RELOAD deliberately segregates storage so that data from different
users and peers is stored in different locations, and a single users and peers is stored in different locations, and a single
peer will typically only be in a single network partition, this peer will typically only be in a single network partition, this
case will generally not arise. case will generally not arise.
The kinds defined by a usage may also be applied to other usages. The Kinds defined by a usage may also be applied to other usages.
However, a need for different parameters, such as different size However, a need for different parameters, such as different size
limits, would imply the need to create a new kind. limits, would imply the need to create a new Kind.
4.3. Service Discovery 4.3. Service Discovery
RELOAD does not currently define a generic service discovery RELOAD does not currently define a generic service discovery
algorithm as part of the base protocol, although a simplistic TURN- algorithm as part of the base protocol, although a simplistic TURN-
specific discovery mechanism is provided. A variety of service specific discovery mechanism is provided. A variety of service
discovery algorithms can be implemented as extensions to the base discovery algorithms can be implemented as extensions to the base
protocol, such as the service discovery algorithm ReDIR protocol, such as the service discovery algorithm ReDIR
[opendht-sigcomm05] or [I-D.ietf-p2psip-service-discovery]. [opendht-sigcomm05] or [I-D.ietf-p2psip-service-discovery].
skipping to change at page 34, line 21 skipping to change at page 35, line 25
5.1. Message Receipt and Forwarding 5.1. Message Receipt and Forwarding
When a peer receives a message, it first examines the overlay, When a peer receives a message, it first examines the overlay,
version, and other header fields to determine whether the message is 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 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 is for an overlay in which the peer does not participate) it is an
error. The peer SHOULD generate an appropriate error but local error. The peer SHOULD generate an appropriate error but local
policy can override this and cause the messages to be silently policy can override this and cause the messages to be silently
dropped. dropped.
Once the peer has determined that the message is correctly formatted, Once the peer has determined that the message is correctly formatted
it examines the first entry on the destination list. There are three (note that this does not include signature checking on intermediate
possible cases here: 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 o The first entry on the destination list is an ID for which the
peer is responsible. A peer is always responsible for the peer is responsible. A peer is always responsible for the
wildcard Node-ID. Handling of this case is described in wildcard Node-ID. Handling of this case is described in
Section 5.1.1. Section 5.1.1.
o The first entry on the destination list is an ID for which another o The first entry on the destination list is an ID for which another
peer is responsible. Handling of this case is described in peer is responsible. Handling of this case is described in
Section 5.1.2. Section 5.1.2.
o The first entry on the destination list is a private ID that is o The first entry on the destination list is a private ID that is
being used for destination list compression. Handling of this being used for destination list compression. Handling of this
case is described in Section 5.1.3. Note that private IDs can be case is described in Section 5.1.3. Note that private IDs can be
distinguished from Node-IDs and Resource-IDs on the wire as distinguished from Node-IDs and Resource-IDs on the wire as
described in Section 5.3.2.2). described in Section 5.3.2.2).
These cases are handled as discussed below. These cases are handled as discussed below.
5.1.1. Responsible ID 5.1.1. Responsible ID
If the first entry on the destination list is an ID for which the If the first entry on the destination list is an ID for which the
peer is responsible, there are several sub-cases to consider. 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 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 the destination list. If there are other entries, the message
MUST be silently dropped. Otherwise, the message is destined for MUST be silently dropped. Otherwise, the message is destined for
this node and it passes it up to the upper layers. this node and it verify the signature and pass it up to the upper
layers.
o If the entry is a Node-ID which equals this node's Node-ID, then 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 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 on the destination list, the message is destined for this node and
is passed up to the upper layers. Otherwise the entry is removed is passed up to the upper layers. Otherwise the entry is removed
from the destination list and the message is passed to the Message from the destination list and the message is passed to the Message
Transport. If the message is a response and there is state for Transport. If the message is a response and there is state for
the transaction ID, the state is reinserted into the destination the transaction ID, the state is reinserted into the destination
list before the message is further processed. list before the message is further processed.
o If the entry is the wildcard Node-ID, the message is destined for 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. this node and it passes it up to the upper layers.
o If the entry is a Node-ID which is not equal to this node, then 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 the node MUST drop the message silently unless the Node-ID
corresponds to a node which is directly connected to this node corresponds to a node which is directly connected to this node
(i.e., a client). In that case, it MUST forward the message to (i.e., a client). In the later case, it MUST forward the message
the destination node as described in the next section. to the destination node as described in the next section.
Note that this implies that in order to address a message to "the 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 peer that controls region X", a sender sends to Resource-ID X, not
Node-ID X. Node-ID X.
5.1.2. Other ID 5.1.2. Other ID
If neither of the other three cases applies, then the peer MUST If neither of the other three cases applies, then the peer MUST
forward the message towards the first entry on the destination list. 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 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 connected and which is likely to be responsible for the first entry
on the destination list. If the first entry on the destination list 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 is in the peer's connection table, then it SHOULD forward the message
to that peer directly. Otherwise, the peer consults the routing to that peer directly. Otherwise, the peer consults the routing
table to forward the message. table to forward the message.
Any intermediate peer which forwards a RELOAD request MUST arrange Any intermediate peer which forwards a RELOAD request MUST ensure
that if it receives a response to that message the response can be that if it receives a response to that message the response can be
routed back through the set of nodes through which the request routed back through the set of nodes through which the request
passed. This may be arranged in one of two ways: passed. This can be ensured in one of two ways:
o The peer MAY add an entry to the via list in the forwarding header o The peer MAY 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.
o The peer MAY keep per-transaction state which will allow it to o The peer MAY keep per-transaction state which will allow it to
determine the correct node. determine the correct node.
As an example of the first strategy, if node D receives a message As an example of the first strategy, consider an example with nodes
from node C with via list (A, B), then D would forward to the next A, B, C, D and E. If node D receives a message from node C with via
node (E) with via list (A, B, C). Now, if E wants to respond to the list (A, B), then D would forward to the next node (E) with via list
message, it reverses the via list to produce the destination list, (A, B, C). Now, if E wants to respond to the message, it reverses
resulting in (D, C, B, A). When D forwards the response to C, the the via list to produce the destination list, resulting in (D, C, B,
destination list will contain (C, B, A). 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 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 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 (X, C) in its state database and forward the message with the via
list unchanged. When D receives the response, it consults its state list unchanged. When D receives the response, it consults its state
database for transaction id X, determines that the request came from database for transaction id X, determines that the request came from
C, and forwards the response to C. C, and forwards the response to C.
Intermediate peers which modify the via list are not required to Intermediate peers which modify the via list are not required to
simply add entries. The only requirement is that the peer be able to simply add entries. The only requirement is that the peer be able to
skipping to change at page 36, line 35 skipping to change at page 37, line 44
message cannot be forwarded and will be dropped. The ordinary message cannot be forwarded and will be dropped. The ordinary
timeout and retransmission mechanisms provide stability over this timeout and retransmission mechanisms provide stability over this
type of failure. type of failure.
Note that if an intermediate peer retains per-transaction state Note that if an intermediate peer retains per-transaction state
instead of modifying the via list, it needs some mechanism for timing instead of modifying the via list, it needs some mechanism for timing
out that state, otherwise its state database will grow without bound. out that state, otherwise its state database will grow without bound.
Whatever algorithm is used, unless a FORWARD_CRITICAL forwarding Whatever algorithm is used, unless a FORWARD_CRITICAL forwarding
option or overlay configuration option explicitly indicates this option or overlay configuration option explicitly indicates this
state is not needed, the state MUST be maintained for at least the state is not needed, the state MUST be maintained for at least the
value of the overlay reliability timer (3 seconds) and MAY be kept value of the overlay-reliability-timer configuration parameter and
longer. Future extension, such as [I-D.jiang-p2psip-relay], may MAY be kept longer. Future extension, such as
define mechanisms for determining when this state does not need to be [I-D.jiang-p2psip-relay], may define mechanisms for determining when
retained. this state does not need to be retained.
None of the above mechanisms are required for responses, since there None of the above mechanisms are required for responses, since there
is no need to ensure that subsequent requests follow the same path. is no need to ensure that subsequent requests follow the same path.
To be precise on the responsibility of the intermediate node, suppose To be precise on the responsibility of the intermediate node, suppose
that an intermediate node, A, receives a message from node B with via 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 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 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 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 follows the same contract. Node A normally learns the Node-ID B is
skipping to change at page 38, line 5 skipping to change at page 39, line 15
Parallel searches for the resource are a common solution to improve Parallel searches for the resource are a common solution to improve
reliability in the face of churn or of subversive peers. Parallel reliability in the face of churn or of subversive peers. Parallel
searches for usage-specified replicas are managed by the usage layer. searches for usage-specified replicas are managed by the usage layer.
However, a single request can also be routed through multiple However, a single request can also be routed through multiple
adjacent peers, even when known to be sub-optimal, to improve adjacent peers, even when known to be sub-optimal, to improve
reliability [vulnerabilities-acsac04]. Such parallel searches MAY be reliability [vulnerabilities-acsac04]. Such parallel searches MAY be
specified by the topology plugin. specified by the topology plugin.
Because messages may be lost in transit through the overlay, RELOAD Because messages may be lost in transit through the overlay, RELOAD
incorporates an end-to-end reliability mechanism. When an incorporates an end-to-end reliability mechanism. When an
originating node transmits a request it MUST set a 3 second timer. originating node transmits a request it MUST set a timer to the
If a response has not been received when the timer fires, the request current overlay-reliability-timer. If a response has not been
is retransmitted with the same transaction identifier. The request received when the timer fires, the request is retransmitted with the
MAY be retransmitted up to 4 times (for a total of 5 messages). same transaction identifier. The request MAY be retransmitted up to
After the timer for the fifth transmission fires, the message SHALL 4 times (for a total of 5 messages). After the timer for the fifth
be considered to have failed. Note that this retransmission transmission fires, the message SHALL be considered to have failed.
procedure is not followed by intermediate nodes. They follow the Note that this retransmission procedure is not followed by
hop-by-hop reliability procedure described in Section 5.6.3. intermediate nodes. They follow the hop-by-hop reliability procedure
described in Section 5.6.3.
The above algorithm can result in multiple requests being delivered The above algorithm can result in multiple requests being delivered
to a node. Receiving nodes MUST generate semantically equivalent to a node. Receiving nodes MUST generate semantically equivalent
responses to retransmissions of the same request (this can be 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., maximum request lifetime (15 seconds). For some requests (e.g.,
Fetch) this can be accomplished merely by processing the request Fetch) this can be accomplished merely by processing the request
again. For other requests, (e.g., Store) it may be necessary to again. For other requests, (e.g., Store) it may be necessary to
maintain state for the duration of the request lifetime. maintain state for the duration of the request lifetime.
skipping to change at page 50, line 29 skipping to change at page 51, line 29
Error_Not_Found: The resource or peer cannot be found or does not Error_Not_Found: The resource or peer cannot be found or does not
exist. exist.
Error_Request_Timeout: A response to the request has not been Error_Request_Timeout: A response to the request has not been
received in a suitable amount of time. The requesting node MAY received in a suitable amount of time. The requesting node MAY
resend the request at a later time. resend the request at a later time.
Error_Data_Too_Old: A store cannot be completed because the Error_Data_Too_Old: A store cannot be completed because the
storage_time precedes the existing value. storage_time precedes the existing value.
Error_Data_Too_Old: A store cannot be completed because the
storage_time precedes the existing value.
Error_Data_Too_Large: A store cannot be completed because the Error_Data_Too_Large: A store cannot be completed because the
requested object exceeds the size limits for that kind. requested object exceeds the size limits for that Kind.
Error_Generation_Counter_Too_Low: A store cannot be completed Error_Generation_Counter_Too_Low: A store cannot be completed
because the generation counter precedes the existing value. because the generation counter precedes the existing value.
Error_Incompatible_with_Overlay: A peer receiving the request is Error_Incompatible_with_Overlay: A peer receiving the request is
using a different overlay, overlay algorithm, or hash algorithm. using a different overlay, overlay algorithm, or hash algorithm.
Error_Unsupported_Forwarding_Option: A peer receiving the request Error_Unsupported_Forwarding_Option: A peer receiving the request
with a forwarding options flagged as critical but the peer does with a forwarding options flagged as critical but the peer does
not support this option. See section Section 5.3.2.3. not support this option. See section Section 5.3.2.3.
skipping to change at page 51, line 18 skipping to change at page 52, line 15
Error_Response_Too_Large: A peer would have generated a response Error_Response_Too_Large: A peer would have generated a response
that is too large per the max_response_length field. that is too large per the max_response_length field.
Error_Config_Too_Old: A destination peer received a request with a Error_Config_Too_Old: A destination peer received a request with a
configuration sequence that's too old. See Section 5.3.2.1. configuration sequence that's too old. See Section 5.3.2.1.
Error_Config_Too_New: A destination node received a request with a Error_Config_Too_New: A destination node received a request with a
configuration sequence that's too new. See Section 5.3.2.1. configuration sequence that's too new. See Section 5.3.2.1.
Error_Unknown_Kind: A destination node received a request with an Error_Unknown_Kind: A destination node received a request with an
unknown kind-id. See Section 6.4.1.2. unknown Kind-ID. See Section 6.4.1.2.
Error_In_Progress: An Attach is already in progress to this peer. Error_In_Progress: An Attach is already in progress to this peer.
See Section 5.5.1.2. See Section 5.5.1.2.
Error_Unknown_Extension: A destination node received a request with Error_Unknown_Extension: A destination node received a request with
an unknown extension. an unknown extension.
5.3.4. Security Block 5.3.4. Security Block
The third part of a RELOAD message is the security block. The The third part of a RELOAD message is the security block. The
skipping to change at page 54, line 11 skipping to change at page 55, line 11
RSASSA-PKCS1-v1_5 [RFC3447] signatures with SHA-256 hashes. RSASSA-PKCS1-v1_5 [RFC3447] signatures with SHA-256 hashes.
identity identity
The identity used to form the signature. The identity used to form the signature.
signature_value signature_value
The value of the signature. The value of the signature.
There are two permitted identity formats, one for a certificate with There are two permitted identity formats, one for a certificate with
only one node-id and one for a certificate with multiple node-ids. only one node-id and one for a certificate with multiple node-ids.
In the first case, the cert_hash type SHOULD be used. The hash_alg 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. field is used to indicate the algorithm used to produce the hash.
The certificate_hash contains the hash of the certificate object The certificate_hash contains the hash of the certificate object
(i.e., the DER-encoded certificate). (i.e., the DER-encoded certificate).
In the second case, the cert_hash_node_id type MUST be used. The 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 hash_alg is as in cert_hash but the cert_hash_node_id is computed
over the NodeId used to sign concatenated with the certificate. over the NodeId used to sign concatenated with the certificate.
I.e., H(NodeID || certificate). The NodeId is represented without I.e., H(NodeID || certificate). The NodeId is represented without
any framing or length fields, as simple raw bytes. This is safe any framing or length fields, as simple raw bytes. This is safe
because NodeIds are fixed-length for a given overlay. because NodeIds are fixed-length for a given overlay.
skipping to change at page 54, line 34 skipping to change at page 55, line 34
over: over:
overlay || transaction_id || MessageContents || SignerIdentity overlay || transaction_id || MessageContents || SignerIdentity
where overlay and transaction_id come from the forwarding header and where overlay and transaction_id come from the forwarding header and
|| indicates concatenation. || indicates concatenation.
The input to signatures over data values is different, and is The input to signatures over data values is different, and is
described in Section 6.1. described in Section 6.1.
All RELOAD messages MUST be signed. Upon receipt, the receiving node All RELOAD messages MUST be signed. Upon receipt (and fragment
MUST verify the signature and the authorizing certificate. This reassembly if needed) the destination node MUST verify the signature
check provides a minimal level of assurance that the sending node is and the authorizing certificate. If the signature fails, the
a valid part of the overlay as well as cryptographic authentication implementation SHOULD simply drop the message. This check provides a
of the sending node. In addition, responses MUST be checked as minimal level of assurance that the sending node is a valid part of
follows: the overlay as well as cryptographic authentication of the sending
node. In addition, responses MUST be checked as follows:
1. The response to a message sent to a specific Node-ID MUST have 1. The response to a message sent to a specific Node-ID MUST have
been sent by that Node-ID. been sent by that Node-ID.
2. The response to a message sent to a Resource-Id MUST have been 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 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 Resource-Id than any node in the requesting node's neighbor
table. table.
The second condition serves as a primitive check for responses from The second condition serves as a primitive check for responses from
wildly wrong nodes but is not a complete check. Note that in periods wildly wrong nodes but is not a complete check. Note that in periods
skipping to change at page 56, line 20 skipping to change at page 57, line 21
opaque overlay_specific_data<0..2^16-1>; opaque overlay_specific_data<0..2^16-1>;
} JoinReq; } JoinReq;
The minimal JoinReq contains only the Node-ID which the sending peer The minimal JoinReq contains only the Node-ID which the sending peer
wishes to assume. Overlay algorithms MAY specify other data to wishes to assume. Overlay algorithms MAY specify other data to
appear in this request. Receivers of the JoinReq MUST verify that appear in this request. Receivers of the JoinReq MUST verify that
the joining_peer_id field matches the Node-ID used to sign the 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 message and if not MUST reject the message with an Error_Forbidden
error. 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
provided that DTLS anti-replay is used.
If the request succeeds, the responding peer responds with a JoinAns If the request succeeds, the responding peer responds with a JoinAns
message, as defined below: message, as defined below:
struct { struct {
opaque overlay_specific_data<0..2^16-1>; opaque overlay_specific_data<0..2^16-1>;
} JoinAns; } JoinAns;
If the request succeeds, the responding peer MUST follow up by If the request succeeds, the responding peer MUST follow up by
executing the right sequence of Stores and Updates to transfer the 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 peer. In
addition, overlay algorithms MAY define data to appear in the addition, overlay algorithms MAY define data to appear in the
response payload that provides additional info. 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 In general, nodes which cannot form connections SHOULD report an
error. However, implementations MUST provide some mechanism whereby error. However, implementations MUST provide some mechanism whereby
nodes can determine that they are potentially the first node and take nodes can determine that they are potentially the first node and take
responsibility for the overlay. This specification does not mandate responsibility for the overlay. This specification does not mandate
any particular mechanism, but a configuration flag or setting seems any particular mechanism, but a configuration flag or setting seems
appropriate. appropriate.
5.4.2.2. Leave 5.4.2.2. Leave
The LeaveReq message is used to indicate that a node is exiting the The LeaveReq message is used to indicate that a node is exiting the
skipping to change at page 57, line 11 skipping to change at page 58, line 22
NodeId leaving_peer_id; NodeId leaving_peer_id;
opaque overlay_specific_data<0..2^16-1>; opaque overlay_specific_data<0..2^16-1>;
} LeaveReq; } LeaveReq;
LeaveReq contains only the Node-ID of the leaving peer. Overlay LeaveReq contains only the Node-ID of the leaving peer. Overlay
algorithms MAY specify other data to appear in this request. algorithms MAY specify other data to appear in this request.
Receivers of the LeaveReq MUST verify that the leaving_peer_id field Receivers of the LeaveReq MUST verify that the leaving_peer_id field
matches the Node-ID used to sign the message and if not MUST reject matches the Node-ID used to sign the message and if not MUST reject
the message with an Error_Forbidden error. the message with an Error_Forbidden error.
Because leaves may only be executed between nodes which are directly
adjacent, receiving peers MUST verify that any LeaveReq they receive
arrives from a transport channel that is bound to the Node-Id to be
assumed by the leaving peer.) This also prevents replay attacks
provided that DTLS anti-replay is used.
Upon receiving a Leave request, a peer MUST update its own routing Upon receiving a Leave request, a peer MUST update its own routing
table, and send the appropriate Store/Update sequences to re- table, and send the appropriate Store/Update sequences to re-
stabilize the overlay. stabilize the overlay.
5.4.2.3. Update 5.4.2.3. Update
Update is the primary overlay-specific maintenance message. It is Update is the primary overlay-specific maintenance message. It is
used by the sender to notify the recipient of the sender's view of used by the sender to notify the recipient of the sender's view of
the current state of the overlay (its routing state), and it is up to the current state of the overlay (its routing state), and it is up to
the recipient to take whatever actions are appropriate to deal with the recipient to take whatever actions are appropriate to deal with
skipping to change at page 64, line 27 skipping to change at page 66, line 27
If a peer receives an Attach request, it MUST determine how to If a peer receives an Attach request, it MUST determine how to
process the request as follows: process the request as follows:
o If it has not initiated an Attach request to the originating peer o If it has not initiated an Attach request to the originating peer
of this Attach request, it MUST process this request and SHOULD of this Attach request, it MUST process this request and SHOULD
generate its own response with an AttachReqAns. It should then generate its own response with an AttachReqAns. It should then
begin ICE checks. begin ICE checks.
o If it has already sent an Attach request to and received the o If it has already sent an Attach request to and received the
response from the originating peer of this Attach request, and as response from the originating peer of this Attach request, and as
a as a result, an ICE check and TLS connection is in progress, a result, an ICE check and TLS connection is in progress, then it
then it SHOULD generate an Error_In_Progress error instead of an SHOULD generate an Error_In_Progress error instead of an
AttachReqAns. AttachReqAns.
o If it has already sent an Attach request to but not yet received o If it has already sent an Attach request to but not yet received
the response from the originating peer of this Attach request, it the response from the originating peer of this Attach request, it
SHOULD apply the following tie-breaker heuristic to determine how SHOULD apply the following tie-breaker heuristic to determine how
to handle this Attach request and the incomplete Attach request it to handle this Attach request and the incomplete Attach request it
has sent out: has sent out:
* If the peer's own Node-ID is smaller when compared as big- * If the peer's own Node-ID is smaller when compared as big-
endian unsigned integers, it MUST cancel its own incomplete endian unsigned integers, it MUST cancel its own incomplete
Attach request. It MUST then process this Attach request, Attach request. It MUST then process this Attach request,
generate an AttachReqAns response, and proceed with the generate an AttachReqAns response, and proceed with the
skipping to change at page 67, line 17 skipping to change at page 69, line 17
blocking. For example, SCTP without message ordering, DCCP, or blocking. For example, SCTP without message ordering, DCCP, or
those protocols encapsulated using UDP. those protocols encapsulated using UDP.
o Second highest priority is assigned to protocols that offer well- o Second highest priority is assigned to protocols that offer well-
understood congestion and flow control but have head of line understood congestion and flow control but have head of line
blocking such as TCP. blocking such as TCP.
o Lowest priority is assigned to protocols encapsulated over UDP o Lowest priority is assigned to protocols encapsulated over UDP
that do not implement well-established congestion control that do not implement well-established congestion control
algorithms. The DTLS/UDP with SR overlay link protocol is an algorithms. The DTLS/UDP with SR overlay link protocol is an
example of such a protocol. example of such a protocol.
Head of line blocking is undesireable 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.
5.5.1.7. Encoding the Attach Message 5.5.1.7. Encoding the Attach Message
Section 4.3 of ICE describes procedures for encoding the SDP for Section 4.3 of ICE describes procedures for encoding the SDP for
conveying RELOAD candidates. Instead of actually encoding an SDP, conveying RELOAD candidates. Instead of actually encoding an SDP
the candidate information (IP address and port and transport message, the candidate information (IP address and port and transport
protocol, priority, foundation, type and related address) is carried protocol, priority, foundation, type and related address) is carried
within the attributes of the Attach request or its response. within the attributes of the Attach request or its response.
Similarly, the username fragment and password are carried in the Similarly, the username fragment and password are carried in the
Attach message or its response. Section 5.5.1 describes the detailed Attach message or its response. Section 5.5.1 describes the detailed
attribute encoding for Attach. The Attach request and its response attribute encoding for Attach. The Attach request and its response
do not contain any default candidates or the ice-lite attribute, as do not contain any default candidates or the ice-lite attribute, as
these features of ICE are not used by RELOAD. these features of ICE are not used by RELOAD.
Since the Attach request contains the candidate information and short Since the Attach request contains the candidate information and short
term credentials, it is considered as an offer for a single media term credentials, it is considered as an offer for a single media
skipping to change at page 71, line 43 skipping to change at page 74, line 11
time time
The time when the Ping response was created represented in the The time when the Ping response was created represented in the
same way as storage_time defined in Section 6. same way as storage_time defined in Section 6.
5.5.4. ConfigUpdate 5.5.4. ConfigUpdate
The ConfigUpdate method is used to push updated configuration data The ConfigUpdate method is used to push updated configuration data
across the overlay. Whenever a node detects that another node has across the overlay. Whenever a node detects that another node has
old configuration data, it MUST generate a ConfigUpdate request. The old configuration data, it MUST generate a ConfigUpdate request. The
ConfigUpdate request allows updating of two kinds of data: the ConfigUpdate request allows updating of two kinds of data: the
configuration data (Section 5.3.2.1) and kind information configuration data (Section 5.3.2.1) and the Kind information
(Section 6.4.1.1). (Section 6.4.1.1).
5.5.4.1. Request Definition 5.5.4.1. Request Definition
enum { reservedConfigUpdate(0), config(1), kind(2), (255) } enum { reservedConfigUpdate(0), config(1), kind(2), (255) }
ConfigUpdateType; ConfigUpdateType;
typedef uint32 KindId; typedef uint32 KindId;
typedef opaque KindDescription<0..2^16-1>; typedef opaque KindDescription<0..2^16-1>;
skipping to change at page 73, line 4 skipping to change at page 75, line 17
MUST be encoded with UTF-8 and assume a default namespace of MUST be encoded with UTF-8 and assume a default namespace of
"urn:ietf:params:xml:ns:p2p:config-base". "urn:ietf:params:xml:ns:p2p:config-base".
5.5.4.2. Response Definition 5.5.4.2. Response Definition
struct { struct {
} ConfigUpdateAns } ConfigUpdateAns
If the ConfigUpdateReq is of type "config" it MUST only be processed If the ConfigUpdateReq is of type "config" it MUST only be processed
if all the following are true: if all the following are true:
o The sequence number in the document is greater than the current o The sequence number in the document is greater than the current
configuration sequence number. configuration sequence number.
o The configuration document is correctly digitally signed (see o The configuration document is correctly digitally signed (see
Section 10 for details on signatures. Section 10 for details on signatures.
Otherwise appropriate errors MUST be generated. Otherwise appropriate errors MUST be generated.
If the ConfigUpdateReq is of type "kind" it MUST only be processed if If the ConfigUpdateReq is of type "kind" it MUST only be processed if
it is correctly digitally signed by an acceptable kind signer as it is correctly digitally signed by an acceptable Kind signer as
specified in the configuration file. Details on kind-signer field in specified in the configuration file. Details on kind-signer field in
the configuration file is described in Section 10.1. In addition, if the configuration file is described in Section 10.1. In addition, if
the kind update conflicts with an existing known kind (i.e., it is the Kind update conflicts with an existing known Kind (i.e., it is
signed by a different signer), then it should be rejected with signed by a different signer), then it should be rejected with
"Error_Forbidden". This should not happen in correctly functioning "Error_Forbidden". This should not happen in correctly functioning
overlays. overlays.
If the update is acceptable, then the node MUST reconfigure itself to If the update is acceptable, then the node MUST reconfigure itself to
match the new information. This may include adding permissions for match the new information. This may include adding permissions for
new kinds, deleting old kinds, or even, in extreme circumstances, new Kinds, deleting old Kinds, or even, in extreme circumstances,
exiting and reentering the overlay, if, for instance, the DHT exiting and reentering the overlay, if, for instance, the DHT
algorithm has changed. algorithm has changed.
The response for ConfigUpdate is empty. The response for ConfigUpdate is empty.
5.6. Overlay Link Layer 5.6. Overlay Link Layer
RELOAD can use multiple Overlay Link protocols to send its messages. RELOAD can use multiple Overlay Link protocols to send its messages.
Because ICE is used to establish connections (see Section 5.5.1.3), Because ICE is used to establish connections (see Section 5.5.1.3),
RELOAD nodes are able to detect which Overlay Link protocols are RELOAD nodes are able to detect which Overlay Link protocols are
offered by other nodes and establish connections between them. Any offered by other nodes and establish connections between them. Any
link protocol needs to be able to establish a secure, authenticated link protocol needs to be able to establish a secure, authenticated
connection and to provide data origin authentication and message connection and to provide data origin authentication and message
integrity for individual data elements. RELOAD currently supports integrity for individual data elements. RELOAD currently supports
three Overlay Link protocols: three Overlay Link protocols:
o DTLS [RFC4347] over UDP with Simple Reliability (SR) o DTLS [RFC4347] over UDP with Simple Reliability (SR)
(OverlayLinkType=DTLS-UDP-SR
o TLS [RFC5246] over TCP with Framing Header, No-ICE o TLS [RFC5246] over TCP with Framing Header, No-ICE
o DTLS [RFC4347] over UDP with SR, No-ICE (OverlayLinkType=TLS-TCP-FH-NO-ICE
o DTLS [RFC4347] over UDP with SR, No-ICE (OverlayLinkType=DTLS-UDP-
SR-NO-ICE)
Note that although UDP does not properly have "connections", both TLS Note that although UDP does not properly have "connections", both TLS
and DTLS have a handshake which establishes a similar, stateful and DTLS have a handshake which establishes a similar, stateful
association, and we simply refer to these as "connections" for the association, and we simply refer to these as "connections" for the
purposes of this document. purposes of this document.
If a peer receives a message that is larger than value of max- If a peer receives a message that is larger than value of max-
message-size defined in the overlay configuration, the peer SHOULD message-size defined in the overlay configuration, the peer SHOULD
send an Error_Message_Too_Large error and then close the TLS or DTLS send an Error_Message_Too_Large error and then close the TLS or DTLS
session from which the message was received. Note that this error session from which the message was received. Note that this error
skipping to change at page 74, line 22 skipping to change at page 76, line 40
protocols. We will first define each of these algorithms, then protocols. We will first define each of these algorithms, then
define overlay link protocols that use them. define overlay link protocols that use them.
Note: We expect future Overlay Link protocols to define replacements Note: We expect future Overlay Link protocols to define replacements
for all components of these protocols, including the framing header. for all components of these protocols, including the framing header.
These protocols have been chosen for simplicity of implementation and These protocols have been chosen for simplicity of implementation and
reasonable performance. reasonable performance.
Note to implementers: There are inherent tradeoffs in utilizing Note to implementers: There are inherent tradeoffs in utilizing
short timeouts to determine when a link has failed. To balance the short timeouts to determine when a link has failed. To balance the
tradeoffs, an implementation should be able to quickly act to remove tradeoffs, an implementation SHOULD quickly act to remove entries
entries from the routing table when there is reason to suspect the from the routing table when there is reason to suspect the link has
link has failed. For example, in a Chord derived overlay algorithm, failed. For example, in a Chord derived overlay algorithm, a closer
a closer finger table entry could be substituted for an entry in the finger table entry could be substituted for an entry in the finger
finger table that has experienced a timeout. That entry can be table that has experienced a timeout. That entry can be restored if
restored if it proves to resume functioning, or replaced at some it proves to resume functioning, or replaced at some point in the
point in the future if necessary. End-to-end retransmissions will future if necessary. End-to-end retransmissions will handle any lost
handle any lost messages, but only if the failing entries do not messages, but only if the failing entries do not remain in the finger
remain in the finger table for subsequent retransmissions. table for subsequent retransmissions.
5.6.1. Future Overlay Link Protocols 5.6.1. Future Overlay Link Protocols
It is possible to define new link-layer protocols and apply them to a It is possible to define new link-layer protocols and apply them to a
new overlay using the "overlay-link-protocol" configuration directive new overlay using the "overlay-link-protocol" configuration directive
(see Section 10.1.). However, any new protocols MUST meet the (see Section 10.1.). However, any new protocols MUST meet the
following requirements. following requirements.
Endpoint authentication When a node forms an association with Endpoint authentication When a node forms an association with
another endpoint, it MUST be possible to cryptographically verify another endpoint, it MUST be possible to cryptographically verify
skipping to change at page 77, line 43 skipping to change at page 80, line 8
means only that it is unknown whether or not the packet has been means only that it is unknown whether or not the packet has been
received, because it might have been received before the 32 most received, because it might have been received before the 32 most
recently received packets. recently received packets.
The received field bits in the ACK provide a high degree of The received field bits in the ACK provide a high degree of
redundancy so that the sender can figure out which packets the redundancy so that the sender can figure out which packets the
receiver has received and can then estimate packet loss rates. If receiver has received and can then estimate packet loss rates. If
the sender also keeps track of the time at which recent sequence the sender also keeps track of the time at which recent sequence
numbers have been sent, the RTT can be estimated. numbers have been sent, the RTT can be estimated.
Note that because retransmissions receive new sequence numbers,
multiple ACKs may be received for the same message. This approach
provides more information than traditional TCP sequence numbers, but
care must be taken when applying algorithms designed based on TCP's
stream-oriented sequence number.
5.6.3. Simple Reliability 5.6.3. Simple Reliability
When RELOAD is carried over DTLS or another unreliable link protocol, When RELOAD is carried over DTLS or another unreliable link protocol,
it needs to be used with a reliability and congestion control it needs to be used with a reliability and congestion control
mechanism, which is provided on a hop-by-hop basis. The basic mechanism, which is provided on a hop-by-hop basis. The basic
principle is that each message, regardless of whether or not it principle is that each message, regardless of whether or not it
carries a request or response, will get an ACK and be reliably carries a request or response, will get an ACK and be reliably
retransmitted. The receiver's job is very simple, limited to just retransmitted. The receiver's job is very simple, limited to just
sending ACKs. All the complexity is at the sender side. This allows sending ACKs. All the complexity is at the sender side. This allows
the sending implementation to trade off performance versus the sending implementation to trade off performance versus
implementation complexity without affecting the wire protocol. implementation complexity without affecting the wire protocol.
5.6.3.1. Retransmission and Flow Control
Because the receiver's role is limited to providing packet Because the receiver's role is limited to providing packet
acknowledgements, a wide variety of congestion control algorithms can acknowledgements, a wide variety of congestion control algorithms can
be implemented on the sender side while using the same basic wire be implemented on the sender side while using the same basic wire
protocol. In general, senders MAY implement any rate control scheme protocol. The sender algorithm used MUST meet the requirements of
of their choice, provided that it is REQUIRED to be no more [RFC5405].
aggressive then TFRC[RFC5348].
The following section describes a simple, inefficient scheme that 5.6.3.1. Stop and Wait Sender Algorithm
complies with this requirement. Another alternative would be TFRC-SP
[RFC4828] and use the received bitmask to allow the sender to compute
packet loss event rates.
5.6.3.1.1. Trivial Retransmission This section describes one possible implementation of a sender
algorithm for Simple Reliability. It is adequate for overlays
running on underlying networks with low latency and loss (LANs) or
low-traffic overlays on the Internet.
A node SHOULD retransmit a message if it has not received an ACK A node MUST NOT have more than one unacknowledged message on the DTLS
after an interval of RTO ("Retransmission TimeOut"). The node MUST connection at a time. Note that because retransmissions of the same
double the time to wait after each retransmission. In each message are given new sequence numbers, there may be multiple
retransmission, the sequence number is incremented. unacknowledged sequence numbers in use.
The RTO is an estimate of the round-trip time (RTT). Implementations The RTO ("Retransmission TimeOut") is based on an estimate of the
can use a static value for RTO or a dynamic estimate which will round-trip time (RTT). The value for RTO is calculated separately
result in better performance. For implementations that use a static for each DTLS session. Implementations can use a static value for
value, the default value for RTO is 500 ms. Nodes MAY use smaller RTO or a dynamic estimate which will result in better performance.
values of RTO if it is known that all nodes are within the local For implementations that use a static value, the default value for
network. The default RTO MAY be chosen larger, and this is RTO is 500 ms. Nodes MAY use smaller values of RTO if it is known
RECOMMENDED if it is known in advance (such as on high latency access that all nodes are within the local network. The default RTO MAY be
links) that the round-trip time is larger. chosen larger, and this is RECOMMENDED if it is known in advance
(such as on high latency access links) that the round-trip time is
larger.
Implementations that use a dynamic estimate to compute the RTO MUST Implementations that use a dynamic estimate to compute the RTO MUST
use the algorithm described in RFC 6298[RFC6298], with the exception use the algorithm described in RFC 6298[RFC6298], with the exception
that the value of RTO SHOULD NOT be rounded up to the nearest second that the value of RTO SHOULD NOT be rounded up to the nearest second
but instead rounded up to the nearest millisecond. The RTT of a but instead rounded up to the nearest millisecond. The RTT of a
successful STUN transaction from the ICE stage is used as the initial successful STUN transaction from the ICE stage is used as the initial
measurement for formula 2.2 of RFC 6298. The sender keeps track of measurement for formula 2.2 of RFC 6298. The sender keeps track of
the time each message was sent for all recently sent messages. Any the time each message was sent for all recently sent messages. Any
time an ACK is received, the sender can compute the RTT for that time an ACK is received, the sender can compute the RTT for that
message by looking at the time the ACK was received and the time when message by looking at the time the ACK was received and the time when
the message was sent. This is used as a subsequent RTT measurement the message was sent. This is used as a subsequent RTT measurement
for formula 2.3 of RFC 6298 to update the RTO estimate. (Note that for formula 2.3 of RFC 6298 to update the RTO estimate. (Note that
because retransmissions receive new sequence numbers, all received because retransmissions receive new sequence numbers, all received
ACKs are used.) ACKs are used.)
The value for RTO is calculated separately for each DTLS session. A node SHOULD retransmit a message if it has not received an ACK
after an interval of RTO. The node MUST double the time to wait
after each retransmission. For each retransmission, the sequence
number MUST be incremented.
Retransmissions continue until a response is received, or until a Retransmissions continue until a response is received, or until a
total of 5 requests have been sent or there has been a hard ICMP 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 error [RFC1122] or a TLS alert. The sender knows a response was
received when it receives an ACK with a sequence number that received when it receives an ACK with a sequence number that
indicates it is a response to one of the transmissions of this indicates it is a response to one of the transmissions of this
messages. For example, assuming an RTO of 500 ms, requests would be 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 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 retransmissions for a message fail, then the sending node SHOULD
close the connection routing the message. close the connection routing the message.
To determine when a link may be failing without waiting for the final 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 timeout, observe when no ACKs have been received for an entire RTO
interval, and then wait for three retransmissions to occur beyond interval, and then wait for three retransmissions to occur beyond
that point. If no ACKs have been received by the time the third that point. If no ACKs have been received by the time the third
retransmission occurs, it is RECOMMENDED that the link be removed retransmission occurs, it is RECOMMENDED that the link be removed
from the routing table. The link MAY be restored to the routing from the routing table. The link MAY be restored to the routing
table if ACKs resume before the connection is closed, as described table if ACKs resume before the connection is closed, as described
above. above.
Once an ACK has been received for a message, the next message can be A sender MUST wait 10ms between receipt of an ACK and transmission of
sent, but the peer SHOULD ensure that there is at least 10 ms between the next message.
sending any two messages. The only time a value less than 10 ms can
be used is when it is known that all nodes are on a network that can
support retransmissions faster than 10 ms with no congestion issues.
5.6.4. DTLS/UDP with SR 5.6.4. DTLS/UDP with SR
This overlay link protocol consists of DTLS over UDP while This overlay link protocol consists of DTLS over UDP while
implementing the Simple Reliability protocol. STUN Connectivity implementing the Simple Reliability protocol. STUN Connectivity
checks and keepalives are used. checks and keepalives are used. Any compliant sender algorithm may
be used.
5.6.5. TLS/TCP with FH, No-ICE 5.6.5. TLS/TCP with FH, No-ICE
This overlay link protocol consists of TLS over TCP with the framing This overlay link protocol consists of TLS over TCP with the framing
header. Because ICE is not used, STUN connectivity checks are not header. Because ICE is not used, STUN connectivity checks are not
used upon establishing the TCP connection, nor are they used for used upon establishing the TCP connection, nor are they used for
keepalives. keepalives.
Because the TCP layer's application-level timeout is too slow to be Because the TCP layer's application-level timeout is too slow to be
useful for overlay routing, the Overlay Link implementation MUST use useful for overlay routing, the Overlay Link implementation MUST use
skipping to change at page 80, line 41 skipping to change at page 83, line 12
larger than the PMTU of the next overlay link minus 32 bytes. This larger than the PMTU of the next overlay link minus 32 bytes. This
is to allow the via list to grow before further fragmentation is is to allow the via list to grow before further fragmentation is
required. required.
Note that this fragmentation is not optimal for the end-to-end path - Note that this fragmentation is not optimal for the end-to-end path -
a message may be refragmented multiple times as it traverses the a message may be refragmented multiple times as it traverses the
overlay but is only assembled at the final destination. This option overlay but is only assembled at the final destination. This option
has been chosen as it is far easier to implement than e2e PMTU has been chosen as it is far easier to implement than e2e PMTU
discovery across an ever-changing overlay, and it effectively discovery across an ever-changing overlay, and it effectively
addresses the reliability issues of relying on IP-layer addresses the reliability issues of relying on IP-layer
fragmentation. However, PING can be used to allow e2e PMTU to be fragmentation. However, PING can be used to allow e2e PMTU discovery
implemented if desired. to be implemented if desired.
Upon receipt of a fragmented message by the intended peer, the peer Upon receipt of a fragmented message by the intended peer, the peer
holds the fragments in a holding buffer until the entire message has holds the fragments in a holding buffer until the entire message has
been received. The message is then reassembled into a single message been received. The message is then reassembled into a single message
and processed. In order to mitigate denial of service attacks, and processed. In order to mitigate denial of service attacks,
receivers SHOULD time out incomplete fragments after maximum request receivers SHOULD time out incomplete fragments after maximum request
lifetime (15 seconds). Note this time was derived from looking at lifetime (15 seconds). Note this time was derived from looking at
the end to end retransmission time and saving fragments long enough the end to end retransmission time and saving fragments long enough
for the full end to end retransmissions to take place. Ideally the for the full end to end retransmissions to take place. Ideally the
receiver would have enough buffer space to deal with as many receiver would have enough buffer space to deal with as many
skipping to change at page 82, line 33 skipping to change at page 85, line 11
time the peer receives the StoreReq. time the peer receives the StoreReq.
value value
The data value itself, as described in Section 6.2. The data value itself, as described in Section 6.2.
signature signature
A signature as defined in Section 6.1. A signature as defined in Section 6.1.
Each Resource-ID specifies a single location in the Overlay Instance. Each Resource-ID specifies a single location in the Overlay Instance.
However, each location may contain multiple StoredData values However, each location may contain multiple StoredData values
distinguished by Kind-ID. The definition of a kind describes both distinguished by Kind-ID. The definition of a Kind describes both
the data values which may be stored and the data model of the data. the data values which may be stored and the data model of the data.
Some data models allow multiple values to be stored under the same Some data models allow multiple values to be stored under the same
Kind-ID. Section Section 6.2 describes the available data models. Kind-ID. Section Section 6.2 describes the available data models.
Thus, for instance, a given Resource-ID might contain a single-value Thus, for instance, a given Resource-ID might contain a single-value
element stored under Kind-ID X and an array containing multiple element stored under Kind-ID X and an array containing multiple
values stored under Kind-ID Y. values stored under Kind-ID Y.
6.1. Data Signature Computation 6.1. Data Signature Computation
Each StoredData element is individually signed. However, the Each StoredData element is individually signed. However, the
skipping to change at page 83, line 26 skipping to change at page 86, line 5
StoredDataValue StoredDataValue
The contents of the stored data value, as described in the The contents of the stored data value, as described in the
previous sections. previous sections.
SignerIdentity SignerIdentity
The signer identity as defined in Section 5.3.4. The signer identity as defined in Section 5.3.4.
Once the signature has been computed, the signature is represented Once the signature has been computed, the signature is represented
using a signature element, as described in Section 5.3.4. using a signature element, as described in Section 5.3.4.
Note that there is no necessarily 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.)
6.2. Data Models 6.2. Data Models
The protocol currently defines the following data models: The protocol currently defines the following data models:
o single value o single value
o array o array
o dictionary o dictionary
These are represented with the StoredDataValue structure. The actual These are represented with the StoredDataValue structure. The actual
dataModel is known from the kind being stored. dataModel is known from the Kind being stored.
struct { struct {
Boolean exists; Boolean exists;
opaque value<0..2^32-1>; opaque value<0..2^32-1>;
} DataValue; } DataValue;
struct { struct {
select (dataModel) { select (dataModel) {
case single_value: case single_value:
DataValue single_value_entry; DataValue single_value_entry;
skipping to change at page 85, line 45 skipping to change at page 88, line 22
The contents of this structure are: The contents of this structure are:
key key
The dictionary key for this value. The dictionary key for this value.
value value
The stored data. The stored data.
6.3. Access Control Policies 6.3. Access Control Policies
Every kind which is storable in an overlay MUST be associated with an Every Kind which is storable in an overlay MUST be associated with an
access control policy. This policy defines whether a request from a access control policy. This policy defines whether a request from a
given node to operate on a given value should succeed or fail. It is given node to operate on a given value should succeed or fail. It is
anticipated that only a small number of generic access control anticipated that only a small number of generic access control
policies are required. To that end, this section describes a small policies are required. To that end, this section describes a small
set of such policies and Section 13.4 establishes a registry for new set of such policies and Section 13.4 establishes a registry for new
policies if required. Each policy has a short string identifier policies if required. Each policy has a short string identifier
which is used to reference it in the configuration document. which is used to reference it in the configuration document.
In the following policies, the term "signer" refers to the signer of In the following policies, the term "signer" refers to the signer of
the StoredValue object and, in the case of non-replica stores, to the the StoredValue object and, in the case of non-replica stores, to the
skipping to change at page 87, line 4 skipping to change at page 89, line 25
be equal to the Node-ID in the certificate and that Node-ID MUST be be equal to the Node-ID in the certificate and that Node-ID MUST be
the one indicated in the SignerIdentity value cert_hash. the one indicated in the SignerIdentity value cert_hash.
6.3.4. NODE-MULTIPLE 6.3.4. NODE-MULTIPLE
In the NODE-MULTIPLE policy, a given value MUST be written (or In the NODE-MULTIPLE policy, a given value MUST be written (or
overwritten) if and only if signer's certificate contains a Node-ID overwritten) if and only if signer's certificate contains a Node-ID
such that H(Node-ID || i) is equal to the Resource-ID for some small such that H(Node-ID || i) is equal to the Resource-ID for some small
integer value of i and that Node-ID is the one indicated in the integer value of i and that Node-ID is the one indicated in the
SignerIdentity value cert_hash. When this policy is in use, the SignerIdentity value cert_hash. When this policy is in use, the
maximum value of i MUST be specified in the kind definition. maximum value of i MUST be specified in the Kind definition.
Note that as i is not carried on the wire, the verifier MUST iterate Note that as i is not carried on the wire, the verifier MUST iterate
through potential i values up to the maximum value in order to through potential i values up to the maximum value in order to
determine whether a store is acceptable. determine whether a store is acceptable.
6.4. Data Storage Methods 6.4. Data Storage Methods
RELOAD provides several methods for storing and retrieving data: RELOAD provides several methods for storing and retrieving data:
o Store values in the overlay o Store values in the overlay
o Fetch values from the overlay o Fetch values from the overlay
o Stat: get metadata about values in the overlay o Stat: get metadata about values in the overlay
o Find the values stored at an individual peer o Find the values stored at an individual peer
These methods are each described in the following sections. These methods are each described in the following sections.
6.4.1. Store 6.4.1. Store
The Store method is used to store data in the overlay. The format of The Store method is used to store data in the overlay. The format of
the Store request depends on the data model which is determined by the Store request depends on the data model which is determined by
the kind. the Kind.
6.4.1.1. Request Definition 6.4.1.1. Request Definition
A StoreReq message is a sequence of StoreKindData values, each of A StoreReq message is a sequence of StoreKindData values, each of
which represents a sequence of stored values for a given kind. The which represents a sequence of stored values for a given Kind. The
same Kind-ID MUST NOT be used twice in a given store request. Each same Kind-ID MUST NOT be used twice in a given store request. Each
value is then processed in turn. These operations MUST be atomic. value is then processed in turn. These operations MUST be atomic.
If any operation fails, the state MUST be rolled back to before the If any operation fails, the state MUST be rolled back to before the
request was received. request was received.
The store request is defined by the StoreReq structure: The store request is defined by the StoreReq structure:
struct { struct {
KindId kind; KindId kind;
uint64 generation_counter; uint64 generation_counter;
skipping to change at page 88, line 17 skipping to change at page 90, line 37
The resource to store at. The resource to store at.
replica_number replica_number
The number of this replica. When a storing peer saves replicas to The number of this replica. When a storing peer saves replicas to
other peers each peer is assigned a replica number starting from 1 other peers each peer is assigned a replica number starting from 1
and sent in the Store message. This field is set to 0 when a node and sent in the Store message. This field is set to 0 when a node
is storing its own data. This allows peers to distinguish replica is storing its own data. This allows peers to distinguish replica
writes from original writes. writes from original writes.
kind_data kind_data
A series of elements, one for each kind of data to be stored. A series of elements, one for each Kind of data to be stored.
If the replica number is zero, then the peer MUST check that it is If the replica number is zero, then the peer MUST check that it is
responsible for the resource and, if not, reject the request. If the responsible for the resource and, if not, reject the request. If the
replica number is nonzero, then the peer MUST check that it expects replica number is nonzero, then the peer MUST check that it expects
to be a replica for the resource and that the request sender is to be a replica for the resource and that the request sender is
consistent with being the responsible node (i.e., that the receiving consistent with being the responsible node (i.e., that the receiving
peer does not know of a better node) and, if not, reject the request. peer does not know of a better node) and, if not, reject the request.
Each StoreKindData element represents the data to be stored for a Each StoreKindData element represents the data to be stored for a
single Kind-ID. The contents of the element are: single Kind-ID. The contents of the element are:
kind kind
The Kind-ID. Implementations MUST reject requests corresponding The Kind-ID. Implementations MUST reject requests corresponding
to unknown kinds. to unknown Kinds.
generation_counter generation_counter
The expected current state of the generation counter The expected current state of the generation counter
(approximately the number of times this object has been written; (approximately the number of times this object has been written;
see below for details). see below for details).
values values
The value or values to be stored. This may contain one or more The value or values to be stored. This may contain one or more
stored_data values depending on the data model associated with stored_data values depending on the data model associated with
each kind. each Kind.
The peer MUST perform the following checks: The peer MUST perform the following checks:
o The Kind-ID is known and supported. o The Kind-ID is known and supported.
o The signatures over each individual data element (if any) are o The signatures over each individual data element (if any) are
valid. If this check fails, the request MUST be rejected with an valid. If this check fails, the request MUST be rejected with an
Error_Forbidden error. Error_Forbidden error.
o Each element is signed by a credential which is authorized to o Each element is signed by a credential which is authorized to
write this kind at this Resource-ID. If this check fails, the write this Kind at this Resource-ID. If this check fails, the
request MUST be rejected with an Error_Forbidden error. request MUST be rejected with an Error_Forbidden error.
o For original (non-replica) stores, the StoreReq is signed by a o For original (non-replica) stores, the StoreReq is signed by a
credential which is authorized to write this kind at this credential which is authorized to write this Kind at this
Resource-Id. If this check fails, the request MUST be rejected Resource-Id. If this check fails, the request MUST be rejected
with an Error_Forbidden error. with an Error_Forbidden error.
o For replica stores, the StoreReq is signed by a Node-Id which is a o For replica stores, the StoreReq is signed by a Node-Id which is a
plausible node to either have originally stored the value or in plausible node to either have originally stored the value or in
the replica set. What this means is overlay specific, but in the the replica set. What this means is overlay specific, but in the
case of the Chord based DHT defined in this specification, replica case of the Chord based DHT defined in this specification, replica
StoreReqs MUST come from nodes which are either in the known StoreReqs MUST come from nodes which are either in the known
replica set for a given resource or which are closer than some replica set for a given resource or which are closer than some
node in the replica set. If this check fails, the request MUST be node in the replica set. If this check fails, the request MUST be
rejected with an Error_Forbidden error. rejected with an Error_Forbidden error.
o For original (non-replica) stores, the peer MUST check that if the o For original (non-replica) stores, the peer MUST check that if the
generation counter is non-zero, it equals the current value of the generation counter is non-zero, it equals the current value of the
generation counter for this kind. This feature allows the generation counter for this Kind. This feature allows the
generation counter to be used in a way similar to the HTTP Etag generation counter to be used in a way similar to the HTTP Etag
feature. feature.
o For replica Stores, the peer MUST set the generation counter to o For replica Stores, the peer MUST set the generation counter to
match the generation counter in the message, and MUST NOT check match the generation counter in the message, and MUST NOT check
the generation counter against the current value. Replica Stores the generation counter against the current value. Replica Stores
MUST NOT use a generation counter of 0. MUST NOT use a generation counter of 0.
o The storage time values are greater than that of any value which o The storage time values are greater than that of any value which
would be replaced by this Store. would be replaced by this Store.
o The size and number of the stored values is consistent with the o The size and number of the stored values is consistent with the
limits specified in the overlay configuration. limits specified in the overlay configuration.
o If the data is signed with identity_type set to "none" and/or o If the data is signed with identity_type set to "none" and/or
SignatureAndHashAlgorithm values set to {0, 0} ("anonymous" and SignatureAndHashAlgorithm values set to {0, 0} ("anonymous" and
"none"), the StoreReq MUST be rejected with an Error_forbidden "none"), the StoreReq MUST be rejected with an Error_forbidden
error. Only synthesized data returned by the storage can use error. Only synthesized data returned by the storage can use
these values these values
If all these checks succeed, the peer MUST attempt to store the data 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 values. For non-replica stores, if the store succeeds and the data
skipping to change at page 90, line 41 skipping to change at page 93, line 22
when it is subsequently fetched. when it is subsequently fetched.
Dictionary: Dictionary:
A store of a dictionary entry replaces (or inserts) the given A store of a dictionary entry replaces (or inserts) the given
value at the location specified by the dictionary key. value at the location specified by the dictionary key.
The following figure shows the relationship between these structures The following figure shows the relationship between these structures
for an example store which stores the following values at resource for an example store which stores the following values at resource
"1234" "1234"
o The value "abc" in the single value location for kind X o The value "abc" in the single value location for Kind X
o The value "foo" at index 0 in the array for kind Y o The value "foo" at index 0 in the array for Kind Y
o The value "bar" at index 1 in the array for kind Y o The value "bar" at index 1 in the array for Kind Y
Store Store
resource=1234 resource=1234
replica_number = 0 replica_number = 0
/ \ / \
/ \ / \
StoreKindData StoreKindData StoreKindData StoreKindData
kind=X (Single-Value) kind=Y (Array) kind=X (Single-Value) kind=Y (Array)
generation_counter = 99 generation_counter = 107 generation_counter = 99 generation_counter = 107
| /\ | /\
| / \ | / \
skipping to change at page 92, line 29 skipping to change at page 95, line 4
Section 6.4.3). Note that the storing peer is not required to Section 6.4.3). Note that the storing peer is not required to
perform this verification. perform this verification.
The response itself is just StoreKindResponse values packed end-to- The response itself is just StoreKindResponse values packed end-to-
end. end.
If any of the generation counters in the request precede the If any of the generation counters in the request precede the
corresponding stored generation counter, then the peer MUST fail the corresponding stored generation counter, then the peer MUST fail the
entire request and respond with an Error_Generation_Counter_Too_Low entire request and respond with an Error_Generation_Counter_Too_Low
error. The error_info in the ErrorResponse MUST be a StoreAns error. The error_info in the ErrorResponse MUST be a StoreAns
response containing the correct generation counter for each kind and response containing the correct generation counter for each Kind and
the replica list, which will be empty. For original (non-replica) the replica list, which will be empty. For original (non-replica)
stores, a node which receives such an error SHOULD attempt to fetch stores, a node which receives such an error SHOULD attempt to fetch
the data and, if the storage_time value is newer, replace its own the data and, if the storage_time value is newer, replace its own
data with that newer data. This rule improves data consistency in data with that newer data. This rule improves data consistency in
the case of partitions and merges. the case of partitions and merges.
If the data being stored is too large for the allowed limit by the If the data being stored is too large for the allowed limit by the
given usage, then the peer MUST fail the request and generate an given usage, then the peer MUST fail the request and generate an
Error_Data_Too_Large error. Error_Data_Too_Large error.
If any type of request tries to access a data kind that the node does If any type of request tries to access a data Kind that the node does
not know about, an Error_Unknown_Kind MUST be generated. The not know about, an Error_Unknown_Kind MUST be generated. The
error_info in the Error_Response is: error_info in the Error_Response is:
KindId unknown_kinds<0..2^8-1>; KindId unknown_kinds<0..2^8-1>;
which lists all the kinds that were unrecognized. A node which which lists all the Kinds that were unrecognized. A node which
receives this error MUST generate a ConfigUpdate message which receives this error MUST generate a ConfigUpdate message which
contains the appropriate kind definition (assuming that in fact a contains the appropriate Kind definition (assuming that in fact a
kind was used which was defined in the configuration document). Kind was used which was defined in the configuration document).
6.4.1.3. Removing Values 6.4.1.3. Removing Values
This version of RELOAD (unlike previous versions) does not have an RELOAD does not have an explicit Remove operation. Rather, values
explicit Remove operation. Rather, values are Removed by storing are Removed by storing "nonexistent" values in their place. Each
"nonexistent" values in their place. Each DataValue contains a DataValue contains a boolean value called "exists" which indicates
boolean value called "exists" which indicates whether a value is whether a value is present at that location. In order to effectively
present at that location. In order to effectively remove a value, remove a value, the owner stores a new DataValue with "exists" set to
the owner stores a new DataValue with "exists" set to "false": "false":
exists = false exists = false
value = {} (0 length) value = {} (0 length)
The owner SHOULD use a lifetime for the nonexistent value at least as The owner SHOULD use a lifetime for the nonexistent value at least as
long as the remainder of the lifetime of the value it is replacing; long as the remainder of the lifetime of the value it is replacing;
otherwise it is possible for the original value to be accidentally or otherwise it is possible for the original value to be accidentally or
maliciously re-stored after the storing node has expired it. Note maliciously re-stored after the storing node has expired it. Note
that there is still a window of vulnerability for replay attack after that there is still a window of vulnerability for replay attack after
the original lifetime has expired (as with any store). This attack the original lifetime has expired (as with any store). This attack
skipping to change at page 93, line 43 skipping to change at page 96, line 16
Note that in the case of arrays and dictionaries, expiration may Note that in the case of arrays and dictionaries, expiration may
create an implicit, unsigned "nonexistent" value to represent a gap create an implicit, unsigned "nonexistent" value to represent a gap
in the data structure, as might happen when any value is aged out. in the data structure, as might happen when any value is aged out.
However, this value isn't persistent nor is it replicated. It is However, this value isn't persistent nor is it replicated. It is
simply synthesized by the storing node. simply synthesized by the storing node.
6.4.2. Fetch 6.4.2. Fetch
The Fetch request retrieves one or more data elements stored at a The Fetch request retrieves one or more data elements stored at a
given Resource-ID. A single Fetch request can retrieve multiple given Resource-ID. A single Fetch request can retrieve multiple
different kinds. different Kinds.
6.4.2.1. Request Definition 6.4.2.1. Request Definition
struct { struct {
int32 first; int32 first;
int32 last; int32 last;
} ArrayRange; } ArrayRange;
struct { struct {
KindId kind; KindId kind;
skipping to change at page 94, line 45 skipping to change at page 97, line 12
The contents of the Fetch requests are as follows: The contents of the Fetch requests are as follows:
resource resource
The Resource-ID to fetch from. The Resource-ID to fetch from.
specifiers specifiers
A sequence of StoredDataSpecifier values, each specifying some of A sequence of StoredDataSpecifier values, each specifying some of
the data values to retrieve. the data values to retrieve.
Each StoredDataSpecifier specifies a single kind of data to retrieve Each StoredDataSpecifier specifies a single Kind of data to retrieve
and (if appropriate) the subset of values that are to be retrieved. and (if appropriate) the subset of values that are to be retrieved.
The contents of the StoredDataSpecifier structure are as follows: The contents of the StoredDataSpecifier structure are as follows:
kind kind
The Kind-ID of the data being fetched. Implementations SHOULD The Kind-ID of the data being fetched. Implementations SHOULD
reject requests corresponding to unknown kinds unless specifically reject requests corresponding to unknown Kinds unless specifically
configured otherwise. configured otherwise.
dataModel dataModel
The data model of the data. This is not transmitted on the wire The data model of the data. This is not transmitted on the wire
but comes from the definition of the kind. but comes from the definition of the Kind.
generation generation
The last generation counter that the requesting node saw. This The last generation counter that the requesting node saw. This
may be used to avoid unnecessary fetches or it may be set to zero. may be used to avoid unnecessary fetches or it may be set to zero.
length length
The length of the rest of the structure, thus allowing The length of the rest of the structure, thus allowing
extensibility. extensibility.
model_specifier model_specifier
A reference to the data value being requested within the data A reference to the data value being requested within the data
model specified for the kind. For instance, if the data model is model specified for the Kind. For instance, if the data model is
"array", it might specify some subset of the values. "array", it might specify some subset of the values.
The model_specifier is as follows: The model_specifier is as follows:
o If the data model is single value, the specifier is empty. o If the data model is single value, the specifier is empty.
o If the data model is array, the specifier contains a list of o If the data model is array, the specifier contains a list of
ArrayRange elements, each of which contains two integers. The ArrayRange elements, each of which contains two integers. The
first integer is the beginning of the range and the second is the first integer is the beginning of the range and the second is the
end of the range. 0 is used to indicate the first element and end of the range. 0 is used to indicate the first element and
0xffffffff is used to indicate the final element. The first 0xffffffff is used to indicate the final element. The first
skipping to change at page 96, line 27 skipping to change at page 98, line 38
FetchKindResponse kind_responses<0..2^32-1>; FetchKindResponse kind_responses<0..2^32-1>;
} FetchAns; } FetchAns;
The FetchAns structure contains a series of FetchKindResponse The FetchAns structure contains a series of FetchKindResponse
structures. There MUST be one FetchKindResponse element for each structures. There MUST be one FetchKindResponse element for each
Kind-ID in the request. Kind-ID in the request.
The contents of the FetchKindResponse structure are as follows: The contents of the FetchKindResponse structure are as follows:
kind kind
the kind that this structure is for. the Kind that this structure is for.
generation generation
the generation counter for this kind. the generation counter for this Kind.
values values
the relevant values. If the generation counter in the request the relevant values. If the generation counter in the request
matches the generation counter in the stored data, then no matches the generation counter in the stored data, then no
StoredData values are returned. Otherwise, all relevant data StoredData values are returned. Otherwise, all relevant data
values MUST be returned. A nonexistent value (i.e., one which the values MUST be returned. A nonexistent value (i.e., one which the
node has no knowledge of) is represented by a synthetic value with node has no knowledge of) is represented by a synthetic value with
"exists" set to False and has an empty signature. Specifically, "exists" set to False and has an empty signature. Specifically,
the identity_type is set to "none", the SignatureAndHashAlgorithm the identity_type is set to "none", the SignatureAndHashAlgorithm
values are set to {0, 0} ("anonymous" and "none" respectively), values are set to {0, 0} ("anonymous" and "none" respectively),
and the signature value is of zero length. This removes the need and the signature value is of zero length. This removes the need
for the responding node to do signatures for values which do not for the responding node to do signatures for values which do not
exist. These signatures are unnecessary as the entire response is exist. These signatures are unnecessary as the entire response is
signed by that node. Note that entries which have been removed by signed by that node. Note that entries which have been removed by
the procedure of Section 6.4.1.3 and have not yet expired also the procedure of Section 6.4.1.3 and have not yet expired also
have exists = false but have valid signatures from the node which have exists = false but have valid signatures from the node which
did the store. did the store.
Upon receipt of a FetchAns message, nodes MUST verify the signatures
on all the received values. Any values with invalid signatures MUST
be discarded. Implementations MAY return the subset of values with
valid signatures, but in that case SHOULD somehow signal to the
application that a partial response was received.
There is one subtle point about signature computation on arrays. If There is one subtle point about signature computation on arrays. If
the storing node uses the append feature (where the the storing node uses the append feature (where the
index=0xffffffff), then the index in the StoredData that is returned index=0xffffffff), then the index in the StoredData that is returned
will not match that used by the storing node, which would break the will not match that used by the storing node, which would break the
signature. In order to avoid this issue, the index value in the signature. In order to avoid this issue, the index value in the
array is set to zero before the signature is computed. This implies array is set to zero before the signature is computed. This implies
that malicious storing nodes can reorder array entries without being that malicious storing nodes can reorder array entries without being
detected. detected.
6.4.3. Stat 6.4.3. Stat
skipping to change at page 101, line 15 skipping to change at page 104, line 15
closest closest
The closest resource ID to the specified resource ID. This is 0 The closest resource ID to the specified resource ID. This is 0
if no resource ID is known. if no resource ID is known.
Note that the response does not contain the contents of the data Note that the response does not contain the contents of the data
stored at these Resource-IDs. If the requester wants this, it must stored at these Resource-IDs. If the requester wants this, it must
retrieve it using Fetch. retrieve it using Fetch.
6.4.5. Defining New Kinds 6.4.5. Defining New Kinds
There are two ways to define a new kind. The first is by writing a There are two ways to define a new Kind. The first is by writing a
document and registering the kind-id with IANA. This is the document and registering the Kind-ID with IANA. This is the
preferred method for kinds which may be widely used and reused. The preferred method for Kinds which may be widely used and reused. The
second method is to simply define the kind and its parameters in the second method is to simply define the Kind and its parameters in the
configuration document using the section of kind-id space set aside configuration document using the section of Kind-id space set aside
for private use. This method MAY be used to define ad hoc kinds in for private use. This method MAY be used to define ad hoc Kinds in
new overlays. new overlays.
However a kind is defined, the definition must include: However a Kind is defined, the definition must include:
o The meaning of the data to be stored (in some textual form). o The meaning of the data to be stored (in some textual form).
o The Kind-ID. o The Kind-ID.
o The data model (single value, array, dictionary, etc). o The data model (single value, array, dictionary, etc).
o The access control model. o The access control model.
In addition, when kinds are registered with IANA, each kind is In addition, when Kinds are registered with IANA, each Kind is
assigned a short string name which is used to refer to it in assigned a short string name which is used to refer to it in
configuration documents. configuration documents.
While each kind needs to define what data model is used for its data, 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 that does not mean that it must define new data models. Where
practical, kinds should use the existing data models. The intention practical, Kinds should use the existing data models. The intention
is that the basic data model set be sufficient for most applications/ is that the basic data model set be sufficient for most applications/
usages. usages.
7. Certificate Store Usage 7. Certificate Store Usage
The Certificate Store usage allows a peer to store its certificate in The Certificate Store usage allows a peer to store its certificate in
the overlay, thus avoiding the need to send a certificate in each the overlay, thus avoiding the need to send a certificate in each
message - a reference may be sent instead. message - a reference may be sent instead.
A user/peer MUST store its certificate at Resource-IDs derived from A user/peer MUST store its certificate at Resource-IDs derived from
skipping to change at page 102, line 18 skipping to change at page 105, line 18
peer's Node-ID but rather at a hash of the peer's Node-ID. The peer's Node-ID but rather at a hash of the peer's Node-ID. The
intention here (as is common throughout RELOAD) is to avoid making a intention here (as is common throughout RELOAD) is to avoid making a
peer responsible for its own data. peer responsible for its own data.
A peer MUST ensure that the user's certificates are stored in the A peer MUST ensure that the user's certificates are stored in the
Overlay Instance. New certificates are stored at the end of the Overlay Instance. New certificates are stored at the end of the
list. This structure allows users to store an old and a new list. This structure allows users to store an old and a new
certificate that both have the same Node-ID, which allows for certificate that both have the same Node-ID, which allows for
migration of certificates when they are renewed. migration of certificates when they are renewed.
This usage defines the following kinds: This usage defines the following Kinds:
Name: CERTIFICATE_BY_NODE Name: CERTIFICATE_BY_NODE
Data Model: The data model for CERTIFICATE_BY_NODE data is array. Data Model: The data model for CERTIFICATE_BY_NODE data is array.
Access Control: NODE-MATCH. Access Control: NODE-MATCH.
Name: CERTIFICATE_BY_USER Name: CERTIFICATE_BY_USER
Data Model: The data model for CERTIFICATE_BY_USER data is array. Data Model: The data model for CERTIFICATE_BY_USER data is array.
skipping to change at page 103, line 35 skipping to change at page 106, line 35
density be an reasonable estimate of the reciprocal of the density be an reasonable estimate of the reciprocal of the
proportion of nodes in the overlay that can act as TURN servers. proportion of nodes in the overlay that can act as TURN servers.
If the turn-density value in the configuration file is too low, If the turn-density value in the configuration file is too low,
then the process of finding TURN servers becomes more expensive as then the process of finding TURN servers becomes more expensive as
multiple candidate Resource-IDs must be probed to find a TURN multiple candidate Resource-IDs must be probed to find a TURN
server. server.
Peers that provide this service need to support the TURN extensions Peers that provide this service need to support the TURN extensions
to STUN for media relay as defined in [RFC5766]. to STUN for media relay as defined in [RFC5766].
This usage defines the following kind to indicate that a peer is This usage defines the following Kind to indicate that a peer is
willing to act as a TURN server: willing to act as a TURN server:
Name TURN-SERVICE Name TURN-SERVICE
Data Model The TURN-SERVICE kind stores a single value for each Data Model The TURN-SERVICE Kind stores a single value for each
Resource-ID. Resource-ID.
Access Control NODE-MULTIPLE, with maximum iteration counter 20. Access Control NODE-MULTIPLE, with maximum iteration counter 20.
Peers can find other servers by selecting a random Resource-ID and Peers can find other servers by selecting a random Resource-ID and
then doing a Find request for the appropriate Kind-ID with that 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 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 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 returned. The returned response may be empty if the peer does not
know of any servers, in which case the process gets repeated with know of any servers, in which case the process gets repeated with
some other random Resource-ID. As long as the ratio of servers some other random Resource-ID. As long as the ratio of servers
relative to peers is not too low, this approach will result in relative to peers is not too low, this approach will result in
finding a server relatively quickly. finding a server relatively quickly.
NOTE TO IMPLEMENTERS: As the access control for this usage is not NOTE TO IMPLEMENTERS: As the access control for this usage is not
CERTIFICATE_BY_NODE or CERTIFICATE_BY_USER, the certificates used by CERTIFICATE_BY_NODE or CERTIFICATE_BY_USER, the certificates used by
TurnServer entries need to be retained as described in Section 5.3.4. TurnServer entries need to be retained as described in Section 5.3.4.
9. Chord Algorithm 9. Chord Algorithm
This algorithm is assigned the name chord-reload to indicate it is an This algorithm is assigned the name CHORD-RELOAD to indicate it is an
adaptation of the basic Chord based DHT algorithm. adaptation of the basic Chord based DHT algorithm.
This algorithm differs from the originally presented Chord algorithm This algorithm differs from the originally presented Chord algorithm
[Chord]. It has been updated based on more recent research results [Chord]. It has been updated based on more recent research results
and implementation experiences, and to adapt it to the RELOAD and implementation experiences, and to adapt it to the RELOAD
protocol. A short list of differences: protocol. A short list of differences:
o The original Chord algorithm specified that a single predecessor o The original Chord algorithm specified that a single predecessor
and a successor list be stored. The chord-reload algorithm and a successor list be stored. The CHORD-RELOAD algorithm
attempts to have more than one predecessor and successor. The attempts to have more than one predecessor and successor. The
predecessor sets help other neighbors learn their successor list. predecessor sets help other neighbors learn their successor list.
o The original Chord specification and analysis called for iterative o The original Chord specification and analysis called for iterative
routing. RELOAD specifies recursive routing. In addition to the routing. RELOAD specifies recursive routing. In addition to the
performance implications, the cost of NAT traversal dictates performance implications, the cost of NAT traversal dictates
recursive routing. recursive routing.
o Finger table entries are indexed in opposite order. Original o Finger table entries are indexed in opposite order. Original
Chord specifies finger[0] as the immediate successor of the peer. Chord specifies finger[0] as the immediate successor of the peer.
chord-reload specifies finger[0] as the peer 180 degrees around CHORD-RELOAD specifies finger[0] as the peer 180 degrees around
the ring from the peer. This change was made to simplify the ring from the peer. This change was made to simplify
discussion and implementation of variable sized finger tables. discussion and implementation of variable sized finger tables.
However, with either approach no more than O(log N) entries should However, with either approach no more than O(log N) entries should
typically be stored in a finger table. typically be stored in a finger table.
o The stabilize() and fix_fingers() algorithms in the original Chord o The stabilize() and fix_fingers() algorithms in the original Chord
algorithm are merged into a single periodic process. algorithm are merged into a single periodic process.
Stabilization is implemented slightly differently because of the Stabilization is implemented slightly differently because of the
larger neighborhood, and fix_fingers is not as aggressive to larger neighborhood, and fix_fingers is not as aggressive to
reduce load, nor does it search for optimal matches of the finger reduce load, nor does it search for optimal matches of the finger
table entries. table entries.
skipping to change at page 116, line 14 skipping to change at page 119, line 14
<multicast-bootstrap address="233.252.0.1" port="6084" /> <multicast-bootstrap address="233.252.0.1" port="6084" />
<clients-permitted> false </clients-permitted> <clients-permitted> false </clients-permitted>
<no-ice> false </no-ice> <no-ice> false </no-ice>
<chord:chord-update-interval> <chord:chord-update-interval>
400</chord:chord-update-interval> 400</chord:chord-update-interval>
<chord:chord-ping-interval>30</chord:chord-ping-interval> <chord:chord-ping-interval>30</chord:chord-ping-interval>
<chord:chord-reactive> true </chord:chord-reactive> <chord:chord-reactive> true </chord:chord-reactive>
<shared-secret> password </shared-secret> <shared-secret> password </shared-secret>
<max-message-size>4000</max-message-size> <max-message-size>4000</max-message-size>
<initial-ttl> 30 </initial-ttl> <initial-ttl> 30 </initial-ttl>
<overlay-reliability-timer> 3000 </overlay-reliability-timer>
<overlay-link-protocol>TLS</overlay-link-protocol> <overlay-link-protocol>TLS</overlay-link-protocol>
<configuration-signer>47112162e84c69ba</configuration-signer> <configuration-signer>47112162e84c69ba</configuration-signer>
<kind-signer> 47112162e84c69ba </kind-signer> <kind-signer> 47112162e84c69ba </kind-signer>
<kind-signer> 6eba45d31a900c06 </kind-signer> <kind-signer> 6eba45d31a900c06 </kind-signer>
<bad-node> 6ebc45d31a900c06 </bad-node> <bad-node> 6ebc45d31a900c06 </bad-node>
<bad-node> 6ebc45d31a900ca6 </bad-node> <bad-node> 6ebc45d31a900ca6 </bad-node>
<ext:example-extension> foo </ext:example-extension> <ext:example-extension> foo </ext:example-extension>
<mandatory-extension> <mandatory-extension>
skipping to change at page 116, line 51 skipping to change at page 120, line 4
<data-model>ARRAY</data-model> <data-model>ARRAY</data-model>
<access-control>NODE-MULTIPLE</access-control> <access-control>NODE-MULTIPLE</access-control>
<max-node-multiple>3</max-node-multiple> <max-node-multiple>3</max-node-multiple>
<max-count>22</max-count> <max-count>22</max-count>
<max-size>4</max-size> <max-size>4</max-size>
<ext:example-kind-extension> 1 <ext:example-kind-extension> 1
</ext:example-kind-extension> </ext:example-kind-extension>
</kind> </kind>
<kind-signature> <kind-signature>
VGhpcyBpcyBub3QgcmlnaHQhCg== VGhpcyBpcyBub3QgcmlnaHQhCg==
</kind-signature>
</kind-signature>
</kind-block> </kind-block>
</required-kinds> </required-kinds>
</configuration> </configuration>
<signature> VGhpcyBpcyBub3QgcmlnaHQhCg== </signature> <signature> VGhpcyBpcyBub3QgcmlnaHQhCg== </signature>
<configuration instance-name="other.example.net"> <configuration instance-name="other.example.net">
</configuration> </configuration>
<signature> VGhpcyBpcyBub3QgcmlnaHQhCg== </signature> <signature> VGhpcyBpcyBub3QgcmlnaHQhCg== </signature>
</overlay> </overlay>
skipping to change at page 119, line 13 skipping to change at page 122, line 13
absent, it is treated as if it were set to "false". 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 9). topology plugin (see Section 9).
chord-ping-interval The ping frequency for the Chord-reload chord-ping-interval The ping frequency for the Chord-reload
topology plugin (see Section 9). topology plugin (see Section 9).
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". overlay. Set to "true" or "false". Default if missing is "true".
(see Section 9). (see Section 9).
shared-secret If shared secret mode is used, this contains the shared-secret If shared secret mode is used, this contains the
shared secret. 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 max-message-size Maximum size in bytes of any message in the
overlay. If this value is not present, the default is 5000. overlay. If this value is not present, the default is 5000.
initial-ttl Initial default TTL (time to live, see Section 5.3.2) initial-ttl Initial default TTL (time to live, see Section 5.3.2)
for messages. If this value is not present, the default is 100. 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 overlay-link-protocol Indicates a permissible overlay link protocol
(see Section 5.6.1 for requirements for such protocols). An (see Section 5.6.1 for requirements for such protocols). An
arbitrary number of these elements may appear. If none appear, arbitrary number of these elements may appear. If none appear,
then this implies the default value, "TLS", which refers to the then this implies the default value, "TLS", which refers to the
use of TLS and DTLS. If one or more elements appear, then no use of TLS and DTLS. If one or more elements appear, then no
default value applies. default value applies.
kind-signer This contains a single Node-ID in hexadecimal and kind-signer This contains a single Node-ID in hexadecimal and
indicates that the certificate with this Node-ID is allowed to indicates that the certificate with this Node-ID is allowed to
sign kinds. Identifying kind-signer by Node-ID instead of sign Kinds. Identifying kind-signer by Node-ID instead of
certificate allows the use of short lived certificates without certificate allows the use of short lived certificates without
constantly having to provide an updated configuration file. constantly having to provide an updated configuration file.
configuration-signer This contains a single Node-ID in hexadecimal configuration-signer This contains a single Node-ID in hexadecimal
and indicates that the certificate with this Node-ID is allowed to and indicates that the certificate with this Node-ID is allowed to
sign configurations for this instance-name. Identifying the sign configurations for this instance-name. Identifying the
signer by Node-ID instead of certificate allows the use of short signer by Node-ID instead of certificate allows the use of short
lived certificates without constantly having to provide an updated lived certificates without constantly having to provide an updated
configuration file. configuration file.
bad-node This contains a single Node-ID in hexadecimal and bad-node This contains a single Node-ID in hexadecimal and
indicates that the certificate with this Node-ID MUST NOT be indicates that the certificate with this Node-ID MUST NOT be
skipping to change at page 120, line 6 skipping to change at page 123, line 15
mandatory-extension This element contains the name of an XML mandatory-extension This element contains the name of an XML
namespace that a node joining the overlay MUST support. The namespace that a node joining the overlay MUST support. The
presence of a mandatory-extension element does not require the presence of a mandatory-extension element does not require the
extension to be used in the current configuration file, but can extension to be used in the current configuration file, but can
indicate that it may be used in the future. Note that the indicate that it may be used in the future. Note that the
namespace is case-sensitive, as specified in [w3c-xml-namespaces] 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. present.
Inside each overlay element, the required-kinds elements can also Inside each overlay element, the required-kinds elements can also
occur. This element indicates the kinds that members must support occur. This element indicates the Kinds that members must support
and contains multiple kind-block elements that each define a single and contains multiple kind-block elements that each define a single
kind that MUST be supported by nodes in the overlay. Each kind-block 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 consists of a single kind element and a kind-signature. The kind
element defines the kind. The kind-signature is the signature element defines the Kind. The kind-signature is the signature
computed over the kind element. computed over the kind element.
Each kind has either an id attribute or a name attribute. The name Each kind has either an id attribute or a name attribute. The name
attribute is a string representing the kind (the name registered to attribute is a string representing the Kind (the name registered to
IANA) while the id is an integer kind-id allocated out of private IANA) while the id is an integer Kind-ID allocated out of private
space. space.
In addition, the kind element contains the following elements: In addition, the kind element contains the following elements:
max-count: the maximum number of values which members of the overlay max-count: the maximum number of values which members of the overlay
must support. must support.
data-model: the data model to be used. data-model: the data model to be used.
max-size: the maximum size of individual values. max-size: the maximum size of individual values.
access-control: the access control model to be used. access-control: the access control model to be used.
max-node-multiple: This is optional and only used when the access max-node-multiple: This is optional and only used when the access
control is NODE-MULTIPLE. This indicates the maximum value for control is NODE-MULTIPLE. This indicates the maximum value for
the i counter. This is an integer greater than 0. the i counter. This is an integer greater than 0.
All of the non optional values MUST be provided. If the kind is All of the non optional values MUST be provided. If the Kind is
registered with IANA, the data-model and access-control elements MUST registered with IANA, the data-model and access-control elements MUST
match those in the kind registration, and clients MUST ignore them in match those in the Kind registration, and clients MUST ignore them in
favor of the IANA versions. Multiple required-kinds elements MAY be favor of the IANA versions. Multiple required-kinds elements MAY be
present. present.
The kind-block element also MUST contain a "kind-signature" element. The kind-block element also MUST contain a "kind-signature" element.
This signature is computed across the kind from the beginning of the 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 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. way as the signature element described later in this section.
The configuration file is a binary file and cannot be changed - The configuration file is a binary file and cannot be changed -
including whitespace changes - or the signature will break. The including whitespace changes - or the signature will break. The
skipping to change at page 121, line 5 skipping to change at page 124, line 14
treating this as a binary blob that is signed using the standard treating this as a binary blob that is signed using the standard
SecurityBlock defined in Section 5.3.4. The SecurityBlock is base 64 SecurityBlock defined in Section 5.3.4. The SecurityBlock is base 64
encoded using the base64 alphabet from RFC[RFC4648] and put in the encoded using the base64 alphabet from RFC[RFC4648] and put in the
signature element following the configuration object in the signature element following the configuration object in the
configuration file. configuration file.
When a node receives a new configuration file, it MUST change its When a node receives a new configuration file, it MUST change its
configuration to meet the new requirements. This may require the 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 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 supporting the new requirements, it MUST exit the overlay. If some
information about a particular kind changes from what the node information about a particular Kind changes from what the node
previously knew about the kind (for example the max size), the new previously knew about the Kind (for example the max size), the new
information in the configuration files overrides any previously information in the configuration files overrides any previously
learned information. If any kind data was signed by a node that is 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 with any stored information of that Kind. Note that forcing an
avalanche restart of the overlay with a configuration change that avalanche restart of the overlay with a configuration change that
requires re-joining the overlay may result in serious performance requires re-joining the overlay may result in serious performance
problems, including total collapse of the network if configuration problems, including total collapse of the network if configuration
parameters are not properly considered. Such an event may be parameters are not properly considered. Such an event may be
necessary in case of a compromised CA or similar problem, but for necessary in case of a compromised CA or similar problem, but for
large overlays should be avoided in almost all circumstances. large overlays should be avoided in almost all circumstances.
10.1.1. Relax NG Grammar 10.1.1. Relax NG Grammar
The grammar for the configuration data is: The grammar for the configuration data is:
skipping to change at page 123, line 45 skipping to change at page 127, line 10
topology-plugin-type |= "CHORD-RELOAD" topology-plugin-type |= "CHORD-RELOAD"
parameter &= element chord:chord-ping-interval { xsd:int }? parameter &= element chord:chord-ping-interval { xsd:int }?
parameter &= element chord:chord-update-interval { xsd:int }? parameter &= element chord:chord-update-interval { xsd:int }?
parameter &= element chord:chord-reactive { xsd:boolean }? parameter &= element chord:chord-reactive { xsd:boolean }?
10.2. Discovery Through Configuration Server 10.2. Discovery Through Configuration Server
When a node first enrolls in a new overlay, it starts with a When a node first enrolls in a new overlay, it starts with a
discovery process to find a configuration server. discovery process to find a configuration server.
The node MAY start by determines the overlay name. This value is The node MAY start by determining the overlay name. This value is
provided by the user or some other out of band provisioning provided by the user or some other out of band provisioning
mechanism. The out of band mechanisms MAY also provide an optional mechanism. The out of band mechanisms MAY also provide an optional
URL for the configuration server. If a URL for the configuration 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 server is not provided, the node MUST do a DNS SRV query using a
Service name of "p2psip-enroll" and a protocol of TCP to find a Service name of "p2psip-enroll" and a protocol of TCP to find a
configuration server and form the URL by appending a path of "/.well- configuration server and form the URL by appending a path of "/.well-
known/p2psip-enroll" to the overlay name. This uses the "well known known/p2psip-enroll" to the overlay name. This uses the "well known
URI" framework defined in [RFC5785]. For example, if the overlay URI" framework defined in [RFC5785]. For example, if the overlay
name was example.com, the URL would be name was example.com, the URL would be
"https://example.com//.well-known/p2psip-enroll". "https://example.com/.well-known/p2psip-enroll".
Once an address and URL for the configuration server is determined, Once an address and URL for the configuration server is determined,
the peer forms an HTTPS connection to that IP address. The the peer forms an HTTPS connection to that IP address. The
certificate MUST match the overlay name as described in [RFC2818]. certificate MUST match the overlay name as described in [RFC2818].
Then the node MUST fetch a new copy of the configuration file. To do 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 this, the peer performs a GET to the URL. The result of the HTTP GET
is an XML configuration file described above, which replaces any is an XML configuration file described above, which replaces any
previously learned configuration file for this overlay. previously learned configuration file for this overlay.
For overlays that do not use a configuration server, nodes obtain the For overlays that do not use a configuration server, nodes obtain the
skipping to change at page 125, line 21 skipping to change at page 128, line 31
returns a certificate. The SubjectAltName field in the certificate returns a certificate. The SubjectAltName field in the certificate
contains the following values: contains the following values:
o One or more Node-IDs which MUST be cryptographically random o One or more Node-IDs which MUST be cryptographically random
[RFC4086]. Each MUST be chosen by the enrollment server in such a [RFC4086]. Each MUST be chosen by the enrollment server in such a
way that they are unpredictable to the requesting user. E.g., the way that they are unpredictable to the requesting user. E.g., the
user MUST NOT be informed of potential (random) Node-IDs prior to user MUST NOT be informed of potential (random) Node-IDs prior to
authenticating. Each is placed in the subjectAltName using the authenticating. Each is placed in the subjectAltName using the
uniformResourceIdentifier type and MUST contain RELOAD URIs as uniformResourceIdentifier type and MUST contain RELOAD URIs as
described in Section 13.15 and MUST contain a Destination list described in Section 13.15 and MUST contain a Destination list
with a single entry of type "node_id". 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-ID, 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 o A single name this user is allowed to use in the overlay, using
type rfc822Name. type rfc822Name.
The certificate is returned as type "application/pkix-cert" as The certificate is returned as type "application/pkix-cert" as
defined in [RFC2585], with an HTTP status code of 200 OK. defined in [RFC2585], with an HTTP status code of 200 OK.
Certificate processing errors should be treated as HTTP errors and Certificate processing errors should be treated as HTTP errors and
have appropriate HTTP status codes. have appropriate HTTP status codes.
The client MUST check that the certificate returned was signed by one The client MUST check that the certificate returned was signed one of
of the certificates received in the "root-cert" list of the overlay the certificates received in the "root-cert" list of the overlay
configuration data. The node then reads the certificate to find the configuration data. The node then reads the certificate to find the
Node-IDs it can use. Node-IDs it can use.
10.3.1. Self-Generated Credentials 10.3.1. Self-Generated Credentials
If the "self-signed-permitted" element is present in the If the "self-signed-permitted" element is present in the
configuration and set to "true", then a node MUST generate its own configuration and set to "true", then a node MUST generate its own
self-signed certificate to join the overlay. The self-signed self-signed certificate to join the overlay. The self-signed
certificate MAY contain any user name of the users choice. certificate MAY contain any user name of the users choice.
skipping to change at page 127, line 7 skipping to change at page 130, line 17
After a node has successfully joined the overlay network, it will After a node has successfully joined the overlay network, it will
have direct connections to several peers. Some MAY be added to the have direct connections to several peers. Some MAY be added to the
cached bootstrap nodes list and used in future boots. Peers that are cached bootstrap nodes list and used in future boots. Peers that are
not directly connected MUST NOT be cached. The suggested number of not directly connected MUST NOT be cached. The suggested number of
peers to cache is 10. Algorithms for determining which peers to peers to cache is 10. Algorithms for determining which peers to
cache are beyond the scope of this specification. cache are beyond the scope of this specification.
11. Message Flow Example 11. Message Flow Example
The following abbreviation are used in the message flow diagrams: JP The following abbreviations are used in the message flow diagrams:
= joining peer, AP = admitting peer, NP = next peer after the AP, NNP JP = joining peer, AP = admitting peer, NP = next peer after the AP,
= next next peer which is the peer after NP, PP = previous peer 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 before the AP, PPP = previous previous peer which is the peer before
the PP, BP = bootstrap peer. the PP, BP = bootstrap peer.
In the following example, we assume that JP has formed a connection 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 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 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 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 AP responds, JP and AP use ICE to set up a connection and then set up
TLS. Once AP has connected to JP, AP sends to JP an Update to TLS. Once AP has connected to JP, AP sends to JP an Update to
populate its Routing Table. The following example shows the Update populate its Routing Table. The following example shows the Update
skipping to change at page 136, line 25 skipping to change at page 139, line 25
the storage. This set of rules makes questions of authorization and the storage. This set of rules makes questions of authorization and
data integrity - which have historically been thorny for overlays - data integrity - which have historically been thorny for overlays -
relatively simple. relatively simple.
12.5.1. Authorization 12.5.1. Authorization
When a client wants to store some value, it first digitally signs the When a client wants to store some value, it first digitally signs the
value with its own private key. It then sends a Store request that value with its own private key. It then sends a Store request that
contains both the value and the signature towards the storing peer contains both the value and the signature towards the storing peer
(which is defined by the Resource Name construction algorithm for (which is defined by the Resource Name construction algorithm for
that particular kind of value). 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 client is authorized to store at this Resource-ID/Kind-ID the storing client is authorized to store at this Resource-ID/Kind-ID
pair. Determining this requires comparing the user's identity to the pair. Determining this requires comparing the user's identity to the
requirements of the access control model (see Section 6.3). If it requirements of the access control model (see Section 6.3). If it
satisfies those requirements the user is authorized to write, pending satisfies those requirements the user is authorized to write, pending
quota checks as described in the next section. quota checks as described in the next section.
For example, consider the certificate with the following properties: For example, consider the certificate with the following properties:
User name: alice@dht.example.com User name: alice@dht.example.com
Node-ID: 013456789abcdef Node-ID: 013456789abcdef
Serial: 1234 Serial: 1234
If Alice wishes to Store a value of the "SIP Location" kind, the If Alice wishes to Store a value of the "SIP Location" Kind, the
Resource Name will be the SIP AOR "sip:alice@dht.example.com". The Resource Name will be the SIP AOR "sip:alice@dht.example.com". The
Resource-ID will be determined by hashing the Resource Name. Because Resource-ID will be determined by hashing the Resource Name. Because
SIP Location uses the USER-NODE-MATCH policy, it first verifies that SIP Location uses the USER-NODE-MATCH policy, it first verifies that
the user name in the certificate hashes to the requested Resource-ID. the user name in the certificate hashes to the requested Resource-ID.
It then verifies that the Node-Id in the certificate matches the It then verifies that the Node-Id in the certificate matches the
dictionary key being used for the store. If both of these checks dictionary key being used for the store. If both of these checks
succeed, the Store is authorized. Note that because the access succeed, the Store is authorized. Note that because the access
control model is different for different kinds, the exact set of control model is different for different Kinds, the exact set of
checks will vary. checks will vary.
12.5.2. Distributed Quota 12.5.2. Distributed Quota
Being a peer in an Overlay Instance carries with it the Being a peer in an Overlay Instance carries with it the
responsibility to store data for a given region of the Overlay responsibility to store data for a given region of the Overlay
Instance. However, allowing clients to store unlimited amounts of Instance. However, allowing clients to store unlimited amounts of
data would create unacceptable burdens on peers and would also enable data would create unacceptable burdens on peers and would also enable
trivial denial of service attacks. RELOAD addresses this issue by trivial denial of service attacks. RELOAD addresses this issue by
requiring configurations to define maximum sizes for each kind of requiring configurations to define maximum sizes for each Kind of
stored data. Attempts to store values exceeding this size MUST be stored data. Attempts to store values exceeding this size MUST be
rejected (if peers are inconsistent about this, then strange rejected (if peers are inconsistent about this, then strange
artifacts will happen when the zone of responsibility shifts and a artifacts will happen when the zone of responsibility shifts and a
different peer becomes responsible for overlarge data). Because each different peer becomes responsible for overlarge data). Because each
Resource-ID/Kind-ID pair is bound to a small set of certificates, Resource-ID/Kind-ID pair is bound to a small set of certificates,
these size restrictions also create a distributed quota mechanism, these size restrictions also create a distributed quota mechanism,
with the quotas administered by the central configuration server. with the quotas administered by the central configuration server.
Allowing different kinds of data to have different size restrictions Allowing different Kinds of data to have different size restrictions
allows new usages the flexibility to define limits that fit their allows new usages the flexibility to define limits that fit their
needs without requiring all usages to have expansive limits. needs without requiring all usages to have expansive limits.
12.5.3. Correctness 12.5.3. Correctness
Because each stored value is signed, it is trivial for any retrieving Because each stored value is signed, it is trivial for any retrieving
peer to verify the integrity of the stored value. Some more care peer to verify the integrity of the stored value. Some more care
needs to be taken to prevent version rollback attacks. Rollback needs to be taken to prevent version rollback attacks. Rollback
attacks on storage are prevented by the use of store times and attacks on storage are prevented by the use of store times and
lifetime values in each store. A lifetime represents the latest time lifetime values in each store. A lifetime represents the latest time
skipping to change at page 138, line 15 skipping to change at page 141, line 15
The certificate-based authentication scheme prevents a single peer The certificate-based authentication scheme prevents a single peer
from being able to forge data owned by other peers. Furthermore, from being able to forge data owned by other peers. Furthermore,
although a subversive peer can refuse to return data resources for although a subversive peer can refuse to return data resources for
which it is responsible, it cannot return forged data because it which it is responsible, it cannot return forged data because it
cannot provide authentication for such registrations. Therefore cannot provide authentication for such registrations. Therefore
parallel searches for redundant registrations can mitigate most of parallel searches for redundant registrations can mitigate most of
the effects of a compromised peer. The ultimate reliability of such the effects of a compromised peer. The ultimate reliability of such
an overlay is a statistical question based on the replication factor an overlay is a statistical question based on the replication factor
and the percentage of compromised peers. and the percentage of compromised peers.
In addition, when a kind is multivalued (e.g., an array data model), In addition, when a Kind is multivalued (e.g., an array data model),
the storing node can return only some subset of the values, thus the storing node can return only some subset of the values, thus
biasing its responses. This can be countered by using single values biasing its responses. This can be countered by using single values
rather than sets, but that makes coordination between multiple rather than sets, but that makes coordination between multiple
storing agents much more difficult. This is a trade off that must be storing agents much more difficult. This is a trade off that must be
made when designing any usage. made when designing any usage.
12.6. Routing Security 12.6. Routing Security
Because the storage security system guarantees (within limits) the Because the storage security system guarantees (within limits) the
integrity of the stored data, routing security focuses on stopping integrity of the stored data, routing security focuses on stopping
skipping to change at page 141, line 13 skipping to change at page 144, line 13
replicated registrations. replicated registrations.
13. IANA Considerations 13. IANA Considerations
This section contains the new code points registered by this This section contains the new code points registered by this
document. [NOTE TO IANA/RFC-EDITOR: Please replace RFC-AAAA with document. [NOTE TO IANA/RFC-EDITOR: Please replace RFC-AAAA with
the RFC number for this specification in the following list.] the RFC number for this specification in the following list.]
13.1. Well-Known URI Registration 13.1. Well-Known URI Registration
IANA will make the following "Well Known URI" registration as IANA SHALL make the following "Well Known URI" registration as
described in [RFC5785]: described in [RFC5785]:
[[Note to RFC Editor - this paragraph can be removed before [[Note to RFC Editor - this paragraph can be removed before
publication. ]] A review request was sent to publication. ]] A review request was sent to
wellknown-uri-review@ietf.org on October 12, 2010. wellknown-uri-review@ietf.org on October 12, 2010.
+----------------------------+----------------------+ +----------------------------+----------------------+
| URI suffix: | p2psip-enroll | | URI suffix: | p2psip-enroll |
| Change controller: | IETF <iesg@ietf.org> | | Change controller: | IETF <iesg@ietf.org> |
| Specification document(s): | [RFC-AAAA] | | Specification document(s): | [RFC-AAAA] |
skipping to change at page 141, line 35 skipping to change at page 144, line 35
+----------------------------+----------------------+ +----------------------------+----------------------+
13.2. Port Registrations 13.2. Port Registrations
[[Note to RFC Editor - this paragraph can be removed before [[Note to RFC Editor - this paragraph can be removed before
publication. ]] IANA has already allocated a TCP port for the main publication. ]] IANA has already allocated a TCP port for the main
peer to peer protocol. This port has the name p2p-sip and the port peer to peer protocol. This port has the name p2p-sip and the port
number of 6084. IANA needs to update this registration to be defined number of 6084. IANA needs to update this registration to be defined
for UDP as well as TCP. for UDP as well as TCP.
IANA will make the following port registration: IANA SHALL make the following port registration:
+------------------------------+------------------------------------+ +------------------------------+------------------------------------+
| Registration Technical | Cullen Jennings <fluffy@cisco.com> | | Registration Technical | Cullen Jennings <fluffy@cisco.com> |
| Contact | | | Contact | |
| Registration Owner | IETF <iesg@ietf.org> | | Registration Owner | IETF <iesg@ietf.org> |
| Transport Protocol | TCP & UDP | | Transport Protocol | TCP & UDP |
| Port Number | 6084 | | Port Number | 6084 |
| Service Name | p2psip-enroll | | Service Name | p2psip-enroll |
| Description | Peer to Peer Infrastructure | | Description | Peer to Peer Infrastructure |
| | Enrollment | | | Enrollment |
skipping to change at page 142, line 20 skipping to change at page 145, line 20
IETF Review. The initial contents of this registry are: IETF Review. The initial contents of this registry are:
+----------------+----------+ +----------------+----------+
| Algorithm Name | RFC | | Algorithm Name | RFC |
+----------------+----------+ +----------------+----------+
| CHORD-RELOAD | RFC-AAAA | | CHORD-RELOAD | RFC-AAAA |
| EXP-OVERLAY | RFC-AAAA | | EXP-OVERLAY | RFC-AAAA |
+----------------+----------+ +----------------+----------+
The value EXP-OVERLAY has been made available for the purposes of The value EXP-OVERLAY has been made available for the purposes of
experimentation. This values is not meant for vendor specific use of experimentation. This value is not meant for vendor specific use of
any sort and it MUST NOT be used for operational deployments. any sort and it MUST NOT be used for operational deployments.
13.4. Access Control Policies 13.4. Access Control Policies
IANA SHALL create a "RELOAD Access Control Policy" Registry. Entries IANA SHALL create a "RELOAD Access Control Policy" Registry. Entries
in this registry are strings denoting access control policies, as in this registry are strings denoting access control policies, as
described in Section 6.3. New entries in this registry SHALL be described in Section 6.3. New entries in this registry SHALL be
registered via RFC 5226 Standards Action. The initial contents of registered via RFC 5226 Standards Action. The initial contents of
this registry are: this registry are:
skipping to change at page 142, line 42 skipping to change at page 145, line 42
| Access Policy | RFC | | Access Policy | RFC |
+-----------------+----------+ +-----------------+----------+
| USER-MATCH | RFC-AAAA | | USER-MATCH | RFC-AAAA |
| NODE-MATCH | RFC-AAAA | | NODE-MATCH | RFC-AAAA |
| USER-NODE-MATCH | RFC-AAAA | | USER-NODE-MATCH | RFC-AAAA |
| NODE-MULTIPLE | RFC-AAAA | | NODE-MULTIPLE | RFC-AAAA |
| EXP-MATCH | RFC-AAAA | | EXP-MATCH | RFC-AAAA |
+-----------------+----------+ +-----------------+----------+
The value EXP-MATCH has been made available for the purposes of The value EXP-MATCH has been made available for the purposes of
experimentation. This values is not meant for vendor specific use of experimentation. This value is not meant for vendor specific use of
any sort and it MUST NOT be used for operational deployments. any sort and it MUST NOT be used for operational deployments.
13.5. Application-ID 13.5. Application-ID
IANA SHALL create a "RELOAD Application-ID" Registry. Entries in IANA SHALL create a "RELOAD Application-ID" Registry. Entries in
this registry are 16-bit integers denoting application kinds. Code this registry are 16-bit integers denoting application Kinds. Code
points in the range 0x0001 to 0x7fff SHALL be registered via RFC 5226 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 Standards Action. Code points in the range 0x8000 to 0xf000 SHALL be
registered via RFC 5226 Expert Review. Code points in the range registered via RFC 5226 Expert Review. Code points in the range
0xf001 to 0xfffe are reserved for private use. The initial contents 0xf001 to 0xfffe are reserved for private use. The initial contents
of this registry are: of this registry are:
+-------------+----------------+-------------------------------+ +-------------+----------------+-------------------------------+
| Application | Application-ID | Specification | | Application | Application-ID | Specification |
+-------------+----------------+-------------------------------+ +-------------+----------------+-------------------------------+
| INVALID | 0 | RFC-AAAA | | INVALID | 0 | RFC-AAAA |
| SIP | 5060 | Reserved for use by SIP Usage | | SIP | 5060 | Reserved for use by SIP Usage |
| SIP | 5061 | Reserved for use by SIP Usage | | SIP | 5061 | Reserved for use by SIP Usage |
| Reserved | 0xffff | RFC-AAAA | | Reserved | 0xffff | RFC-AAAA |
+-------------+----------------+-------------------------------+ +-------------+----------------+-------------------------------+
13.6. Data Kind-ID 13.6. Data Kind-ID
IANA SHALL create a "RELOAD Data Kind-ID" Registry. Entries in this IANA SHALL create a "RELOAD Data Kind-ID" Registry. Entries in this
registry are 32-bit integers denoting data kinds, as described in registry are 32-bit integers denoting data Kinds, as described in
Section 4.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 be registered via RFC 5226 Standards Action. Code points in the
range 0x8000000 to 0xf0000000 SHALL be registered via RFC 5226 Expert range 0x8000000 to 0xf0000000 SHALL be registered via RFC 5226 Expert
Review. Code points in the range 0xf0000001 to 0xfffffffe are Review. Code points in the range 0xf0000001 to 0xfffffffe are
reserved for private use via the kind description mechanism described reserved for private use via the Kind description mechanism described
in Section 10. The initial contents of this registry are: in Section 10. The initial contents of this registry are:
+---------------------+------------+----------+ +---------------------+------------+----------+
| Kind | Kind-ID | RFC | | Kind | Kind-ID | RFC |
+---------------------+------------+----------+ +---------------------+------------+----------+
| INVALID | 0 | RFC-AAAA | | INVALID | 0 | RFC-AAAA |
| TURN_SERVICE | 2 | RFC-AAAA | | TURN-SERVICE | 2 | RFC-AAAA |
| CERTIFICATE_BY_NODE | 3 | RFC-AAAA | | CERTIFICATE_BY_NODE | 3 | RFC-AAAA |
| CERTIFICATE_BY_USER | 16 | RFC-AAAA | | CERTIFICATE_BY_USER | 16 | RFC-AAAA |
| Reserved | 0x7fffffff | RFC-AAAA | | Reserved | 0x7fffffff | RFC-AAAA |
| Reserved | 0xfffffffe | RFC-AAAA | | Reserved | 0xfffffffe | RFC-AAAA |
+---------------------+------------+----------+ +---------------------+------------+----------+
13.7. Data Model 13.7. Data Model
IANA SHALL create a "RELOAD Data Model" Registry. Entries in this IANA SHALL create a "RELOAD Data Model" Registry. Entries in this
registry denoting data models, as described in Section 6.2. Code registry denoting data models, as described in Section 6.2. Code
skipping to change at page 144, line 17 skipping to change at page 147, line 17
+------------+----------+ +------------+----------+
| INVALID | RFC-AAAA | | INVALID | RFC-AAAA |
| SINGLE | RFC-AAAA | | SINGLE | RFC-AAAA |
| ARRAY | RFC-AAAA | | ARRAY | RFC-AAAA |
| DICTIONARY | RFC-AAAA | | DICTIONARY | RFC-AAAA |
| EXP-DATA | RFC-AAAA | | EXP-DATA | RFC-AAAA |
| RESERVED | RFC-AAAA | | RESERVED | RFC-AAAA |
+------------+----------+ +------------+----------+
The value EXP-DATA has been made available for the purposes of The value EXP-DATA has been made available for the purposes of
experimentation. This values is not meant for vendor specific use of experimentation. This value is not meant for vendor specific use of
any sort and it MUST NOT be used for operational deployments. any sort and it MUST NOT be used for operational deployments.
13.8. Message Codes 13.8. Message Codes
IANA SHALL create a "RELOAD Message Code" Registry. Entries in this IANA SHALL create a "RELOAD Message Code" Registry. Entries in this
registry are 16-bit integers denoting method codes as described in registry are 16-bit integers denoting method codes as described in
Section 5.3.3. These codes SHALL be registered via RFC 5226 Section 5.3.3. These codes SHALL be registered via RFC 5226
Standards Action. The initial contents of this registry are: Standards Action. The initial contents of this registry are:
+---------------------------------+----------------+----------+ +---------------------------------+----------------+----------+
skipping to change at page 146, line 47 skipping to change at page 149, line 47
| reserved | 0x8000..0xfffe | RFC-AAAA | | reserved | 0x8000..0xfffe | RFC-AAAA |
+-------------------------------------+----------------+----------+ +-------------------------------------+----------------+----------+
The values Error_Exp_A and Error_Exp_B have been made available for The values Error_Exp_A and Error_Exp_B have been made available for
the purposes of experimentation. These values are not meant for the purposes of experimentation. These values are not meant for
vendor specific use of any sort and MUST NOT be used for operational vendor specific use of any sort and MUST NOT be used for operational
deployments. deployments.
13.10. Overlay Link Types 13.10. Overlay Link Types
IANA shall create a "RELOAD Overlay Link." New entries SHALL be IANA SHALL create a "RELOAD Overlay Link Registry." New entries
defined via RFC 5226 Standards Action. This registry SHALL be SHALL be defined via RFC 5226 Standards Action. This registry SHALL
initially populated with the following values: be initially populated with the following values:
+--------------------+------+---------------+ +--------------------+------+---------------+
| Protocol | Code | Specification | | Protocol | Code | Specification |
+--------------------+------+---------------+ +--------------------+------+---------------+
| reserved | 0 | RFC-AAAA | | reserved | 0 | RFC-AAAA |
| DTLS-UDP-SR | 1 | RFC-AAAA | | DTLS-UDP-SR | 1 | RFC-AAAA |
| DTLS-UDP-SR-NO-ICE | 3 | RFC-AAAA | | DTLS-UDP-SR-NO-ICE | 3 | RFC-AAAA |
| TLS-TCP-FH-NO-ICE | 4 | RFC-AAAA | | TLS-TCP-FH-NO-ICE | 4 | RFC-AAAA |
| EXP-LINK | 5 | RFC-AAAA | | EXP-LINK | 5 | RFC-AAAA |
| reserved | 255 | RFC-AAAA | | reserved | 255 | RFC-AAAA |
+--------------------+------+---------------+ +--------------------+------+---------------+
The value EXP-LINK has been made available for the purposes of The value EXP-LINK has been made available for the purposes of
experimentation. This values is not meant for vendor specific use of experimentation. This value is not meant for vendor specific use of
any sort and it MUST NOT be used for operational deployments. any sort and it MUST NOT be used for operational deployments.
13.11. Overlay Link Protocols 13.11. Overlay Link Protocols
IANA shall create an "Overlay Link Protocol Registry". Entries in IANA SHALL create an "Overlay Link Protocol Registry". Entries in
this registry SHALL be defined via RFC 5226 Standards Action. This this registry SHALL be defined via RFC 5226 Standards Action. This
registry SHALL be initially populated with the following valuse: registry SHALL be initially populated with the following valuse:
+---------------+---------------+ +---------------+---------------+
| Link Protocol | Specification | | Link Protocol | Specification |
+---------------+---------------+ +---------------+---------------+
| TLS | RFC-AAAA | | TLS | RFC-AAAA |
| EXP-PROTOCOL | RFC-AAAA | | EXP-PROTOCOL | RFC-AAAA |
+---------------+---------------+ +---------------+---------------+
The value EXP-PROTOCOL has been made available for the purposes of The value EXP-PROTOCOL has been made available for the purposes of
experimentation. This values is not meant for vendor specific use of experimentation. This value is not meant for vendor specific use of
any sort and it MUST NOT be used for operational deployments. any sort and it MUST NOT be used for operational deployments.
13.12. Forwarding Options 13.12. Forwarding Options
IANA shall create a "Forwarding Option Registry". Entries in this IANA SHALL create a "Forwarding Option Registry". Entries in this
registry between 1 and 127 SHALL be defined via RFC 5226 Standards registry between 1 and 127 SHALL be defined via RFC 5226 Standards
Action. Entries in this registry between 128 and 254 SHALL be Action. Entries in this registry between 128 and 254 SHALL be
defined via RFC 5226 Specification Required. This registry SHALL be defined via RFC 5226 Specification Required. This registry SHALL be
initially populated with the following values: initially populated with the following values:
+-------------------+------+---------------+ +-------------------+------+---------------+
| Forwarding Option | Code | Specification | | Forwarding Option | Code | Specification |
+-------------------+------+---------------+ +-------------------+------+---------------+
| invalid | 0 | RFC-AAAA | | invalid | 0 | RFC-AAAA |
| exp-forward | 1 | RFC-AAAA | | exp-forward | 1 | RFC-AAAA |
| reserved | 255 | RFC-AAAA | | reserved | 255 | RFC-AAAA |
+-------------------+------+---------------+ +-------------------+------+---------------+
The value exp-forward has been made available for the purposes of The value exp-forward has been made available for the purposes of
experimentation. This values is not meant for vendor specific use of experimentation. This value is not meant for vendor specific use of
any sort and it MUST NOT be used for operational deployments. any sort and it MUST NOT be used for operational deployments.
13.13. Probe Information Types 13.13. Probe Information Types
IANA shall create a "RELOAD Probe Information Type Registry". IANA SHALL create a "RELOAD Probe Information Type Registry".
Entries in this registry SHALL be defined via RFC 5226 Standards Entries in this registry SHALL be defined via RFC 5226 Standards
Action. This registry SHALL be initially populated with the Action. This registry SHALL be initially populated with the
following values: following values:
+-----------------+------+---------------+ +-----------------+------+---------------+
| Probe Option | Code | Specification | | Probe Option | Code | Specification |
+-----------------+------+---------------+ +-----------------+------+---------------+
| invalid | 0 | RFC-AAAA | | invalid | 0 | RFC-AAAA |
| responsible_set | 1 | RFC-AAAA | | responsible_set | 1 | RFC-AAAA |
| num_resources | 2 | RFC-AAAA | | num_resources | 2 | RFC-AAAA |
| uptime | 3 | RFC-AAAA | | uptime | 3 | RFC-AAAA |
| exp-probe | 4 | RFC-AAAA | | exp-probe | 4 | RFC-AAAA |
| reserved | 255 | RFC-AAAA | | reserved | 255 | RFC-AAAA |
+-----------------+------+---------------+ +-----------------+------+---------------+
The value exp-probe has been made available for the purposes of The value exp-probe has been made available for the purposes of
experimentation. This values is not meant for vendor specific use of experimentation. This value is not meant for vendor specific use of
any sort and it MUST NOT be used for operational deployments. any sort and it MUST NOT be used for operational deployments.
13.14. Message Extensions 13.14. Message Extensions
IANA shall create a "RELOAD Extensions Registry". Entries in this IANA SHALL create a "RELOAD Extensions Registry". Entries in this
registry SHALL be defined via RFC 5226 Specification Required. This registry SHALL be defined via RFC 5226 Specification Required. This
registry SHALL be initially populated with the following values: registry SHALL be initially populated with the following values:
+-----------------+--------+---------------+ +-----------------+--------+---------------+
| Extensions Name | Code | Specification | | Extensions Name | Code | Specification |
+-----------------+--------+---------------+ +-----------------+--------+---------------+
| invalid | 0 | RFC-AAAA | | invalid | 0 | RFC-AAAA |
| exp-ext | 1 | RFC-AAAA | | exp-ext | 1 | RFC-AAAA |
| reserved | 0xFFFF | RFC-AAAA | | reserved | 0xFFFF | RFC-AAAA |
+-----------------+--------+---------------+ +-----------------+--------+---------------+
The value exp-ext has been made available for the purposes of The value exp-ext has been made available for the purposes of
experimentation. This values is not meant for vendor specific use of experimentation. This value is not meant for vendor specific use of
any sort and it MUST NOT be used for operational deployments. any sort and it MUST NOT be used for operational deployments.
13.15. reload URI Scheme 13.15. reload URI Scheme
This section describes the scheme for a reload URI, which can be used This section describes the scheme for a reload URI, which can be used
to refer to either: to refer to either:
o A peer. o A peer.
o A resource inside a peer. o A resource inside a peer.
skipping to change at page 150, line 32 skipping to change at page 153, line 32
Subtype name: p2p-overlay+xml Subtype name: p2p-overlay+xml
Required parameters: none Required parameters: none
Optional parameters: none Optional parameters: none
Encoding considerations: Must be binary encoded. Encoding considerations: Must be binary encoded.
Security considerations: This media type is typically not used to Security considerations: This media type is typically not used to
transport information that typically needs to be kept confidential transport information that needs to be kept confidential, however
however there are cases where it is integrity of the information is there are cases where it is integrity of the information is
important. For these cases using a digital signature is RECOMMENDED. important. For these cases using a digital signature is RECOMMENDED.
One way of doing this is specified in RFC-AAAA. In the case when the One way of doing this is specified in RFC-AAAA. In the case when the
media includes a "shared-secret" element, then the contents of the media includes a "shared-secret" element, then the contents of the
file need to be kept confidential or else anyone that can see the file need to be kept confidential or else anyone that can see the
shared-secret and effect the RELOAD overlay network. shared-secret and effect the RELOAD overlay network.
Interoperability considerations: No knows interoperability Interoperability considerations: No known interoperability
consideration beyond those identified for application/xml in consideration beyond those identified for application/xml in
[RFC3023]. [RFC3023].
Published specification: RFC-AAAA Published specification: RFC-AAAA
Applications that use this media type: The type is used to configure Applications that use this media type: The type is used to configure
the peer to peer overlay networks defined in RFC-AAAA. the peer to peer overlay networks defined in RFC-AAAA.
Additional information: The syntax for this media type is specified Additional information: The syntax for this media type is specified
in Section 10.1 of RFC-AAAA. The contents MUST be valid XML in Section 10.1 of RFC-AAAA. The contents MUST be valid XML
skipping to change at page 151, line 41 skipping to change at page 154, line 41
draft by Salman A. Baset, Henning Schulzrinne, and Marcin draft by Salman A. Baset, Henning Schulzrinne, and Marcin
Matuszewski. Thanks to the authors of RFC 5389 for text included Matuszewski. Thanks to the authors of RFC 5389 for text included
from that. Vidya Narayanan provided many comments and improvements. from that. Vidya Narayanan provided many comments and improvements.
The ideas and text for the Chord specific extension data to the Leave The ideas and text for the Chord specific extension data to the Leave
mechanisms was provided by Jouni Maenpaa, Gonzalo Camarillo, and Jani mechanisms was provided by Jouni Maenpaa, Gonzalo Camarillo, and Jani
Hautakorpi. Hautakorpi.
Thanks to the many people who contributed including Ted Hardie, Thanks to the many people who contributed including Ted Hardie,
Michael Chen, Dan York, Das Saumitra, Lyndsay Campbell, Brian Rosen, Michael Chen, Dan York, Das Saumitra, Lyndsay Campbell, Brian Rosen,
David Bryan, Dave Craig, and Julian Cain. Extensive working last David Bryan, Dave Craig, and Julian Cain. Extensive last call
call comments were provided by: Jouni Maenpaa, Roni Even, Gonzalo comments were provided by: Jouni Maenpaa, Roni Even, Gonzalo
Camarillo, Ari Keranen, John Buford, Michael Chen, Frederic-Philippe Camarillo, Ari Keranen, John Buford, Michael Chen, Frederic-Philippe
Met, and David Bryan. Special thanks to Marc Petit-Huguenin who Met, Mary Barnes, and David Bryan. Special thanks to Marc Petit-
provied an amazing amount to detailed review. Huguenin who provided an amazing amount of detailed review.
15. References 15. References
15.1. Normative References 15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key
Infrastructure Operational Protocols: FTP and HTTP", Infrastructure Operational Protocols: FTP and HTTP",
RFC 2585, May 1999. RFC 2585, May 1999.
skipping to change at page 153, line 20 skipping to change at page 156, line 20
(CMC): Transport Protocols", RFC 5273, June 2008. (CMC): Transport Protocols", RFC 5273, June 2008.
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification", Friendly Rate Control (TFRC): Protocol Specification",
RFC 5348, September 2008. RFC 5348, September 2008.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. October 2008.
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
for Application Designers", BCP 145, RFC 5405,
November 2008.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, August 2010. Address Text Representation", RFC 5952, August 2010.
[RFC6091] Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys [RFC6091] Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys
for Transport Layer Security (TLS) Authentication", for Transport Layer Security (TLS) Authentication",
RFC 6091, February 2011. RFC 6091, February 2011.
skipping to change at page 154, line 16 skipping to change at page 157, line 20
[I-D.ietf-hip-reload-instance] [I-D.ietf-hip-reload-instance]
Keranen, A., Camarillo, G., and J. Maenpaa, "Host Identity Keranen, A., Camarillo, G., and J. Maenpaa, "Host Identity
Protocol-Based Overlay Networking Environment (HIP BONE) Protocol-Based Overlay Networking Environment (HIP BONE)
Instance Specification for REsource LOcation And Discovery Instance Specification for REsource LOcation And Discovery
(RELOAD)", draft-ietf-hip-reload-instance-03 (work in (RELOAD)", draft-ietf-hip-reload-instance-03 (work in
progress), January 2011. progress), January 2011.
[I-D.ietf-mmusic-ice-tcp] [I-D.ietf-mmusic-ice-tcp]
Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach,
"TCP Candidates with Interactive Connectivity "TCP Candidates with Interactive Connectivity
Establishment (ICE)", draft-ietf-mmusic-ice-tcp-13 (work Establishment (ICE)", draft-ietf-mmusic-ice-tcp-15 (work
in progress), April 2011. in progress), September 2011.
[I-D.ietf-p2psip-self-tuning] [I-D.ietf-p2psip-self-tuning]
Maenpaa, J., Camarillo, G., and J. Hautakorpi, "A Self- Maenpaa, J., Camarillo, G., and J. Hautakorpi, "A Self-
tuning Distributed Hash Table (DHT) for REsource LOcation tuning Distributed Hash Table (DHT) for REsource LOcation
And Discovery (RELOAD)", draft-ietf-p2psip-self-tuning-04 And Discovery (RELOAD)", draft-ietf-p2psip-self-tuning-04
(work in progress), July 2011. (work in progress), July 2011.
[I-D.ietf-p2psip-service-discovery] [I-D.ietf-p2psip-service-discovery]
Maenpaa, J. and G. Camarillo, "Service Discovery Usage for Maenpaa, J. and G. Camarillo, "Service Discovery Usage for
REsource LOcation And Discovery (RELOAD)", REsource LOcation And Discovery (RELOAD)",
skipping to change at page 161, line 5 skipping to change at page 164, line 11
peer that implements the server-side functionality required by the peer that implements the server-side functionality required by the
SIP protocol. In this case, the peer would be acting as if it were SIP protocol. In this case, the peer would be acting as if it were
the user's peer, and would need the appropriate credentials for that the user's peer, and would need the appropriate credentials for that
user. user.
Application-level support for clients is defined by a usage. A usage Application-level support for clients is defined by a usage. A usage
offering support for application-level clients should specify how the offering support for application-level clients should specify how the
security of the system is maintained when the data is moved between security of the system is maintained when the data is moved between
the application and RELOAD layers. the application and RELOAD layers.
Appendix C. Change Log
C.1. Changes since draft-ietf-p2psip-reload-13
Note to RFC Editor: Please remove this section.
o Fixed finger formula.
o Support for getting a certificate with multiple Node-IDs.
o Added configuration signer.
o Added way to specify mandatory extensions in configuration file.
Authors' Addresses Authors' Addresses
Cullen Jennings Cullen Jennings
Cisco Cisco
170 West Tasman Drive 170 West Tasman Drive
MS: SJC-21/2 MS: SJC-21/2
San Jose, CA 95134 San Jose, CA 95134
USA USA
Phone: +1 408 421-9990 Phone: +1 408 421-9990
 End of changes. 181 change blocks. 
496 lines changed or deleted 620 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/