draft-ietf-homenet-dncp-04.txt   draft-ietf-homenet-dncp-05.txt 
Homenet Working Group M. Stenberg Homenet Working Group M. Stenberg
Internet-Draft Internet-Draft
Intended status: Standards Track S. Barth Intended status: Standards Track S. Barth
Expires: December 3, 2015 Expires: December 5, 2015
June 1, 2015 June 3, 2015
Distributed Node Consensus Protocol Distributed Node Consensus Protocol
draft-ietf-homenet-dncp-04 draft-ietf-homenet-dncp-05
Abstract Abstract
This document describes the Distributed Node Consensus Protocol This document describes the Distributed Node Consensus Protocol
(DNCP), a generic state synchronization protocol which uses Trickle (DNCP), a generic state synchronization protocol which uses Trickle
and Merkle trees. DNCP is transport agnostic and leaves some of the and Merkle trees. DNCP is transport agnostic and leaves some of the
details to be specified in profiles, which define actual details to be specified in profiles, which define actual
implementable DNCP based protocols. implementable DNCP based protocols.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 December 3, 2015. This Internet-Draft will expire on December 5, 2015.
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 13 skipping to change at page 2, line 13
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
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Trickle-Driven Status Updates . . . . . . . . . . . . . . 7 5.1. Trickle-Driven Status Updates . . . . . . . . . . . . . . 7
5.2. Processing of Received TLVs . . . . . . . . . . . . . . . 7 5.2. Processing of Received TLVs . . . . . . . . . . . . . . . 8
5.3. Adding and Removing Peers . . . . . . . . . . . . . . . . 9 5.3. Adding and Removing Peers . . . . . . . . . . . . . . . . 9
5.4. Purging Unreachable Nodes . . . . . . . . . . . . . . . . 10 5.4. Purging Unreachable Nodes . . . . . . . . . . . . . . . . 10
6. Optional Extensions . . . . . . . . . . . . . . . . . . . . . 10 6. Optional Extensions . . . . . . . . . . . . . . . . . . . . . 11
6.1. Keep-Alives . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Keep-Alives . . . . . . . . . . . . . . . . . . . . . . . 11
6.1.1. Data Model Additions . . . . . . . . . . . . . . . . 11 6.1.1. Data Model Additions . . . . . . . . . . . . . . . . 11
6.1.2. Per-Endpoint Periodic Keep-Alives . . . . . . . . . . 11 6.1.2. Per-Endpoint Periodic Keep-Alives . . . . . . . . . . 12
6.1.3. Per-Peer Periodic Keep-Alives . . . . . . . . . . . . 11 6.1.3. Per-Peer Periodic Keep-Alives . . . . . . . . . . . . 12
6.1.4. Received TLV Processing Additions . . . . . . . . . . 11 6.1.4. Received TLV Processing Additions . . . . . . . . . . 12
6.1.5. Neighbor Removal . . . . . . . . . . . . . . . . . . 12 6.1.5. Neighbor Removal . . . . . . . . . . . . . . . . . . 12
6.2. Support For Dense Broadcast Links . . . . . . . . . . . . 12 6.2. Support For Dense Broadcast Links . . . . . . . . . . . . 12
6.3. Node Data Fragmentation . . . . . . . . . . . . . . . . . 12 6.3. Node Data Fragmentation . . . . . . . . . . . . . . . . . 13
7. Type-Length-Value Objects . . . . . . . . . . . . . . . . . . 13 7. Type-Length-Value Objects . . . . . . . . . . . . . . . . . . 14
7.1. Request TLVs . . . . . . . . . . . . . . . . . . . . . . 14 7.1. Request TLVs . . . . . . . . . . . . . . . . . . . . . . 14
7.1.1. Request Network State TLV . . . . . . . . . . . . . . 14 7.1.1. Request Network State TLV . . . . . . . . . . . . . . 14
7.1.2. Request Node State TLV . . . . . . . . . . . . . . . 14 7.1.2. Request Node State TLV . . . . . . . . . . . . . . . 14
7.2. Data TLVs . . . . . . . . . . . . . . . . . . . . . . . . 14 7.2. Data TLVs . . . . . . . . . . . . . . . . . . . . . . . . 15
7.2.1. Node Endpoint TLV . . . . . . . . . . . . . . . . . . 14 7.2.1. Node Endpoint TLV . . . . . . . . . . . . . . . . . . 15
7.2.2. Network State TLV . . . . . . . . . . . . . . . . . . 15 7.2.2. Network State TLV . . . . . . . . . . . . . . . . . . 15
7.2.3. Node State TLV . . . . . . . . . . . . . . . . . . . 15 7.2.3. Node State TLV . . . . . . . . . . . . . . . . . . . 16
7.2.4. Custom TLV . . . . . . . . . . . . . . . . . . . . . 16 7.2.4. Custom TLV . . . . . . . . . . . . . . . . . . . . . 17
7.3. Data TLVs within Node State TLV . . . . . . . . . . . . . 16 7.3. Data TLVs within Node State TLV . . . . . . . . . . . . . 17
7.3.1. Fragment Count TLV . . . . . . . . . . . . . . . . . 17 7.3.1. Fragment Count TLV . . . . . . . . . . . . . . . . . 17
7.3.2. Neighbor TLV . . . . . . . . . . . . . . . . . . . . 17 7.3.2. Neighbor TLV . . . . . . . . . . . . . . . . . . . . 18
7.3.3. Keep-Alive Interval TLV . . . . . . . . . . . . . . . 17 7.3.3. Keep-Alive Interval TLV . . . . . . . . . . . . . . . 18
8. Security and Trust Management . . . . . . . . . . . . . . . . 18 8. Security and Trust Management . . . . . . . . . . . . . . . . 19
8.1. Pre-Shared Key Based Trust Method . . . . . . . . . . . . 18 8.1. Pre-Shared Key Based Trust Method . . . . . . . . . . . . 19
8.2. PKI Based Trust Method . . . . . . . . . . . . . . . . . 18 8.2. PKI Based Trust Method . . . . . . . . . . . . . . . . . 19
8.3. Certificate Based Trust Consensus Method . . . . . . . . 19 8.3. Certificate Based Trust Consensus Method . . . . . . . . 19
8.3.1. Trust Verdicts . . . . . . . . . . . . . . . . . . . 19 8.3.1. Trust Verdicts . . . . . . . . . . . . . . . . . . . 20
8.3.2. Trust Cache . . . . . . . . . . . . . . . . . . . . . 20 8.3.2. Trust Cache . . . . . . . . . . . . . . . . . . . . . 21
8.3.3. Announcement of Verdicts . . . . . . . . . . . . . . 20 8.3.3. Announcement of Verdicts . . . . . . . . . . . . . . 21
8.3.4. Bootstrap Ceremonies . . . . . . . . . . . . . . . . 21 8.3.4. Bootstrap Ceremonies . . . . . . . . . . . . . . . . 22
9. DNCP Profile-Specific Definitions . . . . . . . . . . . . . . 22 9. DNCP Profile-Specific Definitions . . . . . . . . . . . . . . 23
10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
12.1. Normative references . . . . . . . . . . . . . . . . . . 25 12.1. Normative references . . . . . . . . . . . . . . . . . . 26
12.2. Informative references . . . . . . . . . . . . . . . . . 25 12.2. Informative references . . . . . . . . . . . . . . . . . 26
Appendix A. Some Questions and Answers [RFC Editor: please Appendix A. Some Questions and Answers [RFC Editor: please
remove] . . . . . . . . . . . . . . . . . . . . . . 25 remove] . . . . . . . . . . . . . . . . . . . . . . 26
Appendix B. Changelog [RFC Editor: please remove] . . . . . . . 26 Appendix B. Changelog [RFC Editor: please remove] . . . . . . . 26
Appendix C. Draft Source [RFC Editor: please remove] . . . . . . 27 Appendix C. Draft Source [RFC Editor: please remove] . . . . . . 28
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 27 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
DNCP is designed to provide a way for nodes to publish data DNCP is designed to provide a way for nodes to publish data
consisting of an ordered set of TLV (Type-Length-Value) tuples and to consisting of an ordered set of TLV (Type-Length-Value) tuples and to
receive the data published by all other reachable DNCP nodes. receive the data published by all other reachable DNCP nodes.
DNCP validates the set of data within it by ensuring that it is DNCP validates the set of data within it by ensuring that it is
reachable via nodes that are currently accounted for; therefore, reachable via nodes that are currently accounted for; therefore,
unlike Time-To-Live (TTL) based solutions, it does not require unlike Time-To-Live (TTL) based solutions, it does not require
skipping to change at page 3, line 35 skipping to change at page 3, line 35
stale data. Another notable feature is the use of Trickle to send stale data. Another notable feature is the use of Trickle to send
status updates as it makes the DNCP network very thrifty when there status updates as it makes the DNCP network very thrifty when there
are no updates. DNCP is most suitable for data that changes only are no updates. DNCP is most suitable for data that changes only
gradually to gain the maximum benefit from using Trickle, and if more gradually to gain the maximum benefit from using Trickle, and if more
rapid state exchanges are needed, something point-to-point is rapid state exchanges are needed, something point-to-point is
recommended and just e.g. publishing of addresses of the services recommended and just e.g. publishing of addresses of the services
within DNCP. within DNCP.
DNCP has relatively few requirements for the underlying transport; it DNCP has relatively few requirements for the underlying transport; it
requires some way of transmitting either unicast datagram or stream requires some way of transmitting either unicast datagram or stream
data to a DNCP peer and, if used in multicast mode, a way of sending data to a peer and, if used in multicast mode, a way of sending
multicast datagrams. If security is desired and one of the built-in multicast datagrams. If security is desired and one of the built-in
security methods is to be used, support for some TLS-derived 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. [RFC6347] on top of UDP - is also required.
2. Requirements Language 2. 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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Terminology 3. Terminology
DNCP profile is a definition of a set of rules and values listed in DNCP profile a definition of the set of rules and values listed
Section 9 specifying the behavior of a DNCP based protocol, such as in Section 9 specifying the behavior of a DNCP
the used transport method. For readability, any DNCP profile based protocol, such as the used transport method.
specific parameters with a profile-specific fixed value are prefixed
with DNCP_.
DNCP node is a single node which runs a protocol based on a DNCP For readability, any DNCP profile specific
profile. parameters with a profile-specific fixed value are
prefixed with DNCP_.
DNCP network is a set of DNCP nodes running the same DNCP profile DNCP node a single node which runs a protocol based on a DNCP
that can reach each other, either via discovered connectivity in the profile.
underlying network, or using each other's addresses learned via other
means. As DNCP exchanges are bidirectional, DNCP nodes connected via
only unidirectional links are not considered connected.
DNCP message is an abstract concept: when using a reliable stream DNCP network a set of DNCP nodes running the same DNCP profile
transport, the whole stream of TLVs can be considered a single that can reach each other, either via discovered
message, with new TLVs becoming one by one available once they have connectivity in the underlying network, or using
been fully received. On a datagram transport, each individual each other's addresses learned via other means. As
datagram is considered a separate message. DNCP exchanges are bidirectional, DNCP nodes
connected via only unidirectional links are not
considered connected.
Node identifier is an opaque fixed-length identifier consisting of DNCP message an abstract concept - when using a reliable stream
DNCP_NODE_IDENTIFIER_LENGTH bytes which uniquely identifies a DNCP transport, the whole stream of TLVs can be
node within a DNCP network. considered a single message, with new TLVs becoming
one by one available once they have been fully
received. On a datagram transport, each individual
datagram is considered a separate message.
Link indicates a link-layer media over which directly connected nodes Node identifier an opaque fixed-length identifier consisting of
can communicate. DNCP_NODE_IDENTIFIER_LENGTH bytes which uniquely
identifies a DNCP node within a DNCP network.
Interface indicates a port of a node that is connected to a Link a link-layer media over which directly connected
particular link. nodes can communicate.
Endpoint denotes a locally configured use of DNCP on a DNCP node. It Interface a port of a node that is connected to a particular
is attached either to an interface, a specific remote unicast address link.
to be contacted, or a range of remote unicast addresses that are
allowed to contact.
Endpoint identifier is a 32-bit opaque value, which identifies a Endpoint a locally configured use of DNCP on a DNCP node. It
particular endpoint of that particular DNCP node. The value 0 is is attached either to an interface, a specific
reserved for DNCP and sub-protocol purposes and MUST NOT be used to remote unicast address to be contacted, or a range
identify an actual endpoint. This definition is in sync with the of remote unicast addresses that are allowed to
interface index definition in [RFC3493], as the non-zero small contact.
positive integers should comfortably fit within 32 bits.
(DNCP) peer refers to another DNCP node with which a DNCP node Endpoint a 32-bit opaque value, which identifies a
communicates directly using a particular local and remote endpoint identifier particular endpoint of that particular DNCP node.
pair. The value 0 is reserved for DNCP and sub-protocol
purposes and MUST NOT be 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.
Node data is a set of TLVs published by a node in the DNCP network. Peer another DNCP node with which a DNCP node
The whole node data is owned by the node that publishes it, and it communicates directly using a particular local and
MUST be passed along as-is, including TLVs unknown to the forwarder. remote endpoint pair.
Node state is a set of metadata attributes for node data. It Node data a set of TLVs published by a node in the DNCP
includes a sequence number for versioning, a hash value for comparing network. The whole node data is owned by the node
and a timestamp indicating the time passed since its last that publishes it, and it MUST be passed along as-
publication. The hash function and the number of bits used are is, including TLVs unknown to the forwarder.
defined in the DNCP profile.
Network state (hash) is a hash value which represents the current Node state a set of metadata attributes for node data. It
state of the network. The hash function and the number of bits used includes a sequence number for versioning, a hash
are defined in the DNCP profile. Whenever a node is added, removed value for comparing and a timestamp indicating the
or updates its published node data this hash value changes as well. time passed since its last publication. The hash
It is calculated over each reachable nodes' update number function and the number of bits used are defined in
concatenated with the hash value of its node data. For calculation the DNCP profile.
these tuples are sorted in ascending order of the respective node's
node identifier.
(Trust) verdict is a statement about the trustworthiness of a Network state a hash value which represents the current state of
certificate announced by a node participating in the certificate hash the network. The hash function and the number of
based trust consensus mechanism. bits used are defined in the DNCP profile.
Whenever a node is added, removed or updates its
published node data this hash value changes as
well. It is calculated over each reachable nodes'
update number concatenated with the hash value of
its node data. For calculation these tuples are
sorted in ascending order of the respective node's
node identifier.
Effective (trust) verdict for a certificate is defined as the verdict Trust verdict a statement about the trustworthiness of a
with the highest priority within the set of verdicts announced for certificate announced by a node participating in
the certificate in the DNCP network. the certificate based trust consensus mechanism.
Neighbor graph is the undirected graph of DNCP nodes produced by Effective trust the trust verdict with the highest priority within
retaining only bidirectional peer relationships between nodes. verdict the set of trust verdicts announced for the
certificate in the DNCP network.
Neighbor graph the undirected graph of DNCP nodes produced by
retaining only bidirectional peer relationships
between nodes.
4. Data Model 4. Data Model
A DNCP node has: A DNCP node has:
o A timestamp indicating the most recent neighbor graph traversal o A timestamp indicating the most recent neighbor graph traversal
described in Section 5.4. described in Section 5.4.
o Something with data about most recent request(s) for network state o A data structure containing data about the most recently sent
- simplest one being a timestamp for the most recent request for Request Network State TLVs (Section 7.1.1). The simplest option
network state (see Section 5.2). is keeping a timestamp of the most recent request (see
Section 5.2).
A DNCP node has for every DNCP node in the DNCP network: A DNCP node has for every DNCP node in the DNCP network:
o Node identifier, which uniquely identifies the node. o Node identifier: the unique identifier of the node.
o Node data, an ordered set of TLV tuples published by that o Node data: the ordered set of TLV tuples published by that
particular node. This set of TLVs MUST be strictly ordered based particular node. This set of TLVs MUST be strictly ordered based
on ascending binary content (including TLV type and length). This on ascending binary content (including TLV type and length). This
facilitates linear time state delta processing. facilitates linear time state delta processing.
o Latest update sequence number, a 32 bit number that is incremented o Latest update sequence number: the 32-bit sequence number that is
any time the TLV set is published. For comparison purposes, a incremented any time the TLV set is published. For comparison
looping comparison should be used to avoid problems in case of purposes, a looping comparison should be used to avoid problems in
overflow. An example would be: a < b <=> (a - b) % 2^32 & 2^31 != case of overflow. An example would be: a < b <=> (a - b) % 2^32 &
0. 2^31 != 0.
o Relative time (in milliseconds), time since the current TLV data o Relative time delta: the time (in milliseconds) since the current
set with the current update sequence number was published. It is TLV data set with the current update sequence number was
also a 32 bit number on the wire. If this number is close to published. It is also a 32 bit number on the wire. If this
overflow (greater than 2^32-2^16), a node MUST re-publish its TLVs number is close to overflow (greater than 2^32-2^16), a node MUST
even if there is no change. In other words, absent any other re-publish its TLVs even if there is no change. In other words,
changes, the TLV set MUST be re-published roughly every 49 days. absent any other changes, the TLV set MUST be re-published roughly
every 49 days.
o Timestamp, the time it was last reachable based on neighbor graph o Timestamp: the time it was last reachable based on neighbor graph
traversal described in Section 5.4. traversal described in Section 5.4.
Additionally, a DNCP node has a set of endpoints for which DNCP is Additionally, a DNCP node has a set of endpoints for which DNCP is
configured to be used. For each such endpoint, a node has: configured to be used. For each such endpoint, a node has:
o An endpoint identifier, a 32-bit opaque value. o Endpoint identifier: the 32-bit opaque value uniquely identifying
it.
o An interface, a unicast address of a DNCP node it should connect o Trickle [RFC6206] instance: the endpoint's individual trickle
with, or a range of addresses from which DNCP nodes are allowed to instance with parameters I, T, and c.
connect.
o A Trickle [RFC6206] instance with parameters I, T, and c. and one (or more) of the following:
For each remote (DNCP node, endpoint) pair detected on a local o Interface: the assigned local network interface.
endpoint, a DNCP node has:
o The node identifier of the DNCP peer. o Unicast address: the DNCP node it should connect with.
o The endpoint identifier of the DNCP peer. o Range of addresses: the DNCP nodes that are allowed to connect.
o The most recent address used by the DNCP peer (authenticated and For each remote (peer, endpoint) pair detected on a local endpoint, a
authorized, if security is enabled). 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).
5. Operation 5. Operation
The DNCP protocol consists of Trickle [RFC6206] driven unicast or The DNCP protocol consists of Trickle [RFC6206] driven unicast or
multicast status payloads which indicate the current status of shared multicast status payloads which indicate the current status of shared
TLV data and additional unicast exchanges which ensure DNCP peer TLV data and additional unicast exchanges which ensure peer
reachability and synchronize the data when necessary. reachability and synchronize the data when necessary.
If DNCP is to be used on a multicast-capable interface, as opposed to If DNCP is to be used on a multicast-capable interface, as opposed to
only point-to-point using unicast, a datagram-based transport which only point-to-point using unicast, a datagram-based transport which
supports multicast SHOULD be defined in the DNCP profile to be used supports multicast SHOULD be defined in the DNCP profile to be used
for the TLVs to be sent to the whole link. As this is used only to for the TLVs to be sent to the whole link. As this is used only to
identify potential new DNCP nodes and to notify that a unicast identify potential new DNCP nodes and to 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 particularly secure. to be particularly secure.
skipping to change at page 8, line 34 skipping to change at page 9, line 6
TLV (Section 7.2.3) for the corresponding node. The optional node TLV (Section 7.2.3) for the corresponding node. The optional node
data part MUST be included in the TLV. data part MUST be included in the TLV.
o Network State TLV (Section 7.2.2): If the network state hash o Network State TLV (Section 7.2.2): If the network state hash
differs from the locally calculated network state hash, and the differs from the locally calculated network state hash, and the
receiver is unaware of any particular node state differences with receiver is unaware of any particular node state differences with
the sender, the receiver MUST reply with a Request Network State the sender, the receiver MUST reply with a Request Network State
TLV (Section 7.1.1). These replies MUST be rate limited to only 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 at most one reply per link per unique network state hash within
Imin. The simplest way to ensure this rate limit is a timestamp Imin. The simplest way to ensure this rate limit is a timestamp
indicating requests, and just sending at most one request for indicating requests, and sending at most one Request Network State
network state per Imin. To facilitate faster state TLV (Section 7.1.1) per Imin. To facilitate faster state
synchronization, if a Request Network State TLV is sent in a synchronization, if a Request Network State TLV is sent in a
reply, a local, current Network State TLV SHOULD be also sent. reply, a local, current Network State TLV SHOULD be also sent.
o Node State TLV (Section 7.2.3): o Node State TLV (Section 7.2.3):
* If the node identifier matches the local node identifier and * If the node identifier matches the local node identifier and
the TLV has a higher update sequence number than its current the TLV has a higher update sequence number than its current
local value, or the same update sequence number and a different local value, or the same update sequence number and a different
hash, the node SHOULD re-publish its own node data with an hash, the node SHOULD re-publish its own node data with an
update sequence number 1000 higher than the received one. This update sequence number 1000 higher than the received one. This
skipping to change at page 9, line 41 skipping to change at page 10, line 15
o If it comes via unicast, the remote node MUST be added as a peer o If it comes via unicast, the remote node MUST be added as a peer
on the endpoint and a Neighbor TLV (Section 7.3.2) MUST be created on the endpoint and a Neighbor TLV (Section 7.3.2) MUST be created
for it. for it.
o If it comes via multicast, the node SHOULD be sent a (possibly o If it comes via multicast, the node SHOULD be sent a (possibly
rate-limited) unicast Request Network State TLV (Section 7.1.1). 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 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
means MUST be employed to ensure a DNCP peer is present. When the means MUST be employed to ensure its presence. When the peer is no
peer is no longer present, the Neighbor TLV and the local DNCP peer longer present, the Neighbor TLV and the local DNCP peer state MUST
state MUST be removed. be removed.
If the DNCP profile supports dense broadcast link optimization If the DNCP profile supports dense broadcast link optimization
(Section 6.2), and if a node does not have the highest node (Section 6.2), and if a node does not have the highest node
identifier on a link, the endpoint may be in a unicast mode in which identifier on a link, the endpoint may be in a unicast mode in which
multicast traffic is only listened to. In that mode, all peers multicast traffic is only listened to. In that mode, all peers
except the one with the highest node identifier MUST NOT have except the one with the highest node identifier MUST NOT have
Neighbor TLV (Section 7.3.2) published nor any local state. Neighbor TLV (Section 7.3.2) published nor any local state.
5.4. Purging Unreachable Nodes 5.4. Purging Unreachable Nodes
skipping to change at page 10, line 40 skipping to change at page 11, line 15
6. Optional Extensions 6. Optional Extensions
This section specifies extensions to the core protocol that a DNCP This section specifies extensions to the core protocol that a DNCP
profile may want to use. profile may want to use.
6.1. Keep-Alives 6.1. Keep-Alives
Trickle-driven status updates (Section 5.1) provide a mechanism for Trickle-driven status updates (Section 5.1) provide a mechanism for
handling of new peer detection (if applicable) on an endpoint, as handling of new peer detection (if applicable) on an endpoint, as
well as state change notifications. Another mechanism may be needed well as state change notifications. Another mechanism may be needed
to get rid of old, no longer valid DNCP peers if the transport or to get rid of old, no longer valid peers if the transport or lower
lower layers do not provide one. layers do not provide one.
If keep-alives are not specified in the DNCP profile, the rest of If keep-alives are not specified in the DNCP profile, the rest of
this subsection MUST be ignored. this subsection MUST be ignored.
A DNCP profile MAY specify either per-endpoint or per-peer keep-alive A DNCP profile MAY specify either per-endpoint or per-peer keep-alive
support. support.
For every endpoint that a keep-alive is specified for in the DNCP For every endpoint that a keep-alive is specified for in the DNCP
profile, the endpoint-specific keep-alive interval MUST be profile, the endpoint-specific keep-alive interval MUST be
maintained. By default, it is DNCP_KEEPALIVE_INTERVAL. If there is maintained. By default, it is DNCP_KEEPALIVE_INTERVAL. If there is
skipping to change at page 13, line 33 skipping to change at page 14, line 12
considered reachable if the fragment number 0 itself is reachable considered reachable if the fragment number 0 itself is reachable
based on graph traversal. based on graph traversal.
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 Each TLV is encoded as a 2 byte type field, followed by a 2 byte
length field (of the value, excluding header; 0 means no value) length field (of the value, excluding header; 0 means no value)
followed by the value itself (if any). Both type and length fields 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 in the header as well as all integer fields inside the value - unless
explicitly stated otherwise - are represented in network byte order. explicitly stated otherwise - are represented in network byte order.
Zeroed padding bytes MUST be added up to the next 4 byte boundary if Padding bytes with value zero MUST be added up to the next 4 byte
the length is not divisible by 4. These padding bytes MUST NOT be boundary if the length is not divisible by 4. These padding bytes
included in the length field. MUST NOT be included in the number stored in the length field.
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 |
| (variable # of bytes) | | (variable # of bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 14, line 21 skipping to change at page 15, line 4
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: REQ-NETWORK-STATE (1) | Length: 0 | | Type: REQ-NETWORK-STATE (1) | Length: 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV is used to request response with a Network State TLV 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). (Section 7.2.2) and all Node State TLVs (Section 7.2.3).
7.1.2. Request Node State TLV 7.1.2. Request Node State 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: REQ-NODE-STATE (2) | Length: >0 | | Type: REQ-NODE-STATE (2) | Length: >0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node Identifier | | Node Identifier |
| (length fixed in DNCP profile) | | (length fixed in DNCP profile) |
... ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV is used to request a Node State TLV (Section 7.2.3) This TLV is used to request a Node State TLV (Section 7.2.3)
(including node data) for the node with matching node identifier. (including node data) for the node matching the node identifier.
7.2. Data TLVs 7.2. Data TLVs
7.2.1. Node Endpoint TLV 7.2.1. Node Endpoint 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: NODE-ENDPOINT (3) | Length: > 4 | | Type: NODE-ENDPOINT (3) | Length: > 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 19, line 9 skipping to change at page 19, line 44
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
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 verdict on X.509-certificates and allows each DNCP node to provide a trust
any other certificate and a consensus is found to determine whether a verdict on any other certificate and a consensus is found to
node using this certificate or any certificate signed by it is to be determine whether a node using this certificate or any certificate
trusted. signed by it is to be trusted.
The current effective trust verdict for any certificate is defined as The current effective trust verdict for any certificate is defined as
the one with the highest priority from all verdicts announced for the one with the highest priority from all trust verdicts announced
said certificate at the time. for said certificate at the time.
8.3.1. Trust Verdicts 8.3.1. Trust Verdicts
Trust Verdicts are statements of DNCP nodes about the trustworthiness Trust verdicts are statements of DNCP nodes about the trustworthiness
of X.509-certificates. There are 5 possible verdicts in order of of X.509-certificates. There are 5 possible trust verdicts in order
ascending priority: of ascending priority:
0 Neutral : no verdict exists but the DNCP network should determine 0 (Neutral): no trust verdict exists but the DNCP network should
one. determine one.
1 Cached Trust : the last known effective verdict was Configured or 1 (Cached Trust): the last known effective trust verdict was
Cached Trust. Configured or Cached Trust.
2 Cached Distrust : the last known effective verdict was Configured 2 (Cached Distrust): the last known effective trust verdict was
or Cached Distrust. Configured or Cached Distrust.
3 Configured Trust : trustworthy based upon an external ceremony or 3 (Configured Trust): trustworthy based upon an external ceremony
configuration. or configuration.
4 Configured Distrust : not trustworthy based upon an external 4 (Configured Distrust): not trustworthy based upon an external
ceremony or configuration. ceremony or configuration.
Verdicts are differentiated in 3 groups: Trust verdicts are differentiated in 3 groups:
o Configured verdicts are used to announce explicit verdicts a node o Configured verdicts are used to announce explicit trust verdicts a
has based on any external trust bootstrap or predefined relation a node has based on any external trust bootstrap or predefined
node has formed with a given certificate. relation a node has formed with a given certificate.
o Cached verdicts are used to retain the last known trust state in o Cached verdicts are used to retain the last known trust state in
case all nodes with configured verdicts about a given certificate case all nodes with configured verdicts about a given certificate
have been disconnected or turned off. have been disconnected or turned off.
o The Neutral verdict is used to announce a new node intending to 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. join the network so a final verdict for it can be found.
The current effective trust verdict for any certificate is defined as The current effective trust verdict for any certificate is defined as
the one with the highest priority within the set of verdicts + the one with the highest priority within the set of trust verdicts
announced for the certificate in the DNCP network. A node MUST be announced for the certificate in the DNCP network. A node MUST be
trusted for participating in the DNCP network if and only if the trusted for participating in the DNCP network if and only if the
current effective verdict for its own certificate or any one in its current effective trust verdict for its own certificate or any one in
certificate hierarchy is (Cached or Configured) Trust and none of the its certificate hierarchy is (Cached or Configured) Trust and none of
certificates in its hierarchy have an effective verdict of (Cached or the certificates in its hierarchy have an effective trust verdict of
Configured) Distrust. In case a node has a configured verdict, which (Cached or Configured) Distrust. In case a node has a configured
is different from the current effective verdict for a certificate, verdict, which is different from the current effective trust verdict
the current effective verdict takes precedence in deciding for a certificate, the current effective trust verdict takes
trustworthiness. Despite that, the node still retains and announces precedence in deciding trustworthiness. Despite that, the node still
its configured verdict. retains and announces its configured verdict.
8.3.2. Trust Cache 8.3.2. Trust Cache
Each node SHOULD maintain a trust cache containing the current Each node SHOULD maintain a trust cache containing the current
effective trust verdicts for all certificates currently announced in effective trust verdicts for all certificates currently announced in
the DNCP network. This cache is used as a backup of the last known 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 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 known certificate. It SHOULD be saved to a non-volatile memory at
reasonable time intervals to survive a reboot or power outage. reasonable time intervals to survive a reboot or power outage.
Every time a node (re)joins the network or detects the change of an Every time a node (re)joins the network or detects the change of an
effective trust verdict for any certificate, it will synchronize its effective trust verdict for any certificate, it will synchronize its
cache, i.e. store new effective verdicts overwriting any previously cache, i.e. store new effective trust verdicts overwriting any
cached verdicts. Configured verdicts are stored in the cache as previously cached verdicts. Configured verdicts are stored in the
their respective cached counterparts. Neutral verdicts are never cache as their respective cached counterparts. Neutral verdicts are
stored and do not override existing cached verdicts. never stored and do not override existing cached verdicts.
8.3.3. Announcement of Verdicts 8.3.3. Announcement of Verdicts
A node SHOULD always announce any configured trust verdicts it has A node SHOULD always announce any configured trust verdicts it has
established by itself, and it MUST do so if announcing the configured established by itself, and it MUST do so if announcing the configured
trust verdict leads to a change in the current effective verdict for trust verdict leads to a change in the current effective trust
the respective certificate. In absence of configured verdicts, it verdict for the respective certificate. In absence of configured
MUST announce cached trust verdicts it has stored in its trust cache, verdicts, it MUST announce cached trust verdicts it has stored in its
if one of the following conditions applies: trust cache, if one of the following conditions applies:
o The stored verdict is Cached Trust and the current effective o The stored trust verdict is Cached Trust and the current effective
verdict for the certificate is Neutral or does not exist. trust verdict for the certificate is Neutral or does not exist.
o The stored verdict is Cached Distrust and the current effective o The stored trust verdict is Cached Distrust and the current
verdict for the certificate is Cached Trust. effective trust verdict for the certificate is Cached Trust.
A node rechecks these conditions whenever it detects changes of A node rechecks these conditions whenever it detects changes of
announced trust verdicts anywhere in the network. announced trust verdicts anywhere in the network.
Upon encountering a node with a hierarchy of certificates for which Upon encountering a node with a hierarchy of certificates for which
there is no effective verdict, a node adds a Neutral Trust-Verdict- there is no effective trust verdict, a node adds a Neutral Trust-
TLV to its node data for all certificates found in the hierarchy, and Verdict-TLV to its node data for all certificates found in the
publishes it until an effective verdict different from Neutral can be hierarchy, and publishes it until an effective trust verdict
found for any of the certificates, or a reasonable amount of time (10 different from Neutral can be found for any of the certificates, or a
minutes is suggested) with no reaction and no further authentication reasonable amount of time (10 minutes is suggested) with no reaction
attempts has passed. Such verdicts SHOULD also be limited in rate and no further authentication attempts has passed. Such trust
and number to prevent denial-of-service attacks. verdicts SHOULD also be limited in rate and number to prevent denial-
of-service attacks.
Trust verdicts are announced using Trust-Verdict TLVs: Trust verdicts are announced using Trust-Verdict TLVs:
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: Trust-Verdict (10) | Length: 37-100 | | Type: Trust-Verdict (10) | Length: 37-100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Verdict | (reserved) | | Verdict | (reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 21, line 34 skipping to change at page 22, line 23
| | | |
| | | |
| SHA-256 Fingerprint | | SHA-256 Fingerprint |
| | | |
| | | |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Common Name | | Common Name |
Verdict represents the numerical index of the verdict. Verdict represents the numerical index of the trust verdict.
(reserved) is reserved for future additions and MUST be set to 0 (reserved) is reserved for future additions and MUST be set to 0
when creating TLVs and ignored when parsing them. when creating TLVs and ignored when parsing them.
SHA-256 Fingerprint contains the SHA-256 [RFC6234] hash value of SHA-256 Fingerprint contains the SHA-256 [RFC6234] hash value of
the certificate in DER-format. the certificate in DER-format.
Common Name contains the variable-length (1-64 bytes) common name Common Name contains the variable-length (1-64 bytes) common name
of the certificate. Final byte MUST have value of 0. of the certificate. Final byte MUST have value of 0.
 End of changes. 71 change blocks. 
191 lines changed or deleted 213 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/