idnits 2.17.1 draft-behringer-autonomic-control-plane-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 : ---------------------------------------------------------------------------- ** 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 225: '... MUST support this function....' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 20, 2014) is 3592 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.irtf-nmrg-an-gap-analysis' is defined on line 428, but no explicit reference was found in the text == Unused Reference: 'I-D.irtf-nmrg-autonomic-network-definitions' is defined on line 433, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-irtf-nmrg-an-gap-analysis-00 == Outdated reference: A later version (-07) exists of draft-irtf-nmrg-autonomic-network-definitions-00 == Outdated reference: A later version (-01) exists of draft-pritikin-bootstrapping-keyinfrastructures-00 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Behringer 3 Internet-Draft S. Bjarnason 4 Intended status: Informational Balaji. BL 5 Expires: December 22, 2014 T. Eckert 6 Cisco 7 June 20, 2014 9 An Autonomic Control Plane 10 draft-behringer-autonomic-control-plane-00 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 an "Autonomic Control 18 Plane", which can be used as a "virtual out of band channel" - a 19 self-managing overlay network, which is independent of configuration, 20 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 December 22, 2014. 39 Copyright Notice 41 Copyright (c) 2014 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 . . . . . . . . . 3 59 3.1. Preconditions . . . . . . . . . . . . . . . . . . . . . . 4 60 3.2. Adjacency Discovery . . . . . . . . . . . . . . . . . . . 4 61 3.3. Authenticating Neighbors . . . . . . . . . . . . . . . . 4 62 3.4. Capability Negotiation . . . . . . . . . . . . . . . . . 5 63 3.5. Channel Establishment . . . . . . . . . . . . . . . . . . 5 64 3.6. Context Separation . . . . . . . . . . . . . . . . . . . 5 65 3.7. Addressing in the ACP . . . . . . . . . . . . . . . . . . 6 66 3.8. Routing in the ACP . . . . . . . . . . . . . . . . . . . 6 67 4. Self-Healing Properties . . . . . . . . . . . . . . . . . . . 7 68 5. Self-Protection Properties . . . . . . . . . . . . . . . . . 7 69 6. Use Cases for the ACP . . . . . . . . . . . . . . . . . . . . 8 70 7. The Administrator View . . . . . . . . . . . . . . . . . . . 8 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 73 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 74 11. Change log [RFC Editor: Please remove] . . . . . . . . . . . 9 75 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 78 1. Introduction 80 Today, the management and control plane of networks typically runs in 81 the global routing table, which is dependent on correct configuration 82 and routing. Misconfigurations or routing problems can therefore 83 disrupt management and control channels. Traditionally, an out of 84 band network has been used to recover from such problems, or 85 personnel is sent on site to access devices through console ports. 86 However, both options are operationally expensive. 88 In increasingly automated networks either controllers or autonomic 89 service agents in the network require a control plane which is 90 independent of the network they manage, to avoid impacting their own 91 operations. 93 This document describes a self-forming, self-managing and self- 94 protecting "Autonomic Control Plane" (ACP) which is inband on the 95 network, yet independent of configuration, addressing and routing 96 problems. It therefore remains operational even in the presence of 97 configuration errors, addressing or routing issues, or where policy 98 could inadvertedly affect control plane connectivity. It serves as a 99 "virtual out of band channel": An operator can use it to log into 100 remote devices in such cases. And an SDN controller can use it to 101 securely bootstrap network devices in remote locations, even if the 102 network in between is not yet configured; no data-plane dependent 103 bootstrap configuration is required. An example of such a secure 104 bootstrap process is described in 105 [I-D.pritikin-bootstrapping-keyinfrastructures] 107 2. Problem Statement 109 An "Autonomic Control Plane" (ACP) provides a solution to some of 110 today's operational challenges. These fall into three broad 111 categories: 113 o Bootstrapping a network while devices are not yet configured. 114 Bootstrapping a new device today requires all devices between the 115 controller and the new device to be completely and correctly 116 addressed, configured and secured. Therefore, bootstrapping a 117 network happens in layers around the controller. Without console 118 access it is not possible today to make devices securely reachable 119 before having configured the entire network between. 121 o Maintaining reachability of network devices even in the case of 122 certain forms of misconfiguration and routing issues. For 123 example: certain AAA misconfigurations can lock an administrator 124 out of a device; routing or addressing issues can make a device 125 unreachable; shutting down interfaces over which a current 126 management session is running can lock an admin irreversibly out 127 of the device. Traditionally only console access can help recover 128 from such issues. 130 o Data plane dependencies for NOC/SDN controller applications: 131 Certain network changes are today hard to operate, because the 132 change itself may affect reachability of the devices. Examples 133 are address or mask changes, routing changes, or security 134 policies. Today such changes require precise hop-by-hop planning; 135 an ACP would simplify them. 137 3. Self-Creation of an Autonomic Control Plane 139 This section describes the steps to set up an Autonomic Control 140 Plane, and highlights the key properties which make it 141 "indestructible" against many inadvert changes to the data plane, for 142 example caused by misconfigurations. 144 3.1. Preconditions 146 Each autonomic device has a globally unique domain certificate, with 147 which it can cryptographically assert its membership of the domain. 148 The document [I-D.pritikin-bootstrapping-keyinfrastructures] 149 describes how a domain certificate can be automatically and securely 150 derived from a vendor specific Unique Device Identifier (UDI) or 151 IDevID certificate. 153 3.2. Adjacency Discovery 155 Adjacency discovery exchanges identity information about neighbors, 156 either the UDI or, if present, the domain certificate (see 157 Section 3.1. This document assumes the existance of a domain 158 certificate. 160 Adjacency discovery provides a table of information of adjacent 161 neighbours. Each neighbour is identified by an globally unique 162 device identifier (UDI). 164 The adjacency table contains the following information about the 165 adjacent neighbours. 167 o Globally valid Unique devide identifier (UDI) 169 o Link Local IPv6 address 171 o Trust information 173 o Validity of the trust 175 Adjacency discovery can populate this table by several means. One 176 such mechanism is to discover using link local multicast probes, 177 which has no dependency on configured addressing and is preferable in 178 an autonomic network. 180 3.3. Authenticating Neighbors 182 Each neighbour in the adjacency table is authenticated. The result 183 of the authentication of the neighbour information is stored in the 184 adjacency table. We distinguish the following cases: 186 o Inside the domain: If the domain certificate presented is 187 validated to be in the same domain as that of the autonomic entity 188 then the neighbour is deemed to be inside the autonomic domain. 189 Only entities inside the autonomic domain will by default be able 190 to establish the autonomic control plane. An ACP channel will be 191 established. 193 o Outside the domain: If there is no domain certificate presented by 194 the neighbour, or if the domain certificate presented is invalid 195 or expired, then the neighbour is deemed to be outside the 196 autonomic domain. No ACP channel will be established. 198 3.4. Capability Negotiation 200 Autonomic devices have different capabilities based on the type of 201 device and where it is deployed. To establish a trusted secure 202 communication channel, devices must be able to negotiate with each 203 neighbour a set of parameters for establishing the communication 204 channel, most notably channel type and security type. The channel 205 type could be any tunnel mechanism that is feasible between two 206 adjacent neighbours, for example a GRE tunnel. The security type 207 could be any of the channel protection mechanism that is available 208 between two adjacent neighbours on a given channel type, for example 209 IPSEC. The establishment of the autonomic control plane can happen 210 after the channel type and security type is negotiated. 212 3.5. Channel Establishment 214 After authentication and capability negotiation autonomic nodes 215 establish a secure channel towards their direct AN neighbours with 216 the above negotiated parameters. In order to be independent of 217 configured link addresses, these channels can be implemented in 218 several ways: 220 o As a secure IP tunnel (e.g., IPsec), using IPv6 link local 221 addresses between two adjacent neighbours. This way, the ACP 222 tunnels are independent of correct network wide routing. They 223 also do not require larger than link local scope addresses, which 224 would normally need to be configured or maintained. Each AN node 225 MUST support this function. 227 o L2 separation, for example via a separate 802.1q tag for ACP 228 traffic. This even further reduces dependency against the data 229 plane (not even IPv6 link-local there required), but may be harder 230 to implement. 232 3.6. Context Separation 234 The ACP is in a separate context from the normal data plane of the 235 device. This context includes the ACP channels IPv6 forwarding and 236 routing as well as any required higher layer ACP functions. 238 In classical network device platforms, a dedicated so called "Virtual 239 routing and forwarding instance" (VRF) is one logical implementation 240 option for the ACP. If possible by the platform SW architecture, 241 separation options that minimize shared components are preferred. 242 The context for the ACP needs to be established automatically during 243 bootstrap of a device and - as necessitated by the implementation 244 option be protected from being modified unintential from data plane 245 configuration. 247 In addition this provides for security, because the ACP is not 248 reachable from the global routing table. Also, configuration errors 249 from the data plane setup do not affect the ACP. 251 3.7. Addressing in the ACP 253 The channels explained above only establish communication between two 254 adjacent neighbours. In order for the communication to happen across 255 multiple hops, the autonomic control plane requires internal network 256 wide valid addresses and routing. Each autonomic node must create a 257 loop back interface with a network wide unique address inside the ACP 258 context mentioned in Section 3.6. 260 We suggest to create network wide Unique Local Addresses (ULA) in 261 accordance with [RFC4193] with the following algorithm: 263 o Prefix FC01::/8 265 o Global ID: a hash of the domain ID; this way all devices in the 266 same domain have the same /48 prefix. 268 o Subnet ID and interface ID: These can be either derived 269 deterministically from the name of the device, or assigned at 270 registration time of the device. 272 3.8. Routing in the ACP 274 Once ULA address are set up all autonomic entities should run a 275 routing protocol within the autonomic control plane context. This 276 routing protocol distributes the ULA created in the previous section 277 for reachability. The use of the autonomic control plane specific 278 context eliminates the probable clash with the global routing table 279 and also secures the ACP from interference from the configuration 280 mismatch or incorrect routing updates. 282 The establishment of the routing plane and its parameters are 283 automatic and strictly within the confines of the autonomic control 284 plane. Therefore, no manual configuration is required. 286 All routing updates are automatically secured in transit as the 287 channels of the autonomic control plane are by default secured. 289 The routing protocol inside the ACP should be light weight and highly 290 scalable to ensure that the ACP does not become a limiting factor in 291 network scalability. We suggest the use of RPL as one such protocol 292 which is light weight and scales well for the control plane traffic. 294 4. Self-Healing Properties 296 The ACP is self-healing: 298 o New neighbors will automatically join the ACP after successful 299 validation and will become reachable using their unique ULA 300 address across the ACP. 302 o When any changes happen in the topology, the routing protocol used 303 in the ACP will automatically adapt to the changes and will 304 continue to provide reachability to all devices. 306 o If an existing device gets revoked, it will automatically be 307 denied access to the ACP as its domain certificate will be 308 validated against a Certificate Revocation List during 309 authentication. 311 5. Self-Protection Properties 313 As explained in Section 3, the ACP is based on channels being built 314 between devices which have been previously been authenticated based 315 on their domain certificates. The channels themselves are protected 316 using standard encryption technologies like IPsec which provide 317 additional authentication during channel establishment, data 318 integrity and data confidentiality protection of data inside the ACP 319 and in addition, provide replay protection. 321 An attacker will therefore not be able to join the ACP unless having 322 a valid domain certificate, also packet injection and sniffing 323 traffic will not be possible due to the security provided by the 324 encryption protocol. 326 The remaining attack vector would be to attack the underlying AN 327 protocols themselves, either via directed attacks or by denial-of- 328 service attacks. However, as the ACP is built using link-local IPv6 329 address, remote attacks are impossible. The ULA addresses are only 330 reachable inside the ACP context, therefore unreachable from the data 331 plane. Also, the ACP protocols should be implemented to be attack 332 resistant and not consume unnecessary resources even while under 333 attack. 335 6. Use Cases for the ACP 337 The ACP automatically enables a number of use cases which provide 338 immediate benefits: 340 o Secure bootstrap of new devices without requiring any 341 configuration. As explained in Section 3, a new device will 342 automatically be bootstrapped in a secure fashion and be deployed 343 with a domain certificate. This will happen without any 344 configuration, allowing a new device to be shipped directly to the 345 end-user location without the need for any pre-provisioning. 347 o Virtual-out-of-band (VooB) control plane which provides 348 connectivity to all devices regardless of their configuration or 349 global routing table. This makes it possible to manage devices 350 without having to configure data plane services or to deploy a 351 separate management network. It also simplifies management 352 applications, because changes done by the applications cannot 353 affect reachability of the devices. 355 7. The Administrator View 357 An ACP is self-forming, self-managing and self-protecting, therefore 358 has minimal dependencies on the administrator of the network. 359 Specifically, it cannot be configured, there is therefore no scope 360 for configuration errors on the ACP itself. The administrator may 361 have the option to enable or disable the entire approach, but 362 detailed configuration is not possible. This means that the ACP must 363 not be reflected in the running configuration of devices, except a 364 possible on/off switch. 366 While configuration is not possible, an administrator must have full 367 visibility of the ACP and all its parameters, to be able to do 368 trouble-shooting. Therefore, an ACP must support all show and debug 369 options, as for any other network function. Specifically, a network 370 management system or controller must be able to discover the ACP, and 371 monitor its health. This visibility of ACP operations must clearly 372 be separated from visibility of data plane so automated systems will 373 never have to deal with ACP aspect unless they explicitly desire to 374 do so. 376 Since an ACP is self-protecting, a device not supporting the ACP, or 377 without a valid domain certificate cannot connect to it. This means 378 that by default a traditional controller or network management system 379 cannot connect to an ACP. To make this possible for systems not 380 supporting the ACP natively, the connection to the ACP must be 381 manually established, through configuration. [EDNOTE: More details 382 to be provided in a later version of this document.] Long term NMS 383 systems might become autonomic devices with domain certificates, and 384 then automatically join the ACP. 386 8. Security Considerations 388 An ACP is self-protecting and there is no need to apply configuration 389 to make it secure. Its security therefore does not depend on 390 configuration. 392 However, the security of the ACP depends on a number of other 393 factors: 395 o The usage of domain certificates depends on a valid supporting PKI 396 infrastructure. If the chain of trust of this PKI infrastructure 397 is compromised, the security of the ACP is also compromised. This 398 is typically under the control of the network administrator. 400 o Security can be compromised by implementation errors (bugs), as in 401 all products. 403 Fundamentally, security depends on correct operation, implementation 404 and architecture. Autonomic approaches such as the ACP largely 405 eliminate the dependency on correct operation; implementation and 406 architectural mistakes are still possible, as in all networking 407 technologies. 409 9. IANA Considerations 411 This document requests no action by IANA. 413 10. Acknowledgements 415 This work originated from an Autonomic Networking project at Cisco 416 Systems, which started in early 2010. Many people contributed to 417 this project and the idea of the Autonomic Control Plane, amongst 418 which (in alphabetical order): Ignas Bagdonas, Parag Bhide, Alex 419 Clemm, Toerless Eckert, Yves Hertoghs, Bruno Klauser, Max Pritikin, 420 Ravi Kumar Vadapalli. 422 11. Change log [RFC Editor: Please remove] 424 00: Initial version. 426 12. References 428 [I-D.irtf-nmrg-an-gap-analysis] 429 Behringer, M., Carpenter, B., and S. Jiang, "Gap Analysis 430 for Autonomic Networking", draft-irtf-nmrg-an-gap- 431 analysis-00 (work in progress), April 2014. 433 [I-D.irtf-nmrg-autonomic-network-definitions] 434 Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 435 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 436 Networking - Definitions and Design Goals", draft-irtf- 437 nmrg-autonomic-network-definitions-00 (work in progress), 438 December 2013. 440 [I-D.pritikin-bootstrapping-keyinfrastructures] 441 Pritikin, M., Behringer, M., and S. Bjarnason, 442 "Bootstrapping Key Infrastructures", draft-pritikin- 443 bootstrapping-keyinfrastructures-00 (work in progress), 444 January 2014. 446 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 447 Addresses", RFC 4193, October 2005. 449 Authors' Addresses 451 Michael H. Behringer 452 Cisco 454 Email: mbehring@cisco.com 456 Steinthor Bjarnason 457 Cisco 459 Email: sbjarnas@cisco.com 461 Balaji BL 462 Cisco 464 Email: blbalaji@cisco.com 466 Toerless Eckert 467 Cisco 469 Email: eckert@cisco.com