draft-ietf-p2psip-base-22.txt   draft-ietf-p2psip-base-23.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: January 17, 2013 Skype Expires: May 9, 2013 Skype
E. Rescorla E. Rescorla
RTFM, Inc. RTFM, Inc.
S. Baset S. Baset
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
July 16, 2012 November 05, 2012
REsource LOcation And Discovery (RELOAD) Base Protocol REsource LOcation And Discovery (RELOAD) Base Protocol
draft-ietf-p2psip-base-22 draft-ietf-p2psip-base-23
Abstract Abstract
This specification defines REsource LOcation And Discovery (RELOAD), This specification defines REsource LOcation And Discovery (RELOAD),
a peer-to-peer (P2P) signaling protocol for use on the Internet. A a peer-to-peer (P2P) signaling protocol for use on the Internet. A
P2P signaling protocol provides its clients with an abstract storage P2P signaling protocol provides its clients with an abstract storage
and messaging service between a set of cooperating peers that form and messaging service between a set of cooperating peers that form
the overlay network. RELOAD is designed to support a P2P Session the overlay network. RELOAD is designed to support a P2P Session
Initiation Protocol (P2PSIP) network, but can be utilized by other Initiation Protocol (P2PSIP) network, but can be utilized by other
applications with similar requirements by defining new usages that applications with similar requirements by defining new usages that
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 17, 2013. This Internet-Draft will expire on May 9, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 6 skipping to change at page 4, line 6
6.1.3. Opaque ID . . . . . . . . . . . . . . . . . . . . . 39 6.1.3. Opaque ID . . . . . . . . . . . . . . . . . . . . . 39
6.2. Symmetric Recursive Routing . . . . . . . . . . . . . . 39 6.2. Symmetric Recursive Routing . . . . . . . . . . . . . . 39
6.2.1. Request Origination . . . . . . . . . . . . . . . . 39 6.2.1. Request Origination . . . . . . . . . . . . . . . . 39
6.2.2. Response Origination . . . . . . . . . . . . . . . . 40 6.2.2. Response Origination . . . . . . . . . . . . . . . . 40
6.3. Message Structure . . . . . . . . . . . . . . . . . . . 40 6.3. Message Structure . . . . . . . . . . . . . . . . . . . 40
6.3.1. Presentation Language . . . . . . . . . . . . . . . 41 6.3.1. Presentation Language . . . . . . . . . . . . . . . 41
6.3.1.1. Common Definitions . . . . . . . . . . . . . . . 42 6.3.1.1. Common Definitions . . . . . . . . . . . . . . . 42
6.3.2. Forwarding Header . . . . . . . . . . . . . . . . . 44 6.3.2. Forwarding Header . . . . . . . . . . . . . . . . . 44
6.3.2.1. Processing Configuration Sequence Numbers . . . . 46 6.3.2.1. Processing Configuration Sequence Numbers . . . . 46
6.3.2.2. Destination and Via Lists . . . . . . . . . . . . 47 6.3.2.2. Destination and Via Lists . . . . . . . . . . . . 47
6.3.2.3. Forwarding Options . . . . . . . . . . . . . . . 49 6.3.2.3. Forwarding Option . . . . . . . . . . . . . . . . 49
6.3.3. Message Contents Format . . . . . . . . . . . . . . 50 6.3.3. Message Contents Format . . . . . . . . . . . . . . 50
6.3.3.1. Response Codes and Response Errors . . . . . . . 51 6.3.3.1. Response Codes and Response Errors . . . . . . . 51
6.3.4. Security Block . . . . . . . . . . . . . . . . . . . 53 6.3.4. Security Block . . . . . . . . . . . . . . . . . . . 53
6.4. Overlay Topology . . . . . . . . . . . . . . . . . . . . 57 6.4. Overlay Topology . . . . . . . . . . . . . . . . . . . . 57
6.4.1. Topology Plugin Requirements . . . . . . . . . . . . 57 6.4.1. Topology Plugin Requirements . . . . . . . . . . . . 57
6.4.2. Methods and types for use by topology plugins . . . 58 6.4.2. Methods and types for use by topology plugins . . . 58
6.4.2.1. Join . . . . . . . . . . . . . . . . . . . . . . 58 6.4.2.1. Join . . . . . . . . . . . . . . . . . . . . . . 58
6.4.2.2. Leave . . . . . . . . . . . . . . . . . . . . . . 59 6.4.2.2. Leave . . . . . . . . . . . . . . . . . . . . . . 59
6.4.2.3. Update . . . . . . . . . . . . . . . . . . . . . 59 6.4.2.3. Update . . . . . . . . . . . . . . . . . . . . . 59
6.4.2.4. RouteQuery . . . . . . . . . . . . . . . . . . . 60 6.4.2.4. RouteQuery . . . . . . . . . . . . . . . . . . . 60
skipping to change at page 6, line 12 skipping to change at page 6, line 12
10.7.4.3. Adjusting finger table size . . . . . . . . . . . 116 10.7.4.3. Adjusting finger table size . . . . . . . . . . . 116
10.7.4.4. Detecting partitioning . . . . . . . . . . . . . 117 10.7.4.4. Detecting partitioning . . . . . . . . . . . . . 117
10.8. Route query . . . . . . . . . . . . . . . . . . . . . . 117 10.8. Route query . . . . . . . . . . . . . . . . . . . . . . 117
10.9. Leaving . . . . . . . . . . . . . . . . . . . . . . . . 118 10.9. Leaving . . . . . . . . . . . . . . . . . . . . . . . . 118
11. Enrollment and Bootstrap . . . . . . . . . . . . . . . . . . 119 11. Enrollment and Bootstrap . . . . . . . . . . . . . . . . . . 119
11.1. Overlay Configuration . . . . . . . . . . . . . . . . . 119 11.1. Overlay Configuration . . . . . . . . . . . . . . . . . 119
11.1.1. Relax NG Grammar . . . . . . . . . . . . . . . . . . 126 11.1.1. Relax NG Grammar . . . . . . . . . . . . . . . . . . 126
11.2. Discovery Through Configuration Server . . . . . . . . . 128 11.2. Discovery Through Configuration Server . . . . . . . . . 128
11.3. Credentials . . . . . . . . . . . . . . . . . . . . . . 129 11.3. Credentials . . . . . . . . . . . . . . . . . . . . . . 129
11.3.1. Self-Generated Credentials . . . . . . . . . . . . . 131 11.3.1. Self-Generated Credentials . . . . . . . . . . . . . 130
11.4. Searching for a Bootstrap Node . . . . . . . . . . . . . 131 11.4. Searching for a Bootstrap Node . . . . . . . . . . . . . 131
11.5. Contacting a Bootstrap Node . . . . . . . . . . . . . . 131 11.5. Contacting a Bootstrap Node . . . . . . . . . . . . . . 131
12. Message Flow Example . . . . . . . . . . . . . . . . . . . . 132 12. Message Flow Example . . . . . . . . . . . . . . . . . . . . 132
13. Security Considerations . . . . . . . . . . . . . . . . . . . 138 13. Security Considerations . . . . . . . . . . . . . . . . . . . 138
13.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 138 13.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 138
13.2. Attacks on P2P Overlays . . . . . . . . . . . . . . . . 139 13.2. Attacks on P2P Overlays . . . . . . . . . . . . . . . . 139
13.3. Certificate-based Security . . . . . . . . . . . . . . . 139 13.3. Certificate-based Security . . . . . . . . . . . . . . . 139
13.4. Shared-Secret Security . . . . . . . . . . . . . . . . . 140 13.4. Shared-Secret Security . . . . . . . . . . . . . . . . . 140
13.5. Storage Security . . . . . . . . . . . . . . . . . . . . 141 13.5. Storage Security . . . . . . . . . . . . . . . . . . . . 141
13.5.1. Authorization . . . . . . . . . . . . . . . . . . . 141 13.5.1. Authorization . . . . . . . . . . . . . . . . . . . 141
skipping to change at page 12, line 24 skipping to change at page 12, line 24
Forwarding and Link Management Layer: Stores and implements the Forwarding and Link Management Layer: Stores and implements the
routing table by providing packet forwarding services between routing table by providing packet forwarding services between
nodes. It also handles establishing new links between nodes, nodes. It also handles establishing new links between nodes,
including setting up connections across NATs using ICE. including setting up connections across NATs using ICE.
Overlay Link Layer: Responsible for actually transporting traffic Overlay Link Layer: Responsible for actually transporting traffic
directly between nodes. Each such protocol includes the directly between nodes. Each such protocol includes the
appropriate provisions for per-hop framing or hop-by-hop ACKs appropriate provisions for per-hop framing or hop-by-hop ACKs
required by unreliable transports. TLS [RFC5246] and DTLS required by unreliable transports. TLS [RFC5246] and DTLS
[RFC4347] are the currently defined "link layer" protocols used by [RFC6347] are the currently defined "link layer" protocols used by
RELOAD for hop-by-hop communication. New protocols can be RELOAD for hop-by-hop communication. New protocols can be
defined, as described in Section 6.6.1 and Section 11.1. As this defined, as described in Section 6.6.1 and Section 11.1. As this
document defines only TLS and DTLS, we use those terms throughout document defines only TLS and DTLS, we use those terms throughout
the remainder of the document with the understanding that some the remainder of the document with the understanding that some
future specification may add new overlay link layers. future specification may add new overlay link layers.
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:
skipping to change at page 17, line 34 skipping to change at page 17, line 34
1.3. Security 1.3. Security
RELOAD's security model is based on each node having one or more RELOAD's security model is based on each node having one or more
public key certificates. In general, these certificates will be public key certificates. In general, these certificates will be
assigned by a central server which also assigns Node-IDs, although assigned by a central server which also assigns Node-IDs, although
self-signed certificates can be used in closed networks. These self-signed certificates can be used in closed networks. These
credentials can be leveraged to provide communications security for credentials can be leveraged to provide communications security for
RELOAD messages. RELOAD provides communications security at three RELOAD messages. RELOAD provides communications security at three
levels: levels:
Connection Level: Connections between peers are secured with TLS, Connection Level: Connections between nodes are secured with TLS,
DTLS, or potentially some to be defined future protocol. DTLS, or potentially some to be defined future protocol.
Message Level: Each RELOAD message is signed. Message Level: Each RELOAD message is signed.
Object Level: Stored objects is signed by the creating peer. Object Level: Stored objects are signed by the creating node.
These three levels of security work together to allow peers to verify These three levels of security work together to allow nodes to verify
the origin and correctness of data they receive from other peers, the origin and correctness of data they receive from other nodes,
even in the face of malicious activity by other peers in the overlay. even in the face of malicious activity by other nodes in the overlay.
RELOAD also provides access control built on top of these RELOAD also provides access control built on top of these
communications security features. Because the peer responsible for communications security features. Because the peer responsible for
storing a piece of data can validate the signature on the data being storing a piece of data can validate the signature on the data being
stored, the responsible peer can determine whether a given operation stored, the responsible peer can determine whether a given operation
is permitted or not. is permitted or not.
RELOAD also provides an optional shared secret based admission RELOAD also provides an optional shared secret based admission
control feature using shared secrets and TLS-PSK. In order to form a control feature using shared secrets and TLS-PSK. In order to form a
TLS connection to any node in the overlay, a new node needs to know TLS connection to any node in the overlay, a new node needs to know
the shared overlay key, thus restricting access to authorized users the shared overlay key, thus restricting access to authorized users
skipping to change at page 21, line 46 skipping to change at page 21, line 46
Every node in the RELOAD overlay is identified by a Node-ID. The Every node in the RELOAD overlay is identified by a Node-ID. The
Node-ID is used for three major purposes: Node-ID is used for three major purposes:
o To address the node itself. o To address the node itself.
o To determine its position in the overlay topology when the overlay o To determine its position in the overlay topology when the overlay
is structured. is structured.
o To determine the set of resources for which the node is o To determine the set of resources for which the node is
responsible. responsible.
Each node has a certificate [RFC5280] containing a Node-ID, which is Each node has a certificate [RFC5280] containing this Node-ID, which
unique within an overlay instance. is unique within an overlay instance.
The certificate serves multiple purposes: The certificate serves multiple purposes:
o It entitles the user to store data at specific locations in the o It entitles the user to store data at specific locations in the
Overlay Instance. Each data Kind defines the specific rules for Overlay Instance. Each data Kind defines the specific rules for
determining which certificates can access each Resource-ID/Kind-ID determining which certificates can access each Resource-ID/Kind-ID
pair. For instance, some Kinds might allow anyone to write at a pair. For instance, some Kinds might allow anyone to write at a
given location, whereas others might restrict writes to the owner given location, whereas others might restrict writes to the owner
of a single certificate. of a single certificate.
o It entitles the user to operate a node that has a Node-ID found in o It entitles the user to operate a node that has a Node-ID found in
skipping to change at page 27, line 8 skipping to change at page 27, line 8
<---------- <----------
Dest=B,A Dest=B,A
<---------- <----------
Dest=A Dest=A
Note that the preceding Figure does not indicate whether A is a Note that the preceding Figure does not indicate whether A is a
client or peer: A forwards its request to B and the response is client or peer: A forwards its request to B and the response is
returned to A in the same manner regardless of A's role in the returned to A in the same manner regardless of A's role in the
overlay. overlay.
This figure shows use of full via-lists by intermediate peers B and This figure shows use of full via lists by intermediate peers B and
X. However, if B and/or X are willing to store state, then they may X. However, if B and/or X are willing to store state, then they may
elect to truncate the lists, save that information internally (keyed elect to truncate the lists, save that information internally (keyed
by the transaction id), and return the response message along the by the transaction id), and return the response message along the
path from which it was received when the response is received. This path from which it was received when the response is received. This
option requires greater state to be stored on intermediate peers but option requires greater state to be stored on intermediate peers but
saves a small amount of bandwidth and reduces the need for modifying saves a small amount of bandwidth and reduces the need for modifying
the message en route. Selection of this mode of operation is a the message en route. Selection of this mode of operation is a
choice for the individual peer; the techniques are interoperable even choice for the individual peer; the techniques are interoperable even
on a single message. The figure below shows B using full via lists on a single message. The figure below shows B using full via lists
but X truncating them to X1 and saving the state internally. but X truncating them to X1 and saving the state internally.
skipping to change at page 27, line 39 skipping to change at page 27, line 39
Via=X1 Via=X1
Dest=Z Dest=Z
<---------- <----------
Dest=X,X1 Dest=X,X1
<---------- <----------
Dest=B,A Dest=B,A
<---------- <----------
Dest=A Dest=A
As before, when B receives the message, he creates via list As before, when B receives the message, he creates a via list
consisting of [A]. However, instead of sending [A,B], X creates an consisting of [A]. However, instead of sending [A, B], X creates an
opaque ID X1 which maps internally to [A, B] (perhaps by being an opaque ID X1 which maps internally to [A, B] (perhaps by being an
encryption of [A, B] and forwards to Z with only X1 as the via list. encryption of [A, B] and forwards to Z with only X1 as the via list.
When the response arrives at X, it maps X1 back to [A, B] and then When the response arrives at X, it maps X1 back to [A, B] and then
inverts it to produce the new destination list [B, A] and routes it inverts it to produce the new destination list [B, A] and routes it
to B. to B.
RELOAD also supports a basic Iterative routing mode (where the RELOAD also supports a basic Iterative routing mode (where the
intermediate peers merely return a response indicating the next hop, intermediate peers merely return a response indicating the next hop,
but do not actually forward the message to that next hop themselves). but do not actually forward the message to that next hop themselves).
Iterative routing is implemented using the RouteQuery method, which Iterative routing is implemented using the RouteQuery method, which
skipping to change at page 28, line 30 skipping to change at page 28, line 30
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.
There are two cases where Attach is not used. The first is when a There are two cases where Attach is not used. The first is when a
peer is joining the overlay and is not connected to any peers. In peer is joining the overlay and is not connected to any peers. In
order to support this case, some small number of "bootstrap nodes" order to support this case, some small number of "bootstrap nodes"
typically need to be publicly accessible so that new peers can typically need to be publicly accessible so that new peers can
directly connect to them. Section 11 contains more detail on this. directly connect to them. Section 11 contains more detail on this.
The second case is when a client node connects to a node at an The second case is when a client connects to a peer at an arbitrary
arbitrary IP address, rather than to its responsible peer, as IP address, rather than to its responsible peer, as described in the
described in the second bullet point of Section 3.2.1. second bullet point of Section 3.2.1.
In general, a peer needs to maintain connections to all of the peers In general, a peer needs to maintain connections to all of the peers
near it in the Overlay Instance and to enough other peers to have near it in the Overlay Instance and to enough other peers to have
efficient routing (the details depend on the specific overlay). If a efficient routing (the details depend on the specific overlay). If a
peer cannot form a connection to some other peer, this isn't peer cannot form a connection to some other peer, this isn't
necessarily a disaster; overlays can route correctly even without necessarily a disaster; overlays can route correctly even without
fully connected links. However, a peer should try to maintain the fully connected links. However, a peer should try to maintain the
specified link set and if it detects that it has fewer direct specified link set and if it detects that it has fewer direct
connections, should form more as required. This also implies that connections, should form more as required. This also implies that
peers need to periodically verify that the connected peers are still peers need to periodically verify that the connected peers are still
skipping to change at page 31, line 19 skipping to change at page 31, line 19
configuration parameters. The node does a DNS SRV lookup on the configuration parameters. The node does a DNS SRV lookup on the
overlay name to get the address of a configuration server. It can overlay name to get the address of a configuration server. It can
then connect to this server with HTTPS [RFC2818] to download a then connect to this server with HTTPS [RFC2818] to download a
configuration document which contains the basic overlay configuration configuration document which contains the basic overlay configuration
parameters as well as a set of bootstrap nodes which can be used to parameters as well as a set of bootstrap nodes which can be used to
join the overlay. The expected domain name for HTTPS is the name of join the overlay. The expected domain name for HTTPS is the name of
the overlay. the overlay.
If a node already has the valid configuration document that it If a node already has the valid configuration document that it
received by some out of band method, this step can be skipped. Note received by some out of band method, this step can be skipped. Note
that that out of band method MUST provide authentication and that that out of band method must provide authentication and
integrity, because the configuration document contains the trust integrity, because the configuration document contains the trust
anchors for the system. anchors for the system.
3.6.2. Enrollment 3.6.2. Enrollment
If the overlay is using centralized enrollment, then a user needs to If the overlay is using centralized enrollment, then a user needs to
acquire a certificate before joining the overlay. The certificate acquire a certificate before joining the overlay. The certificate
attests both to the user's name within the overlay and to the Node- attests both to the user's name within the overlay and to the Node-
IDs which they are permitted to operate. In that case, the IDs which they are permitted to operate. In that case, the
configuration document will contain the address of an enrollment configuration document will contain the address of an enrollment
server which can be used to obtain such a certificate. The server which can be used to obtain such a certificate. The
enrollment server may (and probably will) require some sort of enrollment server may (and probably will) require some sort of
username and password before issuing the certificate. The enrollment username and password before issuing the certificate. The enrollment
server's ability to restrict attackers' access to certificates in the server's ability to restrict attackers' access to certificates in the
overlay is one of the cornerstones of RELOAD's security. overlay is one of the cornerstones of RELOAD's security.
3.6.3. Diagnostics 3.6.3. Diagnostics
Significant advice around managing a RELAOD overlay and extensions Significant advice around managing a RELOAD overlay and extensions
for diagnostics are described in [I-D.ietf-p2psip-diagnostics]. for diagnostics are described in [I-D.ietf-p2psip-diagnostics].
4. RFC 2119 Terminology 4. RFC 2119 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
5. Application Support Overview 5. Application Support Overview
skipping to change at page 33, line 35 skipping to change at page 33, line 35
a small number of locations in the overlay, with those locations a small number of locations in the overlay, with those locations
being determined by the node's certificate. When a peer uses a Store being determined by the node's certificate. When a peer uses a Store
request to place data at a location authorized by its certificate, it request to place data at a location authorized by its certificate, it
signs that data with the private key that corresponds to its signs that data with the private key that corresponds to its
certificate. Then the peer responsible for storing the data is able certificate. Then the peer responsible for storing the data is able
to verify that the peer issuing the request is authorized to make to verify that the peer issuing the request is authorized to make
that request. Each data Kind defines the exact rules for determining that request. Each data Kind defines the exact rules for determining
what certificate is appropriate. what certificate is appropriate.
The most natural rule is that a certificate authorizes a user to The most natural rule is that a certificate authorizes a user to
store data keyed with their user name X. This rule is used for all store data keyed with their user name X. Thus, only a user with a
the Kinds defined in this specification. Thus, only a user with a
certificate for "alice@example.org" could write to that location in certificate for "alice@example.org" could write to that location in
the overlay. However, other usages can define any rules they choose, the overlay. However, other usages can define any rules they choose,
including publicly writable values. including publicly writable values.
The digital signature over the data serves two purposes. First, it The digital signature over the data serves two purposes. First, it
allows the peer responsible for storing the data to verify that this allows the peer responsible for storing the data to verify that this
Store is authorized. Second, it provides integrity for the data. Store is authorized. Second, it provides integrity for the data.
The signature is saved along with the data value (or values) so that The signature is saved along with the data value (or values) so that
any reader can verify the integrity of the data. Of course, the any reader can verify the integrity of the data. Of course, the
responsible peer can "lose" the value but it cannot undetectably responsible peer can "lose" the value but it cannot undetectably
skipping to change at page 34, line 48 skipping to change at page 34, line 47
5.2. Usages 5.2. Usages
By itself, the distributed storage layer just provides infrastructure By itself, the distributed storage layer just provides infrastructure
on which applications are built. In order to do anything useful, a on which applications are built. In order to do anything useful, a
usage must be defined. Each Usage needs to specify several things: usage must be defined. Each Usage needs to specify several things:
o Registers Kind-ID code points for any Kinds that the Usage o Registers Kind-ID code points for any Kinds that the Usage
defines. defines.
o Defines the data structure for each of the Kinds. o Defines the data structure for each of the Kinds.
o Defines access control rules for each of the Kinds. o Defines access control rules for each of the Kinds.
o Defines how the Resource Name is formed that is hashed to form the o Defines how the Resource Name is hashed to form the Resource-ID
Resource-ID where each Kind is stored. where each Kind is stored.
o Describes how values will be merged after a network partition. o Describes how values will be merged after a network partition.
Unless otherwise specified, the default merging rule is to act as Unless otherwise specified, the default merging rule is to act as
if all the values that need to be merged were stored and as if the if all the values that need to be merged were stored and as if the
order they were stored in corresponds to the stored time values order they were stored in corresponds to the stored time values
associated with (and carried in) their values. Because the stored associated with (and carried in) their values. Because the stored
time values are those associated with the peer which did the time values are those associated with the peer which did the
writing, clock skew is generally not an issue. If two nodes are writing, clock skew is generally not an issue. If two nodes are
on different partitions, write to the same location, and have on different partitions, write to the same location, and have
clock skew, this can create merge conflicts. However because clock skew, this can create merge conflicts. However because
RELOAD deliberately segregates storage so that data from different RELOAD deliberately segregates storage so that data from different
skipping to change at page 37, line 4 skipping to change at page 36, line 48
If the first entry on the destination list is an ID for which the If the first entry on the destination list is an ID for which the
peer is responsible, there are several (mutually exclusive) sub-cases peer is responsible, there are several (mutually exclusive) sub-cases
to consider. to consider.
o If the entry is a Resource-ID, then it MUST be the only entry on o If the entry is a Resource-ID, then it MUST be the only entry on
the destination list. If there are other entries, the message the destination list. If there are other entries, the message
MUST be silently dropped. Otherwise, the message is destined for MUST be silently dropped. Otherwise, the message is destined for
this node and it verify the signature and pass it up to the upper this node and it verify the signature and pass it up to the upper
layers. 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
so the node passes it up to the upper layers. Otherwise the node so the node passes it up to the upper layers. Otherwise the node
removes the entry from the destination list and repeats the removes the entry from the destination list and repeats the
routing process with the next entry on the destination list. If routing process with the next entry on the destination list. If
the message is a response and list compression was used, then the the message is a response and list compression was used, then the
node first modifies the destination list to reinsert the saved node first modifies the destination list to reinsert the saved
state, e.g., by unpacking any opaque ids. state, e.g., by unpacking any opaque IDS.
o If the entry is the wildcard Node-ID, the message is destined for o If the entry is the wildcard Node-ID, the message is destined for
this node and it passes it up to the upper layers. this node and it passes it up to the upper layers.
o If the entry is a Node-ID which is not equal to this node, then o If the entry is a Node-ID which is not equal to this node, then
the node MUST drop the message silently unless the Node-ID the node MUST drop the message silently unless the Node-ID
corresponds to a node which is directly connected to this node corresponds to a node which is directly connected to this node
(i.e., a client). In the later case, it MUST forward the message (i.e., a client). In the later case, it MUST forward the message
to the destination node as described in the next section. to the destination node as described in the next section.
Note that this implies that in order to address a message to "the Note that this implies that in order to address a message to "the
peer that controls region X", a sender sends to Resource-ID X, not peer that controls region X", a sender sends to Resource-ID X, not
skipping to change at page 37, line 49 skipping to change at page 37, line 44
routed back through the set of nodes through which the request routed back through the set of nodes through which the request
passed. There are two major ways of accomplishing this: passed. There are two major ways of accomplishing this:
o The peer can add an entry to the via list in the forwarding header o The peer can add an entry to the via list in the forwarding header
that will enable it to determine the correct node. that will enable it to determine the correct node.
o The peer can keep per-transaction state which will allow it to o The peer can keep per-transaction state which will allow it to
determine the correct node. determine the correct node.
As an example of the first strategy, consider an example with nodes As an example of the first strategy, consider an example with nodes
A, B, C, D and E. If node D receives a message from node C with via A, B, C, D and E. If node D receives a message from node C with via
list (A, B), then D would forward to the next node (E) with via list list [A, B], then D would forward to the next node E with via list
(A, B, C). Now, if E wants to respond to the message, it reverses [A, B, C]. Now, if E wants to respond to the message, it reverses
the via list to produce the destination list, resulting in (D, C, B, the via list to produce the destination list, resulting in [D, C, B,
A). When D forwards the response to C, the destination list will A]. When D forwards the response to C, the destination list will
contain (C, B, A). contain [C, B, A].
As an example of the second strategy, if node D receives a message As an example of the second strategy, if node D receives a message
from node C with transaction ID X and via list (A, B), it could store from node C with transaction ID X and via list [A, B], it could store
(X, C) in its state database and forward the message with the via
[X, C] in its state database and forward the message with the via
list unchanged. When D receives the response, it consults its state list unchanged. When D receives the response, it consults its state
database for transaction id X, determines that the request came from database for transaction id X, determines that the request came from
C, and forwards the response to C. C, and forwards the response to C.
Intermediate peers which modify the via list are not required to Intermediate peers which modify the via list are not required to
simply add entries. The only requirement is that the peer MUST be simply add entries. The only requirement is that the peer MUST be
able to reconstruct the correct destination list on the return route. able to reconstruct the correct destination list on the return route.
RELOAD provides explicit support for this functionality in the form RELOAD provides explicit support for this functionality in the form
of opaque IDs, which can replace any number of via list entries. For of opaque IDs, which can replace any number of via list entries. For
instance, in the above example, Node D might send E a via list instance, in the above example, Node D might send E a via list
containing only the opaque ID (I). E would then use the destination containing only the opaque ID I. E would then use the destination
list (D, I) to send its return message. When D processes this list [D, I] to send its return message. When D processes this
destination list, it would detect that I is a opaque ID, recover the destination list, it would detect that I is a opaque ID, recover the
via list (A, B, C), and reverse that to produce the correct via list [A, B, C], and reverse that to produce the correct
destination list (C, B, A) before sending it to C. This feature is destination list [C, B, A] before sending it to C. This feature is
called List Compression. Possibilities for a opaque id include a called List Compression. Possibilities for a opaque ID include a
compressed version of the original via list or an index into a state compressed version of the original via list or an index into a state
database containing the original via list, but the details are a database containing the original via list, but the details are a
local matter. local matter.
No matter what mechanism for storing via list state is used, if an No matter what mechanism for storing via list state is used, if an
intermediate peer exits the overlay, then on the return trip the intermediate peer exits the overlay, then on the return trip the
message cannot be forwarded and will be dropped. The ordinary message cannot be forwarded and will be dropped. The ordinary
timeout and retransmission mechanisms provide stability over this timeout and retransmission mechanisms provide stability over this
type of failure. type of failure.
Note that if an intermediate peer retains per-transaction state Note that if an intermediate peer retains per-transaction state
instead of modifying the via list, it needs some mechanism for timing instead of modifying the via list, it needs some mechanism for timing
out that state, otherwise its state database will grow without bound. out that state, otherwise its state database will grow without bound.
Whatever algorithm is used, unless a FORWARD_CRITICAL forwarding Whatever algorithm is used, unless a FORWARD_CRITICAL forwarding
option or overlay configuration option explicitly indicates this option or overlay configuration option explicitly indicates this
state is not needed, the state MUST be maintained for at least the state is not needed, the state MUST be maintained for at least the
value of the overlay-reliability-timer configuration parameter and value of the overlay-reliability-timer configuration parameter and
MAY be kept longer. Future extension, such as MAY be kept longer. Future extension, such as [I-D.ietf-p2psip-rpr],
[I-D.jiang-p2psip-relay], may define mechanisms for determining when may define mechanisms for determining when this state does not need
this state does not need to be retained. to be retained.
None of the above mechanisms are required for responses, since there None of the above mechanisms are required for responses, since there
is no need to ensure that subsequent requests follow the same path. is no need to ensure that subsequent requests follow the same path.
To be precise on the responsibility of the intermediate node, suppose To be precise on the responsibility of the intermediate node, suppose
that an intermediate node, A, receives a message from node B with via that an intermediate node, A, receives a message from node B with via
list X-Y-Z. Node A MUST implement an algorithm that ensures that A list [X, Y, Z]. Node A MUST implement an algorithm that ensures that
returns a response to this request to node B with the destination A returns a response to this request to node B with the destination
list B-Z-Y-X, provided that the node to which A forwards the request list [B, Z, Y, X], provided that the node to which A forwards the
follows the same contract. Node A normally learns the Node-ID B is request follows the same contract. Node A normally learns the
using via an Attach, but a node using a certificate with a single Node-ID B is using via an Attach, but a node using a certificate with
Node-ID MAY elect to not send an Attach (see Section 3.2.1 bullet 2). a single Node-ID MAY elect to not send an Attach (see Section 3.2.1
If a node with a certificate with multiple Node-IDs attempts to route bullet 2). If a node with a certificate with multiple Node-IDs
a message other than a Ping or Attach through a node without attempts to route a message other than a Ping or Attach through a
performing an Attach, the receiving node MUST reject the request with node without performing an Attach, the receiving node MUST reject the
an Error_Forbidden error. The node MUST implement support for request with an Error_Forbidden error. The node MUST implement
returning responses to a Ping or Attach request made by a joining support for returning responses to a Ping or Attach request made by a
node Attaching to its responsible peer. joining node Attaching to its responsible peer.
6.1.3. Opaque ID 6.1.3. Opaque ID
If the first entry in the destination list is an opaque id (e.g., a If the first entry in the destination list is an opaque ID (e.g., a
compressed via list), the peer MUST replace that entry with the compressed via list), the peer MUST replace that entry with the
original via list that it replaced and then re-examine the original via list that it replaced and then re-examine the
destination list to determine which of the three cases in Section 6.1 destination list to determine which of the three cases in Section 6.1
now applies. now applies.
6.2. Symmetric Recursive Routing 6.2. Symmetric Recursive Routing
This Section defines RELOAD's symmetric recursive routing algorithm, This Section defines RELOAD's Symmetric Recursive Routing (SRR)
which is the default algorithm used by nodes to route messages algorithm, which is the default algorithm used by nodes to route
through the overlay. All implementations MUST implement this routing messages through the overlay. All implementations MUST implement
algorithm. An overlay MAY be configured to use alternative routing this routing algorithm. An overlay MAY be configured to use
algorithms, and alternative routing algorithms MAY be selected on a alternative routing algorithms, and alternative routing algorithms
per-message basis. I.e., a node in an overlay which supports SRR and MAY be selected on a per-message basis. I.e., a node in an overlay
routing algorithm XXX might use SRR some of the time and XXX some of which supports SRR and routing algorithm RPR [I-D.ietf-p2psip-rpr]
the time. might use SRR some of the time and RPR some of the time.
6.2.1. Request Origination 6.2.1. Request Origination
In order to originate a message to a given Node-ID or Resource-ID, a In order to originate a message to a given Node-ID or Resource-ID, a
node constructs an appropriate destination list. The simplest such node constructs an appropriate destination list. The simplest such
destination list is a single entry containing the Node-ID or destination list is a single entry containing the Node-ID or
Resource-ID. The resulting message uses the normal overlay routing Resource-ID. The resulting message uses the normal overlay routing
mechanisms to forward the message to that destination. The node can mechanisms to forward the message to that destination. The node can
also construct a more complicated destination list for source also construct a more complicated destination list for source
routing. routing.
skipping to change at page 41, line 38 skipping to change at page 41, line 35
digital signature over the "Message Contents" section. Note that digital signature over the "Message Contents" section. Note that
this signature can be computed without parsing the message this signature can be computed without parsing the message
contents. All messages MUST be signed by their originator. contents. All messages MUST be signed by their originator.
The following sections describe the format of each part of the The following sections describe the format of each part of the
message. message.
6.3.1. Presentation Language 6.3.1. Presentation Language
The structures defined in this document are defined using a C-like The structures defined in this document are defined using a C-like
syntax based on the presentation language used to define syntax based on the presentation language used to define TLS
TLS[RFC5246]. Advantages of this style include: [RFC5246]. Advantages of this style include:
o It familiar enough looking that most readers can grasp it quickly. o It is familiar enough looking that most readers can grasp it
quickly.
o The ability to define nested structures allows a separation o The ability to define nested structures allows a separation
between high-level and low-level message structures. between high-level and low-level message structures.
o It has a straightforward wire encoding that allows quick o It has a straightforward wire encoding that allows quick
implementation, but the structures can be comprehended without implementation, but the structures can be comprehended without
knowing the encoding. knowing the encoding.
o The ability to mechanically compile encoders and decoders. o The ability to mechanically compile encoders and decoders.
Several idiosyncrasies of this language are worth noting. Several idiosyncrasies of this language are worth noting.
o All lengths are denoted in bytes, not objects. o All lengths are denoted in bytes, not objects.
skipping to change at page 42, line 25 skipping to change at page 42, line 24
The following definitions are used throughout RELOAD and so are The following definitions are used throughout RELOAD and so are
defined here. They also provide a convenient introduction to how to defined here. They also provide a convenient introduction to how to
read the presentation language. read the presentation language.
An enum represents an enumerated type. The values associated with An enum represents an enumerated type. The values associated with
each possibility are represented in parentheses and the maximum value each possibility are represented in parentheses and the maximum value
is represented as a nameless value, for purposes of describing the is represented as a nameless value, for purposes of describing the
width of the containing integral type. For instance, Boolean width of the containing integral type. For instance, Boolean
represents a true or false: represents a true or false:
enum { false (0), true(1), (255)} Boolean; enum { false (0), true(1), (255) } Boolean;
A boolean value is either a 1 or a 0. The max value of 255 indicates A boolean value is either a 1 or a 0. The max value of 255 indicates
this is represented as a single byte on the wire. this is represented as a single 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[NodeIdLength]; typedef opaque NodeId[NodeIdLength];
A NodeId is a fixed-length structure represented as a series of A NodeId is a fixed-length structure represented as a series of
bytes, with the most significant byte first. The length is set on a bytes, with the most significant byte first. The length is set on a
skipping to change at page 43, line 17 skipping to change at page 43, line 16
"FOO" would be encoded as: 03 46 4f 4f. Note the < range > syntax "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 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 element in the on the wire encoding. The number of bytes to encode
the length on the wire is derived by range; i.e., it is the minimum the length on the wire is derived by range; i.e., it is the minimum
number of bytes which can encode the largest range value. number of bytes which can encode the largest range value.
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 {reservedAddr(0), ipv4_address (1), ipv6_address (2), enum { reservedAddr(0), ipv4_address(1), ipv6_address(2),
(255)} AddressType; (255) } AddressType;
struct { struct {
uint32 addr; uint32 addr;
uint16 port; uint16 port;
} IPv4AddrPort; } IPv4AddrPort;
struct { struct {
uint128 addr; uint128 addr;
uint16 port; uint16 port;
} IPv6AddrPort; } IPv6AddrPort;
struct { struct {
AddressType type; AddressType type;
uint8 length; uint8 length;
select (type) { select (type) {
case ipv4_address: case ipv4_address:
skipping to change at page 44, line 50 skipping to change at page 44, line 50
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]; ForwardingOption 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. This field MUST contain the value 0xd2454c4f (the string message. This field MUST contain the value 0xd2454c4f (the string
'RELO' with the high bit of the first byte set). 'RELO' with the high bit of the first byte set).
overlay: The 32 bit checksum/hash of the overlay being used. This overlay: The 32 bit checksum/hash of the overlay being used. This
MUST be formed by taking the lower 32 bits of the SHA-1 [RFC3174] MUST be formed by taking the lower 32 bits of the SHA-1 [RFC3174]
hash of the overlay name. The purpose of this field is to allow hash of the overlay name. The purpose of this field is to allow
nodes to participate in multiple overlays and to detect accidental nodes to participate in multiple overlays and to detect accidental
misconfiguration. This is not a security critical function. The misconfiguration. This is not a security critical function. The
overlay name MUST consist of a sequence of charters what would be overlay name MUST consist of a sequence of characters what would
allowable as a DNS name. be allowable as a DNS name.
configuration_sequence: The sequence number of the configuration configuration_sequence: The sequence number of the configuration
file. file.
version: The version of the RELOAD protocol being used. This is a version: The version of the RELOAD protocol being used. This is a
fixed point integer between 0.1 and 25.4. This document describes fixed point integer between 0.1 and 25.4. This document describes
version 1.0, with a value of 0x0a. [Note: Pre-RFC versions used version 1.0, with a value of 0x0a. [Note: Pre-RFC versions used
version number 0.1]. Nodes MUST reject messages with other version number 0.1]. Nodes MUST reject messages with other
versions. versions.
ttl: An 8 bit field indicating the number of iterations, or hops, a ttl: An 8 bit field indicating the number of iterations, or hops, a
message can experience before it is discarded. The TTL value MUST message can experience before it is discarded. The TTL value MUST
be decremented by one at every hop along the route the message be decremented by one at every hop along the route the message
traverses just before transmission. If a received message has a traverses just before transmission. If a received message has a
TTL of 0, and the message is not destined for the receiving node, TTL of 0, and the message is not destined for the receiving node,
then the message MUST NOT be propagated further and and a then the message MUST NOT be propagated further and a
"Error_TTL_Exceeded" error should be generated. The initial value "Error_TTL_Exceeded" error should be generated. The initial value
of the TTL SHOULD be 100 and MUST NOT exceed 100 unless defined of the TTL SHOULD be 100 and MUST NOT exceed 100 unless defined
otherwise by the overlay configuration. Implementations which otherwise by the overlay configuration. Implementations which
receive message with a TTL greater than the current value of receive message with a TTL greater than the current value of
initial-ttl (or the 100 default) MUST discard the message and send initial-ttl (or the 100 default) MUST discard the message and send
an "Error_TTL_Exceeded" error. an "Error_TTL_Exceeded" error.
fragment: This field is used to handle fragmentation. The high bit fragment: This field is used to handle fragmentation. The high bit
(0x80000000) MUST be set for historical reasons. If the next bit (0x80000000) MUST be set for historical reasons. If the next bit
(0x40000000) is set to 1, it indicates that this is the last (or (0x40000000) is set to 1, it indicates that this is the last (or
only) fragment. The next six bits (0x20000000 to 0x01000000) are only) fragment. The next six bits (0x20000000 to 0x01000000) are
reserved and SHOULD be set to zero. The remainder of the field is reserved and SHOULD be set to zero. The remainder of the field is
used to indicate the fragment offset; see Section 6.7 used to indicate the fragment offset; see Section 6.7.
length: The count in bytes of the size of the message, including the length: The count in bytes of the size of the message, including the
header. header.
transaction_id: A unique 64 bit number that identifies this transaction_id: A unique 64 bit number that identifies this
transaction and also allows receivers to disambiguate transactions transaction and also allows receivers to disambiguate transactions
which are otherwise identical. In order to provide a high which are otherwise identical. In order to provide a high
probability that transaction IDs are unique, they MUST be randomly probability that transaction IDs are unique, they MUST be randomly
generated. Responses use the same Transaction ID as the request generated. Responses use the same Transaction ID as the request
they correspond to. Transaction IDs are also used for fragment they correspond to. Transaction IDs are also used for fragment
skipping to change at page 46, line 44 skipping to change at page 46, line 44
via_list: The via_list contains the sequence of destinations through via_list: The via_list contains the sequence of destinations through
which the message has passed. The via_list starts out empty and which the message has passed. The via_list starts out empty and
grows as the message traverses each peer. grows as the message traverses each peer.
destination_list: The destination_list contains a sequence of destination_list: The destination_list contains a sequence of
destinations which the message should pass through. The destinations which the message should pass through. The
destination list is constructed by the message originator. The destination list is constructed by the message originator. The
first element in the destination list is where the message goes first element in the destination list is where the message goes
next. The list shrinks as the message traverses each listed peer. next. The list shrinks as the message traverses each listed peer.
options: Contains a series of ForwardingOptions entries. See options: Contains a series of ForwardingOption entries. See
Section 6.3.2.3. Section 6.3.2.3.
6.3.2.1. Processing Configuration Sequence Numbers 6.3.2.1. Processing Configuration Sequence Numbers
In order to be part of the overlay, a node MUST have a copy of the In order to be part of the overlay, a node MUST have a copy of the
overlay configuration document. In order to allow for configuration overlay configuration document. In order to allow for configuration
document changes, each version of the configuration document has a document changes, each version of the configuration document has a
sequence number which is monotonically increasing mod 65536. Because sequence number which is monotonically increasing mod 65535. Because
the sequence number may in principle wrap, greater than or less than the sequence number may in principle wrap, greater than or less than
are interpreted by modulo arithmetic as in TCP. are interpreted by modulo arithmetic as in TCP.
When a destination node receives a request, it MUST check that the When a destination node receives a request, it MUST check that the
configuration_sequence field is equal to its own configuration configuration_sequence field is equal to its own configuration
sequence number. If they do not match, it MUST generate an error, sequence number. If they do not match, it MUST generate an error,
either Error_Config_Too_Old or Error_Config_Too_New. In addition, if either Error_Config_Too_Old or Error_Config_Too_New. In addition, if
the configuration file in the request is too old, it MUST generate a the configuration file in the request is too old, it MUST generate a
ConfigUpdate message to update the requesting node. This allows new ConfigUpdate message to update the requesting node. This allows new
configuration documents to propagate quickly throughout the system. configuration documents to propagate quickly throughout the system.
The one exception to this rule is that if the configuration_sequence The one exception to this rule is that if the configuration_sequence
field is equal to 0xffff, and the message type is ConfigUpdate, then field is equal to 0xffff, and the message type is ConfigUpdate, then
the message MUST be accepted regardless of the receiving node's the message MUST be accepted regardless of the receiving node's
configuration sequence number. Since 65535 is a special value, peers configuration sequence number. Since 65535 is a special value, peers
sending a new configuration when the configuration sequence is sending a new configuration when the configuration sequence is
currently 65534 MUST set the configuration sequence number to 0 when currently 65534 MUST set the configuration sequence number to 0 when
they send out a new configuration. they send out a new configuration.
6.3.2.2. Destination and Via Lists 6.3.2.2. Destination and Via Lists
The destination list and via lists are sequences of Destination The destination list and via list are sequences of Destination
values: values:
enum {reserved(0), node(1), resource(2), opaque_id_type(3), enum { reserved(0), node(1), resource(2), opaque_id_type(3),
/* 128-255 not allowed */ (255) } /* 128-255 not allowed */ (255) }
DestinationType; DestinationType;
select (destination_type) { select (destination_type) {
case node: case node:
NodeId node_id; NodeId node_id;
case resource: case resource:
ResourceId resource_id; ResourceId resource_id;
skipping to change at page 48, line 38 skipping to change at page 48, line 38
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:
node node
A Node-ID. A Node-ID.
opaque opaque
A compressed list of Node-IDs and/or resources. Because this A compressed list of Node-IDs and an eventual Resource-ID.
value was compressed by one of the peers, it is only meaningful to Because this value was compressed by one of the peers, it is only
that peer and cannot be decoded by other peers. Thus, it is meaningful to that peer and cannot be decoded by other peers.
represented as an opaque string. Thus, it is 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
only appear in the final location of a destination list and MUST only appear in the final location of a destination list and MUST
NOT appear in a via list. It is meaningless to try to route NOT appear in a via list. It is meaningless to try to route
through a resource. through a resource.
One possible encoding of the 16 bit integer version as an opaque One possible encoding of the 16 bit integer version as an opaque
identifier is to encode an index into a connection table. To avoid identifier is to encode an index into a connection table. To avoid
misrouting responses in the event a response is delayed and the misrouting responses in the event a response is delayed and the
connection table entry has changed, the identifier SHOULD be split connection table entry has changed, the identifier SHOULD be split
between an index and a generation counter for that index. At between an index and a generation counter for that index. At
startup, the generation counters should be initialized to random startup, the generation counters should be initialized to random
values. An implementation could use 12 bits for the connection table values. An implementation could use 12 bits for the connection table
index and 3 bits for the generation counter. (Note that this does index and 3 bits for the generation counter. (Note that this does
not suggest a 4096 entry connection table for every node, only the not suggest a 4096 entry connection table for every peer, only the
ability to encode for a larger connection table.) When a connection ability to encode for a larger connection table.) When a connection
table slot is used for a new connection, the generation counter is table slot is used for a new connection, the generation counter is
incremented (with wrapping). Connection table slots are used on a incremented (with wrapping). Connection table slots are used on a
rotating basis to maximize the time interval between uses of the same rotating basis to maximize the time interval between uses of the same
slot for different connections. When routing a message to an entry slot for different connections. When routing a message to an entry
in the destination list encoding a connection table entry, the node in the destination list encoding a connection table entry, the peer
confirms that the generation counter matches the current generation confirms that the generation counter matches the current generation
counter of that index before forwarding the message. If it does not counter of that index before forwarding the message. If it does not
match, the message is silently dropped. match, the message is silently dropped.
6.3.2.3. Forwarding Options 6.3.2.3. Forwarding Option
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 { reservedForwarding(0), (255) } enum { reservedForwarding(0), (255) }
ForwardingOptionsType; ForwardingOptionType;
struct { struct {
ForwardingOptionsType type; ForwardingOptionType type;
uint8 flags; uint8 flags;
uint16 length; uint16 length;
select (type) { select (type) {
/* This type may be extended */ /* This type may be extended */
} option; };
} ForwardingOption; } 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.
flags flags
Three flags are defined FORWARD_CRITICAL(0x01), Three flags are defined FORWARD_CRITICAL(0x01),
DESTINATION_CRITICAL(0x02), and RESPONSE_COPY(0x04). These flags DESTINATION_CRITICAL(0x02), and RESPONSE_COPY(0x04). These flags
MUST NOT be set in a response. If the FORWARD_CRITICAL flag is MUST NOT be set in a response. If the FORWARD_CRITICAL flag is
set, any node that would forward the message but does not set, any peer that would forward the message but does not
understand this options MUST reject the request with an understand this options MUST reject the request with an
Error_Unsupported_Forwarding_Option error response. If the Error_Unsupported_Forwarding_Option error response. If the
DESTINATION_CRITICAL flag is set, any node that generates a DESTINATION_CRITICAL flag is set, any node that generates a
response to the message but does not understand the forwarding response to the message but does not understand the forwarding
option MUST reject the request with an option MUST reject the request with an
Error_Unsupported_Forwarding_Option error response. If the Error_Unsupported_Forwarding_Option error response. If the
RESPONSE_COPY flag is set, any node generating a response MUST RESPONSE_COPY flag is set, any node generating a response MUST
copy the option from the request to the response except that the copy the option from the request to the response except that the
RESPONSE_COPY, FORWARD_CRITICAL and DESTINATION_CRITICAL flags RESPONSE_COPY, FORWARD_CRITICAL and DESTINATION_CRITICAL flags
MUST be cleared. MUST be cleared.
skipping to change at page 50, line 40 skipping to change at page 50, line 40
struct { struct {
MessageExtensionType type; MessageExtensionType type;
Boolean critical; Boolean critical;
opaque extension_contents<0..2^32-1>; opaque extension_contents<0..2^32-1>;
} MessageExtension; } MessageExtension;
struct { struct {
uint16 message_code; uint16 message_code;
opaque message_body<0..2^32-1>; opaque message_body<0..2^32-1>;
MessageExtensions extensions<0..2^32-1>; MessageExtension extensions<0..2^32-1>;
} MessageContents; } MessageContents;
The contents of this structure are as follows: The contents of this structure are as follows:
message_code message_code
This indicates the message that is being sent. The code space is This indicates the message that is being sent. The code space is
broken up as follows. broken up as follows.
0 Reserved 0 Reserved
skipping to change at page 51, line 43 skipping to change at page 51, line 43
message. If critical = True and the recipient does not understand message. If critical = True and the recipient does not understand
the message, it MUST generate an Error_Unknown_Extension error. the message, it MUST generate an Error_Unknown_Extension error.
If critical = False, the recipient MAY choose to process the If critical = False, the recipient MAY choose to process the
message even if it does not understand the extension. message even if it does not understand the extension.
extension_contents extension_contents
The contents of the extension (extension-dependent). The contents of the extension (extension-dependent).
6.3.3.1. Response Codes and Response Errors 6.3.3.1. Response Codes and Response Errors
A peer processing a request returns its status in the message_code A node processing a request returns its status in the message_code
field. If the request was a success, then the message code is the field. If the request was a success, then the message code is the
response code that matches the request (i.e., the next code up). The response code that matches the request (i.e., the next code up). The
response payload is then as defined in the request/response response payload is then as defined in the request/response
descriptions. descriptions.
If the request has failed, then the message code is set to 0xffff If the request has failed, then the message code is set to 0xffff
(error) and the payload MUST be an error_response PDU, as shown (error) and the payload MUST be an error_response message, as shown
below. below.
When the message code is 0xffff, the payload MUST be an When the message code is 0xffff, the payload MUST be an
ErrorResponse. ErrorResponse.
public struct { public struct {
uint16 error_code; uint16 error_code;
opaque error_info<0..2^16-1>; opaque error_info<0..2^16-1>;
} ErrorResponse; } ErrorResponse;
skipping to change at page 52, line 31 skipping to change at page 52, line 31
this will be a UTF-8 text string providing further information this will be a UTF-8 text string providing further information
about what went wrong. Developers are encouraged to put enough about what went wrong. Developers are encouraged to put enough
diagnostic information to be useful in error_info. diagnostic information to be useful in error_info.
The following error code values are defined. The numeric values for The following error code values are defined. The numeric values for
these are defined in Section 14.9. these are defined in Section 14.9.
Error_Forbidden: The requesting node does not have permission to Error_Forbidden: The requesting node does not have permission to
make this request. make this request.
Error_Not_Found: The resource or peer cannot be found or does not Error_Not_Found: The resource or node cannot be found or does not
exist. exist.
Error_Request_Timeout: A response to the request has not been Error_Request_Timeout: A response to the request has not been
received in a suitable amount of time. The requesting node MAY received in a suitable amount of time. The requesting node MAY
resend the request at a later time. resend the request at a later time.
Error_Data_Too_Old: A store cannot be completed because the Error_Data_Too_Old: A store cannot be completed because the
storage_time precedes the existing value. storage_time precedes the existing value.
Error_Data_Too_Large: A store cannot be completed because the Error_Data_Too_Large: A store cannot be completed because the
requested object exceeds the size limits for that Kind. requested object exceeds the size limits for that Kind.
Error_Generation_Counter_Too_Low: A store cannot be completed Error_Generation_Counter_Too_Low: A store cannot be completed
because the generation counter precedes the existing value. because the generation counter precedes the existing value.
Error_Incompatible_with_Overlay: A peer receiving the request is Error_Incompatible_with_Overlay: A peer receiving the request is
using a different overlay, overlay algorithm, or hash algorithm, using a different overlay, overlay algorithm, or hash algorithm,
or some other parameter that is inconsistent with the overlay or some other parameter that is inconsistent with the overlay
configuration. configuration.
Error_Unsupported_Forwarding_Option: A peer receiving the request Error_Unsupported_Forwarding_Option: A node receiving the request
with a forwarding options flagged as critical but the peer does with a forwarding options flagged as critical but the node does
not support this option. See section Section 6.3.2.3. not support this option. See section Section 6.3.2.3.
Error_TTL_Exceeded: A peer receiving the request where the TTL got Error_TTL_Exceeded: A peer receiving the request where the TTL got
decremented to zero. See section Section 6.3.2. decremented to zero. See section Section 6.3.2.
Error_Message_Too_Large: A peer receiving the request that was too Error_Message_Too_Large: A peer receiving the request that was too
large. See section Section 6.6. large. See section Section 6.6.
Error_Response_Too_Large: A peer would have generated a response Error_Response_Too_Large: A node would have generated a response
that is too large per the max_response_length field. that is too large per the max_response_length field.
Error_Config_Too_Old: A destination peer received a request with a Error_Config_Too_Old: A destination node received a request with a
configuration sequence that's too old. See Section 6.3.2.1. configuration sequence that's too old. See Section 6.3.2.1.
Error_Config_Too_New: A destination node received a request with a Error_Config_Too_New: A destination node received a request with a
configuration sequence that's too new. See Section 6.3.2.1. configuration sequence that's too new. See Section 6.3.2.1.
Error_Unknown_Kind: A destination node received a request with an Error_Unknown_Kind: A destination peer received a request with an
unknown Kind-ID. See Section 7.4.1.2. unknown Kind-ID. See Section 7.4.1.2.
Error_In_Progress: An Attach is already in progress to this peer. Error_In_Progress: An Attach is already in progress to this peer.
See Section 6.5.1.2. See Section 6.5.1.2.
Error_Unknown_Extension: A destination node received a request with Error_Unknown_Extension: A destination node received a request with
an unknown extension. an unknown extension.
Error_Invalid_Message: Something about this message is invalid but Error_Invalid_Message: Something about this message is invalid but
it doesn't fit the other error codes. When this message is sent, it doesn't fit the other error codes. When this message is sent,
skipping to change at page 54, line 21 skipping to change at page 54, line 21
GenericCertificate certificates<0..2^16-1>; GenericCertificate certificates<0..2^16-1>;
Signature signature; Signature signature;
} SecurityBlock; } SecurityBlock;
The contents of this structure are: The contents of this structure are:
certificates certificates
A bucket of certificates. A bucket of certificates.
signature signature
A signature over the message contents. A signature.
The certificates bucket SHOULD contain all the certificates necessary The certificates bucket SHOULD contain all the certificates necessary
to verify every signature in both the message and the internal to verify every signature in both the message and the internal
message objects, except for those certificates in a root-cert element message objects, except for those certificates in a root-cert element
of the current configuration file. This is the only location in the of the current configuration file. This is the only location in the
message which contains certificates, thus allowing for only a single message which contains certificates, thus allowing for only a single
copy of each certificate to be sent. In systems that have an copy of each certificate to be sent. In systems that have an
alternative certificate distribution mechanism, some certificates MAY alternative certificate distribution mechanism, some certificates MAY
be omitted. However, unless an alternative mechanism for immediately be omitted. However, unless an alternative mechanism for immediately
generating certifcates, such as shared secret security (Section 13.4) generating certificates, such as shared secret security
is used, it is strongly RECOMMENDED that implementors include all (Section 13.4) is used, it is strongly RECOMMENDED that implementors
referenced certificates, otherwise there is the possibility that include all referenced certificates, otherwise there is the
messages may not be immediately verifiable because certificates must possibility that messages may not be immediately verifiable because
first be retrieved. certificates must first be retrieved.
NOTE TO IMPLEMENTERS: This requirement implies that a peer storing NOTE TO IMPLEMENTERS: This requirement implies that a peer storing
data is obligated to retain certificates for the data it holds data is obligated to retain certificates for the data it holds
regardless of whether it is responsible for or actually holding the regardless of whether it is responsible for or actually holding the
certificates for the Certificate Store usage. certificates for the Certificate Store usage.
Each certificate is represented by a GenericCertificate structure, Each certificate is represented by a GenericCertificate structure,
which has the following contents: which has the following contents:
type type
The type of the certificate, as defined in [RFC6091]. Only the The type of the certificate, as defined in [RFC6091]. Only the
use of X.509 certificates is defined in this draft. use of X.509 certificates is defined in this document.
certificate certificate
The encoded version of the certificate. For X.509 certificates, The encoded version of the certificate. For X.509 certificates,
it is the DER form. it is the DER form.
The signature is computed over the payload and parts of the The signature is computed over the payload and parts of the
forwarding header. The payload, in case of a Store, may contain an forwarding header. The payload, in case of a Store, may contain an
additional signature computed over a StoreReq structure. All additional signature computed over a StoreReq structure. All
signatures are formatted using the Signature element. This element signatures are formatted using the Signature element. This element
is also used in other contexts where signatures are needed. The is also used in other contexts where signatures are needed. The
input structure to the signature computation varies depending on the input structure to the signature computation varies depending on the
data element being signed. data element being signed.
enum { reservedSignerIdentity(0), enum { reservedSignerIdentity(0),
cert_hash(1), cert_hash_node_id(2), cert_hash(1), cert_hash_node_id(2),
none(3) none(3)
(255)} SignerIdentityType; (255) } SignerIdentityType;
struct { struct {
select (identity_type) { select (identity_type) {
case cert_hash; case cert_hash;
HashAlgorithm hash_alg; // From TLS HashAlgorithm hash_alg; // From TLS
opaque certificate_hash<0..2^8-1>; opaque certificate_hash<0..2^8-1>;
case cert_hash_node_id: case cert_hash_node_id:
HashAlgorithm hash_alg; // From TLS HashAlgorithm hash_alg; // From TLS
skipping to change at page 55, line 45 skipping to change at page 55, line 45
/* This structure may be extended with new types if necessary*/ /* This structure may be extended with new types if necessary*/
}; };
} SignerIdentityValue; } SignerIdentityValue;
struct { struct {
SignerIdentityType identity_type; SignerIdentityType identity_type;
uint16 length; uint16 length;
SignerIdentityValue identity[SignerIdentity.length]; SignerIdentityValue identity[SignerIdentity.length];
} SignerIdentity; } SignerIdentity;
struct { struct {
SignatureAndHashAlgorithm algorithm; // From TLS SignatureAndHashAlgorithm algorithm; // From TLS
SignerIdentity identity; SignerIdentity identity;
opaque signature_value<0..2^16-1>; opaque signature_value<0..2^16-1>;
} Signature; } Signature;
The signature construct contains the following values: The signature construct contains the following values:
algorithm algorithm
The signature algorithm in use. The algorithm definitions are The signature algorithm in use. The algorithm definitions are
found in the IANA TLS SignatureAlgorithm Registry and found in the IANA TLS SignatureAlgorithm and HashAlgorithm
HashAlgorithm registries. All implementations MUST support Registries. All implementations MUST support RSASSA-PKCS1-v1_5
RSASSA-PKCS1-v1_5 [RFC3447] signatures with SHA-256 hashes. [RFC3447] signatures with SHA-256 hashes.
identity identity
The identity used to form the signature. The identity used to form the signature.
signature_value signature_value
The value of the signature. The value of the signature.
There are two permitted identity formats, one for a certificate with There are two permitted identity formats, one for a certificate with
only one node-id and one for a certificate with multiple node-ids. only one Node-ID and one for a certificate with multiple Node-IDs.
In the first case, the cert_hash type MUST be used. The hash_alg In the first case, the cert_hash type MUST be used. The hash_alg
field is used to indicate the algorithm used to produce the hash. field is used to indicate the algorithm used to produce the hash.
The certificate_hash contains the hash of the certificate object The certificate_hash contains the hash of the certificate object
(i.e., the DER-encoded certificate). (i.e., the DER-encoded certificate).
In the second case, the cert_hash_node_id type MUST be used. The In the second case, the cert_hash_node_id type MUST be used. The
hash_alg is as in cert_hash but the cert_hash_node_id is computed hash_alg is as in cert_hash but the cert_hash_node_id is computed
over the NodeId used to sign concatenated with the certificate. over the NodeId used to sign concatenated with the certificate.
I.e., H(NodeID || certificate). The NodeId is represented without I.e., H(NodeId || certificate). The NodeId is represented without
any framing or length fields, as simple raw bytes. This is safe any framing or length fields, as simple raw bytes. This is safe
because NodeIds are fixed-length for a given overlay. because NodeIds are fixed-length for a given overlay.
For signatures over messages the input to the signature is computed For signatures over messages the input to the signature is computed
over: over:
overlay || transaction_id || MessageContents || SignerIdentity overlay || transaction_id || MessageContents || SignerIdentity
where overlay and transaction_id come from the forwarding header and where overlay and transaction_id come from the forwarding header and
|| indicates concatenation. || indicates concatenation.
skipping to change at page 57, line 7 skipping to change at page 57, line 7
reassembly if needed) the destination node MUST verify the signature reassembly if needed) the destination node MUST verify the signature
and the authorizing certificate. If the signature fails, the and the authorizing certificate. If the signature fails, the
implementation SHOULD simply drop the message and MUST not process implementation SHOULD simply drop the message and MUST not process
it. This check provides a minimal level of assurance that the it. This check provides a minimal level of assurance that the
sending node is a valid part of the overlay as well as cryptographic sending node is a valid part of the overlay as well as cryptographic
authentication of the sending node. In addition, responses MUST be authentication of the sending node. In addition, responses MUST be
checked as follows by the requesting node: checked as follows by the requesting node:
1. The response to a message sent to a specific Node-ID MUST have 1. The response to a message sent to a specific Node-ID MUST have
been sent by that Node-ID. been sent by that Node-ID.
2. The response to a message sent to a Resource-Id MUST have been 2. The response to a message sent to a Resource-ID MUST have been
sent by a Node-ID which is as close to or closer to the target sent by a Node-ID which is as close to or closer to the target
Resource-Id than any node in the requesting node's neighbor Resource-ID than any node in the requesting node's neighbor
table. table.
The second condition serves as a primitive check for responses from The second condition serves as a primitive check for responses from
wildly wrong nodes but is not a complete check. Note that in periods wildly wrong nodes but is not a complete check. Note that in periods
of churn, it is possible for the requesting node to obtain a closer of churn, it is possible for the requesting node to obtain a closer
neighbor while the request is outstanding. This will cause the neighbor while the request is outstanding. This will cause the
response to be rejected and the request to be retransmitted. response to be rejected and the request to be retransmitted.
In addition, some methods (especially Store) have additional In addition, some methods (especially Store) have additional
authentication requirements, which are described in the sections authentication requirements, which are described in the sections
skipping to change at page 58, line 33 skipping to change at page 58, line 33
The minimal JoinReq contains only the Node-ID which the sending peer The minimal JoinReq contains only the Node-ID which the sending peer
wishes to assume. Overlay algorithms MAY specify other data to wishes to assume. Overlay algorithms MAY specify other data to
appear in this request. Receivers of the JoinReq MUST verify that appear in this request. Receivers of the JoinReq MUST verify that
the joining_peer_id field matches the Node-ID used to sign the the joining_peer_id field matches the Node-ID used to sign the
message and if not MUST reject the message with an Error_Forbidden message and if not MUST reject the message with an Error_Forbidden
error. error.
Because joins may only be executed between nodes which are directly Because joins may only be executed between nodes which are directly
adjacent, receiving peers MUST verify that any JoinReq they receive adjacent, receiving peers MUST verify that any JoinReq they receive
arrives from a transport channel that is bound to the Node-Id to be arrives from a transport channel that is bound to the Node-ID to be
assumed by the joining peer.) This also prevents replay attacks assumed by the joining peer.) This also prevents replay attacks
provided that DTLS anti-replay is used. provided that DTLS anti-replay is used.
If the request succeeds, the responding peer responds with a JoinAns If the request succeeds, the responding peer responds with a JoinAns
message, as defined below: message, as defined below:
struct { struct {
opaque overlay_specific_data<0..2^16-1>; opaque overlay_specific_data<0..2^16-1>;
} JoinAns; } JoinAns;
skipping to change at page 59, line 34 skipping to change at page 59, line 34
} LeaveReq; } LeaveReq;
LeaveReq contains only the Node-ID of the leaving peer. Overlay LeaveReq contains only the Node-ID of the leaving peer. Overlay
algorithms MAY specify other data to appear in this request. algorithms MAY specify other data to appear in this request.
Receivers of the LeaveReq MUST verify that the leaving_peer_id field Receivers of the LeaveReq MUST verify that the leaving_peer_id field
matches the Node-ID used to sign the message and if not MUST reject matches the Node-ID used to sign the message and if not MUST reject
the message with an Error_Forbidden error. the message with an Error_Forbidden error.
Because leaves may only be executed between nodes which are directly Because leaves may only be executed between nodes which are directly
adjacent, receiving peers MUST verify that any LeaveReq they receive adjacent, receiving peers MUST verify that any LeaveReq they receive
arrives from a transport channel that is bound to the Node-Id to be arrives from a transport channel that is bound to the Node-ID to be
assumed by the leaving peer.) This also prevents replay attacks assumed by the leaving peer.) This also prevents replay attacks
provided that DTLS anti-replay is used. provided that DTLS anti-replay is used.
Upon receiving a Leave request, a peer MUST update its own routing Upon receiving a Leave request, a peer MUST update its own routing
table, and send the appropriate Store/Update sequences to re- table, and send the appropriate Store/Update sequences to re-
stabilize the overlay. stabilize the overlay.
6.4.2.3. Update 6.4.2.3. Update
Update is the primary overlay-specific maintenance message. It is Update is the primary overlay-specific maintenance message. It is
used by the sender to notify the recipient of the sender's view of used by the sender to notify the recipient of the sender's view of
the current state of the overlay (its routing state), and it is up to the current state of the overlay (its routing state), and it is up to
the recipient to take whatever actions are appropriate to deal with the recipient to take whatever actions are appropriate to deal with
the state change. In general, peers send Update messages to all the state change. In general, peers send Update messages to all
their adjacencies whenever they detect a topology shift. their adjacencies whenever they detect a topology shift.
When a peer receives an Attach request with the send_update flag set When a peer receives an Attach request with the send_update flag set
to "true" (Section 6.4.2.4.1, it MUST send an Update message back to to True (Section 6.4.2.4.1), it MUST send an Update message back to
the sender of the Attach request after the completion of the the sender of the Attach request after the completion of the
corresponding ICE check and TLS connection. Note that the sender of corresponding ICE check and TLS connection. Note that the sender of
a such Attach request may not have joined the overlay yet. a such Attach request may not have joined the overlay yet.
When a peer detects through an Update that it is no longer When a peer detects through an Update that it is no longer
responsible for any data value it is storing, it MUST attempt to responsible for any data value it is storing, it MUST attempt to
Store a copy to the correct node unless it knows the newly Store a copy to the correct node unless it knows the newly
responsible node already has a copy of the data. This prevents data responsible node already has a copy of the data. This prevents data
loss during large-scale topology shifts such as the merging of loss during large-scale topology shifts such as the merging of
partitioned overlays. partitioned overlays.
skipping to change at page 60, line 33 skipping to change at page 60, line 33
The RouteQuery request allows the sender to ask a peer where they The RouteQuery request allows the sender to ask a peer where they
would route a message directed to a given destination. In other would route a message directed to a given destination. In other
words, a RouteQuery for a destination X requests the Node-ID for the words, a RouteQuery for a destination X requests the Node-ID for the
node that the receiving peer would next route to in order to get to node that the receiving peer would next route to in order to get to
X. A RouteQuery can also request that the receiving peer initiate an X. A RouteQuery can also request that the receiving peer initiate an
Update request to transfer the receiving peer's routing table. Update request to transfer the receiving peer's routing table.
One important use of the RouteQuery request is to support iterative One important use of the RouteQuery request is to support iterative
routing. The sender selects one of the peers in its routing table routing. The sender selects one of the peers in its routing table
and sends it a RouteQuery message with the destination_object set to and sends it a RouteQuery message with the destination field set to
the Node-ID or Resource-ID it wishes to route to. The receiving peer the Node-ID or Resource-ID it wishes to route to. The receiving peer
responds with information about the peers to which the request would responds with information about the peers to which the request would
be routed. The sending peer MAY then use the Attach method to attach be routed. The sending peer MAY then use the Attach method to attach
to that peer(s), and repeat the RouteQuery. Eventually, the sender to that peer(s), and repeat the RouteQuery. Eventually, the sender
gets a response from a peer that is closest to the identifier in the gets a response from a peer that is closest to the identifier in the
destination_object as determined by the topology plugin. At that destination field as determined by the topology plugin. At that
point, the sender can send messages directly to that peer. point, the sender can send messages directly to that peer.
6.4.2.4.1. Request Definition 6.4.2.4.1. Request Definition
A RouteQueryReq message indicates the peer or resource that the A RouteQueryReq message indicates the peer or resource that the
requesting node is interested in. It also contains a "send_update" requesting node is interested in. It also contains a "send_update"
option allowing the requesting node to request a full copy of the option allowing the requesting node to request a full copy of the
other peer's routing table. other peer's routing table.
struct { struct {
Boolean send_update; Boolean send_update;
Destination destination; Destination destination;
opaque overlay_specific_data<0..2^16-1>; opaque overlay_specific_data<0..2^16-1>;
} RouteQueryReq; } RouteQueryReq;
The contents of the RouteQueryReq message are as follows: The contents of the RouteQueryReq message are as follows:
send_update send_update
A single byte. This may be set to "true" to indicate that the A single byte. This may be set to True to indicate that the
requester wishes the responder to initiate an Update request requester wishes the responder to initiate an Update request
immediately. Otherwise, this value MUST be set to "false". immediately. Otherwise, this value MUST be set to False.
destination destination
The destination which the requester is interested in. This may be The destination which the requester is interested in. This may be
any valid destination object, including a Node-ID, opaque ids, or any valid destination object, including a Node-ID, opaque ID, or
Resource-ID. Resource-ID.
overlay_specific_data overlay_specific_data
Other data as appropriate for the overlay. Other data as appropriate for the overlay.
6.4.2.4.2. Response Definition 6.4.2.4.2. Response Definition
A response to a successful RouteQueryReq request is a RouteQueryAns A response to a successful RouteQueryReq request is a RouteQueryAns
message. This is completely overlay specific. message. This is completely overlay specific.
6.4.2.5. Probe 6.4.2.5. Probe
Probe provides primitive "exploration" services: it allows node to Probe provides primitive "exploration" services: it allows a node to
determine which resources another node is responsible for; and it determine which resources another node is responsible for; and it
allows some discovery services using multicast, anycast, or allows some discovery services using multicast, anycast, or
broadcast. A probe can be addressed to a specific Node-ID, or the broadcast. A probe can be addressed to a specific Node-ID, or the
peer controlling a given location (by using a Resource-ID). In peer controlling a given location (by using a Resource-ID). In
either case, the target Node-IDs respond with a simple response either case, the target Node-IDs respond with a simple response
containing some status information. containing some status information.
6.4.2.5.1. Request Definition 6.4.2.5.1. Request Definition
The ProbeReq message contains a list (potentially empty) of the The ProbeReq message contains a list (potentially empty) of the
pieces of status information that the requester would like the pieces of status information that the requester would like the
responder to provide. responder to provide.
enum { reservedProbeInformation(0), responsible_set(1), enum { reservedProbeInformation(0), responsible_set(1),
num_resources(2), uptime(3), (255)} num_resources(2), uptime(3), (255) }
ProbeInformationType; ProbeInformationType;
struct { struct {
ProbeInformationType requested_info<0..2^8-1>; ProbeInformationType requested_info<0..2^8-1>;
} ProbeReq } ProbeReq;
The currently defined values for ProbeInformation are: The currently defined values for ProbeInformation are:
responsible_set responsible_set
indicates that the peer should Respond with the fraction of the indicates that the peer should Respond with the fraction of the
overlay for which the responding peer is responsible. overlay for which the responding peer is responsible.
num_resources num_resources
indicates that the peer should Respond with the number of indicates that the peer should Respond with the number of
resources currently being stored by the peer. resources currently being stored by the peer.
skipping to change at page 63, line 44 skipping to change at page 63, line 44
AppAttach: used to form application layer connections between AppAttach: used to form application layer connections between
nodes. nodes.
Ping: is a simple request/response which is used to verify Ping: is a simple request/response which is used to verify
connectivity of the target peer. connectivity of the target peer.
6.5.1. Attach 6.5.1. Attach
A node sends an Attach request when it wishes to establish a direct A node sends an Attach request when it wishes to establish a direct
TCP or UDP connection to another node for the purpose of sending TCP or UDP connection to another node for the purpose of sending
RELOAD messages. A client that can establish a connection directly RELOAD messages. A client that can establish a connection directly
need not send an attach as described in the second bullet of need not send an Attach as described in the second bullet of
Section 3.2.1 Section 3.2.1
As described in Section 6.1, an Attach may be routed to either a As described in Section 6.1, an Attach may be routed to either a
Node-ID or to a Resource-ID. An Attach routed to a specific Node-ID Node-ID or to a Resource-ID. An Attach routed to a specific Node-ID
will fail if that node is not reached. An Attach routed to a will fail if that node is not reached. An Attach routed to a
Resource-ID will establish a connection with the peer currently Resource-ID will establish a connection with the peer currently
responsible for that Resource-ID, which may be useful in establishing responsible for that Resource-ID, which may be useful in establishing
a direct connection to the responsible peer for use with frequent or a direct connection to the responsible peer for use with frequent or
large resource updates. large resource updates.
skipping to change at page 65, line 23 skipping to change at page 65, line 23
opaque name<0..2^16-1>; opaque name<0..2^16-1>;
opaque value<0..2^16-1>; opaque value<0..2^16-1>;
} IceExtension; } IceExtension;
struct { struct {
IpAddressPort addr_port; IpAddressPort addr_port;
OverlayLinkType overlay_link; OverlayLinkType 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 */ ; /* Empty */
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>;
Boolean send_update; Boolean send_update;
} AttachReqAns; } AttachReqAns;
The values contained in AttachReqAns are: The values contained in AttachReqAns are:
ufrag ufrag
skipping to change at page 66, line 20 skipping to change at page 66, line 20
the Attach response). the Attach response).
candidates candidates
One or more ICE candidate values, as described below. One or more ICE candidate values, as described below.
send_update send_update
Has the same meaning as the send_update field in RouteQueryReq. Has the same meaning as the send_update field in RouteQueryReq.
Each ICE candidate is represented as an IceCandidate structure, which Each ICE candidate is represented as an IceCandidate structure, which
is a direct translation of the information from the ICE string is a direct translation of the information from the ICE string
structures, with the exception of the component ID. Since there is structures, with the exception of the component ID. Since there is
only one component, it is always 1, and thus left out of the PDU. only one component, it is always 1, and thus left out of the
The remaining values are specified as follows: structure. The remaining values are specified as follows:
addr_port addr_port
corresponds to the connection-address and port productions. corresponds to the connection-address and port productions.
overlay_link overlay_link
corresponds to the OverlayLinkType production, Overlay Link corresponds to the OverlayLinkType production, Overlay Link
protocols used with No-ICE MUST specify "No-ICE" in their protocols used with No-ICE MUST specify "No-ICE" in their
description. Future overlay link values can be added be defining description. Future overlay link values can be added by defining
new OverlayLinkType values in the IANA registry in Section 14.10. new OverlayLinkType values in the IANA registry in Section 14.10.
Future extensions to the encapsulation or framing that provide for Future extensions to the encapsulation or framing that provide for
backward compatibility with that specified by a previously defined backward compatibility with that specified by a previously defined
OverlayLinkType values MUST use that previous value. OverlayLinkType values MUST use that previous value.
OverlayLinkType protocols are defined in Section 6.6 OverlayLinkType protocols are defined in Section 6.6
A single AttachReqAns MUST NOT include both candidates whose A single AttachReqAns MUST NOT include both candidates whose
OverlayLinkType protocols use ICE (the default) and candidates OverlayLinkType protocols use ICE (the default) and candidates
that specify "No-ICE". that specify "No-ICE".
foundation foundation
corresponds to the foundation production. corresponds to the foundation production.
priority priority
corresponds to the priority production. corresponds to the priority production.
type type
corresponds to the cand-type production. corresponds to the cand-type production.
rel_addr_port rel_addr_port
corresponds to the rel-addr and rel-port productions. Only corresponds to the rel-addr and rel-port productions. Only
present for type "relay". present for types "relay", "srflx" and "prflx".
extensions extensions
ICE extensions. The name and value fields correspond to binary ICE extensions. The name and value fields correspond to binary
translations of the equivalent fields in the ICE extensions. translations of the equivalent fields in the ICE extensions.
These values should be generated using the procedures described in These values should be generated using the procedures described in
Section 6.5.1.3. Section 6.5.1.3.
6.5.1.2. Response Definition 6.5.1.2. Response Definition
skipping to change at page 67, line 40 skipping to change at page 67, line 40
o If it has already sent an Attach request to but not yet received o If it has already sent an Attach request to but not yet received
the response from the originating peer of this Attach request, it the response from the originating peer of this Attach request, it
SHOULD apply the following tie-breaker heuristic to determine how SHOULD apply the following tie-breaker heuristic to determine how
to handle this Attach request and the incomplete Attach request it to handle this Attach request and the incomplete Attach request it
has sent out: has sent out:
* If the peer's own Node-ID is smaller when compared as big- * If the peer's own Node-ID is smaller when compared as big-
endian unsigned integers, it MUST cancel its own incomplete endian unsigned integers, it MUST cancel its own incomplete
Attach request. It MUST then process this Attach request, Attach request. It MUST then process this Attach request,
generate an AttachReqAns response, and proceed with the generate an AttachReqAns response, and proceed with the
corresponding ICE check. corresponding ICE check.
* If the peer's own Node-ID is larger when compared as big-endien * If the peer's own Node-ID is larger when compared as big-endian
unsigned integers, it MUST generate an Error_In_Progress error unsigned integers, it MUST generate an Error_In_Progress error
to this Attach request, then proceed to wait for and complete to this Attach request, then proceed to wait for and complete
the Attach and the corresponding ICE check it has originated. the Attach and the corresponding ICE check it has originated.
o If the peer is overloaded or detects some other kind of error, it o If the peer is overloaded or detects some other kind of error, it
MAY generate an error instead of an AttachReqAns. MAY generate an error instead of an AttachReqAns.
When a peer receives an Attach response, it SHOULD parse the response When a peer receives an Attach response, it SHOULD parse the response
and begin its own ICE checks. and begin its own ICE checks.
6.5.1.3. Using ICE With RELOAD 6.5.1.3. Using ICE With RELOAD
skipping to change at page 69, line 10 skipping to change at page 69, line 10
outside its NAT. However, if there are more NATs involved, it may outside its NAT. However, if there are more NATs involved, it may
learn additional server reflexive addresses (which vary based on learn additional server reflexive addresses (which vary based on
where in the topology the STUN server is). To maximize the chance of where in the topology the STUN server is). To maximize the chance of
achieving a direct connection, a peer SHOULD group other peers by the achieving a direct connection, a peer SHOULD group other peers by the
peer-reflexive addresses it discovers through them. It SHOULD then peer-reflexive addresses it discovers through them. It SHOULD then
select one peer from each group to use as a STUN server for future select one peer from each group to use as a STUN server for future
connections. connections.
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 MUST be list of STUN servers and a new server from the same group MUST be
selected unless there are no others servers in the group in which selected unless there are no others servers in the group in which
case some other peer MAY be used. case some other peer MAY be used.
6.5.1.5. Gathering Candidates 6.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 [RFC5245]. gathering candidates as described in Section 4 of ICE [RFC5245].
RELOAD utilizes a single component. Consequently, gathering for RELOAD utilizes a single component. Consequently, gathering for
these "streams" requires a single component. In the case where a these "streams" requires a single component. In the case where a
skipping to change at page 69, line 45 skipping to change at page 69, line 45
whether or not these Overlay Link protocols can be used. An overlay whether or not these Overlay Link protocols can be used. An overlay
MUST be either all ICE or all No-ICE. MUST be either all ICE or all No-ICE.
No-ICE will not work in all of the scenarios where ICE would work, No-ICE will not work in all of the scenarios where ICE would work,
but in some cases, particularly those with no NATs or firewalls, it but in some cases, particularly those with no NATs or firewalls, it
will work. will work.
6.5.1.6. Prioritizing Candidates 6.5.1.6. Prioritizing Candidates
However, standardization of additional protocols for use with ICE is However, standardization of additional protocols for use with ICE is
expected, including TCP[I-D.ietf-mmusic-ice-tcp] and protocols such expected, including TCP [RFC6544] and protocols such as SCTP and
as SCTP and DCCP. UDP encapsulations for SCTP and DCCP would expand DCCP. UDP encapsulations for SCTP and DCCP would expand the
the available Overlay Link protocols available for RELOAD. When available Overlay Link protocols available for RELOAD. When
additional protocols are available, the following prioritization is additional protocols are available, the following prioritization is
RECOMMENDED: RECOMMENDED:
o Highest priority is assigned to protocols that offer well- o Highest priority is assigned to protocols that offer well-
understood congestion and flow control without head of line understood congestion and flow control without head of line
blocking. For example, SCTP without message ordering, DCCP, or blocking. For example, SCTP without message ordering, DCCP, or
those protocols encapsulated using UDP. those protocols encapsulated using UDP.
o Second highest priority is assigned to protocols that offer well- o Second highest priority is assigned to protocols that offer well-
understood congestion and flow control but have head of line understood congestion and flow control but have head of line
blocking such as TCP. blocking such as TCP.
skipping to change at page 72, line 31 skipping to change at page 72, line 31
matches the identity of the other peer as found in the Attach matches the identity of the other peer as found in the Attach
message. Once the TLS or DTLS signaling is complete, the application message. Once the TLS or DTLS signaling is complete, the application
protocol is free to use the connection. protocol is free to use the connection.
The concept of a previous selected pair for a component does not The concept of a previous selected pair for a component does not
apply to RELOAD, since ICE restarts are not possible with RELOAD. apply to RELOAD, since ICE restarts are not possible with RELOAD.
6.5.1.14. Receiving Media 6.5.1.14. Receiving Media
An agent MUST be prepared to receive packets for the application An agent MUST be prepared to receive packets for the application
protocol (TLS or DTLS carrying RELOAD, SIP or anything else) at any protocol (TLS or DTLS carrying RELOAD) at any time. The jitter and
time. The jitter and RTP considerations in Section 11 of ICE do not RTP considerations in Section 11 of ICE do not apply to RELOAD.
apply to RELOAD.
6.5.2. AppAttach 6.5.2. AppAttach
A node sends an AppAttach request when it wishes to establish a A node sends an AppAttach request when it wishes to establish a
direct connection to another node for the purposes of sending direct connection to another node for the purposes of sending
application layer messages. AppAttach is nearly identical to Attach, application layer messages. AppAttach is nearly identical to Attach,
except for the purpose of the connection: it is used to transport except for the purpose of the connection: it is used to transport
non-RELOAD "media". A separate request is used to avoid implementor non-RELOAD "media". A separate request is used to avoid implementor
confusion between the two methods (this was found to be a real confusion between the two methods (this was found to be a real
problem with initial implementations). The AppAttach request and its problem with initial implementations). The AppAttach request and its
response contain an application attribute, which indicates what response contain an application attribute, which indicates what
protocol is to be run over the connection. protocol is to be run over the connection.
6.5.2.1. Request Definition 6.5.2.1. Request Definition
An AppAttachReq message contains the requesting node's ICE connection An AppAttachReq message contains the requesting node's ICE connection
parameters formatted into a binary structure. parameters formatted into a binary structure.
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>;
uint16 application; uint16 application;
opaque role<0..2^8-1>; opaque role<0..2^8-1>;
IceCandidate candidates<0..2^16-1>; IceCandidate candidates<0..2^16-1>;
} AppAttachReq; } AppAttachReq;
The values contained in AppAttachReq and AppAttachAns are: The values contained in AppAttachReq and AppAttachAns are:
ufrag ufrag
skipping to change at page 73, line 46 skipping to change at page 73, line 46
6.5.2.2. Response Definition 6.5.2.2. Response Definition
If a peer receives an AppAttach request, it SHOULD process the If a peer receives an AppAttach request, it SHOULD process the
request and generate its own response with a AppAttachAns. It should request and generate its own response with a AppAttachAns. It should
then begin ICE checks. When a peer receives an AppAttach response, then begin ICE checks. When a peer receives an AppAttach response,
it SHOULD parse the response and begin its own ICE checks. If the it SHOULD parse the response and begin its own ICE checks. If the
application ID is not supported, the peer MUST reply with an application ID is not supported, the peer MUST reply with an
Error_Not_Found error. Error_Not_Found error.
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>;
uint16 application; uint16 application;
opaque role<0..2^8-1>; opaque role<0..2^8-1>;
IceCandidate candidates<0..2^16-1>; IceCandidate candidates<0..2^16-1>;
} AppAttachAns; } AppAttachAns;
The meaning of the fields is the same as in the AppAttachReq. The meaning of the fields is the same as in the AppAttachReq.
6.5.3. Ping 6.5.3. Ping
Ping is used to test connectivity along a path. A ping can be Ping is used to test connectivity along a path. A ping can be
addressed to a specific Node-ID, to the peer controlling a given addressed to a specific Node-ID, to the peer controlling a given
location (by using a resource ID), or to the broadcast Node-ID location (by using a Resource-ID), or to the broadcast Node-ID
(2^128-1). (2^128-1).
6.5.3.1. Request Definition 6.5.3.1. Request Definition
struct { struct {
opaque<0..2^16-1> padding; opaque<0..2^16-1> padding;
} PingReq } PingReq;
The Ping request is empty of meaningful contents. However, it may The Ping request is empty of meaningful contents. However, it may
contain up to 65535 bytes of padding to facilitate the discovery of contain up to 65535 bytes of padding to facilitate the discovery of
overlay maximum packet sizes. overlay maximum packet sizes.
6.5.3.2. Response Definition 6.5.3.2. Response Definition
A successful PingAns response contains the information elements A successful PingAns response contains the information elements
requested by the peer. requested by the peer.
skipping to change at page 76, line 13 skipping to change at page 76, line 13
The contents of the configuration document. The contents of the configuration document.
kinds (type==kind) kinds (type==kind)
One or more XML kind-block productions (see Section 11.1). These One or more XML kind-block productions (see Section 11.1). These
MUST be encoded with UTF-8 and assume a default namespace of MUST be encoded with UTF-8 and assume a default namespace of
"urn:ietf:params:xml:ns:p2p:config-base". "urn:ietf:params:xml:ns:p2p:config-base".
6.5.4.2. Response Definition 6.5.4.2. Response Definition
struct { struct {
} ConfigUpdateAns } ConfigUpdateAns;
If the ConfigUpdateReq is of type "config" it MUST only be processed If the ConfigUpdateReq is of type "config" it MUST only be processed
if all the following are true: if all the following are true:
o The sequence number in the document is greater than the current o The sequence number in the document is greater than the current
configuration sequence number. configuration sequence number.
o The configuration document is correctly digitally signed (see o The configuration document is correctly digitally signed (see
Section 11 for details on signatures. Section 11 for details on signatures.
Otherwise appropriate errors MUST be generated. Otherwise appropriate errors MUST be generated.
If the ConfigUpdateReq is of type "kind" it MUST only be processed if If the ConfigUpdateReq is of type "kind" it MUST only be processed if
skipping to change at page 77, line 9 skipping to change at page 77, line 9
RELOAD can use multiple Overlay Link protocols to send its messages. RELOAD can use multiple Overlay Link protocols to send its messages.
Because ICE is used to establish connections (see Section 6.5.1.3), Because ICE is used to establish connections (see Section 6.5.1.3),
RELOAD nodes are able to detect which Overlay Link protocols are RELOAD nodes are able to detect which Overlay Link protocols are
offered by other nodes and establish connections between them. Any offered by other nodes and establish connections between them. Any
link protocol needs to be able to establish a secure, authenticated link protocol needs to be able to establish a secure, authenticated
connection and to provide data origin authentication and message connection and to provide data origin authentication and message
integrity for individual data elements. RELOAD currently supports integrity for individual data elements. RELOAD currently supports
three Overlay Link protocols: three Overlay Link protocols:
o DTLS [RFC4347] over UDP with Simple Reliability (SR) o DTLS [RFC6347] over UDP with Simple Reliability (SR)
(OverlayLinkType=DTLS-UDP-SR (OverlayLinkType=DTLS-UDP-SR
o TLS [RFC5246] over TCP with Framing Header, No-ICE o TLS [RFC5246] over TCP with Framing Header, No-ICE
(OverlayLinkType=TLS-TCP-FH-NO-ICE (OverlayLinkType=TLS-TCP-FH-NO-ICE
o DTLS [RFC4347] over UDP with SR, No-ICE (OverlayLinkType=DTLS-UDP- o DTLS [RFC6347] over UDP with SR, No-ICE (OverlayLinkType=DTLS-UDP-
SR-NO-ICE) SR-NO-ICE)
Note that although UDP does not properly have "connections", both TLS Note that although UDP does not properly have "connections", both TLS
and DTLS have a handshake which establishes a similar, stateful and DTLS have a handshake which establishes a similar, stateful
association, and we simply refer to these as "connections" for the association, and we simply refer to these as "connections" for the
purposes of this document. purposes of this document.
If a peer receives a message that is larger than value of max- If a peer receives a message that is larger than value of max-
message-size defined in the overlay configuration, the peer SHOULD message-size defined in the overlay configuration, the peer SHOULD
send an Error_Message_Too_Large error and then close the TLS or DTLS send an Error_Message_Too_Large error and then close the TLS or DTLS
skipping to change at page 78, line 15 skipping to change at page 78, line 15
6.6.1. Future Overlay Link Protocols 6.6.1. Future Overlay Link Protocols
It is possible to define new link-layer protocols and apply them to a It is possible to define new link-layer protocols and apply them to a
new overlay using the "overlay-link-protocol" configuration directive new overlay using the "overlay-link-protocol" configuration directive
(see Section 11.1.). However, any new protocols MUST meet the (see Section 11.1.). However, any new protocols MUST meet the
following requirements. following requirements.
Endpoint authentication When a node forms an association with Endpoint authentication When a node forms an association with
another endpoint, it MUST be possible to cryptographically verify another endpoint, it MUST be possible to cryptographically verify
that the endpoint has a given Node-Id. that the endpoint has a given Node-ID.
Traffic origin authentication and integrity When a node receives Traffic origin authentication and integrity When a node receives
traffic from another endpoint, it MUST be possible to traffic from another endpoint, it MUST be possible to
cryptographically verify that the traffic came from a given cryptographically verify that the traffic came from a given
association and that it has not been modified in transit from the association and that it has not been modified in transit from the
other endpoint in the association. The overlay link protocol MUST other endpoint in the association. The overlay link protocol MUST
also provide replay prevention/detection. also provide replay prevention/detection.
Traffic confidentiality When a node sends traffic to another Traffic confidentiality When a node sends traffic to another
endpoint, it MUST NOT be possible for a third party not involved endpoint, it MUST NOT be possible for a third party not involved
skipping to change at page 79, line 7 skipping to change at page 79, line 7
the HIP base exchange. We anticipate that this would require a the HIP base exchange. We anticipate that this would require a
mapping between ORCHIDs and NodeIds. mapping between ORCHIDs and NodeIds.
o How to carry the HIP I1 and I2 messages. o How to carry the HIP I1 and I2 messages.
o How to carry RELOAD messages over HIP. o How to carry RELOAD messages over HIP.
[I-D.ietf-hip-reload-instance] documents work in progress on using [I-D.ietf-hip-reload-instance] documents work in progress on using
RELOAD with the HIP BONE. RELOAD with the HIP BONE.
6.6.1.2. ICE-TCP 6.6.1.2. ICE-TCP
The ICE-TCP draft [I-D.ietf-mmusic-ice-tcp] allows TCP to be The ICE-TCP RFC [RFC6544] allows TCP to be supported as an Overlay
supported as an Overlay Link protocol that can be added using ICE. Link protocol that can be added using ICE.
6.6.1.3. Message-oriented Transports 6.6.1.3. Message-oriented Transports
Modern message-oriented transports offer high performance, good Modern message-oriented transports offer high performance, good
congestion control, and avoid head of line blocking in case of lost congestion control, and avoid head of line blocking in case of lost
data. These characteristics make them preferable as underlying data. These characteristics make them preferable as underlying
transport protocols for RELOAD links. SCTP without message ordering transport protocols for RELOAD links. SCTP without message ordering
and DCCP are two examples of such protocols. However, currently they and DCCP are two examples of such protocols. However, currently they
are not well-supported by commonly available NATs, and specifications are not well-supported by commonly available NATs, and specifications
for ICE session establishment are not available. for ICE session establishment are not available.
skipping to change at page 80, line 5 skipping to change at page 80, line 5
In order to support unreliable links and to allow for quick detection In order to support unreliable links and to allow for quick detection
of link failures when using reliable end-to-end transports, each of link failures when using reliable end-to-end transports, each
message is wrapped in a very simple framing layer (FramedMessage) message is wrapped in a very simple framing layer (FramedMessage)
which is only used for each hop. This layer contains a sequence which is only used for each hop. This layer contains a sequence
number which can then be used for ACKs. The same header is used for number which can then be used for ACKs. The same header is used for
both reliable and unreliable transports for simplicity of both reliable and unreliable transports for simplicity of
implementation. implementation.
The definition of FramedMessage is: The definition of FramedMessage is:
enum { data(128), ack(129), (255)} FramedMessageType; enum { data(128), ack(129), (255) } FramedMessageType;
struct { struct {
FramedMessageType type; FramedMessageType type;
select (type) { select (type) {
case data: case data:
uint32 sequence; uint32 sequence;
opaque message<0..2^24-1>; opaque message<0..2^24-1>;
case ack: case ack:
skipping to change at page 84, line 33 skipping to change at page 84, line 33
fragments that are no larger than the PMTU of the next overlay link fragments that are no larger than the PMTU of the next overlay link
minus 32 bytes. This is to allow the via list to grow before further minus 32 bytes. This is to allow the via list to grow before further
fragmentation is required. fragmentation is required.
Note that this fragmentation is not optimal for the end-to-end path - Note that this fragmentation is not optimal for the end-to-end path -
a message may be refragmented multiple times as it traverses the a message may be refragmented multiple times as it traverses the
overlay but is only assembled at the final destination. This option overlay but is only assembled at the final destination. This option
has been chosen as it is far easier to implement than e2e PMTU has been chosen as it is far easier to implement than e2e PMTU
discovery across an ever-changing overlay, and it effectively discovery across an ever-changing overlay, and it effectively
addresses the reliability issues of relying on IP-layer addresses the reliability issues of relying on IP-layer
fragmentation. However, PING can be used to allow e2e PMTU discovery fragmentation. However, Ping can be used to allow e2e PMTU discovery
to be implemented if desired. to be implemented if desired.
Upon receipt of a fragmented message by the intended peer, the peer Upon receipt of a fragmented message by the intended peer, the peer
holds the fragments in a holding buffer until the entire message has holds the fragments in a holding buffer until the entire message has
been received. The message is then reassembled into a single message been received. The message is then reassembled into a single message
and processed. In order to mitigate denial of service attacks, and processed. In order to mitigate denial of service attacks,
receivers SHOULD time out incomplete fragments after maximum request receivers SHOULD time out incomplete fragments after maximum request
lifetime (15 seconds). Note this time was derived from looking at lifetime (15 seconds). Note this time was derived from looking at
the end to end retransmission time and saving fragments long enough the end to end retransmission time and saving fragments long enough
for the full end to end retransmissions to take place. Ideally the for the full end to end retransmissions to take place. Ideally the
skipping to change at page 85, line 43 skipping to change at page 85, line 43
uint32 length; uint32 length;
uint64 storage_time; uint64 storage_time;
uint32 lifetime; uint32 lifetime;
StoredDataValue value; StoredDataValue value;
Signature signature; Signature signature;
} StoredData; } StoredData;
The contents of this structure are as follows: The contents of this structure are as follows:
length length
The size of the StoredData structure in octets excluding the size The size of the StoredData structure in bytes excluding the size
of length itself. of length itself.
storage_time storage_time
The time when the data was stored represented as the number of The time when the data was stored represented as the number of
milliseconds elapsed since midnight Jan 1, 1970 UTC not counting milliseconds elapsed since midnight Jan 1, 1970 UTC not counting
leap seconds. This will have the same values for seconds as leap seconds. This will have the same values for seconds as
standard UNIX time or POSIX time. More information can be found standard UNIX time or POSIX time. More information can be found
at [UnixTime]. Any attempt to store a data value with a storage at [UnixTime]. Any attempt to store a data value with a storage
time before that of a value already stored at this location MUST time before that of a value already stored at this location MUST
generate a Error_Data_Too_Old error. This prevents rollback generate a Error_Data_Too_Old error. This prevents rollback
skipping to change at page 86, line 43 skipping to change at page 86, line 43
The data value itself, as described in Section 7.2. The data value itself, as described in Section 7.2.
signature signature
A signature as defined in Section 7.1. A signature as defined in Section 7.1.
Each Resource-ID specifies a single location in the Overlay Instance. Each Resource-ID specifies a single location in the Overlay Instance.
However, each location may contain multiple StoredData values However, each location may contain multiple StoredData values
distinguished by Kind-ID. The definition of a Kind describes both distinguished by Kind-ID. The definition of a Kind describes both
the data values which may be stored and the data model of the data. the data values which may be stored and the data model of the data.
Some data models allow multiple values to be stored under the same Some data models allow multiple values to be stored under the same
Kind-ID. Section Section 7.2 describes the available data models. Kind-ID. Section 7.2 describes the available data models. Thus, for
Thus, for instance, a given Resource-ID might contain a single-value instance, a given Resource-ID might contain a single-value element
element stored under Kind-ID X and an array containing multiple stored under Kind-ID X and an array containing multiple values stored
values stored under Kind-ID Y. under Kind-ID Y.
7.1. Data Signature Computation 7.1. Data Signature Computation
Each StoredData element is individually signed. However, the Each StoredData element is individually signed. However, the
signature also must be self-contained and cover the Kind-ID and signature also must be self-contained and cover the Kind-ID and
Resource-ID even though they are not present in the StoredData Resource-ID even though they are not present in the StoredData
structure. The input to the signature algorithm is: structure. The input to the signature algorithm is:
resource_id || kind || storage_time || StoredDataValue || resource_id || kind || storage_time || StoredDataValue ||
SignerIdentity SignerIdentity
Where || indicates concatenation. Where || indicates concatenation.
Where these values are: Where these values are:
resource_id resource_id
The resource ID where this data is stored. The Resource-ID where this data is stored.
kind kind
The Kind-ID for this data. The Kind-ID for this data.
storage_time storage_time
The contents of the storage_time data value. The contents of the storage_time data value.
StoredDataValue StoredDataValue
The contents of the stored data value, as described in the The contents of the stored data value, as described in the
previous sections. previous sections.
SignerIdentity SignerIdentity
The signer identity as defined in Section 6.3.4. The signer identity as defined in Section 6.3.4.
Once the signature has been computed, the signature is represented Once the signature has been computed, the signature is represented
using a signature element, as described in Section 6.3.4. using a signature element, as described in Section 6.3.4.
skipping to change at page 87, line 50 skipping to change at page 87, line 50
7.2. Data Models 7.2. Data Models
The protocol currently defines the following data models: The protocol currently defines the following data models:
o single value o single value
o array o array
o dictionary o dictionary
These are represented with the StoredDataValue structure. The actual These are represented with the StoredDataValue structure. The actual
dataModel is known from the Kind being stored. data model is known from the Kind being stored.
struct { struct {
Boolean exists; Boolean exists;
opaque value<0..2^32-1>; opaque value<0..2^32-1>;
} DataValue; } DataValue;
struct { struct {
select (dataModel) { select (DataModel) {
case single_value: case single_value:
DataValue single_value_entry; DataValue single_value_entry;
case array: case array:
ArrayEntry array_entry; ArrayEntry array_entry;
case dictionary: case dictionary:
DictionaryEntry dictionary_entry; DictionaryEntry dictionary_entry;
/* This structure may be extended */ /* This structure may be extended */
skipping to change at page 91, line 50 skipping to change at page 91, line 50
uint64 generation_counter; uint64 generation_counter;
StoredData values<0..2^32-1>; StoredData values<0..2^32-1>;
} StoreKindData; } StoreKindData;
struct { struct {
ResourceId resource; ResourceId resource;
uint8 replica_number; uint8 replica_number;
StoreKindData kind_data<0..2^32-1>; StoreKindData kind_data<0..2^32-1>;
} StoreReq; } StoreReq;
A single Store request stores data of a number of kinds to a single A single Store request stores data of a number of Kinds to a single
resource location. The contents of the structure are: resource location. The contents of the structure are:
resource resource
The resource to store at. The resource to store at.
replica_number replica_number
The number of this replica. When a storing peer saves replicas to The number of this replica. When a storing peer saves replicas to
other peers each peer is assigned a replica number starting from 1 other peers each peer is assigned a replica number starting from 1
and sent in the Store message. This field is set to 0 when a node and sent in the Store message. This field is set to 0 when a node
is storing its own data. This allows peers to distinguish replica is storing its own data. This allows peers to distinguish replica
skipping to change at page 93, line 7 skipping to change at page 93, line 7
o The Kind-ID is known and supported. o The Kind-ID is known and supported.
o The signatures over each individual data element (if any) are o The signatures over each individual data element (if any) are
valid. If this check fails, the request MUST be rejected with an valid. If this check fails, the request MUST be rejected with an
Error_Forbidden error. Error_Forbidden error.
o Each element is signed by a credential which is authorized to o Each element is signed by a credential which is authorized to
write this Kind at this Resource-ID. If this check fails, the write this Kind at this Resource-ID. If this check fails, the
request MUST be rejected with an Error_Forbidden error. request MUST be rejected with an Error_Forbidden error.
o For original (non-replica) stores, the StoreReq is signed by a o For original (non-replica) stores, the StoreReq is signed by a
credential which is authorized to write this Kind at this credential which is authorized to write this Kind at this
Resource-Id. If this check fails, the request MUST be rejected Resource-ID. If this check fails, the request MUST be rejected
with an Error_Forbidden error. with an Error_Forbidden error.
o For replica stores, the StoreReq is signed by a Node-Id which is a o For replica stores, the StoreReq is signed by a Node-ID which is a
plausible node to either have originally stored the value or in plausible node to either have originally stored the value or in
the replica set. What this means is overlay specific, but in the the replica set. What this means is overlay specific, but in the
case of the Chord based DHT defined in this specification, replica case of the Chord based DHT defined in this specification, replica
StoreReqs MUST come from nodes which are either in the known StoreReqs MUST come from nodes which are either in the known
replica set for a given resource or which are closer than some replica set for a given resource or which are closer than some
node in the replica set. If this check fails, the request MUST be node in the replica set. If this check fails, the request MUST be
rejected with an Error_Forbidden error. rejected with an Error_Forbidden error.
o For original (non-replica) stores, the peer MUST check that if the o For original (non-replica) stores, the peer MUST check that if the
generation counter is non-zero, it equals the current value of the generation counter is non-zero, it equals the current value of the
generation counter for this Kind. This feature allows the generation counter for this Kind. This feature allows the
skipping to change at page 94, line 12 skipping to change at page 94, line 12
downward to reflect the amount of time the value was stored at the downward to reflect the amount of time the value was stored at the
peer. The adjustment SHOULD be implemented by an algorithm peer. The adjustment SHOULD be implemented by an algorithm
equivalent to the following: at the time the peer initially receives equivalent to the following: at the time the peer initially receives
the StoreReq it notes the local time T. When it then attempts to do a the StoreReq it notes the local time T. When it then attempts to do a
StoreReq to another node it should decrement the lifetime value by StoreReq to another node it should decrement the lifetime value by
the difference between the current local time and T. the difference between the current local time and T.
Unless otherwise specified by the usage, if a peer attempts to store Unless otherwise specified by the usage, if a peer attempts to store
data previously stored by another node (e.g., for replicas or data previously stored by another node (e.g., for replicas or
topology shifts) and that store fails with either an topology shifts) and that store fails with either an
Error_Generation_Counter_Too_Low or an Error_Data_Too old error, the Error_Generation_Counter_Too_Low or an Error_Data_Too_Old error, the
peer MUST fetch the newer data from the peer generating the error and peer MUST fetch the newer data from the peer generating the error and
use that to replace its own copy. This rule allows resynchronization use that to replace its own copy. This rule allows resynchronization
after partitions heal. after partitions heal.
The properties of stores for each data model are as follows: The properties of stores for each data model are as follows:
Single-value: Single-value:
A store of a new single-value element creates the element if it A store of a new single-value element creates the element if it
does not exist and overwrites any existing value with the new does not exist and overwrites any existing value with the new
value. value.
Array: Array:
A store of an array entry replaces (or inserts) the given value at A store of an array entry replaces (or inserts) the given value at
the location specified by the index. Because arrays are sparse, a the location specified by the index. Because arrays are sparse, a
store past the end of the array extends it with nonexistent values store past the end of the array extends it with nonexistent values
(exists=False) as required. A store at index 0xffffffff places (exists = False) as required. A store at index 0xffffffff places
the new value at the end of the array regardless of the length of the new value at the end of the array regardless of the length of
the array. The resulting StoredData has the correct index value the array. The resulting StoredData has the correct index value
when it is subsequently fetched. when it is subsequently fetched.
Dictionary: Dictionary:
A store of a dictionary entry replaces (or inserts) the given A store of a dictionary entry replaces (or inserts) the given
value at the location specified by the dictionary key. value at the location specified by the dictionary key.
The following figure shows the relationship between these structures The following figure shows the relationship between these structures
for an example store which stores the following values at resource for an example store which stores the following values at resource
skipping to change at page 96, line 16 skipping to change at page 96, line 16
kind kind
The Kind-ID being represented. The Kind-ID being represented.
generation_counter generation_counter
The current value of the generation counter for that Kind-ID. The current value of the generation counter for that Kind-ID.
replicas replicas
The list of other peers at which the data was/will be replicated. The list of other peers at which the data was/will be replicated.
In overlays and applications where the responsible peer is In overlays and applications where the responsible peer is
intended to store redundant copies, this allows the storing peer intended to store redundant copies, this allows the storing node
to independently verify that the replicas have in fact been to independently verify that the replicas have in fact been
stored. It does this verification by using the Stat method (see stored. It does this verification by using the Stat method (see
Section 7.4.3). Note that the storing peer is not required to Section 7.4.3). Note that the storing node is not required to
perform this verification. perform this verification.
The response itself is just StoreKindResponse values packed end-to- The response itself is just StoreKindResponse values packed end-to-
end. end.
If any of the generation counters in the request precede the If any of the generation counters in the request precede the
corresponding stored generation counter, then the peer MUST fail the corresponding stored generation counter, then the peer MUST fail the
entire request and respond with an Error_Generation_Counter_Too_Low entire request and respond with an Error_Generation_Counter_Too_Low
error. The error_info in the ErrorResponse MUST be a StoreAns error. The error_info in the ErrorResponse MUST be a StoreAns
response containing the correct generation counter for each Kind and response containing the correct generation counter for each Kind and
the replica list, which will be empty. For original (non-replica) the replica list, which will be empty. For original (non-replica)
stores, a node which receives such an error SHOULD attempt to fetch stores, a node which receives such an error SHOULD attempt to fetch
the data and, if the storage_time value is newer, replace its own the data and, if the storage_time value is newer, replace its own
data with that newer data. This rule improves data consistency in data with that newer data. This rule improves data consistency in
the case of partitions and merges. the case of partitions and merges.
If the data being stored is too large for the allowed limit by the If the data being stored is too large for the allowed limit by the
given usage, then the peer MUST fail the request and generate an given usage, then the peer MUST fail the request and generate an
Error_Data_Too_Large error. Error_Data_Too_Large error.
If any type of request tries to access a data Kind that the node does If any type of request tries to access a data Kind that the peer does
not know about, an Error_Unknown_Kind MUST be generated. The not know about, an Error_Unknown_Kind MUST be generated. The
error_info in the Error_Response is: error_info in the Error_Response is:
KindId unknown_kinds<0..2^8-1>; KindId unknown_kinds<0..2^8-1>;
which lists all the Kinds that were unrecognized. A node which which lists all the Kinds that were unrecognized. A node which
receives this error MUST generate a ConfigUpdate message which receives this error MUST generate a ConfigUpdate message which
contains the appropriate Kind definition (assuming that in fact a contains the appropriate Kind definition (assuming that in fact a
Kind was used which was defined in the configuration document). Kind was used which was defined in the configuration document).
7.4.1.3. Removing Values 7.4.1.3. Removing Values
RELOAD does not have an explicit Remove operation. Rather, values RELOAD does not have an explicit Remove operation. Rather, values
are Removed by storing "nonexistent" values in their place. Each are Removed by storing "nonexistent" values in their place. Each
DataValue contains a boolean value called "exists" which indicates DataValue contains a boolean value called "exists" which indicates
whether a value is present at that location. In order to effectively whether a value is present at that location. In order to effectively
remove a value, the owner stores a new DataValue with "exists" set to remove a value, the owner stores a new DataValue with "exists" set to
"false": False:
exists = false exists = False
value = {} (0 length) value = {} (0 length)
The owner SHOULD use a lifetime for the nonexistent value at least as The owner SHOULD use a lifetime for the nonexistent value at least as
long as the remainder of the lifetime of the value it is replacing; long as the remainder of the lifetime of the value it is replacing;
otherwise it is possible for the original value to be accidentally or otherwise it is possible for the original value to be accidentally or
maliciously re-stored after the storing node has expired it. Note maliciously re-stored after the storing node has expired it. Note
that there is still a window of vulnerability for replay attack after that there is still a window of vulnerability for replay attack after
the original lifetime has expired (as with any store). This attack the original lifetime has expired (as with any store). This attack
can be mitigated by doing a nonexistent store with a very long can be mitigated by doing a nonexistent store with a very long
lifetime. lifetime.
skipping to change at page 98, line 17 skipping to change at page 98, line 17
struct { struct {
int32 first; int32 first;
int32 last; int32 last;
} ArrayRange; } ArrayRange;
struct { struct {
KindId kind; KindId kind;
uint64 generation; uint64 generation;
uint16 length; uint16 length;
select (dataModel) { select (DataModel) {
case single_value: ; /* Empty */ case single_value: ; /* Empty */
case array: case array:
ArrayRange indices<0..2^16-1>; ArrayRange indices<0..2^16-1>;
case dictionary: case dictionary:
DictionaryKey keys<0..2^16-1>; DictionaryKey keys<0..2^16-1>;
/* This structure may be extended */ /* This structure may be extended */
} model_specifier; } model_specifer;
} StoredDataSpecifier; } StoredDataSpecifier;
struct { struct {
ResourceId resource; ResourceId resource;
StoredDataSpecifier specifiers<0..2^16-1>; StoredDataSpecifier specifiers<0..2^16-1>;
} FetchReq; } FetchReq;
The contents of the Fetch requests are as follows: The contents of the Fetch requests are as follows:
resource resource
skipping to change at page 99, line 10 skipping to change at page 99, line 10
Each StoredDataSpecifier specifies a single Kind of data to retrieve Each StoredDataSpecifier specifies a single Kind of data to retrieve
and (if appropriate) the subset of values that are to be retrieved. and (if appropriate) the subset of values that are to be retrieved.
The contents of the StoredDataSpecifier structure are as follows: The contents of the StoredDataSpecifier structure are as follows:
kind kind
The Kind-ID of the data being fetched. Implementations SHOULD The Kind-ID of the data being fetched. Implementations SHOULD
reject requests corresponding to unknown Kinds unless specifically reject requests corresponding to unknown Kinds unless specifically
configured otherwise. configured otherwise.
dataModel DataModel
The data model of the data. This is not transmitted on the wire The data model of the data. This is not transmitted on the wire
but comes from the definition of the Kind. but comes from the definition of the Kind.
generation generation
The last generation counter that the requesting node saw. This The last generation counter that the requesting node saw. This
may be used to avoid unnecessary fetches or it may be set to zero. may be used to avoid unnecessary fetches or it may be set to zero.
length length
The length of the rest of the structure, thus allowing The length of the rest of the structure, thus allowing
extensibility. extensibility.
skipping to change at page 100, line 46 skipping to change at page 100, line 46
values MUST be returned. A nonexistent value (i.e., one which the values MUST be returned. A nonexistent value (i.e., one which the
node has no knowledge of) is represented by a synthetic value with node has no knowledge of) is represented by a synthetic value with
"exists" set to False and has an empty signature. Specifically, "exists" set to False and has an empty signature. Specifically,
the identity_type is set to "none", the SignatureAndHashAlgorithm the identity_type is set to "none", the SignatureAndHashAlgorithm
values are set to {0, 0} ("anonymous" and "none" respectively), values are set to {0, 0} ("anonymous" and "none" respectively),
and the signature value is of zero length. This removes the need and the signature value is of zero length. This removes the need
for the responding node to do signatures for values which do not for the responding node to do signatures for values which do not
exist. These signatures are unnecessary as the entire response is exist. These signatures are unnecessary as the entire response is
signed by that node. Note that entries which have been removed by signed by that node. Note that entries which have been removed by
the procedure of Section 7.4.1.3 and have not yet expired also the procedure of Section 7.4.1.3 and have not yet expired also
have exists = false but have valid signatures from the node which have exists = False but have valid signatures from the node which
did the store. did the store.
Upon receipt of a FetchAns message, nodes MUST verify the signatures Upon receipt of a FetchAns message, nodes MUST verify the signatures
on all the received values. Any values with invalid signatures on all the received values. Any values with invalid signatures
(including expired certificates) MUST be discarded. Note that this (including expired certificates) MUST be discarded. Note that this
implies that implementations which wish to store data for long implies that implementations which wish to store data for long
periods of time must have certificates with appropriate expiry dates periods of time must have certificates with appropriate expiry dates
or re-store periodically. Implementations MAY return the subset of or re-store periodically. Implementations MAY return the subset of
values with valid signatures, but in that case SHOULD somehow signal values with valid signatures, but in that case SHOULD somehow signal
to the application that a partial response was received. to the application that a partial response was received.
skipping to change at page 102, line 23 skipping to change at page 102, line 23
uint32 index; uint32 index;
MetaData value; MetaData value;
} ArrayEntryMeta; } ArrayEntryMeta;
struct { struct {
DictionaryKey key; DictionaryKey key;
MetaData value; MetaData value;
} DictionaryEntryMeta; } DictionaryEntryMeta;
struct { struct {
select (model) { select (DataModel) {
case single_value: case single_value:
MetaData single_value_entry; MetaData single_value_entry;
case array: case array:
ArrayEntryMeta array_entry; ArrayEntryMeta array_entry;
case dictionary: case dictionary:
DictionaryEntryMeta dictionary_entry; DictionaryEntryMeta dictionary_entry;
/* This structure may be extended */ /* This structure may be extended */
skipping to change at page 103, line 7 skipping to change at page 103, line 7
uint64 generation; uint64 generation;
StoredMetaData values<0..2^32-1>; StoredMetaData values<0..2^32-1>;
} StatKindResponse; } StatKindResponse;
struct { struct {
StatKindResponse kind_responses<0..2^32-1>; StatKindResponse kind_responses<0..2^32-1>;
} StatAns; } StatAns;
The structures used in StatAns parallel those used in FetchAns: a The structures used in StatAns parallel those used in FetchAns: a
response consists of multiple StatKindResponse values, one for each response consists of multiple StatKindResponse values, one for each
kind that was in the request. The contents of the StatKindResponse Kind that was in the request. The contents of the StatKindResponse
are the same as those in the FetchKindResponse, except that the are the same as those in the FetchKindResponse, except that the
values list contains StoredMetaData entries instead of StoredData values list contains StoredMetaData entries instead of StoredData
entries. entries.
The contents of the StoredMetaData structure are the same as the The contents of the StoredMetaData structure are the same as the
corresponding fields in StoredData except that there is no signature corresponding fields in StoredData except that there is no signature
field and the value is a MetaDataValue rather than a StoredDataValue. field and the value is a MetaDataValue rather than a StoredDataValue.
A MetaDataValue is a variant structure, like a StoredDataValue, A MetaDataValue is a variant structure, like a StoredDataValue,
except for the types of each arm, which replace DataValue with except for the types of each arm, which replace DataValue with
skipping to change at page 103, line 33 skipping to change at page 103, line 33
exists exists
Same as in DataValue Same as in DataValue
value_length value_length
The length of the stored value. The length of the stored value.
hash_algorithm hash_algorithm
The hash algorithm used to perform the digest of the value. The hash algorithm used to perform the digest of the value.
hash_value hash_value
A digest of the value using hash_algorithm. A digest using hash_algorithm on the value field of the DataValue
including its 4 leading length bytes.
7.4.4. Find 7.4.4. Find
The Find request can be used to explore the Overlay Instance. A Find The Find request can be used to explore the Overlay Instance. A Find
request for a Resource-ID R and a Kind-ID T retrieves the Resource-ID request for a Resource-ID R and a Kind-ID T retrieves the Resource-ID
(if any) of the resource of kind T known to the target peer which is (if any) of the resource of kind T known to the target peer which is
closest to R. This method can be used to walk the Overlay Instance by closest to R. This method can be used to walk the Overlay Instance by
iteratively fetching R_n+1=nearest(1 + R_n). iteratively fetching R_n+1=nearest(1 + R_n).
7.4.4.1. Request Definition 7.4.4.1. Request Definition
skipping to change at page 105, line 6 skipping to change at page 105, line 6
0. Note that different Kind-IDs may have different closest Resource- 0. Note that different Kind-IDs may have different closest Resource-
IDs. IDs.
The response is simply a series of FindKindData elements, one per The response is simply a series of FindKindData elements, one per
kind, concatenated end-to-end. The contents of each element are: kind, concatenated end-to-end. The contents of each element are:
kind kind
The Kind-ID. The Kind-ID.
closest closest
The closest resource ID to the specified resource ID. This is 0 The closest Resource-ID to the specified Resource-ID. This is 0
if no resource ID is known. if no Resource-ID is known.
Note that the response does not contain the contents of the data Note that the response does not contain the contents of the data
stored at these Resource-IDs. If the requester wants this, it must stored at these Resource-IDs. If the requester wants this, it must
retrieve it using Fetch. retrieve it using Fetch.
7.4.5. Defining New Kinds 7.4.5. Defining New Kinds
There are two ways to define a new Kind. The first is by writing a There are two ways to define a new Kind. The first is by writing a
document and registering the Kind-ID with IANA. This is the document and registering the Kind-ID with IANA. This is the
preferred method for Kinds which may be widely used and reused. The preferred method for Kinds which may be widely used and reused. The
second method is to simply define the Kind and its parameters in the second method is to simply define the Kind and its parameters in the
configuration document using the section of Kind-id space set aside configuration document using the section of Kind-ID space set aside
for private use. This method MAY be used to define ad hoc Kinds in for private use. This method MAY be used to define ad hoc Kinds in
new overlays. new overlays.
However a Kind is defined, the definition MUST include: However a Kind is defined, the definition MUST include:
o The meaning of the data to be stored (in some textual form). o The meaning of the data to be stored (in some textual form).
o The Kind-ID. o The Kind-ID.
o The data model (single value, array, dictionary, etc). o The data model (single value, array, dictionary, etc).
o The access control model. o The access control model.
skipping to change at page 107, line 15 skipping to change at page 107, line 15
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. If the turn- what percentage of peers will act as TURN servers. If the turn-
density is not set to zero, for each value, called d, between 1 and density is not set to zero, for each value, called d, between 1 and
turn-density, the peer forms a Resource Name by concatenating its turn-density, the peer forms a Resource Name by concatenating its
Node-ID and the value d. This Resource Name is hashed to form a Node-ID and the value d. This Resource Name is hashed to form a
Resource-ID. The address of the peer is stored at that Resource-ID Resource-ID. The address of the peer is stored at that Resource-ID
using type TURN-SERVICE and the TurnServer object: using type TURN-SERVICE and the TurnServer object:
struct { struct {
uint8 iteration; uint8 iteration;
IpAddressAndPort server_address; IpAddressPort server_address;
} TurnServer; } TurnServer;
The contents of this structure are as follows: The contents of this structure are as follows:
iteration iteration
the d value the d value
server_address server_address
the address at which the TURN server can be contacted. the address at which the TURN server can be contacted.
skipping to change at page 109, line 15 skipping to change at page 109, line 15
levels of churn [handling-churn-usenix04]. The overlay levels of churn [handling-churn-usenix04]. The overlay
configuration file specifies a "chord-reactive" element that configuration file specifies a "chord-reactive" element that
indicates whether reactive recovery should be used. indicates whether reactive recovery should be used.
10.1. Overview 10.1. Overview
The algorithm described here is a modified version of the Chord The algorithm described here is a modified version of the Chord
algorithm. In Chord (and in the algorithm described here), nodes are algorithm. In Chord (and in the algorithm described here), nodes are
arranged in a ring with node n being adjacent to nodes n-1 and n+1, arranged in a ring with node n being adjacent to nodes n-1 and n+1,
with all arithmetic being done modulo 2^{k}, where k is the length of with all arithmetic being done modulo 2^{k}, where k is the length of
the Node-Id in bits, so that node 2^{k} - 1 is directly before node the Node-ID in bits, so that node 2^{k} - 1 is directly before node
0. 0.
Each peer keeps track of a finger table and a neighbor table. The Each peer keeps track of a finger table and a neighbor table. The
neighbor table contains at least the three peers before and after neighbor table contains at least the three peers before and after
this peer in the DHT ring. There may not be three entries in all this peer in the DHT ring. There may not be three entries in all
cases such as small rings or while the ring topology is changing. cases such as small rings or while the ring topology is changing.
The first entry in the finger table contains the peer half-way around The first entry in the finger table contains the peer half-way around
the ring from this peer; the second entry contains the peer that is the ring from this peer; the second entry contains the peer that is
1/4 of the way around; the third entry contains the peer that is 1/4 of the way around; the third entry contains the peer that is
1/8th of the way around, and so on. Fundamentally, the chord DHT can 1/8th of the way around, and so on. Fundamentally, the chord DHT can
skipping to change at page 109, line 51 skipping to change at page 109, line 51
A peer, x, is responsible for a particular Resource-ID k if k is less A peer, x, is responsible for a particular Resource-ID k if k is less
than or equal to x and k is greater than p, where p is the Node-ID of than or equal to x and k is greater than p, where p is the Node-ID of
the previous peer in the neighbor table. Care must be taken when the previous peer in the neighbor table. Care must be taken when
computing to note that all math is modulo 2^128. computing to note that all math is modulo 2^128.
10.2. Hash Function 10.2. Hash Function
For this Chord based topology plugin, the size of the Resource-ID is For this Chord based topology plugin, the size of the Resource-ID is
128 bits. The hash of a Resource-ID MUST be computed using SHA-1 128 bits. The hash of a Resource-ID MUST be computed using SHA-1
[RFC3174]then truncating the SHA-1 result to the most significant 128 [RFC3174] then truncating the SHA-1 result to the most significant
bits. 128 bits.
10.3. Routing 10.3. Routing
The routing table is conceptually the union of the neighbor table and The routing table is conceptually the union of the neighbor table and
the finger table. the finger table.
If a peer is not responsible for a Resource-ID k, but is directly If a peer is not responsible for a Resource-ID k, but is directly
connected to a node with Node-ID k, then it MUST route the message to connected to a node with Node-ID k, then it MUST route the message to
that node. Otherwise, it MUST route the request to the peer in the that node. Otherwise, it MUST route the request to the peer in the
routing table that has the largest Node-ID that is in the interval routing table that has the largest Node-ID that is in the interval
between the peer and k. If no such node is found, it finds the between the peer and k. If no such node is found, it finds the
smallest Node-Id that is greater than k and MUST route the message to smallest Node-ID that is greater than k and MUST route the message to
that node. that node.
10.4. Redundancy 10.4. Redundancy
When a peer receives a Store request for Resource-ID k, and it is When a peer receives a Store request for Resource-ID k, and it is
responsible for Resource-ID k, it MUST store the data and returns a responsible for Resource-ID k, it MUST store the data and returns a
success response. It MUST then send a Store request to its successor success response. It MUST then send a Store request to its successor
in the neighbor table and to that peer's successor. Note that these in the neighbor table and to that peer's successor. Note that these
Store requests are addressed to those specific peers, even though the Store requests are addressed to those specific peers, even though the
Resource-ID they are being asked to store is outside the range that Resource-ID they are being asked to store is outside the range that
skipping to change at page 112, line 19 skipping to change at page 112, line 19
learned the new peer's Node-ID. Source-routing these requests allows learned the new peer's Node-ID. Source-routing these requests allows
the overlay to recover from instability. the overlay to recover from instability.
All other Attach requests, such as those for new finger table All other Attach requests, such as those for new finger table
entries, are routed conventionally through the overlay. entries, are routed conventionally through the overlay.
10.7. Updates 10.7. Updates
An Update for this DHT is defined as An Update for this DHT is defined as
enum { reserved (0), enum { reserved(0),
peer_ready(1), neighbors(2), full(3), (255) } peer_ready(1), neighbors(2), full(3), (255) }
ChordUpdateType; ChordUpdateType;
struct { struct {
uint32 uptime; uint32 uptime;
ChordUpdateType type; ChordUpdateType type;
select(type){ select (type){
case peer_ready: /* Empty */ case peer_ready: /* Empty */
; ;
case neighbors: case neighbors:
NodeId predecessors<0..2^16-1>; NodeId predecessors<0..2^16-1>;
NodeId successors<0..2^16-1>; NodeId successors<0..2^16-1>;
case full: case full:
NodeId predecessors<0..2^16-1>; NodeId predecessors<0..2^16-1>;
NodeId successors<0..2^16-1>; NodeId successors<0..2^16-1>;
skipping to change at page 115, line 47 skipping to change at page 115, line 47
state. state.
2. search for better peers to place in its finger table. 2. search for better peers to place in its finger table.
3. search to determine if the current finger table size is 3. search to determine if the current finger table size is
sufficiently large. sufficiently large.
4. search to determine if the overlay has partitioned and needs to 4. search to determine if the overlay has partitioned and needs to
recover. recover.
10.7.4.1. Updating neighbor table 10.7.4.1. Updating neighbor table
A peer MUST periodically send an Update request to every peer in its A peer MUST periodically send an Update request to every peer in its
Connection Table. The purpose of this is to keep the predecessor and Neighbor Table. The purpose of this is to keep the predecessor and
successor lists up to date and to detect failed peers. The default successor lists up to date and to detect failed peers. The default
time is about every ten minutes, but the configuration server SHOULD time is about every ten minutes, but the configuration server SHOULD
set this in the configuration document using the "chord-update- set this in the configuration document using the "chord-update-
interval" element (denominated in seconds.) A peer SHOULD randomly interval" element (denominated in seconds.) A peer SHOULD randomly
offset these Update requests so they do not occur all at once. offset these Update requests so they do not occur all at once.
10.7.4.2. Refreshing finger table 10.7.4.2. Refreshing finger table
A peer MUST periodically search for new peers to replace invalid A peer MUST periodically search for new peers to replace invalid
entries in the finger table. For peer x, the i'th finger table entry entries in the finger table. For peer x, the i'th finger table entry
skipping to change at page 116, line 25 skipping to change at page 116, line 25
interval", which defaults to 3600 seconds (one per hour). interval", which defaults to 3600 seconds (one per hour).
Two possible methods for searching for new peers for the finger table Two possible methods for searching for new peers for the finger table
entries are presented: entries are presented:
Alternative 1: A peer selects one entry in the finger table from Alternative 1: A peer selects one entry in the finger table from
among the invalid entries. It pings for a new peer for that finger among the invalid entries. It pings for a new peer for that finger
table entry. The selection SHOULD be exponentially weighted to table entry. The selection SHOULD be exponentially weighted to
attempt to replace earlier (lower i) entries in the finger table. A attempt to replace earlier (lower i) entries in the finger table. A
simple way to implement this selection is to search through the simple way to implement this selection is to search through the
finger table entries from i=0 and each time an invalid entry is finger table entries from i=1 and each time an invalid entry is
encountered, send a Ping to replace that entry with probability 0.5. encountered, send a Ping to replace that entry with probability 0.5.
Alternative 2: A peer monitors the Update messages received from its Alternative 2: A peer monitors the Update messages received from its
connections to observe when an Update indicates a peer that would be connections to observe when an Update indicates a peer that would be
used to replace in invalid finger table entry, i, and flags that used to replace in invalid finger table entry, i, and flags that
entry in the finger table. Every "chord-ping-interval" seconds, the entry in the finger table. Every "chord-ping-interval" seconds, the
peer selects from among those flagged candidates using an peer selects from among those flagged candidates using an
exponentially weighted probability as above. exponentially weighted probability as above.
When searching for a better entry, the peer SHOULD send the Ping to a When searching for a better entry, the peer SHOULD send the Ping to a
skipping to change at page 117, line 45 skipping to change at page 117, line 45
may not be in P's neighbor table once the overlay is healed, but the may not be in P's neighbor table once the overlay is healed, but the
connection will allow S' to discover appropriate neighbor entries for connection will allow S' to discover appropriate neighbor entries for
itself via its own stabilization.) itself via its own stabilization.)
Future specifications may describe alternative mechanisms for Future specifications may describe alternative mechanisms for
determining when to repeat the discovery process. determining when to repeat the discovery process.
10.8. Route query 10.8. Route query
For this topology plugin, the RouteQueryReq contains no additional For this topology plugin, the RouteQueryReq contains no additional
information. The RouteQueryAns contains the single node ID of the information. The RouteQueryAns contains the single Node-ID of the
next peer to which the responding peer would have routed the request next peer to which the responding peer would have routed the request
message in recursive routing: message in recursive routing:
struct { struct {
NodeId next_peer; NodeId next_peer;
} ChordRouteQueryAns; } ChordRouteQueryAns;
The contents of this structure are as follows: The contents of this structure are as follows:
skipping to change at page 118, line 23 skipping to change at page 118, line 23
If the requester has set the send_update flag, the responder SHOULD If the requester has set the send_update flag, the responder SHOULD
initiate an Update immediately after sending the RouteQueryAns. initiate an Update immediately after sending the RouteQueryAns.
10.9. Leaving 10.9. Leaving
To support extensions, such as [I-D.ietf-p2psip-self-tuning], Peers To support extensions, such as [I-D.ietf-p2psip-self-tuning], Peers
SHOULD send a Leave request to all members of their neighbor table SHOULD send a Leave request to all members of their neighbor table
prior to exiting the Overlay Instance. The overlay_specific_data prior to exiting the Overlay Instance. The overlay_specific_data
field MUST contain the ChordLeaveData structure defined below: field MUST contain the ChordLeaveData structure defined below:
enum { reserved (0), enum { reserved(0),
from_succ(1), from_pred(2), (255) } from_succ(1), from_pred(2), (255) }
ChordLeaveType; ChordLeaveType;
struct { struct {
ChordLeaveType type; ChordLeaveType type;
select(type) { select (type) {
case from_succ: case from_succ:
NodeId successors<0..2^16-1>; NodeId successors<0..2^16-1>;
case from_pred: case from_pred:
NodeId predecessors<0..2^16-1>; NodeId predecessors<0..2^16-1>;
}; };
} ChordLeaveData; } ChordLeaveData;
The 'type' field indicates whether the Leave request was sent by a The 'type' field indicates whether the Leave request was sent by a
predecessor or a successor of the recipient: predecessor or a successor of the recipient:
from_succ from_succ
The Leave request was sent by a successor. The Leave request was sent by a successor.
from_pred from_pred
skipping to change at page 122, line 49 skipping to change at page 122, line 49
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 "sha1" compute the Node-ID. Valid values for this parameter are "sha1"
and "sha256" representing SHA-1 [RFC3174] and SHA-256 [RFC6234] and "sha256" representing SHA-1 [RFC3174] and SHA-256 [RFC6234]
respectively. Implementations MUST support both of these respectively. 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 optional attribute called "port" that distinguished) and an optional attribute called "port" that
represents the port and defaults to 6084. The IP address is in represents the port and defaults to 6084. The IPv6 address is in
typical hexadecimal form using standard period and colon typical hexadecimal form using standard period and colon
separators as specified in [RFC5952]. More than one bootstrap- separators as specified in [RFC5952]. More than one bootstrap-
peer element may be present. 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 5% of the nodes can act as TURN servers, servers. For example, if 5% of the nodes can act as TURN servers,
this would be set to 20. If it is not present, the default value this would be set to 20. If it is not present, the default value
is 1. If there are no TURN servers in the overlay, it is set to is 1. If there are no TURN servers in the overlay, it is set to
zero. zero.
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 attribute called "address" that represents the IP address and an
optional attribute called "port" that represents the port and optional attribute called "port" that represents the port and
defaults to 6084. More than one "multicast-bootstrap" element may defaults to 6084. More than one "multicast-bootstrap" element may
be present. be present.
clients-permitted This element represents whether clients are clients-permitted This element represents whether clients are
permitted or whether all nodes must be peers. If it is set to permitted or whether all nodes must be peers. If it is set to
"true" or absent, this indicates that clients are permitted. If "true" or absent, this indicates that clients are permitted. If
it is set to "false" then nodes are not allowed to remain clients it is set to "false" then nodes are not allowed to remain clients
after the initial join. There is currently no way for the overlay after the initial join. There is currently no way for the overlay
to enforce this. to enforce this.
no-ice This element represents whether nodes are required to use no-ice This element represents whether nodes are required to use
skipping to change at page 124, line 22 skipping to change at page 124, line 22
sign configurations for this instance-name. Identifying the sign configurations for this instance-name. Identifying the
signer by Node-ID instead of certificate allows the use of short signer by Node-ID instead of certificate allows the use of short
lived certificates without constantly having to provide an updated lived certificates without constantly having to provide an updated
configuration file. configuration file.
bad-node This contains a single Node-ID in hexadecimal and bad-node This contains a single Node-ID in hexadecimal and
indicates that the certificate with this Node-ID MUST NOT be indicates that the certificate with this Node-ID MUST NOT be
considered valid. This allows certificate revocation. An considered valid. This allows certificate revocation. An
arbitrary number of these elements can be provided. Note that arbitrary number of these elements can be provided. Note that
because certificates may expire, bad-node entries need only be because certificates may expire, bad-node entries need only be
present for the lifetime of the certificate. Technically present for the lifetime of the certificate. Technically
speaking, bad node-ids may be reused once their certificates have speaking, bad Node-IDs may be reused once their certificates have
expired, the requirement for node-ids to be pseudo randomly expired, the requirement for Node-IDs to be pseudo randomly
generated gives this event a vanishing probability. generated gives this event a vanishing probability.
mandatory-extension This element contains the name of an XML mandatory-extension This element contains the name of an XML
namespace that a node joining the overlay MUST support. The namespace that a node joining the overlay MUST support. The
presence of a mandatory-extension element does not require the presence of a mandatory-extension element does not require the
extension to be used in the current configuration file, but can extension to be used in the current configuration file, but can
indicate that it may be used in the future. Note that the indicate that it may be used in the future. Note that the
namespace is case-sensitive, as specified in [w3c-xml-namespaces] namespace is case-sensitive, as specified in [w3c-xml-namespaces]
Section 2.3. More than one mandatory-extension element may be Section 2.3. More than one mandatory-extension element may be
present. present.
Inside each overlay element, the required-kinds elements can also Inside each configuration element, the required-kinds element can
occur. This element indicates the Kinds that members must support also occur. This element indicates the Kinds that members must
and contains multiple kind-block elements that each define a single support and contains multiple kind-block elements that each define a
Kind that MUST be supported by nodes in the overlay. Each kind-block single Kind that MUST be supported by nodes in the overlay. Each
consists of a single kind element and a kind-signature. The kind kind-block consists of a single kind element and a kind-signature.
element defines the Kind. The kind-signature is the signature The kind element defines the Kind. The kind-signature is the
computed over the kind element. signature computed over the kind element.
Each kind has either an id attribute or a name attribute. The name Each kind has either an id attribute or a name attribute. The name
attribute is a string representing the Kind (the name registered to attribute is a string representing the Kind (the name registered to
IANA) while the id is an integer Kind-ID allocated out of private IANA) while the id is an integer Kind-ID allocated out of private
space. space.
In addition, the kind element contains the following elements: In addition, the kind element contains the following elements:
max-count: the maximum number of values which members of the overlay max-count: the maximum number of values which members of the overlay
must support. must support.
data-model: the data model to be used. data-model: the data model to be used.
max-size: the maximum size of individual values. max-size: the maximum size of individual values.
access-control: the access control model to be used. access-control: the access control model to be used.
max-node-multiple: This is optional and only used when the access max-node-multiple: This is optional and only used when the access
control is NODE-MULTIPLE. This indicates the maximum value for control is NODE-MULTIPLE. This indicates the maximum value for
the i counter. This is an integer greater than 0. the i counter. This is an integer greater than 0.
All of the non optional values MUST be provided. If the Kind is All of the non optional values MUST be provided. If the Kind is
registered with IANA, the data-model and access-control elements MUST registered with IANA, the data-model and access-control elements MUST
match those in the Kind registration, and clients MUST ignore them in match those in the Kind registration, and clients MUST ignore them in
favor of the IANA versions. Multiple required-kinds elements MAY be favor of the IANA versions. Multiple kind-block elements MAY be
present. present.
The kind-block element also MUST contain a "kind-signature" element. The kind-block element also MUST contain a "kind-signature" element.
This signature is computed across the kind from the beginning of the This signature is computed across the kind from the beginning of the
first < of the kind to the end of the last > of the kind in the same first < of the kind to the end of the last > of the kind in the same
way as the signature element described later in this section. way as the signature element described later in this section.
The configuration file needs to be treated as a binary blob that The configuration element needs to be treated as a binary blob that
cannot be changed - including any whitespace changes - or the cannot be changed - including any whitespace changes - or the
signature will break. The signature is computed by taking each signature will break. The signature is computed by taking each
configuration element and starting from, and including, the first < configuration element and starting from, and including, the first <
at the start of <configuration> up to and including the > in at the start of <configuration> up to and including the > in
</configuration> and treating this as a binary blob that is signed </configuration> and treating this as a binary blob that is signed
using the standard SecurityBlock defined in Section 6.3.4. The using the standard SecurityBlock defined in Section 6.3.4. The
SecurityBlock is base 64 encoded using the base64 alphabet from SecurityBlock is base 64 encoded using the base64 alphabet from
RFC[RFC4648] and put in the signature element following the [RFC4648] and put in the signature element following the
configuration object in the configuration file. Any configuration configuration object in the configuration file. Any configuration
file through the overlay (as opposed to directly from the file MUST be signed by one of the configuration-signer elements from
configuration server) MUST be signed by one of the configure-signers the previous extant configuration. Recipients MUST verify the
from the previous extant configuration. Recipients MUST verify the
signature prior to accepting the configuration file. signature prior to accepting the configuration file.
When a node receives a new configuration file, it MUST change its When a node receives a new configuration file, it MUST change its
configuration to meet the new requirements. This may require the configuration to meet the new requirements. This may require the
node to exit the DHT and re-join. If a node is not capable of node to exit the DHT and re-join. If a node is not capable of
supporting the new requirements, it MUST exit the overlay. If some supporting the new requirements, it MUST exit the overlay. If some
information about a particular Kind changes from what the node information about a particular Kind changes from what the node
previously knew about the Kind (for example the max size), the new previously knew about the Kind (for example the max size), the new
information in the configuration files overrides any previously information in the configuration files overrides any previously
learned information. If any Kind data was signed by a node that is learned information. If any Kind data was signed by a node that is
skipping to change at page 128, line 38 skipping to change at page 128, line 36
11.2. Discovery Through Configuration Server 11.2. Discovery Through Configuration Server
When a node first enrolls in a new overlay, it starts with a When a node first enrolls in a new overlay, it starts with a
discovery process to find a configuration server. discovery process to find a configuration server.
The node MAY start by determining the overlay name. This value is The node MAY start by determining the overlay name. This value is
provided by the user or some other out of band provisioning provided by the user or some other out of band provisioning
mechanism. The out of band mechanisms MAY also provide an optional mechanism. The out of band mechanisms MAY also provide an optional
URL for the configuration server. If a URL for the configuration URL for the configuration server. If a URL for the configuration
server is not provided, the node MUST do a DNS SRV query using a server is not provided, the node MUST do a DNS SRV query using a
Service name of "p2psip-enroll" and a protocol of TCP to find a Service name of "reload-config" and a protocol of TCP to find a
configuration server and form the URL by appending a path of "/.well- configuration server and form the URL by appending a path of "/.well-
known/p2psip-enroll" to the overlay name. This uses the "well known known/reload-config" to the overlay name. This uses the "well known
URI" framework defined in [RFC5785]. For example, if the overlay URI" framework defined in [RFC5785]. For example, if the overlay
name was example.com, the URL would be name was example.com, the URL would be
"https://example.com/.well-known/p2psip-enroll". "https://example.com/.well-known/reload-config".
Once an address and URL for the configuration server is determined, Once an address and URL for the configuration server is determined,
the peer MUST form an HTTPS connection to that IP address. The the peer MUST form an HTTPS connection to that IP address. The
certificate MUST match the overlay name as described in [RFC2818]. certificate MUST match the overlay name as described in [RFC2818].
Then the node MUST fetch a new copy of the configuration file. To do Then the node MUST fetch a new copy of the configuration file. To do
this, the peer performs a GET to the URL. The result of the HTTP GET this, the peer performs a GET to the URL. The result of the HTTP GET
is an XML configuration file described above, which MUST replace any is an XML configuration file described above, which MUST replace any
previously learned configuration file for this overlay. previously learned configuration file for this overlay.
For overlays that do not use a configuration server, nodes need to For overlays that do not use a configuration server, nodes need to
skipping to change at page 129, line 31 skipping to change at page 129, line 30
protocols, such as [RFC5272] and [RFC5273]. The objective was to protocols, such as [RFC5272] and [RFC5273]. The objective was to
have a protocol which could be easily implemented in a Web server have a protocol which could be easily implemented in a Web server
which the operator did not control (e.g., in a hosted service) and which the operator did not control (e.g., in a hosted service) and
was compatible with the existing certificate handling tooling as used was compatible with the existing certificate handling tooling as used
with the Web certificate infrastructure. This means accepting bare with the Web certificate infrastructure. This means accepting bare
PKCS#10 requests and returning a single bare X.509 certificate. PKCS#10 requests and returning a single bare X.509 certificate.
Although the MIME types for these objects are defined, none of the Although the MIME types for these objects are defined, none of the
existing protocols support exactly this model. existing protocols support exactly this model.
The certificate request protocol is performed over HTTPS. The The certificate request protocol is performed over HTTPS. The
request is an HTTP POST with the parameter encodes as described in request is an HTTP POST with the parameters encoded as described in
[RFC2388] and the following properties: [RFC2388] and the following properties:
o If authentication is required, there is an form parameter of o If authentication is required, there is an form parameter of
"password" and "username" containing the user's name and password "password" and "username" containing the user's name and password
in the clear (hence the need for HTTPS) in the clear (hence the need for HTTPS)
o If more than one Node-ID is required, there is an form parameter o If more than one Node-ID is required, there is an form parameter
of "nodeids" containing the number of Node-IDs required. of "nodeids" containing the number of Node-IDs required.
o There MUST be a form parameter of "csr" with a content type of o There MUST be a form parameter of "csr" with a content type of
"application/pkcs10", as defined in [RFC2311]. "application/pkcs10", as defined in [RFC2311].
o The Accept header MUST contain the type "application/pkix-cert", o The Accept header MUST contain the type "application/pkix-cert",
skipping to change at page 130, line 14 skipping to change at page 130, line 13
certificate contains the following values: certificate contains the following values:
o One or more Node-IDs which MUST be cryptographically random o One or more Node-IDs which MUST be cryptographically random
[RFC4086]. Each MUST be chosen by the enrollment server in such a [RFC4086]. Each MUST be chosen by the enrollment server in such a
way that they are unpredictable to the requesting user. E.g., the way that they are unpredictable to the requesting user. E.g., the
user MUST NOT be informed of potential (random) Node-IDs prior to user MUST NOT be informed of potential (random) Node-IDs prior to
authenticating. Each is placed in the subjectAltName using the authenticating. Each is placed in the subjectAltName using the
uniformResourceIdentifier type and MUST contain RELOAD URIs as uniformResourceIdentifier type and MUST contain RELOAD URIs as
described in Section 14.15 and MUST contain a Destination list described in Section 14.15 and MUST contain a Destination list
with a single entry of type "node_id". The enrollment server with a single entry of type "node_id". The enrollment server
SHOULD maintain a mapping of users to node-ids and if the same SHOULD maintain a mapping of users to Node-IDs and if the same
user returns (e.g., to have their certificate re-issued) return user returns (e.g., to have their certificate re-issued) return
the same Node-ID, thus avoiding the need for implementations to the same Node-IDs, thus avoiding the need for implementations to
re-store all their data when their certificates expire. re-store all their data when their certificates expire.
o A single name this user is allowed to use in the overlay, using o A single name this user is allowed to use in the overlay, using
type rfc822Name. Enrollment servers SHOULD take care to only type rfc822Name. Enrollment servers SHOULD take care to only
allow legal characters in the name (e.g., no embedded NULs), allow legal characters in the name (e.g., no embedded NULs),
rather than simply accepting any name provided by the user. rather than simply accepting any name provided by the user.
The certificate is returned as type "application/pkix-cert" as The certificate is returned as type "application/pkix-cert" as
defined in [RFC2585], with an HTTP status code of 200 OK. defined in [RFC2585], with an HTTP status code of 200 OK.
Certificate processing errors should result in a HTTP return code of Certificate processing errors should result in a HTTP return code of
skipping to change at page 130, line 42 skipping to change at page 130, line 41
username_not_available The requested userName for the certificate username_not_available The requested userName for the certificate
was not acceptable. was not acceptable.
Node-IDs_not_available The number of Node-IDs requested was not Node-IDs_not_available The number of Node-IDs requested was not
acceptable. acceptable.
bad_CSR There was a problem with the CSR. bad_CSR There was a problem with the CSR.
If the client receives an unknown token in the body, it SHOULD treat If the client receives an unknown token in the body, it SHOULD treat
it as a failure for an unknown reasons. it as a failure for an unknown reason.
The client MUST check that the certificate returned chains back to The client MUST check that the certificate returned chains back to
one of the certificates received in the "root-cert" list of the one of the certificates received in the "root-cert" list of the
overlay configuration data (including PKIX BasicConstraints checks.) overlay configuration data (including PKIX BasicConstraints checks.)
The node then reads the certificate to find the Node-IDs it can use. The node then reads the certificate to find the Node-ID it can use.
11.3.1. Self-Generated Credentials 11.3.1. Self-Generated Credentials
If the "self-signed-permitted" element is present in the If the "self-signed-permitted" element is present in the
configuration and set to "true", then a node MUST generate its own configuration and set to "true", then a node MUST generate its own
self-signed certificate to join the overlay. The self-signed self-signed certificate to join the overlay. The self-signed
certificate MAY contain any user name of the users choice. certificate MAY contain any user name of the users choice.
The Node-ID MUST be computed by applying the digest specified in the For self-signed certificate containing only one Node-ID, the Node-ID
self-signed-permitted element to the DER representation of the user's MUST be computed by applying the digest specified in the self-signed-
public key (more specifically the subjectPublicKeyInfo) and taking permitted element to the DER representation of the user's public key
the high order bits. When accepting a self-signed certificate, nodes (more specifically the subjectPublicKeyInfo) and taking the high
MUST check that the Node-ID and public keys match. This prevents order bits. For self-signed certficates containing multiple Node-
Node-ID theft. IDs, the index of the Node-ID (from 1 to the number of Node-IDs
needed) must be prepended as a 4 bytes big endian integer to the DER
representation of the user's public key and taking the high order
bits. When accepting a self-signed certificate, nodes MUST check
that the Node-ID and public keys match. This prevents Node-ID theft.
Once the node has constructed a self-signed certificate, it MAY join Once the node has constructed a self-signed certificate, it MAY join
the overlay. Before storing its certificate in the overlay the overlay. Before storing its certificate in the overlay
(Section 8) it SHOULD look to see if the user name is already taken (Section 8) it SHOULD look to see if the user name is already taken
and if so choose another user name. Note that this only provides and if so choose another user name. Note that this only provides
protection against accidental name collisions. Name theft is still protection against accidental name collisions. Name theft is still
possible. If protection against name theft is desired, then the possible. If protection against name theft is desired, then the
enrollment service must be used. enrollment service must be used.
11.4. Searching for a Bootstrap Node 11.4. Searching for a Bootstrap Node
skipping to change at page 132, line 32 skipping to change at page 132, line 31
JP = joining peer, AP = admitting peer, NP = next peer after the AP, 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 NNP = next next peer which is the peer after NP, PP = previous peer
before the AP, PPP = previous previous peer which is the peer before before the AP, PPP = previous previous peer which is the peer before
the PP, BP = bootstrap peer. the PP, BP = bootstrap peer.
In the following example, we assume that JP has formed a connection In the following example, we assume that JP has formed a connection
to one of the bootstrap nodes. JP then sends an Attach through that to one of the bootstrap nodes. JP then sends an Attach through that
peer to a resource ID of itself (JP). It gets routed to the peer to a resource ID of itself (JP). It gets routed to the
admitting peer (AP) because JP is not yet part of the overlay. When admitting peer (AP) because JP is not yet part of the overlay. When
AP responds, JP and AP use ICE to set up a connection and then set up AP responds, JP and AP use ICE to set up a connection and then set up
TLS. Once AP has connected to JP, AP sends to JP an Update to DTLS. Once AP has connected to JP, AP sends to JP an Update to
populate its Routing Table. The following example shows the Update populate its Routing Table. The following example shows the Update
happening after the TLS connection is formed but it could also happen happening after the DTLS connection is formed but it could also
before in which case the Update would often be routed through other happen before in which case the Update would often be routed through
nodes. other nodes.
JP PPP PP AP NP NNP BP JP PPP PP AP NP NNP BP
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
|Attach Dest=JP | | | | | |Attach Dest=JP | | | | |
|---------------------------------------------------------->| |---------------------------------------------------------->|
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | |Attach Dest=JP | | | | | |Attach Dest=JP | | |
skipping to change at page 133, line 50 skipping to change at page 133, line 50
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
|UpdateAns| | | | | | |UpdateAns| | | | | |
|---------------------------->| | | | |---------------------------->| | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
The JP then forms connections to the appropriate neighbors, such as The JP then forms connections to the appropriate neighbors, such as
NP, by sending an Attach which gets routed via other nodes. When NP NP, by sending an Attach which gets routed via other nodes. When NP
responds, JP and NP use ICE and TLS to set up a connection. responds, JP and NP use ICE and DTLS to set up a connection.
JP PPP PP AP NP NNP BP JP PPP PP AP NP NNP BP
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
|Attach NP | | | | | |Attach NP | | | | |
|---------------------------->| | | | |---------------------------->| | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | |Attach NP| | | | | | |Attach NP| | |
skipping to change at page 139, line 8 skipping to change at page 139, line 8
P2PSIP deployments require the ability to authenticate both peers and P2PSIP deployments require the ability to authenticate both peers and
resources (users) without the active presence of a trusted entity in resources (users) without the active presence of a trusted entity in
the system. We describe two mechanisms. The first mechanism is the system. We describe two mechanisms. The first mechanism is
based on public key certificates and is suitable for general based on public key certificates and is suitable for general
deployments. The second is an admission control mechanism based on deployments. The second is an admission control mechanism based on
an overlay-wide shared symmetric key. an overlay-wide shared symmetric key.
13.2. Attacks on P2P Overlays 13.2. Attacks on P2P Overlays
The two basic functions provided by overlay nodes are storage and The two basic functions provided by overlay nodes are storage and
routing: some node is responsible for storing a peer's data and for routing: some peer is responsible for storing a node's data and for
allowing a third peer to fetch this stored data. Other nodes are allowing a third node to fetch this stored data. Other peers are
responsible for routing messages to and from the storing nodes. Each responsible for routing messages to and from the storing nodes. Each
of these issues is covered in the following sections. of these issues is covered in the following sections.
P2P overlays are subject to attacks by subversive nodes that may P2P overlays are subject to attacks by subversive nodes that may
attempt to disrupt routing, corrupt or remove user registrations, or attempt to disrupt routing, corrupt or remove user registrations, or
eavesdrop on signaling. The certificate-based security algorithms we eavesdrop on signaling. The certificate-based security algorithms we
describe in this specification are intended to protect overlay describe in this specification are intended to protect overlay
routing and user registration information in RELOAD messages. routing and user registration information in RELOAD messages.
To protect the signaling from attackers pretending to be valid peers To protect the signaling from attackers pretending to be valid nodes
(or peers other than themselves), the first requirement is to ensure (or nodes other than themselves), the first requirement is to ensure
that all messages are received from authorized members of the that all messages are received from authorized members of the
overlay. For this reason, RELOAD transports all messages over a overlay. For this reason, RELOAD transports all messages over a
secure channel (TLS and DTLS are defined in this document) which secure channel (TLS and DTLS are defined in this document) which
provides message integrity and authentication of the directly provides message integrity and authentication of the directly
communicating peer. In addition, messages and data are digitally communicating peer. In addition, messages and data are digitally
signed with the sender's private key, providing end-to-end security signed with the sender's private key, providing end-to-end security
for communications. for communications.
13.3. Certificate-based Security 13.3. Certificate-based Security
skipping to change at page 139, line 43 skipping to change at page 139, 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 Node-ID are placed in the certificate, along Both the name and the Node-IDs 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 Node-ID(s) listed in the certificate. o As a overlay peer with the Node-ID(s) listed in the certificate.
Note that since only users of this Overlay Instance need to validate Note that since only users of this Overlay Instance need to validate
a certificate, this usage does not require a global PKI. Instead, a certificate, this usage does not require a global PKI. Instead,
certificates are signed by a central enrollment authority which acts certificates are signed by a central enrollment authority which acts
as the certificate authority for the Overlay Instance. This as the certificate authority for the Overlay Instance. This
authority signs each peer's certificate. Because each peer possesses authority signs each node's certificate. Because each node possesses
the CA's certificate (which they receive on enrollment) they can the CA's certificate (which they receive on enrollment) they can
verify the certificates of the other entities in the overlay without verify the certificates of the other entities in the overlay without
further communication. Because the certificates contain the user/ further communication. Because the certificates contain the user/
peer's public key, communications from the user/peer can be verified node's public key, communications from the user/node can be verified
in turn. in turn.
If self-signed certificates are used, then the security provided is If self-signed certificates are used, then the security provided is
significantly decreased, since attackers can mount Sybil attacks. In significantly decreased, since attackers can mount Sybil attacks. In
addition, attackers cannot trust the user names in certificates addition, attackers cannot trust the user names in certificates
(though they can trust the Node-IDs because they are (though they can trust the Node-IDs because they are
cryptographically verifiable). This scheme may be appropriate for cryptographically verifiable). This scheme may be appropriate for
some small deployments, such as a small office or an ad hoc overlay some small deployments, such as a small office or an ad hoc overlay
set up among participants in a meeting where all hosts on the network set up among participants in a meeting where all hosts on the network
are trusted. Some additional security can be provided by using the are trusted. Some additional security can be provided by using the
shared secret admission control scheme as well. shared secret admission control scheme as well.
Because all stored data is signed by the owner of the data the Because all stored data is signed by the owner of the data the
storing peer can verify that the storer is authorized to perform a storing node can verify that the storer is authorized to perform a
store at that Resource-ID and also allow any consumer of the data to store at that Resource-ID and also allow any consumer of the data to
verify the provenance and integrity of the data when it retrieves it. verify the provenance and integrity of the data when it retrieves it.
Note that RELOAD does not itself provide a revocation/status Note that RELOAD does not itself provide a revocation/status
mechanism (though certificates may of course include OCSP responder mechanism (though certificates may of course include OCSP responder
information). Thus, certificate lifetimes should be chosen to information). Thus, certificate lifetimes should be chosen to
balance the compromise window versus the cost of certificate renewal. balance the compromise window versus the cost of certificate renewal.
Because RELOAD is already designed to operate in the face of some Because RELOAD is already designed to operate in the face of some
fraction of malicious peers, this form of compromise is not fatal. fraction of malicious nodes, this form of compromise is not fatal.
All implementations MUST implement certificate-based security. All implementations MUST implement certificate-based security.
13.4. Shared-Secret Security 13.4. Shared-Secret Security
RELOAD also supports a shared secret admission control scheme that RELOAD also supports a shared secret admission control scheme that
relies on a single key that is shared among all members of the relies on a single key that is shared among all members of the
overlay. It is appropriate for small groups that wish to form a overlay. It is appropriate for small groups that wish to form a
private network without complexity. In shared secret mode, all the private network without complexity. In shared secret mode, all the
peers share a single symmetric key which is used to key TLS-PSK peers share a single symmetric key which is used to key TLS-PSK
skipping to change at page 141, line 21 skipping to change at page 141, line 21
Resource-ID/Kind-ID pair is bound to some small set of certificates. Resource-ID/Kind-ID pair is bound to some small set of certificates.
In order to write data, the writer must prove possession of the In order to write data, the writer must prove possession of the
private key for one of those certificates. Moreover, all data is private key for one of those certificates. Moreover, all data is
stored, signed with the same private key that was used to authorize stored, signed with the same private key that was used to authorize
the storage. This set of rules makes questions of authorization and the storage. This set of rules makes questions of authorization and
data integrity - which have historically been thorny for overlays - data integrity - which have historically been thorny for overlays -
relatively simple. relatively simple.
13.5.1. Authorization 13.5.1. Authorization
When a client wants to store some value, it first digitally signs the When a node wants to store some value, it first digitally signs the
value with its own private key. It then sends a Store request that value with its own private key. It then sends a Store request that
contains both the value and the signature towards the storing peer contains both the value and the signature towards the storing peer
(which is defined by the Resource Name construction algorithm for (which is defined by the Resource Name construction algorithm for
that particular Kind of value). that particular Kind of value).
When the storing peer receives the request, it must determine whether When the storing peer receives the request, it must determine whether
the storing client is authorized to store at this Resource-ID/Kind-ID the storing node is authorized to store at this Resource-ID/Kind-ID
pair. Determining this requires comparing the user's identity to the pair. Determining this requires comparing the user's identity to the
requirements of the access control model (see Section 7.3). If it requirements of the access control model (see Section 7.3). If it
satisfies those requirements the user is authorized to write, pending satisfies those requirements the user is authorized to write, pending
quota checks as described in the next section. quota checks as described in the next section.
For example, consider the certificate with the following properties: For example, consider the certificate with the following properties:
User name: alice@dht.example.com User name: alice@dht.example.com
Node-ID: 013456789abcdef Node-ID: 013456789abcdef
Serial: 1234 Serial: 1234
If Alice wishes to Store a value of the "SIP Location" Kind, the If Alice wishes to Store a value of the "SIP Location" Kind, the
Resource Name will be the SIP AOR "sip:alice@dht.example.com". The Resource Name will be the SIP AOR "sip:alice@dht.example.com". The
Resource-ID will be determined by hashing the Resource Name. Because Resource-ID will be determined by hashing the Resource Name. Because
SIP Location uses the USER-NODE-MATCH policy, it first verifies that SIP Location uses the USER-NODE-MATCH policy, it first verifies that
the user name in the certificate hashes to the requested Resource-ID. the user name in the certificate hashes to the requested Resource-ID.
It then verifies that the Node-Id in the certificate matches the It then verifies that the Node-ID in the certificate matches the
dictionary key being used for the store. If both of these checks dictionary key being used for the store. If both of these checks
succeed, the Store is authorized. Note that because the access succeed, the Store is authorized. Note that because the access
control model is different for different Kinds, the exact set of control model is different for different Kinds, the exact set of
checks will vary. checks will vary.
13.5.2. Distributed Quota 13.5.2. Distributed Quota
Being a peer in an Overlay Instance carries with it the Being a peer in an Overlay Instance carries with it the
responsibility to store data for a given region of the Overlay responsibility to store data for a given region of the Overlay
Instance. However, allowing clients to store unlimited amounts of Instance. However, allowing nodes to store unlimited amounts of data
data would create unacceptable burdens on peers and would also enable would create unacceptable burdens on peers and would also enable
trivial denial of service attacks. RELOAD addresses this issue by trivial denial of service attacks. RELOAD addresses this issue by
requiring configurations to define maximum sizes for each Kind of requiring configurations to define maximum sizes for each Kind of
stored data. Attempts to store values exceeding this size MUST be stored data. Attempts to store values exceeding this size MUST be
rejected (if peers are inconsistent about this, then strange rejected (if peers are inconsistent about this, then strange
artifacts will happen when the zone of responsibility shifts and a artifacts will happen when the zone of responsibility shifts and a
different peer becomes responsible for overlarge data). Because each different peer becomes responsible for overlarge data). Because each
Resource-ID/Kind-ID pair is bound to a small set of certificates, Resource-ID/Kind-ID pair is bound to a small set of certificates,
these size restrictions also create a distributed quota mechanism, these size restrictions also create a distributed quota mechanism,
with the quotas administered by the central configuration server. with the quotas administered by the central configuration server.
Allowing different Kinds of data to have different size restrictions Allowing different Kinds of data to have different size restrictions
allows new usages the flexibility to define limits that fit their allows new usages the flexibility to define limits that fit their
needs without requiring all usages to have expansive limits. needs without requiring all usages to have expansive limits.
13.5.3. Correctness 13.5.3. Correctness
Because each stored value is signed, it is trivial for any retrieving Because each stored value is signed, it is trivial for any retrieving
peer to verify the integrity of the stored value. Some more care node to verify the integrity of the stored value. Some more care
needs to be taken to prevent version rollback attacks. Rollback needs to be taken to prevent version rollback attacks. Rollback
attacks on storage are prevented by the use of store times and attacks on storage are prevented by the use of store times and
lifetime values in each store. A lifetime represents the latest time lifetime values in each store. A lifetime represents the latest time
at which the data is valid and thus limits (though does not at which the data is valid and thus limits (though does not
completely prevent) the ability of the storing node to perform a completely prevent) the ability of the storing node to perform a
rollback attack on retrievers. In order to prevent a rollback attack rollback attack on retrievers. In order to prevent a rollback attack
at the time of the Store request, we require that storage times be at the time of the Store request, we require that storage times be
monotonically increasing. Storing peers MUST reject Store requests monotonically increasing. Storing peers MUST reject Store requests
with storage times smaller than or equal to those they are currently with storage times smaller than or equal to those they are currently
storing. In addition, a fetching node which receives a data value storing. In addition, a fetching node which receives a data value
with a storage time older than the result of the previous fetch knows with a storage time older than the result of the previous fetch knows
a rollback has occurred. a rollback has occurred.
13.5.4. Residual Attacks 13.5.4. Residual Attacks
The mechanisms described here provides a high degree of security, but The mechanisms described here provides a high degree of security, but
some attacks remain possible. Most simply, it is possible for some attacks remain possible. Most simply, it is possible for
storing nodes to refuse to store a value (i.e., reject any request). storing peers to refuse to store a value (i.e., reject any request).
In addition, a storing node can deny knowledge of values which it has In addition, a storing peer can deny knowledge of values which it has
previously accepted. To some extent these attacks can be ameliorated previously accepted. To some extent these attacks can be ameliorated
by attempting to store to/retrieve from replicas, but a retrieving by attempting to store to/retrieve from replicas, but a retrieving
client does not know whether it should try this or not, since there node does not know whether it should try this or not, since there is
is a cost to doing so. a cost to doing so.
The certificate-based authentication scheme prevents a single peer The certificate-based authentication scheme prevents a single peer
from being able to forge data owned by other peers. Furthermore, from being able to forge data owned by other peers. Furthermore,
although a subversive peer can refuse to return data resources for although a subversive peer can refuse to return data resources for
which it is responsible, it cannot return forged data because it which it is responsible, it cannot return forged data because it
cannot provide authentication for such registrations. Therefore cannot provide authentication for such registrations. Therefore
parallel searches for redundant registrations can mitigate most of parallel searches for redundant registrations can mitigate most of
the effects of a compromised peer. The ultimate reliability of such the effects of a compromised peer. The ultimate reliability of such
an overlay is a statistical question based on the replication factor an overlay is a statistical question based on the replication factor
and the percentage of compromised peers. and the percentage of compromised peers.
In addition, when a Kind is multivalued (e.g., an array data model), In addition, when a Kind is multivalued (e.g., an array data model),
the storing node can return only some subset of the values, thus the storing peer can return only some subset of the values, thus
biasing its responses. This can be countered by using single values biasing its responses. This can be countered by using single values
rather than sets, but that makes coordination between multiple rather than sets, but that makes coordination between multiple
storing agents much more difficult. This is a trade off that must be storing agents much more difficult. This is a trade off that must be
made when designing any usage. made when designing any usage.
13.6. Routing Security 13.6. Routing Security
Because the storage security system guarantees (within limits) the Because the storage security system guarantees (within limits) the
integrity of the stored data, routing security focuses on stopping integrity of the stored data, routing security focuses on stopping
the attacker from performing a DOS attack that misroutes requests in the attacker from performing a DOS attack that misroutes requests in
the overlay. There are a few obvious observations to make about the overlay. There are a few obvious observations to make about
this. First, it is easy to ensure that an attacker is at least a this. First, it is easy to ensure that an attacker is at least a
valid peer in the Overlay Instance. Second, this is a DOS attack valid node in the Overlay Instance. Second, this is a DOS attack
only. Third, if a large percentage of the peers on the Overlay only. Third, if a large percentage of the nodes on the Overlay
Instance are controlled by the attacker, it is probably impossible to Instance are controlled by the attacker, it is probably impossible to
perfectly secure against this. perfectly secure against this.
13.6.1. Background 13.6.1. Background
In general, attacks on DHT routing are mounted by the attacker In general, attacks on DHT routing are mounted by the attacker
arranging to route traffic through one or two nodes it controls. In arranging to route traffic through one or two nodes it controls. In
the Eclipse attack [Eclipse] the attacker tampers with messages to the Eclipse attack [Eclipse] the attacker tampers with messages to
and from nodes for which it is on-path with respect to a given victim and from nodes for which it is on-path with respect to a given victim
node. This allows it to pretend to be all the nodes that are node. This allows it to pretend to be all the nodes that are
skipping to change at page 144, line 8 skipping to change at page 144, line 8
Both the Eclipse and Sybil attacks require the attacker to be able to Both the Eclipse and Sybil attacks require the attacker to be able to
exercise control over her Node-IDs. The Sybil attack requires the exercise control over her Node-IDs. The Sybil attack requires the
creation of a large number of peers. The Eclipse attack requires creation of a large number of peers. The Eclipse attack requires
that the attacker be able to impersonate specific peers. In both that the attacker be able to impersonate specific peers. In both
cases, these attacks are limited by the use of centralized, cases, these attacks are limited by the use of centralized,
certificate-based admission control. certificate-based admission control.
13.6.2. Admissions Control 13.6.2. Admissions Control
Admission to a RELOAD Overlay Instance is controlled by requiring Admission to a RELOAD Overlay Instance is controlled by requiring
that each peer have a certificate containing its Node-Id. The that each peer have a certificate containing its Node-ID. The
requirement to have a certificate is enforced by using certificate- requirement to have a certificate is enforced by using certificate-
based mutual authentication on each connection. (Note: the based mutual authentication on each connection. (Note: the
following only applies when self-signed certificates are not used.) following only applies when self-signed certificates are not used.)
Whenever a peer connects to another peer, each side automatically Whenever a peer connects to another peer, each side automatically
checks that the other has a suitable certificate. These Node-Ids are checks that the other has a suitable certificate. These Node-IDs are
randomly assigned by the central enrollment server. This has two randomly assigned by the central enrollment server. This has two
benefits: benefits:
o It allows the enrollment server to limit the number of Node-IDs o It allows the enrollment server to limit the number of Node-IDs
issued to any individual user. issued to any individual user.
o It prevents the attacker from choosing specific Node-Ids. o It prevents the attacker from choosing specific Node-IDs.
The first property allows protection against Sybil attacks (provided The first property allows protection against Sybil attacks (provided
the enrollment server uses strict rate limiting policies). The the enrollment server uses strict rate limiting policies). The
second property deters but does not completely prevent Eclipse second property deters but does not completely prevent Eclipse
attacks. Because an Eclipse attacker must impersonate peers on the attacks. Because an Eclipse attacker must impersonate peers on the
other side of the attacker, he must have a certificate for suitable other side of the attacker, he must have a certificate for suitable
Node-Ids, which requires him to repeatedly query the enrollment Node-IDs, which requires him to repeatedly query the enrollment
server for new certificates, which will match only by chance. From server for new certificates, which will match only by chance. From
the attacker's perspective, the difficulty is that if he only has a the attacker's perspective, the difficulty is that if he only has a
small number of certificates, the region of the Overlay Instance he small number of certificates, the region of the Overlay Instance he
is impersonating appears to be very sparsely populated by comparison is impersonating appears to be very sparsely populated by comparison
to the victim's local region. to the victim's local region.
13.6.3. Peer Identification and Authentication 13.6.3. Peer Identification and Authentication
In general, whenever a peer engages in overlay activity that might In general, whenever a peer engages in overlay activity that might
affect the routing table it must establish its identity. This affect the routing table it must establish its identity. This
skipping to change at page 146, line 37 skipping to change at page 146, line 37
14.1. Well-Known URI Registration 14.1. Well-Known URI Registration
IANA SHALL make the following "Well Known URI" registration as IANA SHALL make the following "Well Known URI" registration as
described in [RFC5785]: described in [RFC5785]:
[[Note to RFC Editor - this paragraph can be removed before [[Note to RFC Editor - this paragraph can be removed before
publication. ]] A review request was sent to publication. ]] A review request was sent to
wellknown-uri-review@ietf.org on October 12, 2010. wellknown-uri-review@ietf.org on October 12, 2010.
+----------------------------+----------------------+ +----------------------------+----------------------+
| URI suffix: | p2psip-enroll | | URI suffix: | reload-config |
| Change controller: | IETF <iesg@ietf.org> | | Change controller: | IETF <iesg@ietf.org> |
| Specification document(s): | [RFC-AAAA] | | Specification document(s): | [RFC-AAAA] |
| Related information: | None | | Related information: | None |
+----------------------------+----------------------+ +----------------------------+----------------------+
14.2. Port Registrations 14.2. Port Registrations
[[Note to RFC Editor - this paragraph can be removed before [[Note to RFC Editor - this paragraph can be removed before
publication. ]] IANA has already allocated a TCP port for the main publication. ]] IANA has already allocated a TCP port for the main
peer to peer protocol. This port has the name p2p-sip and the port peer to peer protocol. This port has the name p2psip-enroll and the
number of 6084. IANA needs to update this registration to be defined port number of 6084. IANA needs to update this registration to
for UDP as well as TCP. change the service name to reload-config and to define it for UDP as
well as TCP.
IANA SHALL make the following port registration: IANA SHALL make the following port registration:
+------------------------------+------------------------------------+ +-----------------------------+-------------------------------------+
| Registration Technical | Cullen Jennings <fluffy@cisco.com> | | Registration Technical | Cullen Jennings <fluffy@cisco.com> |
| Contact | | | Contact | |
| Registration Owner | IETF <iesg@ietf.org> | | Registration Owner | IETF <iesg@ietf.org> |
| Transport Protocol | TCP & UDP | | Transport Protocol | TCP & UDP |
| Port Number | 6084 | | Port Number | 6084 |
| Service Name | p2psip-enroll | | Service Name | reload-config |
| Description | Peer to Peer Infrastructure | | Description | Peer to Peer Infrastructure |
| | Enrollment | | | Configuration |
| Reference | [RFC-AAAA] | +-----------------------------+-------------------------------------+
+------------------------------+------------------------------------+
14.3. Overlay Algorithm Types 14.3. Overlay Algorithm Types
IANA SHALL create a "RELOAD Overlay Algorithm Type" Registry. IANA SHALL create a "RELOAD Overlay Algorithm Type" Registry.
Entries in this registry are strings denoting the names of overlay Entries in this registry are strings denoting the names of overlay
algorithms. The registration policy for this registry is RFC 5226 algorithms. The registration policy for this registry is RFC 5226
IETF Review. The initial contents of this registry are: IETF Review. The initial contents of this registry are:
+----------------+----------+ +----------------+----------+
| Algorithm Name | RFC | | Algorithm Name | RFC |
skipping to change at page 158, line 16 skipping to change at page 158, line 16
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[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.
[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.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006.
[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.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, October 2006.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] 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", RFC 5245, Traversal for Offer/Answer Protocols", RFC 5245,
skipping to change at page 159, line 17 skipping to change at page 159, line 14
for Transport Layer Security (TLS) Authentication", for Transport Layer Security (TLS) Authentication",
RFC 6091, February 2011. RFC 6091, February 2011.
[RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,
"Computing TCP's Retransmission Timer", RFC 6298, "Computing TCP's Retransmission Timer", RFC 6298,
June 2011. June 2011.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012.
[w3c-xml-namespaces] [w3c-xml-namespaces]
Bray, T., Hollander, D., Layman, A., Tobin, R., and Henry Bray, T., Hollander, D., Layman, A., Tobin, R., and Henry
S. , "Namespaces in XML 1.0 (Third Edition)". S. , "Namespaces in XML 1.0 (Third Edition)".
16.2. Informative References 16.2. Informative References
[Chord] Stoica, I., Morris, R., Liben-Nowell, D., Karger, D., [Chord] Stoica, I., Morris, R., Liben-Nowell, D., Karger, D.,
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.
[Eclipse] Singh, A., Ngan, T., Druschel, T., and D. Wallach, [Eclipse] Singh, A., Ngan, T., Druschel, T., and D. Wallach,
"Eclipse Attacks on Overlay Networks: Threats and "Eclipse Attacks on Overlay Networks: Threats and
Defenses", INFOCOM 2006, April 2006. Defenses", INFOCOM 2006, April 2006.
[I-D.ietf-hip-reload-instance] [I-D.ietf-hip-reload-instance]
Keranen, A., Camarillo, G., and J. Maenpaa, "Host Identity Keranen, A., Camarillo, G., and J. Maenpaa, "Host Identity
Protocol-Based Overlay Networking Environment (HIP BONE) Protocol-Based Overlay Networking Environment (HIP BONE)
Instance Specification for REsource LOcation And Discovery Instance Specification for REsource LOcation And Discovery
(RELOAD)", draft-ietf-hip-reload-instance-04 (work in (RELOAD)", draft-ietf-hip-reload-instance-05 (work in
progress), October 2011. progress), April 2012.
[I-D.ietf-mmusic-ice-tcp]
Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach,
"TCP Candidates with Interactive Connectivity
Establishment (ICE)", draft-ietf-mmusic-ice-tcp-16 (work
in progress), November 2011.
[I-D.ietf-p2psip-diagnostics] [I-D.ietf-p2psip-diagnostics]
Bryan, D., Jiang, X., Even, R., and H. Song, "P2PSIP Song, H., Jiang, X., Even, R., and D. Bryan, "P2PSIP
Overlay Diagnostics", draft-ietf-p2psip-diagnostics-08 Overlay Diagnostics", draft-ietf-p2psip-diagnostics-09
(work in progress), December 2011. (work in progress), August 2012.
[I-D.ietf-p2psip-rpr]
Zong, N., Jiang, X., Even, R., and Y. Zhang, "An extension
to RELOAD to support Relay Peer Routing",
draft-ietf-p2psip-rpr-03 (work in progress), October 2012.
[I-D.ietf-p2psip-self-tuning] [I-D.ietf-p2psip-self-tuning]
Maenpaa, J., Camarillo, G., and J. Hautakorpi, "A Self- Maenpaa, J., Camarillo, G., and J. Hautakorpi, "A Self-
tuning Distributed Hash Table (DHT) for REsource LOcation tuning Distributed Hash Table (DHT) for REsource LOcation
And Discovery (RELOAD)", draft-ietf-p2psip-self-tuning-05 And Discovery (RELOAD)", draft-ietf-p2psip-self-tuning-06
(work in progress), January 2012. (work in progress), July 2012.
[I-D.ietf-p2psip-service-discovery] [I-D.ietf-p2psip-service-discovery]
Maenpaa, J. and G. Camarillo, "Service Discovery Usage for Maenpaa, J. and G. Camarillo, "Service Discovery Usage for
REsource LOcation And Discovery (RELOAD)", REsource LOcation And Discovery (RELOAD)",
draft-ietf-p2psip-service-discovery-04 (work in progress), draft-ietf-p2psip-service-discovery-06 (work in progress),
January 2012. October 2012.
[I-D.ietf-p2psip-sip] [I-D.ietf-p2psip-sip]
Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
H. Schulzrinne, "A SIP Usage for RELOAD", H. Schulzrinne, "A SIP Usage for RELOAD",
draft-ietf-p2psip-sip-07 (work in progress), January 2012. draft-ietf-p2psip-sip-07 (work in progress), January 2012.
[I-D.jiang-p2psip-relay]
Jiang, X., Zong, N., Even, R., and Y. Zhang, "An extension
to RELOAD to support Direct Response and Relay Peer
routing", draft-jiang-p2psip-relay-05 (work in progress),
March 2011.
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
[RFC2311] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and [RFC2311] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and
L. Repka, "S/MIME Version 2 Message Specification", L. Repka, "S/MIME Version 2 Message Specification",
RFC 2311, March 1998. RFC 2311, March 1998.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
skipping to change at page 161, line 32 skipping to change at page 161, line 25
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
Uniform Resource Identifiers (URIs)", RFC 5785, Uniform Resource Identifiers (URIs)", RFC 5785,
April 2010. April 2010.
[RFC6079] Camarillo, G., Nikander, P., Hautakorpi, J., Keranen, A., [RFC6079] Camarillo, G., Nikander, P., Hautakorpi, J., Keranen, A.,
and A. Johnston, "HIP BONE: Host Identity Protocol (HIP) and A. Johnston, "HIP BONE: Host Identity Protocol (HIP)
Based Overlay Networking Environment (BONE)", RFC 6079, Based Overlay Networking Environment (BONE)", RFC 6079,
January 2011. January 2011.
[RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach,
"TCP Candidates with Interactive Connectivity
Establishment (ICE)", RFC 6544, March 2012.
[Sybil] Douceur, J., "The Sybil Attack", IPTPS 02, March 2002. [Sybil] Douceur, J., "The Sybil Attack", IPTPS 02, March 2002.
[UnixTime] [UnixTime]
Wikipedia, "Unix Time", <http:/wikipedia.org/wiki/ Wikipedia, "Unix Time", <http:/wikipedia.org/wiki/
Unix_time>. Unix_time>.
[bryan-design-hotp2p08] [bryan-design-hotp2p08]
Bryan, D., Lowekamp, B., and M. Zangrilli, "The Design of Bryan, D., Lowekamp, B., and M. Zangrilli, "The Design of
a Versatile, Secure P2PSIP Communications Architecture for a Versatile, Secure P2PSIP Communications Architecture for
the Public Internet", Hot-P2P'08. the Public Internet", Hot-P2P'08.
skipping to change at page 164, line 36 skipping to change at page 164, line 36
An extension to RELOAD that supports direct response routing but An extension to RELOAD that supports direct response routing but
relies on symmetric responses as a fallback would be possible, but relies on symmetric responses as a fallback would be possible, but
due to the complexities of determining when to use direct response due to the complexities of determining when to use direct response
and when to fallback to symmetric, and the reduced performance for and when to fallback to symmetric, and the reduced performance for
responses to peers behind restrictive NATs, we have chosen not to responses to peers behind restrictive NATs, we have chosen not to
include it as an option at this point. include it as an option at this point.
A.4. Relay Peers A.4. Relay Peers
[I-D.jiang-p2psip-relay] has proposed implementing a form of direct [I-D.ietf-p2psip-rpr] has proposed implementing a form of direct
response by having A identify a peer, Q, that will be directly response by having A identify a peer, Q, that will be directly
reachable by any other peer. A uses Attach to establish a connection reachable by any other peer. A uses Attach to establish a connection
with Q and advertises Q's IP address in the request sent to Z. Z with Q and advertises Q's IP address in the request sent to Z. Z
sends the response to Q, which relays it to A. This then reduces the sends the response to Q, which relays it to A. This then reduces the
latency to two hops, plus Z negotiating a secure connection to Q. latency to two hops, plus Z negotiating a secure connection to Q.
This technique relies on the relative population of nodes such as A This technique relies on the relative population of nodes such as A
that require relay peers and peers such as Q that are capable of that require relay peers and peers such as Q that are capable of
serving as a relay peer. It also requires nodes to be able to serving as a relay peer. It also requires nodes to be able to
identify which category they are in. This identification problem has identify which category they are in. This identification problem has
 End of changes. 192 change blocks. 
302 lines changed or deleted 302 lines changed or added

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