draft-ietf-p2psip-base-07.txt   draft-ietf-p2psip-base-08.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: August 21, 2010 Skype Expires: September 8, 2010 Skype
E. Rescorla E. Rescorla
Network Resonance Network Resonance
S. Baset S. Baset
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
February 17, 2010 March 7, 2010
REsource LOcation And Discovery (RELOAD) Base Protocol REsource LOcation And Discovery (RELOAD) Base Protocol
draft-ietf-p2psip-base-07 draft-ietf-p2psip-base-08
Abstract Abstract
In this document the term BCP 78 and BCP 79 refer to RFC 3978 and RFC In this document the term BCP 78 and BCP 79 refer to RFC 3978 and RFC
3979 respectively. They refer only to those RFCs and not to any 3979 respectively. They refer only to those RFCs and not to any
documents that update or supersede them. documents that update or supersede them.
This document defines REsource LOcation And Discovery (RELOAD), a This specification defines REsource LOcation And Discovery (RELOAD),
peer-to-peer (P2P) signaling protocol for use on the Internet. A P2P a peer-to-peer (P2P) signaling protocol for use on the Internet. A
signaling protocol provides its clients with an abstract storage and P2P signaling protocol provides its clients with an abstract storage
messaging service between a set of cooperating peers that form the and messaging service between a set of cooperating peers that form
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
a fundamental service of the protocol. RELOAD also allows access a fundamental service of the protocol. RELOAD also allows access
from "client" nodes that do not need to route traffic or store data from "client" nodes that do not need to route traffic or store data
for others. for others.
Legal Legal
skipping to change at page 2, line 23 skipping to change at page 2, line 23
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 21, 2010. This Internet-Draft will expire on September 8, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 18 skipping to change at page 3, line 18
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 . . . . . . . . . . . . . . . . . . . . . . 14
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 . . . . . . . . 15
1.3. Security . . . . . . . . . . . . . . . . . . . . . . . . 16 1.3. Security . . . . . . . . . . . . . . . . . . . . . . . . 16
1.4. Structure of This Document . . . . . . . . . . . . . . . 17 1.4. Structure of This Document . . . . . . . . . . . . . . . 17
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 17 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 17
3. Overlay Management Overview . . . . . . . . . . . . . . . . . 19 3. Overlay Management Overview . . . . . . . . . . . . . . . . . 20
3.1. Security and Identification . . . . . . . . . . . . . . 20 3.1. Security and Identification . . . . . . . . . . . . . . 20
3.1.1. Shared-Key Security . . . . . . . . . . . . . . . . 21 3.1.1. Shared-Key Security . . . . . . . . . . . . . . . . 21
3.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . 21 3.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.1. Client Routing . . . . . . . . . . . . . . . . . . . 22 3.2.1. Client Routing . . . . . . . . . . . . . . . . . . . 22
3.2.2. Minimum Functionality Requirements for Clients . . . 22 3.2.2. Minimum Functionality Requirements for Clients . . . 22
3.3. Routing . . . . . . . . . . . . . . . . . . . . . . . . 23 3.3. Routing . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4. Connectivity Management . . . . . . . . . . . . . . . . 25 3.4. Connectivity Management . . . . . . . . . . . . . . . . 25
3.5. Overlay Algorithm Support . . . . . . . . . . . . . . . 26 3.5. Overlay Algorithm Support . . . . . . . . . . . . . . . 26
3.5.1. Support for Pluggable Overlay Algorithms . . . . . . 26 3.5.1. Support for Pluggable Overlay Algorithms . . . . . . 26
3.5.2. Joining, Leaving, and Maintenance Overview . . . . . 26 3.5.2. Joining, Leaving, and Maintenance Overview . . . . . 26
3.6. First-Time Setup . . . . . . . . . . . . . . . . . . . . 28 3.6. First-Time Setup . . . . . . . . . . . . . . . . . . . . 28
3.6.1. Initial Configuration . . . . . . . . . . . . . . . 28 3.6.1. Initial Configuration . . . . . . . . . . . . . . . 28
3.6.2. Enrollment . . . . . . . . . . . . . . . . . . . . . 28 3.6.2. Enrollment . . . . . . . . . . . . . . . . . . . . . 28
4. Application Support Overview . . . . . . . . . . . . . . . . 28 4. Application Support Overview . . . . . . . . . . . . . . . . 29
4.1. Data Storage . . . . . . . . . . . . . . . . . . . . . . 29 4.1. Data Storage . . . . . . . . . . . . . . . . . . . . . . 29
4.1.1. Storage Permissions . . . . . . . . . . . . . . . . 30 4.1.1. Storage Permissions . . . . . . . . . . . . . . . . 30
4.1.2. Usages . . . . . . . . . . . . . . . . . . . . . . . 31 4.1.2. Usages . . . . . . . . . . . . . . . . . . . . . . . 31
4.1.3. Replication . . . . . . . . . . . . . . . . . . . . 31 4.1.3. Replication . . . . . . . . . . . . . . . . . . . . 31
4.2. Service Discovery . . . . . . . . . . . . . . . . . . . 32 4.2. Service Discovery . . . . . . . . . . . . . . . . . . . 32
4.3. Application Connectivity . . . . . . . . . . . . . . . . 32 4.3. Application Connectivity . . . . . . . . . . . . . . . . 32
5. Overlay Management Protocol . . . . . . . . . . . . . . . . . 33 5. Overlay Management Protocol . . . . . . . . . . . . . . . . . 33
5.1. Message Receipt and Forwarding . . . . . . . . . . . . . 33 5.1. Message Receipt and Forwarding . . . . . . . . . . . . . 33
5.1.1. Responsible ID . . . . . . . . . . . . . . . . . . . 33 5.1.1. Responsible ID . . . . . . . . . . . . . . . . . . . 33
5.1.2. Other ID . . . . . . . . . . . . . . . . . . . . . . 34 5.1.2. Other ID . . . . . . . . . . . . . . . . . . . . . . 34
5.1.3. Private ID . . . . . . . . . . . . . . . . . . . . . 35 5.1.3. Private ID . . . . . . . . . . . . . . . . . . . . . 35
5.2. Symmetric Recursive Routing . . . . . . . . . . . . . . 35 5.2. Symmetric Recursive Routing . . . . . . . . . . . . . . 35
5.2.1. Request Origination . . . . . . . . . . . . . . . . 35 5.2.1. Request Origination . . . . . . . . . . . . . . . . 35
5.2.2. Response Origination . . . . . . . . . . . . . . . . 36 5.2.2. Response Origination . . . . . . . . . . . . . . . . 36
5.3. Message Structure . . . . . . . . . . . . . . . . . . . 36 5.3. Message Structure . . . . . . . . . . . . . . . . . . . 37
5.3.1. Presentation Language . . . . . . . . . . . . . . . 37 5.3.1. Presentation Language . . . . . . . . . . . . . . . 37
5.3.1.1. Common Definitions . . . . . . . . . . . . . . . 38 5.3.1.1. Common Definitions . . . . . . . . . . . . . . . 38
5.3.2. Forwarding Header . . . . . . . . . . . . . . . . . 40 5.3.2. Forwarding Header . . . . . . . . . . . . . . . . . 40
5.3.2.1. Processing Configuration Sequence Numbers . . . . 42 5.3.2.1. Processing Configuration Sequence Numbers . . . . 42
5.3.2.2. Destination and Via Lists . . . . . . . . . . . . 43 5.3.2.2. Destination and Via Lists . . . . . . . . . . . . 43
5.3.2.3. Forwarding Options . . . . . . . . . . . . . . . 45 5.3.2.3. Forwarding Options . . . . . . . . . . . . . . . 45
5.3.3. Message Contents Format . . . . . . . . . . . . . . 46 5.3.2.4. Direct Return Response Forwarding Options . . . . 46
5.3.3.1. Response Codes and Response Errors . . . . . . . 47 5.3.3. Message Contents Format . . . . . . . . . . . . . . 47
5.3.4. Security Block . . . . . . . . . . . . . . . . . . . 49 5.3.3.1. Response Codes and Response Errors . . . . . . . 48
5.4. Overlay Topology . . . . . . . . . . . . . . . . . . . . 52 5.3.4. Security Block . . . . . . . . . . . . . . . . . . . 50
5.4.1. Topology Plugin Requirements . . . . . . . . . . . . 52 5.4. Overlay Topology . . . . . . . . . . . . . . . . . . . . 53
5.4.2. Methods and types for use by topology plugins . . . 52 5.4.1. Topology Plugin Requirements . . . . . . . . . . . . 53
5.4.2.1. Join . . . . . . . . . . . . . . . . . . . . . . 52 5.4.2. Methods and types for use by topology plugins . . . 54
5.4.2.2. Leave . . . . . . . . . . . . . . . . . . . . . . 53 5.4.2.1. Join . . . . . . . . . . . . . . . . . . . . . . 54
5.4.2.3. Update . . . . . . . . . . . . . . . . . . . . . 54 5.4.2.2. Leave . . . . . . . . . . . . . . . . . . . . . . 55
5.4.2.4. Route_Query . . . . . . . . . . . . . . . . . . . 54 5.4.2.3. Update . . . . . . . . . . . . . . . . . . . . . 55
5.4.2.5. Probe . . . . . . . . . . . . . . . . . . . . . . 55 5.4.2.4. Route_Query . . . . . . . . . . . . . . . . . . . 56
5.5. Forwarding and Link Management Layer . . . . . . . . . . 57 5.4.2.5. Probe . . . . . . . . . . . . . . . . . . . . . . 57
5.5.1. Attach . . . . . . . . . . . . . . . . . . . . . . . 58 5.5. Forwarding and Link Management Layer . . . . . . . . . . 59
5.5.1.1. Request Definition . . . . . . . . . . . . . . . 58 5.5.1. Attach . . . . . . . . . . . . . . . . . . . . . . . 59
5.5.1.2. Response Definition . . . . . . . . . . . . . . . 61 5.5.1.1. Request Definition . . . . . . . . . . . . . . . 60
5.5.1.3. Using ICE With RELOAD . . . . . . . . . . . . . . 61 5.5.1.2. Response Definition . . . . . . . . . . . . . . . 62
5.5.1.4. Collecting STUN Servers . . . . . . . . . . . . . 61 5.5.1.3. Using ICE With RELOAD . . . . . . . . . . . . . . 62
5.5.1.5. Gathering Candidates . . . . . . . . . . . . . . 62 5.5.1.4. Collecting STUN Servers . . . . . . . . . . . . . 62
5.5.1.6. Prioritizing Candidates . . . . . . . . . . . . . 63 5.5.1.5. Gathering Candidates . . . . . . . . . . . . . . 63
5.5.1.7. Encoding the Attach Message . . . . . . . . . . . 63 5.5.1.6. Prioritizing Candidates . . . . . . . . . . . . . 64
5.5.1.8. Verifying ICE Support . . . . . . . . . . . . . . 64 5.5.1.7. Encoding the Attach Message . . . . . . . . . . . 64
5.5.1.9. Role Determination . . . . . . . . . . . . . . . 64 5.5.1.8. Verifying ICE Support . . . . . . . . . . . . . . 65
5.5.1.10. Full ICE . . . . . . . . . . . . . . . . . . . . 64 5.5.1.9. Role Determination . . . . . . . . . . . . . . . 65
5.5.1.11. No ICE . . . . . . . . . . . . . . . . . . . . . 65 5.5.1.10. Full ICE . . . . . . . . . . . . . . . . . . . . 65
5.5.1.12. Subsequent Offers and Answers . . . . . . . . . . 65 5.5.1.11. No ICE . . . . . . . . . . . . . . . . . . . . . 66
5.5.1.13. Sending Media . . . . . . . . . . . . . . . . . . 65 5.5.1.12. Subsequent Offers and Answers . . . . . . . . . . 66
5.5.1.14. Receiving Media . . . . . . . . . . . . . . . . . 66 5.5.1.13. Sending Media . . . . . . . . . . . . . . . . . . 66
5.5.2. AppAttach . . . . . . . . . . . . . . . . . . . . . 66 5.5.1.14. Receiving Media . . . . . . . . . . . . . . . . . 67
5.5.2.1. Request Definition . . . . . . . . . . . . . . . 66 5.5.2. AppAttach . . . . . . . . . . . . . . . . . . . . . 67
5.5.2.2. Response Definition . . . . . . . . . . . . . . . 67 5.5.2.1. Request Definition . . . . . . . . . . . . . . . 67
5.5.3. Ping . . . . . . . . . . . . . . . . . . . . . . . . 67 5.5.2.2. Response Definition . . . . . . . . . . . . . . . 68
5.5.3.1. Request Definition . . . . . . . . . . . . . . . 67 5.5.3. Ping . . . . . . . . . . . . . . . . . . . . . . . . 68
5.5.3.2. Response Definition . . . . . . . . . . . . . . . 67 5.5.3.1. Request Definition . . . . . . . . . . . . . . . 68
5.5.4. Config_Update . . . . . . . . . . . . . . . . . . . 68 5.5.3.2. Response Definition . . . . . . . . . . . . . . . 68
5.5.4.1. Request Definition . . . . . . . . . . . . . . . 68 5.5.4. Config_Update . . . . . . . . . . . . . . . . . . . 69
5.5.4.2. Response Definition . . . . . . . . . . . . . . . 69 5.5.4.1. Request Definition . . . . . . . . . . . . . . . 69
5.6. Overlay Link Layer . . . . . . . . . . . . . . . . . . . 70 5.5.4.2. Response Definition . . . . . . . . . . . . . . . 70
5.6.1. Future Overlay Link Protocols . . . . . . . . . . . 71 5.6. Overlay Link Layer . . . . . . . . . . . . . . . . . . . 71
5.6.1.1. HIP . . . . . . . . . . . . . . . . . . . . . . . 71 5.6.1. Future Overlay Link Protocols . . . . . . . . . . . 72
5.6.1.2. ICE-TCP . . . . . . . . . . . . . . . . . . . . . 71 5.6.1.1. HIP . . . . . . . . . . . . . . . . . . . . . . . 72
5.6.1.3. Message-oriented Transports . . . . . . . . . . . 71 5.6.1.2. ICE-TCP . . . . . . . . . . . . . . . . . . . . . 72
5.6.1.4. Tunneled Transports . . . . . . . . . . . . . . . 71 5.6.1.3. Message-oriented Transports . . . . . . . . . . . 72
5.6.2. Framing Header . . . . . . . . . . . . . . . . . . . 72 5.6.1.4. Tunneled Transports . . . . . . . . . . . . . . . 72
5.6.3. Simple Reliability . . . . . . . . . . . . . . . . . 73 5.6.2. Framing Header . . . . . . . . . . . . . . . . . . . 73
5.6.3.1. Retransmission and Flow Control . . . . . . . . . 74 5.6.3. Simple Reliability . . . . . . . . . . . . . . . . . 74
5.6.4. DTLS/UDP with SR . . . . . . . . . . . . . . . . . . 75 5.6.3.1. Retransmission and Flow Control . . . . . . . . . 75
5.6.5. TLS/TCP with FH, no ICE . . . . . . . . . . . . . . 75 5.6.4. DTLS/UDP with SR . . . . . . . . . . . . . . . . . . 76
5.6.6. DTLS/UDP with SR, no ICE . . . . . . . . . . . . . . 76 5.6.5. TLS/TCP with FH, no ICE . . . . . . . . . . . . . . 76
5.7. Fragmentation and Reassembly . . . . . . . . . . . . . . 76 5.6.6. DTLS/UDP with SR, no ICE . . . . . . . . . . . . . . 77
6. Data Storage Protocol . . . . . . . . . . . . . . . . . . . . 77 5.7. Fragmentation and Reassembly . . . . . . . . . . . . . . 77
6.1. Data Signature Computation . . . . . . . . . . . . . . . 78 6. Data Storage Protocol . . . . . . . . . . . . . . . . . . . . 78
6.2. Data Models . . . . . . . . . . . . . . . . . . . . . . 79 6.1. Data Signature Computation . . . . . . . . . . . . . . . 79
6.2.1. Single Value . . . . . . . . . . . . . . . . . . . . 80 6.2. Data Models . . . . . . . . . . . . . . . . . . . . . . 80
6.2.2. Array . . . . . . . . . . . . . . . . . . . . . . . 81 6.2.1. Single Value . . . . . . . . . . . . . . . . . . . . 81
6.2.3. Dictionary . . . . . . . . . . . . . . . . . . . . . 81 6.2.2. Array . . . . . . . . . . . . . . . . . . . . . . . 82
6.3. Access Control Policies . . . . . . . . . . . . . . . . 82 6.2.3. Dictionary . . . . . . . . . . . . . . . . . . . . . 82
6.3.1. USER-MATCH . . . . . . . . . . . . . . . . . . . . . 82 6.3. Access Control Policies . . . . . . . . . . . . . . . . 83
6.3.2. NODE-MATCH . . . . . . . . . . . . . . . . . . . . . 82 6.3.1. USER-MATCH . . . . . . . . . . . . . . . . . . . . . 83
6.3.3. USER-NODE-MATCH . . . . . . . . . . . . . . . . . . 82 6.3.2. NODE-MATCH . . . . . . . . . . . . . . . . . . . . . 83
6.3.4. NODE-MULTIPLE . . . . . . . . . . . . . . . . . . . 82 6.3.3. USER-NODE-MATCH . . . . . . . . . . . . . . . . . . 83
6.4. Data Storage Methods . . . . . . . . . . . . . . . . . . 83 6.3.4. NODE-MULTIPLE . . . . . . . . . . . . . . . . . . . 83
6.4.1. Store . . . . . . . . . . . . . . . . . . . . . . . 83 6.4. Data Storage Methods . . . . . . . . . . . . . . . . . . 84
6.4.1.1. Request Definition . . . . . . . . . . . . . . . 83 6.4.1. Store . . . . . . . . . . . . . . . . . . . . . . . 84
6.4.1.2. Response Definition . . . . . . . . . . . . . . . 87 6.4.1.1. Request Definition . . . . . . . . . . . . . . . 84
6.4.1.3. Removing Values . . . . . . . . . . . . . . . . . 88 6.4.1.2. Response Definition . . . . . . . . . . . . . . . 88
6.4.2. Fetch . . . . . . . . . . . . . . . . . . . . . . . 89 6.4.1.3. Removing Values . . . . . . . . . . . . . . . . . 89
6.4.2.1. Request Definition . . . . . . . . . . . . . . . 90 6.4.2. Fetch . . . . . . . . . . . . . . . . . . . . . . . 90
6.4.2.2. Response Definition . . . . . . . . . . . . . . . 92 6.4.2.1. Request Definition . . . . . . . . . . . . . . . 91
6.4.3. Stat . . . . . . . . . . . . . . . . . . . . . . . . 92 6.4.2.2. Response Definition . . . . . . . . . . . . . . . 93
6.4.3.1. Request Definition . . . . . . . . . . . . . . . 93 6.4.3. Stat . . . . . . . . . . . . . . . . . . . . . . . . 93
6.4.3.2. Response Definition . . . . . . . . . . . . . . . 93 6.4.3.1. Request Definition . . . . . . . . . . . . . . . 94
6.4.4. Find . . . . . . . . . . . . . . . . . . . . . . . . 95 6.4.3.2. Response Definition . . . . . . . . . . . . . . . 94
6.4.4.1. Request Definition . . . . . . . . . . . . . . . 95 6.4.4. Find . . . . . . . . . . . . . . . . . . . . . . . . 96
6.4.4.2. Response Definition . . . . . . . . . . . . . . . 95 6.4.4.1. Request Definition . . . . . . . . . . . . . . . 96
6.4.5. Defining New Kinds . . . . . . . . . . . . . . . . . 96 6.4.4.2. Response Definition . . . . . . . . . . . . . . . 96
7. Certificate Store Usage . . . . . . . . . . . . . . . . . . . 97 6.4.5. Defining New Kinds . . . . . . . . . . . . . . . . . 97
8. TURN Server Usage . . . . . . . . . . . . . . . . . . . . . . 98 7. Certificate Store Usage . . . . . . . . . . . . . . . . . . . 98
9. Chord Algorithm . . . . . . . . . . . . . . . . . . . . . . . 99 8. TURN Server Usage . . . . . . . . . . . . . . . . . . . . . . 99
9.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 100 9. Chord Algorithm . . . . . . . . . . . . . . . . . . . . . . . 100
9.2. Routing . . . . . . . . . . . . . . . . . . . . . . . . 101 9.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 101
9.3. Redundancy . . . . . . . . . . . . . . . . . . . . . . . 101 9.2. Routing . . . . . . . . . . . . . . . . . . . . . . . . 102
9.4. Joining . . . . . . . . . . . . . . . . . . . . . . . . 102 9.3. Redundancy . . . . . . . . . . . . . . . . . . . . . . . 102
9.5. Routing Attaches . . . . . . . . . . . . . . . . . . . . 102 9.4. Joining . . . . . . . . . . . . . . . . . . . . . . . . 103
9.6. Updates . . . . . . . . . . . . . . . . . . . . . . . . 103 9.5. Routing Attaches . . . . . . . . . . . . . . . . . . . . 103
9.6.1. Handling Neighbor Failures . . . . . . . . . . . . . 104 9.6. Updates . . . . . . . . . . . . . . . . . . . . . . . . 104
9.6.2. Handling Finger Table Entry Failure . . . . . . . . 105 9.6.1. Handling Neighbor Failures . . . . . . . . . . . . . 105
9.6.3. Receiving Updates . . . . . . . . . . . . . . . . . 105 9.6.2. Handling Finger Table Entry Failure . . . . . . . . 106
9.6.4. Stabilization . . . . . . . . . . . . . . . . . . . 106 9.6.3. Receiving Updates . . . . . . . . . . . . . . . . . 106
9.6.4.1. Updating neighbor table . . . . . . . . . . . . . 106 9.6.4. Stabilization . . . . . . . . . . . . . . . . . . . 107
9.6.4.2. Refreshing finger table . . . . . . . . . . . . . 106 9.6.4.1. Updating neighbor table . . . . . . . . . . . . . 107
9.6.4.3. Adjusting finger table size . . . . . . . . . . . 107 9.6.4.2. Refreshing finger table . . . . . . . . . . . . . 107
9.6.4.4. Detecting partitioning . . . . . . . . . . . . . 108 9.6.4.3. Adjusting finger table size . . . . . . . . . . . 108
9.7. Route Query . . . . . . . . . . . . . . . . . . . . . . 108 9.6.4.4. Detecting partitioning . . . . . . . . . . . . . 109
9.8. Leaving . . . . . . . . . . . . . . . . . . . . . . . . 109 9.7. Route Query . . . . . . . . . . . . . . . . . . . . . . 109
10. Enrollment and Bootstrap . . . . . . . . . . . . . . . . . . 110 9.8. Leaving . . . . . . . . . . . . . . . . . . . . . . . . 110
10.1. Overlay Configuration . . . . . . . . . . . . . . . . . 110
10.1.1. Relax NG Grammar . . . . . . . . . . . . . . . . . . 115 10. Enrollment and Bootstrap . . . . . . . . . . . . . . . . . . 111
10.2. Discovery Through Enrollment Server . . . . . . . . . . 117 10.1. Overlay Configuration . . . . . . . . . . . . . . . . . 111
10.3. Credentials . . . . . . . . . . . . . . . . . . . . . . 117 10.1.1. Relax NG Grammar . . . . . . . . . . . . . . . . . . 116
10.3.1. Self-Generated Credentials . . . . . . . . . . . . . 118 10.2. Discovery Through Enrollment Server . . . . . . . . . . 118
10.4. Searching for a Bootstrap Node . . . . . . . . . . . . . 119 10.3. Credentials . . . . . . . . . . . . . . . . . . . . . . 118
10.5. Contacting a Bootstrap Node . . . . . . . . . . . . . . 119 10.3.1. Self-Generated Credentials . . . . . . . . . . . . . 119
11. Message Flow Example . . . . . . . . . . . . . . . . . . . . 120 10.4. Searching for a Bootstrap Node . . . . . . . . . . . . . 120
12. Security Considerations . . . . . . . . . . . . . . . . . . . 125 10.5. Contacting a Bootstrap Node . . . . . . . . . . . . . . 120
12.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 125 11. Message Flow Example . . . . . . . . . . . . . . . . . . . . 121
12.2. Attacks on P2P Overlays . . . . . . . . . . . . . . . . 126 12. Security Considerations . . . . . . . . . . . . . . . . . . . 127
12.3. Certificate-based Security . . . . . . . . . . . . . . . 126 12.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 127
12.4. Shared-Secret Security . . . . . . . . . . . . . . . . . 127 12.2. Attacks on P2P Overlays . . . . . . . . . . . . . . . . 128
12.5. Storage Security . . . . . . . . . . . . . . . . . . . . 128 12.3. Certificate-based Security . . . . . . . . . . . . . . . 128
12.5.1. Authorization . . . . . . . . . . . . . . . . . . . 128 12.4. Shared-Secret Security . . . . . . . . . . . . . . . . . 129
12.5.2. Distributed Quota . . . . . . . . . . . . . . . . . 129 12.5. Storage Security . . . . . . . . . . . . . . . . . . . . 130
12.5.3. Correctness . . . . . . . . . . . . . . . . . . . . 129 12.5.1. Authorization . . . . . . . . . . . . . . . . . . . 130
12.5.4. Residual Attacks . . . . . . . . . . . . . . . . . . 129 12.5.2. Distributed Quota . . . . . . . . . . . . . . . . . 131
12.6. Routing Security . . . . . . . . . . . . . . . . . . . . 130 12.5.3. Correctness . . . . . . . . . . . . . . . . . . . . 131
12.6.1. Background . . . . . . . . . . . . . . . . . . . . . 130 12.5.4. Residual Attacks . . . . . . . . . . . . . . . . . . 131
12.6.2. Admissions Control . . . . . . . . . . . . . . . . . 131 12.6. Routing Security . . . . . . . . . . . . . . . . . . . . 132
12.6.3. Peer Identification and Authentication . . . . . . . 131 12.6.1. Background . . . . . . . . . . . . . . . . . . . . . 132
12.6.4. Protecting the Signaling . . . . . . . . . . . . . . 132 12.6.2. Admissions Control . . . . . . . . . . . . . . . . . 133
12.6.5. Residual Attacks . . . . . . . . . . . . . . . . . . 132 12.6.3. Peer Identification and Authentication . . . . . . . 133
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 133 12.6.4. Protecting the Signaling . . . . . . . . . . . . . . 134
13.1. Port Registrations . . . . . . . . . . . . . . . . . . . 133 12.6.5. Residual Attacks . . . . . . . . . . . . . . . . . . 134
13.2. Overlay Algorithm Types . . . . . . . . . . . . . . . . 133 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 135
13.3. Access Control Policies . . . . . . . . . . . . . . . . 133 13.1. Port Registrations . . . . . . . . . . . . . . . . . . . 135
13.4. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . 134 13.2. Overlay Algorithm Types . . . . . . . . . . . . . . . . 135
13.5. Data Model . . . . . . . . . . . . . . . . . . . . . . . 134 13.3. Access Control Policies . . . . . . . . . . . . . . . . 135
13.6. Message Codes . . . . . . . . . . . . . . . . . . . . . 135 13.4. Application-ID . . . . . . . . . . . . . . . . . . . . . 136
13.7. Error Codes . . . . . . . . . . . . . . . . . . . . . . 136 13.5. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . 136
13.8. Overlay Link Types . . . . . . . . . . . . . . . . . . . 136 13.6. Data Model . . . . . . . . . . . . . . . . . . . . . . . 137
13.9. Forwarding Options . . . . . . . . . . . . . . . . . . . 136 13.7. Message Codes . . . . . . . . . . . . . . . . . . . . . 137
13.10. Probe Information Types . . . . . . . . . . . . . . . . 137 13.8. Error Codes . . . . . . . . . . . . . . . . . . . . . . 138
13.11. Message Extensions . . . . . . . . . . . . . . . . . . . 137 13.9. Overlay Link Types . . . . . . . . . . . . . . . . . . . 139
13.12. reload URI Scheme . . . . . . . . . . . . . . . . . . . 137 13.10. Forwarding Options . . . . . . . . . . . . . . . . . . . 139
13.12.1. URI Registration . . . . . . . . . . . . . . . . . . 138 13.11. Probe Information Types . . . . . . . . . . . . . . . . 140
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 139 13.12. Message Extensions . . . . . . . . . . . . . . . . . . . 140
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 139 13.13. reload URI Scheme . . . . . . . . . . . . . . . . . . . 140
15.1. Normative References . . . . . . . . . . . . . . . . . . 139 13.13.1. URI Registration . . . . . . . . . . . . . . . . . . 141
15.2. Informative References . . . . . . . . . . . . . . . . . 140 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 141
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 144 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 142
A.1. Changes since draft-ietf-p2psip-reload-04 . . . . . . . 144 15.1. Normative References . . . . . . . . . . . . . . . . . . 142
A.2. Changes since draft-ietf-p2psip-reload-01 . . . . . . . 144 15.2. Informative References . . . . . . . . . . . . . . . . . 143
A.3. Changes since draft-ietf-p2psip-reload-00 . . . . . . . 144 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 146
A.4. Changes since draft-ietf-p2psip-base-00 . . . . . . . . 144 A.1. Changes since draft-ietf-p2psip-reload-04 . . . . . . . 146
A.5. Changes since draft-ietf-p2psip-base-01 . . . . . . . . 144 A.2. Changes since draft-ietf-p2psip-reload-01 . . . . . . . 146
A.6. Changes since draft-ietf-p2psip-base-01a . . . . . . . . 145 A.3. Changes since draft-ietf-p2psip-reload-00 . . . . . . . 147
A.7. Changes since draft-ietf-p2psip-base-02 . . . . . . . . 145 A.4. Changes since draft-ietf-p2psip-base-00 . . . . . . . . 147
Appendix B. Routing Alternatives . . . . . . . . . . . . . . . . 145 A.5. Changes since draft-ietf-p2psip-base-01 . . . . . . . . 147
B.1. Iterative vs Recursive . . . . . . . . . . . . . . . . . 145 A.6. Changes since draft-ietf-p2psip-base-01a . . . . . . . . 147
B.2. Symmetric vs Forward response . . . . . . . . . . . . . 146 A.7. Changes since draft-ietf-p2psip-base-02 . . . . . . . . 148
B.3. Direct Response . . . . . . . . . . . . . . . . . . . . 146 Appendix B. Routing Alternatives . . . . . . . . . . . . . . . . 148
B.4. Relay Peers . . . . . . . . . . . . . . . . . . . . . . 147 B.1. Iterative vs Recursive . . . . . . . . . . . . . . . . . 148
B.5. Symmetric Route Stability . . . . . . . . . . . . . . . 148 B.2. Symmetric vs Forward response . . . . . . . . . . . . . 148
Appendix C. Why Clients? . . . . . . . . . . . . . . . . . . . . 148 B.3. Direct Response . . . . . . . . . . . . . . . . . . . . 149
C.1. Why Not Only Peers? . . . . . . . . . . . . . . . . . . 149 B.4. Relay Peers . . . . . . . . . . . . . . . . . . . . . . 150
C.2. Clients as Application-Level Agents . . . . . . . . . . 149 B.5. Symmetric Route Stability . . . . . . . . . . . . . . . 151
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 149 Appendix C. Why Clients? . . . . . . . . . . . . . . . . . . . . 151
C.1. Why Not Only Peers? . . . . . . . . . . . . . . . . . . 151
C.2. Clients as Application-Level Agents . . . . . . . . . . 152
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 152
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 14, line 12 skipping to change at page 14, line 12
single application may require multiple usages; for example a SIP single application may require multiple usages; for example a SIP
application may also require a voicemail usage. A usage may define application may also require a voicemail usage. A usage may define
multiple kinds of data that are stored in the overlay and may also multiple kinds of data that are stored in the overlay and may also
rely on kinds originally defined by other usages. 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 draft. 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, including retransmissions. Each
peer is identified by its location in the overlay as determined by peer is identified by its location in the overlay as determined by
its Node-ID. A component that is a client of the Message Transport its Node-ID. A component that is a client of the Message Transport
can perform two basic functions: can perform two basic functions:
skipping to change at page 16, line 18 skipping to change at page 16, line 18
topology plugin to control the overlay and resource operations and topology plugin to control the overlay and resource operations and
messages. Since each overlay algorithm is defined and functions messages. Since each overlay algorithm is defined and functions
differently, we generically refer to the table of other peers that differently, we generically refer to the table of other peers that
the overlay algorithm maintains and uses to route requests the overlay algorithm maintains and uses to route requests
(neighbors) as a Routing Table. The Topology Plugin actually owns (neighbors) as a Routing Table. The Topology Plugin actually owns
the Routing Table, and forwarding decisions are made by querying the the Routing Table, and forwarding decisions are made by querying the
Topology Plugin for the next hop for a particular Node-ID or Topology Plugin for the next hop for a particular Node-ID or
Resource-ID. If this node is the destination of the message, the Resource-ID. If this node is the destination of the message, the
message is delivered to the Message Transport. message is delivered to the Message Transport.
This layer may also utilize a framing header to encapsulate messages
as they are forwarding along each hop. Such a header may be used to
aid reliability, congestion control, flow control, etc. Any such
header has meaning only in the context of that individual link.
The Forwarding and Link Management Layer sits on top of the Overlay The Forwarding and Link Management Layer sits on top of the Overlay
Link Layer protocols that carry the actual traffic. This Link Layer protocols that carry the actual traffic. This
specification defines how to use DTLS and TLS protocols to carry specification defines how to use DTLS and TLS protocols to carry
RELOAD messages. RELOAD messages.
1.3. Security 1.3. Security
RELOAD's security model is based on each node having one or more RELOAD's security model is based on each node having one or more
public key certificates. In general, these certificates will be public key certificates. In general, these certificates will be
assigned by a central server which also assigns Node-IDs, although assigned by a central server which also assigns Node-IDs, although
skipping to change at page 22, line 18 skipping to change at page 22, line 27
3.2.1. Client Routing 3.2.1. Client Routing
There are two routing options by which a client may be located in an There are two routing options by which a client may be located in an
overlay. overlay.
o Establish a connection to the peer responsible for the client's o Establish a connection to the peer responsible for the client's
Node-ID in the overlay. Then requests may be sent from/to the Node-ID in the overlay. Then requests may be sent from/to the
client using its Node-ID in the same manner as if it were a peer, client using its Node-ID in the same manner as if it were a peer,
because the responsible peer in the overlay will handle the final because the responsible peer in the overlay will handle the final
step of routing to the client. This will not work in overlays step of routing to the client. This may require a TURN relay in
where NATs or firewalls prevent clients from forming connections cases where NATs or firewalls prevent a client from forming a
with other peers. Note that clients that choose this option MUST direct connections with its responsible peer. Note that clients
process Update messages from the peer. Those updates can indicate that choose this option MUST process Update messages from the
that the peer no longer owns the Client's Node-ID. The client peer. Those updates can indicate that the peer no longer owns the
then forms a connection to the appropriate peer. Failure to do so Client's Node-ID. The client then forms a connection to the
will result in the client no longer receiving messages. appropriate peer. Failure to do so will result in the client no
longer receiving messages.
o Establish a connection with an arbitrary peer in the overlay o Establish a connection with an arbitrary peer in the overlay
(perhaps based on network proximity or an inability to establish a (perhaps based on network proximity or an inability to establish a
direct connection with the responsible peer). In this case, the direct connection with the responsible peer). In this case, the
client will rely on RELOAD's Destination List feature to ensure client will rely on RELOAD's Destination List feature to ensure
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. The Destination List required to reach it using only its Node-ID. The Destination List required to reach it
must be learnable via other mechanisms, such as being stored in must be learnable via other mechanisms, such as being stored in
the overlay by a usage, if the client is to receive incoming the overlay by a usage, if the client is to receive incoming
skipping to change at page 26, line 26 skipping to change at page 26, line 30
fully connected links. However, a peer should try to maintain the fully connected links. However, a peer should try to maintain the
specified link set and if it detects that it has fewer direct specified link set and if it detects that it has fewer direct
connections, should form more as required. This also implies that connections, should form more as required. This also implies that
peers need to periodically verify that the connected peers are still peers need to periodically verify that the connected peers are still
alive and if not try to reform the connection or form an alternate alive and if not try to reform the connection or form an alternate
one. one.
3.5. Overlay Algorithm Support 3.5. Overlay Algorithm Support
The Topology Plugin allows RELOAD to support a variety of overlay The Topology Plugin allows RELOAD to support a variety of overlay
algorithms. This draft defines a DHT based on Chord [Chord], which algorithms. This specification defines a DHT based on Chord [Chord],
is mandatory to implement, but the base RELOAD protocol is designed which is mandatory to implement, but the base RELOAD protocol is
to support a variety of overlay algorithms. designed to support a variety of overlay algorithms.
3.5.1. Support for Pluggable Overlay Algorithms 3.5.1. Support for Pluggable Overlay Algorithms
RELOAD defines three methods for overlay maintenance: Join, Update, RELOAD defines three methods for overlay maintenance: Join, Update,
and Leave. However, the contents of those messages, when they are and Leave. However, the contents of those messages, when they are
sent, and their precise semantics are specified by the actual overlay sent, and their precise semantics are specified by the actual overlay
algorithm; RELOAD merely provides a framework of commonly-needed algorithm; RELOAD merely provides a framework of commonly-needed
methods that provides uniformity of notation (and ease of debugging) methods that provides uniformity of notation (and ease of debugging)
for a variety of overlay algorithms. for a variety of overlay algorithms.
skipping to change at page 32, line 9 skipping to change at page 32, line 18
resources. resources.
A variety of schemes are used in P2P overlays to achieve some of A variety of schemes are used in P2P overlays to achieve some of
these goals. Common techniques include replicating on neighbors of these goals. Common techniques include replicating on neighbors of
the responsible peer, randomly locating replicas around the overlay, the responsible peer, randomly locating replicas around the overlay,
or replicating along the path to the responsible peer. or replicating along the path to the responsible peer.
The core RELOAD specification does not specify a particular The core RELOAD specification does not specify a particular
replication strategy. Instead, the first level of replication replication strategy. Instead, the first level of replication
strategies are determined by the overlay algorithm, which can base strategies are determined by the overlay algorithm, which can base
the replication strategy on the its particular topology. For the replication strategy on its particular topology. For example,
example, Chord places replicas on successor peers, which will take Chord places replicas on successor peers, which will take over
over responsibility should the responsible peer fail [Chord]. responsibility should the responsible peer fail [Chord].
If additional replication is needed, for example if data persistence If additional replication is needed, for example if data persistence
is particularly important for a particular usage, then that usage may is particularly important for a particular usage, then that usage may
specify additional replication, such as implementing random specify additional replication, such as implementing random
replications by inserting a different well known constant into the replications by inserting a different well known constant into the
Resource Name used to store each replicated copy of the resource. Resource Name used to store each replicated copy of the resource.
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.
skipping to change at page 33, line 47 skipping to change at page 34, line 5
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
node is responsible, there are several sub-cases. node is responsible, there are several sub-cases.
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 passes it up to the upper layers.
o If the entry is a Node-ID which belongs to this node, then the o If the entry is a Node-ID which equals this node's Node-ID, then
message is destined for this node. If this is the only entry on the message is destined for this node. If this is the only entry
the destination list, the message is destined for this node and is on the destination list, the message is destined for this node and
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 first. list first.
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 that case, it MUST forward the message to
the destination node as described in the next section. 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 two cases applies, then the peer MUST forward If neither of the other three cases applies, then the peer MUST
the message towards the first entry on the destination list. This forward the message towards the first entry on the destination list.
means that it MUST select one of the peers to which it is connected This means that it MUST select one of the peers to which it is
and which is likely to be responsible for the first entry on the connected and which is likely to be responsible for the first entry
destination list. If the first entry on the destination list is in on the destination list. If the first entry on the destination list
the peer's connection table, then it SHOULD forward the message to is in the peer's connection table, then it SHOULD forward the message
that peer directly. Otherwise, the peer consults the routing table to that peer directly. Otherwise, the peer consults the routing
to forward the message. table to forward the message.
Any intermediate peer which forwards a RELOAD message MUST arrange Any intermediate peer which forwards a RELOAD message MUST arrange
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 may be arranged 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.
skipping to change at page 37, line 4 skipping to change at page 37, line 14
5.3. Message Structure 5.3. Message Structure
RELOAD is a message-oriented request/response protocol. The messages RELOAD is a message-oriented request/response protocol. The messages
are encoded using binary fields. All integers are represented in are encoded using binary fields. All integers are represented in
network byte order. The general philosophy behind the design was to network byte order. The general philosophy behind the design was to
use Type, Length, Value fields to allow for extensibility. However, use Type, Length, Value fields to allow for extensibility. However,
for the parts of a structure that were required in all messages, we for the parts of a structure that were required in all messages, we
just define these in a fixed position, as adding a type and length just define these in a fixed position, as adding a type and length
for them is unnecessary and would simply increase bandwidth and for them is unnecessary and would simply increase bandwidth and
introduce new potential for interoperability issues. introduces new potential for interoperability issues.
Each message has three parts, concatenated as shown below: Each message has three parts, concatenated as shown below:
+-------------------------+ +-------------------------+
| Forwarding Header | | Forwarding Header |
+-------------------------+ +-------------------------+
| Message Contents | | Message Contents |
+-------------------------+ +-------------------------+
| Security Block | | Security Block |
+-------------------------+ +-------------------------+
skipping to change at page 37, line 48 skipping to change at page 38, line 12
syntax based on the presentation language used to define TLS. syntax based on the presentation language used to define TLS.
Advantages of this style include: Advantages of this style include:
o It is easy to write and familiar enough looking that most readers o It is easy to write and familiar enough looking that most readers
can grasp it quickly. can grasp it quickly.
o The ability to define nested structures allows a separation o The ability to define nested structures allows a separation
between high-level and low-level message structures. between high-level and low-level message structures.
o It has a straightforward wire encoding that allows quick o It has a straightforward wire encoding that allows quick
implementation, but the structures can be comprehended without implementation, but the structures can be comprehended without
knowing the encoding. knowing the encoding.
o The ability to mechanically (compile) encoders and decoders. o The ability to mechanically compile encoders and decoders.
Several idiosyncrasies of this language are worth noting. Several idiosyncrasies of this language are worth noting.
o All lengths are denoted in bytes, not objects. o All lengths are denoted in bytes, not objects.
o Variable length values are denoted like arrays with angle o Variable length values are denoted like arrays with angle
brackets. brackets.
o "select" is used to indicate variant structures. o "select" is used to indicate variant structures.
For instance, "uint16 array<0..2^8-2>;" represents up to 254 bytes For instance, "uint16 array<0..2^8-2>;" represents up to 254 bytes
but only up to 127 values of two bytes (16 bits) each. but only up to 127 values of two bytes (16 bits) each.
skipping to change at page 38, line 47 skipping to change at page 39, line 13
should be relatively obvious. should be relatively obvious.
A ResourceId, shown below, represents a single Resource-ID. A ResourceId, shown below, represents a single Resource-ID.
typedef opaque ResourceId<0..2^8-1>; typedef opaque ResourceId<0..2^8-1>;
Like a NodeId, a ResourceId is an opaque string of bytes, but unlike Like a NodeId, a ResourceId is an opaque string of bytes, but unlike
NodeIds, ResourceIds are variable length, up to 255 bytes (2048 bits) NodeIds, ResourceIds are variable length, up to 255 bytes (2048 bits)
in length. On the wire, each ResourceId is preceded by a single in length. On the wire, each ResourceId is preceded by a single
length byte (allowing lengths up to 255). Thus, the 3-byte value length byte (allowing lengths up to 255). Thus, the 3-byte value
"Foo" would be encoded as: 03 46 4f 4f. "FOO" would be encoded as: 03 46 4f 4f.
A more complicated example is IpAddressPort, which represents a A more complicated example is IpAddressPort, which represents a
network address and can be used to carry either an IPv6 or IPv4 network address and can be used to carry either an IPv6 or IPv4
address: address:
enum {reserved_addr(0), ipv4_address (1), ipv6_address (2), enum {reserved_addr(0), ipv4_address (1), ipv6_address (2),
(255)} AddressType; (255)} AddressType;
struct { struct {
uint32 addr; uint32 addr;
skipping to change at page 45, line 20 skipping to change at page 45, line 27
Regardless of how the 16 bit integer field or opaque DestinationType Regardless of how the 16 bit integer field or opaque DestinationType
is used, the encoding MUST include a generation counter designed to is used, the encoding MUST include a generation counter designed to
prevent misrouting of responses due to the connection table entry prevent misrouting of responses due to the connection table entry
having changed since the request message was originally forwarded. having changed since the request message was originally forwarded.
5.3.2.3. Forwarding Options 5.3.2.3. Forwarding Options
The Forwarding header can be extended with forwarding header options, The Forwarding header can be extended with forwarding header options,
which are a series of ForwardingOptions structures: which are a series of ForwardingOptions structures:
enum { (255) } ForwardingOptionsType; enum { directResponseForwarding(1), (255) } ForwardingOptionsType;
struct { struct {
ForwardingOptionsType type; ForwardingOptionsType type;
uint8 flags; uint8 flags;
uint16 length; uint16 length;
select (type) { select (type) {
/* Option values go here */ case directResponseForwarding:
} option; DirectResponseForwardingOption directResponseForwardingOption;
} ForwardingOption;
/* This type may be extended */
} option;
} ForwardingOption;
Each ForwardingOption consists of the following values: Each ForwardingOption consists of the following values:
type type
The type of the option. This structure allows for unknown options The type of the option. This structure allows for unknown options
types. types.
length length
The length of the rest of the structure. The length of the rest of the structure.
skipping to change at page 46, line 12 skipping to change at page 46, line 26
response to the message but does not understand the forwarding response to the message but does not understand the forwarding
option MUST reject the request with an option MUST reject the request with an
Error_Unsupported_Forwarding_Option error response. If the Error_Unsupported_Forwarding_Option error response. If the
RESPONSE_COPY flag is set, any node generating a response MUST RESPONSE_COPY flag is set, any node generating a response MUST
copy the option from the request to the response and clear the copy the option from the request to the response and clear the
RESPONSE_COPY, FORWARD_CRITICAL and DESTINATION_CRITICAL flags. RESPONSE_COPY, FORWARD_CRITICAL and DESTINATION_CRITICAL flags.
option option
The option value. The option value.
5.3.2.4. Direct Return Response Forwarding Options
NOTE: This section does not have working group consensus but to help
facilitate discussion of the topic, the authors have included it in
the text. This section will be adjusted or removed in the next
version to represent working group consensus.
This section defines an OPTIONAL forwarding option that allows the
originator of a request to signal that the node responsindg to the
request should try to route the response directly to the node that
made the request instead of having the responses traverse the
overlay. :
struct {
AttachReqAns connection_information;
NodeID requesting_node;
} DirectResponseForwardingOption;
Each ForwardingOption consists of the following values:
connection_information
All of the information needed to initiate a new connection to the
requesting node.
requesting_node
The NodeID of the node that originated the request. This is used
to match the TLS certificate.
This option can only be used if the
DirecteRetrurnResonsoseRoutingAllowed flag in the configuration for
the overlay is set to true. The RESPONSE_COPY flag SHOULD be set to
false while the FORWARD_CRITICAL and DESTINATION_CRITICAL SHOULD be
set to true. When a node that supports this forwarding options
receives a request with it, it acts as if it had send an Attache
request to the the requesting_node and it had received the
connection_information in the answer. This cases it to form a new
connection directly to that node. Once that is complete the response
to this request is sent over that connection. If a connection
already exists directly to that node, it is used instead of a a new
connection being formed. The connection MAY be closed at any point
but is typically kept open until TODO (need WG input). [ TODO - add
appropriate text to configuration file ]
5.3.3. Message Contents Format 5.3.3. Message Contents Format
The second major part of a RELOAD message is the contents part, which The second major part of a RELOAD message is the contents part, which
is defined by MessageContents: is defined by MessageContents:
enum { (2^16-1) } MessageExtensionType; enum { (2^16-1) } MessageExtensionType;
struct { struct {
MessageExtensionType type; MessageExtensionType type;
Boolean critical; Boolean critical;
skipping to change at page 47, line 14 skipping to change at page 48, line 28
message_body message_body
The message body itself, represented as a variable-length string The message body itself, represented as a variable-length string
of bytes. The bytes themselves are dependent on the code value. of bytes. The bytes themselves are dependent on the code value.
See the sections describing the various RELOAD methods (Join, See the sections describing the various RELOAD methods (Join,
Update, Attach, Store, Fetch, etc.) for the definitions of the Update, Attach, Store, Fetch, etc.) for the definitions of the
payload contents. payload contents.
extensions extensions
Extensions to the message. Currently no extensions are defined, Extensions to the message. Currently no extensions are defined,
but new extensions can be defined by the process described in but new extensions can be defined by the process described in
Section 13.11. Section 13.12.
All extensions have the following form: All extensions have the following form:
type type
The extension type. The extension type.
critical critical
Whether this extension must be understood in order to process the Whether this extension must be understood in order to process the
message. If critical = True and the recipient does not understand message. If critical = True and the recipient does not understand
the message, it MUST generate an Error_Unknown_Extension error. the message, it MUST generate an Error_Unknown_Extension error.
skipping to change at page 48, line 16 skipping to change at page 49, line 29
error_code error_code
A numeric error code indicating the error that occurred. A numeric error code indicating the error that occurred.
error_info error_info
An optional arbitrary byte string. Unless otherwise specified, An optional arbitrary byte string. Unless otherwise specified,
this will be a UTF-8 text string providing further information this will be a UTF-8 text string providing further information
about what went wrong. about what went wrong.
The following error code values are defined. The numeric values for The following error code values are defined. The numeric values for
these are defined in Section 13.7. these are defined in Section 13.8.
Error_Forbidden: The requesting node does not have permission to Error_Forbidden: The requesting node does not have permission to
make this request. make this request.
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.
skipping to change at page 59, line 7 skipping to change at page 60, line 12
to act as a peer. Thus, clients (unlike peers) can simply Attach to act as a peer. Thus, clients (unlike peers) can simply Attach
without sending Join or Update. without sending Join or Update.
5.5.1.1. Request Definition 5.5.1.1. Request Definition
An Attach request message contains the requesting node ICE connection An Attach request message contains the requesting node ICE connection
parameters formatted into a binary structure. parameters formatted into a binary structure.
enum { reserved(0), DTLS-UDP-SR(1), <!--TLS/TCP with FH(2),--> enum { reserved(0), DTLS-UDP-SR(1), <!--TLS/TCP with FH(2),-->
DLTS-UDP-SR-NO-ICE(3), TLS-TCP-FH-NO-ICE(4), DLTS-UDP-SR-NO-ICE(3), TLS-TCP-FH-NO-ICE(4),
(255) } Overlay Link; (255) } OverlayLink;
enum { reserved(0), host(1), srflx(2), prflx(3), relay(4), enum { reserved(0), host(1), srflx(2), prflx(3), relay(4),
(255) } CandType; (255) } CandType;
struct { struct {
opaque name<2^16-1>; opaque name<2^16-1>;
opaque value<2^16-1>; opaque value<2^16-1>;
} IceExtension; } IceExtension;
struct { struct {
IpAddressPort addr_port; IpAddressPort addr_port;
Overlay Link overlay_link; OverlayLink overlay_link;
opaque foundation<0..255>; opaque foundation<0..255>;
uint32 priority; uint32 priority;
CandType type; CandType type;
select (type){ select (type){
case host: case host:
; /* Nothing */ ; /* Nothing */
case srflx: case srflx:
case prflx: case prflx:
case relay: case relay:
IpAddressPort rel_addr_port; IpAddressPort rel_addr_port;
skipping to change at page 60, line 24 skipping to change at page 61, line 30
Each ICE candidate is represented as an IceCandidate structure, which Each ICE candidate is represented as an IceCandidate structure, which
is a direct translation of the information from the ICE string is a direct translation of the information from the ICE string
structures, with the exception of the component ID. Since there is structures, with the exception of the component ID. Since there is
only one component, it is always 1, and thus left out of the PDU. only one component, it is always 1, and thus left out of the PDU.
The remaining values are specified as follows: The remaining values are specified as follows:
addr_port addr_port
corresponds to the connection-address and port productions. corresponds to the connection-address and port productions.
overlay_link overlay_link
corresponds to the Overlay Link production, Overlay Link protocols corresponds to the OverlayLink production, Overlay Link protocols
used with No ICE MUST specify "no ICE" in their description. used with No ICE MUST specify "no ICE" in their description.
Future overlay link values can be added be defining new Overlay Future overlay link values can be added be defining new
Link values in the IANA registry in Section 13.8. Future OverlayLink values in the IANA registry in Section 13.9. Future
extensions to the encapsulation or framing that provide for extensions to the encapsulation or framing that provide for
backward compatibility with that specified by a previously defined backward compatibility with that specified by a previously defined
Overlay Link values MUST use that previous value. Overlay Link OverlayLink values MUST use that previous value. OverlayLink
protocols are defined in Section 5.6 protocols are defined in Section 5.6
A single AttachReqAns MUST NOT include both candidates whose A single AttachReqAns MUST NOT include both candidates whose
Overlay Link protocols use ICE (the default) and candidates that OverlayLink protocols use ICE (the default) and candidates that
specify "no ICE". specify "no ICE".
foundation foundation
corresponds to the foundation production. corresponds to the foundation production.
priority priority
corresponds to the priority production. corresponds to the priority production.
type type
corresponds to the cand-type production. corresponds to the cand-type production.
skipping to change at page 65, line 26 skipping to change at page 66, line 26
certificate exchanged during the (D)TLS handshake must match the node certificate exchanged during the (D)TLS handshake must match the node
that sent the AttachReqAns and if it does not, the connection MUST be that sent the AttachReqAns and if it does not, the connection MUST be
closed. closed.
5.5.1.11.1. Implementation Notes for No-ICE 5.5.1.11.1. Implementation Notes for No-ICE
This is a non-normative section to help implementors. This is a non-normative section to help implementors.
At times ICE can seem a bit daunting to get one's head around. For a At times ICE can seem a bit daunting to get one's head around. For a
simple IPv4 only peer, a simple implementation of No-ICE could be simple IPv4 only peer, a simple implementation of No-ICE could be
done be doing the following: done by doing the following:
o When sending an AttachReqAns, form one candidate with a priority o When sending an AttachReqAns, form one candidate with a priority
value of (2^24)*(126)+(2^8)*(65535)+(2^0)*(256-1) that specifies value of (2^24)*(126)+(2^8)*(65535)+(2^0)*(256-1) that specifies
the UDP port being listened to and another one with the TCP port. the UDP port being listened to and another one with the TCP port.
o Check the certificate received in the TLS handshake has the same o Check the certificate received in the TLS handshake has the same
Node-ID as the node that has sent the AttachReqAns. If multiple Node-ID as the node that has sent the AttachReqAns. If multiple
connections succeed, close all but the one with highest priority. connections succeed, close all but the one with highest priority.
o Do normal TLS and DTLS with no need for any special framing or o Do normal TLS and DTLS with no need for any special framing or
STUN processing. STUN processing.
5.5.1.12. Subsequent Offers and Answers 5.5.1.12. Subsequent Offers and Answers
skipping to change at page 67, line 6 skipping to change at page 68, line 6
The values contained in AppAttachReqAns are: The values contained in AppAttachReqAns are:
ufrag ufrag
The username fragment (from ICE) The username fragment (from ICE)
password password
The ICE password. The ICE password.
application application
A 16-bit port number. This port number represents the IANA A 16-bit application-id as defined in the Section 13.4. This
registered port of the protocol that is going to be sent on this number represents the IANA registered applications that is going
connection. For SIP, this is 5060 or 5061. By using the IANA to be sent data on this connection. For SIP, this is 5060 or
registered port, we avoid the need for an additional registry and 5061.
allow RELOAD to be used to set up connections for any existing or
future application protocols.
role role
An active/passive/actpass attribute from RFC 4145 [RFC4145]. An active/passive/actpass attribute from RFC 4145 [RFC4145].
candidates candidates
One or more ICE candidate values One or more ICE candidate values
5.5.2.2. Response Definition 5.5.2.2. Response Definition
If a peer receives an AppAttach request, it SHOULD process the If a peer receives an AppAttach request, it SHOULD process the
skipping to change at page 73, line 38 skipping to change at page 74, line 38
previously received packet number M. For each of the previous 32 previously received packet number M. For each of the previous 32
packets, if the sequence number M is less than N but greater than packets, if the sequence number M is less than N but greater than
N-32, the N-M bit of the received bitmask is set to one; otherwise N-32, the N-M bit of the received bitmask is set to one; otherwise
it is zero. Note that a bit being set to one indicates positively it is zero. Note that a bit being set to one indicates positively
that a particular packet was received, but a bit being set to zero that a particular packet was received, but a bit being set to zero
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 very high degree of The received field bits in the ACK provide a very high degree of
redundancy so that the sender to 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.
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
skipping to change at page 78, line 18 skipping to change at page 79, line 18
storage_time storage_time
The time when the data was stored in absolute time, represented in The time when the data was stored in absolute time, represented in
milliseconds since the Unix epoch of midnight Jan 1, 1970. Any milliseconds since the Unix epoch of midnight Jan 1, 1970. Any
attempt to store a data value with a storage time before that of a attempt to store a data value with a storage time before that of a
value already stored at this location MUST generate a value already stored at this location MUST generate a
Error_Data_Too_Old error. This prevents rollback attacks. Note Error_Data_Too_Old error. This prevents rollback attacks. Note
that this does not require synchronized clocks: the receiving that this does not require synchronized clocks: the receiving
peer uses the storage time in the previous store, not its own peer uses the storage time in the previous store, not its own
clock. clock.
A node that is attempting to store new data in response to a user
request (rather than as an overlay maintenance operation such as
occurs during unpartitioning) is rejected with an
Error_Data_Too_Old error, the node MAY elect to perform its store
using a storage_time that increments the value used with the
previous store. This situation may occur when the clocks of nodes
storing to this location are not properly synchronized.
lifetime lifetime
The validity period for the data, in seconds, starting from the The validity period for the data, in seconds, starting from the
time of store. time of store.
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.
skipping to change at page 96, line 15 skipping to change at page 97, line 15
struct { struct {
KindId kind; KindId kind;
ResourceId closest; ResourceId closest;
} FindKindData; } FindKindData;
struct { struct {
FindKindData results<0..2^16-1>; FindKindData results<0..2^16-1>;
} FindAns; } FindAns;
If the processing peer is not responsible for the specified If the processing peer is not responsible for the specified
Resource-ID, it SHOULD return a 404 error. Resource-ID, it SHOULD return a 404 RELOAD error code.
For each Kind-ID in the request the response MUST contain a For each Kind-ID in the request the response MUST contain a
FindKindData indicating the closest Resource-ID for that Kind-ID, FindKindData indicating the closest Resource-ID for that Kind-ID,
unless the kind is not allowed to be used with Find in which case a unless the kind is not allowed to be used with Find in which case a
FindKindData for that Kind-ID MUST NOT be included in the response. FindKindData for that Kind-ID MUST NOT be included in the response.
If a Kind-ID is not known, then the corresponding Resource-ID MUST be If a Kind-ID is not known, then the corresponding Resource-ID MUST be
0. Note that different Kind-IDs may have different closest Resource- 0. Note that different Kind-IDs may have different closest Resource-
IDs. IDs.
The response is simply a series of FindKindData elements, one per The response is simply a series of FindKindData elements, one per
skipping to change at page 106, line 8 skipping to change at page 107, line 8
In the first case, no change is needed. In the first case, no change is needed.
In the second case, N MUST attempt to Attach to the new peers and if In the second case, N MUST attempt to Attach to the new peers and if
it is successful it MUST adjust its neighbor set accordingly. Note it is successful it MUST adjust its neighbor set accordingly. Note
that it can maintain the now inferior peers as neighbors, but it MUST that it can maintain the now inferior peers as neighbors, but it MUST
remember the closer ones. remember the closer ones.
After any Pings and Attaches are done, if the neighbor table changes After any Pings and Attaches are done, if the neighbor table changes
and the peer is using reactive recovery, the peer sends an Update and the peer is using reactive recovery, the peer sends an Update
request to each member of its Connection Table. These Update request to each member of its Connection Table. These Update
requests are what ends up filling in the predecessor/successor tables requests are what end up filling in the predecessor/successor tables
of peers that this peer is a neighbor to. A peer MUST NOT enter of peers that this peer is a neighbor to. A peer MUST NOT enter
itself in its successor or predecessor table and instead should leave itself in its successor or predecessor table and instead should leave
the entries empty. the entries empty.
If peer N is responsible for a Resource-ID R, and N discovers that If peer N is responsible for a Resource-ID R, and N discovers that
the replica set for R (the next two nodes in its successor set) has the replica set for R (the next two nodes in its successor set) has
changed, it MUST send a Store for any data associated with R to any changed, it MUST send a Store for any data associated with R to any
new node in the replica set. It SHOULD NOT delete data from peers new node in the replica set. It SHOULD NOT delete data from peers
which have left the replica set. which have left the replica set.
skipping to change at page 109, line 14 skipping to change at page 110, line 14
next_peer next_peer
The peer to which the responding peer would route the message in The peer to which the responding peer would route the message in
order to deliver it to the destination listed in the request. order to deliver it to the destination listed in the request.
If the requester has set the send_update flag, the responder SHOULD If the requester has set the send_update flag, the responder SHOULD
initiate an Update immediately after sending the RouteQueryAns. initiate an Update immediately after sending the RouteQueryAns.
9.8. Leaving 9.8. Leaving
To support extentions, such as [I-D.maenpaa-p2psip-self-tuning], To support extensions, such as [I-D.maenpaa-p2psip-self-tuning],
Peers SHOULD send a Leave request to all members of their neighbor Peers SHOULD send a Leave request to all members of their neighbor
table prior to exiting the Overlay Instance. The table prior to exiting the Overlay Instance. The
overlay_specific_data field MUST contain the ChordLeaveData structure overlay_specific_data field MUST contain the ChordLeaveData structure
defined below: defined below:
enum { reserved (0), enum { reserved (0),
from_succ(1), from_pred(2), (255) } from_succ(1), from_pred(2), (255) }
ChordLeaveType; ChordLeaveType;
struct { struct {
skipping to change at page 110, line 44 skipping to change at page 111, line 44
information. An example document is shown below. information. An example document is shown below.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<overlay xmlns="urn:ietf:params:xml:ns:p2p:config-base" <overlay xmlns="urn:ietf:params:xml:ns:p2p:config-base"
xmlns:ext="urn:ietf:params:xml:ns:p2p:config-ext1" xmlns:ext="urn:ietf:params:xml:ns:p2p:config-ext1"
xmlns:chord="urn:ietf:params:xml:ns:p2p:config-chord"> xmlns:chord="urn:ietf:params:xml:ns:p2p:config-chord">
<configuration instance-name="overlay.example.org" sequence="22" <configuration instance-name="overlay.example.org" sequence="22"
expiration="2002-10-10T07:00:00Z"> expiration="2002-10-10T07:00:00Z">
<ice-lite-permitted>false</ice-lite-permitted> <ice-lite-permitted>false</ice-lite-permitted>
<bootstrap-node>192.0.0.1:5678</bootstrap-node> <bootstrap-node address="192.0.0.1" port="5678" />
<bootstrap-node>192.0.2.2:6789</bootstrap-node> <bootstrap-node address="192.0.2.2" port="6789" />
<initial-ttl> 30 </initial-ttl> <initial-ttl> 30 </initial-ttl>
<clients-permitted>false</clients-permitted> <clients-permitted>false</clients-permitted>
<turn-density> 10 </turn-density>< <turn-density> 10 </turn-density>
<max-message-size>4000</max-message-size> <max-message-size>4000</max-message-size>
<enrollment-server>https://example.org</enrollment-server> <enrollment-server>https://example.org</enrollment-server>
<ext:example-extention> foo </ext:example-extention> <ext:example-extension> foo </ext:example-extension>
<chord:chord-ping-interval>300</chord:chord-ping-interval> <chord:chord-ping-interval>300</chord:chord-ping-interval>
<chord:chord-update-interval>400</chord:chord-update-interval> <chord:chord-update-interval>400</chord:chord-update-interval>
<self-signed-permitted <self-signed-permitted
digest="sha1">false</self-signed-permitted> digest="sha1">false</self-signed-permitted>
<shared-secret>asecret</shared-secret> <shared-secret>asecret</shared-secret>
<topology-plugin>chord</topology-plugin> <topology-plugin>chord</topology-plugin>
<root-cert>DATA GOES HERE</root-cert> <root-cert>DATA GOES HERE</root-cert>
<required-kinds> <required-kinds>
<kind-block> <kind-block>
<kind name="sip-registration"> <kind name="sip-registration">
skipping to change at page 111, line 32 skipping to change at page 112, line 32
VGhpcyBpcyBub3QgcmlnaHQhCg== VGhpcyBpcyBub3QgcmlnaHQhCg==
</kind-signature> </kind-signature>
</kind-block> </kind-block>
<kind-block> <kind-block>
<kind id="2000"> <kind id="2000">
<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-extention> 1 <ext:example-kind-extension> 1
</ext:example-kind-extention> </ext:example-kind-extension>
</kind> </kind>
<kind-signature> <kind-signature>
VGhpcyBpcyBub3QgcmlnaHQhCg== VGhpcyBpcyBub3QgcmlnaHQhCg==
</kind-signature> </kind-signature>
</kind-block> </kind-block>
</required-kinds> </required-kinds>
<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>
</configuration> </configuration>
<signature> VGhpcyBpcyBub3QgcmlnaHQhCg==</signature> <signature> VGhpcyBpcyBub3QgcmlnaHQhCg==</signature>
</overlay> </overlay>
The file MUST be a well formed XML document and it SHOULD contain an The file MUST be a well formed XML document and it SHOULD contain an
encoding declaration in the XML declaration. If the charset encoding declaration in the XML declaration. If the charset
parameter of the MIME content type declaration is present and it is parameter of the MIME content type declaration is present and it is
different from the encoding declaration, the charset parameter takes different from the encoding declaration, the charset parameter takes
precedence. Every application conforming to this specification MUST precedence. Every application conforming to this specification MUST
accept the UTF-8 character encoding to ensure minimal accept the UTF-8 character encoding to ensure minimal
skipping to change at page 112, line 42 skipping to change at page 113, line 43
server and root-cert elements may be absent. Otherwise, it SHOULD server and root-cert elements may be absent. Otherwise, it SHOULD
be absent, but MAY be set to "false". This element also contains be absent, but MAY be set to "false". This element also contains
an attribute "digest" which indicates the digest to be used to an attribute "digest" which indicates the digest to be used to
compute the Node-ID. Valid values for this parameter are "SHA-1" compute the Node-ID. Valid values for this parameter are "SHA-1"
and "SHA-256". Implementations MUST support both of these and "SHA-256". Implementations MUST support both of these
algorithms. algorithms.
bootstrap-node This element represents the address of one of the bootstrap-node This element represents the address of one of the
bootstrap nodes. It has an attribute called "address" that bootstrap nodes. It has an attribute called "address" that
represents the IP address (either IPv4 or IPv6, since they can be represents the IP address (either IPv4 or IPv6, since they can be
distinguished) and an attribute called "port" that represents the distinguished) and an attribute called "port" that represents the
port. More than one bootstrap-peer element may be present. port. The IP address is in typical decimal of hex from suing
standard period and colon separators. (TODO - provide a reference
to well specified version of this). More than one bootstrap-peer
element may be present.
turn-density This element is a positive integer that represents the turn-density This element is a positive integer that represents the
approximate reciprocal of density of nodes that can act as TURN approximate reciprocal of density of nodes that can act as TURN
servers. For example, if 10% of the nodes can act as TURN servers. For example, if 10% of the nodes can act as TURN
servers, this would be set to 10. If it is not present, the servers, this would be set to 10. If it is not present, the
default value is 1. default value is 1.
multicast-bootstrap This element represents the address of a multicast-bootstrap This element represents the address of a
multicast, boradcast, or anycast address and port that may be used multicast, broadcast, or anycast address and port that may be used
for bootstrap. Nodes SHOULD listen on the address. It has an for bootstrap. Nodes SHOULD listen on the address. It has an
attributed called "address" that represents the IP address and an attributed called "address" that represents the IP address and an
attribute called "port" that represents the port. More than one attribute called "port" that represents the port. More than one
"multicast-bootstrap" element may be present. "multicast-bootstrap" element may be present.
clients-permitted This element represents whether clients are clients-permitted This element represents whether clients are
permitted or whether all nodes must be peers. If it is set to permitted or whether all nodes must be peers. If it is set to
"TRUE" or absent, this indicates that clients are permitted. If "TRUE" or absent, this indicates that clients are permitted. If
it is set to "FALSE" then nodes MUST join as peers. it is set to "FALSE" then nodes MUST join as peers.
ice-lite-permitted This element represents whether nodes are ice-lite-permitted This element represents whether nodes are
allowed to use the "no-ICE" Overlay Link protocols. in this allowed to use the "no-ICE" Overlay Link protocols. in this
skipping to change at page 113, line 36 skipping to change at page 114, line 36
shared secret. shared secret.
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.
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.
bad-node This contains a single Node-ID in hexadecimal and
indicates that the certificate with this Node-ID MUST not be
considered valid. This allows certificate revocation.
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 atribute. The name Each kind has either an ID attribute or a name atribute. The name
skipping to change at page 115, line 9 skipping to change at page 116, line 10
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:
namespace chord = "urn:ietf:params:xml:ns:p2p:config-chord" namespace chord = "urn:ietf:params:xml:ns:p2p:config-chord"
namespace local = "" namespace local = ""
default namespace p2pcf="urn:ietf:params:xml:ns:p2p:config-base" default namespace p2pcf = "urn:ietf:params:xml:ns:p2p:config-base"
namespace rng = "http://relaxng.org/ns/structure/1.0" namespace rng = "http://relaxng.org/ns/structure/1.0"
anything = anything =
(element * { anything } (element * { anything }
| attribute * { text } | attribute * { text }
| text)* | text)*
foreign-elements = element * - (p2pcf:*|local:*|chord:*) {anything}*
start = foreign-elements = element * - (p2pcf:* | local:* | chord:*) { anything }*
element p2pcf:overlay { foreign-attributes = attribute * - (p2pcf:*|local:*|chord:*) { text }*
element configuration { foreign-nodes = (foreign-attributes | foreign-elements)*
attribute instance-name { text },
attribute expiration { xsd:dateTime },
attribute sequence { xsd:long },
parameter
},
element signature {
attribute algorithm { signature-algorithm-type }?,
xsd:base64Binary
}?
}
signature-algorithm-type |= "rsa-sha1"
parameter &= element topology-plugin { topology-plugin-type } start =
parameter &= element max-message-size { xsd:int }? element p2pcf:overlay {
parameter &= element initial-ttl { xsd:int }? element configuration {
parameter &= element root-cert { text }? attribute instance-name { text },
parameter &= element required-kinds { kind-block* } attribute expiration { xsd:dateTime },
parameter &= element enrollment-server { xsd:anyURI }? attribute sequence { xsd:long },
parameter &= element kind-signer { text }* parameter
parameter &= element ice-lite-permitted { xsd:boolean }? },
parameter &= element shared-secret { xsd:string }? element signature {
parameter &= element clients-permitted { xsd:boolean }? attribute algorithm { signature-algorithm-type }?,
parameter &= element turn-density { xsd:int }? xsd:base64Binary
parameter &= foreign-elements* }?
parameter &= }
element self-signed-permitted { signature-algorithm-type |= "rsa-sha1"
attribute digest { self-signed-digest-type },
xsd:boolean
}?
self-signed-digest-type |= "sha1"
parameter &=
element bootstrap-node { hostPort
}+
hostPort = text
parameter &=
element multicast-bootstrap { hostPort
}*
kind-block = element kind-block { parameter &= element topology-plugin { topology-plugin-type }
element kind { parameter &= element max-message-size { xsd:int }?
(attribute name { kind-names } parameter &= element initial-ttl { xsd:int }?
| attribute id { xsd:int }), parameter &= element root-cert { text }?
kind-paramter parameter &= element required-kinds { kind-block* }
} & parameter &= element enrollment-server { xsd:anyURI }?
element kind-signature { parameter &= element kind-signer { text }*
attribute algorithm { signature-algorithm-type }?, parameter &= element bad-node { text }*
xsd:base64Binary parameter &= element attach-lite-permitted { xsd:boolean }?
}? parameter &= element shared-secret { xsd:string }?
parameter &= element clients-permitted { xsd:boolean }?
parameter &= element turn-density { xsd:int }?
parameter &= foreign-elements*
parameter &=
element self-signed-permitted {
attribute digest { self-signed-digest-type },
xsd:boolean
}?
self-signed-digest-type |= "sha1"
parameter &=
element bootstrap-node {
attribute address { xsd:string },
attribute port { xsd:int }
}+
hostPort = text
parameter &=
element multicast-bootstrap { hostPort
}*
} kind-block = element kind-block {
element kind {
(attribute name { kind-names }
| attribute id { xsd:int }),
kind-paramter
} &
element kind-signature {
attribute algorithm { signature-algorithm-type }?,
xsd:base64Binary
}?
kind-paramter &= element max-count { xsd:int } }
kind-paramter &= element max-size { xsd:int }
kind-paramter &= element data-model { data-model-type }
data-model-type |= "single"
data-model-type |= "array"
data-model-type |= "dictionary"
kind-paramter &= element access-control { access-control-type }
kind-paramter &= element max-node-multiple { xsd:int }?
access-control-type |= "user-match"
access-control-type |= "node-match"
access-control-type |= "user-node-match"
access-control-type |= "node-multiple"
access-control-type |= "user-match-with-anon-create"
kind-paramter &= foreign-elements*
# Chord specific paramters kind-paramter &= element max-count { xsd:int }
topology-plugin-type |= "chord" kind-paramter &= element max-size { xsd:int }
kind-names |= "sip-registration" kind-paramter &= element data-model { data-model-type }
kind-names |= "turn-service" data-model-type |= "single"
parameter &= element chord:chord-ping-interval { xsd:int }? data-model-type |= "array"
parameter &= element chord:chord-update-interval { xsd:int }? data-model-type |= "dictionary"
kind-paramter &= element access-control { access-control-type }
kind-paramter &= element max-node-multiple { xsd:int }?
access-control-type |= "user-match"
access-control-type |= "node-match"
access-control-type |= "user-node-match"
access-control-type |= "node-multiple"
access-control-type |= "user-match-with-anon-create"
kind-paramter &= foreign-elements*
# Chord specific paramters
topology-plugin-type |= "chord"
kind-names |= "sip-registration"
kind-names |= "turn-service"
parameter &= element chord:chord-ping-interval { xsd:int }?
parameter &= element chord:chord-update-interval { xsd:int }?
10.2. Discovery Through Enrollment Server 10.2. Discovery Through Enrollment 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 an enrollment server. Related work to the discovery process to find an enrollment server. Related work to the
approach used here is described in approach used here is described in
[I-D.garcia-p2psip-dns-sd-bootstrapping] and [I-D.garcia-p2psip-dns-sd-bootstrapping] and
[I-D.matthews-p2psip-bootstrap-mechanisms]. Another scheme for [I-D.matthews-p2psip-bootstrap-mechanisms]. Another scheme for
referencing overlays is described in referencing overlays is described in
[I-D.hardie-p2poverlay-pointers]. [I-D.hardie-p2poverlay-pointers].
The node first determines the overlay name. This value is provided The node first determines the overlay name. This value is provided
by the user or some other out-of-band provisioning mechanism. The by the user or some other out-of-band provisioning mechanism. The
out-of-band mechanisms may also provide an optional URL for the out-of-band mechanisms may also provide an optional URL for the
enrollment server. If a URL for the enrollment server is not enrollment server. If a URL for the enrollment server is not
provided, the node MUST do a DNS SRV query using a Service name of provided, the node MUST do a DNS SRV query using a Service name of
"p2psip_enroll" and a protocol of tcp to find an enrollment server "p2psip_enroll" and a protocol of tcp to find an enrollment server
and form the URL by appending a path of "/p2psip/ enroll" to the and form the URL by appending a path of "/p2psip/enroll" to the
overlay name. For example, if the overlay name was example.com, the overlay name. For example, if the overlay name was example.com, the
URL would be "https://example.com/p2psip/enroll". URL would be "https://example.com/p2psip/enroll".
Once an address and URL for the enrollment server is determined, the Once an address and URL for the enrollment server is determined, the
peer forms an HTTPS connection to that IP address. The certificate peer forms an HTTPS connection to that IP address. The certificate
MUST match the overlay name as described in [RFC2818]. Then the node MUST match the overlay name as described in [RFC2818]. Then the node
MUST fetch a new copy of the configuration file. To do this, the MUST fetch a new copy of the configuration file. To do this, the
peer performs a GET to the URL. The result of the HTTP GET is an XML peer performs a GET to the URL. The result of the HTTP GET is an XML
configuration file described above, which replaces any previously configuration file described above, which replaces any previously
learned configuration file for this overlay. learned configuration file for this overlay.
skipping to change at page 117, line 47 skipping to change at page 118, line 49
10.3. Credentials 10.3. Credentials
If the configuration document contains a enrollment-server element, If the configuration document contains a enrollment-server element,
credentials are required to join the Overlay Instance. A peer which credentials are required to join the Overlay Instance. A peer which
does not yet have credentials MUST contact the enrollment server to does not yet have credentials MUST contact the enrollment server to
acquire them. acquire them.
RELOAD defines its own trivial certificate request protocol. We RELOAD defines its own trivial certificate request protocol. We
would have liked to have used an existing protocol but were concerned would have liked to have used an existing protocol but were concerned
about the implementation burden of even the simplest of those about the implementation burden of even the simplest of those
protocols, such as [RFC5272]) and [RFC5273]. Our objective was to protocols, such as [RFC5272] and [RFC5273]. Our objective was to
have a protocol which could be easily implemented in a Web server have a protocol which could be easily implemented in a Web server
which the operator did not control (e.g., in a hosted service) and which the operator did not control (e.g., in a hosted service) and
was compatible with the existing certificate handling tooling as used was compatible with the existing certificate handling tooling as used
with the Web certificate infrastructure. This means accepting bare with the Web certificate infrastructure. This means accepting bare
PKCS#10 requests and returning a single bare X.509 certificate. PKCS#10 requests and returning a single bare X.509 certificate.
Although the MIME types for these objects are defined, none of the Although the MIME types for these objects are defined, none of the
existing protocols support exactly this model. existing protocols support exactly this model.
The certificate request protocol is performed over HTTPS. The The certificate request protocol is performed over HTTPS. The
request is an HTTP POST with the following properties: request is an HTTP POST with the following properties:
o If authentication is required, there is a URL parameter of o If authentication is required, there is a URL parameter of
"password" and "username" containing the user's name and password "password" and "username" containing the user's name and password
in the clear (hence the need for HTTPS) in the clear (hence the need for HTTPS)
o The body is of content type "application/pkcs10", as defined in o The body is of content type "application/pkcs10", as defined in
skipping to change at page 118, line 29 skipping to change at page 119, line 31
The enrollment server MUST authenticate the request using the The enrollment server MUST authenticate the request using the
provided user name and password. If the authentication succeeds and provided user name and password. If the authentication succeeds and
the requested user name is acceptable, the server generates and the requested user name is acceptable, the server generates and
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. Each is way that they are unpredictable to the requesting user. Each is
placed in the subjectAltName using the uniformResourceIdentifier placed in the subjectAltName using the uniformResourceIdentifier
type and MUST contain RELOAD URIs as described in Section 13.12 type and MUST contain RELOAD URIs as described in Section 13.13
and MUST contain a Destination list with a single entry of type and MUST contain a Destination list with a single entry of type
"node_id". "node_id".
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", with an The certificate is returned as type "application/pkix-cert", with an
HTTP status code of 200 OK. Certificate processing errors should be HTTP status code of 200 OK. Certificate processing errors should be
treated as HTTP errors and have appropriate HTTP stats codes. treated as HTTP errors and 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 by one
of the certificates received in the "root-cert" list of the overlay of 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 and set to "TRUE", If the "self-signed-permitted" element is present and set to "TRUE",
then a node MUST generate its own self-signed certificate to join the then a node MUST generate its own self-signed certificate to join the
skipping to change at page 126, line 16 skipping to change at page 128, line 16
The two basic functions provided by overlay nodes are storage and The two basic functions provided by overlay nodes are storage and
routing: some node is responsible for storing a peer's data and for routing: some node is responsible for storing a peer's data and for
allowing a third peer to fetch this stored data. Other nodes are allowing a third peer to fetch this stored data. Other nodes are
responsible for routing messages to and from the storing nodes. Each responsible for routing messages to and from the storing nodes. Each
of these issues is covered in the following sections. of these issues is covered in the following sections.
P2P overlays are subject to attacks by subversive nodes that may P2P overlays are subject to attacks by subversive nodes that may
attempt to disrupt routing, corrupt or remove user registrations, or attempt to disrupt routing, corrupt or remove user registrations, or
eavesdrop on signaling. The certificate-based security algorithms we eavesdrop on signaling. The certificate-based security algorithms we
describe in this draft are intended to protect overlay routing and describe in this specification are intended to protect overlay
user registration information in RELOAD messages. routing and user registration information in RELOAD messages.
To protect the signaling from attackers pretending to be valid peers To protect the signaling from attackers pretending to be valid peers
(or peers other than themselves), the first requirement is to ensure (or peers other than themselves), the first requirement is to ensure
that all messages are received from authorized members of the that all messages are received from authorized members of the
overlay. For this reason, RELOAD transports all messages over a overlay. For this reason, RELOAD transports all messages over a
secure channel (TLS and DTLS are defined in this document) which secure channel (TLS and DTLS are defined in this document) which
provides message integrity and authentication of the directly provides message integrity and authentication of the directly
communicating peer. In addition, messages and data are digitally communicating peer. In addition, messages and data are digitally
signed with the sender's private key, providing end-to-end security signed with the sender's private key, providing end-to-end security
for communications. for communications.
skipping to change at page 127, line 5 skipping to change at page 129, line 5
with the user's public key. with the user's public key.
Each certificate enables an entity to act in two sorts of roles: Each certificate enables an entity to act in two sorts of roles:
o As a user, storing data at specific Resource-IDs in the Overlay o As a user, storing data at specific Resource-IDs in the Overlay
Instance corresponding to the user name. Instance corresponding to the user name.
o As a overlay peer with the Peer-ID(s) listed in the certificate. o As a overlay peer with the Peer-ID(s) listed in the certificate.
Note that since only users of this Overlay Instance need to validate Note that since only users of this Overlay Instance need to validate
a certificate, this usage does not require a global PKI. Instead, a certificate, this usage does not require a global PKI. Instead,
certificates are signed by require a central enrollment authority certificates are signed by a central enrollment authority which acts
which acts as the certificate authority for the Overlay Instance. as the certificate authority for the Overlay Instance. This
This authority signs each peer's certificate. Because each peer authority signs each peer's certificate. Because each peer possesses
possesses the CA's certificate (which they receive on enrollment) the CA's certificate (which they receive on enrollment) they can
they can verify the certificates of the other entities in the overlay verify the certificates of the other entities in the overlay without
without further communication. Because the certificates contain the further communication. Because the certificates contain the user/
user/peer's public key, communications from the user/peer can be peer's public key, communications from the user/peer can be verified
verified in turn. in turn.
If self-signed certificates are used, then the security provided is If self-signed certificates are used, then the security provided is
significantly decreased, since attackers can mount Sybil attacks. In significantly decreased, since attackers can mount Sybil attacks. In
addition, attackers cannot trust the user names in certificates addition, attackers cannot trust the user names in certificates
(though they can trust the Node-IDs because they are (though they can trust the Node-IDs because they are
cryptographically verifiable). This scheme may be appropriate for cryptographically verifiable). This scheme may be appropriate for
some small deployments, such as a small office or an ad hoc overlay some small deployments, such as a small office or an ad hoc overlay
set up among participants in a meeting where all hosts on the network set up among participants in a meeting where all hosts on the network
are trusted. Some additional security can be provided by using the are trusted. Some additional security can be provided by using the
shared secret admission control scheme as well. shared secret admission control scheme as well.
skipping to change at page 131, line 52 skipping to change at page 133, line 52
cryptography. cryptography.
In some situations, however, it is desirable to be able to establish In some situations, however, it is desirable to be able to establish
the identity of a peer with whom one is not directly connected. The the identity of a peer with whom one is not directly connected. The
most natural case is when a peer Updates its state. At this point, most natural case is when a peer Updates its state. At this point,
other peers may need to update their view of the overlay structure, other peers may need to update their view of the overlay structure,
but they need to verify that the Update message came from the actual but they need to verify that the Update message came from the actual
peer rather than from an attacker. To prevent this, all overlay peer rather than from an attacker. To prevent this, all overlay
routing messages are signed by the peer that generated them. routing messages are signed by the peer that generated them.
Replay is typical prevented for messages that impact the topology of Replay is typically prevented for messages that impact the topology
the overlay by having the information come directly, or be verified of the overlay by having the information come directly, or be
by, the nodes that claimed to have generated the update. Data verified by, the nodes that claimed to have generated the update.
storage replay detection is done by signing time of the node that Data storage replay detection is done by signing time of the node
generated the signature on the store request thus providing a time that generated the signature on the store request thus providing a
based replay protection but the time synchronization is only needed time based replay protection but the time synchronization is only
between peers that can write to the same location. needed between peers that can write to the same location.
12.6.4. Protecting the Signaling 12.6.4. Protecting the Signaling
The goal here is to stop an attacker from knowing who is signaling The goal here is to stop an attacker from knowing who is signaling
what to whom. An attacker is unlikely to be able to observe the what to whom. An attacker is unlikely to be able to observe the
activities of a specific individual given the randomization of IDs activities of a specific individual given the randomization of IDs
and routing based on the present peers discussed above. Furthermore, and routing based on the present peers discussed above. Furthermore,
because messages can be routed using only the header information, the because messages can be routed using only the header information, the
actual body of the RELOAD message can be encrypted during actual body of the RELOAD message can be encrypted during
transmission. transmission.
skipping to change at page 134, line 10 skipping to change at page 136, line 10
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:
USER-MATCH USER-MATCH
NODE-MATCH NODE-MATCH
USER-NODE-MATCH USER-NODE-MATCH
NODE-MULTIPLE NODE-MULTIPLE
13.4. Data Kind-ID 13.4. Application-ID
IANA SHALL create a "RELOAD Application-ID" Registry. Entries in
this registry are 16-bit integers denoting applictions kinds. Code
points in the range 0x0001 to 0x7fff SHALL be registered via RFC 5226
Standards Action. Code points in the range 0x8000 to 0xf000 SHALL be
registered via RFC 5226 Expert Review. Code points in the range
0xf001 to 0xfffe are reserved for private us. The initial contents
of this registry are:
+-------------+----------------+-------------------------------+
| Application | Application-ID | Specification |
+-------------+----------------+-------------------------------+
| INVALID | 0 | RFC-AAAA |
| RELOAD | 1 | RFC-AAAA |
| SIP | 5060 | Reserved for use by SIP Usage |
| SIP | 5061 | Reserved for use by SIP Usage |
| Reserved | 0xffff | RFC-AAAA |
+-------------+----------------+-------------------------------+
13.5. 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.1.2. Code points in the range 0x00000001 to 0x7fffffff Section 4.1.2. Code points in the range 0x00000001 to 0x7fffffff
SHALL be registered via RFC 5226 Standards Action. Code points in SHALL be registered via RFC 5226 Standards Action. Code points in
the range 0x8000000 to 0xf0000000 SHALL be registered via RFC 5226 the range 0x8000000 to 0xf0000000 SHALL be registered via RFC 5226
Expert Review. Code points in the range 0xf0000001 to 0xffffffff are Expert Review. Code points in the range 0xf0000001 to 0xffffffff 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:
skipping to change at page 134, line 32 skipping to change at page 137, line 5
| 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 | 0xffffffff | RFC-AAAA | | Reserved | 0xffffffff | RFC-AAAA |
+---------------------+------------+----------+ +---------------------+------------+----------+
13.5. Data Model 13.6. 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 are 8-bit integers denoting data models, as described in registry are 8-bit integers denoting data models, as described in
Section 6.2. Code points in this registry SHALL be registered via Section 6.2. Code points in this registry SHALL be registered via
RFC 5226 Standards Action. The initial contents of this registry RFC 5226 Standards Action. The initial contents of this registry
are: are:
+--------------+------+----------+ +--------------+------+----------+
| Data Model | Code | RFC | | Data Model | Code | RFC |
+--------------+------+----------+ +--------------+------+----------+
| INVALID | 0 | RFC-AAAA | | INVALID | 0 | RFC-AAAA |
| SINGLE_VALUE | 1 | RFC-AAAA | | SINGLE_VALUE | 1 | RFC-AAAA |
| ARRAY | 2 | RFC-AAAA | | ARRAY | 2 | RFC-AAAA |
| DICTIONARY | 3 | RFC-AAAA | | DICTIONARY | 3 | RFC-AAAA |
| RESERVED | 255 | RFC-AAAA | | RESERVED | 255 | RFC-AAAA |
+--------------+------+----------+ +--------------+------+----------+
13.6. Message Codes 13.7. 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:
+--------------------+----------------+----------+ +---------------------------------+----------------+----------+
| Message Code Name | Code Value | RFC | | Message Code Name | Code Value | RFC |
+--------------------+----------------+----------+ +---------------------------------+----------------+----------+
| invalid | 0 | RFC-AAAA | | invalid | 0 | RFC-AAAA |
| probe_req | 1 | RFC-AAAA | | probe_req | 1 | RFC-AAAA |
| probe_ans | 2 | RFC-AAAA | | probe_ans | 2 | RFC-AAAA |
| attach_req | 3 | RFC-AAAA | | attach_req | 3 | RFC-AAAA |
| attach_ans | 4 | RFC-AAAA | | attach_ans | 4 | RFC-AAAA |
| unused | 5 | | | unused | 5 | |
| unused | 6 | | | unused | 6 | |
| store_req | 7 | RFC-AAAA | | store_req | 7 | RFC-AAAA |
| store_ans | 8 | RFC-AAAA | | store_ans | 8 | RFC-AAAA |
| fetch_req | 9 | RFC-AAAA | | fetch_req | 9 | RFC-AAAA |
| fetch_ans | 10 | RFC-AAAA | | fetch_ans | 10 | RFC-AAAA |
| remove_req | 11 | RFC-AAAA | | remove_req | 11 | RFC-AAAA |
| remove_ans | 12 | RFC-AAAA | | remove_ans | 12 | RFC-AAAA |
| find_req | 13 | RFC-AAAA | | find_req | 13 | RFC-AAAA |
| find_ans | 14 | RFC-AAAA | | find_ans | 14 | RFC-AAAA |
| join_req | 15 | RFC-AAAA | | join_req | 15 | RFC-AAAA |
| join_ans | 16 | RFC-AAAA | | join_ans | 16 | RFC-AAAA |
| leave_req | 17 | RFC-AAAA | | leave_req | 17 | RFC-AAAA |
| leave_ans | 18 | RFC-AAAA | | leave_ans | 18 | RFC-AAAA |
| update_req | 19 | RFC-AAAA | | update_req | 19 | RFC-AAAA |
| update_ans | 20 | RFC-AAAA | | update_ans | 20 | RFC-AAAA |
| route_query_req | 21 | RFC-AAAA | | route_query_req | 21 | RFC-AAAA |
| route_query_ans | 22 | RFC-AAAA | | route_query_ans | 22 | RFC-AAAA |
| ping_req | 23 | RFC-AAAA | | ping_req | 23 | RFC-AAAA |
| ping_ans | 24 | RFC-AAAA | | ping_ans | 24 | RFC-AAAA |
| stat_req | 25 | RFC-AAAA | | stat_req | 25 | RFC-AAAA |
| stat_ans | 26 | RFC-AAAA | | stat_ans | 26 | RFC-AAAA |
| attachlite_req | 27 | RFC-AAAA | | unused (was attachlite_req) | 27 | RFC-AAAA |
| attachlite_ans | 28 | RFC-AAAA | | unused (was attachlite_ans) | 28 | RFC-AAAA |
| app_attach_req | 29 | RFC-AAAA | | app_attach_req | 29 | RFC-AAAA |
| attach_ans | 30 | RFC-AAAA | | app_attach_ans | 30 | RFC-AAAA |
| app_attachlite_req | 31 | RFC-AAAA | | unused (was app_attachlite_req) | 31 | RFC-AAAA |
| app_attachlite_ans | 32 | RFC-AAAA | | unused (was app_attachlite_ans) | 32 | RFC-AAAA |
| reserved | 0x8000..0xfffe | RFC-AAAA | | reserved | 0x8000..0xfffe | RFC-AAAA |
| error | 0xffff | RFC-AAAA | | error | 0xffff | RFC-AAAA |
+--------------------+----------------+----------+ +---------------------------------+----------------+----------+
13.7. Error Codes 13.8. Error Codes
IANA SHALL create a "RELOAD Error Code" Registry. Entries in this IANA SHALL create a "RELOAD Error Code" Registry. Entries in this
registry are 16-bit integers denoting error codes. New entries SHALL registry are 16-bit integers denoting error codes. New entries SHALL
be defined via RFC 5226 Standards Action. The initial contents of be defined via RFC 5226 Standards Action. The initial contents of
this registry are: this registry are:
+-------------------------------------+----------------+----------+ +-------------------------------------+----------------+----------+
| Error Code Name | Code Value | RFC | | Error Code Name | Code Value | RFC |
+-------------------------------------+----------------+----------+ +-------------------------------------+----------------+----------+
| invalid | 0 | RFC-AAAA | | invalid | 0 | RFC-AAAA |
skipping to change at page 136, line 32 skipping to change at page 139, line 25
| Error_Unsupported_Forwarding_Option | 7 | RFC-AAAA | | Error_Unsupported_Forwarding_Option | 7 | RFC-AAAA |
| Error_Data_Too_Large | 8 | RFC-AAAA | | Error_Data_Too_Large | 8 | RFC-AAAA |
| Error_Data_Too_Old | 9 | RFC-AAAA | | Error_Data_Too_Old | 9 | RFC-AAAA |
| Error_TTL_Exceeded | 10 | RFC-AAAA | | Error_TTL_Exceeded | 10 | RFC-AAAA |
| Error_Message_Too_Large | 11 | RFC-AAAA | | Error_Message_Too_Large | 11 | RFC-AAAA |
| Error_Unknown_Kind | 12 | RFC-AAAA | | Error_Unknown_Kind | 12 | RFC-AAAA |
| Error_Unknown_Extension | 13 | RFC-AAAA | | Error_Unknown_Extension | 13 | RFC-AAAA |
| reserved | 0x8000..0xfffe | RFC-AAAA | | reserved | 0x8000..0xfffe | RFC-AAAA |
+-------------------------------------+----------------+----------+ +-------------------------------------+----------------+----------+
13.8. Overlay Link Types 13.9. Overlay Link Types
IANA shall create a "RELOAD Overlay Link." New entries SHALL be IANA shall create a "RELOAD Overlay Link." New entries SHALL be
defined via RFC 5226 Standards Action. This registry SHALL be defined via RFC 5226 Standards Action. This registry SHALL be
initially populated with the following values: 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 |
| reserved | 255 | RFC-AAAA | | reserved | 255 | RFC-AAAA |
+--------------------+------+---------------+ +--------------------+------+---------------+
13.9. Forwarding Options 13.10. 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 |
| reserved | 255 | RFC-AAAA | | reserved | 255 | RFC-AAAA |
+-------------------+------+---------------+ +-------------------+------+---------------+
13.10. Probe Information Types 13.11. 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 |
| reserved | 255 | RFC-AAAA | | reserved | 255 | RFC-AAAA |
+-----------------+------+---------------+ +-----------------+------+---------------+
13.11. Message Extensions 13.12. 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 |
| reserved | 0xFFFF | RFC-AAAA | | reserved | 0xFFFF | RFC-AAAA |
+-----------------+--------+---------------+ +-----------------+--------+---------------+
13.12. reload URI Scheme 13.13. 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.
The reload URI is defined using a subset of the URI schema specified The reload URI is defined using a subset of the URI schema specified
in Appendix A of RFC 3986 [RFC3986] and the associated URI Guidelines in Appendix A of RFC 3986 [RFC3986] and the associated URI Guidelines
[RFC4395] per the following ABNF syntax: [RFC4395] per the following ABNF syntax:
RELOAD-URI = "reload://" destination "@" overlay "/" RELOAD-URI = "reload://" destination "@" overlay "/"
[specifier] [specifier]
destination = 1 * HEXDIG destination = 1 * HEXDIG
skipping to change at page 138, line 32 skipping to change at page 141, line 26
overlay: the name of the overlay. overlay: the name of the overlay.
specifier : a hex-encoded StoredDataSpecifier indicating the data specifier : a hex-encoded StoredDataSpecifier indicating the data
element. element.
If no specifier is present then this URI addresses the peer which can If no specifier is present then this URI addresses the peer which can
be reached via the indicated destination list at the indicated be reached via the indicated destination list at the indicated
overlay name. If a specifier is present, then the URI addresses the overlay name. If a specifier is present, then the URI addresses the
data value. data value.
13.12.1. URI Registration 13.13.1. URI Registration
The following summarizes the information necessary to register the The following summarizes the information necessary to register the
reload URI. reload URI.
URI Scheme Name: reload URI Scheme Name: reload
Status: permanent Status: permanent
URI Scheme Syntax: see Section 13.12 of RFC-AAAA URI Scheme Syntax: see Section 13.13 of RFC-AAAA
URI Scheme Semantics: The reload URI is intended to be used as a URI Scheme Semantics: The reload URI is intended to be used as a
reference to a RELOAD peer or resource. reference to a RELOAD peer or resource.
Encoding Considerations: The reload URI is not intended to be Encoding Considerations: The reload URI is not intended to be
human-readable text, so it is encoded entirely in US-ASCII. human-readable text, so it is encoded entirely in US-ASCII.
Applications/protocols that use this URI scheme: The RELOAD Applications/protocols that use this URI scheme: The RELOAD
protocol described in RFC-AAAA. protocol described in RFC-AAAA.
Interoperability considerations See RFC-AAAA. Interoperability considerations See RFC-AAAA.
Security considerations See RFC-AAAA Security considerations See RFC-AAAA
Contact Cullen Jennings <fluffy@cisco.com> Contact Cullen Jennings <fluffy@cisco.com>
Author/Change controller IESG Author/Change controller IESG
References RFC-AAAA References RFC-AAAA
14. Acknowledgments 14. Acknowledgments
This draft is a merge of the "REsource LOcation And Discovery This specification is a merge of the "REsource LOcation And Discovery
(RELOAD)" draft by David A. Bryan, Marcia Zangrilli and Bruce B. (RELOAD)" draft by David A. Bryan, Marcia Zangrilli and Bruce B.
Lowekamp, the "Address Settlement by Peer to Peer" draft by Cullen Lowekamp, the "Address Settlement by Peer to Peer" draft by Cullen
Jennings, Jonathan Rosenberg, and Eric Rescorla, the "Security Jennings, Jonathan Rosenberg, and Eric Rescorla, the "Security
Extensions for RELOAD" draft by Bruce B. Lowekamp and James Deverick, Extensions for RELOAD" draft by Bruce B. Lowekamp and James Deverick,
the "A Chord-based DHT for Resource Lookup in P2PSIP" by Marcia the "A Chord-based DHT for Resource Lookup in P2PSIP" by Marcia
Zangrilli and David A. Bryan, and the Peer-to-Peer Protocol (P2PP) Zangrilli and David A. Bryan, and the Peer-to-Peer Protocol (P2PP)
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 imporvements. from that. Vidya Narayanan provided many comments and imporvements.
skipping to change at page 141, line 37 skipping to change at page 144, line 27
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
RFC 5382, October 2008. RFC 5382, October 2008.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
the Session Description Protocol (SDP)", RFC 4145, the Session Description Protocol (SDP)", RFC 4145,
September 2005. September 2005.
[RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP)
and RTP Control Protocol (RTCP) Packets over Connection-
Oriented Transport", RFC 4571, July 2006.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin,
"Using the Secure Remote Password (SRP) Protocol for TLS "Using the Secure Remote Password (SRP) Protocol for TLS
Authentication", RFC 5054, November 2007. Authentication", RFC 5054, November 2007.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
 End of changes. 76 change blocks. 
390 lines changed or deleted 477 lines changed or added

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