idnits 2.17.1 draft-behringer-anima-autonomic-control-plane-02.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 361: '... node MUST support this function....' RFC 2119 keyword, line 373: '...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 (March 6, 2015) is 3339 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) == 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-02 == 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-04 ** 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 (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANIMA WG M. Behringer 3 Internet-Draft S. Bjarnason 4 Intended status: Standards Track Balaji. BL 5 Expires: September 7, 2015 T. Eckert 6 Cisco 7 March 6, 2015 9 An Autonomic Control Plane 10 draft-behringer-anima-autonomic-control-plane-02 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 September 7, 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. Use Cases for an Autonomic Control Plane . . . . . . . . . . 4 58 2.1. Secure Bootstrap over an Unconfigured Network . . . . . . 4 59 2.2. Data Plane Independent Permanent Reachability . . . . . . 4 60 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4. Self-Creation of an Autonomic Control Plane . . . . . . . . . 6 62 4.1. Preconditions . . . . . . . . . . . . . . . . . . . . . . 6 63 4.2. Adjacency Discovery . . . . . . . . . . . . . . . . . . . 6 64 4.3. Authenticating Neighbors . . . . . . . . . . . . . . . . 7 65 4.4. Capability Negotiation . . . . . . . . . . . . . . . . . 8 66 4.5. Channel Establishment . . . . . . . . . . . . . . . . . . 8 67 4.6. Context Separation . . . . . . . . . . . . . . . . . . . 9 68 4.7. Addressing inside the ACP . . . . . . . . . . . . . . . . 9 69 4.8. Routing in the ACP . . . . . . . . . . . . . . . . . . . 10 70 4.9. Connecting a Controller / NMS system . . . . . . . . . . 10 71 5. Self-Healing Properties . . . . . . . . . . . . . . . . . . . 11 72 6. Self-Protection Properties . . . . . . . . . . . . . . . . . 12 73 7. The Administrator View . . . . . . . . . . . . . . . . . . . 12 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 75 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 76 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 77 11. Change log [RFC Editor: Please remove] . . . . . . . . . . . 14 78 11.1. Initial version . . . . . . . . . . . . . . . . . . . . 14 79 11.2. version 00 . . . . . . . . . . . . . . . . . . . . . . . 14 80 11.3. version 01 . . . . . . . . . . . . . . . . . . . . . . . 14 81 11.4. version 02 . . . . . . . . . . . . . . . . . . . . . . . 15 82 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 85 1. Introduction 87 Today, the management and control plane of networks typically runs in 88 the global routing table, which is dependent on correct configuration 89 and routing. Misconfigurations or routing problems can therefore 90 disrupt management and control channels. Traditionally, an out of 91 band network has been used to recover from such problems, or 92 personnel is sent on site to access devices through console ports. 93 However, both options are operationally expensive. 95 In increasingly automated networks either controllers or distributed 96 autonomic service agents in the network require a control plane which 97 is independent of the network they manage, to avoid impacting their 98 own operations. 100 This document describes a self-forming, self-managing and self- 101 protecting "Autonomic Control Plane" (ACP) which is inband on the 102 network, yet independent of configuration, addressing and routing 103 problems (for details how this achieved, see Section 4). It 104 therefore remains operational even in the presence of configuration 105 errors, addressing or routing issues, or where policy could 106 inadvertently affect control plane connectivity. The Autonomic 107 Control Plane serves several purposes at the same time: 109 o An operator can use it to log into remote devices, even if the 110 data plane is misconfigured or unconfigured. 112 o A controller or network management system can use it to securely 113 bootstrap network devices in remote locations, even if the network 114 in between is not yet configured; no data-plane dependent 115 bootstrap configuration is required. An example of such a secure 116 bootstrap process is described in 117 [I-D.pritikin-anima-bootstrapping-keyinfra] 119 o Devices can use the ACP for direct decentralised communications, 120 such as negotiations or discovery. The ACP therefore supports 121 directly Autonomic Networking functions, as described in 122 [I-D.behringer-anima-reference-model]. For example, GDNP 123 [I-D.carpenter-anima-gdn-protocol] can run inside the ACP. 125 The Autonomic Control plane relies exclusively on IPv6 for its 126 operation, and all operations in the ACP are exclusively IPv6. Since 127 the ACP is a new approach, there should be no need to support dual 128 stack IPv4/v6. The network operator can configure the network data 129 plane for any protocol, including IPv4 or IPv6. 131 This document describes how the Autonomic Control Plane is 132 constructed, and some use cases for it. The document "Autonomic 133 Network Stable Connectivity" [I-D.eckert-anima-stable-connectivity] 134 describes how the ACP can be used to provide stable connectivity for 135 OAM applications. It also explains on how existing management 136 solutions can leverage the ACP in parallel with traditional 137 management models, when to use the ACP versus the data plane, how to 138 integrate IPv4 based management, etc. 140 The ACP can support Autonomic Networking functions. For background 141 information, definitions and design goals of Autonomic Networking, 142 refer to [I-D.irtf-nmrg-autonomic-network-definitions]. For a gap 143 analysis please see [I-D.irtf-nmrg-an-gap-analysis]. 145 2. Use Cases for an Autonomic Control Plane 147 2.1. Secure Bootstrap over an Unconfigured Network 149 Today, bootstrapping a new device typically requires all devices 150 between a controlling node (such as an SDN controller) and the new 151 device to be completely and correctly addressed, configured and 152 secured. Therefore, bootstrapping a network happens in layers around 153 the controller. Without console access (for example through an out 154 of band network) it is not possible today to make devices securely 155 reachable before having configured the entire network between. 157 With the ACP, secure bootstrap of new devices can happen without 158 requiring any configuration on the network. A new device can 159 automatically be bootstrapped in a secure fashion and be deployed 160 with a domain certificate. This does not require any configuration 161 on intermediate nodes, because they can communicate through the ACP. 163 2.2. Data Plane Independent Permanent Reachability 165 Today, most critical control plane protocols and network management 166 protocols are running in the data plane (global routing table) of the 167 network. This leads to undesirable dependencies between control and 168 management plane on one side and the data plane on the other: Only if 169 the data plane is operational, will the other planes work as 170 expected. 172 Data plane connectivity can be affected by errors and faults, for 173 example certain AAA misconfigurations can lock an administrator out 174 of a device; routing or addressing issues can make a device 175 unreachable; shutting down interfaces over which a current management 176 session is running can lock an admin irreversibly out of the device. 177 Traditionally only console access can help recover from such issues. 179 Data plane dependencies also affect NOC/SDN controller applications: 180 Certain network changes are today hard to operate, because the change 181 itself may affect reachability of the devices. Examples are address 182 or mask changes, routing changes, or security policies. Today such 183 changes require precise hop-by-hop planning. 185 The ACP provides reachability that is largely independent of the data 186 plane, which allows control plane and management plane to operate 187 more robustly: 189 o For management plane protocols, the ACP provides the functionality 190 of a "Virtual-out-of-band (VooB) channel", by providing 191 connectivity to all devices regardless of their configuration or 192 global routing table. 194 o For control plane protocols, the ACP allows their operation even 195 when the data plane is temporarily faulty, or during transitional 196 events, such as routing changes, which may affect the control 197 plane at least temporarily. This is specifically important for 198 autonomic service agents, which could affect data plane 199 connectivity. 201 The document "Autonomic Network Stable Connectivity" 202 [I-D.eckert-anima-stable-connectivity] explains the use cases for the 203 ACP in significantly more detail and explains how the ACP can be used 204 in practical network operations. 206 3. Overview 208 The Autonomic Control Plane is constructed in the following way (for 209 details, see Section 4): 211 o Each autonomic node creates a virtual routing and forwarding (VRF) 212 instance, or a similar virtual context. 214 o When an autonomic node discovers another autonomic node from the 215 same domain, it authenticates that node and negotiates a secure 216 tunnel to it. These tunnels are placed into the previously set up 217 VRF. This creates an overlay network with hop-by-hop tunnels. 219 o Inside the ACP VRF, each node sets up a loopback interface with a 220 ULA IPv6 address. 222 o Each node runs a lightweight routing protocol, to announce 223 reachability of the loopback addresses inside the ACP. 225 o NMS systems or controllers have to be manually connected into the 226 ACP. 228 o None of the above operations is reflected in the configuration of 229 the device. 231 The following figure illustrates the ACP. 233 autonomic node 1 autonomic node 2 234 ................... ................... 235 secure . . secure . . secure 236 tunnel : +-----------+ : tunnel : +-----------+ : tunnel 237 ..--------| ACP VRF |---------------------| ACP VRF |---------.. 238 : / \ / \ <--routing--> / \ / \ 239 : \ / \ / \ / \ / 240 ..--------| loopback |---------------------| loopback |---------.. 241 : +-----------+ : : +-----------+ : 242 : : : : 243 : data plane :...............: data plane : 244 : : link : : 245 :.................: :.................: 247 Figure 1 249 The resulting overlay network is normally based exclusively on hop- 250 by-hop tunnels. This is because addressing used on links is IPv6 251 link local addressing, which does not require any prior set-up. This 252 way the ACP can be built even if there is no configuration on the 253 devices, or if the data plane has issues such as addressing or 254 routing problems. 256 4. Self-Creation of an Autonomic Control Plane 258 This section describes the steps to set up an Autonomic Control 259 Plane, and highlights the key properties which make it 260 "indestructible" against many inadvert changes to the data plane, for 261 example caused by misconfigurations. 263 4.1. Preconditions 265 Each autonomic device has a globally unique domain certificate, with 266 which it can cryptographically assert its membership of the domain. 267 The document [I-D.pritikin-anima-bootstrapping-keyinfra] describes 268 how a domain certificate can be automatically and securely derived 269 from a vendor specific Unique Device Identifier (UDI) or IDevID 270 certificate. (Note the UDI used in this document is NOT the UUID 271 specified in [RFC4122].) 273 4.2. Adjacency Discovery 275 Adjacency discovery exchanges identity information about neighbors, 276 either the UDI or, if present, the domain certificate (see 277 Section 4.1. This document assumes the existence of a domain 278 certificate. 280 Adjacency discovery provides a table of information of adjacent 281 neighbors. Each neighbor is identified by a globally unique device 282 identifier (UDI). 284 The adjacency table contains the following information about the 285 adjacent neighbors. 287 o Globally valid Unique device identifier (UDI). 289 o Link Local IPv6 address with its scope. 291 o Trust information: The certificate chain, if available. 293 o Validity of the trust (once validated, see next section). 295 Adjacency discovery can populate this table by several means. One 296 such mechanism is to discover using link local multicast probes, 297 which has no dependency on configured addressing and is preferable in 298 an autonomic network. 300 The "Generic Discovery and Negotiation Protocol" GDNP described in 301 [I-D.carpenter-anima-gdn-protocol] is a possible candidate protocol 302 to meet the requirements for Adjacency Discovery described here. 304 4.3. Authenticating Neighbors 306 Each neighbor in the adjacency table is authenticated. The result of 307 the authentication of the neighbor information is stored in the 308 adjacency table. We distinguish the following cases: 310 o Inside the domain: If the domain certificate presented is 311 validated (including proof of possession of the corresponding 312 private key) to be in the same domain as that of the autonomic 313 entity then the neighbor is deemed to be inside the autonomic 314 domain. Only entities inside the autonomic domain will by default 315 be able to establish the autonomic control plane. Alternatively, 316 policy can define whether to simply trust devices with the same 317 trust anchor. An ACP channel will be established. 319 o Outside the domain: If there is no domain certificate presented by 320 the neighbor, or if the domain certificate presented is invalid or 321 expired, then the neighbor is deemed to be outside the autonomic 322 domain. No ACP channel will be established. 324 Certificate management questions such as enrolment, revocation, 325 renewal, etc, are not discussed in this draft. Please refer to 326 [I-D.pritikin-anima-bootstrapping-keyinfra] for more details. 328 4.4. Capability Negotiation 330 Autonomic devices have different capabilities based on the type of 331 device and where it is deployed. To establish a trusted secure 332 communication channel, devices must be able to negotiate with each 333 neighbor a set of parameters for establishing the communication 334 channel, most notably channel type and security type. the 335 communication channel, most notably channel type and security type. 336 The channel type could be any tunnel mechanism that is feasible 337 between two adjacent neighbors, for example a GRE tunnel. The 338 security type could be any of the channel protection mechanism that 339 is available between two adjacent neighbors on a given channel type, 340 for example TLS, DTLS or IPsec. The establishment of the autonomic 341 control plane can happen after the channel type and security type is 342 negotiated. 344 The "Generic Discovery and Negotiation Protocol GDNP described in 345 [I-D.carpenter-anima-gdn-protocol] is a possible candidate protocol 346 to meet the requirements for capability negotiation described here. 348 4.5. Channel Establishment 350 After authentication and capability negotiation autonomic nodes 351 establish a secure channel towards their direct AN neighbors with the 352 above negotiated parameters. In order to be independent of 353 configured link addresses, these channels can be implemented in 354 several ways: 356 o As a secure IP tunnel (e.g., IPsec, DTLS, TLS, etc.), using IPv6 357 link local addresses between two adjacent neighbors. This way, 358 the ACP tunnels are independent of correct network wide routing. 359 They also do not require larger than link local scope addresses, 360 which would normally need to be configured or maintained. Each AN 361 node MUST support this function. 363 o L2 separation, for example via a separate 802.1q tag for ACP 364 traffic. This even further reduces dependency against the data 365 plane (not even IPv6 link-local there required), but may be harder 366 to implement. 368 Since channels are established between adjacent neighbors, the 369 resulting overlay network does hop by hop encryption. Each node 370 decrypts incoming traffic from the ACP, and encrypts outgoing traffic 371 to its neighbors in the ACP. Routing is discussed in Section 4.8. 373 If two nodes are connected via several links, the ACP SHOULD be 374 established on every link, but it is possible to establish the ACP 375 only on a sub-set of links. Having an ACP channel on every link has 376 a number of advantages, for example it allows for a faster failover 377 in case of link failure, and it reflects the physical topology more 378 closely. Using a subset of links (for example, a single link), 379 reduces resource consumption on the devices, because state needs to 380 be kept per ACP channel. 382 4.6. Context Separation 384 The ACP is in a separate context from the normal data plane of the 385 device. This context includes the ACP channels IPv6 forwarding and 386 routing as well as any required higher layer ACP functions. 388 In classical network device platforms, a dedicated so called "Virtual 389 routing and forwarding instance" (VRF) is one logical implementation 390 option for the ACP. If possible by the platform SW architecture, 391 separation options that minimize shared components are preferred. 392 The context for the ACP needs to be established automatically during 393 bootstrap of a device and - as necessitated by the implementation 394 option be protected from being modified unintential from data plane 395 configuration. 397 In addition this provides for security, because the ACP is not 398 reachable from the global routing table. Also, configuration errors 399 from the data plane setup do not affect the ACP. 401 4.7. Addressing inside the ACP 403 The channels explained above only establish communication between two 404 adjacent neighbors. In order for the communication to happen across 405 multiple hops, the autonomic control plane requires internal network 406 wide valid addresses and routing. Each autonomic node must create a 407 loopback interface with a network wide unique address inside the ACP 408 context mentioned in Section 4.6. 410 We suggest to create network wide Unique Local Addresses (ULA) in 411 accordance with [RFC4193] with the following algorithm: 413 o Prefix FC01::/8 415 o Global ID: a hash of the domain ID; this way all devices in the 416 same domain have the same /48 prefix. Conversely, global ID from 417 different domains are unlikely to clash, such that two networks 418 can be merged, as long as the policy allows that merge. See also 419 Section 5 for a discussion on merging domains. 421 o Subnet ID and interface ID: These can be either derived 422 deterministically from the name of the device, or assigned at 423 registration time of the device. 425 Links inside the ACP only use link-local IPv6 addressing, such that 426 each node only requires one routable loopback address. 428 4.8. Routing in the ACP 430 Once ULA address are set up all autonomic entities should run a 431 routing protocol within the autonomic control plane context. This 432 routing protocol distributes the ULA created in the previous section 433 for reachability. The use of the autonomic control plane specific 434 context eliminates the probable clash with the global routing table 435 and also secures the ACP from interference from the configuration 436 mismatch or incorrect routing updates. 438 The establishment of the routing plane and its parameters are 439 automatic and strictly within the confines of the autonomic control 440 plane. Therefore, no manual configuration is required. 442 All routing updates are automatically secured in transit as the 443 channels of the autonomic control plane are by default secured. 445 The routing protocol inside the ACP should be light weight and highly 446 scalable to ensure that the ACP does not become a limiting factor in 447 network scalability. We suggest the use of RPL as one such protocol 448 which is light weight and scales well for the control plane traffic. 450 4.9. Connecting a Controller / NMS system 452 The Autonomic Control Plane can be used by management systems, such 453 as controllers or network management system (NMS) hosts (henceforth 454 called simply "NMS hosts"), to connect to devices through it. For 455 this, an NMS host must have access to the ACP. By default, the ACP 456 is a self-protecting overlay network, which only allows access to 457 trusted systems. Therefore, a traditional NMS system does not have 458 access to the ACP by default, just like any other external device. 460 The preferred way for an NMS host to connect to the ACP of a network 461 is to enrol that NMS host as a domain device, such that it shares a 462 domain certificate with the same trust anchor as the network devices. 463 Then, the NMS host can automatically discover an adjacent network 464 element, and join the ACP automatically, just like a network device 465 would connect to a neighboring device. Alternatively, if there is no 466 directly connected autonomic network element, a secure connection to 467 a single remote network element can be established by configuration, 468 authenticated using the domain certificates. There, the NMS host 469 "enters" the ACP, from which point it can use the ACP to reach 470 further nodes. 472 If the NMS host does not support autonomic negotiation of the ACP, 473 then it can be brought into the ACP by configuration. On an adjacent 474 autonomic node with ACP, the interface with the NMS host can be 475 configured to be part of the ACP. In this case, the NMS host is with 476 this interface entirely and exclusively inside the ACP. It would 477 likely require a second interface for connections between the NMS 478 host and administrators, or Internet based services. This mode of 479 connecting an NMS host has security consequences: All systems and 480 processes connected to this implicitly trusted interface have access 481 to all autonomic nodes on the entire ACP, without further 482 authentication. Thus, this connection must be physically controlled. 484 In both options, the NMS host must be routed in the ACP. This 485 involves two parts: 1) the NMS host must point default to the AN 486 device for all IPv6, or for the ULA prefix used inside the ACP, and 487 2) the prefix used between AN node and NMS host must be announced 488 into the ACP, and distributed there. 490 The document "Autonomic Network Stable Connectivity" 491 [I-D.eckert-anima-stable-connectivity] explains in more detail how 492 the ACP can be integrated in a mixed NOC environment. 494 5. Self-Healing Properties 496 The ACP is self-healing: 498 o New neighbors will automatically join the ACP after successful 499 validation and will become reachable using their unique ULA 500 address across the ACP. 502 o When any changes happen in the topology, the routing protocol used 503 in the ACP will automatically adapt to the changes and will 504 continue to provide reachability to all devices. 506 o If an existing device gets revoked, it will automatically be 507 denied access to the ACP as its domain certificate will be 508 validated against a Certificate Revocation List during 509 authentication. Since the revocation check is only done at the 510 establishment of a new security association, existing ones are not 511 automatically torn down. If an immediate disconnect is required, 512 existing sessions to a freshly revoked device can be re-set. 514 The ACP can also sustain network partitions and mergers. Practically 515 all ACP operations are link local, where a network partition has no 516 impact. Devices authenticate each other using the domain 517 certificates to establish the ACP locally. Addressing inside the ACP 518 remains unchanged, and the routing protocol inside both parts of the 519 ACP will lead to two working (although partitioned) ACPs. 521 There are few central dependencies: A certificate revocation list 522 (CRL) may not be available during a network partition; a suitable 523 policy to not immediately disconnect neighbors when no CRL is 524 available can address this issue. Also, a registrar or Certificate 525 Authority might not be available during a partition. This may delay 526 renewal of certificates that are to expire in the future, and it may 527 prevent the enrolment of new devices during the partition. 529 After a network partition, a re-merge will just establish the 530 previous status, certificates can be renewed, the CRL is available, 531 and new devices can be enrolled everywhere. Since all devices use 532 the same trust anchor, a re-merge will be smooth. 534 Merging two networks with different trust anchors requires the trust 535 anchors to mutually trust each other (for example, by cross-signing). 536 As long as the domain names are different, the addressing will not 537 overlap (see Section 4.7). 539 6. Self-Protection Properties 541 As explained in Section 4, the ACP is based on channels being built 542 between devices which have been previously authenticated based on 543 their domain certificates. The channels themselves are protected 544 using standard encryption technologies like DTLS or IPsec which 545 provide additional authentication during channel establishment, data 546 integrity and data confidentiality protection of data inside the ACP 547 and in addition, provide replay protection. 549 An attacker will therefore not be able to join the ACP unless having 550 a valid domain certificate, also packet injection and sniffing 551 traffic will not be possible due to the security provided by the 552 encryption protocol. 554 The remaining attack vector would be to attack the underlying AN 555 protocols themselves, either via directed attacks or by denial-of- 556 service attacks. However, as the ACP is built using link-local IPv6 557 address, remote attacks are impossible. The ULA addresses are only 558 reachable inside the ACP context, therefore unreachable from the data 559 plane. Also, the ACP protocols should be implemented to be attack 560 resistant and not consume unnecessary resources even while under 561 attack. 563 7. The Administrator View 565 An ACP is self-forming, self-managing and self-protecting, therefore 566 has minimal dependencies on the administrator of the network. 567 Specifically, it cannot be configured, there is therefore no scope 568 for configuration errors on the ACP itself. The administrator may 569 have the option to enable or disable the entire approach, but 570 detailed configuration is not possible. This means that the ACP must 571 not be reflected in the running configuration of devices, except a 572 possible on/off switch. 574 While configuration is not possible, an administrator must have full 575 visibility of the ACP and all its parameters, to be able to do 576 trouble-shooting. Therefore, an ACP must support all show and debug 577 options, as for any other network function. Specifically, a network 578 management system or controller must be able to discover the ACP, and 579 monitor its health. This visibility of ACP operations must clearly 580 be separated from visibility of data plane so automated systems will 581 never have to deal with ACP aspect unless they explicitly desire to 582 do so. 584 Since an ACP is self-protecting, a device not supporting the ACP, or 585 without a valid domain certificate cannot connect to it. This means 586 that by default a traditional controller or network management system 587 cannot connect to an ACP. See Section 4.9 for more details on how to 588 connect an NMS host into the ACP. 590 8. Security Considerations 592 An ACP is self-protecting and there is no need to apply configuration 593 to make it secure. Its security therefore does not depend on 594 configuration. 596 However, the security of the ACP depends on a number of other 597 factors: 599 o The usage of domain certificates depends on a valid supporting PKI 600 infrastructure. If the chain of trust of this PKI infrastructure 601 is compromised, the security of the ACP is also compromised. This 602 is typically under the control of the network administrator. 604 o Security can be compromised by implementation errors (bugs), as in 605 all products. 607 Fundamentally, security depends on correct operation, implementation 608 and architecture. Autonomic approaches such as the ACP largely 609 eliminate the dependency on correct operation; implementation and 610 architectural mistakes are still possible, as in all networking 611 technologies. 613 9. IANA Considerations 615 This document requests no action by IANA. 617 10. Acknowledgements 619 This work originated from an Autonomic Networking project at Cisco 620 Systems, which started in early 2010. Many people contributed to 621 this project and the idea of the Autonomic Control Plane, amongst 622 which (in alphabetical order): Ignas Bagdonas, Parag Bhide, Alex 623 Clemm, Toerless Eckert, Yves Hertoghs, Bruno Klauser, Max Pritikin, 624 Ravi Kumar Vadapalli. 626 Further input and suggestions were received from: Rene Struik, Brian 627 Carpenter, Benoit Claise. 629 11. Change log [RFC Editor: Please remove] 631 11.1. Initial version 633 First version of this document: 634 [I-D.behringer-autonomic-control-plane] 636 11.2. version 00 638 Initial version of the anima document; only minor edits. 640 11.3. version 01 642 o Clarified that the ACP should be based on, and support only IPv6. 644 o Clarified in intro that ACP is for both, between devices, as well 645 as for access from a central entity, such as an NMS. 647 o Added a section on how to connect an NMS system. 649 o Clarified the hop-by-hop crypto nature of the ACP. 651 o Added several references to GDNP as a candidate protocol. 653 o Added a discussion on network split and merge. Although, this 654 should probably go into the certificate management story longer 655 term. 657 11.4. version 02 659 Addresses (numerous) comments from Brian Carpenter. See mailing list 660 for details. The most important changes are: 662 Introduced a new section "overview", to ease the understanding of 663 the approach. 665 Merged the previous "problem statement" and "use case" sections 666 into a mostly re-written "use cases" section, since they were 667 overlapping. 669 Clarified the relationship with draft-eckert-anima-stable- 670 connectivity 672 12. References 674 [I-D.behringer-anima-reference-model] 675 Behringer, M., Carpenter, B., and T. Eckert, "A Reference 676 Model for Autonomic Networking", draft-behringer-anima- 677 reference-model-00 (work in progress), October 2014. 679 [I-D.behringer-autonomic-control-plane] 680 Behringer, M., Bjarnason, S., BL, B., and T. Eckert, "An 681 Autonomic Control Plane", draft-behringer-autonomic- 682 control-plane-00 (work in progress), June 2014. 684 [I-D.carpenter-anima-gdn-protocol] 685 Carpenter, B. and B. Liu, "A Generic Discovery and 686 Negotiation Protocol for Autonomic Networking", draft- 687 carpenter-anima-gdn-protocol-02 (work in progress), 688 February 2015. 690 [I-D.eckert-anima-stable-connectivity] 691 Eckert, T. and M. Behringer, "Autonomic Network Stable 692 Connectivity", draft-eckert-anima-stable-connectivity-00 693 (work in progress), October 2014. 695 [I-D.irtf-nmrg-an-gap-analysis] 696 Jiang, S., Carpenter, B., and M. Behringer, "General Gap 697 Analysis for Autonomic Networking", draft-irtf-nmrg-an- 698 gap-analysis-04 (work in progress), March 2015. 700 [I-D.irtf-nmrg-autonomic-network-definitions] 701 Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 702 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 703 Networking - Definitions and Design Goals", draft-irtf- 704 nmrg-autonomic-network-definitions-05 (work in progress), 705 December 2014. 707 [I-D.pritikin-anima-bootstrapping-keyinfra] 708 Pritikin, M., Behringer, M., and S. Bjarnason, 709 "Bootstrapping Key Infrastructures", draft-pritikin-anima- 710 bootstrapping-keyinfra-01 (work in progress), February 711 2015. 713 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 714 Unique IDentifier (UUID) URN Namespace", RFC 4122, July 715 2005. 717 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 718 Addresses", RFC 4193, October 2005. 720 Authors' Addresses 722 Michael H. Behringer 723 Cisco 725 Email: mbehring@cisco.com 727 Steinthor Bjarnason 728 Cisco 730 Email: sbjarnas@cisco.com 732 Balaji BL 733 Cisco 735 Email: blbalaji@cisco.com 737 Toerless Eckert 738 Cisco 740 Email: eckert@cisco.com