draft-ietf-homenet-dncp-09.txt   draft-ietf-homenet-dncp-10.txt 
Homenet Working Group M. Stenberg Homenet Working Group M. Stenberg
Internet-Draft S. Barth Internet-Draft S. Barth
Intended status: Standards Track Independent Intended status: Standards Track Independent
Expires: February 6, 2016 August 5, 2015 Expires: March 24, 2016 September 21, 2015
Distributed Node Consensus Protocol Distributed Node Consensus Protocol
draft-ietf-homenet-dncp-09 draft-ietf-homenet-dncp-10
Abstract Abstract
This document describes the Distributed Node Consensus Protocol This document describes the Distributed Node Consensus Protocol
(DNCP), a generic state synchronization protocol that uses the (DNCP), a generic state synchronization protocol that uses the
Trickle algorithm and hash trees. DNCP is an abstract protocol, and Trickle algorithm and hash trees. DNCP is an abstract protocol, and
must be combined with a specific profile to make a complete must be combined with a specific profile to make a complete
implementable protocol. implementable protocol.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 6, 2016. This Internet-Draft will expire on March 24, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 2, line 11 skipping to change at page 2, line 11
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 6 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 6
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Hash Tree . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Hash Tree . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Data Transport . . . . . . . . . . . . . . . . . . . . . 8 4.2. Data Transport . . . . . . . . . . . . . . . . . . . . . 8
4.3. Trickle-Driven Status Updates . . . . . . . . . . . . . . 9 4.3. Trickle-Driven Status Updates . . . . . . . . . . . . . . 9
4.4. Processing of Received TLVs . . . . . . . . . . . . . . . 10 4.4. Processing of Received TLVs . . . . . . . . . . . . . . . 10
4.5. Adding and Removing Peers . . . . . . . . . . . . . . . . 12 4.5. Adding and Removing Peers . . . . . . . . . . . . . . . . 13
4.6. Data Liveliness Validation . . . . . . . . . . . . . . . 13 4.6. Data Liveliness Validation . . . . . . . . . . . . . . . 13
5. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Optional Extensions . . . . . . . . . . . . . . . . . . . . . 15 6. Optional Extensions . . . . . . . . . . . . . . . . . . . . . 16
6.1. Keep-Alives . . . . . . . . . . . . . . . . . . . . . . . 15 6.1. Keep-Alives . . . . . . . . . . . . . . . . . . . . . . . 16
6.1.1. Data Model Additions . . . . . . . . . . . . . . . . 16 6.1.1. Data Model Additions . . . . . . . . . . . . . . . . 16
6.1.2. Per-Endpoint Periodic Keep-Alives . . . . . . . . . . 16 6.1.2. Per-Endpoint Periodic Keep-Alives . . . . . . . . . . 17
6.1.3. Per-Peer Periodic Keep-Alives . . . . . . . . . . . . 17 6.1.3. Per-Peer Periodic Keep-Alives . . . . . . . . . . . . 17
6.1.4. Received TLV Processing Additions . . . . . . . . . . 17 6.1.4. Received TLV Processing Additions . . . . . . . . . . 17
6.1.5. Peer Removal . . . . . . . . . . . . . . . . . . . . 17 6.1.5. Peer Removal . . . . . . . . . . . . . . . . . . . . 17
6.2. Support For Dense Multicast-Enabled Links . . . . . . . . 17 6.2. Support For Dense Multicast-Enabled Links . . . . . . . . 18
7. Type-Length-Value Objects . . . . . . . . . . . . . . . . . . 18 7. Type-Length-Value Objects . . . . . . . . . . . . . . . . . . 19
7.1. Request TLVs . . . . . . . . . . . . . . . . . . . . . . 19 7.1. Request TLVs . . . . . . . . . . . . . . . . . . . . . . 20
7.1.1. Request Network State TLV . . . . . . . . . . . . . . 19 7.1.1. Request Network State TLV . . . . . . . . . . . . . . 20
7.1.2. Request Node State TLV . . . . . . . . . . . . . . . 19 7.1.2. Request Node State TLV . . . . . . . . . . . . . . . 20
7.2. Data TLVs . . . . . . . . . . . . . . . . . . . . . . . . 20 7.2. Data TLVs . . . . . . . . . . . . . . . . . . . . . . . . 20
7.2.1. Node Endpoint TLV . . . . . . . . . . . . . . . . . . 20 7.2.1. Node Endpoint TLV . . . . . . . . . . . . . . . . . . 20
7.2.2. Network State TLV . . . . . . . . . . . . . . . . . . 20 7.2.2. Network State TLV . . . . . . . . . . . . . . . . . . 21
7.2.3. Node State TLV . . . . . . . . . . . . . . . . . . . 21 7.2.3. Node State TLV . . . . . . . . . . . . . . . . . . . 21
7.3. Data TLVs within Node State TLV . . . . . . . . . . . . . 22 7.3. Data TLVs within Node State TLV . . . . . . . . . . . . . 22
7.3.1. Peer TLV . . . . . . . . . . . . . . . . . . . . . . 22 7.3.1. Peer TLV . . . . . . . . . . . . . . . . . . . . . . 22
7.3.2. Keep-Alive Interval TLV . . . . . . . . . . . . . . . 22 7.3.2. Keep-Alive Interval TLV . . . . . . . . . . . . . . . 23
8. Security and Trust Management . . . . . . . . . . . . . . . . 23 8. Security and Trust Management . . . . . . . . . . . . . . . . 23
8.1. Pre-Shared Key Based Trust Method . . . . . . . . . . . . 23 8.1. Pre-Shared Key Based Trust Method . . . . . . . . . . . . 23
8.2. PKI Based Trust Method . . . . . . . . . . . . . . . . . 23 8.2. PKI Based Trust Method . . . . . . . . . . . . . . . . . 24
8.3. Certificate Based Trust Consensus Method . . . . . . . . 23 8.3. Certificate Based Trust Consensus Method . . . . . . . . 24
8.3.1. Trust Verdicts . . . . . . . . . . . . . . . . . . . 24 8.3.1. Trust Verdicts . . . . . . . . . . . . . . . . . . . 24
8.3.2. Trust Cache . . . . . . . . . . . . . . . . . . . . . 25 8.3.2. Trust Cache . . . . . . . . . . . . . . . . . . . . . 25
8.3.3. Announcement of Verdicts . . . . . . . . . . . . . . 25 8.3.3. Announcement of Verdicts . . . . . . . . . . . . . . 26
8.3.4. Bootstrap Ceremonies . . . . . . . . . . . . . . . . 26 8.3.4. Bootstrap Ceremonies . . . . . . . . . . . . . . . . 27
9. DNCP Profile-Specific Definitions . . . . . . . . . . . . . . 27 9. DNCP Profile-Specific Definitions . . . . . . . . . . . . . . 28
10. Security Considerations . . . . . . . . . . . . . . . . . . . 29 10. Security Considerations . . . . . . . . . . . . . . . . . . . 29
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
12.1. Normative references . . . . . . . . . . . . . . . . . . 30 12.1. Normative references . . . . . . . . . . . . . . . . . . 31
12.2. Informative references . . . . . . . . . . . . . . . . . 30 12.2. Informative references . . . . . . . . . . . . . . . . . 31
Appendix A. Alternative Modes of Operation . . . . . . . . . . . 31 Appendix A. Alternative Modes of Operation . . . . . . . . . . . 31
A.1. Read-only Operation . . . . . . . . . . . . . . . . . . . 31 A.1. Read-only Operation . . . . . . . . . . . . . . . . . . . 32
A.2. Forwarding Operation . . . . . . . . . . . . . . . . . . 31 A.2. Forwarding Operation . . . . . . . . . . . . . . . . . . 32
Appendix B. Some Questions and Answers [RFC Editor: please Appendix B. DNCP Profile Additional Guidance . . . . . . . . . . 32
remove] . . . . . . . . . . . . . . . . . . . . . . 31 B.1. Unicast Transport - UDP or TCP? . . . . . . . . . . . . . 32
Appendix C. Changelog [RFC Editor: please remove] . . . . . . . 32 B.2. (Optional) Multicast Transport . . . . . . . . . . . . . 33
Appendix D. Draft Source [RFC Editor: please remove] . . . . . . 33 B.3. (Optional) Transport Security . . . . . . . . . . . . . . 33
Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 34 Appendix C. Example Profile . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 Appendix D. Some Questions and Answers [RFC Editor: please
remove] . . . . . . . . . . . . . . . . . . . . . . 35
Appendix E. Changelog [RFC Editor: please remove] . . . . . . . 35
Appendix F. Draft Source [RFC Editor: please remove] . . . . . . 37
Appendix G. Acknowledgements . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction 1. Introduction
DNCP is designed to provide a way for each participating node to DNCP is designed to provide a way for each participating node to
publish a set of TLV (Type-Length-Value) tuples, and to provide a publish a small set of TLV (Type-Length-Value) tuples (at most 64
shared and common view about the data published by every currently or KB), and to provide a shared and common view about the data published
recently bidirectionally reachable DNCP node in a network. by every currently or recently bidirectionally reachable DNCP node in
a network.
For state synchronization a hash tree is used. It is formed by first For state synchronization a hash tree is used. It is formed by first
calculating a hash for the dataset published by each node, called calculating a hash for the dataset published by each node, called
node data, and then calculating another hash over those node data node data, and then calculating another hash over those node data
hashes. The single resulting hash, called network state hash, is hashes. The single resulting hash, called network state hash, is
transmitted using the Trickle algorithm [RFC6206] to ensure that all transmitted using the Trickle algorithm [RFC6206] to ensure that all
nodes share the same view of the current state of the published data 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 within the network. The use of Trickle with only short network state
hashes sent infrequently (in steady state, once the maximum Trickle hashes sent infrequently (in steady state, once the maximum Trickle
interval per link or unicast connection has been reached) makes DNCP interval per link or unicast connection has been reached) makes DNCP
skipping to change at page 4, line 19 skipping to change at page 4, line 25
If constant rapid state changes are needed, the preferable choice is If constant rapid state changes are needed, the preferable choice is
to use an additional point-to-point channel whose address or locator to use an additional point-to-point channel whose address or locator
is published using DNCP. Nevertheless, if doing so does not raise is published using DNCP. Nevertheless, if doing so does not raise
A_NC_I above the (sensibly chosen) Trickle interval parameters for a A_NC_I above the (sensibly chosen) Trickle interval parameters for a
particular application, using DNCP is probably not suitable for the particular application, using DNCP is probably not suitable for the
application. application.
Another consideration is the size of the published TLV set by a node 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 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, published by a node is very large, and has frequent small changes,
DNCP as currently specified may be unsuitable since it does not DNCP as currently specified in this specification may be unsuitable
define any delta synchronization scheme but always transmits the as it lacks a delta synchronization scheme to keep implementation
complete updated TLV set verbatim. simple.
DNCP can be used in networks where only unicast transport is DNCP can be used in networks where only unicast transport is
available. While DNCP uses the least amount of bandwidth when available. While DNCP uses the least amount of bandwidth when
multicast is utilized, even in pure unicast mode, the use of Trickle multicast is utilized, even in pure unicast mode, the use of Trickle
(ideally with k < 2) results in a protocol with an exponential (ideally with k < 2) results in a protocol with an exponential
backoff timer and fewer transmissions than a simpler protocol not backoff timer and fewer transmissions than a simpler protocol not
using Trickle. using Trickle.
2. Terminology 2. Terminology
DNCP profile the values for the set of parameters, given in DNCP profile the values for the set of parameters, given in
Section 9. They are prefixed with DNCP_ in this Section 9. They are prefixed with DNCP_ in this
document. The profile also specifies the set of document. The profile also specifies the set of
optional DNCP extensions to be used. optional DNCP extensions to be used. For a simple
example DNCP profile, see Appendix C.
DNCP-based a protocol which provides a DNCP profile, according DNCP-based a protocol which provides a DNCP profile, according
protocol to Section 9, and zero or more TLV assignments from protocol to Section 9, and zero or more TLV assignments from
the per-DNCP profile TLV registry as well as their the per-DNCP profile TLV registry as well as their
processing rules. processing rules.
DNCP node a single node which runs a DNCP-based protocol. DNCP node a single node which runs a DNCP-based protocol.
Link a link-layer media over which directly connected Link a link-layer media over which directly connected
nodes can communicate. nodes can communicate.
skipping to change at page 5, line 42 skipping to change at page 5, line 48
should comfortably fit within 32 bits. should comfortably fit within 32 bits.
Peer another DNCP node with which a DNCP node Peer another DNCP node with which a DNCP node
communicates using a particular local and remote communicates using a particular local and remote
endpoint pair. endpoint pair.
Node data a set of TLVs published and owned by a node in the Node data a set of TLVs published and owned by a node in the
DNCP network. Other nodes pass it along as-is, even DNCP network. Other nodes pass it along as-is, even
if they cannot fully interpret it. 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 Node state a set of metadata attributes for node data. It
includes a sequence number for versioning, a hash includes a sequence number for versioning, a hash
value for comparing equality of stored node data, value for comparing equality of stored node data,
and a timestamp indicating the time passed since and a timestamp indicating the time passed since
its last publication. The hash function and the its last publication (i.e., since the origination
length of the hash value are defined in the DNCP time). The hash function and the length of the hash
profile. value are defined in the DNCP profile.
Network state a hash value which represents the current state of Network state a hash value which represents the current state of
hash the network. The hash function and the length of hash the network. The hash function and the length of
the hash value are defined in the DNCP profile. the hash value are defined in the DNCP profile.
Whenever a node is added, removed or updates its Whenever a node is added, removed or updates its
published node data this hash value changes as published node data this hash value changes as
well. For calculation, please see Section 4.1. well. For calculation, please see Section 4.1.
Trust verdict a statement about the trustworthiness of a Trust verdict a statement about the trustworthiness of a
certificate announced by a node participating in certificate announced by a node participating in
skipping to change at page 6, line 33 skipping to change at page 6, line 41
message has been received by the local node (see message has been received by the local node (see
Section 4.5). If said peer in return also Section 4.5). If said peer in return also
considers the local node unidirectionally considers the local node unidirectionally
reachable, then bidirectionally reachability is reachable, then bidirectionally reachability is
established. As this process is based on established. As this process is based on
publishing peer relationships and evaluating the publishing peer relationships and evaluating the
resulting topology graph as described in Section resulting topology graph as described in Section
4.6, this information is available to the whole 4.6, this information is available to the whole
DNCP network. 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 2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119]. 2119 [RFC2119].
3. Overview 3. Overview
DNCP operates primarily using unicast exchanges between nodes, and DNCP operates primarily using unicast exchanges between nodes, and
may use multicast for Trickle-based shared state dissemination and may use multicast for Trickle-based shared state dissemination and
topology discovery. If used in pure unicast mode with unreliable topology discovery. If used in pure unicast mode with unreliable
transport, Trickle is also used between peers. transport, Trickle is also used between peers.
DNCP discovers the topology of the nodes in the DNCP network and DNCP discovers the topology of the nodes in the DNCP network and
maintains the liveliness of published node data by ensuring that the maintains the liveliness of published node data by ensuring that the
publishing node was - at least recently - bidirectionally reachable. publishing node is bidirectionally reachable. New potential peers
New potential peers can be discovered autonomously on multicast- can be discovered autonomously on multicast-enabled links, their
enabled links, their addresses may be manually configured or they may addresses may be manually configured or they may be found by some
be found by some other means defined in a later specification. other means defined in the particular DNCP profile. The DNCP profile
may specify, for example, a well-known anycast address or
provisioning 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 A hash tree of height 1, rooted in itself, is maintained by each node
to represent the state of all currently reachable nodes (see to represent the state of all currently reachable nodes (see
Section 4.1) and the Trickle algorithm is used to trigger Section 4.1) and the Trickle algorithm is used to trigger
synchronization (see Section 4.3). The need to check peer nodes for synchronization (see Section 4.3). The need to check peer nodes for
state changes is thereby determined by comparing the current root of state changes is thereby determined by comparing the current root of
their respective hash trees, i.e., their individually calculated their respective hash trees, i.e., their individually calculated
network state hashes. network state hashes.
Before joining a DNCP network, a node starts with a hash tree that Before joining a DNCP network, a node starts with a hash tree that
skipping to change at page 7, line 39 skipping to change at page 8, line 10
updated (e.g., due to its own or another node's node state changing 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 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 reset which eventually causes any update to be propagated to all of
its peers. its peers.
4. Operation 4. Operation
4.1. Hash Tree 4.1. Hash Tree
Each DNCP node maintains an arbitrary width hash tree of height 1. Each DNCP node maintains an arbitrary width hash tree of height 1.
Each leaf represents one recently bidirectionally reachable DNCP node Each leaf represents one bidirectionally reachable DNCP node (see
(see Section 4.6), and is represented by a tuple consisting of the Section 4.6), and is represented by a tuple consisting of the node's
node's sequence number in network byte order concatenated with the sequence number in network byte order concatenated with the hash-
hash-value of the node's ordered node data published in the Node value of the node's ordered node data published in the Node State TLV
State TLV (Section 7.2.3). These leaves are ordered in ascending (Section 7.2.3). These leaves are ordered in ascending order of the
order of the respective node identifiers. The root of the tree - the node identifiers of the nodes they represent. The root of the tree -
network state hash - is represented by the hash-value calculated over the network state hash - is represented by the hash-value calculated
all such leaf tuples concatenated in order. It is used to determine over all such leaf tuples concatenated in order. It is used to
whether the view of the network of two or more nodes is consistent determine whether the view of the network of two or more nodes is
and shared. consistent and shared.
The node data hashes in the leaves and the root network state hash The node data hashes in the leaves and the root network state hash
are updated on-demand and whenever any locally stored per-node state are updated on-demand and whenever any locally stored per-node state
changes. This includes local unidirectional reachability encoded in changes. This includes local unidirectional reachability encoded in
the published Peer TLVs (Section 7.3.1) and - when combined with the published Peer TLVs (Section 7.3.1) and - when combined with
remote data - results in awareness of bidirectional reachability remote data - results in awareness of bidirectional reachability
changes. changes.
4.2. Data Transport 4.2. Data Transport
DNCP has few requirements for the underlying transport; it requires DNCP has few requirements for the underlying transport; it requires
some way of transmitting either unicast datagram or stream data to a some way of transmitting either unicast datagram or stream data to a
peer and, if used in multicast mode, a way of sending multicast peer and, if used in multicast mode, a way of sending multicast
datagrams. As multicast is used only to identify potential new DNCP datagrams. As multicast is used only to identify potential new DNCP
nodes and to send status messages which merely notify that a unicast nodes and to send status messages which merely notify that a unicast
exchange should be triggered, the multicast transport does not have exchange should be triggered, the multicast transport does not have
to be secured. If unicast security is desired and one of the built- 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 in security methods is to be used, support for some TLS-derived
transport scheme - such as TLS [RFC5246] on top of TCP or DTLS transport scheme - such as TLS [RFC5246] on top of TCP or DTLS
[RFC6347] on top of UDP - is also required. A specific definition of [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 their parameters MUST be provided by the the transport(s) in use and their parameters MUST be provided by the
DNCP profile. DNCP profile.
TLVs are sent across the transport as is, and they SHOULD be sent TLVs are sent across the transport as is, and they SHOULD be sent
together where, e.g., MTU considerations do not recommend sending together where, e.g., MTU considerations do not recommend sending
them in multiple batches. TLVs in general are handled individually them in multiple batches. TLVs in general are handled individually
and statelessly, with one exception: To form bidirectional peer and statelessly, with one exception: To form bidirectional peer
relationships DNCP requires identification of the endpoints used for relationships DNCP requires identification of the endpoints used for
communication. As bidirectional peer relationships are required for communication. As bidirectional peer relationships are required for
validating liveliness of published node data as described in validating liveliness of published node data as described in
skipping to change at page 8, line 42 skipping to change at page 9, line 15
(Section 7.2.1). When it is sent varies, depending on the underlying (Section 7.2.1). When it is sent varies, depending on the underlying
transport, but conceptually it should be available whenever transport, but conceptually it should be available whenever
processing a Network State TLV: processing a Network State TLV:
o If using a stream transport, the TLV MUST be sent at least once o If using a stream transport, the TLV MUST be sent at least once
per connection, but SHOULD NOT be sent more than once. per connection, but SHOULD NOT be sent more than once.
o If using a datagram transport, it MUST be included in every o If using a datagram transport, it MUST be included in every
datagram that also contains a Network State TLV (Section 7.2.2) datagram that also contains a Network State TLV (Section 7.2.2)
and MUST be located before any such TLV. It SHOULD also be and MUST be located before any such TLV. It SHOULD also be
included in any other datagram, to speeds up initial peer included in any other datagram, to speed up initial peer
detection. detection.
Given the assorted transport options as well as potential endpoint Given the assorted transport options as well as potential endpoint
configuration, a DNCP endpoint may be used in various transport configuration, a DNCP endpoint may be used in various transport
modes: modes:
Unicast: Unicast:
* If only reliable unicast transport is used, Trickle is not used * If only reliable unicast transport is used, Trickle is not used
at all. Where Trickle reset has been specified, a single at all. Where Trickle reset has been specified, a single
Network State TLV (Section 7.2.2) is sent instead to every Network State TLV (Section 7.2.2) is sent instead to every
unicast peer. Additionally, recently changed Node State TLVs unicast peer. Additionally, recently changed Node State TLVs
(Section 7.2.3) MAY be included. (Section 7.2.3) MAY be included.
* If only unreliable unicast transport is used, Trickle state is * If only unreliable unicast transport is used, Trickle state is
kept per peer and it is used to send Network State TLVs kept per peer and it is used to send Network State TLVs
intermittently, as specified in Section 4.3. intermittently, as specified in Section 4.3.
Multicast+Unicast: If multicast datagram transport is available on Multicast+Unicast: If multicast datagram transport is available on
an endpoint, Trickle state is only maintained for the endpoint as an endpoint, Trickle state is only maintained for the endpoint as
a whole. It is used to send Network State TLVs every now and a whole. It is used to send Network State TLVs periodically, as
then, as specified in Section 4.3. Additionally, per-endpoint specified in Section 4.3. Additionally, per-endpoint keep-alives
keep-alives MAY be defined in the DNCP profile, as specified in MAY be defined in the DNCP profile, as specified in Section 6.1.2.
Section 6.1.2.
MulticastListen+Unicast: Just like Unicast, except multicast MulticastListen+Unicast: Just like Unicast, except multicast
transmissions are listened to in order to detect changes of the transmissions are listened to in order to detect changes of the
highest node identifier. This mode is used only if the DNCP highest node identifier. This mode is used only if the DNCP
profile supports dense multicast-enabled link optimization profile supports dense multicast-enabled link optimization
(Section 6.2). (Section 6.2).
4.3. Trickle-Driven Status Updates 4.3. Trickle-Driven Status Updates
The Trickle algorithm [RFC6206] has 3 parameters: Imin, Imax and k. The Trickle algorithm [RFC6206] has 3 parameters: Imin, Imax and k.
Imin and Imax represent the minimum and maximum values for I, which Imin and Imax represent the minimum value for I and the maximum
is the time interval during which at least k Trickle updates must be number of doublings of Imin, where I is the time interval during
seen on an endpoint to prevent local state transmission. The actual which at least k Trickle updates must be seen on an endpoint to
suggested Trickle algorithm parameters are DNCP profile specific, as prevent local state transmission. The actual suggested Trickle
described in Section 9. algorithm parameters are DNCP profile specific, as described in
Section 9.
The Trickle state for all Trickle instances is considered The Trickle state for all Trickle instances defined in Section 5 is
inconsistent and reset if and only if the locally calculated network considered inconsistent and reset if and only if the locally
state hash changes. This occurs either due to a change in the local calculated network state hash changes. This occurs either due to a
node's own node data, or due to receipt of more recent data from change in the local node's own node data, or due to receipt of more
another node. A node MUST NOT reset its Trickle state merely based recent data from another node. A node MUST NOT reset its Trickle
on receiving a Network State TLV (Section 7.2.2) with a network state state merely based on receiving a Network State TLV (Section 7.2.2)
hash which is different from its locally calculated one. with a network state hash which is different from its locally
calculated one.
Every time a particular Trickle instance indicates that an update Every time a particular Trickle instance indicates that an update
should be sent, the node MUST send a Network State TLV should be sent, the node MUST send a Network State TLV
(Section 7.2.2) if and only if: (Section 7.2.2) if and only if:
o the endpoint is in Multicast+Unicast transport mode, in which case o the endpoint is in Multicast+Unicast transport mode, in which case
the TLV MUST be sent over multicast. the TLV MUST be sent over multicast.
o the endpoint is NOT in Multicast+Unicast transport mode, and the o the endpoint is NOT in Multicast+Unicast transport mode, and the
unicast transport is unreliable, in which case the TLV MUST be unicast transport is unreliable, in which case the TLV MUST be
skipping to change at page 10, line 24 skipping to change at page 10, line 43
4.4. Processing of Received TLVs 4.4. Processing of Received TLVs
This section describes how received TLVs are processed. The DNCP This section describes how received TLVs are processed. The DNCP
profile may specify when to ignore particular TLVs, e.g., to modify profile may specify when to ignore particular TLVs, e.g., to modify
security properties - see Section 9 for what may be safely defined to security properties - see Section 9 for what may be safely defined to
be ignored in a profile. Any 'reply' mentioned in the steps below be ignored in a profile. Any 'reply' mentioned in the steps below
denotes sending of the specified TLV(s) over unicast to the denotes sending of the specified TLV(s) over unicast to the
originator of the TLV being processed. If the TLV being replied to originator of the TLV being processed. If the TLV being replied to
was received via multicast and it was sent to a multiple access link, was received via multicast and it was sent to a multiple access link,
the reply SHOULD be delayed by a random timespan in [0, Imin/2], to the reply MUST be delayed by a random timespan in [0, Imin/2], to
avoid potential simultaneous replies that may cause problems on some avoid potential simultaneous replies that may cause problems on some
links. Sending of replies MAY also be rate-limited or omitted for a links, unless specified differently in the DNCP profile. Sending of
short period of time by an implementation. However, an replies MAY also be rate-limited or omitted for a short period of
implementation MUST eventually reply to similar repeated requests, as time by an implementation. However, if the TLV is not forbidden by
otherwise state synchronization breaks. 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 address, as A DNCP node MUST process TLVs received from any valid (e.g.,
specified by the DNCP profile and the configuration of a particular correctly scoped) address, as specified by the DNCP profile and the
endpoint, whether this address is known to be the address of a peer configuration of a particular endpoint, whether this address is known
or not. This provision satisfies the needs of monitoring or other to be the address of a peer or not. This provision satisfies the
host software that needs to discover the DNCP topology without adding needs of monitoring or other host software that needs to discover the
to the state in the network. DNCP topology without adding to the state in the network.
Upon receipt of: Upon receipt of:
o Request Network State TLV (Section 7.1.1): The receiver MUST reply 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 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 (Section 7.2.3) for each node data used to calculate the network
state hash. The Node State TLVs SHOULD NOT contain the optional state hash. The Node State TLVs SHOULD NOT contain the optional
node data part to avoid redundant transmission of node data, node data part to avoid redundant transmission of node data,
unless explicitly specified in the DNCP profile. unless explicitly specified in the DNCP profile.
skipping to change at page 11, line 49 skipping to change at page 12, line 22
(local sequence number is less than that within the TLV). (local sequence number is less than that within the TLV).
+ The local information is potentially incorrect (local + The local information is potentially incorrect (local
sequence number matches but the node data hash differs). sequence number matches but the node data hash differs).
+ There is no data for that node altogether. + There is no data for that node altogether.
Then: Then:
+ If the TLV contains the Node Data field, it SHOULD also be + If the TLV contains the Node Data field, it SHOULD also be
verified by ensuring that the locally calculated H(Node verified by ensuring that the locally calculated hash of the
Data) matches the content of the H(Node Data) field within Node Data matches the content of the H(Node Data) field
the TLV. If they differ, the TLV SHOULD be ignored and not within the TLV. If they differ, the TLV SHOULD be ignored
processed further. and not processed further.
+ If the TLV does not contain the Node Data field, and the + If the TLV does not contain the Node Data field, and the
H(Node Data) field within the TLV differs from the local H(Node Data) field within the TLV differs from the local
node data hash for that node (or there is none), the node data hash for that node (or there is none), the
receiver MUST reply with a Request Node State TLV receiver MUST reply with a Request Node State TLV
(Section 7.1.2) for the corresponding node. (Section 7.1.2) for the corresponding node.
+ Otherwise the receiver MUST update its locally stored state + Otherwise the receiver MUST update its locally stored state
for that node (node data based on Node Data field if for that node (node data based on Node Data field if
present, sequence number and relative time) to match the present, sequence number and relative time) to match the
skipping to change at page 12, line 49 skipping to change at page 13, line 24
o If received over multicast, the node MAY be sent a (possibly rate- o If received over multicast, the node MAY be sent a (possibly rate-
limited) unicast Request Network State TLV (Section 7.1.1). limited) unicast Request Network State TLV (Section 7.1.1).
If keep-alives specified in Section 6.1 are NOT sent by the peer 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 (either the DNCP profile does not specify the use of keep-alives or
the particular peer chooses not to send keep-alives), some other the particular peer chooses not to send keep-alives), some other
existing local transport-specific means (such as Ethernet carrier- existing local transport-specific means (such as Ethernet carrier-
detection or TCP keep-alive) MUST be used to ensure its presence. If 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 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 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 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 sending keep-alives again. When the peer is no longer present, the
Peer TLV and the local DNCP peer state MUST be removed. Peer TLV and the local DNCP peer state MUST be removed.
If the local endpoint is in the Multicast-Listen+Unicast transport 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 mode, a Peer TLV (Section 7.3.1) MUST NOT be published for the peers
not having the highest node identifier. not having the highest node identifier.
4.6. Data Liveliness Validation 4.6. Data Liveliness Validation
The topology graph MUST be traversed either immediately or with a The topology graph MUST be traversed either immediately or with a
skipping to change at page 13, line 27 skipping to change at page 13, line 50
o the origination time (in milliseconds) of some node's node data is o the origination time (in milliseconds) of some node's node data is
less than current time - 2^32 + 2^15. less than current time - 2^32 + 2^15.
The topology graph traversal starts with the local node marked as The topology graph traversal starts with the local node marked as
reachable. Other nodes are then iteratively marked as reachable reachable. Other nodes are then iteratively marked as reachable
using the following algorithm: A candidate not-yet-reachable node N using the following algorithm: A candidate not-yet-reachable node N
with an endpoint NE is marked as reachable if there is a reachable with an endpoint NE is marked as reachable if there is a reachable
node R with an endpoint RE that meet all of the following criteria: node R with an endpoint RE that meet all of the following criteria:
o The origination time (in milliseconds) of R's node data is greater o The origination time (in milliseconds) of R's node data is greater
than current time in - 2^32 + 2^15. than current time - 2^32 + 2^15.
o R publishes a Peer TLV with: o R publishes a Peer TLV with:
* Peer Node Identifier = N's node identifier * Peer Node Identifier = N's node identifier
* Peer Endpoint Identifier = NE's endpoint identifier * Peer Endpoint Identifier = NE's endpoint identifier
* Endpoint Identifier = RE's endpoint identifier * Endpoint Identifier = RE's endpoint identifier
o N publishes a Peer TLV with: o N publishes a Peer TLV with:
skipping to change at page 13, line 51 skipping to change at page 14, line 25
* Peer Endpoint Identifier = RE's endpoint identifier * Peer Endpoint Identifier = RE's endpoint identifier
* Endpoint Identifier = NE's endpoint identifier * Endpoint Identifier = NE's endpoint identifier
The algorithm terminates, when no more candidate nodes fulfilling The algorithm terminates, when no more candidate nodes fulfilling
these criteria can be found. these criteria can be found.
DNCP nodes that have not been reachable in the most recent topology DNCP nodes that have not been reachable in the most recent topology
graph traversal MUST NOT be used for calculation of the network state 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 hash, be provided to any applications that need to use the whole TLV
graph, or be provided to remote nodes. They MAY be removed graph, or be provided to remote nodes. They MAY be forgotten
immediately after the topology graph traversal, however it is immediately after the topology graph traversal, however it is
RECOMMENDED to keep them at least briefly to improve the speed of RECOMMENDED to keep them at least briefly to improve the speed of
DNCP network state convergence and to reduce the number of redundant DNCP network state convergence. This reduces the number of queries
state transmissions between nodes. 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 5. Data Model
This section describes the local data structures a minimal This section describes the local data structures a minimal
implementation might use. This section is provided only as a implementation might use. This section is provided only as a
convenience for the implementor. Some of the optional extensions convenience for the implementor. Some of the optional extensions
(Section 6) describe additional data requirements, and some optional (Section 6) describe additional data requirements, and some optional
parts of the core protocol may also require more. parts of the core protocol may also require more.
A DNCP node has: A DNCP node has:
skipping to change at page 18, line 34 skipping to change at page 19, line 7
Multicast+Unicast mode, and as well to react to nodes with a greater Multicast+Unicast mode, and as well to react to nodes with a greater
node identifier appearing. If the highest node identifier present on node identifier appearing. If the highest node identifier present on
the link changes, the remote unicast address of the endpoints in the link changes, the remote unicast address of the endpoints in
Multicast-Listen+Unicast transport mode MUST be changed. If the node Multicast-Listen+Unicast transport mode MUST be changed. If the node
identifier of the local node is the highest one, the node MUST switch identifier of the local node is the highest one, the node MUST switch
back to, or stay in Multicast+Unicast mode, and normally form peer back to, or stay in Multicast+Unicast mode, and normally form peer
relationships with all peers. relationships with all peers.
7. Type-Length-Value Objects 7. Type-Length-Value Objects
Each TLV is encoded as a 2 byte type field, followed by a 2 byte
length field (of the value excluding header, in bytes, 0 meaning no
value) followed by the value itself, if any. Both type and length
fields in the header as well as all integer fields inside the value -
unless explicitly stated otherwise - are represented unsigned and in
network byte order. Padding bytes with value zero MUST be added up
to the next 4 byte boundary if the length is not divisible by 4.
These padding bytes MUST NOT be included in the number stored in the
length field. Each TLV which does not define optional fields or
variable-length content MAY be sent with additional nested TLVs
appended after the required TLV fields - and padding (if applicable)
to allow for extensibility. In this case the length field includes
the length of the original TLV, the length of the padding that are
inserted before the embedded TLVs and the length of the added TLVs.
Therefore, each node MUST accept received TLVs that are longer than
the fixed fields specified and ignore embedded TLVs it does not
understand.
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | | Value (if any) (+padding (if any)) |
.. ..
| (variable # of bytes) | | (variable # of bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Optional nested TLVs) | | (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 value of zero up to the next 4 byte boundary if
the Length is not divisible by 4.
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 which 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 not supported within that particular TLV
type. 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 For example, type=123 (0x7b) TLV with value 'x' (120 = 0x78) is
encoded as: 007B 0001 7800 0000. If it were to have sub-TLV of encoded as: 007B 0001 7800 0000. If it were to have sub-TLV of
type=124 (0x7c) with value 'y', it would be encoded as 007B 0009 7800 type=124 (0x7c) with value 'y', it would be encoded as 007B 000C 7800
0000 007C 0001 7900 0000. 0000 007C 0001 7900 0000.
In this section, the following special notation is used: In this section, the following special notation is used:
.. = octet string concatenation operation. .. = octet string concatenation operation.
H(x) = non-cryptographic hash function specified by DNCP profile. H(x) = non-cryptographic hash function specified by DNCP profile.
7.1. Request TLVs 7.1. Request TLVs
skipping to change at page 22, line 13 skipping to change at page 22, line 32
type and length). This enables, e.g., efficient state delta type and length). This enables, e.g., efficient state delta
processing and no-copy indexing by TLV type by the recipient. The processing and no-copy indexing by TLV type by the recipient. The
Node Data content MUST be passed along exactly as it was received. Node Data content MUST be passed along exactly as it was received.
It SHOULD be also verified on receipt that the locally calculated 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 H(Node Data) matches the content of the field within the TLV, and if
the hash differs, the TLV SHOULD be ignored. the hash differs, the TLV SHOULD be ignored.
7.3. Data TLVs within Node State TLV 7.3. Data TLVs within Node State TLV
These TLVs are published by the DNCP nodes, and therefore only These TLVs are published by the DNCP nodes, and therefore only
encoded within the Node State TLVs. If encountered outside Node encoded in the Node Data field of Node State TLVs. If encountered
State TLV, they MUST be silently ignored. outside Node State TLV, they MUST be silently ignored.
7.3.1. Peer TLV 7.3.1. Peer TLV
0 1 2 3 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 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 | | Type: PEER (8) | Length: > 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Node Identifier | | Peer Node Identifier |
| (length fixed in DNCP profile) | | (length fixed in DNCP profile) |
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Endpoint Identifier | | Peer Endpoint Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Endpoint Identifier | | (Local) Endpoint Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV indicates that the node in question vouches that the This TLV indicates that the node in question vouches that the
specified peer is reachable by it on the specified local endpoint. specified peer is reachable by it on the specified local endpoint.
The presence of this TLV at least guarantees that the node publishing The presence of this TLV at least guarantees that the node publishing
it has received traffic from the peer recently. For guaranteed up- it has received traffic from the peer recently. For guaranteed up-
to-date bidirectional reachability, the existence of both nodes' to-date bidirectional reachability, the existence of both nodes'
matching Peer TLVs needs to be checked. matching Peer TLVs needs to be checked.
7.3.2. Keep-Alive Interval TLV 7.3.2. Keep-Alive Interval TLV
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 23, line 44 skipping to change at page 24, line 15
8.2. PKI Based Trust Method 8.2. PKI Based Trust Method
A PKI-based trust-model enables more advanced management capabilities A PKI-based trust-model enables more advanced management capabilities
at the cost of increased complexity and bootstrapping effort. It at the cost of increased complexity and bootstrapping effort. It
however allows trust to be managed in a centralized manner and is however allows trust to be managed in a centralized manner and is
therefore useful for larger networks with a need for an authoritative therefore useful for larger networks with a need for an authoritative
trust management. trust management.
8.3. Certificate Based Trust Consensus Method 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 tradeoff
between security and user experience. This section includes guidance
for implementing an opportunistic security [RFC7435] method which
DNCP profiles can build upon and adapt for their specific
requirements.
The certificate-based consensus model is designed to be a compromise The certificate-based consensus model is designed to be a compromise
between trust management effort and flexibility. It is based on between trust management effort and flexibility. It is based on
X.509-certificates and allows each DNCP node to provide a trust X.509-certificates and allows each DNCP node to provide a trust
verdict on any other certificate and a consensus is found to verdict on any other certificate and a consensus is found to
determine whether a node using this certificate or any certificate determine whether a node using this certificate or any certificate
signed by it is to be trusted. signed by it is to be trusted.
A DNCP node not using this security method MUST ignore all announced A DNCP node not using this security method MUST ignore all announced
trust verdicts and MUST NOT announce any such verdicts by itself, trust verdicts and MUST NOT announce any such verdicts by itself,
i.e., any other normative language in this subsection does not apply i.e., any other normative language in this subsection does not apply
skipping to change at page 28, line 6 skipping to change at page 28, line 32
methods, or with something else. If the links with DNCP nodes can methods, or with something else. If the links with DNCP nodes can
be sufficiently secured or isolated, it is possible to run DNCP in be sufficiently secured or isolated, it is possible to run DNCP in
a secure manner without using any form of authentication or a secure manner without using any form of authentication or
encryption. encryption.
o Transport protocols' parameters such as port numbers to be used, o Transport protocols' parameters such as port numbers to be used,
or multicast address to be used. Unicast, multicast, and secure or multicast address to be used. Unicast, multicast, and secure
unicast may each require different parameters, if applicable. unicast may each require different parameters, if applicable.
o When receiving TLVs, what sort of TLVs are ignored in addition - o When receiving TLVs, what sort of TLVs are ignored in addition -
as specified in Section 4.4 - e.g., for security reasons. A DNCP as specified in Section 4.4 - e.g., for security reasons. While
profile may safely define the following DNCP TLVs to be safely the security of the node data published within the Node State TLVs
ignored: is already ensured by the base specification (if secure mode is
enabled, 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 * Anything received over multicast, except Node Endpoint TLV
(Section 7.2.1) and Network State TLV (Section 7.2.2). (Section 7.2.1) and Network State TLV (Section 7.2.2).
* Any TLVs received over unreliable unicast or multicast at too * Any TLVs received over unreliable unicast or multicast at too
high rate; Trickle will ensure eventual convergence given the high rate; Trickle will ensure eventual convergence given the
rate slows down at some point. rate slows down at some point.
o How to deal with node identifier collision as described in o How to deal with node identifier collision as described in
Section 4.4. Main options are either for one or both nodes to Section 4.4. Main options are either for one or both nodes to
skipping to change at page 29, line 5 skipping to change at page 29, line 37
* DNCP_KEEPALIVE_INTERVAL: How often keep-alives are to be sent * DNCP_KEEPALIVE_INTERVAL: How often keep-alives are to be sent
by default (if enabled). by default (if enabled).
* DNCP_KEEPALIVE_MULTIPLIER: How many times the * DNCP_KEEPALIVE_MULTIPLIER: How many times the
DNCP_KEEPALIVE_INTERVAL (or peer-supplied keep-alive interval DNCP_KEEPALIVE_INTERVAL (or peer-supplied keep-alive interval
value) a node may not be heard from to be considered still value) a node may not be heard from to be considered still
valid. This is just a default used in absence of any other valid. This is just a default used in absence of any other
configuration information, or particular per-endpoint configuration information, or particular per-endpoint
configuration. 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 10. Security Considerations
DNCP-based protocols may use multicast to indicate DNCP state changes DNCP-based protocols may use multicast to indicate DNCP state changes
and for keep-alive purposes. However, no actual published data TLVs and for keep-alive purposes. However, no actual published data TLVs
will be sent across that channel. Therefore an attacker may only 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 learn hash values of the state within DNCP and may be able to trigger
unicast synchronization attempts between nodes on a local link this unicast synchronization attempts between nodes on a local link this
way. A DNCP node MUST therefore rate-limit its reactions to way. A DNCP node MUST therefore rate-limit its reactions to
multicast packets. multicast packets.
skipping to change at page 30, line 4 skipping to change at page 30, line 43
5: Node state 5: Node state
6: Reserved (was: Custom) 6: Reserved (was: Custom)
7: Reserved (was: Fragment count) 7: Reserved (was: Fragment count)
8: Peer 8: Peer
9: Keep-alive interval 9: Keep-alive interval
10: Trust-Verdict 10: Trust-Verdict
11-31: Free - policy of 'standards action' should be used 11-31: Free - policy of standards action [RFC5226] should be used
32-511: Reserved for per-DNCP profile use 32-511: Reserved for per-DNCP profile use
512-767: Free - policy of 'standards action' should be used 512-767: Free - policy of standards action [RFC5226] should be
used
768-1023: Private use 768-1023: Private use [RFC5226]
1024-65535: Reserved for future protocol evolution (for example, 1024-65535: Reserved for future protocol evolution (for example,
DNCP version 2) DNCP version 2)
12. References 12. References
12.1. Normative references 12.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, March 1997.
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
"The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, "The Trickle Algorithm", RFC 6206, March 2011.
March 2011, <http://www.rfc-editor.org/info/rfc6206>.
[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>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
(TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.
RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
(SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI IANA Considerations Section in RFCs", BCP 26, RFC 5226,
10.17487/RFC6234, May 2011, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc6234>. <http://www.rfc-editor.org/info/rfc5226>.
12.2. Informative references 12.2. Informative references
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6", RFC Stevens, "Basic Socket Interface Extensions for IPv6", RFC
3493, DOI 10.17487/RFC3493, February 2003, 3493, February 2003.
<http://www.rfc-editor.org/info/rfc3493>.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[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>.
Appendix A. Alternative Modes of Operation Appendix A. Alternative Modes of Operation
Beyond what is described in the main text, the protocol allows for Beyond what is described in the main text, the protocol allows for
other uses. These are provided as examples. other uses. These are provided as examples.
A.1. Read-only Operation A.1. Read-only Operation
If a node uses just a single endpoint and does not need to publish If a node uses just a single endpoint and does not need to publish
any TLVs, full DNCP node functionality is not required. Such limited any TLVs, full DNCP node functionality is not required. Such limited
skipping to change at page 31, line 34 skipping to change at page 32, line 29
it can detect (for example) nodes with the highest node identifier on 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 each of the endpoints (if any). Any TLVs received from one of them
would be forwarded verbatim as unicast to the other node with highest would be forwarded verbatim as unicast to the other node with highest
node identifier. node identifier.
Any tinkering with the TLVs would remove guarantees of this scheme Any tinkering with the TLVs would remove guarantees of this scheme
working; however passive monitoring would obviously be fine. This working; however passive monitoring would obviously be fine. This
type of simple forwarding cannot be chained, as it does not send type of simple forwarding cannot be chained, as it does not send
anything proactively. anything proactively.
Appendix B. Some Questions and Answers [RFC Editor: please remove] Appendix B. DNCP Profile Additional Guidance
This appendix explains implications of design choices made when
specifying 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 64KB 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 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
which 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
which 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 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 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 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 re-
authentication/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 the writing of 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.
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 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 which 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 which support both protocols 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 = 200ms, 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.
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 unicast
connections, and those that fail sufficiently many retransmissions
are dropped much before keep-alive actually would fire.
o No support for dense multicast-enabled link optimization
(Section 6.2); SHSP is a simple protocol for few nodes (network-
wide, not even to mention on a single link), and therefore would
not provide any benefit.
Appendix D. Some Questions and Answers [RFC Editor: please remove]
Q: 32-bit endpoint id? Q: 32-bit endpoint id?
A: Here, it would save 32 bits per peer if it was 16 bits (and less A: Here, it would save 32 bits per peer if it was 16 bits (and less
is not realistic). However, TLVs defined elsewhere would not seem to is not realistic). However, TLVs defined elsewhere would not seem to
even gain that much on average. 32 bits is also used for ifindex in even gain that much on average. 32 bits is also used for ifindex in
various operating systems, making for simpler implementation. various operating systems, making for simpler implementation.
Q: Why have topology information at all? Q: Why have topology information at all?
A: It is an alternative to the more traditional seq#/TTL-based A: It is an alternative to the more traditional seq#/TTL-based
flooding schemes. In steady state, there is no need to, e.g., re- flooding schemes. In steady state, there is no need to, e.g., re-
publish every now and then. publish every now and then.
Appendix C. Changelog [RFC Editor: please remove] Appendix E. Changelog [RFC Editor: please remove]
draft-ietf-homenet-dncp-10:
o Added profile guidance section, as well as example profile.
draft-ietf-homenet-dncp-09: draft-ietf-homenet-dncp-09:
o Reserved 1024+ TLV types for future versions (=versioning o Reserved 1024+ TLV types for future versions (=versioning
mechanism); private use section moved from 192-255 to 512-767. mechanism); private use section moved from 192-255 to 512-767.
o Added applicability statement and clarified some text based on o Added applicability statement and clarified some text based on
reviews. reviews.
draft-ietf-homenet-dncp-08: draft-ietf-homenet-dncp-08:
skipping to change at page 33, line 44 skipping to change at page 37, line 14
o Trickle is reset only when locally calculated network state hash o Trickle is reset only when locally calculated network state hash
is changes, not as remote different network state hash is seen. is changes, not as remote different network state hash is seen.
This prevents, e.g., attacks by multicast with one multicast This prevents, e.g., attacks by multicast with one multicast
packet to force Trickle reset on every interface of every node on packet to force Trickle reset on every interface of every node on
a link. a link.
o Instead of 'ping', use 'keep-alive' (optional) for dead peer o Instead of 'ping', use 'keep-alive' (optional) for dead peer
detection. Different message used! detection. Different message used!
Appendix D. Draft Source [RFC Editor: please remove] Appendix F. Draft Source [RFC Editor: please remove]
As usual, this draft is available at https://github.com/fingon/ietf- As usual, this draft is available at https://github.com/fingon/ietf-
drafts/ in source format (with nice Makefile too). Feel free to send drafts/ in source format (with nice Makefile too). Feel free to send
comments and/or pull requests if and when you have changes to it! comments and/or pull requests if and when you have changes to it!
Appendix E. Acknowledgements Appendix G. Acknowledgements
Thanks to Ole Troan, Pierre Pfister, Mark Baugher, Mark Townsley, Thanks to Ole Troan, Pierre Pfister, Mark Baugher, Mark Townsley,
Juliusz Chroboczek, Jiazi Yi, Mikael Abrahamsson, Brian Carpenter, Juliusz Chroboczek, Jiazi Yi, Mikael Abrahamsson, Brian Carpenter,
Thomas Clausen, DENG Hui and Margaret Cullen for their contributions Thomas Clausen, DENG Hui and Margaret Cullen for their contributions
to the draft. to the draft.
Thanks to Kaiwen Jin and Xavier Bonnetain for their related research
work.
Authors' Addresses Authors' Addresses
Markus Stenberg Markus Stenberg
Independent Independent
Helsinki 00930 Helsinki 00930
Finland Finland
Email: markus.stenberg@iki.fi Email: markus.stenberg@iki.fi
Steven Barth Steven Barth
 End of changes. 58 change blocks. 
149 lines changed or deleted 334 lines changed or added

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