idnits 2.17.1 draft-behringer-anima-autonomic-control-plane-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 273: '... MUST support this function....' RFC 2119 keyword, line 285: '...d via several links, the ACP SHOULD be...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 20, 2015) is 3353 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) == Unused Reference: 'I-D.irtf-nmrg-an-gap-analysis' is defined on line 602, but no explicit reference was found in the text == Unused Reference: 'I-D.irtf-nmrg-autonomic-network-definitions' is defined on line 607, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-behringer-anima-reference-model-00 ** Downref: Normative reference to an Informational draft: draft-behringer-anima-reference-model (ref. 'I-D.behringer-anima-reference-model') ** Downref: Normative reference to an Informational draft: draft-behringer-autonomic-control-plane (ref. 'I-D.behringer-autonomic-control-plane') == Outdated reference: A later version (-04) exists of draft-carpenter-anima-gdn-protocol-01 == Outdated reference: A later version (-02) exists of draft-eckert-anima-stable-connectivity-00 ** Downref: Normative reference to an Informational draft: draft-eckert-anima-stable-connectivity (ref. 'I-D.eckert-anima-stable-connectivity') == Outdated reference: A later version (-06) exists of draft-irtf-nmrg-an-gap-analysis-03 ** Downref: Normative reference to an Informational draft: draft-irtf-nmrg-an-gap-analysis (ref. 'I-D.irtf-nmrg-an-gap-analysis') == Outdated reference: A later version (-07) exists of draft-irtf-nmrg-autonomic-network-definitions-05 ** Downref: Normative reference to an Informational draft: draft-irtf-nmrg-autonomic-network-definitions (ref. 'I-D.irtf-nmrg-autonomic-network-definitions') == Outdated reference: A later version (-02) exists of draft-pritikin-anima-bootstrapping-keyinfra-01 ** Downref: Normative reference to an Informational draft: draft-pritikin-anima-bootstrapping-keyinfra (ref. 'I-D.pritikin-anima-bootstrapping-keyinfra') Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANIMA M. Behringer 3 Internet-Draft S. Bjarnason 4 Intended status: Standards Track Balaji. BL 5 Expires: August 24, 2015 T. Eckert 6 Cisco 7 February 20, 2015 9 An Autonomic Control Plane 10 draft-behringer-anima-autonomic-control-plane-01 12 Abstract 14 In certain scenarios, for example when bootstrapping a network, it is 15 desirable to automatically bring up a secure, routed control plane, 16 which is independent of device configurations and global routing 17 table. This document describes an approach for a logically separated 18 "Autonomic Control Plane", which can be used as a "virtual out of 19 band channel" - a self-managing overlay network, which is independent 20 of configuration, addressing and routing on the data plane. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 24, 2015. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Self-Creation of an Autonomic Control Plane . . . . . . . . . 4 59 3.1. Preconditions . . . . . . . . . . . . . . . . . . . . . . 4 60 3.2. Adjacency Discovery . . . . . . . . . . . . . . . . . . . 4 61 3.3. Authenticating Neighbors . . . . . . . . . . . . . . . . 5 62 3.4. Capability Negotiation . . . . . . . . . . . . . . . . . 6 63 3.5. Channel Establishment . . . . . . . . . . . . . . . . . . 6 64 3.6. Context Separation . . . . . . . . . . . . . . . . . . . 7 65 3.7. Addressing in the ACP . . . . . . . . . . . . . . . . . . 7 66 3.8. Routing in the ACP . . . . . . . . . . . . . . . . . . . 8 67 3.9. Connecting a Controller / NMS system . . . . . . . . . . 8 68 4. Self-Healing Properties . . . . . . . . . . . . . . . . . . . 9 69 5. Self-Protection Properties . . . . . . . . . . . . . . . . . 10 70 6. Use Cases for the ACP . . . . . . . . . . . . . . . . . . . . 10 71 7. The Administrator View . . . . . . . . . . . . . . . . . . . 11 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 73 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 74 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 75 11. Change log [RFC Editor: Please remove] . . . . . . . . . . . 12 76 11.1. Initial version . . . . . . . . . . . . . . . . . . . . 12 77 11.2. version 00 . . . . . . . . . . . . . . . . . . . . . . . 12 78 11.3. version 01 . . . . . . . . . . . . . . . . . . . . . . . 12 79 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 82 1. Introduction 84 Today, the management and control plane of networks typically runs in 85 the global routing table, which is dependent on correct configuration 86 and routing. Misconfigurations or routing problems can therefore 87 disrupt management and control channels. Traditionally, an out of 88 band network has been used to recover from such problems, or 89 personnel is sent on site to access devices through console ports. 90 However, both options are operationally expensive. 92 In increasingly automated networks either controllers or distributed 93 autonomic service agents in the network require a control plane which 94 is independent of the network they manage, to avoid impacting their 95 own operations. 97 This document describes a self-forming, self-managing and self- 98 protecting "Autonomic Control Plane" (ACP) which is inband on the 99 network, yet independent of configuration, addressing and routing 100 problems (for details how this achieved, see Section 3). It 101 therefore remains operational even in the presence of configuration 102 errors, addressing or routing issues, or where policy could 103 inadvertently affect control plane connectivity. The Autonomic 104 Control Plane serves several purposes: 106 o An operator can use it to log into remote devices, even if the 107 data plane is misconfigured or unconfigured. 109 o A controller or network management system can use it to securely 110 bootstrap network devices in remote locations, even if the network 111 in between is not yet configured; no data-plane dependent 112 bootstrap configuration is required. An example of such a secure 113 bootstrap process is described in 114 [I-D.pritikin-anima-bootstrapping-keyinfra] 116 o Devices can use the ACP for direct decentralised communications, 117 such as negotiations or discovery. The ACP therefore supports 118 directly Autonomic Networking functions, as described in 119 [I-D.behringer-anima-reference-model]. 121 This document describes how the Autonomic Control Plane is 122 constructed, and some use cases for it. A more detailed use case 123 description on how the Autonomic Control Plane can be used to provide 124 stable connectivity for OAM applications is discussed in the document 125 "Autonomic Network Stable Connectivity" 126 [I-D.eckert-anima-stable-connectivity]. 128 The Autonomic Control plane relies exclusively on IPv6 for its 129 operation, and all operations in the ACP are exclusively IPv6. Since 130 the ACP is a new approach, there should be no need to support dual 131 stack IPv4/v6. The network operator can configure the network data 132 plane for any protocol, including IPv4 or IPv6. 134 2. Problem Statement 136 An "Autonomic Control Plane" (ACP) provides a solution to some of 137 today's operational challenges. These fall into three broad 138 categories: 140 o Bootstrapping a network while devices are not yet configured. 141 Bootstrapping a new device typically requires all devices between 142 the controller and the new device to be completely and correctly 143 addressed, configured and secured. Therefore, bootstrapping a 144 network happens in layers around the controller. Without console 145 access it is not possible today to make devices securely reachable 146 before having configured the entire network between. 148 o Maintaining reachability of network devices even in the case of 149 certain forms of misconfiguration and routing issues. For 150 example: certain AAA misconfigurations can lock an administrator 151 out of a device; routing or addressing issues can make a device 152 unreachable; shutting down interfaces over which a current 153 management session is running can lock an admin irreversibly out 154 of the device. Traditionally only console access can help recover 155 from such issues. 157 o Data plane dependencies for NOC/SDN controller applications: 158 Certain network changes are today hard to operate, because the 159 change itself may affect reachability of the devices. Examples 160 are address or mask changes, routing changes, or security 161 policies. Today such changes require precise hop-by-hop planning; 162 an ACP would simplify them. 164 3. Self-Creation of an Autonomic Control Plane 166 This section describes the steps to set up an Autonomic Control 167 Plane, and highlights the key properties which make it 168 "indestructible" against many inadvert changes to the data plane, for 169 example caused by misconfigurations. 171 3.1. Preconditions 173 Each autonomic device has a globally unique domain certificate, with 174 which it can cryptographically assert its membership of the domain. 175 The document [I-D.pritikin-anima-bootstrapping-keyinfra] describes 176 how a domain certificate can be automatically and securely derived 177 from a vendor specific Unique Device Identifier (UDI) or IDevID 178 certificate. (Note the UDI used in this document is NOT the UUID 179 specified in [RFC4122].) 181 3.2. Adjacency Discovery 183 Adjacency discovery exchanges identity information about neighbors, 184 either the UDI or, if present, the domain certificate (see 185 Section 3.1. This document assumes the existence of a domain 186 certificate. 188 Adjacency discovery provides a table of information of adjacent 189 neighbors. Each neighbor is identified by a globally unique device 190 identifier (UDI). 192 The adjacency table contains the following information about the 193 adjacent neighbors. 195 o Globally valid Unique device identifier (UDI). 197 o Link Local IPv6 address with its scope. 199 o Trust information: The certificate chain, if available. 201 o Validity of the trust (once validated, see next section). 203 Adjacency discovery can populate this table by several means. One 204 such mechanism is to discover using link local multicast probes, 205 which has no dependency on configured addressing and is preferable in 206 an autonomic network. 208 The "Generic Discovery and Negotiation Protocol" GDNP described in 209 [I-D.carpenter-anima-gdn-protocol] is a possible candidate protocol 210 to meet the requirements for Adjacency Discovery described here. 212 3.3. Authenticating Neighbors 214 Each neighbor in the adjacency table is authenticated. The result of 215 the authentication of the neighbor information is stored in the 216 adjacency table. We distinguish the following cases: 218 o Inside the domain: If the domain certificate presented is 219 validated (including proof of possession of the corresponding 220 private key) to be in the same domain as that of the autonomic 221 entity then the neighbor is deemed to be inside the autonomic 222 domain. Only entities inside the autonomic domain will by default 223 be able to establish the autonomic control plane. Alternatively, 224 policy can define whether to simply trust devices with the same 225 trust anchor. An ACP channel will be established. 227 o Outside the domain: If there is no domain certificate presented by 228 the neighbor, or if the domain certificate presented is invalid or 229 expired, then the neighbor is deemed to be outside the autonomic 230 domain. No ACP channel will be established. 232 Certificate management questions such as enrolment, revocation, 233 renewal, etc, are not discussed in this draft. Please refer to 234 [I-D.pritikin-anima-bootstrapping-keyinfra] for more details. 236 Authentication could be a function of a generic Adjacency Discovery 237 protocol, for example the "Generic Discovery and Negotiation 238 Protocol" GDNP described in [I-D.carpenter-anima-gdn-protocol]. 240 3.4. Capability Negotiation 242 Autonomic devices have different capabilities based on the type of 243 device and where it is deployed. To establish a trusted secure 244 communication channel, devices must be able to negotiate with each 245 neighbor a set of parameters for establishing the communication 246 channel, most notably channel type and security type. the 247 communication channel, most notably channel type and security type. 248 The channel type could be any tunnel mechanism that is feasible 249 between two adjacent neighbors, for example a GRE tunnel. The 250 security type could be any of the channel protection mechanism that 251 is available between two adjacent neighbors on a given channel type, 252 for example DTLS or IPsec. The establishment of the autonomic 253 control plane can happen after the channel type and security type is 254 negotiated. 256 The "Generic Discovery and Negotiation Protocol GDNP described in 257 [I-D.carpenter-anima-gdn-protocol] is a possible candidate protocol 258 to meet the requirements for capability negotiation described here. 260 3.5. Channel Establishment 262 After authentication and capability negotiation autonomic nodes 263 establish a secure channel towards their direct AN neighbors with the 264 above negotiated parameters. In order to be independent of 265 configured link addresses, these channels can be implemented in 266 several ways: 268 o As a secure IP tunnel (e.g., IPsec, DTLS, etc.), using IPv6 link 269 local addresses between two adjacent neighbors. This way, the ACP 270 tunnels are independent of correct network wide routing. They 271 also do not require larger than link local scope addresses, which 272 would normally need to be configured or maintained. Each AN node 273 MUST support this function. 275 o L2 separation, for example via a separate 802.1q tag for ACP 276 traffic. This even further reduces dependency against the data 277 plane (not even IPv6 link-local there required), but may be harder 278 to implement. 280 Since channels are established between adjacent neighbors, the 281 resulting overlay network does hop by hop encryption. Each node 282 decrypts incoming traffic from the ACP, and encrypts outgoing traffic 283 to its neighbors in the ACP. Routing is discussed in Section 3.8. 285 If two nodes are connected via several links, the ACP SHOULD be 286 established on every link, but it is possible to establish the ACP 287 only on a sub-set of links. Having an ACP channel on every link has 288 a number of advantages, for example it allows for a faster failover 289 in case of link failure, and it reflects the physical topology more 290 closely. Using a subset of links (for example, a single link), 291 reduces resource consumption on the devices, because state needs to 292 be kept per ACP channel. 294 3.6. Context Separation 296 The ACP is in a separate context from the normal data plane of the 297 device. This context includes the ACP channels IPv6 forwarding and 298 routing as well as any required higher layer ACP functions. 300 In classical network device platforms, a dedicated so called "Virtual 301 routing and forwarding instance" (VRF) is one logical implementation 302 option for the ACP. If possible by the platform SW architecture, 303 separation options that minimize shared components are preferred. 304 The context for the ACP needs to be established automatically during 305 bootstrap of a device and - as necessitated by the implementation 306 option be protected from being modified unintential from data plane 307 configuration. 309 In addition this provides for security, because the ACP is not 310 reachable from the global routing table. Also, configuration errors 311 from the data plane setup do not affect the ACP. 313 3.7. Addressing in the ACP 315 The channels explained above only establish communication between two 316 adjacent neighbors. In order for the communication to happen across 317 multiple hops, the autonomic control plane requires internal network 318 wide valid addresses and routing. Each autonomic node must create a 319 loop back interface with a network wide unique address inside the ACP 320 context mentioned in Section 3.6. 322 We suggest to create network wide Unique Local Addresses (ULA) in 323 accordance with [RFC4193] with the following algorithm: 325 o Prefix FC01::/8 327 o Global ID: a hash of the domain ID; this way all devices in the 328 same domain have the same /48 prefix. Conversely, global ID from 329 different domains are unlikely to clash, such that two networks 330 can be merged, as long as the policy allows that merge. See also 331 Section 4 for a discussion on merging domains. 333 o Subnet ID and interface ID: These can be either derived 334 deterministically from the name of the device, or assigned at 335 registration time of the device. 337 3.8. Routing in the ACP 339 Once ULA address are set up all autonomic entities should run a 340 routing protocol within the autonomic control plane context. This 341 routing protocol distributes the ULA created in the previous section 342 for reachability. The use of the autonomic control plane specific 343 context eliminates the probable clash with the global routing table 344 and also secures the ACP from interference from the configuration 345 mismatch or incorrect routing updates. 347 The establishment of the routing plane and its parameters are 348 automatic and strictly within the confines of the autonomic control 349 plane. Therefore, no manual configuration is required. 351 All routing updates are automatically secured in transit as the 352 channels of the autonomic control plane are by default secured. 354 The routing protocol inside the ACP should be light weight and highly 355 scalable to ensure that the ACP does not become a limiting factor in 356 network scalability. We suggest the use of RPL as one such protocol 357 which is light weight and scales well for the control plane traffic. 359 3.9. Connecting a Controller / NMS system 361 The Autonomic Control Plane can be used by management systems, such 362 as controllers or network management system (NMS) hosts (henceforth 363 called simply "NMS hosts"), to connect to devices through it. For 364 this, an NMS host must have access to the ACP. By default, the ACP 365 is a self-protecting overlay network, which only allows access to 366 trusted systems. Therefore, a traditional NMS system does not have 367 access to the ACP by default, just like any other external device. 369 The preferred way for an NMS host to connect to the ACP of a network 370 is to enrol that NMS host as a domain device, such that it shares a 371 domain certificate with the same trust anchor as the network devices. 372 Then, the NMS host can automatically discover an adjacent network 373 element, and join the ACP automatically, just like a network device 374 would connect to a neighboring device. Alternatively, if there is no 375 directly connected autonomic network element, a secure connection to 376 a single remote network element can be established by configuration, 377 authenticated using the domain certificates. There, the NMS host 378 "enters" the ACP, from which point it can use the ACP to reach 379 further nodes. 381 If the NMS host does not support autonomic negotiation of the ACP, 382 then it can be brought into the ACP by configuration. On an adjacent 383 autonomic node with ACP, the interface with the NMS host can be 384 configured to be part of the ACP. In this case, the NMS host is with 385 this interface entirely and exclusively inside the ACP. It would 386 likely require a second interface for connections between the NMS 387 host and administrators, or Internet based services. This mode of 388 connecting an NMS host has security consequences: All systems and 389 processes connected to this implicitly trusted interface have access 390 to all autonomic nodes on the entire ACP, without further 391 authentication. Thus, this connection must be physically controlled. 393 In both options, the NMS host must be routed in the ACP. This 394 involves two parts: 1) the NMS host must point default to the AN 395 device for all IPv6, or for the ULA prefix used inside the ACP, and 396 2) the prefix used between AN node and NMS host must be announced 397 into the ACP, and distributed there. 399 4. Self-Healing Properties 401 The ACP is self-healing: 403 o New neighbors will automatically join the ACP after successful 404 validation and will become reachable using their unique ULA 405 address across the ACP. 407 o When any changes happen in the topology, the routing protocol used 408 in the ACP will automatically adapt to the changes and will 409 continue to provide reachability to all devices. 411 o If an existing device gets revoked, it will automatically be 412 denied access to the ACP as its domain certificate will be 413 validated against a Certificate Revocation List during 414 authentication. 416 The ACP can also sustain network partitions and mergers. Practically 417 all ACP operations are link local, where a network partition has no 418 impact. Devices authenticate each other using the domain 419 certificates to establish the ACP locally. Addressing inside the ACP 420 remains unchanged, and the routing protocol inside both parts of the 421 ACP will lead to two working (although partitioned) ACPs. 423 There are few central dependencies: A certificate revocation list 424 (CRL) may not be available during a network partition; a suitable 425 policy to not immediately disconnect neighbors when no CRL is 426 available can address this issue. Also, a registrar or Certificate 427 Authority might not be available during a partition. This may delay 428 renewal of certificates that are to expire in the future, and it may 429 prevent the enrolment of new devices during the partition. 431 After a network partition, a merge will just establish the previous 432 status, certificates can be renewed, the CRL is available, and new 433 devices can be enrolled everywhere. Since all devices use the same 434 trust anchor, a merge will be smooth. 436 Merging two networks with different trust anchors requires the trust 437 anchors to mutually trust each other (for example, by cross-signing). 438 As long as the domain names are different, the addressing will not 439 overlap (see Section 3.7). 441 5. Self-Protection Properties 443 As explained in Section 3, the ACP is based on channels being built 444 between devices which have been previously authenticated based on 445 their domain certificates. The channels themselves are protected 446 using standard encryption technologies like DTLS or IPsec which 447 provide additional authentication during channel establishment, data 448 integrity and data confidentiality protection of data inside the ACP 449 and in addition, provide replay protection. 451 An attacker will therefore not be able to join the ACP unless having 452 a valid domain certificate, also packet injection and sniffing 453 traffic will not be possible due to the security provided by the 454 encryption protocol. 456 The remaining attack vector would be to attack the underlying AN 457 protocols themselves, either via directed attacks or by denial-of- 458 service attacks. However, as the ACP is built using link-local IPv6 459 address, remote attacks are impossible. The ULA addresses are only 460 reachable inside the ACP context, therefore unreachable from the data 461 plane. Also, the ACP protocols should be implemented to be attack 462 resistant and not consume unnecessary resources even while under 463 attack. 465 6. Use Cases for the ACP 467 The ACP automatically enables a number of use cases which provide 468 immediate benefits: 470 o Secure bootstrap of new devices without requiring any 471 configuration. As explained in Section 3, a new device will 472 automatically be bootstrapped in a secure fashion and be deployed 473 with a domain certificate. This will happen without any 474 configuration, allowing a new device to be shipped directly to the 475 end-user location without the need for any pre-provisioning. 477 o Virtual-out-of-band (VooB) control plane which provides 478 connectivity to all devices regardless of their configuration or 479 global routing table. This makes it possible to manage devices 480 without having to configure data plane services or to deploy a 481 separate management network. It also simplifies management 482 applications, because changes done by the applications cannot 483 affect reachability of the devices. 485 7. The Administrator View 487 An ACP is self-forming, self-managing and self-protecting, therefore 488 has minimal dependencies on the administrator of the network. 489 Specifically, it cannot be configured, there is therefore no scope 490 for configuration errors on the ACP itself. The administrator may 491 have the option to enable or disable the entire approach, but 492 detailed configuration is not possible. This means that the ACP must 493 not be reflected in the running configuration of devices, except a 494 possible on/off switch. 496 While configuration is not possible, an administrator must have full 497 visibility of the ACP and all its parameters, to be able to do 498 trouble-shooting. Therefore, an ACP must support all show and debug 499 options, as for any other network function. Specifically, a network 500 management system or controller must be able to discover the ACP, and 501 monitor its health. This visibility of ACP operations must clearly 502 be separated from visibility of data plane so automated systems will 503 never have to deal with ACP aspect unless they explicitly desire to 504 do so. 506 Since an ACP is self-protecting, a device not supporting the ACP, or 507 without a valid domain certificate cannot connect to it. This means 508 that by default a traditional controller or network management system 509 cannot connect to an ACP. See Section 3.9 for more details on how to 510 connect an NMS host into the ACP. 512 8. Security Considerations 514 An ACP is self-protecting and there is no need to apply configuration 515 to make it secure. Its security therefore does not depend on 516 configuration. 518 However, the security of the ACP depends on a number of other 519 factors: 521 o The usage of domain certificates depends on a valid supporting PKI 522 infrastructure. If the chain of trust of this PKI infrastructure 523 is compromised, the security of the ACP is also compromised. This 524 is typically under the control of the network administrator. 526 o Security can be compromised by implementation errors (bugs), as in 527 all products. 529 Fundamentally, security depends on correct operation, implementation 530 and architecture. Autonomic approaches such as the ACP largely 531 eliminate the dependency on correct operation; implementation and 532 architectural mistakes are still possible, as in all networking 533 technologies. 535 9. IANA Considerations 537 This document requests no action by IANA. 539 10. Acknowledgements 541 This work originated from an Autonomic Networking project at Cisco 542 Systems, which started in early 2010. Many people contributed to 543 this project and the idea of the Autonomic Control Plane, amongst 544 which (in alphabetical order): Ignas Bagdonas, Parag Bhide, Alex 545 Clemm, Toerless Eckert, Yves Hertoghs, Bruno Klauser, Max Pritikin, 546 Ravi Kumar Vadapalli. 548 Further input and suggestions were received from: Rene Struik, Brian 549 Carpenter, Benoit Claise. 551 11. Change log [RFC Editor: Please remove] 553 11.1. Initial version 555 First version of this document: 556 [I-D.behringer-autonomic-control-plane] 558 11.2. version 00 560 Initial version of the anima document; only minor edits. 562 11.3. version 01 564 o Clarified that the ACP should be based on, and support only IPv6. 566 o Clarified in intro that ACP is for both, between devices, as well 567 as for access from a central entity, such as an NMS. 569 o Added a section on how to connect an NMS system. 571 o Clarified the hop-by-hop crypto nature of the ACP. 573 o Added several references to GDNP as a candidate protocol. 575 o Added a discussion on network split and merge. Although, this 576 should probably go into the certificate management story longer 577 term. 579 12. References 581 [I-D.behringer-anima-reference-model] 582 Behringer, M., Carpenter, B., and T. Eckert, "A Reference 583 Model for Autonomic Networking", draft-behringer-anima- 584 reference-model-00 (work in progress), October 2014. 586 [I-D.behringer-autonomic-control-plane] 587 Behringer, M., Bjarnason, S., BL, B., and T. Eckert, "An 588 Autonomic Control Plane", draft-behringer-autonomic- 589 control-plane-00 (work in progress), June 2014. 591 [I-D.carpenter-anima-gdn-protocol] 592 Carpenter, B. and B. Liu, "A Generic Discovery and 593 Negotiation Protocol for Autonomic Networking", draft- 594 carpenter-anima-gdn-protocol-01 (work in progress), 595 January 2015. 597 [I-D.eckert-anima-stable-connectivity] 598 Eckert, T. and M. Behringer, "Autonomic Network Stable 599 Connectivity", draft-eckert-anima-stable-connectivity-00 600 (work in progress), October 2014. 602 [I-D.irtf-nmrg-an-gap-analysis] 603 Jiang, S., Carpenter, B., and M. Behringer, "Gap Analysis 604 for Autonomic Networking", draft-irtf-nmrg-an-gap- 605 analysis-03 (work in progress), December 2014. 607 [I-D.irtf-nmrg-autonomic-network-definitions] 608 Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 609 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 610 Networking - Definitions and Design Goals", draft-irtf- 611 nmrg-autonomic-network-definitions-05 (work in progress), 612 December 2014. 614 [I-D.pritikin-anima-bootstrapping-keyinfra] 615 Pritikin, M., Behringer, M., and S. Bjarnason, 616 "Bootstrapping Key Infrastructures", draft-pritikin-anima- 617 bootstrapping-keyinfra-01 (work in progress), February 618 2015. 620 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 621 Unique IDentifier (UUID) URN Namespace", RFC 4122, July 622 2005. 624 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 625 Addresses", RFC 4193, October 2005. 627 Authors' Addresses 629 Michael H. Behringer 630 Cisco 632 Email: mbehring@cisco.com 634 Steinthor Bjarnason 635 Cisco 637 Email: sbjarnas@cisco.com 639 Balaji BL 640 Cisco 642 Email: blbalaji@cisco.com 644 Toerless Eckert 645 Cisco 647 Email: eckert@cisco.com