idnits 2.17.1 draft-ietf-anima-autonomic-control-plane-09.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 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 432: '... ACP1: The ACP SHOULD provide robust...' RFC 2119 keyword, line 437: '... ACP2: The ACP MUST have a separate ...' RFC 2119 keyword, line 441: '... ACP3: The ACP MUST use autonomicall...' RFC 2119 keyword, line 446: '... ACP4: The ACP MUST be generic. Usa...' RFC 2119 keyword, line 447: '...rastructure. It MUST NOT be tied to a...' (70 more instances...) -- The draft header indicates that this document updates RFC4291, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4193, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 637 has weird spacing: '... called anim...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The Certificate Authority in an ACP network MUST not change this, and create the respective subjectAltName / rfc822Name in the certificate. The ACP nodes can therefore find their ACP address and domain using this field in the domain certificate, both for themselves, as well as for other nodes. (Using the creation date from RFC4193, updated by this document, for RFC5378 checks: 2003-08-27) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 2, 2017) is 2458 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ACP VRF' is mentioned on line 1958, but not defined == Missing Reference: 'Select' is mentioned on line 2117, but not defined == Missing Reference: 'Plane' is mentioned on line 2119, but not defined ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-07 == Outdated reference: A later version (-10) exists of draft-ietf-anima-reference-model-04 == Outdated reference: A later version (-10) exists of draft-ietf-anima-stable-connectivity-04 == Outdated reference: A later version (-29) exists of draft-ietf-netconf-zerotouch-14 == Outdated reference: A later version (-44) exists of draft-ietf-roll-useofrplinfo-16 -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 3 errors (**), 0 flaws (~~), 11 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANIMA WG M. Behringer, Ed. 3 Internet-Draft 4 Updates: 4291,4193 (if approved) T. Eckert, Ed. 5 Intended status: Standards Track Huawei 6 Expires: February 3, 2018 S. Bjarnason 7 Arbor Networks 8 August 2, 2017 10 An Autonomic Control Plane (ACP) 11 draft-ietf-anima-autonomic-control-plane-09 13 Abstract 15 Autonomic functions need a control plane to communicate, which 16 depends on some addressing and routing. This Autonomic Control Plane 17 should ideally be self-managing, and as independent as possible of 18 configuration. This document defines an "Autonomic Control Plane", 19 with the primary use as a control plane for autonomic functions. It 20 also serves as a "virtual out of band channel" for OAM communications 21 over a network that is not configured, or mis-configured. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on February 3, 2018. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Use Cases for an Autonomic Control Plane . . . . . . . . . . 8 60 3.1. An Infrastructure for Autonomic Functions . . . . . . . . 8 61 3.2. Secure Bootstrap over an Unconfigured Network . . . . . . 8 62 3.3. Data Plane Independent Permanent Reachability . . . . . . 9 63 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 10 64 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 12 66 6.1. Domain Certificate . . . . . . . . . . . . . . . . . . . 12 67 6.1.1. ACP information . . . . . . . . . . . . . . . . . . . 12 68 6.1.2. Maintenance . . . . . . . . . . . . . . . . . . . . . 14 69 6.2. AN Adjacency Table . . . . . . . . . . . . . . . . . . . 16 70 6.3. Neighbor Discovery with DULL GRASP . . . . . . . . . . . 17 71 6.4. Candidate ACP Neighbor Selection . . . . . . . . . . . . 19 72 6.5. Channel Selection . . . . . . . . . . . . . . . . . . . . 20 73 6.6. Candidate ACP Neighbor certificate verification . . . . . 21 74 6.7. Security Association protocols . . . . . . . . . . . . . 22 75 6.7.1. ACP via IKEv2 . . . . . . . . . . . . . . . . . . . . 22 76 6.7.2. ACP via dTLS . . . . . . . . . . . . . . . . . . . . 23 77 6.7.3. ACP Secure Channel Requirements . . . . . . . . . . . 23 78 6.8. GRASP in the ACP . . . . . . . . . . . . . . . . . . . . 24 79 6.8.1. GRASP as a core service of the ACP . . . . . . . . . 24 80 6.8.2. ACP as the Security and Transport substrate for GRASP 24 81 6.9. Context Separation . . . . . . . . . . . . . . . . . . . 25 82 6.10. Addressing inside the ACP . . . . . . . . . . . . . . . . 25 83 6.10.1. Fundamental Concepts of Autonomic Addressing . . . . 26 84 6.10.2. The ACP Addressing Base Scheme . . . . . . . . . . . 27 85 6.10.3. ACP Zone Addressing Sub-Scheme . . . . . . . . . . . 27 86 6.10.4. ACP Manual Addressing Sub-Scheme . . . . . . . . . . 30 87 6.10.5. ACP Vlong Addressing Sub-Scheme . . . . . . . . . . 31 88 6.10.6. Other ACP Addressing Sub-Schemes . . . . . . . . . . 32 89 6.11. Routing in the ACP . . . . . . . . . . . . . . . . . . . 32 90 6.11.1. RPL Profile . . . . . . . . . . . . . . . . . . . . 32 91 6.12. General ACP Considerations . . . . . . . . . . . . . . . 36 92 6.12.1. Addressing of Secure Channels in the data plane . . 36 93 6.12.2. MTU . . . . . . . . . . . . . . . . . . . . . . . . 36 94 6.12.3. Multiple links between nodes . . . . . . . . . . . . 37 95 6.12.4. ACP interfaces . . . . . . . . . . . . . . . . . . . 37 96 7. ACP support on L2 switches/ports (Normative) . . . . . . . . 38 97 7.1. Why . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 98 7.2. How (per L2 port DULL GRASP) . . . . . . . . . . . . . . 40 99 8. Support for Non-Autonomic Components (Normative) . . . . . . 41 100 8.1. ACP Connect . . . . . . . . . . . . . . . . . . . . . . . 41 101 8.1.1. Non-Autonomic Controller / NMS system . . . . . . . . 41 102 8.1.2. Software Components . . . . . . . . . . . . . . . . . 44 103 8.1.3. Auto Configuration . . . . . . . . . . . . . . . . . 45 104 8.1.4. Combined ACP and Data Data Plane Interface (VRF 105 Select) . . . . . . . . . . . . . . . . . . . . . . . 45 106 8.1.5. Use of GRASP . . . . . . . . . . . . . . . . . . . . 47 107 8.2. ACP through Non-Autonomic L3 Clouds (Remote ACP 108 neighbors) . . . . . . . . . . . . . . . . . . . . . . . 48 109 8.2.1. Configured Remote ACP neighbor . . . . . . . . . . . 48 110 8.2.2. Tunneled Remote ACP Neighbor . . . . . . . . . . . . 49 111 8.2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 50 112 9. Benefits (Informative) . . . . . . . . . . . . . . . . . . . 50 113 9.1. Self-Healing Properties . . . . . . . . . . . . . . . . . 50 114 9.2. Self-Protection Properties . . . . . . . . . . . . . . . 51 115 9.2.1. From the outside . . . . . . . . . . . . . . . . . . 51 116 9.2.2. From the inside . . . . . . . . . . . . . . . . . . . 52 117 9.3. The Administrator View . . . . . . . . . . . . . . . . . 53 118 10. Further Considerations (Informative) . . . . . . . . . . . . 53 119 10.1. Domain Certificate provisioning / enrollment . . . . . . 53 120 10.2. ACP Neighbor discovery protocol selection . . . . . . . 55 121 10.2.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 55 122 10.2.2. mDNS and L2 support . . . . . . . . . . . . . . . . 55 123 10.2.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 55 124 10.3. Choice of routing protocol (RPL) . . . . . . . . . . . . 56 125 10.4. Extending ACP channel negotiation (via GRASP) . . . . . 57 126 10.5. CAs, domains and routing subdomains . . . . . . . . . . 59 127 11. RFC4291/RFC4193 Updates Considerations . . . . . . . . . . . 61 128 12. Security Considerations . . . . . . . . . . . . . . . . . . . 63 129 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63 130 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 63 131 15. Change log [RFC Editor: Please remove] . . . . . . . . . . . 64 132 15.1. Initial version . . . . . . . . . . . . . . . . . . . . 64 133 15.2. draft-behringer-anima-autonomic-control-plane-00 . . . . 64 134 15.3. draft-behringer-anima-autonomic-control-plane-01 . . . . 64 135 15.4. draft-behringer-anima-autonomic-control-plane-02 . . . . 64 136 15.5. draft-behringer-anima-autonomic-control-plane-03 . . . . 65 137 15.6. draft-ietf-anima-autonomic-control-plane-00 . . . . . . 65 138 15.7. draft-ietf-anima-autonomic-control-plane-01 . . . . . . 65 139 15.8. draft-ietf-anima-autonomic-control-plane-02 . . . . . . 66 140 15.9. draft-ietf-anima-autonomic-control-plane-03 . . . . . . 66 141 15.10. draft-ietf-anima-autonomic-control-plane-04 . . . . . . 66 142 15.11. draft-ietf-anima-autonomic-control-plane-05 . . . . . . 67 143 15.12. draft-ietf-anima-autonomic-control-plane-06 . . . . . . 67 144 15.13. draft-ietf-anima-autonomic-control-plane-07 . . . . . . 68 145 15.14. draft-ietf-anima-autonomic-control-plane-08 . . . . . . 69 146 15.15. draft-ietf-anima-autonomic-control-plane-09 . . . . . . 71 147 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 73 148 16.1. Normative References . . . . . . . . . . . . . . . . . . 73 149 16.2. Informative References . . . . . . . . . . . . . . . . . 74 150 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 76 152 1. Introduction 154 Autonomic Networking is a concept of self-management: Autonomic 155 functions self-configure, and negotiate parameters and settings 156 across the network.[RFC7575] defines the fundamental ideas and design 157 goals of Autonomic Networking. A gap analysis of Autonomic 158 Networking is given in [RFC7576]. The reference architecture for 159 Autonomic Networking in the IETF is currently being defined in the 160 document [I-D.ietf-anima-reference-model] 162 Autonomic functions need a stable and robust infrastructure to 163 communicate on. This infrastructure should be as robust as possible, 164 and it should be re-usable by all autonomic functions.[RFC7575] calls 165 it the "Autonomic Control Plane". This document defines the 166 Autonomic Control Plane. 168 Today, the management and control plane of networks typically runs in 169 the global routing table, which is dependent on correct configuration 170 and routing. Misconfigurations or routing problems can therefore 171 disrupt management and control channels. Traditionally, an out of 172 band network has been used to recover from such problems, or 173 personnel is sent on site to access devices through console ports 174 (craft ports). However, both options are operationally expensive. 176 In increasingly automated networks either controllers or distributed 177 autonomic service agents in the network require a control plane which 178 is independent of the network they manage, to avoid impacting their 179 own operations. 181 This document describes options for a self-forming, self-managing and 182 self-protecting "Autonomic Control Plane" (ACP) which is inband on 183 the network, yet as independent as possible of configuration, 184 addressing and routing problems (for details how this achieved, see 185 Section 6). It therefore remains operational even in the presence of 186 configuration errors, addressing or routing issues, or where policy 187 could inadvertently affect control plane connectivity. The Autonomic 188 Control Plane serves several purposes at the same time: 190 o Autonomic functions communicate over the ACP. The ACP therefore 191 supports directly Autonomic Networking functions, as described in 192 [I-D.ietf-anima-reference-model]. For example, GRASP 194 [I-D.ietf-anima-grasp] runs securely inside the ACP and depends on 195 the ACP as its "security substrate". 197 o An operator can use it to log into remote devices, even if the 198 data plane is misconfigured or unconfigured. 200 o A controller or network management system can use it to securely 201 bootstrap network devices in remote locations, even if the network 202 in between is not yet configured; no data-plane dependent 203 bootstrap configuration is required. An example of such a secure 204 bootstrap process is described in 205 [I-D.ietf-anima-bootstrapping-keyinfra] 207 This document describes some use cases for the ACP in Section 3, it 208 defines the requirements in Section 4, Section 5 gives an overview 209 how an Autonomic Control Plane is constructed, and in Section 6 the 210 detailed process is explained.Section 8 explains how non-autonomic 211 nodes and networks can be integrated, and Section 6.7 the first 212 channel types for the ACP. 214 The document "Autonomic Network Stable Connectivity" 215 [I-D.ietf-anima-stable-connectivity] describes how the ACP can be 216 used to provide stable connectivity for OAM applications. It also 217 explains on how existing management solutions can leverage the ACP in 218 parallel with traditional management models, when to use the ACP 219 versus the data plane, how to integrate IPv4 based management, etc. 221 2. Terminology 223 This document uses the following terms (sorted alphabetically): 225 ACP "Autonomic Control Plane". The Autonomic Function defined in 226 this document. It provides secure zero-touch network wide IPv6 227 connectivity between devices supporting it. The ACP is primarily 228 meant to be used as a component of the ANI to enable Autonomic 229 Networks but it can equally be used in simple ANI networks (with 230 no other Autonomic Functions) or completely by itself. 232 ACP address An IPv6 ULA address assigned to the ACP device. It is 233 stored in the ACP information field of an ACP devices LDevID. 235 ACP connect A physical interface on an ACP device providing access 236 to the ACP for non ACP capable devices. See Section 8.1.1. 238 ACP device A device supporting the ACP according to this document. 240 ACP information (field) An rfc822Name information element (eg: 241 field) in the Domain Certificate in which the ACP relevant 242 information is encoded: the AN Domain Name and the ACP address. 244 ACP (loopback) interface The loopback interface in the ACP VRF that 245 hosts the ACP address. 247 ACP (ULA) prefix(es) The prefixes routed across the ACP. In the 248 normal/simple case, the ACP has one ULA prefix, see Section 6.10. 249 The ACP routing table may include multiple ULA prefixes if the 250 "rsub" option is used to create addresses from more than one ULA 251 prefix. See Section 6.1.1. The ACP may also include non-ULA 252 prefixes if those are configured on ACP connect interfaces. See 253 Section 8.1.1. 255 ACP secure channel A virtual subinterface/tunnel established hop-by- 256 hop between adjacent ACP devices to carry traffic of the ACP VRF 257 separated from Data Plane traffic inband over the same links as 258 the Data Plane. 260 ACP secure channel protocol The protocol used to build an ACP secure 261 channel, eg: IKEv2/IPsec or dTLS. 263 ACP virtual interface An interface in the ACP VRF mapped to one or 264 more ACP secure channels. See Section 6.12.4. 266 ACP VRF The ACP is modelled in this document as a "Virtual Routing 267 and Forwarding" (VRF) component in a network device. 269 AN "Autonomic Network". A network according to 270 [I-D.ietf-anima-reference-model]. Its main components are Intent, 271 Autonomic Functions and ANI. 273 AN Domain Name An FQDN (Fully Qualified Domain Name) identifying an 274 Autonomic Network. It is stored in the ACP information field of 275 an ANI devices LDevID. See Section 6.1.1. 277 ANI (device/network) "Autonomic Network Infrastructure". A device 278 with ANI supports ACP, BRSKI and GRASP. The ANI is the 279 infrastructure to enable autonomic functions. An ANI network or 280 device is a most basic Autonomic Network or device: it does not 281 need to have ASAs other than the ones implementing ACP, BRSKI and 282 GRASP nor Intent support. A simple ANI network (without further 283 autonomic functions) can for example support secure zero touch 284 bootstrap and stble connectivity for SDN networks - see 285 [I-D.ietf-anima-stable-connectivity]. 287 ANIMA "Autonomic Networking Integrated Model and Approach". ACP, 288 BRSKI and GRASP are work products of ANIMA. 290 ASA "Autonomic Service Agent". Autonomic software modules running 291 on an ANI device. The components making up the ANI (BRSKI, ACP, 292 GRASP) are also described as ASAs. 294 Autonomic Function A function/service in an Autonomic Network (AN) 295 composed of one or more ASA across one or more ANI Devices. 297 BRSKI "Bootstrapping Remote Secure Key Infrastructures" 298 ([I-D.ietf-anima-bootstrapping-keyinfra]. A protocol extending 299 EST to enable secure zero touch bootstrap in conjunction with ACP. 300 ANI devices use ACP and BRSKI. 302 Data Plane The counterpoint to the ACP in an ACP device: all VRFs 303 other than the ACP. In a simple ACP or ANI device, the Data Plane 304 is typically provisioned non-autonomic, for example manually 305 (including across the ACP) or via SDN controllers. In a full 306 Autonomic Network Device, the Data Plane is managed autonomically 307 via Autonomic Functions and Intent. 309 Domain Certificate An LDevID with an information element defined in 310 this document used by the ACP to derive and cryptographically 311 assert its membership in an autonomic domain. 313 enrollment The process where a device presents identification (for 314 example through keying material such as the private key of an 315 IDevID) to a network and acquires a network specific identity and 316 trust anchor such as an LDevID. 318 EST "Enrollment over Secure Transport" ([RFC7030]). IETF standard 319 protocol for enrollment of a device with an LDevID. BRSKI is 320 based on EST. 322 GRASP "Generic Autonomic Signaling Protocol". An extensible 323 signaling protocol required by the ACP for ACP neighbor discovery. 324 The ACP also provides the "security and transport substrate" for 325 the "ACP instance of GRASP" which is run inside the ACP to support 326 BRSKI and other future Autonomic Functions. See 327 [I-D.ietf-anima-grasp]. 329 IDevID An "Initial Device IDentity" X.509 certificate installed by 330 the vendor on new equipment. Contains information that 331 establishes the identity of the device in the context of its 332 vendor/manufacturer such as device model/type and serial number. 334 LDevID A "Local Device IDentity" X.509 certificate installed during 335 an "enrollment". The ACP depends on a Domain Certificate which is 336 an LDevID. 338 MIC "Manufacturer Installed Certificate". Another word not used in 339 this document to describe an IDevID. 341 RPL "IPv6 Routing Protocol for Low-Power and Lossy Networks". The 342 routing protocol used in the ACP. 344 MASA (service) "Manufacturer Authorized Signing Authority". A 345 vendor/manufacturer or delegated cloud service on the Internet 346 used as part of the BRSKI protocol. 348 sUDI "secured Unique Device Identifier". Another term not used in 349 this document to refer to an IDevID. 351 UDI "Unique Device Identifier". In the context of this document 352 unsecured identity information of a device typically consisting of 353 at least device model/type and serial number, often in a vendor 354 specific format. See sUDI and LDevID. 356 ULA "Unique Local Address". The IPv6 equivalent to RFC1918 IPv4 357 addresses. ACP addresses are ULA. 359 3. Use Cases for an Autonomic Control Plane 361 3.1. An Infrastructure for Autonomic Functions 363 Autonomic Functions need a stable infrastructure to run on, and all 364 autonomic functions should use the same infrastructure to minimise 365 the complexity of the network. This way, there is only need for a 366 single discovery mechanism, a single security mechanism, and other 367 processes that distributed functions require. 369 3.2. Secure Bootstrap over an Unconfigured Network 371 Today, bootstrapping a new device typically requires all devices 372 between a controlling node (such as an SDN controller) and the new 373 device to be completely and correctly addressed, configured and 374 secured. Therefore, bootstrapping a network happens in layers around 375 the controller. Without console access (for example through an out 376 of band network) it is not possible today to make devices securely 377 reachable before having configured the entire network between. 379 With the ACP, secure bootstrap of new devices can happen without 380 requiring any configuration on the network. A new device can 381 automatically be bootstrapped in a secure fashion and be deployed 382 with a domain certificate. This does not require any configuration 383 on intermediate nodes, because they can communicate through the ACP. 385 3.3. Data Plane Independent Permanent Reachability 387 Today, most critical control plane protocols and network management 388 protocols are running in the data plane (global routing table) of the 389 network. This leads to undesirable dependencies between control and 390 management plane on one side and the data plane on the other: Only if 391 the data plane is operational, will the other planes work as 392 expected. 394 Data plane connectivity can be affected by errors and faults, for 395 example certain AAA misconfigurations can lock an administrator out 396 of a device; routing or addressing issues can make a device 397 unreachable; shutting down interfaces over which a current management 398 session is running can lock an admin irreversibly out of the device. 399 Traditionally only console access can help recover from such issues. 401 Data plane dependencies also affect NOC/SDN controller applications: 402 Certain network changes are today hard to operate, because the change 403 itself may affect reachability of the devices. Examples are address 404 or mask changes, routing changes, or security policies. Today such 405 changes require precise hop-by-hop planning. 407 The ACP provides reachability that is largely independent of the data 408 plane, which allows control plane and management plane to operate 409 more robustly: 411 o For management plane protocols, the ACP provides the functionality 412 of a "Virtual-out-of-band (VooB) channel", by providing 413 connectivity to all devices regardless of their configuration or 414 global routing table. 416 o For control plane protocols, the ACP allows their operation even 417 when the data plane is temporarily faulty, or during transitional 418 events, such as routing changes, which may affect the control 419 plane at least temporarily. This is specifically important for 420 autonomic service agents, which could affect data plane 421 connectivity. 423 The document "Autonomic Network Stable Connectivity" 424 [I-D.ietf-anima-stable-connectivity] explains the use cases for the 425 ACP in significantly more detail and explains how the ACP can be used 426 in practical network operations. 428 4. Requirements 430 The Autonomic Control Plane has the following requirements: 432 ACP1: The ACP SHOULD provide robust connectivity: As far as 433 possible, it should be independent of configured addressing, 434 configuration and routing. Requirements 2 and 3 build on this 435 requirement, but also have value on their own. 437 ACP2: The ACP MUST have a separate address space from the data 438 plane. Reason: traceability, debug-ability, separation from 439 data plane, security (can block easily at edge). 441 ACP3: The ACP MUST use autonomically managed address space. Reason: 442 easy bootstrap and setup ("autonomic"); robustness (admin 443 can't mess things up so easily). This document suggests to 444 use ULA addressing for this purpose. 446 ACP4: The ACP MUST be generic. Usable by all the functions and 447 protocols of the AN infrastructure. It MUST NOT be tied to a 448 particular protocol. 450 ACP5: The ACP MUST provide security: Messages coming through the ACP 451 MUST be authenticated to be from a trusted node, and SHOULD 452 (very strong SHOULD) be encrypted. 454 The default mode of operation of the ACP is hop-by-hop, because this 455 interaction can be built on IPv6 link local addressing, which is 456 autonomic, and has no dependency on configuration (requirement 1). 457 It may be necessary to have ACP connectivity over non-autonomic 458 nodes, for example to link autonomic nodes over the general Internet. 459 This is possible, but then has a dependency on routing over the non- 460 autonomic hops (see Section 8.2). 462 5. Overview 464 The Autonomic Control Plane is constructed in the following way (for 465 details, see Section 6): 467 1. An autonomic node creates a virtual routing and forwarding (VRF) 468 instance, or a similar virtual context. 470 2. It determines, following a policy, a candidate peer list. This 471 is the list of nodes to which it should establish an Autonomic 472 Control Plane. Default policy is: To all adjacent nodes in the 473 same domain. 475 3. For each node in the candidate peer list, it authenticates that 476 node and negotiates a mutually acceptable channel type. 478 4. It then establishes a secure tunnel of the negotiated channel 479 type. These tunnels are placed into the previously set up VRF. 480 This creates an overlay network with hop-by-hop tunnels. 482 5. Inside the ACP VRF, each node sets up a virtual (loopback) 483 interface with its ULA IPv6 address. 485 6. Each node runs a lightweight routing protocol, to announce 486 reachability of the virtual addresses inside the ACP. 488 Note: 490 o Non-autonomic NMS systems or controllers have to be manually 491 connected into the ACP. 493 o Connecting over non-autonomic Layer-3 clouds initially requires a 494 tunnel between autonomic nodes. 496 o None of the above operations (except manual ones) is reflected in 497 the configuration of the device. 499 The following figure illustrates the ACP. 501 autonomic node 1 autonomic node 2 502 ................... ................... 503 secure . . secure . . secure 504 tunnel : +-----------+ : tunnel : +-----------+ : tunnel 505 ..--------| ACP VRF |---------------------| ACP VRF |---------.. 506 : / \ / \ <--routing--> / \ / \ : 507 : \ / \ / \ / \ / : 508 ..--------| virtual |---------------------| virtual |---------.. 509 : | interface | : : | interface | : 510 : +-----------+ : : +-----------+ : 511 : : : : 512 : data plane :...............: data plane : 513 : : link : : 514 :.................: :.................: 516 Figure 1 518 The resulting overlay network is normally based exclusively on hop- 519 by-hop tunnels. This is because addressing used on links is IPv6 520 link local addressing, which does not require any prior set-up. This 521 way the ACP can be built even if there is no configuration on the 522 devices, or if the data plane has issues such as addressing or 523 routing problems. 525 6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 527 This section describes the steps to set up an Autonomic Control Plane 528 (ACP), and highlights the key properties which make it 529 "indestructible" against many inadvert changes to the data plane, for 530 example caused by misconfigurations. 532 An ACP device can be a router, switch, controller, NMS host, or any 533 other IP device. Initially, it must have a globally unique domain 534 certificate (LDevID), as well as an adjacency table. It then can 535 start to discover ACP neighbors and build the ACP. This is described 536 step by step in the following sections: 538 6.1. Domain Certificate 540 To establish an ACP securely, an ACP device MUST have a globally 541 unique domain certificate (LDevID), with which it can 542 cryptographically assert its membership in the domain as well as the 543 CA certificate chain used to sign the LDevID. This CA certificate 544 chain is used to verify the LDevID of candidate ACP peers (see 545 Section 6.6). The ACP does not mandate specific mechanism by which 546 this certificate information is provisioned onto the ACP device, it 547 only requires the following ACP specific information field in its 548 LDevID as well as the LDevIDs of candidate ACP peers. See 549 Section 10.1 for more information about enrollment or provisioning 550 options. 552 6.1.1. ACP information 554 The domain certificate (LDevID) of an autonomic node MUST contain ACP 555 specific information, specifically the domain name, the address of 556 the device in the ACP with the Zone-ID set to zero ("ACP address"). 557 This information MUST be encoded in the LDevID in the subjectAltName 558 / rfc822Name field in the following way: 560 anima.acp+{+{+}}@ 562 Example: 564 anima.acp+fda379A6f6ee00000200000064000001+area51.research@acp.exampl 565 e.com 567 The acp-address MUST be specified as a string of 32 hex characters 568 with only lower letters a-f and numbers 0-9 so that the local part of 569 the address can matches the simple dot-atom format of [RFC5322] (":" 570 are not allowed in that format). 572 is used to indicate the Autonomic Domain across which all 573 ACP nodes trust each other and are willing to build ACP channel with 574 each other. See Section 6.6. It SHOULD be the FQDN of a domain 575 owned by the operator assigning the certificate. This is a simple 576 method to ensure that the domain name is globally unique and 577 collision of ACP addresses would therefore only happen due to ULA 578 hash collisions. If the operator does not own any FQDN, it should 579 choose am FQDN format string that intends to be equally unique. 581 {.} is the autonomic "routing subdomain" that is used 582 used in addressing to calculate the hash used in the creation of the 583 ACP address of the device. As the name implies, every routing 584 subdomain is also a separate routing subdomain. is optional 585 and should only used when its impacts are understood. The domain 586 without any leading rsub field is also just another routing 587 subdomain. 589 The optional field is used for future extensions to this 590 specification. It MUST be ignored if present and not understood. 592 The subjectAlName / rfc822Name encoding of the ACP domain name and 593 ACP address is used for the following reasons: 595 o There are a wide range of pre-existing protocols/services where 596 authentication with LDevID is desirable. Enrolling and 597 maintaining separate LDevIDs for each of these protocols/services 598 is often undesirable overhead. Therefore, the information element 599 required for the ACP in the domain certificate should be encoded 600 in a way that minimizes the possibility of creating 601 incompatibilites with such other uses beside the authentication 602 for the ACP. 604 o The elements in the LDevID required for the ACP should not cause 605 incompatibilities with any pre-existing ASN.1 software potentially 606 in use in those other pre-existing SW systems. This eliminates 607 the use of novel information elements because those require 608 extensions to those pre-existing ASN.1 parsers. 610 o subjectAltname / rfc822Name is a pre-existing element that must be 611 supported by all existing ASN.1 parsers for LDevID. 613 o The elements in the LDevID required for the ACP should also not be 614 misinterpreted by any pre-existing protocol/service that might use 615 the LDevID. If the elements used for the ACP are interpreted by 616 other protocols/services, then the impact should be benign. 618 o Using an IP address format encoding could result in non-benign 619 misinterpretation of the ACP information, for example other 620 protocol/services unaware of the ACP could try to do something 621 with the ACP address that would fail to work correctly. For 622 example, the address could be interpreted to be an address of the 623 device in a VRF other than the ACP VRF. 625 o At minimum, both the AN domain name and the non-domain name 626 derived part of the ACP address need to be encoded in one or more 627 appropriate fields of the certificate, so there are not many 628 alternatives with pre-existing fields where the only possible 629 conflicts would likely be beneficial. 631 o rfc822Name encoding is quite flexible. We choose to encode the 632 full ACP address AND the domain name with sub part into a single 633 rfc822Name information element it, so that it is easier to 634 examine/use the encoded "ACP information (field)". 636 o The format of the rfc822Name is choosen so that an operator can 637 set up a mailbox called anima.acp@ that would receive 638 emails sent towards the rfc822Name of any AN device inside a 639 domain. This is possible because components behind a plus symbol 640 are considered part of a single mailbox. In other words, it is 641 not necessary to set up a separate mailbox for every autonomic 642 devices ACP information field, but only one for the whole domain. 644 o In result, if any unexpected use of the ACP addressing information 645 in a certificate happens, it is benign and detectable: it would be 646 mail to that mailbox. 648 See section 4.2.1.6 of [RFC5280] for details on the subjectAltName 649 field. 651 6.1.2. Maintenance 653 The ACP network MUST have one or more nodes that support EST server 654 ([RFC7030] functionality (eg: as an ASA) through which ACP nodes can 655 renew their domain certificate. The ACP address of at least one such 656 EST server SHOULD have been enrolled/provisioned into the ACP device 657 during initial installation of the domain certificate. 659 EST servers MUST announce their service via GRASP in the ACP through 660 M_FLOOD messages: 662 Example: 664 [M_FLOOD, 12340815, h'fda379a6f6ee0000200000064000001', 180000, 665 ["AN_join_registrar", SYNCH-FLAG, 255, "EST-TLS"], 666 [O_IPv6_LOCATOR, 667 h'fda379a6f6ee0000200000064000001', TCP, 80] 668 ] 670 The formal CDDL definition is: 672 flood-message = [M_FLOOD, session-id, initiator, ttl, 673 +[objective, (locator-option / [])]] 675 objective = ["AN_join_registrar", objective-flags, loop-count, 676 objective-value] 678 objective-flags = SYNCH-FLAG ; as in GRASP spec 679 loop-count = 255 ; mandatory maximum 680 objective-value = text ; name of the (list of) of supported 681 ; protocols: "EST-TLS" for RFC7030. 683 The M_FLOOD message MUST be sent periodically. The period is subject 684 to network administrator policy (EST server configuration). It must 685 be so low that the aggregate amount of periodic M_FLOODs from all EST 686 servers causes negligible traffic across the ACP. 688 In the above (recommended) example the period could be 60 seconds and 689 the indicated ttl of 180000 msec means that the objective would 690 continuously be cached by ACP devices even when two out of three 691 messages are dropped in transit (which is unlikely because GRASP hop- 692 by-hop forwarding is realiable). 694 The locator-option indicates the ACP transport address for the EST 695 server. The loop-count MUST be sete to 255. When an ACP node 696 receives the M_FLOOD, it will have been reduced by the number of hops 697 from the EST server. 699 When it is time for domain certificate reneal, the ACP device MUST 700 attempt to connect to the EST server(s) learned via GRASP starting 701 with the one that has the highest remaining loop-count (closest one). 702 If certificate renewal does not succeed, the device MUST attempt to 703 use the EST server(s) learned during initial provisioning/enrollment 704 of the certificate. After successful renewal of the domain 705 certificate, the ACP address from the certificate of the EST server 706 (as learned during the TLS handshake) is added to the top of the list 707 or provisioned/configured EST-server(s). 709 This logic of selecting an EST server for renewal is choosen to allow 710 for distributed EST servers to be used effectively but to also allow 711 fallback to the most reliably learned EST server - those that 712 performed already successful enrollment in before. A compromised 713 (non EST-server) ACP device for example can filter or fake GRASP 714 announcements, but it can not successfully renew a certificate and 715 can only prohibit traffic to a valid EST server when it is on the 716 path between the ACP device and the EST server. 718 The ACP device MUST support Certificate Revocation Lists via HTTPs 719 from one or more Certificate Distribution Points. These CDPs MUST be 720 indicated in the Domain Certificate when used. If the CDP URL uses 721 an IPv6 ULA, the ACP device will try to reach it via the ACP. In 722 that case the ACP address in the domain certificate of the CDP as 723 learned by the ACP device during the HTTPs TLS handshake MUST match 724 that ULA address in the HTTPs URL. 726 Renewal of certificates SHOULD start after less than 50% of the 727 domain certificate lifetime so that network operations has ample time 728 to investigate and resolve any problems that cause a device to not 729 renew its domain certificate in time - and to allow prolonged periods 730 of running parts of a network disconnected from any CA. 732 Certificate lifetime should be set to be as short as feasible. Given 733 how certificate renewal is fully automated via ACP and EST, the 734 primarily imiting factor for shorter certificate lifetimes (than the 735 typical one year) is load on the EST server(s) and CA. It is 736 therefore recommended that ACP domain certificates are managed via a 737 CA chain where the assigning CA has enough peformance to manage short 738 lived certificates. 740 See Section 10.1 for further optimizationss of certificate 741 optimizations when BRSKI can be used. 743 6.2. AN Adjacency Table 745 To know to which nodes to establish an ACP channel, every autonomic 746 node maintains an adjacency table. The adjacency table contains 747 information about adjacent autonomic nodes, at a minimum: node-ID, IP 748 address, domain, certificate. An autonomic device MUST maintain this 749 adjacency table up to date. This table is used to determine to which 750 neighbor an ACP connection is established. 752 Where the next autonomic device is not directly adjacent, the 753 information in the adjacency table can be supplemented by 754 configuration. For example, the node-ID and IP address could be 755 configured. 757 The adjacency table MAY contain information about the validity and 758 trust of the adjacent autonomic node's certificate. However, 759 subsequent steps MUST always start with authenticating the peer. 761 The adjacency table contains information about adjacent autonomic 762 nodes in general, independently of their domain and trust status. 763 The next step determines to which of those autonomic nodes an ACP 764 connection should be established. 766 6.3. Neighbor Discovery with DULL GRASP 768 Because of the the considerations in Section 10.2, the ACP uses DULL 769 (Discovery Unsolicited Link-Local) insecure instances of GRASP for 770 discovery of ACP neighbors. See section 3.5.2.2 of 771 [I-D.ietf-anima-grasp] for its formal definition. 773 The ACP uses one instance of DULL GRASP for every physical L2 subnet 774 of the ACP device to discovery physically adjacent candidate ACP 775 neighbors. Ideally, all physical interfaces SHOULD be brought up 776 enough so that ACP discovery can be performed and any physically 777 connected interfaces with ACP neighbors can then be brought into the 778 ACP even if the interface is otherwise not configured. Reception of 779 packets on such otherwise unconfigure interfaces MUST be limited so 780 that at first only IPv6 link-local address assignment (SLAAC) and 781 DULL GRASP works and then only the following ACP secure channel setup 782 packets - but not any other unnecessary traffic (eg: no other link- 783 local IPv6 transport stack responders for example). 785 ACP discovery MUST NOT be enabled by default on any non-physical 786 interfaces. In particular, ACP discovery MUST NOT run inside the 787 ACP. See Section 8.2.2 how to enable and use ACP with auto-discovery 788 across configured tunnels. 790 See Section 7 for how ACP should be extended on L3/L2 devices. 792 Note: If an ACP device also implements BRSKI (see Section 10.1) then 793 the above considerations also apply to discovery for BRSKI. Each 794 DULL instance of GRASP set up for ACP is then also used for the 795 discovery of a bootstrap proxy via BRSKI when the device does not 796 have a domain certificate. Discovery of ACP neighbors happens only 797 when the device does have the certificate. The device therefore 798 never needs to discover both a bootstrap proxy and ACP neighbor at 799 the same time. 801 An autonomic node announces itself to potential ACP peers by use of 802 the "AN_ACP" objective. This is a synchronization objective intended 803 to be flooded on a single link using the GRASP Flood Synchronization 804 (M_FLOOD) message. In accordance with the design of the Flood 805 message, a locator consisting of a specific link-local IP address, IP 806 protocol number and port number will be distributed with the flooded 807 objective. An example of the message is informally: 809 Example: 811 [M_FLOOD, 12340815, h'fe80000000000000c0011001FEEF0000, 1, 812 ["AN_ACP", SYNCH-FLAG, 1, "IKEv2"], 813 [O_IPv6_LOCATOR, 814 h'fe80000000000000c0011001FEEF0000, UDP, 15000] 815 ] 817 The formal CDDL definition is: 819 flood-message = [M_FLOOD, session-id, initiator, ttl, 820 +[objective, (locator-option / [])]] 822 objective = ["AN_ACP", objective-flags, loop-count, 823 objective-value] 825 objective-flags = ; as in the GRASP specification 826 loop-count = 1 ; limit to link-local operation 827 objective-value = text ; name of the (list of) secure 828 ; channel negotiation protocol(s) 830 The objective-flags field is set to indicate synchronization. 832 The ttl and loop-count are fixed at 1 since this is a link-local 833 operation. 835 The session-id is a random number used for loop prevention 836 (distinguishing a message from a prior instance of the same message). 837 In DULL this field is irrelevant but must still be set according to 838 the GRASP specification. 840 The originator MUST be the IPv6 link local address of the originating 841 autonomic node on the sending interface. 843 The 'objective-value' parameter is (normally) a string indicating the 844 secure channel protocol available at the specified or implied 845 locator. 847 The locator is optional and only required when the secure channel 848 protocol is not offered at a well-defined port number, or if there is 849 no well defined port number. For example, "IKEv2" has a well defined 850 port number 500, but in the above example, the candidate ACP neighbor 851 is offering ACP secure channel negotiation via IKEv2 on port 15000 852 (for the sake of creating a non-standard example). 854 If a locator is included, it MUST be an O_IPv6_LOCATOR, and the IPv6 855 address MUST be the same as the initiator address (these are DULL 856 requirements to minimize third party DoS attacks). 858 The secure channel methods defined in this document use the objective 859 values of "IKEv2" and "dTLS". There is no distinction between IKEv2 860 native and GRE-IKEv2 because this is purely negotiated via IKEv2. 862 A node that supports more than one secure channel protocol needs to 863 flood multiple versions of the "AN_ACP" objective, each accompanied 864 by its own locator. This can be in a single GRASP M_FLOOD message. 866 If multiple secure channel protocols are supported that all are run 867 on well-defined ports, then they can be announced via a single AN_ACP 868 objective using a list of string names as the objective value without 869 a following locator-option. 871 Note that a node serving both as an ACP node and BRSKI Join Proxy may 872 choose to distribute the "AN_ACP" objective and "AN_join_proxy" 873 objective in the same flood message, since GRASP allows multiple 874 objectives in one Flood message. This may be impractical though if 875 ACP and BRSKI operations are implemented via separate software 876 modules / ASAs though. 878 The result of the discovery is the IPv6 link-local address of the 879 neighbor as well as its supported secure channel protocols (and non- 880 standard port they are running on). It is stored in the AN Adjacency 881 Table, see Section 6.2 which then drives the further building of the 882 ACP to that neighbor. 884 6.4. Candidate ACP Neighbor Selection 886 An autonomic node must determine to which other autonomic nodes in 887 the adjacency table it should build an ACP connection. This is based 888 on the information in the AN Adjacency table. 890 The ACP is by default established exclusively between nodes in the 891 same domain. This includes all routing subdomains.Section 10.5 892 explains how ACP connections across routing subdomains are special. 894 Future extensions to this document including Intent can change this 895 default behaviour. Examples include: 897 o Build the ACP across all domains that have a common parent domain. 898 For example ACP nodes with domain "example.com", nodes of 899 "example.com", "access.example.com", "core.example.com" and 900 "city.core.example.com" could all establish one single ACP. 902 o ACP connections across domains with different CA (certificate 903 authorities) could establish a common ACP by installing the 904 alternate domains' CA into the trusted anchor store. This is an 905 executive management action that could easily be accomplished 906 through the control channel created by the ACP. 908 Since Intent is transported over the ACP, the first ACP connection a 909 node establishes is always following the default behaviour. See 910 Section 10.5 for more details. 912 The result of the candidate ACP neighbor selection process is a list 913 of adjacent or configured autonomic neighbors to which an ACP channel 914 should be established. The next step begins that channel 915 establishment. 917 6.5. Channel Selection 919 To avoid attacks, initial discovery of candidate ACP peers can not 920 include any non-protected negotiation. To avoid re-inventing and 921 validating security association mechanisms, the next step after 922 discoving the address of a candidate neighbor can only be to try 923 first to establish a security association with that neighbor using a 924 well-known security association method. 926 At this time in the lifecycle of autonomic devices, it is unclear 927 whether it is feasible to even decide on a single MTI (mandatory to 928 implement) security association protocol across all autonomic 929 devices: 931 From the use-cases it seems clear that not all type of autonomic 932 devices can or need to connect directly to each other or are able to 933 support or prefer all possible mechanisms. For example, code space 934 limited IoT devices may only support dTLS (because that code exists 935 already on them for end-to-end security use-cases), but low-end in- 936 ceiling L2 switches may only want to support MacSec because that is 937 also supported in HW, and only a more flexible gateway device may 938 need to support both of these mechanisms and potentially more. 940 To support extensible secure channel protocol selection without a 941 single common MTI protocol, autonomic devices must try all the ACP 942 secure channel protocols it supports and that are feasible because 943 the candidate ACP neighbor also announced them via its AN_ACP GRASP 944 parameters (these are called the "feasible" ACP secure channel 945 protocols). 947 To ensure that the selection of the secure channel protocols always 948 succeeds in a predictable fashion without blocking, the following 949 rules apply: 951 An autonomic device may choose to attempt initiate the different 952 feasible ACP secure channel protocol it supports according to its 953 local policies sequentially or in parallel, but it MUST support 954 acting as a responder to all of them in parallel. 956 Once the first secure channel protocol succeeds, the two peers know 957 each others certificates (because that must be used by all secure 958 channel protocols for mutual authentication. The device with the 959 lower Device-ID in the ACP address becomes Bob, the one with the 960 higher Device-ID in the certificate Alice. 962 Bob becomes passive, he does not attempt to further initiate ACP 963 secure channel protocols with Alice and does not consider it to be an 964 error when Alice closes secure channels. Alice becomes the active 965 party, continues to attempt setting up secure channel protocols with 966 Bob until she arrives at the best one (from her view) that also works 967 with Bob. 969 For example, originally Bob could have been the initiator of one ACP 970 secure channel protocol that Bob preferred and the security 971 association succeeded. The roles of Bob abd Alice are then assigned. 972 At this stage, the protocol may not even have completed negotiating a 973 common security profile. The protocol could for example have been 974 IPsec. It is not up to Alice to devide how to proceed. Even if the 975 IPsec connecting determined a working profile with Bob, Alice might 976 prefer some other secure protocol (eg: dTLS) and try to set that up 977 with Bob. If that succeeds, she would close the IPsec connection. If 978 no better protocol attempt succeeds, she would keep the IPsec 979 connection. 981 All this negotiation is in the context of an "L2 interface". Alice 982 and Bob will build ACP connections to each other on every "L2 983 interface" that they both connect to. An autonomic device must not 984 assume that neighbors with the same L2 or link-local IPv6 addresses 985 on different L2 interfaces are the ame devices. This can only be 986 determined after examining the certificate after a successful 987 security association attempt. 989 6.6. Candidate ACP Neighbor certificate verification 991 Independent of the security association protocol choosen, candidate 992 ACP neighbors need to be authenticated based on their autonomic 993 domain certificate. This implies that any security association 994 protocol MUST support certificate based authentication that can 995 support the following verification steps: 997 o The certificate is valid as proven by the security associations 998 protocol exchanges. 1000 o The peers certificate is signed by the same CA as the devices 1001 domain certificate. 1003 o If the device certificates indicate a CDP or OCSP then the peer's 1004 certificate must be valid occording to those criteria. eg: OCSP 1005 check across the ACP or not listed in the CRL. 1007 o The peers certificate has a valid ACP information field 1008 (subjectAltName / rfc822Name) and the domain name in that peers 1009 ACP information field is the same as in the devices certificate. 1010 Note that future Intent rules may modify this for example in 1011 support of subdomains. See Section 10.5. 1013 If the peers certificate fails any of these checks, the connection 1014 attempt is aborted and an error logged (with throttling). 1016 6.7. Security Association protocols 1018 The following sections define the security association protocols that 1019 we consider to be important and feasible to specify in this document: 1021 6.7.1. ACP via IKEv2 1023 An autonomic device announces its ability to support IKEv2 as the ACP 1024 secure channel protcol in GRASP as "IKEv2". 1026 6.7.1.1. Native IPsec 1028 To run ACP via IPsec transport mode, no further IANA assignments/ 1029 definitions are required. All autonomic devices supporting IPsec 1030 MUST support IPsec security setup via IKEv2, transport mode 1031 encapsulation via the device and peer link-local IPv6 addresses, 1032 AES256 encryption and SHA256 hash. 1034 In terms of IKEv2, this means the initiator will offer to support 1035 IPsec transport mode with next protocol equal 41 (IPv6). 1037 6.7.1.2. IPsec with GRE encapsulation 1039 In network devices it is often easier to provide virtual interfaces 1040 on top of GRE encapsulation than natively on top of a simple IPsec 1041 association. On those devices it may be necessary to run the ACP 1042 secure channel on top of a GRE connection protected by the IPsec 1043 association. The requirements for the IPsec association are the same 1044 as in the native IPsec case, but instead of directly carrying the ACP 1045 IPv6 packets, the payload is an ACP IPv6 packet inside GRE/IPv6. The 1046 mandatory security profile is the same as for native IPsec: peer 1047 link-local IPv6 addresses, AES256 encryption, SHA256 hash. 1049 In terms of IKEv2 negotiation, this means the initiator must offer to 1050 support IPsec transport mode with next protocol equal to GRE (47), 1051 followed by 41 (IPv6) (because native IPsec is required to be 1052 supported, see below). 1054 If IKEv2 initiator and responder support GRE, it will be selected. 1055 The version of GRE to be used must the according to [RFC7676]. 1057 6.7.2. ACP via dTLS 1059 We define the use of ACP via dTLS in the assumption that it is likely 1060 the first transport encryption code basis supported in some classes 1061 of constrained devices. 1063 To run ACP via UDP and dTLS v1.2 [RFC6347] a locally assigned UDP 1064 port is used that is announced as a parameter in the GRASP AN_ACP 1065 objective to candidate neighbors. All autonomic devices supporting 1066 ACP via dTLS MUST support AES256 encryption and not permit weaker 1067 crypto options. 1069 There is no additional session setup or other security association 1070 besides this simple dTLS setup. As soon as the dTLS session is 1071 functional, the ACP peers will exchange ACP IPv6 packets as the 1072 payload of the dTLS transport connection. Any dTLS defined security 1073 association mechanisms such as re-keying are used as they would be 1074 for any transport application relying solely on dTLS. 1076 6.7.3. ACP Secure Channel Requirements 1078 A baseline autonomic device MUST support IPsec natively and MAY 1079 support IPsec via GRE. A constrained autonomic device MUST support 1080 dTLS. Autonomic edge device connecting constrained areas with 1081 baseline areas MUST therefore support IPsec and dTLS. 1083 Autonomic devices need to specify in documentation the set of secure 1084 ACP mechanisms they suppport. 1086 ACP secure channel MUST imediately be terminated when the lifetime of 1087 any certificate in the chain used to authenticate the neighbor 1088 expires or becomes revoked. Note that is is not standard behavior in 1089 secure channel protocols such as IPsec because the certificate 1090 authentication only influences the setup of the secure channel in 1091 these protocols. 1093 6.8. GRASP in the ACP 1095 6.8.1. GRASP as a core service of the ACP 1097 The ACP MUST run an instance of GRASP inside of it. It is a key part 1098 of the ACP services. They function in GRASP that makes it 1099 fundamental as a service is the ability for ACP wide service 1100 discovery (called objectives in GRASP). In most other solution 1101 designs such distributed discovery does not exist at all or it was 1102 added as an afterthought and relied upon inconsistently resulting in 1103 diminished self configuration capabilities. of prior solutions. 1105 The ACP does not provide generic IP multicast services, but only IP 1106 unicast which is realized via the RPL routing protocol (described 1107 below) and objective discovery and negotiation realized via the ACP 1108 instance of GRASP. We consider this to be a more lightweight, 1109 modular and easier to extend approach than trying to put service 1110 announcement and discovery onto some autoconfigured network wide IP 1111 multicast layer (for which so far there is no good definition) or 1112 embed it into some IGP flooding mechanism (which makes it less 1113 modular and agile to improve upon). 1115 6.8.2. ACP as the Security and Transport substrate for GRASP 1117 In the terminology of GRASP ([I-D.ietf-anima-grasp]), the ACP is the 1118 security and transport substrate for the GRASP instance run inside 1119 the ACP. 1121 This means that the ACP is responsible to ensure that this instance 1122 of GRASP is only using the ACP virtual interfaces. Whenever the ACP 1123 adds or deletes such an interface (because of new ACP secure channels 1124 or loss thereof), the ACP needs to indicate this to the ACP instance 1125 of GRASP. The ACP exists also in the absence of any active ACP 1126 neighbors. It is created when the device has a domain certificate. 1127 In this case ASAs using GRASP running on the same device would still 1128 need to be able to discover each others objectives. When the ACP 1129 does not exist ASAs leveraging the ACP instance of GRASP via APIs 1130 MUST still be able to operate, and MUST be able to understand that 1131 there is no ACP and that therefore the ACP instance of GRASP can not 1132 provide services. 1134 GRASP inside the ACP uses link-local UDP IPv6 multicast across the 1135 ACP virtual interfaces for GRASP neighbor discovery and IPv6 over TLS 1136 across the ACP virtual interfaces for any of its unicast messages. 1137 TLS is TLS 1.2 ([RFC5246]) with AES256 encryption and SHA256. 1138 Authentication is via the the domain certificates on both sides. 1140 TLS is mandated for GRASP because the ACP secure channel mandatory 1141 authentication and encryption protects only against attacks from the 1142 outside but not against attacks from the inside - compromised ACP 1143 members that have (not yet) been detected and removed (eg: via domain 1144 certificate revocation / expiry). 1146 Eavesdropping/spoofing by a compromised ACP device is possible 1147 because the provider and consumer of an objective have no unique 1148 information about the other side that would allow them to distinguish 1149 a benevolent from a compromised peer. The compromised ACP device 1150 would simply announce the objective as well, potentially filter the 1151 original objective in GRASP when it is a Man In The Middle (MITM) and 1152 act as an application level proxy. This of course requires that the 1153 compromised ACP node understand the semantic of the GRASP negotiation 1154 to an extend that allows it to proxy it without being detected. 1156 6.9. Context Separation 1158 The ACP is in a separate context from the normal data plane of the 1159 device. This context includes the ACP channels IPv6 forwarding and 1160 routing as well as any required higher layer ACP functions. 1162 In classical network device platforms, a dedicated so called "Virtual 1163 routing and forwarding instance" (VRF) is one logical implementation 1164 option for the ACP. If possible by the platform SW architecture, 1165 separation options that minimize shared components are preferred, 1166 such as a logical container or virtual machine instance. The context 1167 for the ACP needs to be established automatically during bootstrap of 1168 a device. As much as possible it should be protected from being 1169 modified unintentionally by data plane configuration. 1171 Context separation improves security, because the ACP is not 1172 reachable from the global routing table. Also, configuration errors 1173 from the data plane setup do not affect the ACP. 1175 6.10. Addressing inside the ACP 1177 The channels explained above typically only establish communication 1178 between two adjacent nodes. In order for communication to happen 1179 across multiple hops, the autonomic control plane requires internal 1180 network wide valid addresses and routing. Each autonomic node must 1181 create a virtual interface with a network wide unique address inside 1182 the ACP context mentioned in Section 6.9. This address may be used 1183 also in other virtual contexts. 1185 With the algorithm introduced here, all ACP devices in the same 1186 subdomain have the same /48 prefix. Conversely, global IDs from 1187 different domains are unlikely to clash, such that two networks can 1188 be merged, as long as the policy allows that merge. See also 1189 Section 9.1 for a discussion on merging domains. 1191 Links inside the ACP only use link-local IPv6 addressing, such that 1192 each node only requires one routable virtual address. 1194 6.10.1. Fundamental Concepts of Autonomic Addressing 1196 o Usage: Autonomic addresses are exclusively used for self- 1197 management functions inside a trusted domain. They are not used 1198 for user traffic. Communications with entities outside the 1199 trusted domain use another address space, for example normally 1200 managed routable address space (called "Data Plane" in this 1201 document). 1203 o Separation: Autonomic address space is used separately from user 1204 address space and other address realms. This supports the 1205 robustness requirement. 1207 o Loopback-only: Only loopback interfaces of autonomic nodes carry 1208 routable address(es); all other interfaces exclusively use IPv6 1209 link local for autonomic functions. The usage of IPv6 link local 1210 addressing is discussed in [RFC7404]. 1212 o Use-ULA: For loopback interfaces of autonomic nodes, we use Unique 1213 Local Addresses (ULA), as specified in [RFC4193]. An alternative 1214 scheme was discussed, using assigned ULA addressing. The 1215 consensus was to use ULA-random [[RFC4193] with L=1], because it 1216 was deemed to be sufficient. 1218 o No external connectivity: They do not provide access to the 1219 Internet. If a node requires further reaching connectivity, it 1220 should use another, traditionally managed address scheme in 1221 parallel. 1223 o Addresses in the ACP are permanent, and do not support temporary 1224 addresses as defined in [RFC4941]. 1226 The ACP is based exclusively on IPv6 addressing, for a variety of 1227 reasons: 1229 o Simplicity, reliability and scale: If other network layer 1230 protocols were supported, each would have to have its own set of 1231 security associations, routing table and process, etc. 1233 o Autonomic functions do not require IPv4: Autonomic functions and 1234 autonomic service agents are new concepts. They can be 1235 exclusively built on IPv6 from day one. There is no need for 1236 backward compatibility. 1238 o OAM protocols no not require IPv4: The ACP may carry OAM 1239 protocols. All relevant protocols (SNMP, TFTP, SSH, SCP, Radius, 1240 Diameter, ...) are available in IPv6. 1242 6.10.2. The ACP Addressing Base Scheme 1244 The Base ULA addressing scheme for autonomic nodes has the following 1245 format: 1247 8 40 2 78 1248 +--+-----------------+------+--------------------------------------+ 1249 |FD| hash(subdomain) | Type | (sub-scheme) | 1250 +--+-----------------+------+--------------------------------------+ 1252 Figure 2: ACP Addressing Base Scheme 1254 The first 48 bits follow the ULA scheme, as defined in [RFC4193], to 1255 which a type field is added: 1257 o "FD" identifies a locally defined ULA address. 1259 o The ULA "global ID" is set here to be a hash of the subdomain 1260 name, which results in a pseudo-random 40 bit value. It is 1261 calculated as the first 40 bits of the SHA256 hash of the 1262 subdomain name, in the example of Section 6.1.1 1263 "area51.research.acp.example.com". 1265 o To allow for extensibility, the fact that the ULA "global ID" is a 1266 hash of the subdomain name SHOULD NOT be assumed by any autonomic 1267 device during normal operations. The hash function is only 1268 executed during the creation of the certificate. If BRSKI is used 1269 then the registrar will create the ACP information field in 1270 response to the CSR Attribute Request by the pledge. 1272 o Type: This field allows different address sub-schemes in the 1273 future. The goal is to start with a single sub-schemes, but to 1274 allow for extensions later if and when required. This addresses 1275 the "upgradability" requirement. Assignment of types for this 1276 field should be maintained by IANA. 1278 6.10.3. ACP Zone Addressing Sub-Scheme 1280 The sub-scheme defined here is defined by the Type value 00b (zero) 1281 in the base scheme. 1283 64 64 1284 +-----------------+---------+---++-----------------------------+---+ 1285 | (base scheme) | Zone-ID | Z || Device-ID | 1286 | | | || Registrar-ID | Device-Number| V | 1287 +-----------------+---------+---++--------------+--------------+---+ 1288 50 13 1 48 15 1 1290 Figure 3: ACP Zone Addressing Sub-Scheme 1292 The fields are defined as follows: 1294 o Zone-ID: If set to all zero bits: The Device-ID bits are used as 1295 an identifier (as opposed to a locator). This results in a non- 1296 hierarchical, flat addressing scheme. Any other value indicates a 1297 zone. See section Section 6.10.3.1 on how this field is used in 1298 detail. 1300 o Z: MUST be 0. 1302 o Device-ID: A unique value for each device. 1304 The 64 bit Device-ID is derived and composed as follows: 1306 o Registrar-ID (48 bit): A number unique inside the domain that 1307 identifies the registrar which assigned the Device-ID to the 1308 device. A MAC address of the registrar can be used for this 1309 purpose. 1311 o Device-Number (Device-Number): A number which is unique for a 1312 given registrar, to identify the device. This can be a 1313 sequentially assigned number. 1315 o V (1 bit): Virtualization bit: 0: Indicates the ACP itself 1316 ("autonomic node base system); 1: Indicates the optional "host" 1317 context on the ACP device (see below). 1319 When referring to the Device-ID of an ACP device overall, the V 1320 bit(s) is/are always "0". This is also the address used in the ACP 1321 information in the domain certificate. The V bit(s) identify the 1322 bits the device can assign itself. The Device knows how many bits 1323 those are from the addressing sub-scheme (see below for a Sub-Scheme 1324 with more than one V-bit). 1326 The "Device-ID" itself is unique in a domain (i.e., the Zone-ID is 1327 not required for uniqueness). Therefore, a device can be addressed 1328 either as part of a flat hierarchy (zone ID = 0), or with an 1329 aggregation scheme (any other zone ID). A address with zone-ID = 0 1330 is an identifier, with another zone-ID as a locator. See 1331 Section 6.10.3.1 for a description of the zone bits. 1333 The Virtual bit in this sub-scheme allows to easily add the ACP as a 1334 component to existing systems without causing problems in the port 1335 number space between the services in the ACP and the existing system. 1336 V:0 is the ACP router (autonomous node base system), V:1 is the host 1337 with pre-existing transport endpoints on it that could collide with 1338 the transport endpoints used by the ACP router. The ACP host could 1339 for example have a virtual p2p interface with the V:0 address as its 1340 router into the ACP. Depending on the SW design of ASA (outside the 1341 scope of this specification), they may use the V:0 or V:1 address. 1343 The location of the V bit(s) at the end of the address allows to 1344 announce a single prefix for each autonomic node. For example, in a 1345 network with 20,000 ACP devices, this avoid 20,000 additional routes 1346 in the routing table. 1348 6.10.3.1. Usage of the Zone Field 1350 The "Zone-ID" allows for the introduction of structure in the 1351 addressing scheme. 1353 Zone = zero is the default addressing scheme in an autonomic domain. 1354 Every autonomic node MUST respond to its ACP address with zone=0. 1355 Used on its own this leads to a non-hierarchical address scheme, 1356 which is suitable for networks up to a certain size. In this case, 1357 the addresses primarily act as identifiers for the nodes, and 1358 aggregation is not possible. 1360 If aggregation is required, the 13 bit value allows for up to 8192 1361 zones. The allocation of zone numbers may either happen 1362 automatically through a to-be-defined algorithm; or it could be 1363 configured and maintained manually. 1365 If a device learns through an autonomic method or through 1366 configuration that it is part of a zone, it MUST also respond to its 1367 ACP address with that zone number. In this case the ACP loopback is 1368 configured with two ACP addresses: One for zone 0 and one for the 1369 assigned zone. This method allows for a smooth transition between a 1370 flat addressing scheme and an hierarchical one. 1372 (Theoretically, the 13 bits for the Zone-ID would allow also for two 1373 levels of zones, introducing a sub-hierarchy. We do not think this 1374 is required at this point, but a new type could be used in the future 1375 to support such a scheme.) 1376 Note: The Zone-ID is one method to introduce structure or hierarchy 1377 into the ACP. Another way is the use of the routing subdomain field 1378 in the ACP that leads to different /40 ULA prefixes within an 1379 autonomic domain. This gives followup work two options to consider. 1381 6.10.4. ACP Manual Addressing Sub-Scheme 1383 The sub-scheme defined here is defined by the Type value 00b (zero) 1384 in the base scheme. 1386 64 64 1387 +---------------------+---------+---++-----------------------------+ 1388 | (base scheme) |Subnet-ID| Z || Interface Identifier | 1389 +---------------------+---------+---++-----------------------------+ 1390 50 13 1 1392 Figure 4: ACP Manual Addressing Sub-Scheme 1394 The fields are defined as follows: 1396 o Subnet-ID: Configured subnet identifier. 1398 o Z: MUST be 1. 1400 o Interface Identifier. 1402 This sub-scheme is meant for "manual" allocation to subnets where the 1403 other addressing schemes can not be used. The primary use case is 1404 for assignment to ACP connect subnets (see Section 8.1.1). 1406 "Manual" means that allocations of the Subnet-ID need to be done 1407 today with pre-existing, non-autonomic mechanisms. Every subnet that 1408 uses this addressing sub-scheme needs to use a unique Subnet-ID 1409 (unless some anycast setup is done). Future work may define 1410 mechanisms for auto-coordination between ACP devices and auto- 1411 allocation of Subnet-IDs between them. 1413 The Z field is following the Subnet-ID field so that future work 1414 could allocate/coordinate both Zone-ID and Subnet-ID consistently and 1415 use an integrated aggregateable routing approach across them. Z=0 1416 (Zone sub-scheme) would then be used for network wide unique, 1417 registrar assigned (and certificate protected) Device-IDs primarily 1418 for ACP devices while Z=1 would be used for device-level assigned 1419 Interface Identifiers primarily for non-ACP-devices. 1421 6.10.5. ACP Vlong Addressing Sub-Scheme 1423 The sub-scheme defined here is defined by the Type value 01b (one) in 1424 the base scheme. 1426 50 78 1427 +---------------------++-----------------------------+----------+ 1428 | (base scheme) || Device-ID | 1429 | || Registrar-ID | Device-Number| V | 1430 +---------------------++--------------+--------------+----------+ 1431 46 33/17 8/16 1433 Figure 5: ACP Vlong Addressing Sub-Scheme 1435 This addressing scheme foregoes the Zone field to allow for larger, 1436 flatter routed networks (eg: as in IoT) with more than 2^32 Device- 1437 Numbers. It also allows for up to 2^16 - 65536 different virtualized 1438 adddresses, which could be used to address individual software 1439 components in an ACP device. 1441 The fields are the same as in the Zone sub-scheme with the following 1442 refinements: 1444 o V: Virtualization bit: Values 0 and 1 as in Zone sub-scheme, 1445 further values use via definition in followup work. 1447 o Registrar-ID: To maximize Device-Number and V, the Registrar-ID is 1448 reduced to 46 bits. This still allows to use the MAC address of a 1449 registrar by removing the V and U bits from the 48 bits of a MAC 1450 address (those two bits are never unique, so they can not be used 1451 to distinguish MAC addresses). 1453 o If the first bit of the "Device-Number" is "1", then the Device 1454 number is 17 bit long and the V field is 16 bit long. Otherwise 1455 the Device-Number is 33 bit long and the V field is 8 bit long. 1456 "0" bit Device-Numbers are intended to be used for "general 1457 purpose" ACP devices that would potentially have a limited number 1458 (< 256) of internal users of the ACP that require separate 1459 V(irtual) addresses. "1" bit Device-Numbers are intended for ACP 1460 devices that are ACP edge devices (see Section 8.1.1) or that have 1461 a large number of internal ACP users requiring separate V(irtual) 1462 addresses. For example large SDN controllers with container 1463 modular software architecture (see Section 8.1.2). 1465 6.10.6. Other ACP Addressing Sub-Schemes 1467 Other ACP addressing sub-schemes can be defined if and when required. 1468 IANA would need to assign a new "type" for each new addressing sub- 1469 scheme. With the current allocations, 5 more schemes are possible 1470 without further reducing the number of bits in a future scheme. 1472 6.11. Routing in the ACP 1474 Once ULA address are set up all autonomic entities should run a 1475 routing protocol within the autonomic control plane context. This 1476 routing protocol distributes the ULA created in the previous section 1477 for reachability. The use of the autonomic control plane specific 1478 context eliminates the probable clash with the global routing table 1479 and also secures the ACP from interference from the configuration 1480 mismatch or incorrect routing updates. 1482 The establishment of the routing plane and its parameters are 1483 automatic and strictly within the confines of the autonomic control 1484 plane. Therefore, no manual configuration is required. 1486 All routing updates are automatically secured in transit as the 1487 channels of the autonomic control plane are by default secured, and 1488 this routing runs only inside the ACP. 1490 The routing protocol inside the ACP is RPL ([RFC6550]). See 1491 Section 10.3 for more details on the choice of RPL. 1493 RPL adjacencies are set up across all ACP channels in the same domain 1494 including all its routing subdomains. See Section 10.5 for more 1495 details. 1497 6.11.1. RPL Profile 1499 The following is a description of the RPL profile that ACP nodes need 1500 to support by default. The format of this section is derived from 1501 draft-ietf-roll-applicability-template. 1503 6.11.1.1. Summary 1505 In summary, the profile chosen for RPL is one that expects a fairly 1506 reliable network reasonable fast links so that RPL convergence will 1507 be triggered immediately upon recognition of link failure/recovery. 1509 The key limitation of the chosen profile is that it is designed to 1510 not require any dataplane artifacts (such as [RFC6553]). While the 1511 senders/receivers of ACP packets can be legacy NOC devices connected 1512 via "ACP connect" (see Section 8.1.1 to the ACP, their connectivity 1513 can be handled as non-RPL-aware leafs (or "Internet") accoding to the 1514 dataplane architecture explained in [I-D.ietf-roll-useofrplinfo]. 1515 This non-artifact profile is largely driven by the desire to avoid 1516 introducing the required Hop-by-Hop headers into the ACP VRF control 1517 plane. Many devices will have their VRF forwarding code designed 1518 into silicon. 1520 In this profile choice, RPL has no dataplane artifacts. A simple 1521 destination prefix based upon the routing table is used. A 1522 consequence of supporting only a single instanceID (containing one 1523 DODAG), the ACP will only accomodate only a single class of routing 1524 table and can not create optimized routing paths to accomplish 1525 latency or energy goals. 1527 Consider a network that has multiple NOCs in different locations. 1528 Only one NOC will become the DODAG root. Other NOCs will have to 1529 send traffic through the DODAG (tree) rooted in the primary NOC. 1530 Depending on topology, this can be an annoyance from a latency point 1531 of view, but it does not represent a single point of failure, as the 1532 DODAG can reconfigure itself when it detects data plane forwarding 1533 failures. 1535 The lack of a RPI (the header defined by [RFC6553]), means that the 1536 dataplane will have no rank value that can be used to detect loops. 1537 As a result, traffic may loop until the TTL of the packet reaches 1538 zero. This the same behavior as that of other IGPs that do not have 1539 the data plane options as RPPL. There are a variety of heuristics 1540 that can be used to signal from the data plane to the RPL control 1541 plane that a new route is needed. 1543 Additionally, failed ACP tunnels will be detected by IKEv2 Dead Peer 1544 Detection (which can function as a replacement for an LLN's ETX). A 1545 failure of an ACP tunnel should signal the RPL control plane to pick 1546 a different parent. 1548 Future Extensions to this RPL profile can provide optimality for 1549 multiple NOCs. This requires utilizing data plane artifact including 1550 IPinIP encap/decap on ACP routers and processing of IPv6 RPI headers. 1551 Alternatively (Src,Dst) routing table entries could be used. A 1552 decision for the preferred technology would have to be done when such 1553 extension is defined. 1555 6.11.1.2. RPL Instances 1557 Single RPL instance. Default RPLInstanceID = 0. 1559 6.11.1.3. Storing vs. Non-Storing Mode 1561 RPL Mode of Operations (MOP): mode 3 "Storing Mode of Operations with 1562 multicast support". Implementations should support also other modes. 1563 Note: Root indicates mode in DIO flow. 1565 6.11.1.4. DAO Policy 1567 Proactive, aggressive DAO state maintenance: 1569 o Use K-flag in unsolicited DAO indicating change from previous 1570 information (to require DAO-ACK). 1572 o Retry such DAO DAO-RETRIES(3) times with DAO- ACK_TIME_OUT(256ms) 1573 in between. 1575 6.11.1.5. Path Metric 1577 Hopcount. 1579 6.11.1.6. Objective Function 1581 Objective Function (OF): Use OF0 [RFC6552]. No use of metric 1582 containers. 1584 rank_factor: Derived from link speed: <= 100Mbps: 1585 LOW_SPEED_FACTOR(5), else HIGH_SPEED_FACTOR(1) 1587 6.11.1.7. DODAG Repair 1589 Global Repair: we assume stable links and ranks (metrics), so no need 1590 to periodically rebuild DODAG. DODAG version only incremented under 1591 catastrophic events (eg: administrative action). 1593 Local Repair: As soon as link breakage is detected, send No-Path DAO 1594 for all the targets that where reachable only via this link. As soon 1595 as link repair is detected, validate if this link provides you a 1596 better parent. If so, compute your new rank, and send new DIO that 1597 advertises your new rank. Then send a DAO with a new path sequence 1598 about yourself. 1600 stretch_rank: none provided ("not stretched"). 1602 Data Path Validation: Not used. 1604 Trickle: Not used. 1606 6.11.1.8. Multicast 1608 Not used yet but possible because of the seleced mode of operations. 1610 6.11.1.9. Security 1612 [RFC6550] security not used, substituted by ACP security. 1614 6.11.1.10. P2P communications 1616 Not used. 1618 6.11.1.11. IPv6 address configuration 1620 Every ACP device (RPL node) announces an IPv6 prefix covering the 1621 address(es) used internally in the ACP device. The prefix length 1622 depends on the choosen addressing sub-scheme of the ACP address 1623 provisioned into the certificate of the ACP device, eg: /127 for Zone 1624 addressing sub-scheme or /112 or /120 for Vlong addressing sub- 1625 scheme. See Section 6.10 for more details. 1627 Every ACP device MUST install a blackhole (aka null route) route for 1628 whatever ACP address space that it advertises (i.e: the /96 or /127). 1629 This is avoid routing loops for addresses that an ACP node has not 1630 (yet) used. 1632 6.11.1.12. Administrative parameters 1634 Administrative Preference ([RFC6552], 3.2.6 - to become root): 1635 Indicated in DODAGPreference field of DIO message. 1637 o Explicit configured "root": 0b100 1639 o Registrar (Default): 0b011 1641 o AN-connect (non registrar): 0b010 1643 o Default: 0b001. 1645 6.11.1.13. RPL Dataplane artifacts 1647 RPI (RPL Packet Information [RFC6553]): Not used as there is only a 1648 single instance, and data path validation is not being used. 1650 SRH (RPL Source Routing - RFC6552): Not used. Storing mode is being 1651 used. 1653 6.11.1.14. Unknown Destinations 1655 Because RPL minimizes the size of the routing and forwarding table, 1656 prefixes reachable through the same interface as the RPL root are not 1657 known on every ACP device. Therefore traffic to unknown destination 1658 addresses can only be discovered at the RPL root. The RPL root 1659 SHOULD have attach safe mechanisms to operationally discover and log 1660 such packets. 1662 6.12. General ACP Considerations 1664 Since channels are by default established between adjacent neighbors, 1665 the resulting overlay network does hop by hop encryption. Each node 1666 decrypts incoming traffic from the ACP, and encrypts outgoing traffic 1667 to its neighbors in the ACP. Routing is discussed in Section 6.11. 1669 6.12.1. Addressing of Secure Channels in the data plane 1671 In order to be independent of the Data Plane configuration of global 1672 IPv6 subnet addresses (that may not exist when the ACP is brought 1673 up), Link-local secure channels MUST use IPv6 link local addresses 1674 between adjacent neighbors. The fully autonomic mechanisms in this 1675 document only specify these link-local secure channels.Section 8.2 1676 specify extensions in which secure channels are tunnels, then this 1677 requirement does not apply. 1679 The Link-local secure channels specified in this document therefore 1680 depend on basic IPv6 link-local functionality to be auto-enabled by 1681 the ACP and prohibiting the Data Plane from disabling it. The ACP 1682 also depends on being able to operate the secure channel protocol 1683 (eg: IPsec / dTLS) across IPv6 link-local addresses, something that 1684 may be an uncommon profile. Functionaly, these are the only 1685 interactions with the Data Plane that the ACP needs to have. 1687 To mitigate these interactions with the Data Plane, extensions to 1688 this document may specify additional layer 2 or layer encapsulations 1689 for ACP secure channels as well as other protocols to auto-discover 1690 peer endpoints for such encapsulations (eg: tunneling across L3 or 1691 use of L2 only encapsulations). 1693 6.12.2. MTU 1695 The MTU for ACP secure channels must be derived locally from the 1696 underlying link MTU minus the secure channel encapsulation overhead. 1698 ACP secure Channel protocols do not need to perform MTU discovery 1699 because they are built across L2 adjacencies - the MTU on both sides 1700 connecting to the L2 connection are assumed to be consistent. 1702 Extensions to ACP where the ACP is for example tunneled need to 1703 consider how to guarantee MTU consistency. This is a standard issue 1704 with tunneling, not specific to running the ACP across it. Transport 1705 stacks running across ACP can perform normal PMTUD (Path MTU 1706 Discovery). Because the ACP is meant to be prioritize reliability 1707 over performance, they MAY opt to only expect IPv6 minimum MTU (1280) 1708 to avoid running into PMTUD implementation bugs or underlying link 1709 MTU mismatch problems. 1711 6.12.3. Multiple links between nodes 1713 If two nodes are connected via several links, the ACP SHOULD be 1714 established across every link, but it is possible to establish the 1715 ACP only on a sub-set of links. Having an ACP channel on every link 1716 has a number of advantages, for example it allows for a faster 1717 failover in case of link failure, and it reflects the physical 1718 topology more closely. Using a subset of links (for example, a 1719 single link), reduces resource consumption on the devices, because 1720 state needs to be kept per ACP channel. The negotiation scheme 1721 explained in Section 6.5 allows Alice (the node with the higher ACP 1722 address) to drop all but the desired ACP channels to Bob - and Bob 1723 will not re-try to build these secure channels from his side unless 1724 Alice shows up with a previously unknown GRASP announcement (eg: on a 1725 different link or with a different address announced in GRASP). 1727 6.12.4. ACP interfaces 1729 The ACP VRF has conceptually two type of interfaces: The ACP loopback 1730 interface(s) to which the ACP ULA address(es) are assigned and the 1731 "ACP virtual interfaces" that are mapped to the ACP secure channels. 1733 The term loopback interface is commonly referred to internal pseudo 1734 interfaces through which the device can only reach itself. In 1735 network devices these interfaces are used to hold addresses used by 1736 the transport stack of the system when an address should be reliable 1737 reachable in the presence of arbitrary link failures. As long as 1738 addresses on a loopback interface are routeable in the routing 1739 protocol used, they will be reachable as long as there is at least 1740 one working network path. This is opposed to routeable address 1741 assigned to an externally connected interface. That address will 1742 become unreachable when that interface goes down. For this reason, 1743 the ACP (ULA) address(es) are assigned to loopback type interface. 1745 ACP secure channels, eg: IPsec, dTLS or other future security 1746 associations with neighboring ACP devices can be mapped to ACP 1747 virtual interfaces in different ways: In one case, every ACP secure 1748 channel is mapped into a separate point-to-point ACP virtual 1749 interface. If a physical subnet has more than two ACP capable nodes 1750 (in the same domain), this implementation approach will lead to a 1751 full mesh of ACP virtual interfaces between them. In a more advanced 1752 implementation approach, the ACP will construct a single multi-access 1753 ACP virtual interface for all ACP secure channels to ACP capable 1754 nodes reachable across the same physical subnet. The multi-access 1755 ACP virtual interace needs to replicate link-local IPv6 multicast 1756 packets sent into the interface towards all ACP secure channels 1757 mapped into it. There is no need for all ACP capable nodes on the 1758 same physical multi-access subnet to agree on a common implementation 1759 approach. This is purely a node local decision. 1761 Multi-access ACP virtual interfaces are preferrable because they do 1762 reflect the presence of a multi-access physical networks into the 1763 virtual interfaces of the ACP. This makes it for example simpler to 1764 build services with topology awareness inside the ACP VRF in the same 1765 way as they could habe been built running natively on the multi- 1766 access interfaces. One example is the efficiency of flooding of 1767 GRASP messages. Assume such a LAN with three ACP neighbors, Alice 1768 Bob and Carol. Alice sends a GRASP link-local multicast message to 1769 Bob and Carol. If Alices ACP emulates the LAN as one point-to-point 1770 interface to Bob and one to Carol, GRASP itself will send two copies, 1771 if Alices ACP emulates a LAN, GRASP will send one packet and the ACP 1772 will replicate it. The result is the same. The difference happens 1773 when Bob and Carol receive their packet. If they use point-to-point 1774 ACP virtual interfaces, their GRASP instance would forward the packet 1775 from Alice to each other as part of the GRASP flooding procedure. 1776 These packets are of course redundant (unnecessary) and would be 1777 discarded by GRASP on receipt as duplicates. If Bob and Charlies ACP 1778 would emulate a LAN, then this would not happen, because GRASPs 1779 flooding procedure does not send bac packets to the interface they 1780 where received from. 1782 For this reason, the ACP SHOULD map ACP secure channels on multi- 1783 access LANs into multi-access ACP virtual interfaces. 1785 Care must be taken when creating multi-access ACP virtual interfaces 1786 across ACP secure channels between ACP devices in different domains 1787 or routing subdomains. The policies to be negotiated may be 1788 described as peer-to-peer policies in which case it is easier to 1789 create point-to-point ACP virtual interfaces for these secure 1790 channels. 1792 7. ACP support on L2 switches/ports (Normative) 1793 7.1. Why 1795 ANrtr1 ------ ANswitch1 --- ANswitch2 ------- ANrtr2 1796 .../ \ \ ... 1797 ANrtrM ------ \ ------- ANrtrN 1798 ANswitchM ... 1800 Figure 6 1802 Consider a large L2 LAN with ANrtr1...ANrtrN connected via some 1803 topology of L2 switches. Examples include large enterprise campus 1804 networks with an L2 core, IoT networks or broadband aggregation 1805 networks which often have even a multi-level L2 switched topology. 1807 If the discovery protocol used for the ACP is operating at the subnet 1808 level, every AN router will see all other AN routers on the LAN as 1809 neighbors and a full mesh of ACP channels will be built. If some or 1810 all of the AN switches are autonomic with the same discovery 1811 protocol, then the full mesh would include those switches as well. 1813 A full mesh of ACP connections like this can creates fundamental 1814 scale challenges. The number of security associations of the secure 1815 channel protocols will likely not scale arbitrarily, especially when 1816 they leverage platform accelerated encryption/decryption. Likewise, 1817 any other ACP operations (such as routing) needs to scale to the 1818 number of direct ACP neigbors. An AN router with just 4 interfaces 1819 might be deployed into a LAN with hundreds of neighbors connected via 1820 switches. Introducing such a new unpredictable scaling factor 1821 requirement makes it harder to support the ACP on arbitrary platforms 1822 and in arbitrary deployments. 1824 Predictable scaling requirements for ACP neighbors can most easily be 1825 achieved if in topologies like these, AN capable L2 switches can 1826 ensure that discovery messages terminate on them so that neighboring 1827 AN routers and switches will only find the physically connected AN L2 1828 switches as their candidate ACP neighbors. With such a discovery 1829 mechanism in place, the ACP and its security associations will only 1830 need to scale to the number of physical interfaces instead of a 1831 potentially much larger number of "LAN-connected" neighbors. And the 1832 ACP topology will follow directly the physical topology, something 1833 which can then also be leveraged in management operations or by ASAs. 1835 In the example above, consider ANswitch1 and ANswitchM are AN 1836 capable, and ANswitch2 is not AN capable. The desired ACP topology 1837 is therefore that ANrtr1 and ANrtrM only have an ACP connetion to 1838 ANswitch1, and that ANswitch1, ANrtr2, ANrtrN have a full mesh of ACP 1839 connection amongst each other. ANswitch1 also has an ACP connection 1840 with ANswitchM and ANswitchM has ACP connections to anything else 1841 behind it. 1843 7.2. How (per L2 port DULL GRASP) 1845 To support ACP on L2 switches or L2 switches ports of an L3 device, 1846 it is necessary to to make those L2 ports look like L3 interfaces for 1847 the ACP implementation. This primarily involves the creation of a 1848 separate DULL GRASP instance/domain on every such L2 port. Because 1849 GRASP has a dedicated IPv6 link-local multicast address, it is 1850 sufficient that all ethernet packets for this address are being 1851 extracted at the port level and passed to that DULL GRASP instance. 1852 Likewise the IPv6 link-local multicast packets sent by that DULL 1853 GRASP instance need to be sent only towards the L2 port for this DULL 1854 GRASP instance. 1856 The rest of ACP operations can operate in the same way as in L3 1857 devices: Assume for example that the device is an L3/L2 hybrid device 1858 where L3 interfaces are assigned to VLANs and each VLAN has 1859 potentially multiple ports. DULL GRASP is run as described 1860 individually on each L2 port. When it discovers a candidate ACP 1861 neighbor, it passes its IPv6 link-local address and supported secure 1862 channel protocols to the ACP secure channel negotiation that can be 1863 bound to the L3 (VLAN) interface. It will simply use link-local IPv6 1864 multicast packets to the candidate ACP neighbor. Once a secure 1865 channel is established to such a neighbor, the virtual interface to 1866 which this secure channel is mapped should then actually be the L2 1867 port and not the L3 interface to best map the actual physical 1868 topology into the ACP virtual interfaces. See Section 6.12.4 for 1869 more details about how to map secure channels into ACP virtual 1870 interfaces. Note that a single L2 port can still have multiple ACP 1871 neighbors if it connect for example to multiple ACP neighbors via a 1872 non-ACP enabled switch. The per L2 port ACP virtual interface can 1873 threfore still be a multi-access virtual LAN. 1875 For example, in the above picture, ANswitch1 would run separate DULL 1876 GRASP instances on its ports to ANrtr1, ANswitch2 and ANswitchI, even 1877 though all those three ports may be in the data plane in the same 1878 (V)LAN and perfom L2 switching between these ports, ANswitch1 would 1879 perform ACP L3 routing between them. 1881 The description in the previous paragraph was specifically meant to 1882 illustrate that on hybrid L3/L2 devices that are common in 1883 enterprise, IoT and broadband aggregation, there is only the GRASP 1884 packet extraction (by ethernet address) and GRASP link-local 1885 multicast per L2-port packet injection that has to consider L2 ports 1886 at the hardware forwarding level. The remaining operations are 1887 purely ACP control plane and setup of secure channels across the L3 1888 interface. This hopefully makes support for per-L2 port ACP on those 1889 hybrid devices easy. 1891 This L2/L3 optimized approach is subject to "address stealing", eg: 1892 where a device on one port uses addresses of a device on another 1893 port. This is a generic issue in L2 LANs and switches often already 1894 have some form of "port security" to prohibit this. They rely on NDP 1895 or DHCP learning of which port/MAC-address and IPv6 address belong 1896 together and block duplicates. This type of function needs to be 1897 enabled to prohibit DoS attacks. Likewise the GRASP DULL instance 1898 needs to ensure that the IPv6 address in the locator-option matches 1899 the source IPv6 address of the DULL GRASP packet. 1901 In devices without such a mix of L2 port/interfaces and L3 interfaces 1902 (to terminate any transport layer connections), implementation 1903 details will differ. Logically most simply every L2 port is 1904 considered and used as a separate L3 subnet for all ACP operations. 1905 The fact that the ACP only requires IPv6 link-local unicast and 1906 multicast should make support for it on any type of L2 devices as 1907 simple as possible, but the need to support secure channel protocols 1908 may be a limiting factor to supporting ACP on such devices. Future 1909 options such as 802.1ae could improve that situation. 1911 A generic issue with ACP in L2 switched networks is the interaction 1912 with the Spanning Tree Protocol. Ideally, the ACP should be built 1913 also across ports that are blocked in STP so that the ACP does not 1914 depend on STP and can continue to run unaffected across STP topology 1915 changes (where reconvergence can be quite slow). The above described 1916 simple implementation options are not sufficient for this. Instead 1917 they would simply have the ACP run across the active STP topology and 1918 therefore the ACP would equally be interrupted and reconverge with 1919 STP changes. 1921 L3/L2 devices SHOULD support per-L2 port ACP. 1923 8. Support for Non-Autonomic Components (Normative) 1925 8.1. ACP Connect 1927 8.1.1. Non-Autonomic Controller / NMS system 1929 The Autonomic Control Plane can be used by management systems, such 1930 as controllers or network management system (NMS) hosts (henceforth 1931 called simply "NMS hosts"), to connect to devices through it. For 1932 this, an NMS host must have access to the ACP. The ACP is a self- 1933 protecting overlay network, which allows by default access only to 1934 trusted, autonomic systems. Therefore, a traditional, non-autonomic 1935 NMS system does not have access to the ACP by default, just like any 1936 other external device. 1938 If the NMS host is not autonomic, i.e., it does not support autonomic 1939 negotiation of the ACP, then it can be brought into the ACP by 1940 explicit configuration. To support connections to adjacent non- 1941 autonomic nodes, an autonomic node with ACP must support "ACP 1942 connect" (sometimes also connect "autonomic connect"): 1944 "ACP connect" is a function on an autonomic device that is called an 1945 "ACP edge device". With "ACP connect", interfaces on the device can 1946 be configured to be put into the ACP VRF. The ACP is then accessible 1947 to other (NOC) systems on such an interface without those systems 1948 having to support any ACP discovery or ACP channel setup. This is 1949 also called "native" access to the ACP because to those (NOC) systems 1950 the interface looks like a normal network interface (without any 1951 encryption/novel-signaling). 1953 data-plane "native" (no ACP) 1954 . 1955 +--------+ +----------------+ . +-------------+ 1956 | ACP | |ACP Edge Device | . | | 1957 | Device | | | v | | 1958 | |-------|...[ACP VRF]....+-----------------| |+ 1959 | | ^ |. | | NOC Device || 1960 | | . | .[Data Plane]..+-----------------| "NMS hosts" || 1961 | | . | [ VRF ] | . ^ | || 1962 +--------+ . +----------------+ . . +-------------+| 1963 . . . +-------------+ 1964 . . . 1965 data-plane "native" . ACP "native" (unencrypted) 1966 + ACP auto-negotiated . "ACP connect subnet" 1967 and encrypted . 1968 ACP connect interface 1969 eg: "vrf ACP native" (config) 1971 Figure 7: ACP connect 1973 ACP connect has security consequences: All systems and processes 1974 connected via ACP connect have access to all autonomic nodes on the 1975 entire ACP, without further authentication. Thus, the ACP connect 1976 interface and (NOC) systems connected to it must be physically 1977 controlled/secured. For this reason the mechanisms described here do 1978 explicitly not include options to allow for a non-ACP router to be 1979 connected across an ACP connect interface and addresses behind such a 1980 router routed inside the ACP. 1982 An ACP connect interface provides exclusively access to only the ACP. 1983 This is likely insufficient for many NMS hosts. Instead, they would 1984 require a second "data-plane" interface outside the ACP for 1985 connections between the NMS host and administrators, or Internet 1986 based services, or for direct access to the data plane. The document 1987 "Autonomic Network Stable Connectivity" 1988 [I-D.ietf-anima-stable-connectivity] explains in more detail how the 1989 ACP can be integrated in a mixed NOC environment. 1991 The ACP connect interface must be (auto-)configured with an IPv6 1992 address prefix. Is prefix SHOULD be covered by one of the (ULA) 1993 prefix(es) used in the ACP. If using non-autonomic configuration, it 1994 SHOULD use the ACP Manual Addressing Sub-Scheme (Section 6.10.4). It 1995 SHOULD NOT use a prefix that is also routed outside the ACP so that 1996 the addresses clearly indicate whether it is used inside the ACP or 1997 not. 1999 The prefix of ACP connect subnets MUST be distributed by the ACP edge 2000 device into the ACP routing protocol (RPL). The NMS hosts MUST 2001 connect to prefixes in the ACP routing table via its ACP connect 2002 interface. In the simple case where the ACP usesonly one ULA prefix 2003 and all ACP connect subnets have prefixes covered by that ULA prefix, 2004 NMS hosts can rely on [RFC6724] - The NMS host will select the ACP 2005 connect interface because any ACP destination address is best matched 2006 by the address on the ACP connect interface. If the NMS hosts ACP 2007 connect interface uses another prefix or if the ACP uses multiple ULA 2008 prefixes, then the NMS hosts require (static) routes towards the ACP 2009 interface. 2011 ACP Edge Device MUST only forward IPv6 packets received from an ACP 2012 connect interface into the ACP that has an IPv6 address from the ACP 2013 prefix assigned to this interface (sometimes called "RPF filtering"). 2014 This MAY be changed through administrative measures. 2016 To limit the security impact of ACP connect, devices supporting it 2017 SHOULD implement a security mechanism to allow configuration/use of 2018 ACP connect interfaces only on devices explicitly targeted to be 2019 deployed with it (such as those physically secure locations like a 2020 NOC). For example, the certificate of such devices could include an 2021 extension required to permit configuration of ACP connect interfaces. 2022 This prohibits that a random ACP device with easy physical access 2023 that is not meant to run ACP connect could start leaking the ACP when 2024 it becomes compromised and the intruder configures ACP connect on it. 2025 The full workflow including the mechanism by which a registrar would 2026 select which device to give such a certificate to is subject to 2027 future work. 2029 8.1.2. Software Components 2031 The ACP connect mechanism be only be used to connect physically 2032 external systems (NMS hosts) to the ACP but also other applications, 2033 containers or virtual machines. In fact, one possible way to 2034 eliminate the security issue of the external ACP connect interface is 2035 to collocate an ACP edge device and an NMS host by making one a 2036 virtual machine or container inside the other - and therefore 2037 converting the unprotected external ACP subnet into an internal 2038 virtual subnet in a single device. This would ultimately result in a 2039 fully autonomic NMS host with minimum impact to the NMS hosts 2040 software architecture. This approach is not limited to NMS hosts but 2041 could equally be applied to devices consisting of one or more VNF 2042 (virtual network functions): An internal virtual subnet connecting 2043 out-of-band-management interfaces of the VNFs to an ACP edge router 2044 VNF. 2046 The core requirement is that the software components need to have a 2047 network stack that permits access to the ACP and optionally also the 2048 data plane. Like in the physical setup for NMS hosts this can be 2049 realized via two internal virtual subnets. One that is connecting to 2050 the ACP (which could be a container or virtual machine by itself), 2051 and one (or more) connecting into the data plane. 2053 This "internal" use of ACP connect approach should not considered to 2054 be a "workaround" because in this case it is possible to build a 2055 correct security model: It is not necessary to rely on unprovable 2056 external physical security mechanisms as in the case of external NMS 2057 hosts. Instead, the orchestration of the ACP, the virtual subnets 2058 and the software components can be done by trusted software that 2059 could be considered to be part of the ANI (or even an extended ACP). 2060 This software component is responsible to ensure that only trusted 2061 software components will get access to that virtual subnet and that 2062 only even more trusted software components will get access to both 2063 the ACP virtual subnet and the data plane (because those ACP users 2064 could leak traffic between ACP and data plane). This trust could be 2065 established for example through cryptographic means such signed 2066 software packages. The specification of these mechanisms is subject 2067 to future work. 2069 Note that ASA (Autonomic Software Agents) could also be software 2070 components as described in this section, but further details of ASAs 2071 are subject to future work. 2073 8.1.3. Auto Configuration 2075 ACP edge devices, NMS hosts and software components that as describd 2076 in the previous section are meant to be composed via virtual 2077 interfaces SHOULD support on the ACP connect subnet Stateless Address 2078 Autoconfiguration (SLAAC - [RFC4862]) and route autoconfiguration 2079 according to [RFC4191]. 2081 The ACP edge device acts as the router on the ACP connect subnet, 2082 providing the (auto-)configured prefix for the ACP connect subnet to 2083 NMS hosts and/or software components. The ACP edge device uses route 2084 prefix option of RFC4191 to announce the default route (::/) with a 2085 lifetime of 0 and aggregated prefixes for routes in the ACP routing 2086 table with normal lifetimes. This will ensure that the ACP edge 2087 device does not become a default router, but that the NMS hosts and 2088 software components will route the prefixes used in the ACP to the 2089 ACP edge device. 2091 Aggregated prefix means that the ACP edge device needs to only 2092 announce the /48 ULA prefixes used in the ACP but none of the actual 2093 /64 (Manual Addressing Sub-Scheme), /127 (Zone Addressing Sub- 2094 Scheme), /112 or /120 (Vlong Addressing Sub-Scheme) routes of actual 2095 ACP devices. If ACP interfaces are configured with non ULA prefixes, 2096 then those prefixes can not be aggreged without further configured 2097 policy on the ACP edge device. This explains the above 2098 recommendation to use ACP ULA prefix covered prefixes for ACP connect 2099 interfaces: They allow for a shorter list of prefixes to be signalled 2100 via RFC4191 to NMS hosts and software components. 2102 The ACP edge devices that have a Vlong ACP address MAY allocate a 2103 subset of their /112 or /120 address prefix to ACP connect 2104 interface(s) to eliminate the need to non-autonomically configure/ 2105 provision the address prefixes for such ACP connect interfaces. See 2106 Section 11 for considerations how this updates the IPv6 address 2107 architecture and ULA specification. 2109 8.1.4. Combined ACP and Data Data Plane Interface (VRF Select) 2110 Combined ACP and Data Plane interface 2111 . 2112 +--------+ +--------------------+ . +--------------+ 2113 | ACP | |ACP Edge Device | . | NMS Host(s) | 2114 | Device | | | . | / Software | 2115 | | | [ACP ]. | . | |+ 2116 | | | .[VRF ] .[VRF ] | v | "ACP address"|| 2117 | +-------+. .[Select].+--------+ "Date Plane || 2118 | | ^ | .[Data ]. | | Address(es)"|| 2119 | | . | [Plane] | | || 2120 | | . | [VRF ] | +--------------+| 2121 +--------+ . +--------------------+ +--------------+ 2122 . 2123 data-plane "native" and + ACP auto-negotiated/encrypted 2125 Figure 8: VRF select 2127 Using two physical and/or virtual subnets (and therefore interfaces) 2128 into NMS Hosts (as per Section 8.1.1) or Software (as per 2129 Section 8.1.2) may be seen as additional complexity, for example with 2130 legacy NMS Hosts that support only one IP interface. 2132 To provide a single subnet into both ACP and Data Plane, the ACP Edge 2133 device needs to demultiplex packets from NMS hosts into ACP VRF and 2134 Data Plane VRF. This is sometimes called "VRF select". If the ACP 2135 VRF has no overlapping IPv6 addresses with the Data Plane (as it 2136 should), then this function can use the IPv6 Destination address. 2137 The problem is Source Address Selection on the NMS Host(s) according 2138 to RFC6724. 2140 Consider the simple case: The ACP uses only one ULA prefix, the ACP 2141 IPv6 prefix for the Combined ACP and Data Plane interface is covered 2142 by that ULA prefix. The ACP edge device announces both the ACP IPv6 2143 prefix and one (or more) prefixes for the data plane. Without 2144 further policy configurations on the NMS Host(s), it may select its 2145 ACP address as a source address for Data Plane ULA destinations 2146 because of Rule 8 of RFC6724. The ACP edge device can pass on the 2147 packet to the Data Plane, but the ACP source address should not be 2148 used for Data Plane traffic, and return traffic may fail. 2150 If the ACP carries multiple ULA prefixes or non-ULA ACP connect 2151 prefixes, then the correct source address selection becomes even more 2152 problematic. 2154 With separate ACP connect and Data Plane subnets and RFC4191 prefix 2155 announcements that are to be routed across the ACP connect interface, 2156 RFC6724 source address selection Rule 5 (use address of outgoing 2157 interface) will be used, so that above problems do not occur, even in 2158 more complex cases of multiple ULA and non-ULA prefixes in the ACP 2159 routing table. 2161 To achieve the same behavior with a Combined ACP and Data Plane 2162 interface, the ACP Edge Device needs to behave as two separate 2163 routers on the interface: One link-local IPv6 address/router for its 2164 ACP reachability, and one link-local IPv6 address/router for its Data 2165 Plane reachability. The Router Advertisements for both are as 2166 described above (Section 8.1.3): For the ACP, the ACP prefix is 2167 announced together with RFC4191 option for the prefixes routed across 2168 the ACP and lifetime=0 to disqualify this next-hop as a default 2169 router. For the Data Plane, the Data Plane prefix(es) are announced 2170 together with whatever dafault router parameters are used for the 2171 Data Plane. 2173 In result, RFC6724 source address selection Rule 5.5 may result in 2174 the same correct source address selection behavior of NMS hosts 2175 without further configuration on it as the separate ACP connect and 2176 Data Plane interfaces. As described in the text for Rule 5.5, this 2177 is only a may, because IPv6 hosts are not required to track next-hop 2178 information. If an NMS Host does not do this, then separate ACP 2179 connect and Data Plane interfaces are the preferrable method of 2180 attachment. 2182 ACP edge devices MAY support the Combined ACP and Data Plane 2183 interface. 2185 8.1.5. Use of GRASP 2187 GRASP can and should be possible to use across ACP connect 2188 interfaces, especially in the architectural correct solution when it 2189 is used as a mechanism to connect Software (eg: ASA or legacy NMS 2190 applications) to the ACP. Given how the ACP is the security and 2191 transport substrate for GRASP, the trustworthyness of devices/ 2192 software allowed to participate in the ACP GRASP domain is one of the 2193 main reasons why the ACP section describes no solution with non-ACP 2194 routers participating in the ACP routing table. 2196 ACP connect interfaces can be dealt with in the GRASP ACP domain like 2197 any other ACP interface assuming that any physical ACP connect 2198 interface is physically protected from attacks and that the connected 2199 Software or NMS Hosts are equally trusted as that on other ACP 2200 devices. ACP edge devices SHOULD have options to filter GRASP 2201 messages in and out of ACP connect interfaces (permit/deny) and MAY 2202 have more fine-grained filtering (eg: based on IPv6 address of 2203 originator or objective). 2205 When using "Combined ACP and Data Plane Interfaces", care must be 2206 taken that only GRASP messages intended for the ACP GRASP domain 2207 received from Software or NMS Hosts are forwarded by ACP edge 2208 devices. Currently there is no definition for a GRASP security and 2209 transport substrate beside the ACP, so there is no definition how 2210 such Software/NMS Host could participate in two separate GRASP 2211 Domains across the same subnet (ACP and Data Plane domains). At 2212 current it is therefore assumed that all GRASP packets on a Combined 2213 ACP and Data Plane interface belong to the GRASP ACP Domain. They 2214 must therefore all use the ACP IPv6 addresses of the Software/NMS 2215 Hosts. The link-local IPv6 addresses of Software/NMS Hosts (used for 2216 GRASP M_DISCOVERY and M_FLOOD messages) are also assumed to belong to 2217 the ACP address space. 2219 8.2. ACP through Non-Autonomic L3 Clouds (Remote ACP neighbors) 2221 Not all devices in a network may support the ACP. If non-ACP Layer-2 2222 devices are between ACP nodes, the ACP will work across it since it 2223 is IP based. However, the autonomic discovery of ACP neigbhors via 2224 DULL GRASP is only intended to work across L2 connections, so it is 2225 not sufficient to autonomically create ACP connections across non-ACP 2226 Layer-3 devices. 2228 8.2.1. Configured Remote ACP neighbor 2230 On the autonomic device remote ACP neighbors are configured as 2231 follows: 2233 remote-peer = [ local-address, method, remote-address ] 2234 local-address = ip-address 2235 remote-address = transport-address 2236 transport-address = 2237 [ (ip-address | pattern) ?( , protocol ?(, port)) (, pmtu) ] 2238 ip-address = (ipv4-address | ipv6-address ) 2239 method = "IKEv2" / "dTLS" / .. 2240 pattern = some IP address set 2242 For each candidate configured remote ACP neighbor, the secure channel 2243 protocol "method" is configured with its expected local IP address 2244 and remote transport endpoint (transport protocol and port number for 2245 the remote transport endpoint are usually not necessary to configure 2246 if defaults for the secure channel protocol method exist. 2248 This is the same information that would be communicated via DULL for 2249 L2 adjacent candidate ACP neighbors. DULL is not used because the 2250 remote IP address would need to be configured anyhow and if the 2251 remote transport address would not be configured but learned via DULL 2252 then this would create a third party attack vector. 2254 The secure channel method leverages the configuration to filter 2255 incoming connection requests by the remote IP address. This is 2256 suplemental security. The primary security is via the mutual domain 2257 certificate based authentication of the secure channel protocol. 2259 On a hub device, the remote IP address may be set to some pattern 2260 instead of explicit IP addresses. In this case, the device does not 2261 attempt to initiate secure channel connections but only acts as their 2262 responder. This allows for simple hub&spoke setups for the ACP where 2263 some method (subject to further specification) provisions the 2264 transport-address of hubs into spokes and hubs accept connections 2265 from any spokes. The typical use case for this are spokes connecting 2266 via the Internet to hubs. For example, this would be simple 2267 extension to BRSKI to allow zero-touch security across the Internet. 2269 Unlike adjacent ACP neighbor connections, configured remote ACP 2270 neighbor connections can also be across IPv4. Not all (future) 2271 secure channel methods may support running IPv6 (as used in the ACP 2272 across the secure channel connection) over IPv4 encapsulation. 2274 Unless the secure channel method supports PMTUD, it needs to be set 2275 up with minimum MTU or the path mtu (pmtu) should be configured. 2277 8.2.2. Tunneled Remote ACP Neighbor 2279 An IPinIP, GRE or other form of pre-existing tunnel is configured 2280 between two remote ACP peers and the virtual interfaces representing 2281 the tunnel are configured to "ACP enable". This will enable IPv6 2282 link local addresses and DULL on this tunnel. In result, the tunnel 2283 is used for normal "L2 adjacent" candidate ACP neighbor discovery 2284 with DULL and secure channel setup procedures described in this 2285 document. 2287 Tunneled Remote ACP Neighbor requires two encapsulations: the 2288 configured tunnel and the secure channel inside of that tunnel. This 2289 makes it in general less desirable than Configured Remote ACP 2290 Neighbor. Benefits of tunnels are that it may be easier to implement 2291 because there is no change to the ACP functionality - just running it 2292 over a virtual (tunnel) interface instead of only physical 2293 interfaces. The tunnel itself may also provide PMTUD while the 2294 secure channel method may not. Or the tunnel mechanism is permitted/ 2295 possible through some firewall while the secure channel method may 2296 not. 2298 8.2.3. Summary 2300 Configured/Tunneled Remote ACP neighbors are less "indestructible" 2301 than L2 adjacent ACP neighbors based on link local addressing, since 2302 they depend on more correct data plane operations, such as routing 2303 and global addressing. 2305 Nevertheless, these options may be crucial to incrementally deploy 2306 the ACP, especially if it is meant to connect islands across the 2307 Internet. Implementations SHOULD support at least Tunneled Remote 2308 ACP Neighbors via GRE tunnels - which is likely the most common 2309 router-to-router tunneling protocol in use today. 2311 Future work could envisage an option where the edge devices of the L3 2312 cloud is configured to automatically forward ACP discovery messages 2313 to the right exit point. This optimisation is not considered in this 2314 document. 2316 9. Benefits (Informative) 2318 9.1. Self-Healing Properties 2320 The ACP is self-healing: 2322 o New neighbors will automatically join the ACP after successful 2323 validation and will become reachable using their unique ULA 2324 address across the ACP. 2326 o When any changes happen in the topology, the routing protocol used 2327 in the ACP will automatically adapt to the changes and will 2328 continue to provide reachability to all devices. 2330 o If an existing device gets revoked, it will automatically be 2331 denied access to the ACP as its domain certificate will be 2332 validated against a Certificate Revocation List during 2333 authentication. Since the revocation check is only done at the 2334 establishment of a new security association, existing ones are not 2335 automatically torn down. If an immediate disconnect is required, 2336 existing sessions to a freshly revoked device can be re-set. 2338 The ACP can also sustain network partitions and mergers. Practically 2339 all ACP operations are link local, where a network partition has no 2340 impact. Devices authenticate each other using the domain 2341 certificates to establish the ACP locally. Addressing inside the ACP 2342 remains unchanged, and the routing protocol inside both parts of the 2343 ACP will lead to two working (although partitioned) ACPs. 2345 There are few central dependencies: A certificate revocation list 2346 (CRL) may not be available during a network partition; a suitable 2347 policy to not immediately disconnect neighbors when no CRL is 2348 available can address this issue. Also, a registrar or Certificate 2349 Authority might not be available during a partition. This may delay 2350 renewal of certificates that are to expire in the future, and it may 2351 prevent the enrolment of new devices during the partition. 2353 After a network partition, a re-merge will just establish the 2354 previous status, certificates can be renewed, the CRL is available, 2355 and new devices can be enrolled everywhere. Since all devices use 2356 the same trust anchor, a re-merge will be smooth. 2358 Merging two networks with different trust anchors requires the trust 2359 anchors to mutually trust each other (for example, by cross-signing). 2360 As long as the domain names are different, the addressing will not 2361 overlap (see Section 6.10). 2363 It is also highly desirable for implementation of the ACP to be able 2364 to run it over interfaces that are administratively down. If this is 2365 not feasible, then it might instead be possible to request explicit 2366 operator override upon administrative actions that would 2367 administratively bring down an interface across whicht the ACP is 2368 running. Especially if bringing down the ACP is known to disconnect 2369 the operator from the device. For example any such down 2370 administrative action could perform a dependency check to see if the 2371 transport connection across which this action is performed is 2372 affected by the down action (with default RPL routing used, packet 2373 forwarding will be symmetric, so this is actually possible to check). 2375 9.2. Self-Protection Properties 2377 9.2.1. From the outside 2379 As explained in Section 6, the ACP is based on secure channels built 2380 between devices that have mutually authenticated each other with 2381 their domain certificates. The channels themselves are protected 2382 using standard encryption technologies like DTLS or IPsec which 2383 provide additional authentication during channel establishment, data 2384 integrity and data confidentiality protection of data inside the ACP 2385 and in addition, provide replay protection. 2387 An attacker will therefore not be able to join the ACP unless having 2388 a valid domain certificate, also packet injection and sniffing 2389 traffic will not be possible due to the security provided by the 2390 encryption protocol. 2392 The ACP also serves as protection (through authentication and 2393 encryption) for protocols relevant to OAM that may not have secured 2394 protocol stack options or where implementation or deployment of those 2395 options fails on some vendor/product/customer limitations. This 2396 includes protocols such as SNMP, NTP/PTP, DNS, DHCP, syslog, 2397 Radius/Diameter/Tacacs, IPFIX/Netflow - just to name a few. 2398 Protection via the ACP secure hop-by-hop channels for these protocols 2399 is meant to be only a stopgap though: The ultimate goal is for these 2400 and other protocols to use end-to-end encryption utilizing the domain 2401 certificate and rely on the ACP secure channels primarily for zero- 2402 touch reliable connectivity, but not primarily for security. 2404 The remaining attack vector would be to attack the underlying AN 2405 protocols themselves, either via directed attacks or by denial-of- 2406 service attacks. However, as the ACP is built using link-local IPv6 2407 address, remote attacks are impossible. The ULA addresses are only 2408 reachable inside the ACP context, therefore unreachable from the data 2409 plane. Also, the ACP protocols should be implemented to be attack 2410 resistant and not consume unnecessary resources even while under 2411 attack. 2413 9.2.2. From the inside 2415 The security model of the ACP is based on trusting all members of the 2416 group of devices that do receive an ACP domain certificate for the 2417 same domain. Attacks from the inside by a compromised group member 2418 are therefore the biggest challenge. 2420 Group members must overall the secured so that there are no easy way 2421 to compromise them, such as data plane accessible privilege level 2422 with simple passwords. This is a lot easier to do in devices whose 2423 software is designed from the ground up with security in mind than 2424 with legacy software based system where ACP is added on as another 2425 feature. 2427 As explained above, traffic across the ACP SHOULD still be end-to-end 2428 encrypted whenever possible. This includes traffic such as GRASP, 2429 EST and BRSKI inside the ACP. This minimizes man in the middle 2430 attacks by compromised ACP group members. Such attackers can not 2431 eavesdrop or modify communications, they can just filter them (which 2432 is unavoidable by any means). 2434 Further security can be achieved by constraining communication 2435 patterns inside the ACP, for example through roles that could be 2436 encoded into the domain certificates. This is subject for future 2437 work. 2439 9.3. The Administrator View 2441 An ACP is self-forming, self-managing and self-protecting, therefore 2442 has minimal dependencies on the administrator of the network. 2443 Specifically, since it is independent of configuration, there is no 2444 scope for configuration errors on the ACP itself. The administrator 2445 may have the option to enable or disable the entire approach, but 2446 detailed configuration is not possible. This means that the ACP must 2447 not be reflected in the running configuration of devices, except a 2448 possible on/off switch. 2450 While configuration is not possible, an administrator must have full 2451 visibility of the ACP and all its parameters, to be able to do 2452 trouble-shooting. Therefore, an ACP must support all show and debug 2453 options, as for any other network function. Specifically, a network 2454 management system or controller must be able to discover the ACP, and 2455 monitor its health. This visibility of ACP operations must clearly 2456 be separated from visibility of data plane so automated systems will 2457 never have to deal with ACP aspect unless they explicitly desire to 2458 do so. 2460 Since an ACP is self-protecting, a device not supporting the ACP, or 2461 without a valid domain certificate cannot connect to it. This means 2462 that by default a traditional controller or network management system 2463 cannot connect to an ACP. See Section 8.1.1 for more details on how 2464 to connect an NMS host into the ACP. 2466 10. Further Considerations (Informative) 2468 The following sections cover topics that are beyond the primary cope 2469 of this document (eg: bootstrap), that explain decisions made in this 2470 document (eg: choice of GRASP) or that explain desirable extensions 2471 to the behavior of the ACP that are not far enough worked out to be 2472 already standardized in this document. 2474 10.1. Domain Certificate provisioning / enrollment 2476 [I-D.ietf-anima-bootstrapping-keyinfra] (BRSKI) describes how devices 2477 with an IDevID certificate can securely and zero-touch enroll with a 2478 domain certificate to support the ACP. BRSKI also leverages the ACP 2479 to enable zero touch bootstrap of new devices across networks without 2480 any configuration requirements across the transit devices (eg: no 2481 DHCP/DS forwarding/server setup). This includes otherwise 2482 unconfigured networks as described in Section 3.2. Therefore BRSKI 2483 in conjunction with ACP provides for a secure and zero-touch 2484 management solution for complete networks. Devices supporting such 2485 an infrastructure (BRSKI and ACP) are called ANI devices (Autonomic 2486 Networking Infrstructure), see [I-D.ietf-anima-reference-model]. 2488 Devices that do not support an IDevID but only an (insecure) vendor 2489 specific Unique Device Identifier (UDI) or devices whose manufacturer 2490 does not support a MASA could use some future security reduced 2491 version of BRSKI. 2493 When BRSKI is used to provision a domain certificate (which is called 2494 enrollment), the registrar (acting as an EST server) MUST include the 2495 subjectAltName / rfc822Name encoded ACP address and domain name to 2496 the enrolling device (called pledge) via its response to the pledges 2497 EST CSR Attribute request that is mandatory in BRSKI. 2499 The Certificate Authority in an ACP network MUST not change this, and 2500 create the respective subjectAltName / rfc822Name in the certificate. 2501 The ACP nodes can therefore find their ACP address and domain using 2502 this field in the domain certificate, both for themselves, as well as 2503 for other nodes. 2505 The use of BRSKI in conjunction with the ACP can also help to further 2506 simplify maintenance and renewal of domain certificates. Instead of 2507 relying on CRL, the lifetime of certificates can be made extremely 2508 small, for example in the order of hours. When a device fails to 2509 connect to the ACP within its certificate lifetime, it can not 2510 connect to the ACP to renew its certificate across it, but it can 2511 still renew its certificate as an "enrolled/expired pledge" via the 2512 BRSKI bootstrap proxy. This requires only that the enhanced EST 2513 server that is part of BRSKI honors expired domain certificates and 2514 that the pledge first attempts to perform TLS authentication for 2515 BRSKI bootstrap with its expired domain certificate - and only 2516 reverts to its IDevID when this fails. This mechanism also replaces 2517 CRLs because the EST server (in conunction with the CA) would not 2518 renew revoked certficates - but in this scheme only the EST-server 2519 need to know which certificate was revoked. 2521 In the absence of BRSKI or less secure variants thereof, provisioning 2522 of certificates may involve one or more touches or non-standardized 2523 automation. Device vendors usually support provisioning of 2524 certificates into devices via PKCS#7 (see [RFC2315]) and may support 2525 this provisioning through vendor specific models via Netconf 2526 ([RFC6241]). If such devices also support Netconf Zerotouch 2527 ([I-D.ietf-netconf-zerotouch]) then this can be combined to zero- 2528 touch provisioning of domain certificates into devices. Unless there 2529 are equivalent integration of Netconf connections across the ACP as 2530 there is in BRSKI, this combination would not support zero-touch 2531 bootstrap across an unconfigured network though. 2533 10.2. ACP Neighbor discovery protocol selection 2535 This section discusses why GRASP DULL was choosen as the discovery 2536 protocol for L2 adjacent candidate ACP neighbors. The contenders 2537 considered where GRASP, mDNS or LLDP. 2539 10.2.1. LLDP 2541 LLDP (and Cisco's similar CDP) are example of L2 discovery protocols 2542 that terminate their messages on L2 ports. If those protocols would 2543 be chosen for ACP neighbor discovery, ACP neighbor discovery would 2544 therefore also terminate on L2 ports. This would prevent ACP 2545 construction over non-ACP capable but LLDP or CDP enabled L2 2546 switches. LLDP has extensions using different MAC addresses and this 2547 could have been an option for ACP discovery as well, but the 2548 additional required IEEE standardization and definition of a profile 2549 for such a modified instance of LLDP seemed to be more work than the 2550 benefit of "reusing the existing protocol" LLDP for this very simple 2551 purpose. 2553 10.2.2. mDNS and L2 support 2555 mDNS [RFC6762] with DNS-SD RRs (Resource Records) as defined in 2556 [RFC6763] is a key contender as an ACP discovery protocol. because it 2557 relies on link-local IP multicast, it does operates at the subnet 2558 level, and is also found in L2 switches. The authors of this 2559 document are not aware of mDNS implementation that terminate their 2560 mDNS messages on L2 ports instead of the subnet level. If mDNS was 2561 used as the ACP discovery mechanism on an ACP capable (L3)/L2 switch 2562 as outlined in Section 7, then this would be necessary to implement. 2563 It is likely that termination of mDNS messages could only be applied 2564 to all mDNS messages from such a port, which would then make it 2565 necessary to software forward any non-ACP related mDNS messages to 2566 maintain prior non-ACP mDNS functionality. Adding support for ACP 2567 into such L2 switches with mDNS could therefore create regression 2568 problems for prior mDNS functionality on those devices. With low 2569 performance of software forwarding in many L2 switches, this could 2570 also make the ACP risky to support on such L2 switches. 2572 10.2.3. Why DULL GRASP 2574 LLDP was not considered because of the above mentioned issues. mDNS 2575 was not selected because of the above L2 mDNS considerations and 2576 because of the following additional points: 2578 If mDNS was not already existing in a device, it would be more work 2579 to implement than DULL GRASP, and if an existing implementation of 2580 mDNS was used, it would likely be more code space than a separate 2581 implementation of DULL GRASP or a shared implementation of DULL GRASP 2582 and GRASP in the ACP. 2584 10.3. Choice of routing protocol (RPL) 2586 This Appendix explains why RPL - "IPv6 Routing Protocol for Low-Power 2587 and Lossy Networks ([RFC6550] was chosen as the default (and in this 2588 specification only) routing protocol for the ACP. The choice and 2589 above explained profile was derived from a pre-standard 2590 implementation of ACP that was successfully deployed in operational 2591 networks. 2593 Requirements for routing in the ACP are: 2595 o Self-management: The ACP must build automatically, without human 2596 intervention. Therefore routing protocol must also work 2597 completely automatically. RPL is a simple, self-managing 2598 protocol, which does not require zones or areas; it is also self- 2599 configuring, since configuration is carried as part of the 2600 protocol (see Section 6.7.6 of [RFC6550]). 2602 o Scale: The ACP builds over an entire domain, which could be a 2603 large enterprise or service provider network. The routing 2604 protocol must therefore support domains of 100,000 nodes or more, 2605 ideally without the need for zoning or separation into areas. RPL 2606 has this scale property. This is based on extensive use of 2607 default routing. RPL also has other scalability improvements, 2608 such as selecting only a subset of peers instead of all possible 2609 ones, and trickle support for information synchronisation. 2611 o Low resource consumption: The ACP supports traditional network 2612 infrastructure, thus runs in addition to traditional protocols. 2613 The ACP, and specifically the routing protocol must have low 2614 resource consumption both in terms of memory and CPU requirements. 2615 Specifically, at edge nodes, where memory and CPU are scarce, 2616 consumption should be minimal. RPL builds a destination-oriented 2617 directed acyclic graph (DODAG), where the main resource 2618 consumption is at the root of the DODAG. The closer to the edge 2619 of the network, the less state needs to be maintained. This 2620 adapts nicely to the typical network design. Also, all changes 2621 below a common parent node are kept below that parent node. 2623 o Support for unstructured address space: In the Autonomic 2624 Networking Infrastructure, node addresses are identifiers, and may 2625 not be assigned in a topological way. Also, nodes may move 2626 topologically, without changing their address. Therefore, the 2627 routing protocol must support completely unstructured address 2628 space. RPL is specifically made for mobile ad-hoc networks, with 2629 no assumptions on topologically aligned addressing. 2631 o Modularity: To keep the initial implementation small, yet allow 2632 later for more complex methods, it is highly desirable that the 2633 routing protocol has a simple base functionality, but can import 2634 new functional modules if needed. RPL has this property with the 2635 concept of "objective function", which is a plugin to modify 2636 routing behaviour. 2638 o Extensibility: Since the Autonomic Networking Infrastructure is a 2639 new concept, it is likely that changes in the way of operation 2640 will happen over time. RPL allows for new objective functions to 2641 be introduced later, which allow changes to the way the routing 2642 protocol creates the DAGs. 2644 o Multi-topology support: It may become necessary in the future to 2645 support more than one DODAG for different purposes, using 2646 different objective functions. RPL allow for the creation of 2647 several parallel DODAGs, should this be required. This could be 2648 used to create different topologies to reach different roots. 2650 o No need for path optimisation: RPL does not necessarily compute 2651 the optimal path between any two nodes. However, the ACP does not 2652 require this today, since it carries mainly non-delay-sensitive 2653 feedback loops. It is possible that different optimisation 2654 schemes become necessary in the future, but RPL can be expanded 2655 (see point "Extensibility" above). 2657 10.4. Extending ACP channel negotiation (via GRASP) 2659 The mechanism described in the normative part of this document to 2660 support multiple different ACP secure channel protocols without a 2661 single network wide MTI protocol is important to allow extending 2662 secure ACP channel protocols beyond what is specified in this 2663 document, but it will run into problem if it would be used for 2664 multiple protocols: 2666 The need to potentially have multiple of these security associations 2667 even temporarily run in parallel to determine which of them works 2668 best does not support the most lightweight implementation options. 2670 The simple policy of letting one side (Alice) decide what is best may 2671 not lead to the mutual best result. 2673 The two limitations can easier be solved if the solution was more 2674 modular and as few as possible initial secure channel negotiation 2675 protocols would be used, and these protocols would then take on the 2676 responsibility to support more flexible objectives to negotiate the 2677 mutually preferred ACP security channel protocol. 2679 IKEv2 is the IETF standard protocol to negotiate network security 2680 associations. It is meant to be extensible, but it is unclear 2681 whether it would be feasible to extend IKEv2 to support possible 2682 future requirements for ACP secure channel negotiation: 2684 Consider the simple case where the use of native IPsec vs. IPsec via 2685 GRE is to be negotiated and the objective is the maximum throughput. 2686 Both sides would indicate some agreed upon performance metric and the 2687 preferred encapsulation is the one with the higher performance of the 2688 slower side. IKEv2 does not support negotiation with this objective. 2690 Consider dTLS and some form of 802.1AE (MacSEC) are to be added as 2691 negotiation options - and the performance objective should work 2692 across all IPsec, dDTLS and 802.1AE options. In the case of MacSEC, 2693 the negotiation would also need to determine a key for the peering. 2694 It is unclear if it would be even appropriate to consider extending 2695 the scope of negotiation in IKEv2 to those cases. Even if feasible 2696 to define, it is unclear if implementations of IKEv2 would be eager 2697 to adopt those type of extension given the long cycles of security 2698 testing that necessarily goes along with core security protocols such 2699 as IKEv2 implementations. 2701 A more modular alternative to extending IKEv2 could be to layer a 2702 modular negotiation mechanism on top of the multitide of existing or 2703 possible future secure channel protocols. For this, GRASP over TLS 2704 could be considered as a first ACP secure channel negotiation 2705 protocol. The following are initial considerations for such an 2706 approach. A full specification is subject to a separate document: 2708 To explicitly allow negotiation of the ACP channel protocol, GRASP 2709 over a TLS connection using the GRASP_LISTEN_PORT and the devices and 2710 peers link-local IPv6 address is used. When Alice and Bob support 2711 GRASP negotiation, they do prefer it over any other non-explicitly 2712 negotiated security association protocol and should wait trying any 2713 non-negotiated ACP channel protocol until after it is clear that 2714 GRASP/TLS will not work to the peer. 2716 When Alice and Bob successfully establish the GRASP/TSL session, they 2717 will negotiate the channel mechanism to use using objectives such as 2718 performance and perceived quality of the security. After agreeing on 2719 a channel mechanism, Alice and Bob start the selected Channel 2720 protocol. Once the secure channel protocol is successfully running, 2721 the GRASP/TLS connection can be kept alive or timed out as long as 2722 the selected channel protocol has a secure association between Alice 2723 and Bob. When it terminates, it needs to be re-negotiated via GRASP/ 2724 TLS. 2726 Notes: 2728 o Negotiation of a channel type may require IANA assignments of code 2729 points. 2731 o TLS is subject to reset attacks, which IKEv2 is not. Normally, 2732 ACP connections (as specified in this document) will be over link- 2733 local addresses so the attack surface for this one issue in TCP 2734 should be reduced (note that this may not be true when ACP is 2735 tunneled as described in Section 8.2.2. 2737 o GRASP packets received inside a TLS connection established for 2738 GRASP/TLS ACP negotiation are assigned to a separate GRASP domain 2739 unique to that TLS connection. 2741 10.5. CAs, domains and routing subdomains 2743 There is a wide range of setting up different ACP solution by 2744 appropriately using CAs and the domain and rsub elements in the ACP 2745 information field of the domain certificate. We summarize these 2746 options here as they have been explained in different parts of the 2747 document in before and discuss possible and desirable extensions: 2749 An ACP domain is the set of all ACP devices using certificates from 2750 the same CA using the same domain field. GRASP inside the ACP is run 2751 across all transitively connected ACP devices in a domain. 2753 The rsub element in the ACP information field primarily allows to use 2754 addresses from different ULA prefixes. One use case is to create 2755 multiple networks that initially may be separated, but where it 2756 should be possible to connect them without further extensions to ACP 2757 when necessary. 2759 Another use case for routing subdomains is as the starting point for 2760 structuring routing inside an ACP. For example, different routing 2761 subdomains could run different routing protocols or different 2762 instances of RPL and auto-aggregation / distribution of routes could 2763 be done across inter routing subdomain ACP channels based on 2764 negotiation (eg: via GRASP). This is subject for further work. 2766 RPL scales very well. It is not necessary to use multiple routing 2767 subdomains to scale autonomic domains in a way it would be possible 2768 if other routing protocols where used. They exist only as options 2769 for the above mentioned reasons. 2771 If different ACP domains are to be created that should not allow to 2772 connect to each other by default, these ACP domains simply need to 2773 have different domain elements in the ACP information field. These 2774 domain elements can be arbitrary, including subdomains of one 2775 another: Domains "example.com" and "research.example.com" are 2776 separate domains if both are domain elements in the ACP information 2777 element of certificates. 2779 It is not necessary to have a sparate CA for different ACP domains: 2780 an operator can use a single CA to sign certificates for multiple ACP 2781 domains that are not allowed to connect to each other because the 2782 checks for ACP adjacencies includes comparison of the domain part. 2784 If multiple independent networks choose the same domain name but had 2785 their own CA, these would not form a single ACP domain because of CA 2786 mismatch. Therefore there is no problem in choosing domain names 2787 that are potentially also used by others. Nevertheless it is highly 2788 recommended to use domain names that one can have high probability to 2789 be unique. It is recommended to use domain names that start with a 2790 DNS domain names owned by the assigning organization and unique 2791 within it. For example "acp.example.com" if you own "example.com". 2793 Future extensions, primarily through intent can create more flexible 2794 options how to build ACP domains. 2796 Intent could modify the ACP connection check to permit connections 2797 between different domains. 2799 If different domains use the same CA one would change the ACP setup 2800 to permit for the ACP to be established between the two ACP devices, 2801 but no routing nor ACP GRASP to be built across this adjacency. The 2802 main difference over routing subdomains is to not permit for the ACP 2803 GRASP instance to be build across the adjacency. Instead, one would 2804 only build a point to point GRASP instance between those peers to 2805 negotiate what type of exchanges are desired across that connection. 2806 This would include routing negotiation, how much GRASP information to 2807 transit and what data-plane forwarding should be done. This approach 2808 could also allow for for Intent to only be injected into the network 2809 from one side and propagate via this GRASP connection. 2811 If different domains have different CAs, they should start to trust 2812 each other by intent injected into both domains that would add the 2813 other domains CA as a trust point during the ACP connection setup - 2814 and then following up with the previous point of inter-domain 2815 connections across domains with the same CA (eg: GRASP negotiation). 2817 11. RFC4291/RFC4193 Updates Considerations 2819 This document may be considered to be updating the IPv6 addressing 2820 architecture ([RFC4291]) and/or the Unique Local IPv6 Unicast 2821 addresses ([RFC4193]) depending on how strict specific statements in 2822 those specs are to be interpreted. This section summarized and 2823 explains the necessity and benefits of these changes. The normative 2824 parts of this document cover the actual updates. 2826 ACP addresses (Section 6.10) are used by network devices supporting 2827 the ACP. They are assigned during bootstrap of the device or initial 2828 provisioning of the ACP. They are encoded in the Domain Certificate 2829 of the device and are primarily used internally within the network 2830 device. In that role they can be thought of as loopback addresses. 2832 Each ACP domain assigns ACP addresses from one or more ULA prefixes. 2833 Within an ACP network, addresses are assigned by nodes called 2834 registrars. A unique Registrar-ID(entifier) is used in ACP addresses 2835 to allow multiple registrars to assign addresses autonomously and 2836 uncoordinated from each other. Typically these Registrar-IDs are 2837 derived from the IEEE 802 48-bit MAC addresses of registrars. 2839 In the ACP Zone Addressing Sub-Scheme (Section 6.10.3), the registrar 2840 assigns a unique 15 bit value to an ACP device. The ACP address has 2841 a 64-bit Device-ID(entifier) composed of the 48-bit Registrar-ID, the 2842 registrar assigned 15-bit Device-Number and 1 V(irtualization) bit 2843 that allows for an ACP device to have two addresses. 2845 The 64-bit Device-Identifier in the ACP Zone Addressing Sub-Scheme 2846 matches the 64 bit Interface Identifier (IID) address part as 2847 specified in RFC4291 section 2.5.1. IIDs are unique across ACP 2848 devices, but all ACP devices with the same ULA prefix that use the 2849 ACP Zone Addressing Sub-Scheme will share the same subnet prefix 2850 (according to the definition of that term in RFC4291). Each ACP 2851 device injects a /127 route into the ACP routing table to cover its 2852 two assigned addresses (V(irtual) bit being 0 or 1). This approach 2853 is used because these ACP addresses are identifiers and not locators. 2854 The ACP device can connect anywhere in the autonomic domain without 2855 having to change its addresses. A lightweight, highly scaleable 2856 routing protocol (RPL) is used to allow for large scale ACP networks. 2858 It is possible, that this scheme constitutes an update to RFC4191 2859 because the same 64 bit subnet prefix is used across many ACP 2860 devices. The ACP Zone addressing Sub-Scheme is very similar to the 2861 common operational practices of assigning /128 loopback addresses to 2862 network devices from the same /48 or /64 subnet prefix. 2864 In the ACP Vlong Addressing Sub-Scheme (Section 6.10.5), the address 2865 elements are the same as described for the Zone Addressing Sub- 2866 Scheme, but the V field is expanded from 1 bit to 8 or 16 bits. The 2867 ACP device with ACP Vlong addressing therefore injects /120 or /112 2868 prefixes into the ACP routing table to cover its internal addresses. 2870 The goal for the 8 or 16-bit addresses available to an ACP device in 2871 this scheme is to assign them as required to software components, 2872 which in autonomic networking are called ASA (Autonomic Service 2873 Agents). It could equally be used for existing software components 2874 such as VNFs (Virtual Networking Functions). The ACP interface would 2875 then be the out-of-band management interface of such a VNF software 2876 component. It should especially be possible to use these software 2877 components in a variety of contexts to allow standardized modular 2878 system composition: Native applications (in some VRF context if 2879 available), containers, virtual machines or other future ones. To 2880 modularily compose a system with containers and virtual machines and 2881 avoid problems such as port space collision or NAT, it is necessary 2882 not only to assign separate addresses to those contexts, but also to 2883 use the notion of virtual interfaces between these contexts to 2884 compose the system. 2886 In practical terms, the ACP should be enabled to create from its /8 2887 or /16 prefix one or more device internal virtual subnets and to 2888 start software components connected to those virtual subnets. 2889 Ideally, these software components should be able to autoconfigure 2890 their addresses on these virtual interfaces. Future work has to 2891 determine whether this address autoconfiguration for the virtual 2892 interface is best done with DHCPv6, if SLAAC should be recommended 2893 for these /8 or /16 virtual interfaces, or if some additional 2894 standardized method would be required. 2896 In the ACP Vlong Addressing scheme, the Device-ID does not match the 2897 RFC4291/RFC4193 64 bith length for the Interface Identifier, so this 2898 addressing Sub-Scheme in the ACP is an update to both standards. 2900 This document also specifies the workaround solution of exposing the 2901 ACP on physical interfaces in support of adoption by existing 2902 hardware and software solutions. A NOC based NMS host could for 2903 example be configured with a second physical interface connecting to 2904 an ACP device that exposes the ACP to that NMS host (called ACP edge 2905 device). The desired evolution of this workaround is that those two 2906 functions would merge into a single device, for example by making the 2907 ACP router a container/virtual machine inside the NMS host or vice 2908 versa. The addressing for those physical interfaces allows for 2909 manually configured address prefixes but it could be fully autonomous 2910 if it could leverage the Vlong addressing format. That would result 2911 in a non /64 IID boundary on those external interfaces (but instead 2912 in /112 or /120 subnet prefixes). 2914 Note that both in the internal as well as the workaround external use 2915 of ACP addresses, all ACP addresses are meant to be used exclusively 2916 by components that are part of network control and OAM, but not for 2917 network users such as normal hosts. This implies that for example no 2918 requirements for privacy addressing have been identified for ACP 2919 addresses. 2921 12. Security Considerations 2923 An ACP is self-protecting and there is no need to apply configuration 2924 to make it secure. Its security therefore does not depend on 2925 configuration. 2927 However, the security of the ACP depends on a number of other 2928 factors: 2930 o The usage of domain certificates depends on a valid supporting PKI 2931 infrastructure. If the chain of trust of this PKI infrastructure 2932 is compromised, the security of the ACP is also compromised. This 2933 is typically under the control of the network administrator. 2935 o Security can be compromised by implementation errors (bugs), as in 2936 all products. 2938 There is no prevention of source-address spoofing inside the ACP. 2939 This implies that if an attacker gains access to the ACP, it can 2940 spoof all addresses inside the ACP and fake messages from any other 2941 device. 2943 Fundamentally, security depends on correct operation, implementation 2944 and architecture. Autonomic approaches such as the ACP largely 2945 eliminate the dependency on correct operation; implementation and 2946 architectural mistakes are still possible, as in all networking 2947 technologies. 2949 13. IANA Considerations 2951 14. Acknowledgements 2953 This work originated from an Autonomic Networking project at Cisco 2954 Systems, which started in early 2010. Many people contributed to 2955 this project and the idea of the Autonomic Control Plane, amongst 2956 which (in alphabetical order): Ignas Bagdonas, Parag Bhide, Balaji 2957 BL, Alex Clemm, Yves Hertoghs, Bruno Klauser, Max Pritikin, Michael 2958 Richardson, Ravi Kumar Vadapalli. 2960 Special thanks to Pascal Thubert and Michael Richardson to provide 2961 the details for the recommendations of the use of RPL in the ACP 2963 Further input and suggestions were received from: Rene Struik, Brian 2964 Carpenter, Benoit Claise. 2966 15. Change log [RFC Editor: Please remove] 2968 15.1. Initial version 2970 First version of this document: draft-behringer-autonomic-control- 2971 plane 2973 15.2. draft-behringer-anima-autonomic-control-plane-00 2975 Initial version of the anima document; only minor edits. 2977 15.3. draft-behringer-anima-autonomic-control-plane-01 2979 o Clarified that the ACP should be based on, and support only IPv6. 2981 o Clarified in intro that ACP is for both, between devices, as well 2982 as for access from a central entity, such as an NMS. 2984 o Added a section on how to connect an NMS system. 2986 o Clarified the hop-by-hop crypto nature of the ACP. 2988 o Added several references to GDNP as a candidate protocol. 2990 o Added a discussion on network split and merge. Although, this 2991 should probably go into the certificate management story longer 2992 term. 2994 15.4. draft-behringer-anima-autonomic-control-plane-02 2996 Addresses (numerous) comments from Brian Carpenter. See mailing list 2997 for details. The most important changes are: 2999 o Introduced a new section "overview", to ease the understanding of 3000 the approach. 3002 o Merged the previous "problem statement" and "use case" sections 3003 into a mostly re-written "use cases" section, since they were 3004 overlapping. 3006 o Clarified the relationship with draft-ietf-anima-stable- 3007 connectivity 3009 15.5. draft-behringer-anima-autonomic-control-plane-03 3011 o Took out requirement for IPv6 --> that's in the reference doc. 3013 o Added requirement section. 3015 o Changed focus: more focus on autonomic functions, not only virtual 3016 out of band. This goes a bit throughout the document, starting 3017 with a changed abstract and intro. 3019 15.6. draft-ietf-anima-autonomic-control-plane-00 3021 No changes; re-submitted as WG document. 3023 15.7. draft-ietf-anima-autonomic-control-plane-01 3025 o Added some paragraphs in addressing section on "why IPv6 only", to 3026 reflect the discussion on the list. 3028 o Moved the data-plane ACP out of the main document, into an 3029 appendix. The focus is now the virtually separated ACP, since it 3030 has significant advantages, and isn't much harder to do. 3032 o Changed the self-creation algorithm: Part of the initial steps go 3033 into the reference document. This document now assumes an 3034 adjacency table, and domain certificate. How those get onto the 3035 device is outside scope for this document. 3037 o Created a new section 6 "workarounds for non-autonomic nodes", and 3038 put the previous controller section (5.9) into this new section. 3039 Now, section 5 is "autonomic only", and section 6 explains what to 3040 do with non-autonomic stuff. Much cleaner now. 3042 o Added an appendix explaining the choice of RPL as a routing 3043 protocol. 3045 o Formalised the creation process a bit more. Now, we create a 3046 "candidate peer list" from the adjacency table, and form the ACP 3047 with those candidates. Also it explains now better that policy 3048 (Intent) can influence the peer selection. (section 4 and 5) 3050 o Introduce a section for the capability negotiation protocol 3051 (section 7). This needs to be worked out in more detail. This 3052 will likely be based on GRASP. 3054 o Introduce a new parameter: ACP tunnel type. And defines it in the 3055 IANA considerations section. Suggest GRE protected with IPSec 3056 transport mode as the default tunnel type. 3058 o Updated links, lots of small edits. 3060 15.8. draft-ietf-anima-autonomic-control-plane-02 3062 o Added explicitly text for the ACP channel negotiation. 3064 o Merged draft-behringer-anima-autonomic-addressing-02 into this 3065 document, as suggested by WG chairs. 3067 15.9. draft-ietf-anima-autonomic-control-plane-03 3069 o Changed Neighbor discovery protocol from GRASP to mDNS. Bootstrap 3070 protocol team decided to go with mDNS to discover bootstrap proxy, 3071 and ACP should be consistent with this. Reasons to go with mDNS 3072 in bootstrap were a) Bootstrap should be reuseable also outside of 3073 full anima solutions and introduce as few as possible new 3074 elements. mDNS was considered well-known and very-likely even pre- 3075 existing in low-end devices (IoT). b) Using GRASP both for the 3076 insecure neighbor discovery and secure ACP operatations raises the 3077 risk of introducing security issues through implementation issues/ 3078 non-isolation between those two instances of GRASP. 3080 o Shortened the section on GRASP instances, because with mDNS being 3081 used for discovery, there is no insecure GRASP session any longer, 3082 simplifying the GRASP considerations. 3084 o Added certificate requirements for ANIMA in section 5.1.1, 3085 specifically how the ANIMA information is encoded in 3086 subjectAltName. 3088 o Deleted the appendix on "ACP without separation", as originally 3089 planned, and the paragraph in the main text referring to it. 3091 o Deleted one sub-addressing scheme, focusing on a single scheme 3092 now. 3094 o Included information on how ANIMA information must be encoded in 3095 the domain certificate in section "preconditions". 3097 o Editorial changes, updated draft references, etc. 3099 15.10. draft-ietf-anima-autonomic-control-plane-04 3101 Changed discovery of ACP neighbor back from mDNS to GRASP after 3102 revisiting the L2 problem. Described problem in discovery section 3103 itself to justify. Added text to explain how ACP discovery relates 3104 to BRSKY (bootstrap) discovery and pointed to Michael Richardsons 3105 draft detailing it. Removed appendix section that contained the 3106 original explanations why GRASP would be useful (current text is 3107 meant to be better). 3109 15.11. draft-ietf-anima-autonomic-control-plane-05 3111 o Section 5.3 (candidate ACP neighbor selection): Add that Intent 3112 can override only AFTER an initial default ACP establishment. 3114 o Section 6.10.1 (addressing): State that addresses in the ACP are 3115 permanent, and do not support temporary addresses as defined in 3116 RFC4941. 3118 o Modified Section 6.3 to point to the GRASP objective defined in 3119 draft-carpenter-anima-ani-objectives. (and added that reference) 3121 o Section 6.10.2: changed from MD5 for calculating the first 40 bits 3122 to SHA256; reason is MD5 should not be used any more. 3124 o Added address sub-scheme to the IANA section. 3126 o Made the routing section more prescriptive. 3128 o Clarified in Section 8.1.1 the ACP Connect port, and defined that 3129 term "ACP Connect". 3131 o Section 8.2: Added some thoughts (from mcr) on how traversing a L3 3132 cloud could be automated. 3134 o Added a CRL check in Section 6.7. 3136 o Added a note on the possibility of source-address spoofing into 3137 the security considerations section. 3139 o Other editoral changes, including those proposed by Michael 3140 Richardson on 30 Nov 2016 (see ANIMA list). 3142 15.12. draft-ietf-anima-autonomic-control-plane-06 3144 o Added proposed RPL profile. 3146 o detailed dTLS profile - dTLS with any additional negotiation/ 3147 signaling channel. 3149 o Fixed up text for ACP/GRE encap. Removed text claiming its 3150 incompatible with non-GRE IPsec and detailled it. 3152 o Added text to suggest admin down interfaces should still run ACP. 3154 15.13. draft-ietf-anima-autonomic-control-plane-07 3156 o Changed author association. 3158 o Improved ACP connect setion (after confusion about term came up in 3159 the stable connectivity draft review). Added picture, defined 3160 complete terminology. 3162 o Moved ACP channel negotiation from normative section to appendix 3163 because it can in the timeline of this document not be fully 3164 specified to be implementable. Aka: work for future document. 3165 That work would also need to include analysing IKEv2 and describin 3166 the difference of a proposed GRASP/TLS solution to it. 3168 o Removed IANA request to allocate registry for GRASP/TLS. This 3169 would come with future draft (see above). 3171 o Gave the name "ACP information field" to the field in the 3172 certificate carrying the ACP address and domain name. 3174 o Changed the rules for mutual authentication of certificates to 3175 rely on the domain in the ACP information field of the certificate 3176 instead of the OU in the certificate. Also renewed the text 3177 pointing out that the ACP information field in the certificate is 3178 meant to be in a form that it does not disturb other uses of the 3179 certificate. As long as the ACP expected to rely on a common OU 3180 across all certificates in a domain, this was not really true: 3181 Other uses of the certificates might require different OUs for 3182 different areas/type of devices. With the rules in this draft 3183 version, the ACP authentication does not rely on any other fields 3184 in the certificate. 3186 o Added an extension field to the ACP information field so that in 3187 the future additional fields like a subdomain could be inserted. 3188 An example using such a subdomain field was added to the pre- 3189 existing text suggesting sub-domains. This approach is necessary 3190 so that there can be a single (main) domain in the ACP information 3191 field, because that is used for mutual authentication of the 3192 certificate. Also clarified that only the register(s) SHOULD/MUST 3193 use that the ACP address was generated from the domain name - so 3194 that we can easier extend change this in extensions. 3196 o Took the text for the GRASP discovery of ACP neighbors from Brians 3197 grasp-ani-objectives draft. Alas, that draft was behind the 3198 latest GRASP draft, so i had to overhaul. The mayor change is to 3199 describe in the ACP draft the whole format of the M_FLOOD message 3200 (and not only the actual objective). This should make it a lot 3201 easier to read (without having to go back and forth to the GRASP 3202 RFC/draft). It was also necessary because the locator in the 3203 M_FLOOD messages has an important role and its not coded inside 3204 the objective. The specification of how to format the M_FLOOD 3205 message shuold now be complete, the text may be some duplicate 3206 with the DULL specificateion in GRASP, but no contradiction. 3208 o One of the main outcomes of reworking the GRASP section was the 3209 notion that GRASP announces both the candidate peers IPv6 link 3210 local address but also the support ACP security protocol including 3211 the port it is running on. In the past we shied away from using 3212 this information because it is not secured, but i think the 3213 additional attack vectors possible by using this information are 3214 negligible: If an attacker on an L2 subnet can fake another 3215 devices GRASP message then it can already provide a similar amount 3216 of attack by purely faking the link-local address. 3218 o Removed the section on discovery and BRSKI. This can be revived 3219 in the BRSKI document, but it seems mood given how we did remove 3220 mDNS from the latest BRSKI document (aka: this section discussed 3221 discrepancies between GRASP and mDNS discovery which should not 3222 exist anymore with latest BRSKI. 3224 o Tried to resolve the EDNOTE about CRL vs. OCSP by pointing out we 3225 do not specify which one is to be used but that the ACP should be 3226 used to reach the URL included in the certificate to get to the 3227 CRL storage or OCSP server. 3229 o Changed ACP via IPsec to ACP via IKEv2 and restructured the 3230 sections to make IPsec native and IPsec via GRE subsections. 3232 o No need for any assigned dTLS port if ACP is run across dTLS 3233 because it is signalled via GRASP. 3235 15.14. draft-ietf-anima-autonomic-control-plane-08 3237 Modified mentioning of BRSKI to make it consistent with current 3238 (07/2017) target for BRSKI: MASA and IDevID are mandatory. Devices 3239 with only insecure UDI would need a security reduced variant of 3240 BRSKI. Also added mentioning of Netconf Zerotouch. Made BRSKI non- 3241 normative for ACP because wrt. ACP it is just one option how the 3242 domain certificate can be provisioned. Instead, BRSKI is mandatory 3243 when a device implements ANI which is ACP+BRSKI. 3245 Enhanced text for ACP across tunnels to decribe two options: one 3246 across configured tunnels (GRE, IPinIP etc) a more efficient one via 3247 directed DULL. 3249 Moved decription of BRSKI to appendex to emphasize that BRSKI is not 3250 a (normative) dependency of GRASP, enhanced text to indicate other 3251 options how Domain Certificates can be provisioned. 3253 Added terminology section. 3255 Separated references into normative and non-normative. 3257 Enhanced section about ACP via "tunnels". Defined an option to run 3258 ACP secure channel without an outer tunnel, discussed PMTU, benefits 3259 of tunneling, potential of using this with BRSKI, made ACP via GREP a 3260 SHOULD requirement. 3262 Moved appendix sections up before IANA section because there where 3263 concerns about appendices to be to far on the bottom to be read. 3264 Added (Informative) / (Normative) to section titles to clarify which 3265 sections are informative and which are normative 3267 Moved explanation of ACP with L2 from precondition to separate 3268 section before workarounds, made it instructive enough to explain how 3269 to implement ACP on L2 ports for L3/L2 switches and made this part of 3270 normative requirement (L2/L3 switches SHOULD support this). 3272 Rewrote section "GRASP in the ACP" to define GRASP in ACP as 3273 mandatory (and why), and define the ACP as security and transport 3274 substrate to GRASP in ACP. And how it works. 3276 Enhanced "self-protection" properties section: protect legacy 3277 management protocols. Security in ACP is for protection from outside 3278 and those legacy protocols. Otherwise need end-to-end encryption 3279 also inside ACP, eg: with domain certificate. 3281 Enhanced initial domain certificate section to include requirements 3282 for maintenance (renewal/revocation) of certificates. Added 3283 explanation to BRSKI informative section how to handle very short 3284 lived certificates (renewal via BRSKI with expired cert). 3286 Modified the encoding of the ACP address to better fit RFC822 simple 3287 local-parts (":" as required by RFC5952 are not permitted in simple 3288 dot-atoms according to RFC5322. Removed reference to RFC5952 as its 3289 now not needed anymore. 3291 Introduced a sub-domain field in the ACP information in the 3292 certificate to allow defining such subdomains with depending on 3293 future Intent definitions. It also makes it clear what the "main 3294 domain" is. Scheme is called "routing subdomain" to have a unique 3295 name. 3297 Added V8 (now called Vlong) addressing sub-scheme according to 3298 suggestion from mcr in his mail from 30 Nov 2016 3299 (https://mailarchive.ietf.org/arch/msg/anima/ 3300 nZpEphrTqDCBdzsKMpaIn2gsIzI). Also modified the explanation of the 3301 single V bit in the first sub-scheme now renamed to Zone sub-scheme 3302 to distinguish it. 3304 15.15. draft-ietf-anima-autonomic-control-plane-09 3306 Added reference to RFC4191 and explained how it should be used on ACP 3307 edge routers to allow autoconfiguration of routing by NMS hosts. 3308 This came after review of stable connectivity draft where ACP connect 3309 is being referred to. 3311 V8 addressing Sub-Scheme was modified to allow not only /8 device- 3312 local address space but also /16. This was in response to the 3313 possible need to have maybe as much as 2^12 local addresses for 3314 future encaps in BRSKI like IPinIP. It also would allow fully 3315 autonomic address assignment for ACP connect interfaces from this 3316 local address space (on an ACP edge device), subject to approval of 3317 the implied update to rfc4291/rfc4193 (IID length). Changed name to 3318 Vlong addressing sub-scheme. 3320 Added text in response to Brian Carpenters review of draft-ietf- 3321 anima-stable-connectivity-04. The stable connectivity draft was 3322 vaguely describing ACP connect behavior that is better standardized 3323 in this ACP draft: 3325 o Added new ACP "Manual" addressing sub-scheme with /64 subnets for 3326 use with ACP connect interfaces. Being covered by the ACP ULA 3327 prefix, these subnets do not require additional routing entries 3328 for NMS hosts. They also are fully 64-bit IID length compliant 3329 and therefore not subject to 4191bis considerations. And they 3330 avoid that operators manually assign prefixes from the ACP ULA 3331 prefixes that might later be assigned autonomiously. 3333 o ACP connect auto-configuration: Defined that ACP edge devices, NMS 3334 hosts should use RFC4191 to automatically learn ACP prefixes. 3335 This is especially necessary when the ACP uses multiple ULA 3336 prefixes (via eg: the rsub domain certificate option), or if ACP 3337 connect subinterfaces use manually configured prefixes NOT covered 3338 by the ACP ULA prefixes. 3340 o Explained how rfc6724 is (only) sufficient when the NMS host has a 3341 separate ACP connect and data plane interface. But not when there 3342 is a single interface. 3344 o Added a separate subsection to talk about "software" instead of 3345 "NMS hosts" connecting to the ACP via the "ACP connect" method. 3346 The reason is to point out that the "ACP connect" method is not 3347 only a workaround (for NMS hosts), but an actual desirable long 3348 term architectural component to modularily build software (eg: ASA 3349 or OAM for VNF) into ACP devices. 3351 o Added a section to define how to run ACP connect across the same 3352 interface as the Data Plane. This turns out to be quite 3353 challenging because we only want to rely on existing standards for 3354 the network stack in the NMS host/software and only define what 3355 features the ACP edge device needs. 3357 o Added section about use of GRASP over ACP connect. 3359 o Added text to indicate packet processing/filtering for security: 3360 filter incorrect packets arriving on ACP connect interfaces, 3361 diagnose on RPL root packets to incorrect destination address (not 3362 in ACP connect section, but because of it). 3364 o Reaffirm security goal of ACP: Do not permit non-ACP routers into 3365 ACP routing domain. 3367 Made this ACP document be an update to RFC4291 and RFC4193. At the 3368 core, some of the ACP addressing sub-schemes do effectively not use 3369 64-bit IIDs as required by RFC4191 and debated in rfc4191bis. During 3370 6man in prague, it was suggested that all documents that do not do 3371 this should be classified as such updates. Add a rather long section 3372 that summarizes the relevant parts of ACP addressing and usage and. 3373 Aka: This section is meant to be the primary review section for 3374 readers interested in these changes (eg: 6man WG.). 3376 Added changes from Michael Richardsons review https://github.com/ 3377 anima-wg/autonomic-control-plane/pull/3/commits, textual and: 3379 o ACP discovery inside ACP is bad *doh*!. 3381 o Better CA trust and revocation sentences. 3383 o More details about RPL behavior in ACP. 3385 o blackhole route to avoid loops in RPL. 3387 Added requirement to terminate ACP channels upon cert expiry/ 3388 revocation. 3390 Added fixes from 08-mcr-review-reply.txt (on github): 3392 o AN Domain Names are FQDNs. 3394 o Fixed bit length of schemes, numerical writing of bits (00b/01b). 3396 o Lets use US american english. 3398 16. References 3400 16.1. Normative References 3402 [I-D.ietf-anima-grasp] 3403 Bormann, C., Carpenter, B., and B. Liu, "A Generic 3404 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 3405 grasp-15 (work in progress), July 2017. 3407 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 3408 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 3409 November 2005, . 3411 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 3412 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 3413 . 3415 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 3416 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 3417 2006, . 3419 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 3420 Address Autoconfiguration", RFC 4862, 3421 DOI 10.17487/RFC4862, September 2007, 3422 . 3424 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 3425 (TLS) Protocol Version 1.2", RFC 5246, 3426 DOI 10.17487/RFC5246, August 2008, 3427 . 3429 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 3430 Housley, R., and W. Polk, "Internet X.509 Public Key 3431 Infrastructure Certificate and Certificate Revocation List 3432 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 3433 . 3435 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 3436 DOI 10.17487/RFC5322, October 2008, 3437 . 3439 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 3440 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 3441 January 2012, . 3443 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 3444 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 3445 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 3446 Low-Power and Lossy Networks", RFC 6550, 3447 DOI 10.17487/RFC6550, March 2012, 3448 . 3450 [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing 3451 Protocol for Low-Power and Lossy Networks (RPL)", 3452 RFC 6552, DOI 10.17487/RFC6552, March 2012, 3453 . 3455 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 3456 "Enrollment over Secure Transport", RFC 7030, 3457 DOI 10.17487/RFC7030, October 2013, 3458 . 3460 [RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support 3461 for Generic Routing Encapsulation (GRE)", RFC 7676, 3462 DOI 10.17487/RFC7676, October 2015, 3463 . 3465 16.2. Informative References 3467 [I-D.ietf-anima-bootstrapping-keyinfra] 3468 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 3469 S., and K. Watsen, "Bootstrapping Remote Secure Key 3470 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 3471 keyinfra-07 (work in progress), July 2017. 3473 [I-D.ietf-anima-reference-model] 3474 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 3475 Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A 3476 Reference Model for Autonomic Networking", draft-ietf- 3477 anima-reference-model-04 (work in progress), July 2017. 3479 [I-D.ietf-anima-stable-connectivity] 3480 Eckert, T. and M. Behringer, "Using Autonomic Control 3481 Plane for Stable Connectivity of Network OAM", draft-ietf- 3482 anima-stable-connectivity-04 (work in progress), July 3483 2017. 3485 [I-D.ietf-netconf-zerotouch] 3486 Watsen, K., Abrahamsson, M., and I. Farrer, "Zero Touch 3487 Provisioning for NETCONF or RESTCONF based Management", 3488 draft-ietf-netconf-zerotouch-14 (work in progress), June 3489 2017. 3491 [I-D.ietf-roll-useofrplinfo] 3492 Robles, I., Richardson, M., and P. Thubert, "When to use 3493 RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll- 3494 useofrplinfo-16 (work in progress), July 2017. 3496 [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax 3497 Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998, 3498 . 3500 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 3501 Extensions for Stateless Address Autoconfiguration in 3502 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 3503 . 3505 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 3506 and A. Bierman, Ed., "Network Configuration Protocol 3507 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 3508 . 3510 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 3511 Power and Lossy Networks (RPL) Option for Carrying RPL 3512 Information in Data-Plane Datagrams", RFC 6553, 3513 DOI 10.17487/RFC6553, March 2012, 3514 . 3516 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 3517 "Default Address Selection for Internet Protocol Version 6 3518 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 3519 . 3521 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 3522 DOI 10.17487/RFC6762, February 2013, 3523 . 3525 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 3526 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 3527 . 3529 [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local 3530 Addressing inside an IPv6 Network", RFC 7404, 3531 DOI 10.17487/RFC7404, November 2014, 3532 . 3534 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 3535 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 3536 Networking: Definitions and Design Goals", RFC 7575, 3537 DOI 10.17487/RFC7575, June 2015, 3538 . 3540 [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap 3541 Analysis for Autonomic Networking", RFC 7576, 3542 DOI 10.17487/RFC7576, June 2015, 3543 . 3545 Authors' Addresses 3547 Michael H. Behringer (editor) 3549 Email: michael.h.behringer@gmail.com 3551 Toerless Eckert (editor) 3552 Futurewei Technologies Inc. 3553 2330 Central Expy 3554 Santa Clara 95050 3555 USA 3557 Email: tte+ietf@cs.fau.de 3559 Steinthor Bjarnason 3560 Arbor Networks 3561 2727 South State Street, Suite 200 3562 Ann Arbor MI 48104 3563 United States 3565 Email: sbjarnason@arbor.net