diff options
Diffstat (limited to 'doc/rfc/rfc7787.txt')
| -rw-r--r-- | doc/rfc/rfc7787.txt | 2299 |
1 files changed, 2299 insertions, 0 deletions
diff --git a/doc/rfc/rfc7787.txt b/doc/rfc/rfc7787.txt new file mode 100644 index 0000000..696e3a0 --- /dev/null +++ b/doc/rfc/rfc7787.txt @@ -0,0 +1,2299 @@ + + + + + + +Internet Engineering Task Force (IETF) M. Stenberg +Request for Comments: 7787 S. Barth +Category: Standards Track Independent +ISSN: 2070-1721 April 2016 + + + Distributed Node Consensus Protocol + +Abstract + + This document describes the Distributed Node Consensus Protocol + (DNCP), a generic state synchronization protocol that uses the + Trickle algorithm and hash trees. DNCP is an abstract protocol and + must be combined with a specific profile to make a complete + implementable protocol. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7787. + +Copyright Notice + + Copyright (c) 2016 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + + + +Stenberg & Barth Standards Track [Page 1] + +RFC 7787 Distributed Node Consensus Protocol April 2016 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 8 + 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 4.1. Hash Tree . . . . . . . . . . . . . . . . . . . . . . . . 9 + 4.1.1. Calculating Network State and Node Data Hashes . . . 10 + 4.1.2. Updating Network State and Node Data Hashes . . . . . 10 + 4.2. Data Transport . . . . . . . . . . . . . . . . . . . . . 10 + 4.3. Trickle-Driven Status Updates . . . . . . . . . . . . . . 12 + 4.4. Processing of Received TLVs . . . . . . . . . . . . . . . 13 + 4.5. Discovering, Adding, and Removing Peers . . . . . . . . . 15 + 4.6. Data Liveliness Validation . . . . . . . . . . . . . . . 16 + 5. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 6. Optional Extensions . . . . . . . . . . . . . . . . . . . . . 19 + 6.1. Keep-Alives . . . . . . . . . . . . . . . . . . . . . . . 19 + 6.1.1. Data Model Additions . . . . . . . . . . . . . . . . 20 + 6.1.2. Per-Endpoint Periodic Keep-Alives . . . . . . . . . . 20 + 6.1.3. Per-Peer Periodic Keep-Alives . . . . . . . . . . . . 20 + 6.1.4. Received TLV Processing Additions . . . . . . . . . . 21 + 6.1.5. Peer Removal . . . . . . . . . . . . . . . . . . . . 21 + 6.2. Support for Dense Multicast-Enabled Links . . . . . . . . 21 + 7. Type-Length-Value Objects . . . . . . . . . . . . . . . . . . 22 + 7.1. Request TLVs . . . . . . . . . . . . . . . . . . . . . . 23 + 7.1.1. Request Network State TLV . . . . . . . . . . . . . . 23 + 7.1.2. Request Node State TLV . . . . . . . . . . . . . . . 24 + 7.2. Data TLVs . . . . . . . . . . . . . . . . . . . . . . . . 24 + 7.2.1. Node Endpoint TLV . . . . . . . . . . . . . . . . . . 24 + 7.2.2. Network State TLV . . . . . . . . . . . . . . . . . . 25 + 7.2.3. Node State TLV . . . . . . . . . . . . . . . . . . . 25 + 7.3. Data TLVs within Node State TLV . . . . . . . . . . . . . 26 + 7.3.1. Peer TLV . . . . . . . . . . . . . . . . . . . . . . 26 + 7.3.2. Keep-Alive Interval TLV . . . . . . . . . . . . . . . 27 + 8. Security and Trust Management . . . . . . . . . . . . . . . . 27 + 8.1. Trust Method Based on Pre-Shared Key . . . . . . . . . . 27 + 8.2. PKI-Based Trust Method . . . . . . . . . . . . . . . . . 28 + 8.3. Certificate-Based Trust Consensus Method . . . . . . . . 28 + 8.3.1. Trust Verdicts . . . . . . . . . . . . . . . . . . . 28 + 8.3.2. Trust Cache . . . . . . . . . . . . . . . . . . . . . 29 + 8.3.3. Announcement of Verdicts . . . . . . . . . . . . . . 30 + 8.3.4. Bootstrap Ceremonies . . . . . . . . . . . . . . . . 31 + 9. DNCP Profile-Specific Definitions . . . . . . . . . . . . . . 32 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 34 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 + + + + +Stenberg & Barth Standards Track [Page 2] + +RFC 7787 Distributed Node Consensus Protocol April 2016 + + + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 36 + 12.2. Informative References . . . . . . . . . . . . . . . . . 36 + Appendix A. Alternative Modes of Operation . . . . . . . . . . . 38 + A.1. Read-Only Operation . . . . . . . . . . . . . . . . . . . 38 + A.2. Forwarding Operation . . . . . . . . . . . . . . . . . . 38 + Appendix B. DNCP Profile Additional Guidance . . . . . . . . . . 38 + B.1. Unicast Transport -- UDP or TCP? . . . . . . . . . . . . 38 + B.2. (Optional) Multicast Transport . . . . . . . . . . . . . 39 + B.3. (Optional) Transport Security . . . . . . . . . . . . . . 39 + Appendix C. Example Profile . . . . . . . . . . . . . . . . . . 40 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 41 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 + +1. Introduction + + DNCP is designed to provide a way for each participating node to + publish a small set of TLV (Type-Length-Value) tuples (at most 64 KB) + and to provide a shared and common view about the data published by + every currently bidirectionally reachable DNCP node in a network. + + For state synchronization, a hash tree is used. It is formed by + first calculating a hash for the data set published by each node, + called node data, and then calculating another hash over those node + data hashes. The single resulting hash, called network state hash, + is transmitted using the Trickle algorithm [RFC6206] to ensure that + all nodes share the same view of the current state of the published + data within the network. The use of Trickle with only short network + state hashes sent infrequently (in steady state, once the maximum + Trickle interval per link or unicast connection has been reached) + makes DNCP very thrifty when updates happen rarely. + + For maintaining liveliness of the topology and the data within it, a + combination of Trickled network state, keep-alives, and "other" means + of ensuring reachability are used. The core idea is that if every + node ensures its peers are present, transitively, the whole network + state also stays up to date. + + + + + + + + + + + + + + +Stenberg & Barth Standards Track [Page 3] + +RFC 7787 Distributed Node Consensus Protocol April 2016 + + +1.1. Applicability + + DNCP is useful for cases like autonomous bootstrapping, discovery, + and negotiation of embedded network devices like routers. + Furthermore, it can be used as a basis to run distributed algorithms + like [RFC7596] or use cases as described in Appendix C. DNCP is + abstract, which allows it to be tuned to a variety of applications by + defining profiles. These profiles include choices of: + + - unicast transport: a datagram or stream-oriented protocol (e.g., + TCP, UDP, or the Stream Control Transmission Protocol (SCTP)) for + generic protocol operation. + + - optional transport security: whether and when to use security + based on Transport Layer Security (TLS) or Datagram Transport + Layer Security (DTLS), if supported over the chosen transport. + + - optional multicast transport: a multicast-capable protocol like + UDP allowing autonomous peer discovery or more efficient use of + multiple access links. + + - communication scopes: using either hop by hop only relying on + link-local addressing (e.g., for LANs), addresses with broader + scopes (e.g., over WANs or the Internet) relying on an existing + routing infrastructure, or a combination of both (e.g., to + exchange state between multiple LANs over a WAN or the Internet). + + - payloads: additional specific payloads (e.g., IANA standardized, + enterprise-specific, or private use). + + - extensions: possible protocol extensions, either as predefined in + this document or specific for a particular use case. + + However, there are certain cases where the protocol as defined in + this document is a less suitable choice. This list provides an + overview while the following paragraphs provide more detailed + guidance on the individual matters. + + - large amounts of data: nodes are limited to 64 KB of published + data. + + - very dense unicast-only networks: nodes include information about + all immediate neighbors as part of their published data. + + - predominantly minimal data changes: node data is always + transported as is, leading to a relatively large transmission + overhead for changes affecting only a small part of it. + + + + +Stenberg & Barth Standards Track [Page 4] + +RFC 7787 Distributed Node Consensus Protocol April 2016 + + + - frequently changing data: DNCP with its use of Trickle is + optimized for the steady state and less efficient otherwise. + + - large amounts of very constrained nodes: DNCP requires each node + to store the entirety of the data published by all nodes. + + The topology of the devices is not limited and automatically + discovered. When relying on link-local communication exclusively, + all links having DNCP nodes need to be at least transitively + connected by routers running the protocol on multiple endpoints in + order to form a connected network. However, there is no requirement + for every device in a physical network to run the protocol. + Especially if globally scoped addresses are used, DNCP peers do not + need to be on the same or even neighboring physical links. + Autonomous discovery features are usually used in local network + scenarios; however, with security enabled, DNCP can also be used over + unsecured public networks. Network size is restricted merely by the + capabilities of the devices, i.e., each DNCP node needs to be able to + store the entirety of the data published by all nodes. The data + associated with each individual node identifier is limited to about + 64 KB in this document; however, protocol extensions could be defined + to mitigate this or other protocol limitations if the need arises. + + DNCP is most suitable for data that changes only infrequently to gain + the maximum benefit from using Trickle. As the network of nodes + grows, or the frequency of data changes per node increases, Trickle + is eventually used less and less, and the benefit of using DNCP + diminishes. In these cases, Trickle just provides extra complexity + within the specification and little added value. + + The suitability of DNCP for a particular application can be roughly + evaluated by considering the expected average network-wide state + change interval A_NC_I; it is computed by dividing the mean interval + at which a node originates a new TLV set by the number of + participating nodes. If keep-alives are used, A_NC_I is the minimum + of the computed A_NC_I and the keep-alive interval. If A_NC_I is + less than the (application-specific) Trickle minimum interval, DNCP + is most likely unsuitable for the application as Trickle will not be + utilized most of the time. + + If constant rapid state changes are needed, the preferable choice is + to use an additional point-to-point channel whose address or locator + is published using DNCP. Nevertheless, if doing so does not raise + A_NC_I above the (sensibly chosen) Trickle interval parameters for a + particular application, using DNCP is probably not suitable for the + application. + + + + + +Stenberg & Barth Standards Track [Page 5] + +RFC 7787 Distributed Node Consensus Protocol April 2016 + + + Another consideration is the size of the published TLV set by a node + compared to the size of deltas in the TLV set. If the TLV set + published by a node is very large, and has frequent small changes, + DNCP as currently specified in this specification may be unsuitable + as it lacks a delta synchronization scheme to keep implementation + simple. + + DNCP can be used in networks where only unicast transport is + available. While DNCP uses the least amount of bandwidth when + multicast is utilized, even in pure unicast mode, the use of Trickle + (ideally with k < 2) results in a protocol with an exponential + backoff timer and fewer transmissions than a simpler protocol not + using Trickle. + +2. Terminology + + DNCP profile the values for the set of parameters given in + Section 9. They are prefixed with DNCP_ in this + document. The profile also specifies the set of + optional DNCP extensions to be used. For a simple + example DNCP profile, see Appendix C. + + DNCP-based a protocol that provides a DNCP profile, according + protocol to Section 9, and zero or more TLV assignments from + the per-DNCP profile TLV registry as well as their + processing rules. + + DNCP node a single node that runs a DNCP-based protocol. + + Link a link-layer media over which directly connected + nodes can communicate. + + DNCP network a set of DNCP nodes running a DNCP-based + protocol(s) with a matching DNCP profile(s). The + set consists of nodes that have discovered each + other using the transport method defined in the + DNCP profile, via multicast on local links, and/or + by using unicast communication. + + Node identifier an opaque fixed-length identifier consisting of + DNCP_NODE_IDENTIFIER_LENGTH bytes that uniquely + identifies a DNCP node within a DNCP network. + + Interface a node's attachment to a particular link. + + Address an identifier used as the source or destination of + a DNCP message flow, e.g., a tuple (IPv6 address, + UDP port) for an IPv6 UDP transport. + + + +Stenberg & Barth Standards Track [Page 6] + +RFC 7787 Distributed Node Consensus Protocol April 2016 + + + Endpoint a locally configured termination point for + (potential or established) DNCP message flows. An + endpoint is the source and destination for separate + unicast message flows to individual nodes and + optionally for multicast messages to all thereby + reachable nodes (e.g., for node discovery). + Endpoints are usually in one of the transport modes + specified in Section 4.2. + + Endpoint a 32-bit opaque and locally unique value, which + identifier identifies a particular endpoint of a particular + DNCP node. The value 0 is reserved for DNCP and + DNCP-based protocol purposes and not used to + identify an actual endpoint. This definition is in + sync with the interface index definition in + [RFC3493], as the non-zero small positive integers + should comfortably fit within 32 bits. + + Peer another DNCP node with which a DNCP node + communicates using at least one particular local + and remote endpoint pair. + + Node data a set of TLVs published and owned by a node in the + DNCP network. Other nodes pass it along as is, + even if they cannot fully interpret it. + + Origination time the (estimated) time when the node data set with + the current sequence number was published. + + Node state a set of metadata attributes for node data. It + includes a sequence number for versioning, a hash + value for comparing equality of stored node data, + and a timestamp indicating the time passed since + its last publication (i.e., since the origination + time). The hash function and the length of the + hash value are defined in the DNCP profile. + + Network state a hash value that represents the current state of + hash the network. The hash function and the length of + the hash value are defined in the DNCP profile. + Whenever a node is added, removed, or updates its + published node data, this hash value changes as + well. For calculation, please see Section 4.1. + + Trust verdict a statement about the trustworthiness of a + certificate announced by a node participating in + the certificate-based trust consensus mechanism. + + + + +Stenberg & Barth Standards Track [Page 7] + +RFC 7787 Distributed Node Consensus Protocol April 2016 + + + Effective trust the trust verdict with the highest priority within + verdict the set of trust verdicts announced for the + certificate in the DNCP network. + + Topology graph the undirected graph of DNCP nodes produced by + retaining only bidirectional peer relationships + between nodes. + + Bidirectionally a peer is locally unidirectionally reachable if a + reachable consistent multicast or any unicast DNCP message + has been received by the local node (see Section + 4.5). If said peer in return also considers the + local node unidirectionally reachable, then + bidirectionally reachability is established. As + this process is based on publishing peer + relationships and evaluating the resulting topology + graph as described in Section 4.6, this information + is available to the whole DNCP network. + + Trickle instance a distinct Trickle [RFC6206] algorithm state kept + by a node (Section 5) and related to an endpoint or + a particular (peer, endpoint) tuple with Trickle + variables I, t, and c. See Section 4.3. + +2.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in RFC + 2119 [RFC2119]. + +3. Overview + + DNCP operates primarily using unicast exchanges between nodes, and it + may use multicast for Trickle-based shared state dissemination and + topology discovery. If used in pure unicast mode with unreliable + transport, Trickle is also used between peers. + + DNCP is based on exchanging TLVs (Section 7) and defines a set of + mandatory and optional ones for its operation. They are categorized + into TLVs for requesting information (Section 7.1), transmitting data + (Section 7.2), and being published as data (Section 7.3). DNCP-based + protocols usually specify additional ones to extend the capabilities. + + DNCP discovers the topology of the nodes in the DNCP network and + maintains the liveliness of published node data by ensuring that the + publishing node is bidirectionally reachable. New potential peers + can be discovered autonomously on multicast-enabled links; their + + + +Stenberg & Barth Standards Track [Page 8] + +RFC 7787 Distributed Node Consensus Protocol April 2016 + + + addresses may be manually configured or they may be found by some + other means defined in the particular DNCP profile. The DNCP profile + may specify, for example, a well-known anycast address or provision + the remote address to contact via some other protocol such as DHCPv6 + [RFC3315]. + + A hash tree of height 1, rooted in itself, is maintained by each node + to represent the state of all currently reachable nodes (see + Section 4.1), and the Trickle algorithm is used to trigger + synchronization (see Section 4.3). The need to check peer nodes for + state changes is thereby determined by comparing the current root of + their respective hash trees, i.e., their individually calculated + network state hashes. + + Before joining a DNCP network, a node starts with a hash tree that + has only one leaf if the node publishes some TLVs, and no leaves + otherwise. It then announces the network state hash calculated from + the hash tree by means of the Trickle algorithm on all its configured + endpoints. + + When an update is detected by a node (e.g., by receiving a different + network state hash from a peer), the originator of the event is + requested to provide a list of the state of all nodes, i.e., all the + information it uses to calculate its own hash tree. The node uses + the list to determine whether its own information is outdated and -- + if necessary -- requests the actual node data that has changed. + + Whenever a node's local copy of any node data and its hash tree are + updated (e.g., due to its own or another node's node state changing + or due to a peer being added or removed), its Trickle instances are + reset, which eventually causes any update to be propagated to all of + its peers. + +4. Operation + +4.1. Hash Tree + + Each DNCP node maintains an arbitrary width hash tree of height 1. + The root of the tree represents the overall network state hash and is + used to determine whether the view of the network of two or more + nodes is consistent and shared. Each leaf represents one + bidirectionally reachable DNCP node. Every time a node is added or + removed from the topology graph (Section 4.6), it is likewise added + or removed as a leaf. At any time, the leaves of the tree are + ordered in ascending order of the node identifiers of the nodes they + represent. + + + + + +Stenberg & Barth Standards Track [Page 9] + +RFC 7787 Distributed Node Consensus Protocol April 2016 + + +4.1.1. Calculating Network State and Node Data Hashes + + The network state hash and the node data hashes are calculated using + the hash function defined in the DNCP profile (Section 9) and + truncated to the number of bits specified therein. + + Individual node data hashes are calculated by applying the function + and truncation on the respective node's node data as published in the + Node State TLV. Such node data sets are always ordered as defined in + Section 7.2.3. + + The network state hash is calculated by applying the function and + truncation on the concatenated network state. This state is formed + by first concatenating each node's sequence number (in network byte + order) with its node data hash to form a per-node datum for each + node. These per-node data are then concatenated in ascending order + of the respective node's node identifier, i.e., in the order that the + nodes appear in the hash tree. + +4.1.2. Updating Network State and Node Data Hashes + + The network state hash and the node data hashes are updated on-demand + and whenever any locally stored per-node state changes. This + includes local unidirectional reachability encoded in the published + Peer TLVs (Section 7.3.1) and -- when combined with remote data -- + results in awareness of bidirectional reachability changes. + +4.2. Data Transport + + DNCP has few requirements for the underlying transport; it requires + some way of transmitting either a unicast datagram or stream data to + a peer and, if used in multicast mode, a way of sending multicast + datagrams. As multicast is used only to identify potential new DNCP + nodes and to send status messages that merely notify that a unicast + exchange should be triggered, the multicast transport does not have + to be secured. If unicast security is desired and one of the + built-in security methods is to be used, support for some TLS-derived + transport scheme -- such as TLS [RFC5246] on top of TCP or DTLS + [RFC6347] on top of UDP -- is also required. They provide for + integrity protection and confidentiality of the node data, as well as + authentication and authorization using the schemes defined in + "Security and Trust Management" (Section 8). A specific definition + of the transport(s) in use and its parameters MUST be provided by the + DNCP profile. + + TLVs (Section 7) are sent across the transport as is, and they SHOULD + be sent together where, e.g., MTU considerations do not recommend + sending them in multiple batches. DNCP does not fragment or + + + +Stenberg & Barth Standards Track [Page 10] + +RFC 7787 Distributed Node Consensus Protocol April 2016 + + + reassemble TLVs; thus, it MUST be ensured that the underlying + transport performs these operations should they be necessary. If + this document indicates sending one or more TLVs, then the sending + node does not need to keep track of the packets sent after handing + them over to the respective transport, i.e., reliable DNCP operation + is ensured merely by the explicitly defined timers and state machines + such as Trickle (Section 4.3). TLVs in general are handled + individually and statelessly (and thus do not need to be sent in any + particular order) with one exception: To form bidirectional peer + relationships, DNCP requires identification of the endpoints used for + communication. As bidirectional peer relationships are required for + validating liveliness of published node data as described in + Section 4.6, a DNCP node MUST send a Node Endpoint TLV + (Section 7.2.1). When it is sent varies, depending on the underlying + transport, but conceptually it should be available whenever + processing a Network State TLV: + + o If using a stream transport, the TLV MUST be sent at least once + per connection but SHOULD NOT be sent more than once. + + o If using a datagram transport, it MUST be included in every + datagram that also contains a Network State TLV (Section 7.2.2) + and MUST be located before any such TLV. It SHOULD also be + included in any other datagram to speed up initial peer detection. + + Given the assorted transport options as well as potential endpoint + configuration, a DNCP endpoint may be used in various transport + modes: + + Unicast: + + * If only reliable unicast transport is used, Trickle is not used + at all. Whenever the locally calculated network state hash + changes, a single Network State TLV (Section 7.2.2) is sent to + every unicast peer. Additionally, recently changed Node State + TLVs (Section 7.2.3) MAY be included. + + * If only unreliable unicast transport is used, Trickle state is + kept per peer, and it is used to send Network State TLVs + intermittently, as specified in Section 4.3. + + Multicast+Unicast: If multicast datagram transport is available on + an endpoint, Trickle state is only maintained for the endpoint as + a whole. It is used to send Network State TLVs periodically, as + specified in Section 4.3. Additionally, per-endpoint keep-alives + MAY be defined in the DNCP profile, as specified in Section 6.1.2. + + + + + +Stenberg & Barth Standards Track [Page 11] + +RFC 7787 Distributed Node Consensus Protocol April 2016 + + + MulticastListen+Unicast: Just like unicast, except multicast + transmissions are listened to in order to detect changes of the + highest node identifier. This mode is used only if the DNCP + profile supports dense multicast-enabled link optimization + (Section 6.2). + +4.3. Trickle-Driven Status Updates + + The Trickle algorithm [RFC6206] is used to ensure protocol + reliability over unreliable multicast or unicast transports. For + reliable unicast transports, its actual algorithm is unnecessary and + omitted (Section 4.2). DNCP maintains multiple Trickle states as + defined in Section 5. Each such state can be based on different + parameters (see below) and is responsible for ensuring that a + specific peer or all peers on the respective endpoint are regularly + provided with the node's current locally calculated network state + hash for state comparison, i.e., to detect potential divergence in + the perceived network state. + + Trickle defines 3 parameters: Imin, Imax, and k. Imin and Imax + represent the minimum value for I and the maximum number of doublings + of Imin, where I is the time interval during which at least k Trickle + updates must be seen on an endpoint to prevent local state + transmission. The actual suggested Trickle algorithm parameters are + DNCP profile specific, as described in Section 9. + + The Trickle state for all Trickle instances defined in Section 5 is + considered inconsistent and reset if and only if the locally + calculated network state hash changes. This occurs either due to a + change in the local node's own node data or due to the receipt of + more recent data from another node as explained in Section 4.1. A + node MUST NOT reset its Trickle state merely based on receiving a + Network State TLV (Section 7.2.2) with a network state hash that is + different from its locally calculated one. + + Every time a particular Trickle instance indicates that an update + should be sent, the node MUST send a Network State TLV + (Section 7.2.2) if and only if: + + o the endpoint is in Multicast+Unicast transport mode, in which case + the TLV MUST be sent over multicast. + + o the endpoint is NOT in Multicast+Unicast transport mode, and the + unicast transport is unreliable, in which case the TLV MUST be + sent over unicast. + + + + + + +Stenberg & Barth Standards Track [Page 12] + +RFC 7787 Distributed Node Consensus Protocol April 2016 + + + A (sub)set of all Node State TLVs (Section 7.2.3) MAY also be + included, unless it is defined as undesirable for some reason by the + DNCP profile or to avoid exposure of the node state TLVs by + transmitting them within insecure multicast when using secure + unicast. + +4.4. Processing of Received TLVs + + This section describes how received TLVs are processed. The DNCP + profile may specify when to ignore particular TLVs, e.g., to modify + security properties -- see Section 9 for what may be safely defined + to be ignored in a profile. Any 'reply' mentioned in the steps below + denotes the sending of the specified TLV(s) to the originator of the + TLV being processed. All such replies MUST be sent using unicast. + If the TLV being replied to was received via multicast and it was + sent to a multiple access link, the reply MUST be delayed by a random + time span in [0, Imin/2], to avoid potential simultaneous replies + that may cause problems on some links, unless specified differently + in the DNCP profile. The sending of replies MAY also be rate limited + or omitted for a short period of time by an implementation. However, + if the TLV is not forbidden by the DNCP profile, an implementation + MUST reply to retransmissions of the TLV with a non-zero probability + to avoid starvation, which would break the state synchronization. + + A DNCP node MUST process TLVs received from any valid (e.g., + correctly scoped) address, as specified by the DNCP profile and the + configuration of a particular endpoint, whether this address is known + to be the address of a peer or not. This provision satisfies the + needs of monitoring or other host software that needs to discover the + DNCP topology without adding to the state in the network. + + Upon receipt of: + + o Request Network State TLV (Section 7.1.1): The receiver MUST reply + with a Network State TLV (Section 7.2.2) and a Node State TLV + (Section 7.2.3) for each node data used to calculate the network + state hash. The Node State TLVs SHOULD NOT contain the optional + node data part to avoid redundant transmission of node data, + unless explicitly specified in the DNCP profile. + + o Request Node State TLV (Section 7.1.2): If the receiver has node + data for the corresponding node, it MUST reply with a Node State + TLV (Section 7.2.3) for the corresponding node. The optional node + data part MUST be included in the TLV. + + o Network State TLV (Section 7.2.2): If the network state hash + differs from the locally calculated network state hash, and the + receiver is unaware of any particular node state differences with + + + +Stenberg & Barth Standards Track [Page 13] + +RFC 7787 Distributed Node Consensus Protocol April 2016 + + + the sender, the receiver MUST reply with a Request Network State + TLV (Section 7.1.1). These replies MUST be rate limited to only + at most one reply per link per unique network state hash within + Imin. The simplest way to ensure this rate limit is a timestamp + indicating requests and sending at most one Request Network State + TLV (Section 7.1.1) per Imin. To facilitate faster state + synchronization, if a Request Network State TLV is sent in a + reply, a local, current Network State TLV MAY also be sent. + + o Node State TLV (Section 7.2.3): + + * If the node identifier matches the local node identifier and + the TLV has a greater sequence number than its current local + value, or the same sequence number and a different hash, the + node SHOULD republish its own node data with a sequence number + significantly greater than the received one (e.g., 1000) to + reclaim the node identifier. This difference is needed in + order to ensure that it is higher than any potentially + lingering copies of the node state in the network. This may + occur normally once due to the local node restarting and not + storing the most recently used sequence number. If this occurs + more than once or for nodes not republishing their own node + data, the DNCP profile MUST provide guidance on how to handle + these situations as it indicates the existence of another + active node with the same node identifier. + + * If the node identifier does not match the local node + identifier, and one or more of the following conditions are + true: + + + The local information is outdated for the corresponding node + (the local sequence number is less than that within the + TLV). + + + The local information is potentially incorrect (the local + sequence number matches but the node data hash differs). + + + There is no data for that node altogether. + + Then: + + + If the TLV contains the Node Data field, it SHOULD also be + verified by ensuring that the locally calculated hash of the + node data matches the content of the H(Node Data) field + within the TLV. If they differ, the TLV SHOULD be ignored + and not processed further. + + + + + +Stenberg & Barth Standards Track [Page 14] + +RFC 7787 Distributed Node Consensus Protocol April 2016 + + + + If the TLV does not contain the Node Data field, and the + H(Node Data) field within the TLV differs from the local + node data hash for that node (or there is none), the + receiver MUST reply with a Request Node State TLV + (Section 7.1.2) for the corresponding node. + + + Otherwise, the receiver MUST update its locally stored state + for that node (node data based on the Node Data field if + present, sequence number, and relative time) to match the + received TLV. + + For comparison purposes of the sequence number, a looping + comparison function MUST be used to avoid problems in case of + overflow. The comparison function a < b <=> ((a - b) % (2^32)) & + (2^31) != 0 where (a % b) represents the remainder of a modulo b + and (a & b) represents bitwise conjunction of a and b is + RECOMMENDED unless the DNCP profile defines another. + + o Any other TLV: TLVs not recognized by the receiver MUST be + silently ignored unless they are sent within another TLV (for + example, TLVs within the Node Data field of a Node State TLV). + TLVs within the Node Data field of the Node State TLV not + recognized by the receiver MUST be retained for distribution to + other nodes and for calculation of the node data hash as described + in Section 7.2.3 but are ignored for other purposes. + + If secure unicast transport is configured for an endpoint, any Node + State TLVs received over insecure multicast MUST be silently ignored. + +4.5. Discovering, Adding, and Removing Peers + + Peer relations are established between neighbors using one or more + mutually connected endpoints. Such neighbors exchange information + about network state and published data directly, and through + transitivity, this information then propagates throughout the + network. + + New peers are discovered using the regular unicast or multicast + transport defined in the DNCP profile (Section 9). This process is + not distinguished from peer addition, i.e., an unknown peer is simply + discovered by receiving regular DNCP protocol TLVs from it, and + dedicated discovery messages or TLVs do not exist. For unicast-only + transports, the individual node's transport addresses are + preconfigured or obtained using an external service discovery + protocol. In the presence of a multicast transport, messages from + unknown peers are handled in the same way as multicast messages from + peers that are already known; thus, new peers are simply discovered + when sending their regular DNCP protocol TLVs using multicast. + + + +Stenberg & Barth Standards Track [Page 15] + +RFC 7787 Distributed Node Consensus Protocol April 2016 + + + When receiving a Node Endpoint TLV (Section 7.2.1) on an endpoint + from an unknown peer: + + o If received over unicast, the remote node MUST be added as a peer + on the endpoint, and a Peer TLV (Section 7.3.1) MUST be created + for it. + + o If received over multicast, the node MAY be sent a (possibly rate- + limited) unicast Request Network State TLV (Section 7.1.1). + + If keep-alives specified in Section 6.1 are NOT sent by the peer + (either the DNCP profile does not specify the use of keep-alives or + the particular peer chooses not to send keep-alives), some other + existing local transport-specific means (such as Ethernet carrier + detection or TCP keep-alive) MUST be used to ensure its presence. If + the peer does not send keep-alives, and no means to verify presence + of the peer are available, the peer MUST be considered no longer + present, and it SHOULD NOT be added back as a peer until it starts + sending keep-alives again. When the peer is no longer present, the + Peer TLV and the local DNCP peer state MUST be removed. DNCP does + not define an explicit message or TLV for indicating the termination + of DNCP operation by the terminating node; however, a derived + protocol could specify an extension, if the need arises. + + If the local endpoint is in the Multicast-Listen+Unicast transport + mode, a Peer TLV (Section 7.3.1) MUST NOT be published for the peers + not having the highest node identifier. + +4.6. Data Liveliness Validation + + Maintenance of the hash tree (Section 4.1) and thereby network state + hash updates depend on up-to-date information on bidirectional node + reachability derived from the contents of a topology graph. This + graph changes whenever nodes are added to or removed from the network + or when bidirectional connectivity between existing nodes is + established or lost. Therefore, the graph MUST be updated either + immediately or with a small delay shorter than the DNCP profile- + defined Trickle Imin whenever: + + o A Peer TLV or a whole node is added or removed, or + + o The origination time (in milliseconds) of some node's node data is + less than current time - 2^32 + 2^15. + + The artificial upper limit for the origination time is used to + gracefully avoid overflows of the origination time and allow for the + node to republish its data as noted in Section 7.2.3. + + + + +Stenberg & Barth Standards Track [Page 16] + +RFC 7787 Distributed Node Consensus Protocol April 2016 + + + The topology graph update starts with the local node marked as + reachable and all other nodes marked as unreachable. Other nodes are + then iteratively marked as reachable using the following algorithm: A + candidate not-yet-reachable node N with an endpoint NE is marked as + reachable if there is a reachable node R with an endpoint RE that + meets all of the following criteria: + + o The origination time (in milliseconds) of R's node data is greater + than current time - 2^32 + 2^15. + + o R publishes a Peer TLV with: + + * Peer Node Identifier = N's node identifier + + * Peer Endpoint Identifier = NE's endpoint identifier + + * Endpoint Identifier = RE's endpoint identifier + + o N publishes a Peer TLV with: + + * Peer Node Identifier = R's node identifier + + * Peer Endpoint Identifier = RE's endpoint identifier + + * Endpoint Identifier = NE's endpoint identifier + + The algorithm terminates when no more candidate nodes fulfilling + these criteria can be found. + + DNCP nodes that have not been reachable in the most recent topology + graph traversal MUST NOT be used for calculation of the network state + hash, be provided to any applications that need to use the whole TLV + graph, or be provided to remote nodes. They MAY be forgotten + immediately after the topology graph traversal; however, it is + RECOMMENDED to keep them at least briefly to improve the speed of + DNCP network state convergence. This reduces the number of queries + needed to reconverge during both initial network convergence and when + a part of the network loses and regains bidirectional connectivity + within that time period. + +5. Data Model + + This section describes the local data structures a minimal + implementation might use. This section is provided only as a + convenience for the implementor. Some of the optional extensions + (Section 6) describe additional data requirements, and some optional + parts of the core protocol may also require more. + + + + +Stenberg & Barth Standards Track [Page 17] + +RFC 7787 Distributed Node Consensus Protocol April 2016 + + + A DNCP node has: + + o A data structure containing data about the most recently sent + Request Network State TLVs (Section 7.1.1). The simplest option + is keeping a timestamp of the most recent request (required to + fulfill reply rate limiting specified in Section 4.4). + + A DNCP node has the following for every DNCP node in the DNCP + network: + + o Node identifier: the unique identifier of the node. The length, + how it is produced, and how collisions are handled is up to the + DNCP profile. + + o Node data: the set of TLV tuples published by that particular + node. As they are transmitted in a particular order (see Node + State TLV (Section 7.2.3) for details), maintaining the order + within the data structure here may be reasonable. + + o Latest sequence number: the 32-bit sequence number that is + incremented any time the TLV set is published. The comparison + function used to compare them is described in Section 4.4. + + o Origination time: the (estimated) time when the current TLV set + with the current sequence number was published. It is used to + populate the Milliseconds Since Origination field in a Node State + TLV (Section 7.2.3). Ideally, it also has millisecond accuracy. + + Additionally, a DNCP node has a set of endpoints for which DNCP is + configured to be used. For each such endpoint, a node has: + + o Endpoint identifier: the 32-bit opaque locally unique value + identifying the endpoint within a node. It SHOULD NOT be reused + immediately after an endpoint is disabled. + + o Trickle instance: the endpoint's Trickle instance with parameters + I, T, and c (only on an endpoint in Multicast+Unicast transport + mode). + + and one (or more) of the following: + + o Interface: the assigned local network interface. + + o Unicast address: the DNCP node it should connect with. + + o Set of addresses: the DNCP nodes from which connections are + accepted. + + + + +Stenberg & Barth Standards Track [Page 18] + +RFC 7787 Distributed Node Consensus Protocol April 2016 + + + For each remote (peer, endpoint) pair detected on a local endpoint, a + DNCP node has: + + o Node identifier: the unique identifier of the peer. + + o Endpoint identifier: the unique endpoint identifier used by the + peer. + + o Peer address: the most recently used address of the peer + (authenticated and authorized, if security is enabled). + + o Trickle instance: the particular peer's Trickle instance with + parameters I, T, and c (only on an endpoint in unicast mode, when + using an unreliable unicast transport). + +6. Optional Extensions + + This section specifies extensions to the core protocol that a DNCP + profile may specify to be used. + +6.1. Keep-Alives + + While DNCP provides mechanisms for discovery and adding new peers on + an endpoint (Section 4.5), as well as state change notifications, + another mechanism may be needed to get rid of old, no longer valid + peers if the transport or lower layers do not provide one as noted in + Section 4.6. + + If keep-alives are not specified in the DNCP profile, the rest of + this subsection MUST be ignored. + + A DNCP profile MAY specify either per-endpoint (sent using multicast + to all DNCP nodes connected to a multicast-enabled link) or per-peer + (sent using unicast to each peer individually) keep-alive support. + + For every endpoint that a keep-alive is specified for in the DNCP + profile, the endpoint-specific keep-alive interval MUST be + maintained. By default, it is DNCP_KEEPALIVE_INTERVAL. If there is + a local value that is preferred for that for any reason + (configuration, energy conservation, media type, ...), it can be + substituted instead. If a non-default keep-alive interval is used on + any endpoint, a DNCP node MUST publish an appropriate Keep-Alive + Interval TLV(s) (Section 7.3.2) within its node data. + + + + + + + + +Stenberg & Barth Standards Track [Page 19] + +RFC 7787 Distributed Node Consensus Protocol April 2016 + + +6.1.1. Data Model Additions + + The following additions to the Data Model (Section 5) are needed to + support keep-alives: + + For each configured endpoint that has per-endpoint keep-alives + enabled: + + o Last sent: If a timestamp that indicates the last time a Network + State TLV (Section 7.2.2) was sent over that interface. + + For each remote (peer, endpoint) pair detected on a local endpoint, a + DNCP node has: + + o Last contact timestamp: A timestamp that indicates the last time a + consistent Network State TLV (Section 7.2.2) was received from the + peer over multicast or when anything was received over unicast. + Failing to update it for a certain amount of time as specified in + Section 6.1.5 results in the removal of the peer. When adding a + new peer, it is initialized to the current time. + + o Last sent: If per-peer keep-alives are enabled, a timestamp that + indicates the last time a Network State TLV (Section 7.2.2) was + sent to that point-to-point peer. When adding a new peer, it is + initialized to the current time. + +6.1.2. Per-Endpoint Periodic Keep-Alives + + If per-endpoint keep-alives are enabled on an endpoint in + Multicast+Unicast transport mode, and if no traffic containing a + Network State TLV (Section 7.2.2) has been sent to a particular + endpoint within the endpoint-specific keep-alive interval, a Network + State TLV (Section 7.2.2) MUST be sent on that endpoint, and a new + Trickle interval started, as specified in step 2 of Section 4.2 of + [RFC6206]. The actual sending time SHOULD be further delayed by a + random time span in [0, Imin/2]. + +6.1.3. Per-Peer Periodic Keep-Alives + + If per-peer keep-alives are enabled on a unicast-only endpoint, and + if no traffic containing a Network State TLV (Section 7.2.2) has been + sent to a particular peer within the endpoint-specific keep-alive + interval, a Network State TLV (Section 7.2.2) MUST be sent to the + peer, and a new Trickle interval started, as specified in step 2 of + Section 4.2 of [RFC6206]. + + + + + + +Stenberg & Barth Standards Track [Page 20] + +RFC 7787 Distributed Node Consensus Protocol April 2016 + + +6.1.4. Received TLV Processing Additions + + If a TLV is received over unicast from the peer, the Last contact + timestamp for the peer MUST be updated. + + On receipt of a Network State TLV (Section 7.2.2) that is consistent + with the locally calculated network state hash, the Last contact + timestamp for the peer MUST be updated in order to maintain it as a + peer. + +6.1.5. Peer Removal + + For every peer on every endpoint, the endpoint-specific keep-alive + interval must be calculated by looking for Keep-Alive Interval TLVs + (Section 7.3.2) published by the node, and if none exist, use the + default value of DNCP_KEEPALIVE_INTERVAL. If the peer's Last contact + timestamp has not been updated for at least a locally chosen + potentially endpoint-specific keep-alive multiplier (defaults to + DNCP_KEEPALIVE_MULTIPLIER) times the peer's endpoint-specific keep- + alive interval, the Peer TLV for that peer and the local DNCP peer + state MUST be removed. + +6.2. Support for Dense Multicast-Enabled Links + + This optimization is needed to avoid a state space explosion. Given + a large set of DNCP nodes publishing data on an endpoint that uses + multicast on a link, every node will add a Peer TLV (Section 7.3.1) + for each peer. While Trickle limits the amount of traffic on the + link in stable state to some extent, the total amount of data that is + added to and maintained in the DNCP network given N nodes on a + multicast-enabled link is O(N^2). Additionally, if per-peer keep- + alives are used, there will be O(N^2) keep-alives running on the link + if the liveliness of peers is not ensured using some other way (e.g., + TCP connection lifetime, Layer 2 notification, or per-endpoint keep- + alive). + + An upper bound for the number of peers that are allowed for a + particular type of link that an endpoint in Multicast+Unicast + transport mode is used on SHOULD be provided by a DNCP profile, but + it MAY also be chosen at runtime. The main consideration when + selecting a bound (if any) for a particular type of link should be + whether it supports multicast traffic and whether a too large number + of peers case is likely to happen during the use of that DNCP profile + on that particular type of link. If neither is likely, there is + little point specifying support for this for that particular link + type. + + + + + +Stenberg & Barth Standards Track [Page 21] + +RFC 7787 Distributed Node Consensus Protocol April 2016 + + + If a DNCP profile does not support this extension at all, the rest of + this subsection MUST be ignored. This is because when this extension + is used, the state within the DNCP network only contains a subset of + the full topology of the network. Therefore, every node must be + aware of the potential of it being used in a particular DNCP profile. + + If the specified upper bound is exceeded for some endpoint in + Multicast+Unicast transport mode and if the node does not have the + highest node identifier on the link, it SHOULD treat the endpoint as + a unicast endpoint connected to the node that has the highest node + identifier detected on the link, therefore transitioning to + Multicast-listen+Unicast transport mode. See Section 4.2 for + implications on the specific endpoint behavior. The nodes in + Multicast-listen+Unicast transport mode MUST keep listening to + multicast traffic to both receive messages from the node(s) still in + Multicast+Unicast mode and react to nodes with a greater node + identifier appearing. If the highest node identifier present on the + link changes, the remote unicast address of the endpoints in + Multicast-Listen+Unicast transport mode MUST be changed. If the node + identifier of the local node is the highest one, the node MUST switch + back to, or stay in, Multicast+Unicast mode and form peer + relationships with all peers as specified in Section 4.5. + +7. Type-Length-Value Objects + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value (if any) (+padding (if any)) | + .. + | (variable # of bytes) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | (optional nested TLVs) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Each TLV is encoded as: + + o a 2-byte Type field + + o a 2-byte Length field, which contains the length of the Value + field in bytes; 0 means no value + + o the value itself (if any) + + o padding bytes with a value of zero up to the next 4-byte boundary + if the Length is not divisible by 4 + + + +Stenberg & Barth Standards Track [Page 22] + +RFC 7787 Distributed Node Consensus Protocol April 2016 + + + While padding bytes MUST NOT be included in the number stored in the + Length field of the TLV, if the TLV is enclosed within another TLV, + then the padding is included in the enclosing TLV's Length value. + + Each TLV that does not define optional fields or variable-length + content MAY be sent with additional sub-TLVs appended after the TLV + to allow for extensibility. When handling such TLV types, each node + MUST accept received TLVs that are longer than the fixed fields + specified for the particular type and ignore the sub-TLVs with either + unknown types or types not supported within that particular TLV. If + any sub-TLVs are present, the Length field of the TLV describes the + number of bytes from the first byte of the TLV's own Value (if any) + to the last (padding) byte of the last sub-TLV. + + For example, type=123 (0x7b) TLV with value 'x' (120 = 0x78) is + encoded as: 007B 0001 7800 0000. If it were to have a sub-TLV of + type=124 (0x7c) with value 'y', it would be encoded as 007B 000C 7800 + 0000 007C 0001 7900 0000. + + In this section, the following special notation is used: + + .. = octet string concatenation operation. + + H(x) = non-cryptographic hash function specified by the DNCP + profile. + + In addition to the TLV types defined in this document, TLV Types + 11-31 and 512-767 are unassigned and may be sequentially registered, + starting at 11, by Standards Action [RFC5226] by extensions to DNCP + that may be applicable in multiple DNCP profiles. + +7.1. Request TLVs + +7.1.1. Request Network State TLV + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |Type: Request network state (1)| Length: >= 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + This TLV is used to request response with a Network State TLV + (Section 7.2.2) and all Node State TLVs (Section 7.2.3) (without node + data). + + + + + + + +Stenberg & Barth Standards Track [Page 23] + +RFC 7787 Distributed Node Consensus Protocol April 2016 + + +7.1.2. Request Node State TLV + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type: Request node state (2) | Length: > 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Node Identifier | + | (length fixed in DNCP profile) | + ... + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + This TLV is used to request a Node State TLV (Section 7.2.3) + (including node data) for the node with the matching node identifier. + +7.2. Data TLVs + +7.2.1. Node Endpoint TLV + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type: Node endpoint (3) | Length: > 4 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Node Identifier | + | (length fixed in DNCP profile) | + ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Endpoint Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + This TLV identifies both the local node's node identifier, as well as + the particular endpoint's endpoint identifier. Section 4.2 specifies + when it is sent. + + + + + + + + + + + + + + + + +Stenberg & Barth Standards Track [Page 24] + +RFC 7787 Distributed Node Consensus Protocol April 2016 + + +7.2.2. Network State TLV + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type: Network state (4) | Length: > 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | H(sequence number of node 1 .. H(node data of node 1) .. | + | .. sequence number of node N .. H(node data of node N)) | + | (length fixed in DNCP profile) | + ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + This TLV contains the current network state hash calculated by its + sender (Section 4.1 describes the algorithm). + +7.2.3. Node State TLV + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type: Node state (5) | Length: > 8 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Node Identifier | + | (length fixed in DNCP profile) | + ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sequence Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Milliseconds Since Origination | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | H(Node Data) | + | (length fixed in DNCP profile) | + ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | (optionally) Node Data (a set of nested TLVs) | + ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + This TLV represents the local node's knowledge about the published + state of a node in the DNCP network identified by the Node Identifier + field in the TLV. + + Every node, including the node publishing the node data, MUST update + the Milliseconds Since Origination whenever it sends a Node State TLV + based on when the node estimates the data was originally published. + This is, e.g., to ensure that any relative timestamps contained + within the published node data can be correctly offset and + + + +Stenberg & Barth Standards Track [Page 25] + +RFC 7787 Distributed Node Consensus Protocol April 2016 + + + interpreted. Ultimately, what is provided is just an approximation, + as transmission delays are not accounted for. + + Absent any changes, if the originating node notices that the 32-bit + Milliseconds Since Origination value would be close to overflow + (greater than 2^32 - 2^16), the node MUST republish its TLVs even if + there is no change. In other words, absent any other changes, the + TLV set MUST be republished roughly every 48 days. + + The actual node data of the node may be included within the TLV as + well as in the optional Node Data field. The set of TLVs MUST be + strictly ordered based on ascending binary content (including TLV + type and length). This enables, e.g., efficient state delta + processing and no-copy indexing by TLV type by the recipient. The + node data content MUST be passed along exactly as it was received. + It SHOULD be also verified on receipt that the locally calculated + H(Node Data) matches the content of the field within the TLV, and if + the hash differs, the TLV SHOULD be ignored. + +7.3. Data TLVs within Node State TLV + + These TLVs are published by the DNCP nodes and are therefore only + encoded in the Node Data field of Node State TLVs. If encountered + outside Node State TLV, they MUST be silently ignored. + +7.3.1. Peer TLV + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type: Peer (8) | Length: > 8 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Peer Node Identifier | + | (length fixed in DNCP profile) | + ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Peer Endpoint Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | (Local) Endpoint Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + This TLV indicates that the node in question vouches that the + specified peer is reachable by it on the specified local endpoint. + The presence of this TLV at least guarantees that the node publishing + it has received traffic from the peer recently. For guaranteed up- + to-date bidirectional reachability, the existence of both nodes' + matching Peer TLVs needs to be checked. + + + + +Stenberg & Barth Standards Track [Page 26] + +RFC 7787 Distributed Node Consensus Protocol April 2016 + + +7.3.2. Keep-Alive Interval TLV + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type: Keep-alive interval (9) | Length: >= 8 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Endpoint Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Interval | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + This TLV indicates a non-default interval being used to send keep- + alives as specified in Section 6.1. + + Endpoint identifier is used to identify the particular (local) + endpoint for which the interval applies on the sending node. If 0, + it applies for ALL endpoints for which no specific TLV exists. + + Interval specifies the interval in milliseconds at which the node + sends keep-alives. A value of zero means no keep-alives are sent at + all; in that case, some lower-layer mechanism that ensures the + presence of nodes MUST be available and used. + +8. Security and Trust Management + + If specified in the DNCP profile, either DTLS [RFC6347] or TLS + [RFC5246] may be used to authenticate and encrypt either some (if + specified optional in the profile) or all unicast traffic. The + following methods for establishing trust are defined, but it is up to + the DNCP profile to specify which ones may, should, or must be + supported. + +8.1. Trust Method Based on Pre-Shared Key + + A trust model based on Pre-Shared Key (PSK) is a simple security + management mechanism that allows an administrator to deploy devices + to an existing network by configuring them with a predefined key, + similar to the configuration of an administrator password or Wi-Fi + Protected Access (WPA) key. Although limited in nature, it is useful + to provide a user-friendly security mechanism for smaller networks. + + + + + + + + + + +Stenberg & Barth Standards Track [Page 27] + +RFC 7787 Distributed Node Consensus Protocol April 2016 + + +8.2. PKI-Based Trust Method + + A PKI-based trust model enables more advanced management capabilities + at the cost of increased complexity and bootstrapping effort. + However, it allows trust to be managed in a centralized manner and is + therefore useful for larger networks with a need for an authoritative + trust management. + +8.3. Certificate-Based Trust Consensus Method + + For some scenarios -- such as bootstrapping a mostly unmanaged + network -- the methods described above may not provide a desirable + trade-off between security and user experience. This section + includes guidance for implementing an opportunistic security + [RFC7435] method that DNCP profiles can build upon and adapt for + their specific requirements. + + The certificate-based consensus model is designed to be a compromise + between trust management effort and flexibility. It is based on + X.509 certificates and allows each DNCP node to provide a trust + verdict on any other certificate, and a consensus is found to + determine whether a node using this certificate or any certificate + signed by it is to be trusted. + + A DNCP node not using this security method MUST ignore all announced + trust verdicts and MUST NOT announce any such verdicts by itself, + i.e., any other normative language in this subsection does not apply + to it. + + The current effective trust verdict for any certificate is defined as + the one with the highest priority from all trust verdicts announced + for said certificate at the time. + +8.3.1. Trust Verdicts + + Trust verdicts are statements of DNCP nodes about the trustworthiness + of X.509 certificates. There are 5 possible trust verdicts in order + of ascending priority: + + 0 (Neutral): no trust verdict exists, but the DNCP network should + determine one. + + 1 (Cached Trust): the last known effective trust verdict was + Configured or Cached Trust. + + 2 (Cached Distrust): the last known effective trust verdict was + Configured or Cached Distrust. + + + + +Stenberg & Barth Standards Track [Page 28] + +RFC 7787 Distributed Node Consensus Protocol April 2016 + + + 3 (Configured Trust): trustworthy based upon an external ceremony + or configuration. + + 4 (Configured Distrust): not trustworthy based upon an external + ceremony or configuration. + + Trust verdicts are differentiated in 3 groups: + + o Configured verdicts are used to announce explicit trust verdicts a + node has based on any external trust bootstrap or predefined + relations a node has formed with a given certificate. + + o Cached verdicts are used to retain the last known trust state in + case all nodes with configured verdicts about a given certificate + have been disconnected or turned off. + + o The Neutral verdict is used to announce a new node intending to + join the network, so a final verdict for it can be found. + + The current effective trust verdict for any certificate is defined as + the one with the highest priority within the set of trust verdicts + announced for the certificate in the DNCP network. A node MUST be + trusted for participating in the DNCP network if and only if the + current effective trust verdict for its own certificate or any one in + its certificate hierarchy is (Cached or Configured) Trust, and none + of the certificates in its hierarchy have an effective trust verdict + of (Cached or Configured) Distrust. In case a node has a configured + verdict, which is different from the current effective trust verdict + for a certificate, the current effective trust verdict takes + precedence in deciding trustworthiness. Despite that, the node still + retains and announces its configured verdict. + +8.3.2. Trust Cache + + Each node SHOULD maintain a trust cache containing the current + effective trust verdicts for all certificates currently announced in + the DNCP network. This cache is used as a backup of the last known + state in case there is no node announcing a configured verdict for a + known certificate. It SHOULD be saved to a non-volatile memory at + reasonable time intervals to survive a reboot or power outage. + + Every time a node (re)joins the network or detects the change of an + effective trust verdict for any certificate, it will synchronize its + cache, i.e., store new effective trust verdicts overwriting any + previously cached verdicts. Configured verdicts are stored in the + cache as their respective cached counterparts. Neutral verdicts are + never stored and do not override existing cached verdicts. + + + + +Stenberg & Barth Standards Track [Page 29] + +RFC 7787 Distributed Node Consensus Protocol April 2016 + + +8.3.3. Announcement of Verdicts + + A node SHOULD always announce any configured verdicts it has + established by itself, and it MUST do so if announcing the configured + verdict leads to a change in the current effective trust verdict for + the respective certificate. In absence of configured verdicts, it + MUST announce Cached Trust verdicts it has stored in its trust cache, + if one of the following conditions applies: + + o The stored trust verdict is Cached Trust, and the current + effective trust verdict for the certificate is Neutral or does not + exist. + + o The stored trust verdict is Cached Distrust, and the current + effective trust verdict for the certificate is Cached Trust. + + A node rechecks these conditions whenever it detects changes of + announced trust verdicts anywhere in the network. + + Upon encountering a node with a hierarchy of certificates for which + there is no effective trust verdict, a node adds a Neutral Trust- + Verdict TLV to its node data for all certificates found in the + hierarchy and publishes it until an effective trust verdict different + from Neutral can be found for any of the certificates, or a + reasonable amount of time (10 minutes is suggested) with no reaction + and no further authentication attempts has passed. Such trust + verdicts SHOULD also be limited in rate and number to prevent + denial-of-service attacks. + + + + + + + + + + + + + + + + + + + + + + + +Stenberg & Barth Standards Track [Page 30] + +RFC 7787 Distributed Node Consensus Protocol April 2016 + + + Trust verdicts are announced using Trust-Verdict TLVs: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type: Trust-Verdict (10) | Length: > 36 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Verdict | (reserved) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | | + | | + | SHA-256 Fingerprint | + | | + | | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Common Name | + + Verdict represents the numerical index of the trust verdict. + + (reserved) is reserved for future additions and MUST be set to 0 + when creating TLVs and ignored when parsing them. + + SHA-256 Fingerprint contains the SHA-256 [RFC6234] hash value of + the certificate in DER format. + + Common name contains the variable-length (1-64 bytes) common name + of the certificate. + +8.3.4. Bootstrap Ceremonies + + The following non-exhaustive list of methods describes possible ways + to establish trust relationships between DNCP nodes and node + certificates. Trust establishment is a two-way process in which the + existing network must trust the newly added node, and the newly added + node must trust at least one of its peer nodes. It is therefore + necessary that both the newly added node and an already trusted node + perform such a ceremony to successfully introduce a node into the + DNCP network. In all cases, an administrator MUST be provided with + external means to identify the node belonging to a certificate based + on its fingerprint and a meaningful common name. + + + + + + + + +Stenberg & Barth Standards Track [Page 31] + +RFC 7787 Distributed Node Consensus Protocol April 2016 + + +8.3.4.1. Trust by Identification + + A node implementing certificate-based trust MUST provide an interface + to retrieve the current set of effective trust verdicts, + fingerprints, and names of all certificates currently known and set + configured verdicts to be announced. Alternatively, it MAY provide a + companion DNCP node or application with these capabilities with which + it has a pre-established trust relationship. + +8.3.4.2. Preconfigured Trust + + A node MAY be preconfigured to trust a certain set of node or CA + certificates. However, such trust relationships MUST NOT result in + unwanted or unrelated trust for nodes not intended to be run inside + the same network (e.g., all other devices by the same manufacturer). + +8.3.4.3. Trust on Button Press + + A node MAY provide a physical or virtual interface to put one or more + of its internal network interfaces temporarily into a mode in which + it trusts the certificate of the first DNCP node it can successfully + establish a connection with. + +8.3.4.4. Trust on First Use + + A node that is not associated with any other DNCP node MAY trust the + certificate of the first DNCP node it can successfully establish a + connection with. This method MUST NOT be used when the node has + already associated with any other DNCP node. + +9. DNCP Profile-Specific Definitions + + Each DNCP profile MUST specify the following aspects: + + o Unicast and optionally a multicast transport protocol(s) to be + used. If a multicast-based node and status discovery is desired, + a datagram-based transport supporting multicast has to be + available. + + o How the chosen transport(s) is secured: Not at all, optionally, or + always with the TLS scheme defined here using one or more of the + methods, or with something else. If the links with DNCP nodes can + be sufficiently secured or isolated, it is possible to run DNCP in + a secure manner without using any form of authentication or + encryption. + + + + + + +Stenberg & Barth Standards Track [Page 32] + +RFC 7787 Distributed Node Consensus Protocol April 2016 + + + o Transport protocols' parameters such as port numbers to be used or + multicast addresses to be used. Unicast, multicast, and secure + unicast may each require different parameters, if applicable. + + o When receiving TLVs, what sort of TLVs are ignored in addition -- + as specified in Section 4.4 -- e.g., for security reasons. While + the security of the node data published within the Node State TLVs + is already ensured by the base specification (if secure unicast + transport is used, Node State TLVs are sent only via unicast as + multicast ones are ignored on receipt), if a profile adds TLVs + that are sent outside the node data, a profile should indicate + whether or not those TLVs should be ignored if they are received + via multicast or non-secured unicast. A DNCP profile may define + the following DNCP TLVs to be safely ignored: + + * Anything received over multicast, except Node Endpoint TLV + (Section 7.2.1) and Network State TLV (Section 7.2.2). + + * Any TLVs received over unreliable unicast or multicast at a + rate that is that is too high; Trickle will ensure eventual + convergence given the rate slows down at some point. + + o How to deal with node identifier collision as described in + Section 4.4. Main options are either for one or both nodes to + assign new node identifiers to themselves or to notify someone + about a fatal error condition in the DNCP network. + + o Imin, Imax, and k ranges to be suggested for implementations to be + used in the Trickle algorithm. The Trickle algorithm does not + require these to be the same across all implementations for it to + work, but similar orders of magnitude help implementations of a + DNCP profile to behave more consistently and to facilitate + estimation of lower and upper bounds for convergence behavior of + the network. + + o Hash function H(x) to be used, and how many bits of the output are + actually used. The chosen hash function is used to handle both + hashing of node data and producing network state hash, which is a + hash of node data hashes. SHA-256 defined in [RFC6234] is the + recommended default choice, but a non-cryptographic hash function + could be used as well. If there is a hash collision in the + network state hash, the network will effectively be partitioned to + partitions that believe they are up to date but are actually no + longer converged. The network will converge either when some node + data anywhere in the network changes or when conflicting Node + State TLVs get transmitted across the partition (either caused by + "Trickle-Driven Status Updates" (Section 4.3) or as part of the + "Processing of Received TLVs" (Section 4.4)). If a node publishes + + + +Stenberg & Barth Standards Track [Page 33] + +RFC 7787 Distributed Node Consensus Protocol April 2016 + + + node data with a hash that collides with any previously published + node data, the update may not be (fully) propagated, and the old + version of node data may be used instead. + + o DNCP_NODE_IDENTIFIER_LENGTH: The fixed length of a node identifier + (in bytes). + + o Whether to send keep-alives, and if so, whether it is per-endpoint + (requires multicast transport) or per-peer. Keep-alive also has + associated parameters: + + * DNCP_KEEPALIVE_INTERVAL: How often keep-alives are to be sent + by default (if enabled). + + * DNCP_KEEPALIVE_MULTIPLIER: How many times the + DNCP_KEEPALIVE_INTERVAL (or peer-supplied keep-alive interval + value) node may not be heard from to be considered still valid. + This is just a default used in absence of any other + configuration information or particular per-endpoint + configuration. + + o Whether to support dense multicast-enabled link optimization + (Section 6.2) or not. + + For some guidance on choosing transport and security options, please + see Appendix B. + +10. Security Considerations + + DNCP-based protocols may use multicast to indicate DNCP state changes + and for keep-alive purposes. However, no actual published data TLVs + will be sent across that channel. Therefore, an attacker may only + learn hash values of the state within DNCP and may be able to trigger + unicast synchronization attempts between nodes on a local link this + way. A DNCP node MUST therefore rate limit its reactions to + multicast packets. + + When using DNCP to bootstrap a network, PKI-based solutions may have + issues when validating certificates due to potentially unavailable + accurate time or due to the inability to use the network to either + check Certificate Revocation Lists or perform online validation. + + The Certificate-based trust consensus mechanism defined in this + document allows for a consenting revocation; however, in case of a + compromised device, the trust cache may be poisoned before the actual + revocation happens allowing the distrusted device to rejoin the + network using a different identity. Stopping such an attack might + require physical intervention and flushing of the trust caches. + + + +Stenberg & Barth Standards Track [Page 34] + +RFC 7787 Distributed Node Consensus Protocol April 2016 + + +11. IANA Considerations + + IANA has set up a registry for the (decimal 16-bit) "DNCP TLV Types" + under "Distributed Node Consensus Protocol (DNCP)". The registration + procedure is Standards Action [RFC5226]. The initial contents are: + + 0: Reserved + + 1: Request network state + + 2: Request node state + + 3: Node endpoint + + 4: Network state + + 5: Node state + + 6: Reserved for future use (was: Custom) + + 7: Reserved for future use (was: Fragment count) + + 8: Peer + + 9: Keep-alive interval + + 10: Trust-Verdict + + 11-31: Unassigned + + 32-511: Reserved for per-DNCP profile use + + 512-767: Unassigned + + 768-1023: Reserved for Private Use [RFC5226] + + 1024-65535: Reserved for future use + + + + + + + + + + + + + + +Stenberg & Barth Standards Track [Page 35] + +RFC 7787 Distributed Node Consensus Protocol April 2016 + + +12. References + +12.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <http://www.rfc-editor.org/info/rfc2119>. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + DOI 10.17487/RFC5226, May 2008, + <http://www.rfc-editor.org/info/rfc5226>. + + [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, + "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, + March 2011, <http://www.rfc-editor.org/info/rfc6206>. + + [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms + (SHA and SHA-based HMAC and HKDF)", RFC 6234, + DOI 10.17487/RFC6234, May 2011, + <http://www.rfc-editor.org/info/rfc6234>. + +12.2. Informative References + + [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, + C., and M. Carney, "Dynamic Host Configuration Protocol + for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July + 2003, <http://www.rfc-editor.org/info/rfc3315>. + + [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. + Stevens, "Basic Socket Interface Extensions for IPv6", + RFC 3493, DOI 10.17487/RFC3493, February 2003, + <http://www.rfc-editor.org/info/rfc3493>. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, + DOI 10.17487/RFC5246, August 2008, + <http://www.rfc-editor.org/info/rfc5246>. + + [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer + Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, + January 2012, <http://www.rfc-editor.org/info/rfc6347>. + + [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection + Most of the Time", RFC 7435, DOI 10.17487/RFC7435, + December 2014, <http://www.rfc-editor.org/info/rfc7435>. + + + + +Stenberg & Barth Standards Track [Page 36] + +RFC 7787 Distributed Node Consensus Protocol April 2016 + + + [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. + Farrer, "Lightweight 4over6: An Extension to the Dual- + Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, + July 2015, <http://www.rfc-editor.org/info/rfc7596>. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Stenberg & Barth Standards Track [Page 37] + +RFC 7787 Distributed Node Consensus Protocol April 2016 + + +Appendix A. Alternative Modes of Operation + + Beyond what is described in the main text, the protocol allows for + other uses. These are provided as examples. + +A.1. Read-Only Operation + + If a node uses just a single endpoint and does not need to publish + any TLVs, full DNCP node functionality is not required. Such a + limited node can acquire and maintain a view of the TLV space by + implementing the processing logic as specified in Section 4.4. Such + node would not need Trickle, peer-maintenance, or even keep-alives at + all, as the DNCP nodes' use of it would guarantee eventual receipt of + network state hashes, and synchronization of node data, even in the + presence of unreliable transport. + +A.2. Forwarding Operation + + If a node with a pair of endpoints does not need to publish any TLVs, + it can detect (for example) nodes with the highest node identifier on + each of the endpoints (if any). Any TLVs received from one of them + would be forwarded verbatim as unicast to the other node with the + highest node identifier. + + Any tinkering with the TLVs would remove guarantees of this scheme + working; however, passive monitoring would obviously be fine. This + type of simple forwarding cannot be chained, as it does not send + anything proactively. + +Appendix B. DNCP Profile Additional Guidance + + This appendix explains implications of design choices made when + specifying the DNCP profile to use particular transport or security + options. + +B.1. Unicast Transport -- UDP or TCP? + + The node data published by a DNCP node is limited to 64 KB due to the + 16-bit size of the length field of the TLV it is published within. + Some transport choices may decrease this limit; if using, e.g., UDP + datagrams for unicast transport, the upper bound of the node data + size is whatever the nodes and the underlying network can pass to + each other as DNCP does not define its own fragmentation scheme. A + profile that chooses UDP has to be limited to small node data (e.g., + somewhat smaller than IPv6 default MTU if using IPv6) or specify a + minimum that all nodes have to support. Even then, if using + non-link-local communications, there is some concern about what + middleboxes do to fragmented packets. Therefore, the use of stream + + + +Stenberg & Barth Standards Track [Page 38] + +RFC 7787 Distributed Node Consensus Protocol April 2016 + + + transport such as TCP is probably a good idea if either + non-link-local communication is desired or fragmentation is expected + to cause problems. + + TCP also provides some other facilities, such as a relatively long + built-in keep-alive, which in conjunction with connection closes + occurring from eventual failed retransmissions may be sufficient to + avoid the use of in-protocol keep-alive defined in Section 6.1. + Additionally, it is reliable, so there is no need for Trickle on such + unicast connections. + + The major downside of using TCP instead of UDP with DNCP-based + profiles lies in the loss of control over the time at which TLVs are + received; while unreliable UDP datagrams also have some delay, TLVs + within reliable stream transport may be delayed significantly due to + retransmissions. This is not a problem if no relative time-dependent + information is stored within the TLVs in the DNCP-based protocol; for + such a protocol, TCP is a reasonable choice for unicast transport if + it is available. + +B.2. (Optional) Multicast Transport + + Multicast is needed for dynamic peer discovery and to trigger unicast + exchanges; for that, unreliable datagram transport (=typically UDP) + is the only transport option defined within this specification, + although DNCP-based protocols may themselves define some other + transport or peer discovery mechanism (e.g., based on Multicast DNS + (mDNS) or DNS). + + If multicast is used, a well-known address should be specified and + for, e.g., IPv6, respectively, the desired address scopes. In most + cases, link-local and possibly site-local are useful scopes. + +B.3. (Optional) Transport Security + + In terms of provided security, DTLS and TLS are equivalent; they also + consume a similar amount of state on the devices. While TLS is on + top of a stream protocol, using DTLS also requires relatively long + session caching within the DTLS layer to avoid expensive + reauthentication/authorization steps if and when any state within the + DNCP network changes or per-peer keep-alive (if enabled) is sent. + + TLS implementations (at the time of writing the specification) seem + more mature and available (as open source) than DTLS ones. This may + be due to a long history of use with HTTPS. + + + + + + +Stenberg & Barth Standards Track [Page 39] + +RFC 7787 Distributed Node Consensus Protocol April 2016 + + + Some libraries seem not to support multiplexing between insecure and + secure communication on the same port, so specifying distinct ports + for secured and unsecured communication may be beneficial. + +Appendix C. Example Profile + + This is the DNCP profile of SHSP, an experimental (and for the + purposes of this document fictional) home automation protocol. The + protocol itself is used to make a key-value store published by each + of the nodes available to all other nodes for distributed monitoring + and control of a home infrastructure. It defines only one additional + TLV type: a key=value TLV that contains a single key=value assignment + for publication. + + o Unicast transport: IPv6 TCP on port EXAMPLE-P1 since only absolute + timestamps are used within the key=value data and since it focuses + primarily on Linux-based nodes that support both protocols as + well. Connections from and to non-link-local addresses are + ignored to avoid exposing this protocol outside the secure links. + + o Multicast transport: IPv6 UDP on port EXAMPLE-P2 to link-local + scoped multicast address ff02:EXAMPLE. At least one node per link + in the home is assumed to facilitate node discovery without + depending on any other infrastructure. + + o Security: None. It is to be used only on trusted links (WPA2-x + wireless, physically secure wired links). + + o Additional TLVs to be ignored: None. No DNCP security is + specified, and no new TLVs are defined outside of node data. + + o Node identifier length (DNCP_NODE_IDENTIFIER_LENGTH): 32 bits that + are randomly generated. + + o Node identifier collision handling: Pick new random node + identifier. + + o Trickle parameters: Imin = 200 ms, Imax = 7, k = 1. It means at + least one multicast per link in 25 seconds in stable state (0.2 * + 2^7). + + o Hash function H(x) + length: SHA-256, only 128 bits used. It's + relatively fast, and 128 bits should be plenty to prevent random + conflicts (64 bits would most likely be sufficient, too). + + o No in-protocol keep-alives (Section 6.1); TCP keep-alive is to be + used. In practice, TCP keep-alive is seldom encountered anyway, + as changes in network state cause packets to be sent on the + + + +Stenberg & Barth Standards Track [Page 40] + +RFC 7787 Distributed Node Consensus Protocol April 2016 + + + unicast connections, and those that fail sufficiently many + retransmissions are dropped much before the keep-alive actually + would fire. + + o No support for dense multicast-enabled link optimization + (Section 6.2); SHSP is a simple protocol for a few nodes (network + wide, not even to mention on a single link) and therefore would + not provide any benefit. + +Acknowledgements + + Thanks to Ole Troan, Pierre Pfister, Mark Baugher, Mark Townsley, + Juliusz Chroboczek, Jiazi Yi, Mikael Abrahamsson, Brian Carpenter, + Thomas Clausen, DENG Hui, and Margaret Cullen for their contributions + to the document. + + Thanks to Kaiwen Jin and Xavier Bonnetain for their related research + work. + +Authors' Addresses + + Markus Stenberg + Independent + Helsinki 00930 + Finland + + Email: markus.stenberg@iki.fi + + + Steven Barth + Independent + Halle 06114 + Germany + + Email: cyrus@openwrt.org + + + + + + + + + + + + + + + + +Stenberg & Barth Standards Track [Page 41] + |