tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7787

 
 
 

Distributed Node Consensus Protocol

Part 2 of 2, p. 22 to 41
Prev RFC Part

 


prevText      Top      ToC       Page 22 
7.  Type-Length-Value Objects

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Type               |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Value (if any) (+padding (if any))              |
   ..
   |                     (variable # of bytes)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     (optional nested TLVs)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Each TLV is encoded as:

   o  a 2-byte Type field

   o  a 2-byte Length field, which contains the length of the Value
      field in bytes; 0 means no value

   o  the value itself (if any)

   o  padding bytes with a value of zero up to the next 4-byte boundary
      if the Length is not divisible by 4

Top      Up      ToC       Page 23 
   While padding bytes MUST NOT be included in the number stored in the
   Length field of the TLV, if the TLV is enclosed within another TLV,
   then the padding is included in the enclosing TLV's Length value.

   Each TLV that does not define optional fields or variable-length
   content MAY be sent with additional sub-TLVs appended after the TLV
   to allow for extensibility.  When handling such TLV types, each node
   MUST accept received TLVs that are longer than the fixed fields
   specified for the particular type and ignore the sub-TLVs with either
   unknown types or types not supported within that particular TLV.  If
   any sub-TLVs are present, the Length field of the TLV describes the
   number of bytes from the first byte of the TLV's own Value (if any)
   to the last (padding) byte of the last sub-TLV.

   For example, type=123 (0x7b) TLV with value 'x' (120 = 0x78) is
   encoded as: 007B 0001 7800 0000.  If it were to have a sub-TLV of
   type=124 (0x7c) with value 'y', it would be encoded as 007B 000C 7800
   0000 007C 0001 7900 0000.

   In this section, the following special notation is used:

      .. = octet string concatenation operation.

      H(x) = non-cryptographic hash function specified by the DNCP
      profile.

   In addition to the TLV types defined in this document, TLV Types
   11-31 and 512-767 are unassigned and may be sequentially registered,
   starting at 11, by Standards Action [RFC5226] by extensions to DNCP
   that may be applicable in multiple DNCP profiles.

7.1.  Request TLVs

7.1.1.  Request Network State TLV

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Type: Request network state (1)|          Length: >= 0         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This TLV is used to request response with a Network State TLV
   (Section 7.2.2) and all Node State TLVs (Section 7.2.3) (without node
   data).

Top      Up      ToC       Page 24 
7.1.2.  Request Node State TLV

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type: Request node state (2)  |          Length: > 0          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Node Identifier                        |
   |                  (length fixed in DNCP profile)               |
   ...
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This TLV is used to request a Node State TLV (Section 7.2.3)
   (including node data) for the node with the matching node identifier.

7.2.  Data TLVs

7.2.1.  Node Endpoint TLV

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type: Node endpoint (3)     |          Length: > 4          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Node Identifier                        |
   |                  (length fixed in DNCP profile)               |
   ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Endpoint Identifier                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This TLV identifies both the local node's node identifier, as well as
   the particular endpoint's endpoint identifier.  Section 4.2 specifies
   when it is sent.

Top      Up      ToC       Page 25 
7.2.2.  Network State TLV

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type: Network state (4)    |          Length: > 0          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     H(sequence number of node 1 .. H(node data of node 1) ..  |
   |    .. sequence number of node N .. H(node data of node N))    |
   |                  (length fixed in DNCP profile)               |
   ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This TLV contains the current network state hash calculated by its
   sender (Section 4.1 describes the algorithm).

7.2.3.  Node State TLV

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type: Node state (5)     |          Length: > 8          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Node Identifier                        |
   |                  (length fixed in DNCP profile)               |
   ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Sequence Number                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Milliseconds Since Origination                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         H(Node Data)                          |
   |                  (length fixed in DNCP profile)               |
   ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       (optionally) Node Data (a set of nested TLVs)           |
   ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This TLV represents the local node's knowledge about the published
   state of a node in the DNCP network identified by the Node Identifier
   field in the TLV.

   Every node, including the node publishing the node data, MUST update
   the Milliseconds Since Origination whenever it sends a Node State TLV
   based on when the node estimates the data was originally published.
   This is, e.g., to ensure that any relative timestamps contained
   within the published node data can be correctly offset and

Top      Up      ToC       Page 26 
   interpreted.  Ultimately, what is provided is just an approximation,
   as transmission delays are not accounted for.

   Absent any changes, if the originating node notices that the 32-bit
   Milliseconds Since Origination value would be close to overflow
   (greater than 2^32 - 2^16), the node MUST republish its TLVs even if
   there is no change.  In other words, absent any other changes, the
   TLV set MUST be republished roughly every 48 days.

   The actual node data of the node may be included within the TLV as
   well as in the optional Node Data field.  The set of TLVs MUST be
   strictly ordered based on ascending binary content (including TLV
   type and length).  This enables, e.g., efficient state delta
   processing and no-copy indexing by TLV type by the recipient.  The
   node data content MUST be passed along exactly as it was received.
   It SHOULD be also verified on receipt that the locally calculated
   H(Node Data) matches the content of the field within the TLV, and if
   the hash differs, the TLV SHOULD be ignored.

7.3.  Data TLVs within Node State TLV

   These TLVs are published by the DNCP nodes and are therefore only
   encoded in the Node Data field of Node State TLVs.  If encountered
   outside Node State TLV, they MUST be silently ignored.

7.3.1.  Peer TLV

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Type: Peer (8)          |          Length: > 8          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Peer Node Identifier                     |
   |                  (length fixed in DNCP profile)               |
   ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Peer Endpoint Identifier                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   (Local) Endpoint Identifier                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This TLV indicates that the node in question vouches that the
   specified peer is reachable by it on the specified local endpoint.
   The presence of this TLV at least guarantees that the node publishing
   it has received traffic from the peer recently.  For guaranteed up-
   to-date bidirectional reachability, the existence of both nodes'
   matching Peer TLVs needs to be checked.

Top      Up      ToC       Page 27 
7.3.2.  Keep-Alive Interval TLV

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type: Keep-alive interval (9) |          Length: >= 8         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Endpoint Identifier                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Interval                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This TLV indicates a non-default interval being used to send keep-
   alives as specified in Section 6.1.

   Endpoint identifier is used to identify the particular (local)
   endpoint for which the interval applies on the sending node.  If 0,
   it applies for ALL endpoints for which no specific TLV exists.

   Interval specifies the interval in milliseconds at which the node
   sends keep-alives.  A value of zero means no keep-alives are sent at
   all; in that case, some lower-layer mechanism that ensures the
   presence of nodes MUST be available and used.

8.  Security and Trust Management

   If specified in the DNCP profile, either DTLS [RFC6347] or TLS
   [RFC5246] may be used to authenticate and encrypt either some (if
   specified optional in the profile) or all unicast traffic.  The
   following methods for establishing trust are defined, but it is up to
   the DNCP profile to specify which ones may, should, or must be
   supported.

8.1.  Trust Method Based on Pre-Shared Key

   A trust model based on Pre-Shared Key (PSK) is a simple security
   management mechanism that allows an administrator to deploy devices
   to an existing network by configuring them with a predefined key,
   similar to the configuration of an administrator password or Wi-Fi
   Protected Access (WPA) key.  Although limited in nature, it is useful
   to provide a user-friendly security mechanism for smaller networks.

Top      Up      ToC       Page 28 
8.2.  PKI-Based Trust Method

   A PKI-based trust model enables more advanced management capabilities
   at the cost of increased complexity and bootstrapping effort.
   However, it allows trust to be managed in a centralized manner and is
   therefore useful for larger networks with a need for an authoritative
   trust management.

8.3.  Certificate-Based Trust Consensus Method

   For some scenarios -- such as bootstrapping a mostly unmanaged
   network -- the methods described above may not provide a desirable
   trade-off between security and user experience.  This section
   includes guidance for implementing an opportunistic security
   [RFC7435] method that DNCP profiles can build upon and adapt for
   their specific requirements.

   The certificate-based consensus model is designed to be a compromise
   between trust management effort and flexibility.  It is based on
   X.509 certificates and allows each DNCP node to provide a trust
   verdict on any other certificate, and a consensus is found to
   determine whether a node using this certificate or any certificate
   signed by it is to be trusted.

   A DNCP node not using this security method MUST ignore all announced
   trust verdicts and MUST NOT announce any such verdicts by itself,
   i.e., any other normative language in this subsection does not apply
   to it.

   The current effective trust verdict for any certificate is defined as
   the one with the highest priority from all trust verdicts announced
   for said certificate at the time.

8.3.1.  Trust Verdicts

   Trust verdicts are statements of DNCP nodes about the trustworthiness
   of X.509 certificates.  There are 5 possible trust verdicts in order
   of ascending priority:

      0 (Neutral): no trust verdict exists, but the DNCP network should
      determine one.

      1 (Cached Trust): the last known effective trust verdict was
      Configured or Cached Trust.

      2 (Cached Distrust): the last known effective trust verdict was
      Configured or Cached Distrust.

Top      Up      ToC       Page 29 
      3 (Configured Trust): trustworthy based upon an external ceremony
      or configuration.

      4 (Configured Distrust): not trustworthy based upon an external
      ceremony or configuration.

   Trust verdicts are differentiated in 3 groups:

   o  Configured verdicts are used to announce explicit trust verdicts a
      node has based on any external trust bootstrap or predefined
      relations a node has formed with a given certificate.

   o  Cached verdicts are used to retain the last known trust state in
      case all nodes with configured verdicts about a given certificate
      have been disconnected or turned off.

   o  The Neutral verdict is used to announce a new node intending to
      join the network, so a final verdict for it can be found.

   The current effective trust verdict for any certificate is defined as
   the one with the highest priority within the set of trust verdicts
   announced for the certificate in the DNCP network.  A node MUST be
   trusted for participating in the DNCP network if and only if the
   current effective trust verdict for its own certificate or any one in
   its certificate hierarchy is (Cached or Configured) Trust, and none
   of the certificates in its hierarchy have an effective trust verdict
   of (Cached or Configured) Distrust.  In case a node has a configured
   verdict, which is different from the current effective trust verdict
   for a certificate, the current effective trust verdict takes
   precedence in deciding trustworthiness.  Despite that, the node still
   retains and announces its configured verdict.

8.3.2.  Trust Cache

   Each node SHOULD maintain a trust cache containing the current
   effective trust verdicts for all certificates currently announced in
   the DNCP network.  This cache is used as a backup of the last known
   state in case there is no node announcing a configured verdict for a
   known certificate.  It SHOULD be saved to a non-volatile memory at
   reasonable time intervals to survive a reboot or power outage.

   Every time a node (re)joins the network or detects the change of an
   effective trust verdict for any certificate, it will synchronize its
   cache, i.e., store new effective trust verdicts overwriting any
   previously cached verdicts.  Configured verdicts are stored in the
   cache as their respective cached counterparts.  Neutral verdicts are
   never stored and do not override existing cached verdicts.

Top      Up      ToC       Page 30 
8.3.3.  Announcement of Verdicts

   A node SHOULD always announce any configured verdicts it has
   established by itself, and it MUST do so if announcing the configured
   verdict leads to a change in the current effective trust verdict for
   the respective certificate.  In absence of configured verdicts, it
   MUST announce Cached Trust verdicts it has stored in its trust cache,
   if one of the following conditions applies:

   o  The stored trust verdict is Cached Trust, and the current
      effective trust verdict for the certificate is Neutral or does not
      exist.

   o  The stored trust verdict is Cached Distrust, and the current
      effective trust verdict for the certificate is Cached Trust.

   A node rechecks these conditions whenever it detects changes of
   announced trust verdicts anywhere in the network.

   Upon encountering a node with a hierarchy of certificates for which
   there is no effective trust verdict, a node adds a Neutral Trust-
   Verdict TLV to its node data for all certificates found in the
   hierarchy and publishes it until an effective trust verdict different
   from Neutral can be found for any of the certificates, or a
   reasonable amount of time (10 minutes is suggested) with no reaction
   and no further authentication attempts has passed.  Such trust
   verdicts SHOULD also be limited in rate and number to prevent
   denial-of-service attacks.

Top      Up      ToC       Page 31 
   Trust verdicts are announced using Trust-Verdict TLVs:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type: Trust-Verdict (10)    |        Length: > 36           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Verdict    |                 (reserved)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   |                                                               |
   |                      SHA-256 Fingerprint                      |
   |                                                               |
   |                                                               |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Common Name                          |

      Verdict represents the numerical index of the trust verdict.

      (reserved) is reserved for future additions and MUST be set to 0
      when creating TLVs and ignored when parsing them.

      SHA-256 Fingerprint contains the SHA-256 [RFC6234] hash value of
      the certificate in DER format.

      Common name contains the variable-length (1-64 bytes) common name
      of the certificate.

8.3.4.  Bootstrap Ceremonies

   The following non-exhaustive list of methods describes possible ways
   to establish trust relationships between DNCP nodes and node
   certificates.  Trust establishment is a two-way process in which the
   existing network must trust the newly added node, and the newly added
   node must trust at least one of its peer nodes.  It is therefore
   necessary that both the newly added node and an already trusted node
   perform such a ceremony to successfully introduce a node into the
   DNCP network.  In all cases, an administrator MUST be provided with
   external means to identify the node belonging to a certificate based
   on its fingerprint and a meaningful common name.

Top      Up      ToC       Page 32 
8.3.4.1.  Trust by Identification

   A node implementing certificate-based trust MUST provide an interface
   to retrieve the current set of effective trust verdicts,
   fingerprints, and names of all certificates currently known and set
   configured verdicts to be announced.  Alternatively, it MAY provide a
   companion DNCP node or application with these capabilities with which
   it has a pre-established trust relationship.

8.3.4.2.  Preconfigured Trust

   A node MAY be preconfigured to trust a certain set of node or CA
   certificates.  However, such trust relationships MUST NOT result in
   unwanted or unrelated trust for nodes not intended to be run inside
   the same network (e.g., all other devices by the same manufacturer).

8.3.4.3.  Trust on Button Press

   A node MAY provide a physical or virtual interface to put one or more
   of its internal network interfaces temporarily into a mode in which
   it trusts the certificate of the first DNCP node it can successfully
   establish a connection with.

8.3.4.4.  Trust on First Use

   A node that is not associated with any other DNCP node MAY trust the
   certificate of the first DNCP node it can successfully establish a
   connection with.  This method MUST NOT be used when the node has
   already associated with any other DNCP node.

9.  DNCP Profile-Specific Definitions

   Each DNCP profile MUST specify the following aspects:

   o  Unicast and optionally a multicast transport protocol(s) to be
      used.  If a multicast-based node and status discovery is desired,
      a datagram-based transport supporting multicast has to be
      available.

   o  How the chosen transport(s) is secured: Not at all, optionally, or
      always with the TLS scheme defined here using one or more of the
      methods, or with something else.  If the links with DNCP nodes can
      be sufficiently secured or isolated, it is possible to run DNCP in
      a secure manner without using any form of authentication or
      encryption.

Top      Up      ToC       Page 33 
   o  Transport protocols' parameters such as port numbers to be used or
      multicast addresses to be used.  Unicast, multicast, and secure
      unicast may each require different parameters, if applicable.

   o  When receiving TLVs, what sort of TLVs are ignored in addition --
      as specified in Section 4.4 -- e.g., for security reasons.  While
      the security of the node data published within the Node State TLVs
      is already ensured by the base specification (if secure unicast
      transport is used, Node State TLVs are sent only via unicast as
      multicast ones are ignored on receipt), if a profile adds TLVs
      that are sent outside the node data, a profile should indicate
      whether or not those TLVs should be ignored if they are received
      via multicast or non-secured unicast.  A DNCP profile may define
      the following DNCP TLVs to be safely ignored:

      *  Anything received over multicast, except Node Endpoint TLV
         (Section 7.2.1) and Network State TLV (Section 7.2.2).

      *  Any TLVs received over unreliable unicast or multicast at a
         rate that is that is too high; Trickle will ensure eventual
         convergence given the rate slows down at some point.

   o  How to deal with node identifier collision as described in
      Section 4.4.  Main options are either for one or both nodes to
      assign new node identifiers to themselves or to notify someone
      about a fatal error condition in the DNCP network.

   o  Imin, Imax, and k ranges to be suggested for implementations to be
      used in the Trickle algorithm.  The Trickle algorithm does not
      require these to be the same across all implementations for it to
      work, but similar orders of magnitude help implementations of a
      DNCP profile to behave more consistently and to facilitate
      estimation of lower and upper bounds for convergence behavior of
      the network.

   o  Hash function H(x) to be used, and how many bits of the output are
      actually used.  The chosen hash function is used to handle both
      hashing of node data and producing network state hash, which is a
      hash of node data hashes.  SHA-256 defined in [RFC6234] is the
      recommended default choice, but a non-cryptographic hash function
      could be used as well.  If there is a hash collision in the
      network state hash, the network will effectively be partitioned to
      partitions that believe they are up to date but are actually no
      longer converged.  The network will converge either when some node
      data anywhere in the network changes or when conflicting Node
      State TLVs get transmitted across the partition (either caused by
      "Trickle-Driven Status Updates" (Section 4.3) or as part of the
      "Processing of Received TLVs" (Section 4.4)).  If a node publishes

Top      Up      ToC       Page 34 
      node data with a hash that collides with any previously published
      node data, the update may not be (fully) propagated, and the old
      version of node data may be used instead.

   o  DNCP_NODE_IDENTIFIER_LENGTH: The fixed length of a node identifier
      (in bytes).

   o  Whether to send keep-alives, and if so, whether it is per-endpoint
      (requires multicast transport) or per-peer.  Keep-alive also has
      associated parameters:

      *  DNCP_KEEPALIVE_INTERVAL: How often keep-alives are to be sent
         by default (if enabled).

      *  DNCP_KEEPALIVE_MULTIPLIER: How many times the
         DNCP_KEEPALIVE_INTERVAL (or peer-supplied keep-alive interval
         value) node may not be heard from to be considered still valid.
         This is just a default used in absence of any other
         configuration information or particular per-endpoint
         configuration.

   o  Whether to support dense multicast-enabled link optimization
      (Section 6.2) or not.

   For some guidance on choosing transport and security options, please
   see Appendix B.

10.  Security Considerations

   DNCP-based protocols may use multicast to indicate DNCP state changes
   and for keep-alive purposes.  However, no actual published data TLVs
   will be sent across that channel.  Therefore, an attacker may only
   learn hash values of the state within DNCP and may be able to trigger
   unicast synchronization attempts between nodes on a local link this
   way.  A DNCP node MUST therefore rate limit its reactions to
   multicast packets.

   When using DNCP to bootstrap a network, PKI-based solutions may have
   issues when validating certificates due to potentially unavailable
   accurate time or due to the inability to use the network to either
   check Certificate Revocation Lists or perform online validation.

   The Certificate-based trust consensus mechanism defined in this
   document allows for a consenting revocation; however, in case of a
   compromised device, the trust cache may be poisoned before the actual
   revocation happens allowing the distrusted device to rejoin the
   network using a different identity.  Stopping such an attack might
   require physical intervention and flushing of the trust caches.

Top      Up      ToC       Page 35 
11.  IANA Considerations

   IANA has set up a registry for the (decimal 16-bit) "DNCP TLV Types"
   under "Distributed Node Consensus Protocol (DNCP)".  The registration
   procedure is Standards Action [RFC5226].  The initial contents are:

      0: Reserved

      1: Request network state

      2: Request node state

      3: Node endpoint

      4: Network state

      5: Node state

      6: Reserved for future use (was: Custom)

      7: Reserved for future use (was: Fragment count)

      8: Peer

      9: Keep-alive interval

      10: Trust-Verdict

      11-31: Unassigned

      32-511: Reserved for per-DNCP profile use

      512-767: Unassigned

      768-1023: Reserved for Private Use [RFC5226]

      1024-65535: Reserved for future use

Top      Up      ToC       Page 36 
12.  References

12.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <http://www.rfc-editor.org/info/rfc5226>.

   [RFC6206]  Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
              "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206,
              March 2011, <http://www.rfc-editor.org/info/rfc6206>.

   [RFC6234]  Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
              (SHA and SHA-based HMAC and HKDF)", RFC 6234,
              DOI 10.17487/RFC6234, May 2011,
              <http://www.rfc-editor.org/info/rfc6234>.

12.2.  Informative References

   [RFC3315]  Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
              C., and M. Carney, "Dynamic Host Configuration Protocol
              for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
              2003, <http://www.rfc-editor.org/info/rfc3315>.

   [RFC3493]  Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
              Stevens, "Basic Socket Interface Extensions for IPv6",
              RFC 3493, DOI 10.17487/RFC3493, February 2003,
              <http://www.rfc-editor.org/info/rfc3493>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,
              <http://www.rfc-editor.org/info/rfc5246>.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
              January 2012, <http://www.rfc-editor.org/info/rfc6347>.

   [RFC7435]  Dukhovni, V., "Opportunistic Security: Some Protection
              Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
              December 2014, <http://www.rfc-editor.org/info/rfc7435>.

Top      Up      ToC       Page 37 
   [RFC7596]  Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I.
              Farrer, "Lightweight 4over6: An Extension to the Dual-
              Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596,
              July 2015, <http://www.rfc-editor.org/info/rfc7596>.

Top      Up      ToC       Page 38 
Appendix A.  Alternative Modes of Operation

   Beyond what is described in the main text, the protocol allows for
   other uses.  These are provided as examples.

A.1.  Read-Only Operation

   If a node uses just a single endpoint and does not need to publish
   any TLVs, full DNCP node functionality is not required.  Such a
   limited node can acquire and maintain a view of the TLV space by
   implementing the processing logic as specified in Section 4.4.  Such
   node would not need Trickle, peer-maintenance, or even keep-alives at
   all, as the DNCP nodes' use of it would guarantee eventual receipt of
   network state hashes, and synchronization of node data, even in the
   presence of unreliable transport.

A.2.  Forwarding Operation

   If a node with a pair of endpoints does not need to publish any TLVs,
   it can detect (for example) nodes with the highest node identifier on
   each of the endpoints (if any).  Any TLVs received from one of them
   would be forwarded verbatim as unicast to the other node with the
   highest node identifier.

   Any tinkering with the TLVs would remove guarantees of this scheme
   working; however, passive monitoring would obviously be fine.  This
   type of simple forwarding cannot be chained, as it does not send
   anything proactively.

Appendix B.  DNCP Profile Additional Guidance

   This appendix explains implications of design choices made when
   specifying the DNCP profile to use particular transport or security
   options.

B.1.  Unicast Transport -- UDP or TCP?

   The node data published by a DNCP node is limited to 64 KB due to the
   16-bit size of the length field of the TLV it is published within.
   Some transport choices may decrease this limit; if using, e.g., UDP
   datagrams for unicast transport, the upper bound of the node data
   size is whatever the nodes and the underlying network can pass to
   each other as DNCP does not define its own fragmentation scheme.  A
   profile that chooses UDP has to be limited to small node data (e.g.,
   somewhat smaller than IPv6 default MTU if using IPv6) or specify a
   minimum that all nodes have to support.  Even then, if using
   non-link-local communications, there is some concern about what
   middleboxes do to fragmented packets.  Therefore, the use of stream

Top      Up      ToC       Page 39 
   transport such as TCP is probably a good idea if either
   non-link-local communication is desired or fragmentation is expected
   to cause problems.

   TCP also provides some other facilities, such as a relatively long
   built-in keep-alive, which in conjunction with connection closes
   occurring from eventual failed retransmissions may be sufficient to
   avoid the use of in-protocol keep-alive defined in Section 6.1.
   Additionally, it is reliable, so there is no need for Trickle on such
   unicast connections.

   The major downside of using TCP instead of UDP with DNCP-based
   profiles lies in the loss of control over the time at which TLVs are
   received; while unreliable UDP datagrams also have some delay, TLVs
   within reliable stream transport may be delayed significantly due to
   retransmissions.  This is not a problem if no relative time-dependent
   information is stored within the TLVs in the DNCP-based protocol; for
   such a protocol, TCP is a reasonable choice for unicast transport if
   it is available.

B.2.  (Optional) Multicast Transport

   Multicast is needed for dynamic peer discovery and to trigger unicast
   exchanges; for that, unreliable datagram transport (=typically UDP)
   is the only transport option defined within this specification,
   although DNCP-based protocols may themselves define some other
   transport or peer discovery mechanism (e.g., based on Multicast DNS
   (mDNS) or DNS).

   If multicast is used, a well-known address should be specified and
   for, e.g., IPv6, respectively, the desired address scopes.  In most
   cases, link-local and possibly site-local are useful scopes.

B.3.  (Optional) Transport Security

   In terms of provided security, DTLS and TLS are equivalent; they also
   consume a similar amount of state on the devices.  While TLS is on
   top of a stream protocol, using DTLS also requires relatively long
   session caching within the DTLS layer to avoid expensive
   reauthentication/authorization steps if and when any state within the
   DNCP network changes or per-peer keep-alive (if enabled) is sent.

   TLS implementations (at the time of writing the specification) seem
   more mature and available (as open source) than DTLS ones.  This may
   be due to a long history of use with HTTPS.

Top      Up      ToC       Page 40 
   Some libraries seem not to support multiplexing between insecure and
   secure communication on the same port, so specifying distinct ports
   for secured and unsecured communication may be beneficial.

Appendix C.  Example Profile

   This is the DNCP profile of SHSP, an experimental (and for the
   purposes of this document fictional) home automation protocol.  The
   protocol itself is used to make a key-value store published by each
   of the nodes available to all other nodes for distributed monitoring
   and control of a home infrastructure.  It defines only one additional
   TLV type: a key=value TLV that contains a single key=value assignment
   for publication.

   o  Unicast transport: IPv6 TCP on port EXAMPLE-P1 since only absolute
      timestamps are used within the key=value data and since it focuses
      primarily on Linux-based nodes that support both protocols as
      well.  Connections from and to non-link-local addresses are
      ignored to avoid exposing this protocol outside the secure links.

   o  Multicast transport: IPv6 UDP on port EXAMPLE-P2 to link-local
      scoped multicast address ff02:EXAMPLE.  At least one node per link
      in the home is assumed to facilitate node discovery without
      depending on any other infrastructure.

   o  Security: None.  It is to be used only on trusted links (WPA2-x
      wireless, physically secure wired links).

   o  Additional TLVs to be ignored: None.  No DNCP security is
      specified, and no new TLVs are defined outside of node data.

   o  Node identifier length (DNCP_NODE_IDENTIFIER_LENGTH): 32 bits that
      are randomly generated.

   o  Node identifier collision handling: Pick new random node
      identifier.

   o  Trickle parameters: Imin = 200 ms, Imax = 7, k = 1.  It means at
      least one multicast per link in 25 seconds in stable state (0.2 *
      2^7).

   o  Hash function H(x) + length: SHA-256, only 128 bits used.  It's
      relatively fast, and 128 bits should be plenty to prevent random
      conflicts (64 bits would most likely be sufficient, too).

   o  No in-protocol keep-alives (Section 6.1); TCP keep-alive is to be
      used.  In practice, TCP keep-alive is seldom encountered anyway,
      as changes in network state cause packets to be sent on the

Top      Up      ToC       Page 41 
      unicast connections, and those that fail sufficiently many
      retransmissions are dropped much before the keep-alive actually
      would fire.

   o  No support for dense multicast-enabled link optimization
      (Section 6.2); SHSP is a simple protocol for a few nodes (network
      wide, not even to mention on a single link) and therefore would
      not provide any benefit.

Acknowledgements

   Thanks to Ole Troan, Pierre Pfister, Mark Baugher, Mark Townsley,
   Juliusz Chroboczek, Jiazi Yi, Mikael Abrahamsson, Brian Carpenter,
   Thomas Clausen, DENG Hui, and Margaret Cullen for their contributions
   to the document.

   Thanks to Kaiwen Jin and Xavier Bonnetain for their related research
   work.

Authors' Addresses

   Markus Stenberg
   Independent
   Helsinki  00930
   Finland

   Email: markus.stenberg@iki.fi


   Steven Barth
   Independent
   Halle  06114
   Germany

   Email: cyrus@openwrt.org