idnits 2.17.1 draft-stenberg-anima-adncp-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 (March 5, 2015) is 3338 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) == Missing Reference: 'TBD1' is mentioned on line 310, but not defined == Missing Reference: 'TBD2' is mentioned on line 310, but not defined == Outdated reference: A later version (-12) exists of draft-ietf-homenet-dncp-00 ** Downref: Normative reference to an Informational RFC: RFC 6234 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-08) exists of draft-ietf-homenet-prefix-assignment-03 == Outdated reference: A later version (-07) exists of draft-irtf-nmrg-autonomic-network-definitions-05 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANIMA M. Stenberg 3 Internet-Draft 4 Intended status: Standards Track March 5, 2015 5 Expires: September 6, 2015 7 Autonomic Distributed Node Consensus Protocol 8 draft-stenberg-anima-adncp-00 10 Abstract 12 This document describes the Autonomic Distributed Node Consensus 13 Protocol (ADNCP), a profile of Distributed Node Consensus Protocol 14 (DNCP) for autonomic networking. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on September 6, 2015. 33 Copyright Notice 35 Copyright (c) 2015 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 52 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 4. DNCP Profile . . . . . . . . . . . . . . . . . . . . . . . . 3 54 5. Point-To-Point Operations . . . . . . . . . . . . . . . . . . 4 55 6. Distributed Operations . . . . . . . . . . . . . . . . . . . 5 56 6.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 5 57 6.2. Negotiation / Synchronization . . . . . . . . . . . . . . 5 58 6.3. Intent Distribution . . . . . . . . . . . . . . . . . . . 5 59 7. Area Support . . . . . . . . . . . . . . . . . . . . . . . . 6 60 7.1. Area Boundaries . . . . . . . . . . . . . . . . . . . . . 6 61 7.2. Area Identifier . . . . . . . . . . . . . . . . . . . . . 6 62 7.3. Area Formation . . . . . . . . . . . . . . . . . . . . . 6 63 7.4. Import/Export . . . . . . . . . . . . . . . . . . . . . . 8 64 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 65 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 10.1. Normative references . . . . . . . . . . . . . . . . . . 8 68 10.2. Informative references . . . . . . . . . . . . . . . . . 9 69 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . 9 70 Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . 10 71 Appendix C. Draft Source . . . . . . . . . . . . . . . . . . . . 10 72 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 10 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 75 1. Introduction 77 DNCP [I-D.ietf-homenet-dncp] provides a single-area link state 78 database for arbitrary use. ADNCP extends DNCP in several ways and 79 makes it implementable by defining a profile. 81 ADNCP allows for several types of point-to-point exchanges that match 82 typical autonomic operations. The shared state within ADNCP itself 83 is used to also facilitate some autonomic operations. Whether point- 84 to-point or multi-party algorithms are used is left up to the 85 specification of particular objectives. 87 To provide for better scalability than the base DNCP, ADNCP also 88 defines (optionally zero-configuration) multi-area system. 90 2. Requirements Language 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC 2119 [RFC2119]. 96 3. Terminology 98 Reader is assumed to be familiar with the autonomic networking 99 terminology described in 100 [I-D.irtf-nmrg-autonomic-network-definitions] and 101 [I-D.ietf-homenet-dncp]. 103 (ADNCP) area: A set of ADNCP running nodes that are directly 104 connected using a set of DNCP connections. In other words, DNCP 105 network. They share a link state database, and may also have some 106 other data from other areas but no actual topology of the other 107 areas. 109 (ADNCP) network: A set of connected ADNCP areas. 111 area owner: The ADNCP node with the highest Node Identifier within 112 the ADNCP area. 114 connection owner: Either ADNCP node with the highest Node Identifier 115 on a multicast-capable link the connection maps to, or the unicast 116 "server" node that other nodes connect. 118 per-area: Applicable to the nodes in a particular area. 120 area-wide: Distribution scope in which content is made available to 121 nodes in only one area. 123 per-net: Applies to the whole (ADNCP) network. 125 net-wide: Distribution scope in which content is made available to 126 nodes in all areas. 128 4. DNCP Profile 130 ADNCP is defined as a profile of DNCP [I-D.ietf-homenet-dncp] with 131 the following parameters: 133 o ADNCP uses UDP datagrams on port ADNCP-UDP-PORT as a multicast 134 transport over IPv6 using group All-ADNCP-Nodes-6, or IPv4 using 135 group All-ADNCP-Nodes-4. TLS [RFC5246] on port ADNCP-TCP-PORT is 136 used for unicast transport. Non-secure unicast transport MUST NOT 137 be used and therefore is not defined at all. In a typical case, 138 multicast transport SHOULD be link-local scoped, although other 139 scopes MAY be also used and supported if multicast routing is 140 available. 142 o ADNCP operates over either unicast connections, or over multicast- 143 capable interfaces. Therefore the value encoded in the DNCP 144 Connection Identifier is left up to the implementation. 146 o ADNCP nodes MUST support the X.509 PKI-based trust method, and MAY 147 support the DNCP Certificate Based Trust Consensus method. 149 o ADNCP nodes MUST use the leading 128 bits of SHA256 [RFC6234] as 150 DNCP non-cryptographic hash function H(x). 152 o ADNCP uses 128-bit node identifiers (DNCP_NODE_IDENTIFIER_LENGTH = 153 128). A node implementing ADNCP MUST generate their node 154 identifier by applying the SHA256 to their public key. If the 155 node receives a Node State TLV with the same node identifier and a 156 higher update sequence number multiple times, an error SHOULD be 157 made visible to an administrator. 159 o ADNCP nodes MUST NOT send multicast Long Network State messages, 160 and received ones MUST be ignored 162 o ADNCP nodes use the following Trickle parameters: 164 * k SHOULD be 1, given the timer reset on data updates and 165 retransmissions should handle packet loss. 167 * Imin SHOULD be 200 milliseconds but SHOULD NOT be lower. Note: 168 Earliest transmissions may occur at Imin / 2. 170 * Imax SHOULD be 7 doublings of Imin (i.e. 25.6 seconds) but 171 SHOULD NOT be lower. 173 o ADNCP nodes MUST use the keep-alive extension on all multicast 174 interface-based connections. The default keep-alive interval 175 (DNCP_KEEPALIVE_INTERVAL) is 20 seconds, the multiplier 176 (DNCP_KEEPALIVE_MULTIPLIER) MUST be 2.1, the grace-interval 177 (DNCP_GRACE_INTERVAL) SHOULD be equal to DNCP_KEEPALIVE_MULTIPLIER 178 times DNCP_KEEPALIVE_INTERVAL. 180 5. Point-To-Point Operations 182 For point-to-point operations such as discovery, negotiation, and 183 synchronization, a single new class of DNCP messages is defined (TBD 184 - more detail?). It is identified by the presence of an objective- 185 specific TLV, and if specified by the objective, it SHOULD be 186 responded to only via unicast at most. Therefore, if an ADNCP 187 implementation does not recognize a message, it MUST be silently 188 ignored. These messages SHOULD NOT in and of themselves establish a 189 DNCP-style bidirectional peering relationship between nodes, and 190 therefore SHOULD NOT contain Node Connection TLV.. 192 Such objective-specific messages should either define some 193 transaction id scheme (TBD - should it be here), or include the 194 request verbatim within the replies, if any. 196 6. Distributed Operations 198 6.1. Discovery 200 If point-to-point discovery (using either multicast-capable 201 interface(s), or known unicast peers) is not chosen, discovery can be 202 handled also either by participating in the ADNCP network, or by 203 performing point-to-point operation with a node participating in the 204 ADNCP. 206 Presence (or lack) of content with ADNCP can be used to discover 207 nodes that support particular objectives in some specific way; for 208 example, an objective might specify TLV which contains an address of 209 some particular type of server (for example, DHCPv6 PD), and 210 therefore by just using ADNCP information, "closest" node (in terms 211 of areas / in terms of routing of the address) could be determined. 213 6.2. Negotiation / Synchronization 215 ADNCP is not suitable for (especially net-wide) transmission of any 216 data that changes rapidly. Therefore it should be used to sparingly 217 publish data that changes at most gradually. 219 With that limitation in mind, ADNCP can be used to implement 220 arbitrary multi-party algorithms, such as Prefix Assignment 221 [I-D.ietf-homenet-prefix-assignment]. Given appropriate per-area 222 hierarchical assignment (published net-wide), it could be also 223 employed net-wide though, as the per-net prefix assignments would 224 change only rarely. 226 For rapidly changing data, point-to-point exchanges (as needed) 227 should be used instead and just e.g. relevant IP addresses published 228 via ADNCP. 230 6.3. Intent Distribution 232 Arbitrary (operator-supplied) objective-specific intent can be 233 supplied as TLVs within ADNCP, either per-area or per-network. 235 7. Area Support 237 Area support for DNCP is added so that non-area-capable 238 implementations can benefit from it, but cannot support more than one 239 interface (for same DNCP instance at any rate), as they cannot handle 240 the logic for transferring data between areas. 242 Areas are uniquely identified by a 32-bit Area Identifier. 244 7.1. Area Boundaries 246 A single connection always belongs to exactly one area. Therefore 247 the boundaries of the areas are within nodes that have multiple 248 connections, and can transfer data between them. 250 For every remote area detected (=on other connections, not on that 251 particular connection), a node should include a Remote Area TLV which 252 contains an Area Identifier, a Node Identifier of the area owner, and 253 pared down (recursive) list of Remote Area TLVs from that area, that 254 MUST be loop free. An exception to the rule is the current area; if 255 the current area is advertised elsewhere, it MUST be included if and 256 only if the owner's Node Identifier differs from the local one. 257 Longer paths to particular areas with matching owner Node Identifier 258 MAY be also omitted. 260 TBD: Remote Area TLV - area id, area owner (+container for more 261 Remote Area TLVs recursively) 263 7.2. Area Identifier 265 Area Identifier for every connection is chosen by the connection 266 owner. The link is owned by the node with the highest Node 267 Identifier on a connection which consists of a multicast-capable 268 link, or the "server" node which other nodes are connecting to in 269 case of an unicast link. 271 TBD: Area Identifier TLV - just area id - originated by the area 272 owner, and then included in every unicast message on link. 274 7.3. Area Formation 276 Areas by definition are connected parts of the network. An operator 277 may set explicit values for the Area Identifiers, thereby forming the 278 areas, or alternatively an automatic formation process described here 279 can be used by the connection owners. Non connection owners on a 280 particular connection should simply follow the connection owner's 281 lead. 283 If the connection owner does not have an area on a particular 284 connection yet, it may use an existing area from some other 285 connection if and only if following suitability criteria are met: 287 o The current set of links covered by that area (calculated by 288 traversing through the neighbor graph) is not more than TBD. 290 o The number of nodes in that area is not more than TBD. 292 o The area owner does not publish an Area Full TLV. 294 If nothing suitable is present, areas connected directly to other 295 nodes within the area can be also considered. For them, the 296 suitability criteria are: 298 o A node within current area exists which publishes Remote Area TLV 299 with the Area Identifier of the area. 301 o No published Area Full TLV for the area. 303 If choosing to use a particular area, the node MUST wait random 304 [TBD1, TBD2] seconds before making the actual assignment, and ensure 305 that the suitability criteria are still matched when it makes the 306 assignment. If not, this process should be repeated again, starting 307 from evaluating the candidates. 309 If no area is found at all, a new area should be created, with a 310 random delay of [TBD1, TBD2] seconds before announcing. At the end 311 of the interval, the presence of available areas to join should be 312 checked before publishing the Area Identifier TLV. 314 Once the area owner notices that the directly connected suitability 315 criteria enumerated above are no longer filled by the local area (=it 316 is too large), the area owner MUST publish an Area Full TLV. It MAY 317 be removed at later point, but if and only if the area is 318 substantially below the maximum desired size in terms of number of 319 links and number of nodes. 321 If the owner of an area detects the presence of a Remote Area TLV 322 with an Area Identifier identical to that of the area it is 323 advertising and with an owner having a higher Node Identifier than 324 itself, then the area owner MUST choose a new (random) Area 325 Identifier. 327 TBD: Area Full TLV - no content, but net-wide. 329 7.4. Import/Export 331 There is no explicit exporting of TLVs; any TLV type that has highest 332 bit set (0x8000) will be considered area-originated, and spread net- 333 wide, as opposed to the default area-wide node-originated. It is 334 important to note that currently node identifier of the originating 335 node is lost as it transitions to another area (TBD), but within the 336 area the originator is still visible. 338 Given the node is on an area boundary, for all areas it is in, it 339 must recursively traverse all Remote Area TLVs announced within the 340 area, and keep track of the shortest recursion depth at which a 341 particular area is first encountered. The Node Identifier of the 342 Remote Area TLV originator is used for tie-breaking, with the higher 343 one preferred. If encountering Remote Area TLV with the local area's 344 Area Identifier, that TLV MUST NOT be recursed into to avoid loops. 346 For any areas for which the node is identified as the importer (by 347 having shortest path of areas, or winning tie-break), the node MUST 348 import Remote Area Content TLV from the first-hop remote area 349 verbatim if there are other areas on the path. If the node is 350 directly connected to the remote area, it MUST create and maintain 351 Remote Area Content TLV which contains all TLVs marked for export. 353 When Remote Area Content TLV changes, or is no longer present in the 354 "upstream" area, it must be also updated/removed by the importer. 356 TBD: Remote Area Content TLV - area id (+container for any exported 357 TLVs from that area) 359 8. Security Considerations 361 TBD 363 9. IANA Considerations 365 TBD - TLVs values here + ADNCP-UDP-PORT, ADNCP-TCP-PORT 367 All-ADNCP-Nodes-4, All-ADNCP-Nodes-6 369 10. References 371 10.1. Normative references 373 [I-D.ietf-homenet-dncp] 374 Stenberg, M. and S. Barth, "Distributed Node Consensus 375 Protocol", draft-ietf-homenet-dncp-00 (work in progress), 376 January 2015. 378 [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 379 (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. 381 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 382 Requirement Levels", BCP 14, RFC 2119, March 1997. 384 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 385 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 387 10.2. Informative references 389 [I-D.ietf-homenet-prefix-assignment] 390 Pfister, P., Paterson, B., and J. Arkko, "Distributed 391 Prefix Assignment Algorithm", draft-ietf-homenet-prefix- 392 assignment-03 (work in progress), February 2015. 394 [I-D.irtf-nmrg-autonomic-network-definitions] 395 Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 396 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 397 Networking - Definitions and Design Goals", draft-irtf- 398 nmrg-autonomic-network-definitions-05 (work in progress), 399 December 2014. 401 Appendix A. Open Issues 403 Should hierarchical PA be defined here or not? 404 [I-D.ietf-homenet-prefix-assignment], with cross-area hierarchical 405 extension, would facilitate even very large scale PA (with 406 potentially multiple upstreams). Perhaps the current mention is 407 enough. 409 Should areas importers / area ID choice TLVs include precedence 410 value? 412 Should we include node-data signatures or not? They improve 413 security, but are not visible across areas in any case - it would 414 need per-TLV signature(!) in that case with a hefty footprint due to 415 needing to include way to identify the public key too. So I think 416 not. 418 Should some way to publish certificate id / raw public key be 419 defined? So it can be verified that e.g. node identifier is really 420 generated based on one. Perhaps.. 422 Should some sort of more granular delta transfer scheme be defined? 423 For a large network, the current scheme's TLV set published by a 424 single node can grow to substantial size. This may occur either here 425 or in DNCP. 427 Appendix B. Changelog 429 draft-stenberg-anima-adncp-00: Initial version. 431 Appendix C. Draft Source 433 As usual, this draft is available at https://github.com/fingon/ietf- 434 drafts/ in source format (with nice Makefile too). Feel free to send 435 comments and/or pull requests if and when you have changes to it! 437 Appendix D. Acknowledgements 439 Thanks to Pierre Pfister, Mark Baugher and Steven Barth for their 440 contributions to the draft. 442 Author's Address 444 Markus Stenberg 445 Helsinki 00930 446 Finland 448 Email: markus.stenberg@iki.fi