idnits 2.17.1 draft-ietf-homenet-dncp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 5, 2015) is 3398 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Homenet Working Group M. Stenberg 3 Internet-Draft 4 Intended status: Standards Track S. Barth 5 Expires: July 9, 2015 6 January 5, 2015 8 Distributed Node Consensus Protocol 9 draft-ietf-homenet-dncp-00 11 Abstract 13 This document describes the Distributed Node Consensus Protocol 14 (DNCP), a generic state synchronization protocol which uses Trickle 15 and Merkle trees. DNCP is transport agnostic and leaves some of the 16 details to be specified in profiles, which define actual 17 implementable DNCP based protocols. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on July 9, 2015. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 55 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 5.1. Trickle-Driven Status Update Messages . . . . . . . . . . 6 59 5.2. Processing of Received Messages . . . . . . . . . . . . . 7 60 5.3. Adding and Removing Peers . . . . . . . . . . . . . . . . 8 61 5.4. Purging Unreachable Nodes . . . . . . . . . . . . . . . . 8 62 6. Keep-Alive Extension . . . . . . . . . . . . . . . . . . . . 9 63 6.1. Data Model Additions . . . . . . . . . . . . . . . . . . 9 64 6.2. Periodic Keep-Alive Messages . . . . . . . . . . . . . . 9 65 6.3. Received Message Processing Additions . . . . . . . . . . 10 66 6.4. Neighbor Removal . . . . . . . . . . . . . . . . . . . . 10 67 7. Protocol Messages . . . . . . . . . . . . . . . . . . . . . . 10 68 7.1. Short Network State Update Message . . . . . . . . . . . 11 69 7.2. Long Network State Update Message . . . . . . . . . . . . 11 70 7.3. Network State Request Message . . . . . . . . . . . . . . 11 71 7.4. Node Data Request Message . . . . . . . . . . . . . . . . 12 72 7.5. Node Data Reply Message . . . . . . . . . . . . . . . . . 12 73 8. Type-Length-Value Objects . . . . . . . . . . . . . . . . . . 12 74 8.1. Request TLVs . . . . . . . . . . . . . . . . . . . . . . 13 75 8.1.1. Request Network State TLV . . . . . . . . . . . . . . 13 76 8.1.2. Request Node Data TLV . . . . . . . . . . . . . . . . 13 77 8.2. Data TLVs . . . . . . . . . . . . . . . . . . . . . . . . 14 78 8.2.1. Node Connection TLV . . . . . . . . . . . . . . . . . 14 79 8.2.2. Network State TLV . . . . . . . . . . . . . . . . . . 14 80 8.2.3. Node State TLV . . . . . . . . . . . . . . . . . . . 14 81 8.2.4. Node Data TLV . . . . . . . . . . . . . . . . . . . . 15 82 8.2.5. Neighbor TLV (within Node Data TLV) . . . . . . . . . 16 83 8.2.6. Keep-Alive Interval TLV (within Node Data TLV) . . . 16 84 8.3. Custom TLV (within/without Node Data TLV) . . . . . . . . 17 85 9. Security and Trust Management . . . . . . . . . . . . . . . . 17 86 9.1. Pre-Shared Key Based Trust Method . . . . . . . . . . . . 17 87 9.2. PKI Based Trust Method . . . . . . . . . . . . . . . . . 17 88 9.3. Certificate Based Trust Consensus Method . . . . . . . . 18 89 9.3.1. Trust Verdicts . . . . . . . . . . . . . . . . . . . 18 90 9.3.2. Trust Cache . . . . . . . . . . . . . . . . . . . . . 19 91 9.3.3. Announcement of Verdicts . . . . . . . . . . . . . . 19 92 9.3.4. Bootstrap Ceremonies . . . . . . . . . . . . . . . . 20 93 10. DNCP Profile-Specific Definitions . . . . . . . . . . . . . . 21 94 11. Security Considerations . . . . . . . . . . . . . . . . . . . 23 95 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 96 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 97 13.1. Normative references . . . . . . . . . . . . . . . . . . 24 98 13.2. Informative references . . . . . . . . . . . . . . . . . 24 99 Appendix A. Some Outstanding Issues . . . . . . . . . . . . . . 25 100 Appendix B. Some Obvious Questions and Answers . . . . . . . . . 25 101 Appendix C. Changelog . . . . . . . . . . . . . . . . . . . . . 25 102 Appendix D. Draft Source . . . . . . . . . . . . . . . . . . . . 26 103 Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 26 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 106 1. Introduction 108 DNCP is designed to provide a way for nodes to publish data 109 consisting of an ordered set of TLV (Type-Length-Value) tuples, and 110 to receive the data published by all other reachable DNCP nodes. 112 DNCP has relatively few requirements for the underlying transport; it 113 requires some way of transmitting either unicast datagram or stream 114 data to a DNCP peer, and if used in multicast mode, a way of sending 115 multicast datagrams. If security is desired and one of the built-in 116 security methods is to be used, support for some TLS-derived 117 transport scheme, such as TLS [RFC5246] on top of TCP, or DTLS 118 [RFC6347] on top of UDP, is also required. 120 2. Requirements Language 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 3. Terminology 128 DNCP profile is a definition of a set of rules and values listed in 129 Section 10 specifying the behavior of a DNCP based protocol, such as 130 the used transport method. For readability, any DNCP profile 131 specific parameters with a profile-specific fixed value are prefixed 132 with DNCP_. 134 DNCP node is a single node which runs a protocol based on a DNCP 135 profile. 137 DNCP network is a set of DNCP nodes running the same DNCP profile 138 that can reach each other, either via learned shared connections in 139 the underlying network, or using each other's addresses learned via 140 other means. As DNCP exchanges are bidirectional, DNCP nodes 141 connected via only unidirectional links are not considered connected. 143 Node identifier is an opaque fixed-length identifier of 144 DNCP_NODE_IDENTIFIER_LENGTH bytes which uniquely identifies a DNCP 145 node within a DNCP network. 147 Link indicates a link-layer media over which directly connected nodes 148 can communicate. 150 Interface indicates a port of a node that is connected to a 151 particular link. 153 Connection denotes a locally configured use of DNCP on a DNCP node, 154 that is attached either to an interface, to a specific remote unicast 155 address to be contacted, or to a range of remote unicast addresses 156 that are allowed to contact. 158 Connection identifier is a 32-bit opaque value, which identifies a 159 particular connection of that particular DNCP node. The value 0 is 160 reserved for DNCP and sub-protocol purposes in the TLVs, and MUST NOT 161 be used to identify an actual connection. This definition is in sync 162 with [RFC3493], as the non-zero small positive integers should 163 comfortably fit within 32 bits. 165 (DNCP) peer refers to another DNCP node with which a DNCP node 166 communicates directly on a particular connection. 168 Node data is a set of TLVs published by a node in the DNCP network. 170 Node state is a set of metadata attributes for node data. It 171 includes a sequence number for versioning, a hash value for comparing 172 and a timestamp indicating the time passed since its last 173 publication. The hash function and the number of bits used are 174 defined in the DNCP profile. 176 Network state (hash) is a hash value which represents the current 177 state of the network. The hash function and the number of bits used 178 are defined in the DNCP profile. Whenever any node is added, removed 179 or changes its published node data this hash value changes as well. 180 It is calculated over the hash values of each reachable nodes' node 181 data in ascending order of the respective node identifier. 183 Effective (trust) verdict for a certificate is defined as the verdict 184 with the highest priority within the set of verdicts announced for 185 the certificate in the DNCP network. 187 4. Data Model 189 A DNCP node has: 191 o A timestamp indicating the most recent neighbor graph traversal 192 described in Section 5.4. 194 A DNCP node has for every DNCP node in the DNCP network: 196 o A node identifier, which uniquely identifies the node. 198 o The node data, an ordered set of TLV tuples published by that 199 particular node. This set of TLVs has a well-defined order based 200 on ascending binary content (including TLV type and length). This 201 facilitates linear time state delta processing. 203 o The latest update sequence number, a 32 bit number that is 204 incremented any time the TLV set is published. For comparison 205 purposes, a looping comparison should be used to avoid problems in 206 case of overflow. An example would be: a < b <=> (a - b) % 2^32 & 207 2^31 != 0. 209 o The relative time (in milliseconds) since the current TLV data set 210 with the current update sequence number was published. It is also 211 a 32 bit number on the wire. If this number is close to overflow 212 (greater than 2^32-2^16), a node MUST re-publish its TLVs even if 213 there is no change to avoid overflow of the value. In other 214 words, absent any other changes, the TLV set MUST be re-published 215 roughly every 49 days. 217 o A timestamp identifying the time it was last reachable based on 218 neighbor graph traversal described in Section 5.4. 220 Additionally, a DNCP node has a set of connections for which DNCP is 221 configured to be used. For each such connection, a node has: 223 o A connection identifier. 225 o An interface, a unicast address of a DNCP peer it should connect 226 with, or a range of addresses from which DNCP peers are allowed to 227 connect. 229 o A Trickle [RFC6206] instance with parameters I, T, and c. 231 For each DNCP peer detected on a connection, a DNCP node has: 233 o The node identifier of the DNCP peer. 235 o The connection identifier of the DNCP peer. 237 o The most recent address used by the DNCP peer (in an authenticated 238 message, if security is enabled). 240 5. Operation 242 The DNCP protocol consists of Trickle [RFC6206] driven unicast or 243 multicast status messages which indicate the current status of shared 244 TLV data, and additional unicast message exchanges which ensure DNCP 245 peer reachability and synchronize the data when necessary. 247 If DNCP is to be used on a multicast-capable interface, as opposed to 248 only point-to-point using unicast, a datagram-based transport which 249 supports multicast SHOULD be defined in the DNCP profile to be used 250 for the messages to be sent to the whole link. As this is used only 251 to identify potential new DNCP nodes, and to notify that an unicast 252 exchange should be triggered, the multicast transport does not have 253 to be particularly secure. 255 5.1. Trickle-Driven Status Update Messages 257 Each node MUST send either a Long Network State Update message 258 (Section 7.2) or a Short Network State Update message (Section 7.1) 259 every time the connection-specific Trickle algorithm [RFC6206] 260 instance indicates that an update should be sent. The destination 261 address of the message should be multicast in case of an interface 262 which is multicast-capable, or the unicast address of the remote 263 party in case of a point-to-point connection. By default, Long 264 Network State Update messages SHOULD be used, but if it is defined as 265 undesirable for some case by the DNCP profile, Short Network State 266 Update message MUST be sent instead. This may be useful to avoid 267 fragmenting packets to multicast destinations, or for security 268 reasons. 270 A Trickle state MUST be maintained separately for each connection. 271 The Trickle state for all connections is considered inconsistent and 272 reset if and only if the locally calculated network state hash 273 changes. This occurs either due to a change in the local node's own 274 node data, or due to receipt of more recent data from another node. 276 The Trickle algorithm has 3 parameters; Imin, Imax and k. Imin and 277 Imax represent the minimum and maximum values for I, which is the 278 time interval during which at least k Trickle updates must be seen on 279 a connection to prevent local state transmission. The actual 280 suggested Trickle algorithm parameters are DNCP profile specific, as 281 described in Section 10. 283 5.2. Processing of Received Messages 285 This section describes how received messages are processed. The DNCP 286 profile may specify criteria based on which received messages are 287 ignored. Any 'reply' mentioned in the steps below denotes sending of 288 the specified message via unicast to the originator of the message 289 being processed. If the reply was caused by a multicast message and 290 sent to a link with shared bandwidth it SHOULD be delayed by a random 291 timespan in [0, Imin/2]. 293 Upon receipt of: 295 Short Network State Update (Section 7.1): If the network state 296 hash within the message differs from the locally calculated 297 network state hash, the receiver MUST reply with a Network State 298 Request message (Section 7.3). 300 Long Network State Update (Section 7.2): 302 * If the network state hash within the message matches the 303 locally calculated network state hash, stop processing. 305 * Otherwise the receiver MUST identify nodes for which local 306 information is outdated (local update sequence number is lower 307 than that within the message), potentially incorrect (local 308 update sequence number matches but the hash of the node data 309 TLV differs) or missing. 311 * If any such nodes are identified, the receiver MUST reply with 312 one or more Node Data Request message(s) (Section 7.4) 313 containing Request Node Data TLV(s) (Section 8.1.2) for the 314 corresponding nodes. 316 Network State Request (Section 7.3): the receiver MUST reply with 317 a Long Network State Update (Section 7.2). 319 Node Data Request (Section 7.4): the receiver MUST reply with the 320 requested data in a Node Data Reply message (Section 7.5). 321 Optionally - if specified by the DNCP profile - multiple replies 322 MAY be sent in order to e.g. keep size of each datagram within the 323 PMTU to the destination. However these replies must be valid 324 stand-alone Node Data Reply messages, with the full state for the 325 particular nodes. 327 Node Data Reply (Section 7.5): If the message contains Node State 328 TLVs that are more recent than the local state (the received TLV 329 has a higher update sequence number, the node data TLV hash 330 differs from the local one, or local data is missing altogether), 331 and if the message also contains corresponding Node Data TLVs, the 332 receiver MUST update its locally stored state. 334 If a message containing Node State TLVs (Section 8.2.3) is received 335 with the node identifier matching the local node identifier and a 336 higher update sequence number than its current local value, or the 337 same update sequence number and a different hash, the node SHOULD re- 338 publish its own node data with an update sequence number 1000 higher 339 than the received one. This may occur normally once due to the local 340 node restarting, and not storing the most recently used update 341 sequence number. If this occurs more than once, the DNCP profile 342 should provide guidance on how to handle these situations as it 343 indicates the existence of a second active node on the network with 344 the same node identifier. 346 5.3. Adding and Removing Peers 348 When receiving a message on a connection from an unknown peer: 350 If it is a unicast message, the remote node MUST be added as a 351 peer on the connection and a Neighbor TLV (Section 8.2.5) MUST be 352 created for it. 354 If it is a multicast message, the remote node SHOULD be sent a 355 (possibly rate-limited) unicast Network State Request Message 356 (Section 7.3). 358 If keep-alives are NOT sent by the peer (either DNCP profile does not 359 specify the use of keep-alives, or the particular peer chooses not to 360 send keep-alive messages), some other means MUST be employed to 361 ensure a DNCP peer is present, and when the peer is no longer 362 present, the Neighbor TLV and the local DNCP peer state MUST be 363 removed. 365 5.4. Purging Unreachable Nodes 367 When a Neighbor TLV or a whole node is added or removed, the neighbor 368 graph SHOULD be traversed for each node following the bidirectional 369 neighbor relationships. These are identified by looking for Neighbor 370 TLVs on both nodes, that have the other node's identifier in the 371 neighbor node identifier, and local and neighbor connection 372 identifiers swapped. Each node reached should be marked currently 373 reachable. 375 DNCP nodes MUST be either purged immediately when not marked 376 reachable in a particular graph traversal, or eventually after they 377 have not been marked reachable within DNCP_GRACE_INTERVAL. During 378 the grace period, the nodes that were not marked reachable in the 379 most recent graph traversal MUST NOT be used for calculation of the 380 network state hash, be provided to any applications that need to use 381 the whole TLV graph, or be provided to remote nodes. 383 6. Keep-Alive Extension 385 The Trickle-driven messages provide a mechanism for handling of new 386 peer detection (if applicable) on a connection, as well as state 387 change notifications. Another mechanism may be needed to get rid of 388 old, no longer valid DNCP peers if the transport or lower layers do 389 not provide one. 391 If keep-alives are not specified in the DNCP profile, the rest of 392 this section MUST be ignored. 394 A DNCP profile MAY specify either per-connection or per-peer keep- 395 alive support. This document specifies only per-connection keep- 396 alive, thus if per-peer support is required either a lower layer 397 mechanism or a definition within the profile is required. 399 6.1. Data Model Additions 401 The following additions to the Data Model (Section 4) are needed to 402 support keep-alive: 404 Each node MUST have a timestamp which indicates the last time a 405 Network State TLV (Section 8.2.2) was sent for each connection, i.e. 406 on an interface or to the point-to-point peer(s). 408 Each node MUST have for each peer: 410 o Last consistent state timestamp: a timestamp which indicates the 411 last time a consistent Network State TLV (Section 8.2.2) was 412 received from the peer. When adding a new peer, it should be 413 initialized to the current time. 415 6.2. Periodic Keep-Alive Messages 417 For every connection that a keep-alive is specified for in the DNCP 418 profile, the connection-specific keep-alive interval MUST be 419 maintained. By default, it is DNCP_KEEPALIVE_INTERVAL. If there is 420 a local value that is preferred for that for any reason 421 (configuration, energy conservation, media type, ..), it should be 422 substituted instead. If non-default keep-alive interval is used on 423 any connection, a DNCP node MUST publish appropriate Keep-Alive 424 Interval TLV(s) (Section 8.2.6). 426 If no traffic containing a Network State TLV (Section 8.2.2) has been 427 sent to a particular connection within the connection-specific keep- 428 alive interval, a Long Network State Update message (Section 7.2) or 429 a Short Network State Update message (Section 7.1) MUST be sent on 430 that connection. The type of message should be chosen based on the 431 considerations in Section 5.1. When such a message is sent, a new 432 Trickle transmission time 't' in [I/2, I] MUST be randomly chosen. 434 6.3. Received Message Processing Additions 436 If the received message contains a Network State TLV (Section 8.2.2) 437 which is consistent with the locally calculated network state hash, 438 the Last consistent state timestamp for the peer MUST be updated. 440 6.4. Neighbor Removal 442 For every peer on every connection, the connection-specific keep- 443 alive interval must be calculated by looking for Keep-Alive Interval 444 TLVs (Section 8.2.6) published by the node, and if none exist, using 445 the default value of DNCP_KEEPALIVE_INTERVAL. If the peer's last 446 consistent state timestamp has not been updated for at least 447 DNCP_KEEPALIVE_MULTIPLIER times the peer's connection-specific keep- 448 alive interval, the Neighbor TLV for that peer and the local DNCP 449 peer state MUST be removed. 451 7. Protocol Messages 453 For point-to-point exchanges, DNCP can run across datagram-based or 454 reliable ordered stream-based transports. If a stream-based 455 transport is used, a 32-bit length-value in network byte order is 456 sent before each message to indicate the number of bytes the 457 following message consists of. 459 DNCP messages are encoded as a concatenated sequence of Type-Length- 460 Value objects (Section 8). In order to facilitate fast comparing of 461 local state with that in a received message update, all TLVs in every 462 encoding scope (either within the message itself, or within a 463 container TLV) MUST be placed in ascending order based on the binary 464 comparison of both TLV header and value. By design, the TLVs which 465 MUST be present have the lowest available type values, ensuring they 466 will naturally occur at the start of the Protocol Message, resembling 467 a fixed format header. 469 DNCP profiles MAY add additional TLVs to the message specified here, 470 or even define additional messages as needed. 472 7.1. Short Network State Update Message 474 The Short Network State Update Message is used to announce the 475 sender's view of the network state using multicast. 477 The following TLVs MUST be present: 479 o One Node Connection TLV (Section 8.2.1) identifying the 480 originating node and connection. 482 o One Network State TLV (Section 8.2.2) containing the network state 483 hash as calculated by the sender. 485 The Short Network Status update message MUST NOT contain any Node 486 State TLV(s) (Section 8.2.3). 488 7.2. Long Network State Update Message 490 The Long Network State Update Message is used to announce the 491 sender's view of the network state and all node states using 492 multicast or unicast. 494 The following TLVs MUST be present: 496 o One Node Connection TLV (Section 8.2.1) identifying the 497 originating node and connection. 499 o One Network State TLV (Section 8.2.2) containing the network state 500 hash as calculated by the sender. 502 o One or more Node State TLVs (Section 8.2.3) containing the node 503 state of DNCP nodes as currently known to the sender. 505 The Long Network State Update message MUST include the corresponding 506 Node State TLV (Section 8.2.3) for each Node Data TLV used to 507 calculate the network state hash. 509 7.3. Network State Request Message 511 The Network State Request message is used to request the recipient's 512 view of the network state and all node states currently known to it. 514 The following TLVs MUST be present: 516 o One Node Connection TLV (Section 8.2.1) identifying the 517 originating node and connection. 519 o One Request Network State TLV (Section 8.1.1) indicating the type 520 of request. 522 7.4. Node Data Request Message 524 The Node Data Request message is used to request the node state and 525 data of one or more DNCP nodes in the network. 527 The following TLVs MUST be present: 529 o One Node Connection TLV (Section 8.2.1) identifying the 530 originating node and connection. 532 o One or more Request Node Data TLVs (Section 8.1.2) indicating the 533 nodes for which state and data is requested. 535 7.5. Node Data Reply Message 537 The Node Data Request message is used to provide the node data of one 538 or more DNCP nodes in the network. 540 The following TLVs MUST be present: 542 o One Node Connection TLV (Section 8.2.1) identifying the 543 originating node and connection. 545 o One or more Node State TLV (Section 8.2.3) and Node Data TLV 546 (Section 8.2.4) pairs with matching node identifiers for each node 547 previously requested in a Node Data Request message (Section 7.4). 549 8. Type-Length-Value Objects 551 Each TLV is encoded as a 2 byte type field, followed by a 2 byte 552 length field (of the value, excluding header; 0 means no value) 553 followed by the value itself (if any). Both type and length fields 554 in the header as well as all integer fields inside the value - unless 555 explicitly stated otherwise - are represented in network byte order. 556 Zero padding bytes MUST be added up to the next 4 byte boundary if 557 the length is not divisible by 4. These padding bytes MUST NOT be 558 included in the length field. 560 0 1 2 3 561 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 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | Type | Length | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | Value | 566 | (variable # of bytes) | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 For example, type=123 (0x7b) TLV with value 'x' (120 = 0x78) is 570 encoded as: 007B 0001 7800 0000. 572 Notation: 574 .. = octet string concatenation operation. 576 H(x) = non-cryptographic hash function specified by DNCP profile. 578 8.1. Request TLVs 580 8.1.1. Request Network State TLV 582 0 1 2 3 583 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 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | Type: REQ-NETWORK-STATE (2) | Length: 0 | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 This TLV is used to identify a Network State Request message 589 (Section 7.3). 591 8.1.2. Request Node Data TLV 593 0 1 2 3 594 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 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | Type: REQ-NODE-DATA (3) | Length: >0 | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | Node Identifier | 599 | (length fixed in DNCP profile) | 600 ... 601 | | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 This TLV is used within a Node Data Request message (Section 7.4) to 605 request node state and node data for the node with matching node 606 identifier, if any, to be included in a subsequent Node Data Reply 607 message (Section 7.5). 609 8.2. Data TLVs 611 8.2.1. Node Connection TLV 613 0 1 2 3 614 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 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | Type: NODE-CONNECTION (1) | Length: > 4 | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | Node Identifier | 619 | (length fixed in DNCP profile) | 620 ... 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | Connection Identifier | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 This TLV identifies both the local node's node identifier, as well as 626 the particular connection identifier. It MUST be sent in all 627 messages. 629 8.2.2. Network State TLV 631 0 1 2 3 632 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 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | Type: NETWORK-STATE (10) | Length: > 0 | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | H(H(node data TLV 1) .. [...] .. H(node data TLV N)) | 637 | (length fixed in DNCP profile) | 638 ... 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 This TLV contains the current locally calculated network state hash. 642 The network state hash is derived by calculating the hash value for 643 each currently reachable node's Node Data TLV, concatenating said 644 hash values based on the ascending order of their corresponding node 645 identifiers, and hashing the resulting concatenated hash values. 647 8.2.3. Node State TLV 648 0 1 2 3 649 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 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | Type: NODE-STATE (11) | Length: > 8 | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | Node Identifier | 654 | (length fixed in DNCP profile) | 655 ... 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | Update Sequence Number | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | Milliseconds since Origination | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | H(node data TLV) | 662 | (length fixed in DNCP profile) | 663 ... 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 This TLV represents the local node's knowledge about the published 667 state of a node in the DNCP network identified by the node identifier 668 field in the TLV. 670 The whole network should have roughly same idea about the time since 671 origination of any particular published state. Therefore every node, 672 including the originating one, MUST increment the time whenever it 673 needs to send a Node State TLV for an already published Node Data 674 TLV. This age value is not included within the Node Data TLV, 675 however, as that is immutable and used to detect changes in the 676 network state. 678 8.2.4. Node Data TLV 680 0 1 2 3 681 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 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | Type: NODE-DATA (12) | Length: > 4 | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | node identifier | 686 | (length fixed in DNCP profile) | 687 ... 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | Update Sequence Number | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | Nested TLVs containing node information | 693 8.2.5. Neighbor TLV (within Node Data TLV) 695 0 1 2 3 696 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 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | Type: NEIGHBOR (13) | Length: > 8 | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | neighbor node identifier | 701 | (length fixed in DNCP profile) | 702 ... 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | Neighbor Connection Identifier | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | Local Connection Identifier | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 This TLV indicates that the node in question vouches that the 710 specified neighbor is reachable by it on the specified local 711 connection. The presence of this TLV at least guarantees that the 712 node publishing it has received traffic from the neighbor recently. 713 For guaranteed up-to-date bidirectional reachability, the existence 714 of both nodes' matching Neighbor TLVs should be checked. 716 8.2.6. Keep-Alive Interval TLV (within Node Data TLV) 718 0 1 2 3 719 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 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | Type: KEEP-ALIVE-INTERVAL (14)| Length: 8 | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | Connection Identifier | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | Interval | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 This TLV indicates a non-default interval being used to send keep- 729 alive messages specified in Section 6. 731 Connection identifier is used to identify the particular connection 732 for which the interval applies. If 0, it applies for ALL connections 733 for which no specific TLV exists. 735 Interval specifies the interval in milliseconds at which the node 736 sends keep-alives. A value of zero means no keep-alives are sent at 737 all; in that case, some lower layer mechanism that ensures presence 738 of nodes MUST be available and used. 740 8.3. Custom TLV (within/without Node Data TLV) 742 0 1 2 3 743 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 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | Type: CUSTOM-DATA (15) | Length: > 0 | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | H(URI) | 748 | (length fixed in DNCP profile) | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | Opaque Data | 752 This TLV can be used to contain anything; the URI used should be 753 under control of the author of that specification. For example: 755 V = H('http://example.com/author/json-for-dncp') .. '{"cool": "json 756 extension!"}' 758 or 760 V = H('mailto:author@example.com') .. '{"cool": "json extension!"}' 762 9. Security and Trust Management 764 If specified in the DNCP profile, either DTLS [RFC6347] or TLS 765 [RFC5246] may be used to authenticate and encrypt either some (if 766 specified optional in the profile), or all unicast traffic. The 767 following methods for establishing trust are defined, but it is up to 768 the DNCP profile to specify which ones may, should or must be 769 supported. 771 9.1. Pre-Shared Key Based Trust Method 773 A PSK-based trust model is a simple security management mechanism 774 that allows an administrator to deploy devices to an existing network 775 by configuring them with a pre-defined key, similar to the 776 configuration of an administrator password or WPA-key. Although 777 limited in nature it is useful to provide a user-friendly security 778 mechanism for smaller networks. 780 9.2. PKI Based Trust Method 782 A PKI-based trust-model enables more advanced management capabilities 783 at the cost of increased complexity and bootstrapping effort. It 784 however allows trust to be managed in a centralized manner and is 785 therefore useful for larger networks with a need for an authoritative 786 trust management. 788 9.3. Certificate Based Trust Consensus Method 790 The certificate-based consensus model is designed to be a compromise 791 between trust management effort and flexibility. It is based on 792 X.509-certificates and allows each DNCP node to provide a verdict on 793 any other certificate and a consensus is found to determine whether a 794 node using this certificate or any certificate signed by it is to be 795 trusted. 797 The current effective trust verdict for any certificate is defined as 798 the one with the highest priority from all verdicts announced for 799 said certificate at the time. 801 9.3.1. Trust Verdicts 803 Trust Verdicts are statements of DNCP nodes about the trustworthiness 804 of X.509-certificates. There are 5 possible verdicts in order of 805 ascending priority: 807 0 Neutral : no verdict exists but the DNCP network should determine 808 one. 810 1 Cached Trust : the last known effective verdict was Configured or 811 Cached Trust. 813 2 Cached Distrust : the last known effective verdict was Configured 814 or Cached Distrust. 816 3 Configured Trust : trustworthy based upon an external ceremony or 817 configuration. 819 4 Configured Distrust : not trustworthy based upon an external 820 ceremony or configuration. 822 Verdicts are differentiated in 3 groups: 824 o Configured verdicts are used to announce explicit verdicts a node 825 has based on any external trust bootstrap or predefined relation a 826 node has formed with a given certificate. 828 o Cached verdicts are used to retain the last known trust state in 829 case all nodes with configured verdicts about a given certificate 830 have been disconnected or turned off. 832 o The Neutral verdict is used to announce a new node intending to 833 join the network so a final verdict for it can be found. 835 The current effective trust verdict for any certificate is defined as 836 the one with the highest priority within the set of verdicts + 837 announced for the certificate in the DNCP network. A node MUST be 838 trusted for participating in the DNCP network if and only if the 839 current effective verdict for its own certificate or any one in its 840 certificate hierarchy is (Cached or Configured) Trust and none of the 841 certificates in its hierarchy have an effective verdict of (Cached or 842 Configured) Distrust. In case a node has a configured verdict, which 843 is different from the current effective verdict for a certificate, 844 the current effective verdict takes precedence in deciding 845 trustworthiness. Despite that, the node still retains and announces 846 its configured verdict. 848 9.3.2. Trust Cache 850 Each node SHOULD maintain a trust cache containing the current 851 effective trust verdicts for all certificates currently announced in 852 the DNCP network. This cache is used as a backup of the last known 853 state in case there is no node announcing a configured verdict for a 854 known certificate. It SHOULD be saved to a non-volatile memory at 855 reasonable time intervals to survive a reboot or power outage. 857 Every time a node (re)joins the network or detects the change of an 858 effective trust verdict for any certificate, it will synchronize its 859 cache, i.e. store new effective verdicts overwriting any previously 860 cached verdicts. Configured verdicts are stored in the cache as 861 their respective cached counterparts. Neutral verdicts are never 862 stored and do not override existing cached verdicts. 864 9.3.3. Announcement of Verdicts 866 A node SHOULD always announce any configured trust verdicts it has 867 established by itself, and it MUST do so if announcing the configured 868 trust verdict leads to a change in the current effective verdict for 869 the respective certificate. In absence of configured verdicts, it 870 MUST announce cached trust verdicts it has stored in its trust cache, 871 if one of the following conditions applies: 873 o The stored verdict is Cached Trust and the current effective 874 verdict for the certificate is Neutral or does not exist. 876 o The stored verdict is Cached Distrust and the current effective 877 verdict for the certificate is Cached Trust. 879 A node rechecks these conditions whenever it detects changes of 880 announced trust verdicts anywhere in the network. 882 Upon encountering a node with a hierarchy of certificates for which 883 there is no effective verdict, a node adds a Neutral Trust-Verdict- 884 TLV to its node data for all certificates found in the hierarchy, and 885 publishes it until an effective verdict different from Neutral can be 886 found for any of the certificates, or a reasonable amount of time (10 887 minutes is suggested) with no reaction and no further authentication 888 attempts has passed. Such verdicts SHOULD also be limited in rate 889 and number to prevent denial-of-service attacks. 891 Trust verdicts are announced using Trust-Verdict TLVs: 893 0 1 2 3 894 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 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 | Type: Trust-Verdict (16) | Length: 37-100 | 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 | Verdict | (reserved) | 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 | | 901 | | 902 | | 903 | SHA-256 Fingerprint | 904 | | 905 | | 906 | | 907 | | 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 | Common Name | 911 Verdict represents the numerical index of the verdict. 913 (reserved) is reserved for future additions and MUST be set to 0 914 when creating TLVs and ignored when parsing them. 916 SHA-256 Fingerprint contains the SHA-256 [RFC6234] hash value of 917 the certificate in DER-format. 919 Common Name contains the variable-length (1-64 bytes) common name 920 of the certificate. Final byte MUST have value of 0. 922 9.3.4. Bootstrap Ceremonies 924 The following non-exhaustive list of methods describes possible ways 925 to establish trust relationships between DNCP nodes and node 926 certificates. Trust establishment is a two-way process in which the 927 existing network must trust the newly added node and the newly added 928 node must trust at least one of its neighboring nodes. It is 929 therefore necessary that both the newly added node and an already 930 trusted node perform such a ceremony to successfully introduce a node 931 into the DNCP network. In all cases an administrator MUST be 932 provided with external means to identify the node belonging to a 933 certificate based on its fingerprint and a meaningful common name. 935 9.3.4.1. Trust by Identification 937 A node implementing certificate-based trust MUST provide an interface 938 to retrieve the current set of effective trust verdicts, fingerprints 939 and names of all certificates currently known and set configured 940 trust verdicts to be announced. Alternatively it MAY provide a 941 companion DNCP node or application with these capabilities with which 942 it has a pre-established trust relationship. 944 9.3.4.2. Preconfigured Trust 946 A node MAY be preconfigured to trust a certain set of node or CA 947 certificates. However such trust relationships MUST NOT result in 948 unwanted or unrelated trust for nodes not intended to be run inside 949 the same network (e.g. all other devices by the same manufacturer). 951 9.3.4.3. Trust on Button Press 953 A node MAY provide a physical or virtual interface to put one or more 954 of its internal network interfaces temporarily into a mode in which 955 it trusts the certificate of the first DNCP node it can successfully 956 establish a connection with. 958 9.3.4.4. Trust on First Use 960 A node which is not associated with any other DNCP node MAY trust the 961 certificate of the first DNCP node it can successfully establish a 962 connection with. This method MUST NOT be used when the node has 963 already associated with any other DNCP node. 965 10. DNCP Profile-Specific Definitions 967 Each DNCP profile MUST define following: 969 o How the messages are secured: 971 * Not at all, 973 * optionally or always with the TLS scheme defined here using one 974 or more of the methods, or 976 * with something else. 978 Given that links with DNCP nodes can be sufficiently secured or 979 isolated it is possible to run DNCP in a secure manner without 980 using any form of authentication or encryption. 982 o Unicast and optionally multicast transport protocol(s) to be used. 983 If TLS scheme within this document is to be used security, TLS or 984 DTLS support for at least the unicast transport protocol is 985 mandatory. 987 o Transport protocols' parameters such as port numbers to be used, 988 or multicast address to be used. Unicast, multicast, and secure 989 unicast may each require different parameters, if applicable. 991 o When receiving messages, what sort of messages are dropped, as 992 specified in Section 5.2. 994 o What is the criteria for sending Trickle-based Long Network State 995 Update message (Section 7.2) on an interface or to a DNCP peer. 997 o How to deal with node identifier collision as described in 998 Section 5.2. Main options are either for one or both nodes to 999 assign new node identifiers to themselves, or to notify someone 1000 about a fatal error condition in the DNCP network. 1002 o Imin, Imax and k ranges to be suggested for implementations to be 1003 used in the Trickle algorithm. The Trickle algorithm does not 1004 require these to be same across all implementations for it to 1005 work, but similar orders of magnitude helps implementations of a 1006 DNCP profile to behave more consistently and to facilitate 1007 estimation of lower and upper bounds for behavior of the network. 1009 o Hash function H(x) to be used, and how many bits of the input are 1010 actually used. The chosen hash function is used to handle both 1011 hashing of node specific data, and network state hash, which is a 1012 hash of node specific data hashes. SHA-256 defined in [RFC6234] 1013 is the recommended default choice. 1015 o DNCP_NODE_IDENTIFIER_LENGTH: The fixed length of a node identifier 1016 (in bytes). 1018 o DNCP_GRACE_INTERVAL: How long node data for unreachable nodes is 1019 kept. 1021 o Whether to send keep-alives, and if so, on an interface, using 1022 multicast, or directly using unicast to peers. Keep-alive has 1023 also associated parameters: 1025 * DNCP_KEEPALIVE_INTERVAL: How often keep-alive messages are to 1026 be sent by default (if enabled). 1028 * DNCP_KEEPALIVE_MULTIPLIER: How many times the 1029 DNCP_KEEPALIVE_INTERVAL (or peer-supplied keep-alive interval 1030 value) a node may not be heard from to be considered still 1031 valid. 1033 11. Security Considerations 1035 DNCP profiles may use multicast to indicate DNCP state changes and 1036 for keep-alive purposes. However, no actual data TLVs will be sent 1037 across that channel. Therefore an attacker may only learn hash 1038 values of the state within DNCP and may be able to trigger unicast 1039 synchronization attempts between nodes on a local link this way. A 1040 DNCP node should therefore rate-limit its reactions to multicast 1041 packets. 1043 When using DNCP to bootstrap a network, PKI based solutions may have 1044 issues when validating certificates due to potentially unavailable 1045 accurate time, or due to inability to use the network to either check 1046 Certifcate Revocation Lists or perform on-line validation. 1048 The Certificate-based trust consensus mechanism defined in this 1049 document allows for a consenting revocation, however in case of a 1050 compromised device the trust cache may be poisoned before the actual 1051 revocation happens allowing the distrusted device to rejoin the 1052 network using a different identity. Stopping such an attack might 1053 require physical intervention and flushing of the trust caches. 1055 12. IANA Considerations 1057 IANA should set up a registry for DNCP TLV types, with the following 1058 initial contents: 1060 0: Reserved (should not happen on wire) 1062 1: Node connection 1064 2: Request network state 1066 3: Request node data 1068 4-9: Reserved for DNCP profile use 1070 10: Network state 1072 11: Node state 1073 12: Node data 1075 13: Neighbor 1077 14: Keep-alive interval 1079 15: Custom 1081 16: Trust-Verdict 1083 17-31: Reserved for future DNCP versions. 1085 192-255: Reserved for per-implementation experimentation. The nodes 1086 using TLV types in this range SHOULD use e.g. Custom TLV to identify 1087 each other and therefore eliminate potential conflict caused by 1088 potential different use of same TLV numbers. 1090 For the rest of the values (32-191, 256-65535), policy of 'standards 1091 action' should be used. 1093 13. References 1095 13.1. Normative references 1097 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1098 Requirement Levels", BCP 14, RFC 2119, March 1997. 1100 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 1101 "The Trickle Algorithm", RFC 6206, March 2011. 1103 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1104 Security Version 1.2", RFC 6347, January 2012. 1106 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1107 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1109 13.2. Informative references 1111 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 1112 Stevens, "Basic Socket Interface Extensions for IPv6", RFC 1113 3493, February 2003. 1115 [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 1116 (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. 1118 Appendix A. Some Outstanding Issues 1120 Should per-peer keep-alives be specified here? They are essentially 1121 constant unicast keep-alives, as opposed to unicast OR multicast per- 1122 connection ones are. 1124 Appendix B. Some Obvious Questions and Answers 1126 Q: Should there be nested container syntax that is actually self- 1127 describing? (i.e. type flag that indicates container, no body except 1128 sub-TLVs?) 1130 A: Not for now, but perhaps valid design.. TBD. 1132 Q: Add third case for multicast - 'medium' network state, which is 1133 'long' one, but partial? 1135 A: Drops typical convergence on large networks 5->3 packets, at 1136 expense of some specification/implementation complexity. However, as 1137 anything else than short network state leaks information via 1138 multicast, it does not seem worth it as secure protocols probably 1139 want to prevent multicast sending of anything else than short network 1140 state in any case. 1142 Q: 32-bit connection id? 1144 A: Here, it would save 32 bits per neighbor if it was 16 bits (and 1145 less is not realistic). However, TLVs defined elsewhere would not 1146 seem to even gain that much on average. 32 bits is also used for 1147 ifindex in various operating systems, making for simpler 1148 implementation. 1150 Q: Why not doing (performance thing X, Y or Z)? 1152 A: This is designed mostly to be minimal (only timers Trickle ones; 1153 everything triggered by Trickle-driven messages or local state 1154 changes). However, feel free to suggest better (even more minimal) 1155 design which works. 1157 Appendix C. Changelog 1159 draft-stenberg-homenet-dncp-00: Split from pre-version of draft-ietf- 1160 homenet-hncp-03 generic parts. Changes that affect implementations: 1162 o TLVs were renumbered. 1164 o TLV length does not include header (=-4). This facilitates e.g. 1165 use of DHCPv6 option parsing libraries (same encoding), and 1166 reduces complexity (no need to handle error values of length less 1167 than 4). 1169 o Trickle is reset only when locally calculated network state hash 1170 is changes, not as remote different network state hash is seen. 1171 This prevents e.g. attacks by multicast with one multicast packet 1172 to force Trickle reset on every interface of every node on a link. 1174 o Instead of 'ping', use 'keep-alive' (optional) for dead peer 1175 detection. Different message used! 1177 Appendix D. Draft Source 1179 As usual, this draft is available at https://github.com/fingon/ietf- 1180 drafts/ in source format (with nice Makefile too). Feel free to send 1181 comments and/or pull requests if and when you have changes to it! 1183 Appendix E. Acknowledgements 1185 Thanks to Ole Troan, Pierre Pfister, Mark Baugher, Mark Townsley, 1186 Juliusz Chroboczek and Jiazi Yi for their contributions to the draft. 1188 Authors' Addresses 1190 Markus Stenberg 1191 Helsinki 00930 1192 Finland 1194 Email: markus.stenberg@iki.fi 1196 Steven Barth 1197 Halle 06114 1198 Germany 1200 Email: cyrus@openwrt.org