draft-ietf-p2psip-base-08.txt   draft-ietf-p2psip-base-09.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: September 8, 2010 Skype Expires: January 13, 2011 Skype
E. Rescorla E. Rescorla
Network Resonance Network Resonance
S. Baset S. Baset
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
March 7, 2010 July 12, 2010
REsource LOcation And Discovery (RELOAD) Base Protocol REsource LOcation And Discovery (RELOAD) Base Protocol
draft-ietf-p2psip-base-08 draft-ietf-p2psip-base-09
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 specification defines REsource LOcation And Discovery (RELOAD), This specification defines REsource LOcation And Discovery (RELOAD),
a peer-to-peer (P2P) signaling protocol for use on the Internet. A a peer-to-peer (P2P) signaling protocol for use on the Internet. A
P2P signaling protocol provides its clients with an abstract storage P2P signaling protocol provides its clients with an abstract storage
skipping to change at page 2, line 4 skipping to change at page 2, line 4
This documents and the information contained therein are provided on This documents and the information contained therein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE. FOR A PARTICULAR PURPOSE.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on January 13, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
skipping to change at page 3, line 51 skipping to change at page 3, line 51
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 . . . . . . . . . . . . . . . . . . . 37 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 . . . . 43
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 . . . . . . . . . . . . . . . 46
5.3.2.4. Direct Return Response Forwarding Options . . . . 46 5.3.2.4. Direct Return Response Forwarding Options . . . . 47
5.3.3. Message Contents Format . . . . . . . . . . . . . . 47 5.3.3. Message Contents Format . . . . . . . . . . . . . . 48
5.3.3.1. Response Codes and Response Errors . . . . . . . 48 5.3.3.1. Response Codes and Response Errors . . . . . . . 49
5.3.4. Security Block . . . . . . . . . . . . . . . . . . . 50 5.3.4. Security Block . . . . . . . . . . . . . . . . . . . 51
5.4. Overlay Topology . . . . . . . . . . . . . . . . . . . . 53 5.4. Overlay Topology . . . . . . . . . . . . . . . . . . . . 54
5.4.1. Topology Plugin Requirements . . . . . . . . . . . . 53 5.4.1. Topology Plugin Requirements . . . . . . . . . . . . 54
5.4.2. Methods and types for use by topology plugins . . . 54 5.4.2. Methods and types for use by topology plugins . . . 54
5.4.2.1. Join . . . . . . . . . . . . . . . . . . . . . . 54 5.4.2.1. Join . . . . . . . . . . . . . . . . . . . . . . 54
5.4.2.2. Leave . . . . . . . . . . . . . . . . . . . . . . 55 5.4.2.2. Leave . . . . . . . . . . . . . . . . . . . . . . 55
5.4.2.3. Update . . . . . . . . . . . . . . . . . . . . . 55 5.4.2.3. Update . . . . . . . . . . . . . . . . . . . . . 56
5.4.2.4. Route_Query . . . . . . . . . . . . . . . . . . . 56 5.4.2.4. Route_Query . . . . . . . . . . . . . . . . . . . 56
5.4.2.5. Probe . . . . . . . . . . . . . . . . . . . . . . 57 5.4.2.5. Probe . . . . . . . . . . . . . . . . . . . . . . 57
5.5. Forwarding and Link Management Layer . . . . . . . . . . 59 5.5. Forwarding and Link Management Layer . . . . . . . . . . 59
5.5.1. Attach . . . . . . . . . . . . . . . . . . . . . . . 59 5.5.1. Attach . . . . . . . . . . . . . . . . . . . . . . . 60
5.5.1.1. Request Definition . . . . . . . . . . . . . . . 60 5.5.1.1. Request Definition . . . . . . . . . . . . . . . 60
5.5.1.2. Response Definition . . . . . . . . . . . . . . . 62 5.5.1.2. Response Definition . . . . . . . . . . . . . . . 63
5.5.1.3. Using ICE With RELOAD . . . . . . . . . . . . . . 62 5.5.1.3. Using ICE With RELOAD . . . . . . . . . . . . . . 63
5.5.1.4. Collecting STUN Servers . . . . . . . . . . . . . 62 5.5.1.4. Collecting STUN Servers . . . . . . . . . . . . . 63
5.5.1.5. Gathering Candidates . . . . . . . . . . . . . . 63 5.5.1.5. Gathering Candidates . . . . . . . . . . . . . . 64
5.5.1.6. Prioritizing Candidates . . . . . . . . . . . . . 64 5.5.1.6. Prioritizing Candidates . . . . . . . . . . . . . 65
5.5.1.7. Encoding the Attach Message . . . . . . . . . . . 64 5.5.1.7. Encoding the Attach Message . . . . . . . . . . . 65
5.5.1.8. Verifying ICE Support . . . . . . . . . . . . . . 65 5.5.1.8. Verifying ICE Support . . . . . . . . . . . . . . 66
5.5.1.9. Role Determination . . . . . . . . . . . . . . . 65 5.5.1.9. Role Determination . . . . . . . . . . . . . . . 66
5.5.1.10. Full ICE . . . . . . . . . . . . . . . . . . . . 65 5.5.1.10. Full ICE . . . . . . . . . . . . . . . . . . . . 66
5.5.1.11. No ICE . . . . . . . . . . . . . . . . . . . . . 66 5.5.1.11. No ICE . . . . . . . . . . . . . . . . . . . . . 67
5.5.1.12. Subsequent Offers and Answers . . . . . . . . . . 66 5.5.1.12. Subsequent Offers and Answers . . . . . . . . . . 67
5.5.1.13. Sending Media . . . . . . . . . . . . . . . . . . 66 5.5.1.13. Sending Media . . . . . . . . . . . . . . . . . . 67
5.5.1.14. Receiving Media . . . . . . . . . . . . . . . . . 67 5.5.1.14. Receiving Media . . . . . . . . . . . . . . . . . 68
5.5.2. AppAttach . . . . . . . . . . . . . . . . . . . . . 67 5.5.2. AppAttach . . . . . . . . . . . . . . . . . . . . . 68
5.5.2.1. Request Definition . . . . . . . . . . . . . . . 67 5.5.2.1. Request Definition . . . . . . . . . . . . . . . 68
5.5.2.2. Response Definition . . . . . . . . . . . . . . . 68 5.5.2.2. Response Definition . . . . . . . . . . . . . . . 69
5.5.3. Ping . . . . . . . . . . . . . . . . . . . . . . . . 68 5.5.3. Ping . . . . . . . . . . . . . . . . . . . . . . . . 69
5.5.3.1. Request Definition . . . . . . . . . . . . . . . 68 5.5.3.1. Request Definition . . . . . . . . . . . . . . . 69
5.5.3.2. Response Definition . . . . . . . . . . . . . . . 68 5.5.3.2. Response Definition . . . . . . . . . . . . . . . 69
5.5.4. Config_Update . . . . . . . . . . . . . . . . . . . 69 5.5.4. Config_Update . . . . . . . . . . . . . . . . . . . 70
5.5.4.1. Request Definition . . . . . . . . . . . . . . . 69 5.5.4.1. Request Definition . . . . . . . . . . . . . . . 70
5.5.4.2. Response Definition . . . . . . . . . . . . . . . 70 5.5.4.2. Response Definition . . . . . . . . . . . . . . . 71
5.6. Overlay Link Layer . . . . . . . . . . . . . . . . . . . 71 5.6. Overlay Link Layer . . . . . . . . . . . . . . . . . . . 72
5.6.1. Future Overlay Link Protocols . . . . . . . . . . . 72 5.6.1. Future Overlay Link Protocols . . . . . . . . . . . 73
5.6.1.1. HIP . . . . . . . . . . . . . . . . . . . . . . . 72 5.6.1.1. HIP . . . . . . . . . . . . . . . . . . . . . . . 73
5.6.1.2. ICE-TCP . . . . . . . . . . . . . . . . . . . . . 72 5.6.1.2. ICE-TCP . . . . . . . . . . . . . . . . . . . . . 73
5.6.1.3. Message-oriented Transports . . . . . . . . . . . 72 5.6.1.3. Message-oriented Transports . . . . . . . . . . . 73
5.6.1.4. Tunneled Transports . . . . . . . . . . . . . . . 72 5.6.1.4. Tunneled Transports . . . . . . . . . . . . . . . 73
5.6.2. Framing Header . . . . . . . . . . . . . . . . . . . 73 5.6.2. Framing Header . . . . . . . . . . . . . . . . . . . 74
5.6.3. Simple Reliability . . . . . . . . . . . . . . . . . 74 5.6.3. Simple Reliability . . . . . . . . . . . . . . . . . 75
5.6.3.1. Retransmission and Flow Control . . . . . . . . . 75 5.6.3.1. Retransmission and Flow Control . . . . . . . . . 76
5.6.4. DTLS/UDP with SR . . . . . . . . . . . . . . . . . . 76 5.6.4. DTLS/UDP with SR . . . . . . . . . . . . . . . . . . 77
5.6.5. TLS/TCP with FH, no ICE . . . . . . . . . . . . . . 76 5.6.5. TLS/TCP with FH, no ICE . . . . . . . . . . . . . . 77
5.6.6. DTLS/UDP with SR, no ICE . . . . . . . . . . . . . . 77 5.6.6. DTLS/UDP with SR, no ICE . . . . . . . . . . . . . . 78
5.7. Fragmentation and Reassembly . . . . . . . . . . . . . . 77 5.7. Fragmentation and Reassembly . . . . . . . . . . . . . . 78
6. Data Storage Protocol . . . . . . . . . . . . . . . . . . . . 78 6. Data Storage Protocol . . . . . . . . . . . . . . . . . . . . 79
6.1. Data Signature Computation . . . . . . . . . . . . . . . 79 6.1. Data Signature Computation . . . . . . . . . . . . . . . 80
6.2. Data Models . . . . . . . . . . . . . . . . . . . . . . 80 6.2. Data Models . . . . . . . . . . . . . . . . . . . . . . 81
6.2.1. Single Value . . . . . . . . . . . . . . . . . . . . 81 6.2.1. Single Value . . . . . . . . . . . . . . . . . . . . 82
6.2.2. Array . . . . . . . . . . . . . . . . . . . . . . . 82 6.2.2. Array . . . . . . . . . . . . . . . . . . . . . . . 83
6.2.3. Dictionary . . . . . . . . . . . . . . . . . . . . . 82 6.2.3. Dictionary . . . . . . . . . . . . . . . . . . . . . 83
6.3. Access Control Policies . . . . . . . . . . . . . . . . 83 6.3. Access Control Policies . . . . . . . . . . . . . . . . 84
6.3.1. USER-MATCH . . . . . . . . . . . . . . . . . . . . . 83 6.3.1. USER-MATCH . . . . . . . . . . . . . . . . . . . . . 84
6.3.2. NODE-MATCH . . . . . . . . . . . . . . . . . . . . . 83 6.3.2. NODE-MATCH . . . . . . . . . . . . . . . . . . . . . 84
6.3.3. USER-NODE-MATCH . . . . . . . . . . . . . . . . . . 83 6.3.3. USER-NODE-MATCH . . . . . . . . . . . . . . . . . . 84
6.3.4. NODE-MULTIPLE . . . . . . . . . . . . . . . . . . . 83 6.3.4. NODE-MULTIPLE . . . . . . . . . . . . . . . . . . . 84
6.4. Data Storage Methods . . . . . . . . . . . . . . . . . . 84 6.4. Data Storage Methods . . . . . . . . . . . . . . . . . . 85
6.4.1. Store . . . . . . . . . . . . . . . . . . . . . . . 84 6.4.1. Store . . . . . . . . . . . . . . . . . . . . . . . 85
6.4.1.1. Request Definition . . . . . . . . . . . . . . . 84 6.4.1.1. Request Definition . . . . . . . . . . . . . . . 85
6.4.1.2. Response Definition . . . . . . . . . . . . . . . 88 6.4.1.2. Response Definition . . . . . . . . . . . . . . . 89
6.4.1.3. Removing Values . . . . . . . . . . . . . . . . . 89 6.4.1.3. Removing Values . . . . . . . . . . . . . . . . . 90
6.4.2. Fetch . . . . . . . . . . . . . . . . . . . . . . . 90 6.4.2. Fetch . . . . . . . . . . . . . . . . . . . . . . . 91
6.4.2.1. Request Definition . . . . . . . . . . . . . . . 91 6.4.2.1. Request Definition . . . . . . . . . . . . . . . 92
6.4.2.2. Response Definition . . . . . . . . . . . . . . . 93 6.4.2.2. Response Definition . . . . . . . . . . . . . . . 94
6.4.3. Stat . . . . . . . . . . . . . . . . . . . . . . . . 93 6.4.3. Stat . . . . . . . . . . . . . . . . . . . . . . . . 94
6.4.3.1. Request Definition . . . . . . . . . . . . . . . 94 6.4.3.1. Request Definition . . . . . . . . . . . . . . . 95
6.4.3.2. Response Definition . . . . . . . . . . . . . . . 94 6.4.3.2. Response Definition . . . . . . . . . . . . . . . 95
6.4.4. Find . . . . . . . . . . . . . . . . . . . . . . . . 96 6.4.4. Find . . . . . . . . . . . . . . . . . . . . . . . . 97
6.4.4.1. Request Definition . . . . . . . . . . . . . . . 96 6.4.4.1. Request Definition . . . . . . . . . . . . . . . 97
6.4.4.2. Response Definition . . . . . . . . . . . . . . . 96 6.4.4.2. Response Definition . . . . . . . . . . . . . . . 97
6.4.5. Defining New Kinds . . . . . . . . . . . . . . . . . 97 6.4.5. Defining New Kinds . . . . . . . . . . . . . . . . . 98
7. Certificate Store Usage . . . . . . . . . . . . . . . . . . . 98 7. Certificate Store Usage . . . . . . . . . . . . . . . . . . . 99
8. TURN Server Usage . . . . . . . . . . . . . . . . . . . . . . 99 8. TURN Server Usage . . . . . . . . . . . . . . . . . . . . . . 100
9. Chord Algorithm . . . . . . . . . . . . . . . . . . . . . . . 100 9. Chord Algorithm . . . . . . . . . . . . . . . . . . . . . . . 101
9.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 101 9.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 102
9.2. Routing . . . . . . . . . . . . . . . . . . . . . . . . 102 9.2. Routing . . . . . . . . . . . . . . . . . . . . . . . . 103
9.3. Redundancy . . . . . . . . . . . . . . . . . . . . . . . 102 9.3. Redundancy . . . . . . . . . . . . . . . . . . . . . . . 103
9.4. Joining . . . . . . . . . . . . . . . . . . . . . . . . 103 9.4. Joining . . . . . . . . . . . . . . . . . . . . . . . . 104
9.5. Routing Attaches . . . . . . . . . . . . . . . . . . . . 103 9.5. Routing Attaches . . . . . . . . . . . . . . . . . . . . 104
9.6. Updates . . . . . . . . . . . . . . . . . . . . . . . . 104 9.6. Updates . . . . . . . . . . . . . . . . . . . . . . . . 105
9.6.1. Handling Neighbor Failures . . . . . . . . . . . . . 105 9.6.1. Handling Neighbor Failures . . . . . . . . . . . . . 106
9.6.2. Handling Finger Table Entry Failure . . . . . . . . 106 9.6.2. Handling Finger Table Entry Failure . . . . . . . . 107
9.6.3. Receiving Updates . . . . . . . . . . . . . . . . . 106 9.6.3. Receiving Updates . . . . . . . . . . . . . . . . . 107
9.6.4. Stabilization . . . . . . . . . . . . . . . . . . . 107 9.6.4. Stabilization . . . . . . . . . . . . . . . . . . . 108
9.6.4.1. Updating neighbor table . . . . . . . . . . . . . 107 9.6.4.1. Updating neighbor table . . . . . . . . . . . . . 108
9.6.4.2. Refreshing finger table . . . . . . . . . . . . . 107 9.6.4.2. Refreshing finger table . . . . . . . . . . . . . 108
9.6.4.3. Adjusting finger table size . . . . . . . . . . . 108 9.6.4.3. Adjusting finger table size . . . . . . . . . . . 109
9.6.4.4. Detecting partitioning . . . . . . . . . . . . . 109 9.6.4.4. Detecting partitioning . . . . . . . . . . . . . 110
9.7. Route Query . . . . . . . . . . . . . . . . . . . . . . 109 9.7. Route Query . . . . . . . . . . . . . . . . . . . . . . 110
9.8. Leaving . . . . . . . . . . . . . . . . . . . . . . . . 110 9.8. Leaving . . . . . . . . . . . . . . . . . . . . . . . . 111
10. Enrollment and Bootstrap . . . . . . . . . . . . . . . . . . 111 10. Enrollment and Bootstrap . . . . . . . . . . . . . . . . . . 112
10.1. Overlay Configuration . . . . . . . . . . . . . . . . . 111 10.1. Overlay Configuration . . . . . . . . . . . . . . . . . 112
10.1.1. Relax NG Grammar . . . . . . . . . . . . . . . . . . 116 10.1.1. Relax NG Grammar . . . . . . . . . . . . . . . . . . 117
10.2. Discovery Through Enrollment Server . . . . . . . . . . 118 10.2. Discovery Through Enrollment Server . . . . . . . . . . 119
10.3. Credentials . . . . . . . . . . . . . . . . . . . . . . 118 10.3. Credentials . . . . . . . . . . . . . . . . . . . . . . 119
10.3.1. Self-Generated Credentials . . . . . . . . . . . . . 119 10.3.1. Self-Generated Credentials . . . . . . . . . . . . . 120
10.4. Searching for a Bootstrap Node . . . . . . . . . . . . . 120 10.4. Searching for a Bootstrap Node . . . . . . . . . . . . . 121
10.5. Contacting a Bootstrap Node . . . . . . . . . . . . . . 120 10.5. Contacting a Bootstrap Node . . . . . . . . . . . . . . 121
11. Message Flow Example . . . . . . . . . . . . . . . . . . . . 121 11. Message Flow Example . . . . . . . . . . . . . . . . . . . . 122
12. Security Considerations . . . . . . . . . . . . . . . . . . . 127 12. Security Considerations . . . . . . . . . . . . . . . . . . . 128
12.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 127 12.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 128
12.2. Attacks on P2P Overlays . . . . . . . . . . . . . . . . 128 12.2. Attacks on P2P Overlays . . . . . . . . . . . . . . . . 129
12.3. Certificate-based Security . . . . . . . . . . . . . . . 128 12.3. Certificate-based Security . . . . . . . . . . . . . . . 129
12.4. Shared-Secret Security . . . . . . . . . . . . . . . . . 129 12.4. Shared-Secret Security . . . . . . . . . . . . . . . . . 130
12.5. Storage Security . . . . . . . . . . . . . . . . . . . . 130 12.5. Storage Security . . . . . . . . . . . . . . . . . . . . 131
12.5.1. Authorization . . . . . . . . . . . . . . . . . . . 130 12.5.1. Authorization . . . . . . . . . . . . . . . . . . . 131
12.5.2. Distributed Quota . . . . . . . . . . . . . . . . . 131 12.5.2. Distributed Quota . . . . . . . . . . . . . . . . . 132
12.5.3. Correctness . . . . . . . . . . . . . . . . . . . . 131 12.5.3. Correctness . . . . . . . . . . . . . . . . . . . . 132
12.5.4. Residual Attacks . . . . . . . . . . . . . . . . . . 131 12.5.4. Residual Attacks . . . . . . . . . . . . . . . . . . 132
12.6. Routing Security . . . . . . . . . . . . . . . . . . . . 132 12.6. Routing Security . . . . . . . . . . . . . . . . . . . . 133
12.6.1. Background . . . . . . . . . . . . . . . . . . . . . 132 12.6.1. Background . . . . . . . . . . . . . . . . . . . . . 133
12.6.2. Admissions Control . . . . . . . . . . . . . . . . . 133 12.6.2. Admissions Control . . . . . . . . . . . . . . . . . 134
12.6.3. Peer Identification and Authentication . . . . . . . 133 12.6.3. Peer Identification and Authentication . . . . . . . 134
12.6.4. Protecting the Signaling . . . . . . . . . . . . . . 134 12.6.4. Protecting the Signaling . . . . . . . . . . . . . . 135
12.6.5. Residual Attacks . . . . . . . . . . . . . . . . . . 134 12.6.5. Residual Attacks . . . . . . . . . . . . . . . . . . 135
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 135 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 136
13.1. Port Registrations . . . . . . . . . . . . . . . . . . . 135 13.1. Port Registrations . . . . . . . . . . . . . . . . . . . 136
13.2. Overlay Algorithm Types . . . . . . . . . . . . . . . . 135 13.2. Overlay Algorithm Types . . . . . . . . . . . . . . . . 136
13.3. Access Control Policies . . . . . . . . . . . . . . . . 135 13.3. Access Control Policies . . . . . . . . . . . . . . . . 136
13.4. Application-ID . . . . . . . . . . . . . . . . . . . . . 136 13.4. Application-ID . . . . . . . . . . . . . . . . . . . . . 137
13.5. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . 136 13.5. Data Kind-ID . . . . . . . . . . . . . . . . . . . . . . 137
13.6. Data Model . . . . . . . . . . . . . . . . . . . . . . . 137 13.6. Data Model . . . . . . . . . . . . . . . . . . . . . . . 138
13.7. Message Codes . . . . . . . . . . . . . . . . . . . . . 137 13.7. Message Codes . . . . . . . . . . . . . . . . . . . . . 138
13.8. Error Codes . . . . . . . . . . . . . . . . . . . . . . 138 13.8. Error Codes . . . . . . . . . . . . . . . . . . . . . . 139
13.9. Overlay Link Types . . . . . . . . . . . . . . . . . . . 139 13.9. Overlay Link Types . . . . . . . . . . . . . . . . . . . 140
13.10. Forwarding Options . . . . . . . . . . . . . . . . . . . 139 13.10. Forwarding Options . . . . . . . . . . . . . . . . . . . 140
13.11. Probe Information Types . . . . . . . . . . . . . . . . 140 13.11. Probe Information Types . . . . . . . . . . . . . . . . 141
13.12. Message Extensions . . . . . . . . . . . . . . . . . . . 140 13.12. Message Extensions . . . . . . . . . . . . . . . . . . . 141
13.13. reload URI Scheme . . . . . . . . . . . . . . . . . . . 140 13.13. reload URI Scheme . . . . . . . . . . . . . . . . . . . 141
13.13.1. URI Registration . . . . . . . . . . . . . . . . . . 141 13.13.1. URI Registration . . . . . . . . . . . . . . . . . . 142
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 141 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 142
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 142 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 143
15.1. Normative References . . . . . . . . . . . . . . . . . . 142 15.1. Normative References . . . . . . . . . . . . . . . . . . 143
15.2. Informative References . . . . . . . . . . . . . . . . . 143 15.2. Informative References . . . . . . . . . . . . . . . . . 144
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 146 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 147
A.1. Changes since draft-ietf-p2psip-reload-04 . . . . . . . 146 A.1. Changes since draft-ietf-p2psip-reload-04 . . . . . . . 147
A.2. Changes since draft-ietf-p2psip-reload-01 . . . . . . . 146 A.2. Changes since draft-ietf-p2psip-reload-01 . . . . . . . 147
A.3. Changes since draft-ietf-p2psip-reload-00 . . . . . . . 147 A.3. Changes since draft-ietf-p2psip-reload-00 . . . . . . . 148
A.4. Changes since draft-ietf-p2psip-base-00 . . . . . . . . 147 A.4. Changes since draft-ietf-p2psip-base-00 . . . . . . . . 148
A.5. Changes since draft-ietf-p2psip-base-01 . . . . . . . . 147 A.5. Changes since draft-ietf-p2psip-base-01 . . . . . . . . 148
A.6. Changes since draft-ietf-p2psip-base-01a . . . . . . . . 147 A.6. Changes since draft-ietf-p2psip-base-01a . . . . . . . . 148
A.7. Changes since draft-ietf-p2psip-base-02 . . . . . . . . 148 A.7. Changes since draft-ietf-p2psip-base-02 . . . . . . . . 149
Appendix B. Routing Alternatives . . . . . . . . . . . . . . . . 148 Appendix B. Routing Alternatives . . . . . . . . . . . . . . . . 149
B.1. Iterative vs Recursive . . . . . . . . . . . . . . . . . 148 B.1. Iterative vs Recursive . . . . . . . . . . . . . . . . . 149
B.2. Symmetric vs Forward response . . . . . . . . . . . . . 148 B.2. Symmetric vs Forward response . . . . . . . . . . . . . 149
B.3. Direct Response . . . . . . . . . . . . . . . . . . . . 149 B.3. Direct Response . . . . . . . . . . . . . . . . . . . . 150
B.4. Relay Peers . . . . . . . . . . . . . . . . . . . . . . 150 B.4. Relay Peers . . . . . . . . . . . . . . . . . . . . . . 151
B.5. Symmetric Route Stability . . . . . . . . . . . . . . . 151 B.5. Symmetric Route Stability . . . . . . . . . . . . . . . 152
Appendix C. Why Clients? . . . . . . . . . . . . . . . . . . . . 151 Appendix C. Why Clients? . . . . . . . . . . . . . . . . . . . . 152
C.1. Why Not Only Peers? . . . . . . . . . . . . . . . . . . 151 C.1. Why Not Only Peers? . . . . . . . . . . . . . . . . . . 152
C.2. Clients as Application-Level Agents . . . . . . . . . . 152 C.2. Clients as Application-Level Agents . . . . . . . . . . 153
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 152 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 153
1. Introduction 1. Introduction
This document defines REsource LOcation And Discovery (RELOAD), a This document defines REsource LOcation And Discovery (RELOAD), a
peer-to-peer (P2P) signaling protocol for use on the Internet. It peer-to-peer (P2P) signaling protocol for use on the Internet. It
provides a generic, self-organizing overlay network service, allowing provides a generic, self-organizing overlay network service, allowing
nodes to efficiently route messages to other nodes and to efficiently nodes to efficiently route messages to other nodes and to efficiently
store and retrieve data in the overlay. RELOAD provides several store and retrieve data in the overlay. RELOAD provides several
features that are critical for a successful P2P protocol for the features that are critical for a successful P2P protocol for the
Internet: Internet:
skipping to change at page 9, line 19 skipping to change at page 9, line 19
is described separately in [I-D.ietf-p2psip-sip]. RELOAD is not is described separately in [I-D.ietf-p2psip-sip]. RELOAD is not
limited to usage by SIP and could serve as a tool for supporting limited to usage by SIP and could serve as a tool for supporting
other P2P applications with similar needs. RELOAD is also based on other P2P applications with similar needs. RELOAD is also based on
the concepts introduced in [I-D.ietf-p2psip-concepts]. the concepts introduced in [I-D.ietf-p2psip-concepts].
1.1. Basic Setting 1.1. Basic Setting
In this section, we provide a brief overview of the operational In this section, we provide a brief overview of the operational
setting for RELOAD. See the concepts document for more details. A setting for RELOAD. See the concepts document for more details. A
RELOAD Overlay Instance consists of a set of nodes arranged in a RELOAD Overlay Instance consists of a set of nodes arranged in a
partly connected graph. Each node in the overlay is assigned a connected graph. Each node in the overlay is assigned a numeric
numeric Node-ID which, together with the specific overlay algorithm Node-ID which, together with the specific overlay algorithm in use,
in use, determines its position in the graph and the set of nodes it determines its position in the graph and the set of nodes it connects
connects to. The figure below shows a trivial example which isn't to. The figure below shows a trivial example which isn't drawn from
drawn from any particular overlay algorithm, but was chosen for any particular overlay algorithm, but was chosen for convenience of
convenience of representation. representation.
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| Node 10|--------------| Node 20|--------------| Node 30| | Node 10|--------------| Node 20|--------------| Node 30|
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| | | | | |
| | | | | |
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| Node 40|--------------| Node 50|--------------| Node 60| | Node 40|--------------| Node 50|--------------| Node 60|
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| | | | | |
skipping to change at page 13, line 7 skipping to change at page 13, line 7
layer" protocols used by RELOAD for hop-by-hop communication. layer" protocols used by RELOAD for hop-by-hop communication.
Each such protocol includes the appropriate provisions for per-hop Each such protocol includes the appropriate provisions for per-hop
framing or hop-by-hop ACKs required by unreliable transports. framing or hop-by-hop ACKs required by unreliable transports.
To further clarify the roles of the various layers, this figure To further clarify the roles of the various layers, this figure
parallels the architecture with each layer's role from an overlay parallels the architecture with each layer's role from an overlay
perspective and implementation layer in the internet: perspective and implementation layer in the internet:
| Internet Model | | Internet Model |
Real | Equivalent | Reload Real | Equivalent | Reload
Internet | in Overlay | Architecture Internet | in Overlay | Architecture
--------------+-----------------+------------------------------------ -------------+-----------------+------------------------------------
| | +-------+ +-------+ | | +-------+ +-------+
| Application | | SIP | | XMPP | ... | Application | | SIP | | XMPP | ...
| | | Usage | | Usage | | | | Usage | | Usage |
| | +-------+ +-------+ | | +-------+ +-------+
| | ---------------------------------- | | ----------------------------------
| |+------------------+ +---------+ | |+------------------+ +---------+
| Transport || Message |<--->| Storage | | Transport || Message |<--->| Storage |
| || Transport | +---------+ | || Transport | +---------+
| |+------------------+ ^ | |+------------------+ ^
| | ^ ^ | | | ^ ^ |
| | | v v | | | v v
Application | | | +-------------------+ Application | | | +-------------------+
| (Routing) | | | Topology | | (Routing) | | | Topology |
| | | | Plugin | | | | | Plugin |
| | | +-------------------+ | | | +-------------------+
| | | ^ | | | ^
| | v v | | v v
| Network | +------------------+ | Network | +------------------+
| | | Forwarding & | | | | Forwarding & |
| | | Link Management | | | | Link Management |
| | +------------------+ | | +------------------+
| | ---------------------------------- | | ----------------------------------
Transport | Link | +-------+ +------+ Transport | Link | +-------+ +------+
| | |TLS | |DTLS | ... | | |TLS | |DTLS | ...
| | +-------+ +------+ | | +-------+ +------+
--------------+-----------------+------------------------------------ -------------+-----------------+------------------------------------
Network | Network |
| |
Link | Link |
1.2.1. Usage Layer 1.2.1. Usage Layer
The top layer, called the Usage Layer, has application usages, such The top layer, called the Usage Layer, has application usages, such
as the SIP Location Usage, that use the abstract Message Transport as the SIP Location Usage, that use the abstract Message Transport
API provided by RELOAD. The goal of this layer is to implement API provided by RELOAD. The goal of this layer is to implement
application-specific usages of the generic overlay services provided application-specific usages of the generic overlay services provided
skipping to change at page 15, line 48 skipping to change at page 15, line 48
Topology Plugin instructs the Storage component to issue resource Topology Plugin instructs the Storage component to issue resource
migration requests as appropriate, in order to ensure that other migration requests as appropriate, in order to ensure that other
peers have whatever resources they are now responsible for. The peers have whatever resources they are now responsible for. The
Topology Plugin is also responsible for providing for redundant data Topology Plugin is also responsible for providing for redundant data
storage to protect against loss of information in the event of a peer storage to protect against loss of information in the event of a peer
failure and to protect against compromised or subversive peers. failure and to protect against compromised or subversive peers.
1.2.5. Forwarding and Link Management Layer 1.2.5. Forwarding and Link Management Layer
The Forwarding and Link Management Layer is responsible for getting a The Forwarding and Link Management Layer is responsible for getting a
packet to the next peer, as determined by the Topology Plugin. This message to the next peer, as determined by the Topology Plugin. This
Layer establishes and maintains the network connections as required Layer establishes and maintains the network connections as required
by the Topology Plugin. This layer is also responsible for setting by the Topology Plugin. This layer is also responsible for setting
up connections to other peers through NATs and firewalls using ICE, up connections to other peers through NATs and firewalls using ICE,
and it can elect to forward traffic using relays for NAT and firewall and it can elect to forward traffic using relays for NAT and firewall
traversal. traversal.
This layer provides a fairly generic interface that allows the This layer provides a generic interface that allows the topology
topology plugin to control the overlay and resource operations and plugin to control the overlay and resource operations and messages.
messages. Since each overlay algorithm is defined and functions Since each overlay algorithm is defined and functions differently, we
differently, we generically refer to the table of other peers that generically refer to the table of other peers that the overlay
the overlay algorithm maintains and uses to route requests algorithm maintains and uses to route requests (neighbors) as a
(neighbors) as a Routing Table. The Topology Plugin actually owns Routing Table. The Topology Plugin actually owns the Routing Table,
the Routing Table, and forwarding decisions are made by querying the and forwarding decisions are made by querying the Topology Plugin for
Topology Plugin for the next hop for a particular Node-ID or the next hop for a particular Node-ID or Resource-ID. If this node
Resource-ID. If this node is the destination of the message, the is the destination of the message, the message is delivered to the
message is delivered to the Message Transport. Message Transport.
This layer may also utilize a framing header to encapsulate messages 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 as they are forwarding along each hop. Such a header may be used to
aid reliability, congestion control, flow control, etc. Any such aid reliability, congestion control, flow control, etc. Any such
header has meaning only in the context of that individual link. 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.
skipping to change at page 25, line 44 skipping to change at page 25, line 44
Iterative routing is implemented using the Route_Query method, which Iterative routing is implemented using the Route_Query method, which
requests this behavior. Note that iterative routing is selected only requests this behavior. Note that iterative routing is selected only
by the initiating node. by the initiating node.
3.4. Connectivity Management 3.4. Connectivity Management
In order to provide efficient routing, a peer needs to maintain a set In order to provide efficient routing, a peer needs to maintain a set
of direct connections to other peers in the Overlay Instance. Due to of direct connections to other peers in the Overlay Instance. Due to
the presence of NATs, these connections often cannot be formed the presence of NATs, these connections often cannot be formed
directly. Instead, we use the Attach request to establish a directly. Instead, we use the Attach request to establish a
connection. Attach uses ICE [I-D.ietf-mmusic-ice] to establish the connection. Attach uses ICE [RFC5245] to establish the connection.
connection. It is assumed that the reader is familiar with ICE. It is assumed that the reader is familiar with ICE.
Say that peer A wishes to form a direct connection to peer B. It Say that peer A wishes to form a direct connection to peer B. It
gathers ICE candidates and packages them up in an Attach request gathers ICE candidates and packages them up in an Attach request
which it sends to B through usual overlay routing procedures. B does which it sends to B through usual overlay routing procedures. B does
its own candidate gathering and sends back a response with its its own candidate gathering and sends back a response with its
candidates. A and B then do ICE connectivity checks on the candidate candidates. A and B then do ICE connectivity checks on the candidate
pairs. The result is a connection between A and B. At this point, A pairs. The result is a connection between A and B. At this point, A
and B can add each other to their routing tables and send messages and B can add each other to their routing tables and send messages
directly between themselves without going through other overlay directly between themselves without going through other overlay
peers. peers.
skipping to change at page 29, line 15 skipping to change at page 29, line 15
4. Application Support Overview 4. Application Support Overview
RELOAD is not intended to be used alone, but rather as a substrate RELOAD is not intended to be used alone, but rather as a substrate
for other applications. These applications can use RELOAD for a for other applications. These applications can use RELOAD for a
variety of purposes: variety of purposes:
o To store data in the overlay and retrieve data stored by other o To store data in the overlay and retrieve data stored by other
nodes. nodes.
o As a discovery mechanism for services such as TURN. o As a discovery mechanism for services such as TURN.
o To form direct connections which can be used to transmit o To form direct connections which can be used to transmit
application-level messages. application-level messages without using the overlay.
This section provides an overview of these services. This section provides an overview of these services.
4.1. Data Storage 4.1. Data Storage
RELOAD provides operations to Store and Fetch data. Each location in RELOAD provides operations to Store and Fetch data. Each location in
the Overlay Instance is referenced by a Resource-ID. However, each the Overlay Instance is referenced by a Resource-ID. However, each
location may contain data elements corresponding to multiple kinds location may contain data elements corresponding to multiple kinds
(e.g., certificate, SIP registration). Similarly, there may be (e.g., certificate, SIP registration). Similarly, there may be
multiple elements of a given kind, as shown below: multiple elements of a given kind, as shown below:
skipping to change at page 34, line 12 skipping to change at page 34, line 12
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 equals this node's Node-ID, then o If the entry is a Node-ID which equals this node's Node-ID, then
the message is destined for this node. If this is the only entry the message is destined for this node. If this is the only entry
on the destination list, the message is destined for this node and on the destination list, the message is destined for this node and
is passed up to the upper layers. Otherwise the entry is removed is passed up to the upper layers. Otherwise the entry is removed
from the destination list and the message is passed to the Message from the destination list and the message is passed to the Message
Transport. If the message is a response and there is state for Transport. If the message is a response and there is state for
the transaction ID, the state is reinserted into the destination the transaction ID, the state is reinserted into the destination
list first. list before the message is further processed.
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.
skipping to change at page 38, line 48 skipping to change at page 38, line 48
A boolean value is either a 1 or a 0 and is represented as a single A boolean value is either a 1 or a 0 and is represented as a single
byte on the wire. byte on the wire.
The NodeId, shown below, represents a single Node-ID. The NodeId, shown below, represents a single Node-ID.
typedef opaque NodeId[16]; typedef opaque NodeId[16];
A NodeId is a fixed-length 128-bit structure represented as a series A NodeId is a fixed-length 128-bit structure represented as a series
of bytes, with the most significant byte first. Note: the use of of bytes, with the most significant byte first. Note: the use of
"typedef" here is an extension to the TLS language, but its meaning "typedef" here is an extension to the TLS language, but its meaning
should be relatively obvious. should be relatively obvious. Note the [ size ] syntax defines a
fixed length element that does not include the length of the element
in the on the wire encoding.
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. Note the < range > syntax
defines a variable length element that does include the length of the
element in the on the wire encoding. The number of bytes to encode
the length on the wire is derived by range.
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 41, line 4 skipping to change at page 41, line 21
uint32 fragment; uint32 fragment;
uint32 length; uint32 length;
uint64 transaction_id; uint64 transaction_id;
uint32 max_response_length; uint32 max_response_length;
uint16 via_list_length; uint16 via_list_length;
uint16 destination_list_length; uint16 destination_list_length;
uint16 options_length; uint16 options_length;
Destination via_list[via_list_length]; Destination via_list[via_list_length];
Destination destination_list Destination destination_list
[destination_list_length]; [destination_list_length];
ForwardingOptions options[options_length]; ForwardingOptions options[options_length];
} ForwardingHeader; } ForwardingHeader;
The contents of the structure are: The contents of the structure are:
relo_token: The first four bytes identify this message as a RELOAD relo_token: The first four bytes identify this message as a RELOAD
message. The message is easy to demultiplex from STUN messages by message. The message is easy to demultiplex from STUN messages by
looking at the first bit. This field MUST contain the value looking at the first bit. This field MUST contain the value
0xc2454c4f (the string 'RELO' with the high bit of the first byte 0xd2454c4f (the string 'RELO' with the high bit of the first byte
set.). set.).
overlay: The 32 bit checksum/hash of the overlay being used. The overlay: The 32 bit checksum/hash of the overlay being used. The
variable length string representing the overlay name is hashed variable length string representing the overlay name is hashed
with SHA-1 and the low order 32 bits are used. The purpose of with SHA-1 and the low order 32 bits are used. The purpose of
this field is to allow nodes to participate in multiple overlays this field is to allow nodes to participate in multiple overlays
and to detect accidental misconfiguration. This is not a security and to detect accidental misconfiguration. This is not a security
critical function. critical function.
configuration_sequence: The sequence number of the configuration configuration_sequence: The sequence number of the configuration
skipping to change at page 44, line 14 skipping to change at page 44, line 42
If destination structure has its first bit set to 1, then it is a 16 If destination structure has its first bit set to 1, then it is a 16
bit integer. If the first bit is not set, then it is a structure bit integer. If the first bit is not set, then it is a structure
starting with DestinationType. If it is a 16 bit integer, it is starting with DestinationType. If it is a 16 bit integer, it is
treated as if it were a full structure with a DestinationType of treated as if it were a full structure with a DestinationType of
compressed and a compressed_id that was 2 bytes long with the value compressed and a compressed_id that was 2 bytes long with the value
of the 16 bit integer. When the destination structure is not a 16 of the 16 bit integer. When the destination structure is not a 16
bit integer, it is the TLV structure with the following contents: bit integer, it is the TLV structure with the following contents:
type type
The type of the DestinationData PDU. This may be one of "peer", The type of the DestinationData Payload Data Unit (PDU). This may
"resource", or "compressed". be one of "node", "resource", or "compressed".
length length
The length of the destination_data. The length of the destination_data.
destination_value destination_value
The destination value itself, which is an encoded DestinationData The destination value itself, which is an encoded DestinationData
structure, depending on the value of "type". structure, depending on the value of "type".
Note: This structure encodes a type, length, value. The length Note: This structure encodes a type, length, value. The length
field specifies the length of the DestinationData values, which field specifies the length of the DestinationData values, which
allows the addition of new DestinationTypes. This allows an allows the addition of new DestinationTypes. This allows an
implementation which does not understand a given DestinationType implementation which does not understand a given DestinationType
to skip over it. to skip over it.
A DestinationData can be one of three types: A DestinationData can be one of three types:
peer node
A Node-ID. A Node-ID.
compressed compressed
A compressed list of Node-IDs and/or resources. Because this A compressed list of Node-IDs and/or resources. Because this
value was compressed by one of the peers, it is only meaningful to value was compressed by one of the peers, it is only meaningful to
that peer and cannot be decoded by other peers. Thus, it is that peer and cannot be decoded by other peers. Thus, it is
represented as an opaque string. represented as an opaque string.
resource resource
The Resource-ID of the resource which is desired. This type MUST The Resource-ID of the resource which is desired. This type MUST
skipping to change at page 45, line 27 skipping to change at page 46, line 15
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 { directResponseForwarding(1), (255) } ForwardingOptionsType; enum { directResponseForwarding(1), (255) } ForwardingOptionsType;
struct {
ForwardingOptionsType type;
uint8 flags;
uint16 length;
select (type) {
case directResponseForwarding:
DirectResponseForwardingOption directResponseForwardingOption;
/* This type may be extended */ struct {
} option; ForwardingOptionsType type;
} ForwardingOption; uint8 flags;
uint16 length;
select (type) {
case directResponseForwarding:
DirectResponseForwardingOption directResponseForwardingOption;
/* 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 60, line 24 skipping to change at page 61, line 19
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;
OverlayLink 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;
} }
IceExtension extensions<0..2^16-1>; IceExtension extensions<0..2^16-1>;
} IceCandidate; } IceCandidate;
struct { struct {
opaque ufrag<0..2^8-1>; opaque ufrag<0..2^8-1>;
opaque password<0..2^8-1>; opaque password<0..2^8-1>;
opaque role<0..2^8-1>; opaque role<0..2^8-1>;
IceCandidate candidates<0..2^16-1>; IceCandidate candidates<0..2^16-1>;
} AttachReqAns; } AttachReqAns;
The values contained in AttachReqAns are: The values contained in AttachReqAns are:
ufrag ufrag
The username fragment (from ICE). The username fragment (from ICE).
password password
The ICE password. The ICE password.
skipping to change at page 62, line 29 skipping to change at page 63, line 24
If a peer receives an Attach request, it SHOULD process the request If a peer receives an Attach request, it SHOULD process the request
and generate its own response with a AttachReqAns. It should then and generate its own response with a AttachReqAns. It should then
begin ICE checks. When a peer receives an Attach response, it SHOULD begin ICE checks. When a peer receives an Attach response, it SHOULD
parse the response and begin its own ICE checks. parse the response and begin its own ICE checks.
5.5.1.3. Using ICE With RELOAD 5.5.1.3. Using ICE With RELOAD
This section describes the profile of ICE that is used with RELOAD. This section describes the profile of ICE that is used with RELOAD.
RELOAD implementations MUST implement full ICE. RELOAD implementations MUST implement full ICE.
In ICE as defined by [I-D.ietf-mmusic-ice], SDP is used to carry the In ICE as defined by [RFC5245], SDP is used to carry the ICE
ICE parameters. In RELOAD, this function is performed by a binary parameters. In RELOAD, this function is performed by a binary
encoding in the Attach method. This encoding is more restricted than encoding in the Attach method. This encoding is more restricted than
the SDP encoding because the RELOAD environment is simpler: the SDP encoding because the RELOAD environment is simpler:
o Only a single media stream is supported. o Only a single media stream is supported.
o In this case, the "stream" refers not to RTP or other types of o In this case, the "stream" refers not to RTP or other types of
media, but rather to a connection for RELOAD itself or for SIP media, but rather to a connection for RELOAD itself or for SIP
signaling. signaling.
o RELOAD only allows for a single offer/answer exchange. Unlike the o RELOAD only allows for a single offer/answer exchange. Unlike the
usage of ICE within SIP, there is never a need to send a usage of ICE within SIP, there is never a need to send a
subsequent offer to update the default candidates to match the subsequent offer to update the default candidates to match the
ones selected by ICE. ones selected by ICE.
An agent follows the ICE specification as described in An agent follows the ICE specification as described in [RFC5245] with
[I-D.ietf-mmusic-ice] with the changes and additional procedures the changes and additional procedures described in the subsections
described in the subsections below. below.
5.5.1.4. Collecting STUN Servers 5.5.1.4. Collecting STUN Servers
ICE relies on the node having one or more STUN servers to use. In ICE relies on the node having one or more STUN servers to use. In
conventional ICE, it is assumed that nodes are configured with one or conventional ICE, it is assumed that nodes are configured with one or
more STUN servers through some out-of-band mechanism. This is still more STUN servers through some out-of-band mechanism. This is still
possible in RELOAD but RELOAD also learns STUN servers as it connects possible in RELOAD but RELOAD also learns STUN servers as it connects
to other peers. Because all RELOAD peers implement ICE and use STUN to other peers. Because all RELOAD peers implement ICE and use STUN
keepalives, every peer is a STUN server [RFC5389]. Accordingly, any keepalives, every peer is a STUN server [RFC5389]. Accordingly, any
peer a node knows will be willing to be a STUN server -- though of peer a node knows will be willing to be a STUN server -- though of
skipping to change at page 63, line 36 skipping to change at page 64, line 31
Only peers to which the peer currently has connections may be used. Only peers to which the peer currently has connections may be used.
If the connection to that host is lost, it MUST be removed from the If the connection to that host is lost, it MUST be removed from the
list of stun servers and a new server from the same group SHOULD be list of stun servers and a new server from the same group SHOULD be
selected. selected.
5.5.1.5. Gathering Candidates 5.5.1.5. Gathering Candidates
When a node wishes to establish a connection for the purposes of When a node wishes to establish a connection for the purposes of
RELOAD signaling or application signaling, it follows the process of RELOAD signaling or application signaling, it follows the process of
gathering candidates as described in Section 4 of ICE gathering candidates as described in Section 4 of ICE [RFC5245].
[I-D.ietf-mmusic-ice]. RELOAD utilizes a single component. RELOAD utilizes a single component. Consequently, gathering for
Consequently, gathering for these "streams" requires a single these "streams" requires a single component. In the case where a
component. In the case where a node has not yet found a TURN server, node has not yet found a TURN server, the agent would not include a
the agent would not include a relayed candidate. relayed candidate.
The ICE specification assumes that an ICE agent is configured with, The ICE specification assumes that an ICE agent is configured with,
or somehow knows of, TURN and STUN servers. RELOAD provides a way or somehow knows of, TURN and STUN servers. RELOAD provides a way
for an agent to learn these by querying the overlay, as described in for an agent to learn these by querying the overlay, as described in
Section 5.5.1.4 and Section 8. Section 5.5.1.4 and Section 8.
The default candidate selection described in Section 4.1.4 of ICE is The default candidate selection described in Section 4.1.4 of ICE is
ignored; defaults are not signaled or utilized by RELOAD. ignored; defaults are not signaled or utilized by RELOAD.
An alternative to using the full ICE supported by the Attach request An alternative to using the full ICE supported by the Attach request
skipping to change at page 75, line 28 skipping to change at page 76, line 28
A peer SHOULD retransmit a message if it has not received an ACK A peer SHOULD retransmit a message if it has not received an ACK
after an interval of RTO ("Retransmission TimeOut"). The peer MUST after an interval of RTO ("Retransmission TimeOut"). The peer MUST
double the time to wait after each retransmission. In each double the time to wait after each retransmission. In each
retransmission, the sequence number is incremented. retransmission, the sequence number is incremented.
The RTO is an estimate of the round-trip time (RTT). Implementations The RTO is an estimate of the round-trip time (RTT). Implementations
can use a static value for RTO or a dynamic estimate which will can use a static value for RTO or a dynamic estimate which will
result in better performance. For implementations that use a static result in better performance. For implementations that use a static
value, the default value for RTO is 500 ms. Nodes MAY use smaller value, the default value for RTO is 500 ms. Nodes MAY use smaller
values of RTO if it is known that all nodes are are within the local values of RTO if it is known that all nodes are within the local
network. The default RTO MAY be chosen larger, and this is network. The default RTO MAY be chosen larger, and this is
RECOMMENDED if it is known in advance (such as on high latency access RECOMMENDED if it is known in advance (such as on high latency access
links) that the round-trip time is larger. links) that the round-trip time is larger.
Implementations that use a dynamic estimate to compute the RTO MUST Implementations that use a dynamic estimate to compute the RTO MUST
use the algorithm described in RFC 2988[RFC2988], with the exception use the algorithm described in RFC 2988[RFC2988], with the exception
that the value of RTO SHOULD NOT be rounded up to the nearest second that the value of RTO SHOULD NOT be rounded up to the nearest second
but instead rounded up to the nearest millisecond. The RTT of a but instead rounded up to the nearest millisecond. The RTT of a
successful STUN transaction from the ICE stage is used as the initial successful STUN transaction from the ICE stage is used as the initial
measurement for formula 2.2 of RFC 2988. The sender keeps track of measurement for formula 2.2 of RFC 2988. The sender keeps track of
skipping to change at page 85, line 29 skipping to change at page 86, line 29
responsible for the resource and, if not, reject the request. If the responsible for the resource and, if not, reject the request. If the
replica number is nonzero, then the peer MUST check that it expects replica number is nonzero, then the peer MUST check that it expects
to be a replica for the resource and that the request sender is to be a replica for the resource and that the request sender is
consistent with being the responsible node (i.e., that the receiving consistent with being the responsible node (i.e., that the receiving
peer does not know of a better node) and, if not, reject the request. peer does not know of a better node) and, if not, reject the request.
Each StoreKindData element represents the data to be stored for a Each StoreKindData element represents the data to be stored for a
single Kind-ID. The contents of the element are: single Kind-ID. The contents of the element are:
kind kind
The Kind-ID. Implementations SHOULD reject requests corresponding The Kind-ID. Implementations MUST reject requests corresponding
to unknown kinds unless specifically configured otherwise. to unknown kinds.
generation generation
The expected current state of the generation counter The expected current state of the generation counter
(approximately the number of times this object has been written; (approximately the number of times this object has been written;
see below for details). see below for details).
values values
The value or values to be stored. This may contain one or more The value or values to be stored. This may contain one or more
stored_data values depending on the data model associated with stored_data values depending on the data model associated with
each kind. each kind.
skipping to change at page 99, line 17 skipping to change at page 100, line 17
Name: CERTIFICATE_BY_USER Name: CERTIFICATE_BY_USER
Data Model: The data model for CERTIFICATE_BY_USER data is array. Data Model: The data model for CERTIFICATE_BY_USER data is array.
Access Control: USER-MATCH. Access Control: USER-MATCH.
8. TURN Server Usage 8. TURN Server Usage
The TURN server usage allows a RELOAD peer to advertise that it is The TURN server usage allows a RELOAD peer to advertise that it is
prepared to be a TURN server as defined in [I-D.ietf-behave-turn]. prepared to be a TURN server as defined in [RFC5766]. When a node
When a node starts up, it joins the overlay network and forms several starts up, it joins the overlay network and forms several connections
connections in the process. If the ICE stage in any of these in the process. If the ICE stage in any of these connections returns
connections returns a reflexive address that is not the same as the a reflexive address that is not the same as the peer's perceived
peer's perceived address, then the peer is behind a NAT and not a address, then the peer is behind a NAT and not a candidate for a TURN
candidate for a TURN server. Additionally, if the peer's IP address server. Additionally, if the peer's IP address is in the private
is in the private address space range, then it is also not a address space range, then it is also not a candidate for a TURN
candidate for a TURN server. Otherwise, the peer SHOULD assume it is server. Otherwise, the peer SHOULD assume it is a potential TURN
a potential TURN server and follow the procedures below. server and follow the procedures below.
If the node is a candidate for a TURN server it will insert some If the node is a candidate for a TURN server it will insert some
pointers in the overlay so that other peers can find it. The overlay pointers in the overlay so that other peers can find it. The overlay
configuration file specifies a turnDensity parameter that indicates configuration file specifies a turnDensity parameter that indicates
how many times each TURN server should record itself in the overlay. how many times each TURN server should record itself in the overlay.
Typically this should be set to the reciprocal of the estimate of Typically this should be set to the reciprocal of the estimate of
what percentage of peers will act as TURN servers. For each value, what percentage of peers will act as TURN servers. For each value,
called d, between 1 and turnDensity, the peer forms a Resource Name called d, between 1 and turnDensity, the peer forms a Resource Name
by concatenating its Peer-ID and the value d. This Resource Name is by concatenating its Peer-ID and the value d. This Resource Name is
hashed to form a Resource-ID. The address of the peer is stored at hashed to form a Resource-ID. The address of the peer is stored at
skipping to change at page 100, line 19 skipping to change at page 101, line 19
the address at which the TURN server can be contacted. the address at which the TURN server can be contacted.
Note: Correct functioning of this algorithm depends critically on Note: Correct functioning of this algorithm depends critically on
having turnDensity be an accurate estimate of the true density of having turnDensity be an accurate estimate of the true density of
TURN servers. If turnDensity is too high, then the process of TURN servers. If turnDensity is too high, then the process of
finding TURN servers becomes extremely expensive as multiple finding TURN servers becomes extremely expensive as multiple
candidate Resource-IDs must be probed. candidate Resource-IDs must be probed.
Peers that provide this service need to support the TURN extensions Peers that provide this service need to support the TURN extensions
to STUN for media relay of both UDP and TCP traffic as defined in to STUN for media relay of both UDP and TCP traffic as defined in
[I-D.ietf-behave-turn] and [RFC5382]. [RFC5766] and [RFC5382].
This usage defines the following kind to indicate that a peer is This usage defines the following kind to indicate that a peer is
willing to act as a TURN server: willing to act as a TURN server:
Name TURN-SERVICE Name TURN-SERVICE
Data Model The TURN-SERVICE kind stores a single value for each Data Model The TURN-SERVICE kind stores a single value for each
Resource-ID. Resource-ID.
Access Control NODE-MULTIPLE, with maximum iteration counter 20. Access Control NODE-MULTIPLE, with maximum iteration counter 20.
Peers can find other servers by selecting a random Resource-ID and Peers can find other servers by selecting a random Resource-ID and
skipping to change at page 105, line 27 skipping to change at page 106, line 27
If the message is of type "full", then the contents of the message If the message is of type "full", then the contents of the message
will be: will be:
predecessors predecessors
The predecessor set of the Updating peer. The predecessor set of the Updating peer.
successors successors
The successor set of the Updating peer. The successor set of the Updating peer.
fingers fingers
The finger table if the Updating peer, in numerically ascending The finger table of the Updating peer, in numerically ascending
order. order.
A peer MUST maintain an association (via Attach) to every member of A peer MUST maintain an association (via Attach) to every member of
its neighbor set. A peer MUST attempt to maintain at least three its neighbor set. A peer MUST attempt to maintain at least three
predecessors and three successors, even though this will not be predecessors and three successors, even though this will not be
possible if the ring is very small. It is RECOMMENDED that O(log(N)) possible if the ring is very small. It is RECOMMENDED that O(log(N))
predecessors and successors be maintained in the neighbor set. predecessors and successors be maintained in the neighbor set.
9.6.1. Handling Neighbor Failures 9.6.1. Handling Neighbor Failures
skipping to change at page 113, line 43 skipping to change at page 114, 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. The IP address is in typical decimal of hex from suing port. The IP address is in typical hexidecimal form using
standard period and colon separators. (TODO - provide a reference standard period and colon separators as specified in
to well specified version of this). More than one bootstrap-peer [I-D.ietf-6man-text-addr-representation]. More than one
element may be present. 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, broadcast, 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
skipping to change at page 114, line 37 skipping to change at page 115, line 37
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 bad-node This contains a single Node-ID in hexadecimal and
indicates that the certificate with this Node-ID MUST not be indicates that the certificate with this Node-ID MUST NOT be
considered valid. This allows certificate revocation. 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.
skipping to change at page 116, line 10 skipping to change at page 117, 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 }* foreign-elements = element * - (p2pcf:* | local:* | chord:*)
foreign-attributes = attribute * - (p2pcf:*|local:*|chord:*) { text }* { anything }*
foreign-nodes = (foreign-attributes | foreign-elements)* foreign-attributes = attribute * - (p2pcf:*|local:*|chord:*)
{ text }*
foreign-nodes = (foreign-attributes | foreign-elements)*
start = start =
element p2pcf:overlay { element p2pcf:overlay {
element configuration { element configuration {
attribute instance-name { text }, attribute instance-name { text },
attribute expiration { xsd:dateTime }, attribute expiration { xsd:dateTime },
attribute sequence { xsd:long }, attribute sequence { xsd:long },
parameter parameter
}, },
element signature { element signature {
attribute algorithm { signature-algorithm-type }?, attribute algorithm { signature-algorithm-type }?,
xsd:base64Binary xsd:base64Binary
}? }?
} }
signature-algorithm-type |= "rsa-sha1" signature-algorithm-type |= "rsa-sha1"
parameter &= element topology-plugin { topology-plugin-type } parameter &= element topology-plugin { topology-plugin-type }
parameter &= element max-message-size { xsd:int }? parameter &= element max-message-size { xsd:int }?
parameter &= element initial-ttl { xsd:int }? parameter &= element initial-ttl { xsd:int }?
parameter &= element root-cert { text }? parameter &= element root-cert { text }?
parameter &= element required-kinds { kind-block* } parameter &= element required-kinds { kind-block* }
parameter &= element enrollment-server { xsd:anyURI }? parameter &= element enrollment-server { xsd:anyURI }?
parameter &= element kind-signer { text }* parameter &= element kind-signer { text }*
parameter &= element bad-node { text }* parameter &= element bad-node { text }*
parameter &= element attach-lite-permitted { xsd:boolean }? parameter &= element attach-lite-permitted { xsd:boolean }?
parameter &= element shared-secret { xsd:string }? parameter &= element shared-secret { xsd:string }?
parameter &= element clients-permitted { xsd:boolean }? parameter &= element clients-permitted { xsd:boolean }?
parameter &= element turn-density { xsd:int }? parameter &= element turn-density { xsd:int }?
parameter &= foreign-elements* parameter &= foreign-elements*
parameter &= parameter &=
element self-signed-permitted { element self-signed-permitted {
attribute digest { self-signed-digest-type }, attribute digest { self-signed-digest-type },
xsd:boolean xsd:boolean
}? }?
self-signed-digest-type |= "sha1" self-signed-digest-type |= "sha1"
parameter &= parameter &=
element bootstrap-node { element bootstrap-node {
attribute address { xsd:string }, attribute address { xsd:string },
attribute port { xsd:int } attribute port { xsd:int }
}+ }+
hostPort = text hostPort = text
parameter &= parameter &=
element multicast-bootstrap { hostPort element multicast-bootstrap { hostPort
}* }*
kind-block = element kind-block { kind-block = element kind-block {
element kind { element kind {
(attribute name { kind-names } (attribute name { kind-names }
| attribute id { xsd:int }), | attribute id { xsd:int }),
kind-paramter kind-paramter
} & } &
element kind-signature { element kind-signature {
attribute algorithm { signature-algorithm-type }?, attribute algorithm { signature-algorithm-type }?,
xsd:base64Binary xsd:base64Binary
}? }?
} }
kind-paramter &= element max-count { xsd:int } kind-paramter &= element max-count { xsd:int }
kind-paramter &= element max-size { xsd:int } kind-paramter &= element max-size { xsd:int }
kind-paramter &= element data-model { data-model-type } kind-paramter &= element data-model { data-model-type }
data-model-type |= "single" data-model-type |= "single"
data-model-type |= "array" data-model-type |= "array"
data-model-type |= "dictionary" data-model-type |= "dictionary"
kind-paramter &= element access-control { access-control-type } kind-paramter &= element access-control { access-control-type }
kind-paramter &= element max-node-multiple { xsd:int }? kind-paramter &= element max-node-multiple { xsd:int }?
access-control-type |= "user-match" access-control-type |= "user-match"
access-control-type |= "node-match" access-control-type |= "node-match"
access-control-type |= "user-node-match" access-control-type |= "user-node-match"
access-control-type |= "node-multiple" access-control-type |= "node-multiple"
access-control-type |= "user-match-with-anon-create" access-control-type |= "user-match-with-anon-create"
kind-paramter &= foreign-elements* kind-paramter &= foreign-elements*
# Chord specific paramters # Chord specific paramters
topology-plugin-type |= "chord" topology-plugin-type |= "chord"
kind-names |= "sip-registration" kind-names |= "sip-registration"
kind-names |= "turn-service" kind-names |= "turn-service"
parameter &= element chord:chord-ping-interval { xsd:int }? parameter &= element chord:chord-ping-interval { xsd:int }?
parameter &= element chord:chord-update-interval { xsd:int }? parameter &= element chord:chord-update-interval { xsd:int }?
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].
skipping to change at page 121, line 14 skipping to change at page 122, line 17
After a node has successfully joined the overlay network, it will After a node has successfully joined the overlay network, it will
have direct connections to several peers. Some MAY be added to the have direct connections to several peers. Some MAY be added to the
cached bootstrap nodes list and used in future boots. Peers that are cached bootstrap nodes list and used in future boots. Peers that are
not directly connected MUST NOT be cached. The suggested number of not directly connected MUST NOT be cached. The suggested number of
peers to cache is 10. Algorithms for determining which peers to peers to cache is 10. Algorithms for determining which peers to
cache are beyond the scope of this specification. cache are beyond the scope of this specification.
11. Message Flow Example 11. Message Flow Example
The following abbreviation are used in the message flow diagrams: JP
= joining peer, AP = admitting peer, NP = next peer after the AP, NNP
= next next peer which is the peer after NP, PP = previous peer
before the AP, PPP = previous previous peer which is the peer before
the PP, BP = bootstrap peer.
The follwowing abbreviation are used in the message flow diagrams:
In the following example, we assume that JP has formed a connection In the following example, we assume that JP has formed a connection
to one of the bootstrap nodes. JP then sends an Attach through that to one of the bootstrap nodes. JP then sends an Attach through that
peer to the admitting peer (AP) to initiate a connection. When AP peer to the admitting peer (AP) to initiate a connection. When AP
responds, JP and AP use ICE to set up a connection and then set up responds, JP and AP use ICE to set up a connection and then set up
TLS. TLS.
JP PPP PP AP NP NNP BP JP PPP PP AP NP NNP BP
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
skipping to change at page 127, line 32 skipping to change at page 128, line 32
| | | | | | | |
| | | | | | | |
12. Security Considerations 12. Security Considerations
12.1. Overview 12.1. Overview
RELOAD provides a generic storage service, albeit one designed to be RELOAD provides a generic storage service, albeit one designed to be
useful for P2PSIP. In this section we discuss security issues that useful for P2PSIP. In this section we discuss security issues that
are likely to be relevant to any usage of RELOAD. More background are likely to be relevant to any usage of RELOAD. More background
information can be found in [I-D.irtf-p2prg-rtc-security]. information can be found in [RFC5765].
In any Overlay Instance, any given user depends on a number of peers In any Overlay Instance, any given user depends on a number of peers
with which they have no well-defined relationship except that they with which they have no well-defined relationship except that they
are fellow members of the Overlay Instance. In practice, these other are fellow members of the Overlay Instance. In practice, these other
nodes may be friendly, lazy, curious, or outright malicious. No nodes may be friendly, lazy, curious, or outright malicious. No
security system can provide complete protection in an environment security system can provide complete protection in an environment
where most nodes are malicious. The goal of security in RELOAD is to where most nodes are malicious. The goal of security in RELOAD is to
provide strong security guarantees of some properties even in the provide strong security guarantees of some properties even in the
face of a large number of malicious nodes and to allow the overlay to face of a large number of malicious nodes and to allow the overlay to
function correctly in the face of a modest number of malicious nodes. function correctly in the face of a modest number of malicious nodes.
skipping to change at page 128, line 43 skipping to change at page 129, line 43
this data as well as securing, as well as possible, the routing in this data as well as securing, as well as possible, the routing in
the overlay. Both types of security are based on requiring that the overlay. Both types of security are based on requiring that
every entity in the system (whether user or peer) authenticate every entity in the system (whether user or peer) authenticate
cryptographically using an asymmetric key pair tied to a certificate. cryptographically using an asymmetric key pair tied to a certificate.
When a user enrolls in the Overlay Instance, they request or are When a user enrolls in the Overlay Instance, they request or are
assigned a unique name, such as "alice@dht.example.net". These names assigned a unique name, such as "alice@dht.example.net". These names
are unique and are meant to be chosen and used by humans much like a are unique and are meant to be chosen and used by humans much like a
SIP Address of Record (AOR) or an email address. The user is also SIP Address of Record (AOR) or an email address. The user is also
assigned one or more Node-IDs by the central enrollment authority. assigned one or more Node-IDs by the central enrollment authority.
Both the name and the Peer-ID are placed in the certificate, along Both the name and the Node-ID are placed in the certificate, along
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,
skipping to change at page 142, line 12 skipping to change at page 143, line 12
(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.
The ideas text for the Chord specific extension data to the Leave The ideas and text for the Chord specific extension data to the Leave
mechanisms was provided by J. Maenpaa, G. Camarillo, and J. mechanisms was provided by J. Maenpaa, G. Camarillo, and J.
Hautakorp. Hautakorpi.
Thanks to the many people who contributed including Ted Hardie, Thanks to the many people who contributed including Ted Hardie,
Michael Chen, Dan York, Das Saumitra, Lyndsay Campbell, Brian Rosen, Michael Chen, Dan York, Das Saumitra, Lyndsay Campbell, Brian Rosen,
David Bryan, Dave Craig, and Julian Cain. Extensinve working last David Bryan, Dave Craig, and Julian Cain. Extensinve working last
call comments were provided by: TODO call comments were provided by: Jouni Maenpaa, Roni Even, Ari
Keranen, John Buford, Michael Chen, Frederic-Philippe Met, and David
Bryan.
15. References 15. References
15.1. Normative References 15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[I-D.ietf-mmusic-ice] [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", Traversal for Offer/Answer Protocols", RFC 5245,
draft-ietf-mmusic-ice-19 (work in progress), October 2007. April 2010.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. October 2008.
[I-D.ietf-behave-turn] [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
draft-ietf-behave-turn-16 (work in progress), July 2009.
[RFC5273] Schaad, J. and M. Myers, "Certificate Management over CMS [RFC5273] Schaad, J. and M. Myers, "Certificate Management over CMS
(CMC): Transport Protocols", RFC 5273, June 2008. (CMC): Transport Protocols", RFC 5273, June 2008.
[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS
(CMC)", RFC 5272, June 2008. (CMC)", RFC 5272, June 2008.
[RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
for Transport Layer Security (TLS)", RFC 4279, for Transport Layer Security (TLS)", RFC 4279,
December 2005. December 2005.
skipping to change at page 143, line 31 skipping to change at page 144, line 30
Timer", RFC 2988, November 2000. Timer", RFC 2988, November 2000.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 35, Registration Procedures for New URI Schemes", BCP 35,
RFC 4395, February 2006. RFC 4395, February 2006.
[I-D.ietf-6man-text-addr-representation]
Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation",
draft-ietf-6man-text-addr-representation-07 (work in
progress), February 2010.
15.2. Informative References 15.2. Informative References
[I-D.ietf-mmusic-ice-tcp] [I-D.ietf-mmusic-ice-tcp]
Rosenberg, J., "TCP Candidates with Interactive Rosenberg, J., "TCP Candidates with Interactive
Connectivity Establishment (ICE)", Connectivity Establishment (ICE)",
draft-ietf-mmusic-ice-tcp-07 (work in progress), draft-ietf-mmusic-ice-tcp-07 (work in progress),
July 2008. July 2008.
[I-D.maenpaa-p2psip-self-tuning] [I-D.maenpaa-p2psip-self-tuning]
Maenpaa, J., Camarillo, G., and J. Hautakorpi, "A Self- Maenpaa, J., Camarillo, G., and J. Hautakorpi, "A Self-
skipping to change at page 146, line 22 skipping to change at page 147, line 27
Kaashoek, M., Dabek, F., and H. Balakrishnan, "Chord: A Kaashoek, M., Dabek, F., and H. Balakrishnan, "Chord: A
Scalable Peer-to-peer Lookup Protocol for Internet Scalable Peer-to-peer Lookup Protocol for Internet
Applications", IEEE/ACM Transactions on Networking Volume Applications", IEEE/ACM Transactions on Networking Volume
11, Issue 1, 17-32, Feb 2003. 11, Issue 1, 17-32, Feb 2003.
[vulnerabilities-acsac04] [vulnerabilities-acsac04]
Srivatsa, M. and L. Liu, "Vulnerabilities and Security Srivatsa, M. and L. Liu, "Vulnerabilities and Security
Threats in Structured Peer-to-Peer Systems: A Quantitative Threats in Structured Peer-to-Peer Systems: A Quantitative
Analysis", ACSAC 2004. Analysis", ACSAC 2004.
[I-D.irtf-p2prg-rtc-security] [RFC5765] Schulzrinne, H., Marocco, E., and E. Ivov, "Security
Schulzrinne, H., Marocco, E., and E. Ivov, "Security Issues and Solutions in Peer-to-Peer Systems for Realtime
Issues and Solutions in Peer-to-peer Systems for Realtime Communications", RFC 5765, February 2010.
Communications", draft-irtf-p2prg-rtc-security-05 (work in
progress), September 2009.
[handling-churn-usenix04] [handling-churn-usenix04]
Rhea, S., Geels, D., Roscoe, T., and J. Kubiatowicz, Rhea, S., Geels, D., Roscoe, T., and J. Kubiatowicz,
"Handling Churn in a DHT", USENIX 2004. "Handling Churn in a DHT", In Proc. of the USENIX Annual
Technical Conference June 2004 USENIX 2004.
[minimizing-churn-sigcomm06] [minimizing-churn-sigcomm06]
Godfrey, P., Shenker, S., and I. Stoica, "Minimizing Churn Godfrey, P., Shenker, S., and I. Stoica, "Minimizing Churn
in Distributed Systems", SIGCOMM 2006. in Distributed Systems", SIGCOMM 2006.
Appendix A. Change Log Appendix A. Change Log
A.1. Changes since draft-ietf-p2psip-reload-04 A.1. Changes since draft-ietf-p2psip-reload-04
o Renamed the XML element in configuration files from <bootstrap- o Renamed the XML element in configuration files from <bootstrap-
 End of changes. 65 change blocks. 
349 lines changed or deleted 360 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/