idnits 2.17.1 draft-ietf-anima-autonomic-control-plane-11.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- 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 684 has weird spacing: '... called ani....' == Line 1277 has weird spacing: '...k-local unic...' == Line 1278 has weird spacing: '...lticast messa...' == 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 (October 12, 2017) is 2389 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 2320, but not defined == Missing Reference: 'Select' is mentioned on line 2480, but not defined == Missing Reference: 'Plane' is mentioned on line 2482, but not defined == Unused Reference: 'RFC5790' is defined on line 4075, but no explicit reference was found in the text ** 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-06 == Outdated reference: A later version (-29) exists of draft-ietf-netconf-zerotouch-17 == Outdated reference: A later version (-44) exists of draft-ietf-roll-useofrplinfo-16 -- Obsolete informational reference (is this intentional?): RFC 2821 (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 2 errors (**), 0 flaws (~~), 15 warnings (==), 6 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: April 15, 2018 S. Bjarnason 7 Arbor Networks 8 October 12, 2017 10 An Autonomic Control Plane (ACP) 11 draft-ietf-anima-autonomic-control-plane-11 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 https://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 April 15, 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 (https://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 . . . . . . . . 9 61 3.2. Secure Bootstrap over an unconfigured Network . . . . . . 9 62 3.3. Data Plane Independent Permanent Reachability . . . . . . 9 63 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 10 64 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 12 66 6.1. Domain Certificate . . . . . . . . . . . . . . . . . . . 12 67 6.1.1. ACP information . . . . . . . . . . . . . . . . . . . 13 68 6.1.2. Maintenance . . . . . . . . . . . . . . . . . . . . . 15 69 6.2. AN Adjacency Table . . . . . . . . . . . . . . . . . . . 17 70 6.3. Neighbor Discovery with DULL GRASP . . . . . . . . . . . 18 71 6.4. Candidate ACP Neighbor Selection . . . . . . . . . . . . 21 72 6.5. Channel Selection . . . . . . . . . . . . . . . . . . . . 21 73 6.6. Candidate ACP Neighbor certificate verification . . . . . 23 74 6.7. Security Association protocols . . . . . . . . . . . . . 23 75 6.7.1. ACP via IKEv2 . . . . . . . . . . . . . . . . . . . . 23 76 6.7.2. ACP via dTLS . . . . . . . . . . . . . . . . . . . . 25 77 6.7.3. ACP Secure Channel Requirements . . . . . . . . . . . 25 78 6.8. GRASP in the ACP . . . . . . . . . . . . . . . . . . . . 25 79 6.8.1. GRASP as a core service of the ACP . . . . . . . . . 25 80 6.8.2. ACP as the Security and Transport substrate for GRASP 27 81 6.9. Context Separation . . . . . . . . . . . . . . . . . . . 30 82 6.10. Addressing inside the ACP . . . . . . . . . . . . . . . . 30 83 6.10.1. Fundamental Concepts of Autonomic Addressing . . . . 31 84 6.10.2. The ACP Addressing Base Scheme . . . . . . . . . . . 32 85 6.10.3. ACP Zone Addressing Sub-Scheme . . . . . . . . . . . 33 86 6.10.4. ACP Manual Addressing Sub-Scheme . . . . . . . . . . 35 87 6.10.5. ACP Vlong Addressing Sub-Scheme . . . . . . . . . . 36 88 6.10.6. Other ACP Addressing Sub-Schemes . . . . . . . . . . 37 89 6.11. Routing in the ACP . . . . . . . . . . . . . . . . . . . 37 90 6.11.1. RPL Profile . . . . . . . . . . . . . . . . . . . . 38 91 6.12. General ACP Considerations . . . . . . . . . . . . . . . 41 92 6.12.1. Performance . . . . . . . . . . . . . . . . . . . . 42 93 6.12.2. Addressing of Secure Channels in the data plane . . 42 94 6.12.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . 42 95 6.12.4. Multiple links between nodes . . . . . . . . . . . . 43 96 6.12.5. ACP interfaces . . . . . . . . . . . . . . . . . . . 43 98 7. ACP support on L2 switches/ports (Normative) . . . . . . . . 46 99 7.1. Why . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 100 7.2. How (per L2 port DULL GRASP) . . . . . . . . . . . . . . 47 101 8. Support for Non-Autonomic Components (Normative) . . . . . . 49 102 8.1. ACP Connect . . . . . . . . . . . . . . . . . . . . . . . 49 103 8.1.1. Non-Autonomic Controller / NMS system . . . . . . . . 49 104 8.1.2. Software Components . . . . . . . . . . . . . . . . . 51 105 8.1.3. Auto Configuration . . . . . . . . . . . . . . . . . 52 106 8.1.4. Combined ACP and Data Data Plane Interface (VRF 107 Select) . . . . . . . . . . . . . . . . . . . . . . . 53 108 8.1.5. Use of GRASP . . . . . . . . . . . . . . . . . . . . 55 109 8.2. ACP through Non-Autonomic L3 Clouds (Remote ACP 110 neighbors) . . . . . . . . . . . . . . . . . . . . . . . 55 111 8.2.1. Configured Remote ACP neighbor . . . . . . . . . . . 55 112 8.2.2. Tunneled Remote ACP Neighbor . . . . . . . . . . . . 57 113 8.2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 57 114 9. Benefits (Informative) . . . . . . . . . . . . . . . . . . . 57 115 9.1. Self-Healing Properties . . . . . . . . . . . . . . . . . 57 116 9.2. Self-Protection Properties . . . . . . . . . . . . . . . 59 117 9.2.1. From the outside . . . . . . . . . . . . . . . . . . 59 118 9.2.2. From the inside . . . . . . . . . . . . . . . . . . . 59 119 9.3. The Administrator View . . . . . . . . . . . . . . . . . 60 120 10. Further Considerations (Informative) . . . . . . . . . . . . 60 121 10.1. Domain Certificate provisioning / enrollment . . . . . . 61 122 10.2. ACP Neighbor discovery protocol selection . . . . . . . 62 123 10.2.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 62 124 10.2.2. mDNS and L2 support . . . . . . . . . . . . . . . . 62 125 10.2.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 63 126 10.3. Choice of routing protocol (RPL) . . . . . . . . . . . . 63 127 10.4. Extending ACP channel negotiation (via GRASP) . . . . . 64 128 10.5. CAs, domains and routing subdomains . . . . . . . . . . 66 129 11. RFC4291/RFC4193 Updates Considerations . . . . . . . . . . . 68 130 12. Security Considerations . . . . . . . . . . . . . . . . . . . 70 131 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71 132 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 72 133 15. Change log [RFC Editor: Please remove] . . . . . . . . . . . 72 134 15.1. Initial version . . . . . . . . . . . . . . . . . . . . 72 135 15.2. draft-behringer-anima-autonomic-control-plane-00 . . . . 72 136 15.3. draft-behringer-anima-autonomic-control-plane-01 . . . . 72 137 15.4. draft-behringer-anima-autonomic-control-plane-02 . . . . 72 138 15.5. draft-behringer-anima-autonomic-control-plane-03 . . . . 73 139 15.6. draft-ietf-anima-autonomic-control-plane-00 . . . . . . 73 140 15.7. draft-ietf-anima-autonomic-control-plane-01 . . . . . . 73 141 15.8. draft-ietf-anima-autonomic-control-plane-02 . . . . . . 74 142 15.9. draft-ietf-anima-autonomic-control-plane-03 . . . . . . 74 143 15.10. draft-ietf-anima-autonomic-control-plane-04 . . . . . . 75 144 15.11. draft-ietf-anima-autonomic-control-plane-05 . . . . . . 75 145 15.12. draft-ietf-anima-autonomic-control-plane-06 . . . . . . 76 146 15.13. draft-ietf-anima-autonomic-control-plane-07 . . . . . . 76 147 15.14. draft-ietf-anima-autonomic-control-plane-08 . . . . . . 78 148 15.15. draft-ietf-anima-autonomic-control-plane-09 . . . . . . 79 149 15.16. draft-ietf-anima-autonomic-control-plane-10 . . . . . . 81 150 15.17. draft-ietf-anima-autonomic-control-plane-11 . . . . . . 83 151 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 83 152 16.1. Normative References . . . . . . . . . . . . . . . . . . 83 153 16.2. Informative References . . . . . . . . . . . . . . . . . 85 154 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 88 156 1. Introduction 158 Autonomic Networking is a concept of self-management: Autonomic 159 functions self-configure, and negotiate parameters and settings 160 across the network.[RFC7575] defines the fundamental ideas and design 161 goals of Autonomic Networking. A gap analysis of Autonomic 162 Networking is given in [RFC7576]. The reference architecture for 163 Autonomic Networking in the IETF is currently being defined in the 164 document [I-D.ietf-anima-reference-model] 166 Autonomic functions need a stable and robust infrastructure to 167 communicate on. This infrastructure should be as robust as possible, 168 and it should be re-usable by all autonomic functions.[RFC7575] calls 169 it the "Autonomic Control Plane". This document defines the 170 Autonomic Control Plane. 172 Today, the management and control plane of networks typically runs in 173 the global routing table, which is dependent on correct configuration 174 and routing. Misconfigurations or routing problems can therefore 175 disrupt management and control channels. Traditionally, an out of 176 band network has been used to recover from such problems, or 177 personnel is sent on site to access devices through console ports 178 (craft ports). However, both options are operationally expensive. 180 In increasingly automated networks either controllers or distributed 181 autonomic service agents in the network require a control plane which 182 is independent of the network they manage, to avoid impacting their 183 own operations. 185 This document describes options for a self-forming, self-managing and 186 self-protecting "Autonomic Control Plane" (ACP) which is inband on 187 the network, yet as independent as possible of configuration, 188 addressing and routing problems (for details how this achieved, see 189 Section 6). It therefore remains operational even in the presence of 190 configuration errors, addressing or routing issues, or where policy 191 could inadvertently affect control plane connectivity. The Autonomic 192 Control Plane serves several purposes at the same time: 194 o Autonomic functions communicate over the ACP. The ACP therefore 195 supports directly Autonomic Networking functions, as described in 196 [I-D.ietf-anima-reference-model]. For example, GRASP 197 [I-D.ietf-anima-grasp] runs securely inside the ACP and depends on 198 the ACP as its "security and transport substrate". 200 o An operator can use it to log into remote devices, even if the 201 data plane is misconfigured or unconfigured. 203 o A controller or network management system can use it to securely 204 bootstrap network devices in remote locations, even if the network 205 in between is not yet configured; no data-plane dependent 206 bootstrap configuration is required. An example of such a secure 207 bootstrap process is described in 208 [I-D.ietf-anima-bootstrapping-keyinfra] 210 This document describes some use cases for the ACP in Section 3, it 211 defines the requirements in Section 4, Section 5 gives an overview 212 how an Autonomic Control Plane is constructed, and in Section 6 the 213 detailed process is explained.Section 8 explains how non-autonomic 214 nodes and networks can be integrated, and Section 6.7 the first 215 channel types for the ACP. 217 The document "Autonomic Network Stable Connectivity" 218 [I-D.ietf-anima-stable-connectivity] describes how the ACP can be 219 used to provide stable connectivity for OAM applications. It also 220 explains on how existing management solutions can leverage the ACP in 221 parallel with traditional management models, when to use the ACP 222 versus the data plane, how to integrate IPv4 based management, etc. 224 2. Terminology 226 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 227 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 228 "OPTIONAL" in this document are to be interpreted as described in 229 [RFC2119] when they appear in ALL CAPS. When these words are not in 230 ALL CAPS (such as "should" or "Should"), they have their usual 231 English meanings, and are not to be interpreted as [RFC2119] key 232 words. 234 This document uses the following terms (sorted alphabetically): 236 ACP "Autonomic Control Plane". The Autonomic Function defined in 237 this document. It provides secure zero-touch network wide IPv6 238 connectivity between devices supporting it. The ACP is primarily 239 meant to be used as a component of the ANI to enable Autonomic 240 Networks but it can equally be used in simple ANI networks (with 241 no other Autonomic Functions) or completely by itself. 243 ACP address An IPv6 ULA address assigned to the ACP device. It is 244 stored in the ACP information field of an ACP devices certificate 245 (LDevID). 247 (Device) ACP address range/set The ACP address may imply a range or 248 set of addresses that the device can assign for different 249 purposes. This address range/set is derived by the device from 250 the format of the ACP address called the "addressing sub-scheme". 252 ACP connect A physical interface on an ACP device providing access 253 to the ACP for non ACP capable devices. See Section 8.1.1. 255 ACP device A device supporting the ACP according to this document. 257 ACP information (field) An rfc822Name information element (eg: 258 field) in the Domain Certificate in which the ACP relevant 259 information is encoded: the AN Domain Name and the ACP address. 261 ACP (loopback) interface The loopback interface in the ACP VRF that 262 hosts the ACP address. 264 ACP (ULA) prefix(es) The prefixes routed across the ACP. In the 265 normal/simple case, the ACP has one ULA prefix, see Section 6.10. 266 The ACP routing table may include multiple ULA prefixes if the 267 "rsub" option is used to create addresses from more than one ULA 268 prefix. See Section 6.1.1. The ACP may also include non-ULA 269 prefixes if those are configured on ACP connect interfaces. See 270 Section 8.1.1. 272 ACP secure channel A virtual subinterface/tunnel established hop-by- 273 hop between adjacent ACP devices to carry traffic of the ACP VRF 274 separated from Data Plane traffic inband over the same links as 275 the Data Plane. 277 ACP secure channel protocol The protocol used to build an ACP secure 278 channel, eg: IKEv2/IPsec or dTLS. 280 ACP virtual interface An interface in the ACP VRF mapped to one or 281 more ACP secure channels. See Section 6.12.5. 283 AN "Autonomic Network". A network according to 284 [I-D.ietf-anima-reference-model]. Its main components are Intent, 285 Autonomic Functions and ANI. 287 AN Domain Name An FQDN (Fully Qualified Domain Name) identifying an 288 Autonomic Network. It is stored in the ACP information field of 289 an ANI devices LDevID. See Section 6.1.1. 291 ANI (device/network) "Autonomic Network Infrastructure". A device 292 with ANI supports ACP, BRSKI and GRASP. The ANI is the 293 infrastructure to enable autonomic functions. An ANI network or 294 device is a most basic Autonomic Network or device: it does not 295 need to have ASAs other than the ones implementing ACP, BRSKI and 296 GRASP nor Intent support. A simple ANI network (without further 297 autonomic functions) can for example support secure zero touch 298 bootstrap and stble connectivity for SDN networks - see 299 [I-D.ietf-anima-stable-connectivity]. 301 ANIMA "Autonomic Networking Integrated Model and Approach". ACP, 302 BRSKI and GRASP are work products of ANIMA. 304 ASA "Autonomic Service Agent". Autonomic software modules running 305 on an ANI device. The components making up the ANI (BRSKI, ACP, 306 GRASP) are also described as ASAs. 308 Autonomic Function A function/service in an Autonomic Network (AN) 309 composed of one or more ASA across one or more ANI Devices. 311 BRSKI "Bootstrapping Remote Secure Key Infrastructures" 312 ([I-D.ietf-anima-bootstrapping-keyinfra]. A protocol extending 313 EST to enable secure zero touch bootstrap in conjunction with ACP. 314 ANI devices use ACP and BRSKI. 316 Data Plane The counterpoint to the ACP in an ACP device: all VRFs 317 other than the ACP. In a simple ACP or ANI device, the Data Plane 318 is typically provisioned non-autonomic, for example manually 319 (including across the ACP) or via SDN controllers. In a full 320 Autonomic Network Device, the Data Plane is managed autonomically 321 via Autonomic Functions and Intent. 323 Domain Certificate An LDevID with an information element defined in 324 this document used by the ACP to derive and cryptographically 325 assert its membership in an autonomic domain. 327 enrollment The process where a device presents identification (for 328 example through keying material such as the private key of an 329 IDevID) to a network and acquires a network specific identity and 330 trust anchor such as an LDevID. 332 EST "Enrollment over Secure Transport" ([RFC7030]). IETF standard 333 protocol for enrollment of a device with an LDevID. BRSKI is 334 based on EST. 336 GRASP "Generic Autonomic Signaling Protocol". An extensible 337 signaling protocol required by the ACP for ACP neighbor discovery. 338 The ACP also provides the "security and transport substrate" for 339 the "ACP instance of GRASP" which is run inside the ACP to support 340 BRSKI and other future Autonomic Functions. See 341 [I-D.ietf-anima-grasp]. 343 IDevID An "Initial Device IDentity" X.509 certificate installed by 344 the vendor on new equipment. Contains information that 345 establishes the identity of the device in the context of its 346 vendor/manufacturer such as device model/type and serial number. 347 See [AR8021]. 349 Intent Northbound operator and automation facing interface of an 350 Autonomic Network according to [I-D.ietf-anima-reference-model]. 352 LDevID A "Local Device IDentity" X.509 certificate installed during 353 an "enrollment". The ACP depends on a Domain Certificate which is 354 an LDevID. See [AR8021]. 356 MIC "Manufacturer Installed Certificate". Another word not used in 357 this document to describe an IDevID. 359 RPL "IPv6 Routing Protocol for Low-Power and Lossy Networks". The 360 routing protocol used in the ACP. 362 MASA (service) "Manufacturer Authorized Signing Authority". A 363 vendor/manufacturer or delegated cloud service on the Internet 364 used as part of the BRSKI protocol. 366 sUDI "secured Unique Device Identifier". Another term not used in 367 this document to refer to an IDevID. 369 UDI "Unique Device Identifier". In the context of this document 370 unsecured identity information of a device typically consisting of 371 at least device model/type and serial number, often in a vendor 372 specific format. See sUDI and LDevID. 374 ULA A "Unique Local Address" (ULA) is an IPv6 address in the block 375 fc00::/7, defined in [RFC4193]. It is the approximate IPv6 376 counterpart of the IPv4 private address ([RFC1918]). 378 ACP VRF The ACP is modelled in this document as a "Virtual Routing 379 and Forwarding" (VRF) component in a network device. 381 3. Use Cases for an Autonomic Control Plane 382 3.1. An Infrastructure for Autonomic Functions 384 Autonomic Functions need a stable infrastructure to run on, and all 385 autonomic functions should use the same infrastructure to minimise 386 the complexity of the network. This way, there is only need for a 387 single discovery mechanism, a single security mechanism, and other 388 processes that distributed functions require. 390 3.2. Secure Bootstrap over an unconfigured Network 392 Today, bootstrapping a new device typically requires all devices 393 between a controlling node (such as an SDN controller) and the new 394 device to be completely and correctly addressed, configured and 395 secured. Therefore, bootstrapping a network happens in layers around 396 the controller. Without console access (for example through an out 397 of band network) it is not possible today to make devices securely 398 reachable before having configured the entire network leading up to 399 them. 401 With the ACP, secure bootstrap of new devices can happen without 402 requiring any configuration on the network. A new device can 403 automatically be bootstrapped in a secure fashion and be deployed 404 with a domain certificate. This does not require any configuration 405 on intermediate nodes, because they can communicate securely through 406 the ACP. 408 3.3. Data Plane Independent Permanent Reachability 410 Today, most critical control plane protocols and network management 411 protocols are running in the data plane (global routing table) of the 412 network. This leads to undesirable dependencies between control and 413 management plane on one side and the data plane on the other: Only if 414 the data plane is operational, will the other planes work as 415 expected. 417 Data plane connectivity can be affected by errors and faults, for 418 example certain AAA misconfigurations can lock an administrator out 419 of a device; routing or addressing issues can make a device 420 unreachable; shutting down interfaces over which a current management 421 session is running can lock an admin irreversibly out of the device. 422 Traditionally only console access can help recover from such issues. 424 Data plane dependencies also affect NOC/SDN controller applications: 425 Certain network changes are today hard to operate, because the change 426 itself may affect reachability of the devices. Examples are address 427 or mask changes, routing changes, or security policies. Today such 428 changes require precise hop-by-hop planning. 430 The ACP provides reachability that is largely independent of the data 431 plane, which allows control plane and management plane to operate 432 more robustly: 434 o For management plane protocols, the ACP provides the functionality 435 of a "Virtual-out-of-band (VooB) channel", by providing 436 connectivity to all devices regardless of their configuration or 437 global routing table. 439 o For control plane protocols, the ACP allows their operation even 440 when the data plane is temporarily faulty, or during transitional 441 events, such as routing changes, which may affect the control 442 plane at least temporarily. This is specifically important for 443 autonomic service agents, which could affect data plane 444 connectivity. 446 The document "Autonomic Network Stable Connectivity" 447 [I-D.ietf-anima-stable-connectivity] explains the use cases for the 448 ACP in significantly more detail and explains how the ACP can be used 449 in practical network operations. 451 4. Requirements 453 The Autonomic Control Plane has the following requirements: 455 ACP1: The ACP SHOULD provide robust connectivity: As far as 456 possible, it should be independent of configured addressing, 457 configuration and routing. Requirements 2 and 3 build on this 458 requirement, but also have value on their own. 460 ACP2: The ACP MUST have a separate address space from the data 461 plane. Reason: traceability, debug-ability, separation from 462 data plane, security (can block easily at edge). 464 ACP3: The ACP MUST use autonomically managed address space. Reason: 465 easy bootstrap and setup ("autonomic"); robustness (admin 466 can't mess things up so easily). This document suggests to 467 use ULA addressing for this purpose. 469 ACP4: The ACP MUST be generic. Usable by all the functions and 470 protocols of the AN infrastructure. It MUST NOT be tied to a 471 particular application or transport protocol. 473 ACP5: The ACP MUST provide security: Messages coming through the ACP 474 MUST be authenticated to be from a trusted node, and SHOULD 475 (very strong SHOULD) be encrypted. 477 The default mode of operation of the ACP is hop-by-hop, because this 478 interaction can be built on IPv6 link local addressing, which is 479 autonomic, and has no dependency on configuration (requirement 1). 480 It may be necessary to have ACP connectivity over non-autonomic 481 nodes, for example to link autonomic nodes over the general Internet. 482 This is possible, but then has a dependency on routing over the non- 483 autonomic hops (see Section 8.2). 485 5. Overview 487 The Autonomic Control Plane is constructed in the following way (for 488 details, see Section 6): 490 1. An autonomic node creates a virtual routing and forwarding (VRF) 491 instance, or a similar virtual context. 493 2. It determines, following a policy, a candidate peer list. This 494 is the list of nodes to which it should establish an Autonomic 495 Control Plane. Default policy is: To all link-layer adjacent 496 nodes in the same autonomic domain. 498 3. For each node in the candidate peer list, it authenticates that 499 node and negotiates a mutually acceptable channel type. 501 4. It then establishes a secure tunnel of the negotiated channel 502 type. These tunnels are placed into the previously set up VRF. 503 This creates an overlay network with hop-by-hop tunnels. 505 5. Inside the ACP VRF, each node sets up a virtual (loopback) 506 interface with its ULA IPv6 address. 508 6. Each node runs a lightweight routing protocol, to announce 509 reachability of the virtual addresses inside the ACP. 511 Note: 513 o Non-autonomic NMS systems or controllers have to be manually 514 connected into the ACP. 516 o Connecting over non-autonomic Layer-3 clouds initially requires a 517 tunnel between autonomic nodes. 519 o None of the above operations (except manual ones) is reflected in 520 the configuration of the device. 522 The following figure illustrates the ACP. 524 autonomic node 1 autonomic node 2 525 ................... ................... 526 secure . . secure . . secure 527 tunnel : +-----------+ : tunnel : +-----------+ : tunnel 528 ..--------| ACP VRF |---------------------| ACP VRF |---------.. 529 : / \ / \ <--routing--> / \ / \ : 530 : \ / \ / \ / \ / : 531 ..--------| virtual |---------------------| virtual |---------.. 532 : | interface | : : | interface | : 533 : +-----------+ : : +-----------+ : 534 : : : : 535 : data plane :...............: data plane : 536 : : link : : 537 :.................: :.................: 539 Figure 1 541 The resulting overlay network is normally based exclusively on hop- 542 by-hop tunnels. This is because addressing used on links is IPv6 543 link local addressing, which does not require any prior set-up. This 544 way the ACP can be built even if there is no configuration on the 545 devices, or if the data plane has issues such as addressing or 546 routing problems. 548 6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 550 This section describes the steps to set up an Autonomic Control Plane 551 (ACP), and highlights the key properties which make it 552 "indestructible" against many inadvert changes to the data plane, for 553 example caused by misconfigurations. 555 An ACP device can be a router, switch, controller, NMS host, or any 556 other IP device. Initially, it must have a globally unique domain 557 certificate (LDevID), as well as an adjacency table. It then can 558 start to discover ACP neighbors and build the ACP. This is described 559 step by step in the following sections: 561 6.1. Domain Certificate 563 To establish an ACP securely, an ACP device MUST have a globally 564 unique domain certificate (LDevID), with which it can 565 cryptographically assert its membership in the domain as well as the 566 CA certificate chain used to sign the LDevID. This CA certificate 567 chain is used to verify the LDevID of candidate ACP peers (see 568 Section 6.6). The ACP does not mandate specific mechanism by which 569 this certificate information is provisioned onto the ACP device, it 570 only requires the following ACP specific information field in its 571 LDevID as well as the LDevIDs of candidate ACP peers. See 572 Section 10.1 for more information about enrollment or provisioning 573 options. 575 6.1.1. ACP information 577 The domain certificate (LDevID) of an autonomic node MUST contain ACP 578 specific information, specifically the domain name, and the ACP 579 address of the device. This information MUST be encoded in the 580 LDevID in the subjectAltName / rfc822Name field according to the 581 following ABNF definition ([RFC5234]): 583 ani.acp+[+{+}}@ 585 acp-information = acp-device-info "@" acp-domain 587 acp-device-info = "ani.acp+" acp-address [ "+" rsub extensions ] 589 acp-address = 32hex-dig 591 hex-dig = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" 593 rsub = [ domain-name ] ; empty if not used 595 acp-domain = domain-name 597 routing-subdomain = [ rsub " ." ] acp-domain 599 domain-name = ; according to section 3.5 of [RFC1034] 601 extensions = *( "+" extension ) 603 extension = ; future definition. Must fit into [RFC5322] simple dot- 604 atom format. 606 Example: 608 acp-information = ani.acp+fda379a6f6ee00000200000064000000+area51.r 609 esearch@acp.example.com 611 routing-subdomain = area51.research.acp.example.com 613 "acp-address" can not use standard IPv6 address formats because it 614 must match the simple dot-atom format of [RFC5322]. ":" are not 615 allowed in that format. 617 "acp-domain" is used to indicate the Autonomic Domain across which 618 all ACP nodes trust each other and are willing to build ACP channel 619 with each other. See Section 6.6. It SHOULD be the FQDN of a domain 620 owned by the operator assigning the certificate. This is a simple 621 method to ensure that the acp-domain is globally unique and collision 622 of ACP addresses would therefore only happen due to ULA hash 623 collisions. If the operator does not own any FQDN, it should choose 624 a string in FQDN format that intends to be equally unique. 626 "routing-subdomain" is the autonomic subdomain that is used to 627 calculate the hash for the ULA prefix of the ACP address of the 628 device. "rsub" is optional and should only used when its impacts are 629 understood. When "rsub" is not used, "routing-subdomain" is "acp- 630 domain". 632 The optional "extensions" field is used for future extensions to this 633 specification. It MUST be ignored if present and not understood. 635 Note that the maximum size of "acp-information" is 254 characters and 636 the maximum size of acp-device-info is 64 characters according to 637 [RFC5280] that is referring to [RFC2821] (superceeded by [RFC5321]). 639 The subjectAlName / rfc822Name encoding of the ACP domain name and 640 ACP address is used for the following reasons: 642 o There are a wide range of pre-existing protocols/services where 643 authentication with LDevID is desirable. Enrolling and 644 maintaining separate LDevIDs for each of these protocols/services 645 is often undesirable overhead. Therefore, the information element 646 required for the ACP in the domain certificate should be encoded 647 in a way that minimizes the possibility of creating 648 incompatibilites with such other uses beside the authentication 649 for the ACP. 651 o The elements in the LDevID required for the ACP should not cause 652 incompatibilities with any pre-existing ASN.1 software potentially 653 in use in those other pre-existing SW systems. This eliminates 654 the use of novel information elements because those require 655 extensions to those pre-existing ASN.1 parsers. 657 o subjectAltname / rfc822Name is a pre-existing element that must be 658 supported by all existing ASN.1 parsers for LDevID. 660 o The elements in the LDevID required for the ACP should also not be 661 misinterpreted by any pre-existing protocol/service that might use 662 the LDevID. If the elements used for the ACP are interpreted by 663 other protocols/services, then the impact should be benign. 665 o Using an IP address format encoding could result in non-benign 666 misinterpretation of the ACP information, for example other 667 protocol/services unaware of the ACP could try to do something 668 with the ACP address that would fail to work correctly. For 669 example, the address could be interpreted to be an address of the 670 device in a VRF other than the ACP VRF. 672 o At minimum, both the AN domain name and the non-domain name 673 derived part of the ACP address need to be encoded in one or more 674 appropriate fields of the certificate, so there are not many 675 alternatives with pre-existing fields where the only possible 676 conflicts would likely be beneficial. 678 o rfc822Name encoding is quite flexible. We choose to encode the 679 full ACP address AND the domain name with sub part into a single 680 rfc822Name information element it, so that it is easier to 681 examine/use the encoded "ACP information (field)". 683 o The format of the rfc822Name is choosen so that an operator can 684 set up a mailbox called ani.acp@ that would receive 685 emails sent towards the rfc822Name of any AN device inside a 686 domain. This is possible because in many modern mail systems, 687 components behind a plus symbol are considered part of a single 688 mailbox. In other words, it is not necessary to set up a separate 689 mailbox for every autonomic devices ACP information field, but 690 only one for the whole domain. 692 o In result, if any unexpected use of the ACP addressing information 693 in a certificate happens, it is benign and detectable: it would be 694 mail to that mailbox. 696 See section 4.2.1.6 of [RFC5280] for details on the subjectAltName 697 field. 699 6.1.2. Maintenance 701 The ACP network MUST have one or more nodes that support EST server 702 ([RFC7030] functionality (eg: as an ASA) through which ACP nodes can 703 renew their domain certificate. The ACP address of at least one such 704 EST server SHOULD have been enrolled/provisioned into the ACP device 705 during initial installation of the domain certificate. 707 EST servers MUST announce their service via GRASP in the ACP through 708 M_FLOOD messages: 710 Example: 712 [M_FLOOD, 12340815, h'fda379a6f6ee0000200000064000001', 180000, 713 ["AN_join_registrar", 4, 255, "EST-TLS"], 714 [O_IPv6_LOCATOR, 715 h'fda379a6f6ee0000200000064000001', TCP, 80] 716 ] 718 The formal CDDL definition is: 720 flood-message = [M_FLOOD, session-id, initiator, ttl, 721 +[objective, (locator-option / [])]] 723 objective = ["AN_join_registrar", objective-flags, loop-count, 724 objective-value] 726 objective-flags = sync-only ; as in GRASP spec 727 sync-only = 4 ; M_FLOOD only requires synchronization 728 loop-count = 255 ; mandatory maximum 729 objective-value = text ; name of the (list of) of supported 730 ; protocols: "EST-TLS" for RFC7030. 732 The M_FLOOD message MUST be sent periodically. The period is subject 733 to network administrator policy (EST server configuration). It must 734 be so low that the aggregate amount of periodic M_FLOODs from all EST 735 servers causes negligible traffic across the ACP. 737 In the above (recommended) example the period could be 60 seconds and 738 the indicated ttl of 180000 msec means that the objective would 739 continuously be cached by ACP devices even when two out of three 740 messages are dropped in transit (which is unlikely because GRASP hop- 741 by-hop forwarding is realiable). 743 The locator-option indicates the ACP transport address for the EST 744 server. The loop-count MUST be sete to 255. When an ACP node 745 receives the M_FLOOD, it will have been reduced by the number of hops 746 from the EST server. 748 When it is time for domain certificate reneal, the ACP device MUST 749 attempt to connect to the EST server(s) learned via GRASP starting 750 with the one that has the highest remaining loop-count (closest one). 751 If certificate renewal does not succeed, the device MUST attempt to 752 use the EST server(s) learned during initial provisioning/enrollment 753 of the certificate. After successful renewal of the domain 754 certificate, the ACP address from the certificate of the EST server 755 (as learned during the TLS handshake) is added to the top of the list 756 or provisioned/configured EST-server(s). 758 This logic of selecting an EST server for renewal is choosen to allow 759 for distributed EST servers to be used effectively but to also allow 760 fallback to the most reliably learned EST server - those that 761 performed already successful enrollment in before. A compromised 762 (non EST-server) ACP device for example can filter or fake GRASP 763 announcements, but it can not successfully renew a certificate and 764 can only prohibit traffic to a valid EST server when it is on the 765 path between the ACP device and the EST server. 767 The ACP device MUST support Certificate Revocation Lists via HTTPs 768 from one or more Certificate Distribution Points. These CDPs MUST be 769 indicated in the Domain Certificate when used. If the CDP URL uses 770 an IPv6 ULA, the ACP device will try to reach it via the ACP. In 771 that case the ACP address in the domain certificate of the CDP as 772 learned by the ACP device during the HTTPs TLS handshake MUST match 773 that ULA address in the HTTPs URL. 775 Renewal of certificates SHOULD start after less than 50% of the 776 domain certificate lifetime so that network operations has ample time 777 to investigate and resolve any problems that cause a device to not 778 renew its domain certificate in time - and to allow prolonged periods 779 of running parts of a network disconnected from any CA. 781 Certificate lifetime should be set to be as short as feasible. Given 782 how certificate renewal is fully automated via ACP and EST, the 783 primarily imiting factor for shorter certificate lifetimes (than the 784 typical one year) is load on the EST server(s) and CA. It is 785 therefore recommended that ACP domain certificates are managed via a 786 CA chain where the assigning CA has enough peformance to manage short 787 lived certificates. 789 See Section 10.1 for further optimizations of certificate 790 optimizations when BRSKI can be used. 792 6.2. AN Adjacency Table 794 To know to which nodes to establish an ACP channel, every autonomic 795 node maintains an adjacency table. The adjacency table contains 796 information about adjacent autonomic nodes, at a minimum: node-ID, 797 Link-local IPv6 address (discovered by GRASP as explained below), 798 domain, certificate. An autonomic device MUST maintain this 799 adjacency table up to date. This table is used to determine to which 800 neighbor an ACP connection is established. 802 Where the next autonomic device is not directly adjacent, the 803 information in the adjacency table can be supplemented by 804 configuration. For example, the node-ID and IP address could be 805 configured. 807 The adjacency table MAY contain information about the validity and 808 trust of the adjacent autonomic node's certificate. However, 809 subsequent steps MUST always start with authenticating the peer. 811 The adjacency table contains information about adjacent autonomic 812 nodes in general, independently of their domain and trust status. 813 The next step determines to which of those autonomic nodes an ACP 814 connection should be established. 816 Interaction between ACP and other autonomic elements like GRASP (see 817 below) or ASAs should be via an API that allows (appropriately access 818 controlled) read/write access to the AN Adjacency Table. 819 Specification of such an API is subject to future work. 821 6.3. Neighbor Discovery with DULL GRASP 823 Because of the the considerations in Section 10.2, the ACP uses DULL 824 (Discovery Unsolicited Link-Local) insecure instances of GRASP for 825 discovery of ACP neighbors. See section 3.5.2.2 of 826 [I-D.ietf-anima-grasp] for its formal definition. 828 The ACP uses one instance of DULL GRASP for every physical L2 subnet 829 of the ACP device to discovery physically adjacent candidate ACP 830 neighbors. Ideally, all physical interfaces SHOULD be brought up 831 enough so that ACP discovery can be performed and any physically 832 connected interfaces with ACP neighbors can then be brought into the 833 ACP even if the interface is otherwise not configured. Reception of 834 packets on such otherwise unconfigure interfaces MUST be limited so 835 that at first only IPv6 link-local address assignment (SLAAC) and 836 DULL GRASP works and then only the following ACP secure channel setup 837 packets - but not any other unnecessary traffic (eg: no other link- 838 local IPv6 transport stack responders for example). 840 Note that the use of the IPv6 link-local multicast address 841 (ALL_GRASP_NEIGHBORS) implies the need to use MLD ([RFC3810]) to 842 announce the desire to receive packets for that address. Otherwise 843 DULL GRASP could fail to operate correctly in the presence of MLD 844 snooping, non-ACP enabled L2 switches - because those would stop 845 forwarding DULL GRASP packets. Switches not supporting MLD snooping 846 simply need to operate as pure L2 bridges for IPv6 multicast packets 847 for DULL GRASP to work. 849 ACP discovery MUST NOT be enabled by default on any non-physical 850 interfaces. In particular, ACP discovery MUST NOT run inside the 851 ACP. See Section 8.2.2 how to enable and use ACP with auto-discovery 852 across configured tunnels. 854 See Section 7 for how ACP should be extended on L3/L2 devices. 856 Note: If an ACP device also implements BRSKI (see Section 10.1) then 857 the above considerations also apply to discovery for BRSKI. Each 858 DULL instance of GRASP set up for ACP is then also used for the 859 discovery of a bootstrap proxy via BRSKI when the device does not 860 have a domain certificate. Discovery of ACP neighbors happens only 861 when the device does have the certificate. The device therefore 862 never needs to discover both a bootstrap proxy and ACP neighbor at 863 the same time. 865 An autonomic node announces itself to potential ACP peers by use of 866 the "AN_ACP" objective. This is a synchronization objective intended 867 to be flooded on a single link using the GRASP Flood Synchronization 868 (M_FLOOD) message. In accordance with the design of the Flood 869 message, a locator consisting of a specific link-local IP address, IP 870 protocol number and port number will be distributed with the flooded 871 objective. An example of the message is informally: 873 Example: 875 [M_FLOOD, 12340815, h'fe80000000000000c0011001FEEF0000, 180000, 876 ["AN_ACP", 4, 1, "IKEv2"], 877 [O_IPv6_LOCATOR, 878 h'fe80000000000000c0011001FEEF0000, UDP, 15000] 879 ] 881 The formal CDDL definition is: 883 flood-message = [M_FLOOD, session-id, initiator, ttl, 884 +[objective, (locator-option / [])]] 886 objective = ["AN_ACP", objective-flags, loop-count, 887 objective-value] 889 objective-flags = sync-only ; as in the GRASP specification 890 sync-only = 4 ; M_FLOOD only requires synchronization 891 loop-count = 1 ; limit to link-local operation 892 objective-value = text ; name of the (list of) secure 893 ; channel negotiation protocol(s) 895 The objective-flags field is set to indicate synchronization. 897 The loop-count is fixed at 1 since this is a link-local operation. 899 In the above (recommended) example the period of sending of the 900 objective could be 60 seconds the indicated ttl of 180000 msec means 901 that the objective would be cached by ACP devices even when two out 902 of three messages are dropped in transit. 904 The session-id is a random number used for loop prevention 905 (distinguishing a message from a prior instance of the same message). 906 In DULL this field is irrelevant but must still be set according to 907 the GRASP specification. 909 The originator MUST be the IPv6 link local address of the originating 910 autonomic node on the sending interface. 912 The 'objective-value' parameter is (normally) a string indicating the 913 secure channel protocol available at the specified or implied 914 locator. 916 The locator is optional and only required when the secure channel 917 protocol is not offered at a well-defined port number, or if there is 918 no well defined port number. For example, "IKEv2" has a well defined 919 port number 500, but in the above example, the candidate ACP neighbor 920 is offering ACP secure channel negotiation via IKEv2 on port 15000 921 (for the sake of creating a non-standard example). 923 If a locator is included, it MUST be an O_IPv6_LOCATOR, and the IPv6 924 address MUST be the same as the initiator address (these are DULL 925 requirements to minimize third party DoS attacks). 927 The secure channel methods defined in this document use the objective 928 values of "IKEv2" and "dTLS". There is no distinction between IKEv2 929 native and GRE-IKEv2 because this is purely negotiated via IKEv2. 931 A node that supports more than one secure channel protocol needs to 932 flood multiple versions of the "AN_ACP" objective, each accompanied 933 by its own locator. This can be in a single GRASP M_FLOOD message. 935 If multiple secure channel protocols are supported that all are run 936 on well-defined ports, then they can be announced via a single AN_ACP 937 objective using a list of string names as the objective value without 938 a following locator-option. 940 Note that a node serving both as an ACP node and BRSKI Join Proxy may 941 choose to distribute the "AN_ACP" objective and "AN_join_proxy" 942 objective in the same flood message, since GRASP allows multiple 943 objectives in one Flood message. This may be impractical though if 944 ACP and BRSKI operations are implemented via separate software 945 modules / ASAs though. 947 The result of the discovery is the IPv6 link-local address of the 948 neighbor as well as its supported secure channel protocols (and non- 949 standard port they are running on). It is stored in the AN Adjacency 950 Table, see Section 6.2 which then drives the further building of the 951 ACP to that neighbor. 953 6.4. Candidate ACP Neighbor Selection 955 An autonomic node must determine to which other autonomic nodes in 956 the adjacency table it should build an ACP connection. This is based 957 on the information in the AN Adjacency table. 959 The ACP is by default established exclusively between nodes in the 960 same domain. This includes all routing subdomains. Section 10.5 961 explains how ACP connections across multiple routing subdomains are 962 special. 964 Future extensions to this document including Intent can change this 965 default behaviour. Examples include: 967 o Build the ACP across all domains that have a common parent domain. 968 For example ACP nodes with domain "example.com", nodes of 969 "example.com", "access.example.com", "core.example.com" and 970 "city.core.example.com" could all establish one single ACP. 972 o ACP connections across domains with different CA (certificate 973 authorities) could establish a common ACP by installing the 974 alternate domains' CA into the trusted anchor store. This is an 975 executive management action that could easily be accomplished 976 through the control channel created by the ACP. 978 Since Intent is transported over the ACP, the first ACP connection a 979 node establishes is always following the default behaviour. See 980 Section 10.5 for more details. 982 The result of the candidate ACP neighbor selection process is a list 983 of adjacent or configured autonomic neighbors to which an ACP channel 984 should be established. The next step begins that channel 985 establishment. 987 6.5. Channel Selection 989 To avoid attacks, initial discovery of candidate ACP peers can not 990 include any non-protected negotiation. To avoid re-inventing and 991 validating security association mechanisms, the next step after 992 discoving the address of a candidate neighbor can only be to try 993 first to establish a security association with that neighbor using a 994 well-known security association method. 996 At this time in the lifecycle of autonomic devices, it is unclear 997 whether it is feasible to even decide on a single MTI (mandatory to 998 implement) security association protocol across all autonomic 999 devices: 1001 From the use-cases it seems clear that not all type of autonomic 1002 devices can or need to connect directly to each other or are able to 1003 support or prefer all possible mechanisms. For example, code space 1004 limited IoT devices may only support dTLS (because that code exists 1005 already on them for end-to-end security use-cases), but low-end in- 1006 ceiling L2 switches may only want to support MacSec because that is 1007 also supported in HW, and only a more flexible gateway device may 1008 need to support both of these mechanisms and potentially more. 1010 To support extensible secure channel protocol selection without a 1011 single common MTI protocol, autonomic devices must try all the ACP 1012 secure channel protocols it supports and that are feasible because 1013 the candidate ACP neighbor also announced them via its AN_ACP GRASP 1014 parameters (these are called the "feasible" ACP secure channel 1015 protocols). 1017 To ensure that the selection of the secure channel protocols always 1018 succeeds in a predictable fashion without blocking, the following 1019 rules apply: 1021 An autonomic device may choose to attempt initiate the different 1022 feasible ACP secure channel protocol it supports according to its 1023 local policies sequentially or in parallel, but it MUST support 1024 acting as a responder to all of them in parallel. 1026 Once the first secure channel protocol succeeds, the two peers know 1027 each others certificates (because that must be used by all secure 1028 channel protocols for mutual authentication. The device with the 1029 lower Device-ID in the ACP address becomes Bob, the one with the 1030 higher Device-ID in the certificate Alice. 1032 Bob becomes passive, he does not attempt to further initiate ACP 1033 secure channel protocols with Alice and does not consider it to be an 1034 error when Alice closes secure channels. Alice becomes the active 1035 party, continues to attempt setting up secure channel protocols with 1036 Bob until she arrives at the best one (from her view) that also works 1037 with Bob. 1039 For example, originally Bob could have been the initiator of one ACP 1040 secure channel protocol that Bob preferred and the security 1041 association succeeded. The roles of Bob abd Alice are then assigned. 1042 At this stage, the protocol may not even have completed negotiating a 1043 common security profile. The protocol could for example have been 1044 IPsec. It is not up to Alice to devide how to proceed. Even if the 1045 IPsec connecting determined a working profile with Bob, Alice might 1046 prefer some other secure protocol (eg: dTLS) and try to set that up 1047 with Bob. If that succeeds, she would close the IPsec connection. If 1048 no better protocol attempt succeeds, she would keep the IPsec 1049 connection. 1051 All this negotiation is in the context of an "L2 interface". Alice 1052 and Bob will build ACP connections to each other on every "L2 1053 interface" that they both connect to. An autonomic device must not 1054 assume that neighbors with the same L2 or link-local IPv6 addresses 1055 on different L2 interfaces are the ame devices. This can only be 1056 determined after examining the certificate after a successful 1057 security association attempt. 1059 6.6. Candidate ACP Neighbor certificate verification 1061 Independent of the security association protocol choosen, candidate 1062 ACP neighbors need to be authenticated based on their autonomic 1063 domain certificate. This implies that any security association 1064 protocol MUST support certificate based authentication that can 1065 support the following verification steps: 1067 o The certificate is valid as proven by the security associations 1068 protocol exchanges. 1070 o The peers certificate is signed by the same CA as the devices 1071 domain certificate. 1073 o If the device certificates indicate a CDP or OCSP then the peer's 1074 certificate must be valid occording to those criteria. eg: OCSP 1075 check across the ACP or not listed in the CRL. 1077 o The peers certificate has a valid ACP information field 1078 (subjectAltName / rfc822Name) and the domain name in that peers 1079 ACP information field is the same as in the devices certificate. 1080 Note that future Intent rules may modify this. See Section 10.5. 1082 If the peers certificate fails any of these checks, the connection 1083 attempt is aborted and an error logged (with throttling). 1085 6.7. Security Association protocols 1087 The following sections define the security association protocols that 1088 we consider to be important and feasible to specify in this document: 1090 6.7.1. ACP via IKEv2 1092 An autonomic device announces its ability to support IKEv2 as the ACP 1093 secure channel protcol in GRASP as "IKEv2". 1095 6.7.1.1. Native IPsec 1097 To run ACP via IPsec natively, no further IANA assignments/ 1098 definitions are required. An ACP devices supporting native IPsec 1099 MUST use IPsec security setup via IKEv2, tunnel mode, local and peer 1100 link-local IPv6 addresses used for encapsuation, ESP with AES256 for 1101 encryption and SHA256 hash. 1103 In terms of IKEv2, this means the initiator will offer to support 1104 IPsec tunnel mode with next protocol equal 41 (IPv6). 1106 IPsec tunnel mode is required because the ACP will route/forward 1107 packets received from any other ACP device across the ACP secure 1108 channels, and not only its own generated ACP packets. With IPsec 1109 transport mode, it would only be possible to send packets originated 1110 by the ACP device itself. 1112 ESP is used because ACP mandates the use of encryption for ACP secure 1113 channels. 1115 6.7.1.2. IPsec with GRE encapsulation 1117 In network devices it is often more common to implement high 1118 performance virtual interfaces on top of GRE encapsulation than 1119 natively on top of a native IPsec association. On those devices it 1120 may be beneficial to run the ACP secure channel on top of GRE 1121 protected by the IPsec association. 1123 To run ACP via GRE/IPsec, no further IANA assignments/definitions are 1124 required. The ACP device MUST support IPsec security setup via 1125 IKEv2, IPsec transport mode, local and peer link-local IPv6 addresses 1126 used for encapsuation, ESP with AES256 encryption and SHA256 hash. 1128 When GRE is used, transport mode is sufficient because the routed ACP 1129 packets are not "tunneled" by IPsec but rather by GRE: IPsec only has 1130 to deal with the GRE/IP packet which always uses the local and peer 1131 link-local IPv6 addresses and is therefore applicable to transport 1132 mode. 1134 ESP is used because ACP mandates the use of encryption for ACP secure 1135 channels. 1137 In terms of IKEv2 negotiation, this means the initiator must offer to 1138 support IPsec transport mode with next protocol equal to GRE (47) 1139 followed by the offer for native IPsec as described above (because 1140 that option is mandatory to support). 1142 If IKEv2 initiator and responder support GRE, it will be selected. 1143 The version of GRE to be used must the according to [RFC7676]. 1145 6.7.2. ACP via dTLS 1147 We define the use of ACP via dTLS in the assumption that it is likely 1148 the first transport encryption code basis supported in some classes 1149 of constrained devices. 1151 To run ACP via UDP and dTLS v1.2 [RFC6347] a locally assigned UDP 1152 port is used that is announced as a parameter in the GRASP AN_ACP 1153 objective to candidate neighbors. All autonomic devices supporting 1154 ACP via dTLS MUST support AES256 encryption and not permit weaker 1155 crypto options. 1157 There is no additional session setup or other security association 1158 besides this simple dTLS setup. As soon as the dTLS session is 1159 functional, the ACP peers will exchange ACP IPv6 packets as the 1160 payload of the dTLS transport connection. Any dTLS defined security 1161 association mechanisms such as re-keying are used as they would be 1162 for any transport application relying solely on dTLS. 1164 6.7.3. ACP Secure Channel Requirements 1166 A baseline autonomic device MUST support IPsec natively and MAY 1167 support IPsec via GRE. A constrained autonomic device MUST support 1168 dTLS. Autonomic edge device connecting constrained areas with 1169 baseline areas MUST therefore support IPsec and dTLS. 1171 Autonomic devices need to specify in documentation the set of secure 1172 ACP mechanisms they suppport. 1174 ACP secure channel MUST imediately be terminated when the lifetime of 1175 any certificate in the chain used to authenticate the neighbor 1176 expires or becomes revoked. Note that is is not standard behavior in 1177 secure channel protocols such as IPsec because the certificate 1178 authentication only influences the setup of the secure channel in 1179 these protocols. 1181 6.8. GRASP in the ACP 1183 6.8.1. GRASP as a core service of the ACP 1185 The ACP MUST run an instance of GRASP inside of it. It is a key part 1186 of the ACP services. They function in GRASP that makes it 1187 fundamental as a service is the ability for ACP wide service 1188 discovery (called objectives in GRASP). In most other solution 1189 designs such distributed discovery does not exist at all or was added 1190 as an afterthought and relied upon inconsistently. 1192 ACP provides IP unicast routing via the RPL routing protocol 1193 (described below). 1195 The ACP does not use IP multicast routing nor does it provide generic 1196 IP multicast services. Instead, the ACP provides service discovery 1197 via the objective discovery/announcement and negotiation mechanisms 1198 of the ACP GRASP instance (services are a form of objectives). These 1199 mechanisms use hop-by-hop reliable flooding of GRASP messages for 1200 both service discovery (GRASP M_DISCOVERY messages) and service 1201 announcement (GRASP M_FLOOD messages). 1203 IP multicast is not used by the ACP because the ANI itself does not 1204 require IP multicast but only service announcement/discovery. Using 1205 IP multicast for that would have made it necessary to develop a zero- 1206 touch autoconfiguring solution for ASM (Any Source Multicast - 1207 original form of IP multicast defined in [RFC1112]), which would be 1208 quite complex and difficult to justify. One aspect of complexity 1209 that has never been attempted to be solved in IETF documents is the 1210 automatic-selection of routers that should be PIM-SM rendezvous 1211 points (RPs) (see xref target="RFC7761"/>. The other aspects of 1212 complexity are the implementation of MLD ([RFC4604]), PIM-SM and 1213 Anycast-RP (see [RFC4610]). If those implementations already exist 1214 in a product, then they would be very likely tied to accelerated 1215 forwarding which consumes hardware resources, and that in return is 1216 difficult to justify as a cost of performing only service discovery. 1218 Future ASA may need high performance in-network data replication. 1219 That is the case when the use of IP multicast is justified. These 1220 ASA can then use service discovery from ACP GRASP, and then they do 1221 not need ASM but only SSM (Source Specific Multicast, see xref 1222 target="RFC4607"/>) for the IP multicast replication. SSM itself can 1223 simply be enabled in the data plane (or even in an update to the ACP) 1224 without any other configuration than just enabling it on all nodes 1225 and only requires a simpler version of MLD (see [RFC5790]). 1227 LSP (Link State Protocol) based IGP routing protocols typically have 1228 a mechanism to flood information, and such a mechanism could be used 1229 to flood GRASP objectives by defining them to be information of that 1230 IGP. This would be a possible optimization in future variations of 1231 the ACP that do use an LSP routing protocol. Note though that such a 1232 mechanism would not work easily for GRASP M_DISCOVERY messages which 1233 are constrained flooded up to a node where a responder is found. We 1234 do expect that many future services in ASA will have only few 1235 consuming ASA, and for those cases, M_DISCOVERY is the more efficient 1236 method than flooding across the whole domain. 1238 Beceause the ACP uses RPL, one desireable future extension is to use 1239 RPLs existing notion of loop-free distribution trees (DODAG) to make 1240 GRASPs flooding more efficient both for M_FLOOD and M_DISCOVERY) See 1241 Section 6.12.5 how this will be specifically beneficial when using 1242 NBMA interfaces. For robustness and easyness, this is not currently 1243 used in this document because it is not quite clear yet what exactly 1244 the implications are to make GRASP flooding depend on RPL DODAG 1245 convergence and how difficult it would be to let GRASP flooding 1246 access the DODAG information. 1248 6.8.2. ACP as the Security and Transport substrate for GRASP 1250 In the terminology of GRASP ([I-D.ietf-anima-grasp]), the ACP is the 1251 security and transport substrate for the GRASP instance run inside 1252 the ACP ("ACP GRASP"). 1254 This means that the ACP is responsible to ensure that this instance 1255 of GRASP is only sending messages across the virtual interfaces 1256 created by the ACP for ACP GRASP. Whenever the ACP adds or deletes 1257 such an interface (because of new ACP secure channels or loss 1258 thereof), the ACP needs to indicate this to the ACP instance of 1259 GRASP. The ACP exists also in the absence of any active ACP 1260 neighbors. It is created when the device has a domain certificate. 1261 In this case ASAs using GRASP running on the same device would still 1262 need to be able to discover each others objectives. When the ACP 1263 does not exist, ASAs leveraging the ACP instance of GRASP via APIs 1264 MUST still be able to operate, and MUST be able to understand that 1265 there is no ACP and that therefore the ACP instance of GRASP can not 1266 provide services. 1268 The way ACP acts as the security and transport substrate for GRASP is 1269 visualized in the following picture: 1271 ACP: 1272 ............................................................... 1273 . . 1274 . /-GRASP-flooding-\ ACP GRASP instance . 1275 . / \ . 1276 . GRASP GRASP GRASP . 1277 . link-local unicast link-local . 1278 . multicast messages multicast . 1279 . messages | messages . 1280 . | | | . 1281 ............................................................... 1282 . v v v ACP security and transport . 1283 . | | | substrate for GRASP . 1284 . | | | . 1285 . | ACP GRASP | - ACP GRASP loopback . 1287 . | loopback | loopback interface . 1288 . | TLS | - AN-cert auth . 1289 . | | | . 1290 . ACP GRASP | ACP GRASP - ACP GRASP virtual . 1291 . subnet1 | subnet2 virtual inerfaces . 1292 . TCP | TCP . 1293 . | | | . 1294 ............................................................... 1295 . | | | ^^^ Users of ACP (GRASP/ASA) . 1296 . | | | ACP interfaces/addressing . 1297 . | | | . 1298 . | | | . 1299 . | ACP-loopack | - ACP loopback interface . 1300 . | ACP-address | - address (global ULA) . 1301 . subnet1 | subnet2 - ACP virtual interfaces . 1302 . link-local | link-local - addresses . 1303 ............................................................... 1304 . | | | ACP routing and forwarding . 1305 . | RPL-routing | . 1306 . | /IP-Forwarding\ | . 1307 . | / \ | . 1308 . ACP IPv6 packets ACP IPv6 packets . 1309 . |/ \| . 1310 . IPsec/dTLS IPsec/dTLS - AN-cert auth . 1311 ............................................................... 1312 | | Data Plane 1313 | | 1314 | | - ACP secure channe 1315 link-local link-local - encap addresses 1316 subnet1 subnet2 - data plane interfaces 1317 | | 1318 ACP-Nbr1 ACP-Nbr2 1320 Figure 2 1322 GRASP unicast messages inside the ACP always use the ACP address. 1323 Link-local ACP addresses must not be used inside objectives. GRASP 1324 unicast messages inside the ACP are transported via TLS 1.2 1325 ([RFC5246]) connections with AES256 encryption and SHA256. Mutual 1326 authentication is via the domain certificate using the same rules as 1327 for secure channels (Section 6.6). 1329 GRASP link-local multicast messages are targeted for a specific ACP 1330 virtual interface (as defined Section 6.12.5) but are sent by the ACP 1331 into an equally built ACP GRASP virtual interface constructed from 1332 the TCP connection(s) to the IPv6 link-local neighbor address(es) on 1333 the underlying ACP virtual interface. If the ACP GRASP virtual 1334 interface has two or more neighbors, the GRASP link-local multicast 1335 messages are replicated to all neighbor TCP connections. 1337 TLS and TLS connections for GRASP in the ACP use the IANA assigned 1338 TCP port for GRASP (7107). Effectively the transport stack is 1339 expected to be TLS for connections from/to the ACP address (eg: 1340 global scope address(es)) and TCP for connections from/to link-local 1341 addreses on the ACP virtual interfaces. The latter ones are only 1342 used for flooding of GRASP messages. 1344 6.8.2.1. Discussion 1346 TCP encapsulation for GRASP M_DISCOVERY and M_FLOOD link local 1347 messages is used because these messages are flooded across 1348 potentially many hops to all ACP devices and a single link with even 1349 temporary packet loss issues (eg: WiFi/Powerline link) can reduce the 1350 probability for loss free transmission so much that applications 1351 would want to increase the frequency with which they send these 1352 messages. This would result in more traffic flooding than hop-by-hop 1353 reliable retransmission as provided for by TCP. 1355 TLS is mandated for GRASP non-link-local unicast because the ACP 1356 secure channel mandatory authentication and encryption protects only 1357 against attacks from the outside but not against attacks from the 1358 inside: Compromised ACP members that have (not yet) been detected and 1359 removed (eg: via domain certificate revocation / expiry). 1361 If GRASP peer connections would just use TCP, compromised ACP members 1362 could simply eavesdrop passively on GRASP peer connections for whom 1363 they are onpath ("Man In The Middle" - MITM). Or intercept and 1364 modify them. With TLS, it is not possible to completely eliminate 1365 problems with compromised ACP members, but attacks are a lot more 1366 complex: 1368 Eavesdropping/spoofing by a compromised ACP device is still possible 1369 because in the model of the ANI and GRASP, the provider and consumer 1370 of an objective have initially no unique information (such as an 1371 identifty) about the other side that would allow them to distinguish 1372 a benevolent from a compromised peer. The compromised ACP device 1373 would simply announce the objective as well, potentially filter the 1374 original objective in GRASP when it is a MITM and act as an 1375 application level proxy. This of course requires that the 1376 compromised ACP node understand the semantic of the GRASP negotiation 1377 to an extend that allows it to proxy it without being detected, but 1378 in an AN environment this is quite likely public knowledge or evens 1379 standardized. 1381 The GRASP TLS connections are run like any other ACP traffic through 1382 the ACP secure channels. This leads to double authentication/ 1383 encryption. Future work optimizations could avoid this but it is 1384 unclear how beneficial/feasible this is: 1386 o The security considerations for GRASP change against attacks from 1387 non-ACP (eg: "outside") nodes: TLS is subject to reset attacks 1388 while secure channel protocols may be not (eg: IPsec is not). 1390 o The secure channel method may leverage hardware acceleration and 1391 there may be little or no gain in eliminating it. 1393 o The GRASP TLS connections need to implement any additional 1394 security options that are required for secure channels. For 1395 example the closing of connections when the peers certificate has 1396 expired. 1398 6.9. Context Separation 1400 The ACP is in a separate context from the normal data plane of the 1401 device. This context includes the ACP channels IPv6 forwarding and 1402 routing as well as any required higher layer ACP functions. 1404 In classical network device platforms, a dedicated so called "Virtual 1405 routing and forwarding instance" (VRF) is one logical implementation 1406 option for the ACP. If possible by the platform SW architecture, 1407 separation options that minimize shared components are preferred, 1408 such as a logical container or virtual machine instance. The context 1409 for the ACP needs to be established automatically during bootstrap of 1410 a device. As much as possible it should be protected from being 1411 modified unintentionally by data plane configuration. 1413 Context separation improves security, because the ACP is not 1414 reachable from the global routing table. Also, configuration errors 1415 from the data plane setup do not affect the ACP. 1417 6.10. Addressing inside the ACP 1419 The channels explained above typically only establish communication 1420 between two adjacent nodes. In order for communication to happen 1421 across multiple hops, the autonomic control plane requires internal 1422 network wide valid addresses and routing. Each autonomic node must 1423 create a virtual interface with a network wide unique address inside 1424 the ACP context mentioned in Section 6.9. This address may be used 1425 also in other virtual contexts. 1427 With the algorithm introduced here, all ACP devices in the same 1428 routing subdomain have the same /48 ULA global ID prefix. 1430 Conversely, ULA global IDs from different domains are unlikely to 1431 clash, such that two networks can be merged, as long as the policy 1432 allows that merge. See also Section 9.1 for a discussion on merging 1433 domains. 1435 Links inside the ACP only use link-local IPv6 addressing, such that 1436 each node only requires one routable virtual address. 1438 6.10.1. Fundamental Concepts of Autonomic Addressing 1440 o Usage: Autonomic addresses are exclusively used for self- 1441 management functions inside a trusted domain. They are not used 1442 for user traffic. Communications with entities outside the 1443 trusted domain use another address space, for example normally 1444 managed routable address space (called "Data Plane" in this 1445 document). 1447 o Separation: Autonomic address space is used separately from user 1448 address space and other address realms. This supports the 1449 robustness requirement. 1451 o Loopback-only: Only loopback interfaces of autonomic nodes carry 1452 routable address(es); all other interfaces exclusively use IPv6 1453 link local for autonomic functions. The usage of IPv6 link local 1454 addressing is discussed in [RFC7404]. 1456 o Use-ULA: For loopback interfaces of autonomic nodes, we use Unique 1457 Local Addresses (ULA), as specified in [RFC4193]. An alternative 1458 scheme was discussed, using assigned ULA addressing. The 1459 consensus was to use ULA-random [[RFC4193] with L=1], because it 1460 was deemed to be sufficient. 1462 o No external connectivity: They do not provide access to the 1463 Internet. If a node requires further reaching connectivity, it 1464 should use another, traditionally managed address scheme in 1465 parallel. 1467 o Addresses in the ACP are permanent, and do not support temporary 1468 addresses as defined in [RFC4941]. 1470 o Addresses in the ACP are not considered sensitive on privacy 1471 grounds because ACP devices are not expected to be end-user 1472 devices. Therefore, ACP addresses do not need to be pseudo-random 1473 as discussed in [RFC7721]. Because they are not propagated to 1474 untrusted (non ACP) devices and stay within a domain (of trust), 1475 we also consider them not to be subject to scanning attacks. 1477 The ACP is based exclusively on IPv6 addressing, for a variety of 1478 reasons: 1480 o Simplicity, reliability and scale: If other network layer 1481 protocols were supported, each would have to have its own set of 1482 security associations, routing table and process, etc. 1484 o Autonomic functions do not require IPv4: Autonomic functions and 1485 autonomic service agents are new concepts. They can be 1486 exclusively built on IPv6 from day one. There is no need for 1487 backward compatibility. 1489 o OAM protocols no not require IPv4: The ACP may carry OAM 1490 protocols. All relevant protocols (SNMP, TFTP, SSH, SCP, Radius, 1491 Diameter, ...) are available in IPv6. 1493 6.10.2. The ACP Addressing Base Scheme 1495 The Base ULA addressing scheme for autonomic nodes has the following 1496 format: 1498 8 40 2 78 1499 +--+-------------------------+------+------------------------------+ 1500 |fd| hash(routing-subdomain) | Type | (sub-scheme) | 1501 +--+-------------------------+------+------------------------------+ 1503 Figure 3: ACP Addressing Base Scheme 1505 The first 48 bits follow the ULA scheme, as defined in [RFC4193], to 1506 which a type field is added: 1508 o "fd" identifies a locally defined ULA address. 1510 o The 40 bits ULA "global ID" (term from [RFC4193]) for ACP 1511 addresses carried in the ACP information field of domain 1512 certificates are the first 40 bits of the SHA256 hash of the 1513 routing subdomain from the same ACP information field. In the 1514 example of Section 6.1.1, the routing subdomain is 1515 "area51.research.acp.example.com" and the 40 bits ULA "global ID" 1516 a379a6f6ee. 1518 o To allow for extensibility, the fact that the ULA "global ID" is a 1519 hash of the routing subdomain SHOULD NOT be assumed by any 1520 autonomic device during normal operations. The hash function is 1521 only executed during the creation of the certificate. If BRSKI is 1522 used then the registrar will create the ACP information field in 1523 response to the CSR Attribute Request by the pledge. 1525 o Type: This field allows different address sub-schemes. This 1526 addresses the "upgradability" requirement. Assignment of types 1527 for this field will be maintained by IANA. 1529 The sub-scheme may imply a range or set of addresses assigned to the 1530 device, this is called the ACP address range/set and explained in 1531 each sub-scheme. 1533 6.10.3. ACP Zone Addressing Sub-Scheme 1535 The sub-scheme defined here is defined by the Type value 00b (zero) 1536 in the base scheme. 1538 64 64 1539 +-----------------+---------+---++-----------------------------+---+ 1540 | (base scheme) | Zone-ID | Z || Device-ID | 1541 | | | || Registrar-ID | Device-Number| V | 1542 +-----------------+---------+---++--------------+--------------+---+ 1543 50 13 1 48 15 1 1545 Figure 4: ACP Zone Addressing Sub-Scheme 1547 The fields are defined as follows: 1549 o Zone-ID: If set to all zero bits: The Device-ID bits are used as 1550 an identifier (as opposed to a locator). This results in a non- 1551 hierarchical, flat addressing scheme. Any other value indicates a 1552 zone. See section Section 6.10.3.1 on how this field is used in 1553 detail. 1555 o Z: MUST be 0. 1557 o Device-ID: A unique value for each device. 1559 The 64 bit Device-ID is derived and composed as follows: 1561 o Registrar-ID (48 bit): A number unique inside the domain that 1562 identifies the registrar which assigned the Device-ID to the 1563 device. A MAC address of the registrar can be used for this 1564 purpose. 1566 o Device-Number (Device-Number): A number which is unique for a 1567 given registrar, to identify the device. This can be a 1568 sequentially assigned number. 1570 o V (1 bit): Virtualization bit: 0: Indicates the ACP itself 1571 ("autonomic node base system); 1: Indicates the optional "host" 1572 context on the ACP device (see below). 1574 In the Zone addressing sub-scheme, the ACP address in the certificate 1575 has Zone and V fields as all zero bits. The ACP address set includes 1576 addresses with any Zone value and any V value. 1578 The "Device-ID" itself is unique in a domain (i.e., the Zone-ID is 1579 not required for uniqueness). Therefore, a device can be addressed 1580 either as part of a flat hierarchy (zone ID = 0), or with an 1581 aggregation scheme (any other zone ID). A address with zone-ID = 0 1582 is an identifier, with another zone-ID as a locator. See 1583 Section 6.10.3.1 for a description of the zone bits. 1585 The Virtual bit in this sub-scheme allows to easily add the ACP as a 1586 component to existing systems without causing problems in the port 1587 number space between the services in the ACP and the existing system. 1588 V:0 is the ACP router (autonomous node base system), V:1 is the host 1589 with pre-existing transport endpoints on it that could collide with 1590 the transport endpoints used by the ACP router. The ACP host could 1591 for example have a virtual p2p interface with the V:0 address as its 1592 router into the ACP. Depending on the SW design of ASA (outside the 1593 scope of this specification), they may use the V:0 or V:1 address. 1595 The location of the V bit(s) at the end of the address allows to 1596 announce a single prefix for each autonomic node. For example, in a 1597 network with 20,000 ACP devices, this avoid 20,000 additional routes 1598 in the routing table. 1600 6.10.3.1. Usage of the Zone Field 1602 The "Zone-ID" allows for the introduction of structure in the 1603 addressing scheme. 1605 Zone = zero is the default addressing scheme in an autonomic domain. 1606 Every autonomic node MUST respond to its ACP address with zone=0. 1607 Used on its own this leads to a non-hierarchical address scheme, 1608 which is suitable for networks up to a certain size. In this case, 1609 the addresses primarily act as identifiers for the nodes, and 1610 aggregation is not possible. 1612 If aggregation is required, the 13 bit value allows for up to 8192 1613 zones. The allocation of zone numbers may either happen 1614 automatically through a to-be-defined algorithm; or it could be 1615 configured and maintained manually. 1617 If a device learns through an autonomic method or through 1618 configuration that it is part of a zone, it MUST also respond to its 1619 ACP address with that zone number. In this case the ACP loopback is 1620 configured with two ACP addresses: One for zone 0 and one for the 1621 assigned zone. This method allows for a smooth transition between a 1622 flat addressing scheme and an hierarchical one. 1624 (Theoretically, the 13 bits for the Zone-ID would allow also for two 1625 levels of zones, introducing a sub-hierarchy. We do not think this 1626 is required at this point, but a new type could be used in the future 1627 to support such a scheme.) 1629 Note: The Zone-ID is one method to introduce structure or hierarchy 1630 into the ACP. Another way is the use of the routing subdomain field 1631 in the ACP that leads to different /40 ULA prefixes within an 1632 autonomic domain. This gives followup work two options to consider. 1634 6.10.4. ACP Manual Addressing Sub-Scheme 1636 The sub-scheme defined here is defined by the Type value 00b (zero) 1637 in the base scheme. 1639 64 64 1640 +---------------------+---------+---++-----------------------------+ 1641 | (base scheme) |Subnet-ID| Z || Interface Identifier | 1642 +---------------------+---------+---++-----------------------------+ 1643 50 13 1 1645 Figure 5: ACP Manual Addressing Sub-Scheme 1647 The fields are defined as follows: 1649 o Subnet-ID: Configured subnet identifier. 1651 o Z: MUST be 1. 1653 o Interface Identifier. 1655 This sub-scheme is meant for "manual" allocation to subnets where the 1656 other addressing schemes can not be used. The primary use case is 1657 for assignment to ACP connect subnets (see Section 8.1.1). 1659 "Manual" means that allocations of the Subnet-ID need to be done 1660 today with pre-existing, non-autonomic mechanisms. Every subnet that 1661 uses this addressing sub-scheme needs to use a unique Subnet-ID 1662 (unless some anycast setup is done). Future work may define 1663 mechanisms for auto-coordination between ACP devices and auto- 1664 allocation of Subnet-IDs between them. 1666 The Z field is following the Subnet-ID field so that future work 1667 could allocate/coordinate both Zone-ID and Subnet-ID consistently and 1668 use an integrated aggregateable routing approach across them. Z=0 1669 (Zone sub-scheme) would then be used for network wide unique, 1670 registrar assigned (and certificate protected) Device-IDs primarily 1671 for ACP devices while Z=1 would be used for device-level assigned 1672 Interface Identifiers primarily for non-ACP-devices. 1674 Manual addressing sub-scheme addresses are not assumed to be used the 1675 ACP information field in certificates. If they are used, then value 1676 of the Interface Identifier is left for future definitions. 1678 6.10.5. ACP Vlong Addressing Sub-Scheme 1680 The sub-scheme defined here is defined by the Type value 01b (one) in 1681 the base scheme. 1683 50 78 1684 +---------------------++-----------------------------+----------+ 1685 | (base scheme) || Device-ID | 1686 | || Registrar-ID | Device-Number| V | 1687 +---------------------++--------------+--------------+----------+ 1688 46 33/17 8/16 1690 Figure 6: ACP Vlong Addressing Sub-Scheme 1692 This addressing scheme foregoes the Zone field to allow for larger, 1693 flatter routed networks (eg: as in IoT) with more than 2^32 Device- 1694 Numbers. It also allows for up to 2^16 - 65536 different virtualized 1695 adddresses, which could be used to address individual software 1696 components in an ACP device. 1698 The fields are the same as in the Zone sub-scheme with the following 1699 refinements: 1701 o V: Virtualization bit: Values 0 and 1 as in Zone sub-scheme, 1702 further values use via definition in followup work. 1704 o Registrar-ID: To maximize Device-Number and V, the Registrar-ID is 1705 reduced to 46 bits. This still allows to use the MAC address of a 1706 registrar by removing the V and U bits from the 48 bits of a MAC 1707 address (those two bits are never unique, so they can not be used 1708 to distinguish MAC addresses). 1710 o If the first bit of the "Device-Number" is "1", then the Device 1711 number is 17 bit long and the V field is 16 bit long. Otherwise 1712 the Device-Number is 33 bit long and the V field is 8 bit long. 1713 "0" bit Device-Numbers are intended to be used for "general 1714 purpose" ACP devices that would potentially have a limited number 1715 (< 256) of internal users of the ACP that require separate 1716 V(irtual) addresses. "1" bit Device-Numbers are intended for ACP 1717 devices that are ACP edge devices (see Section 8.1.1) or that have 1718 a large number of internal ACP users requiring separate V(irtual) 1719 addresses. For example large SDN controllers with container 1720 modular software architecture (see Section 8.1.2). 1722 In the Vlong addressing sub-scheme, the ACP address in the 1723 certificate has all V field bits as zero. The ACP address set 1724 includes address for the device includes any V value. 1726 6.10.6. Other ACP Addressing Sub-Schemes 1728 Before further addressing sub-schemes are defined, experience with 1729 the schemes defined here should be collected. The schemes defined in 1730 this document have been devised to allow hopefully sufficiently 1731 flexible setup of ACPs for a variety of situation. These reasons 1732 also lead to the fairly liberal use of address space: The Zone 1733 addressing sub-schemes is intended to enable optimized routing in 1734 large networks by reserving bits for zones. The Vlong addressing 1735 sub-scheme enables the allocation of 8/16 bit of addresses inside 1736 individual ACP nodes. Both address spaces allow distributed, 1737 uncoordinated allocation of node addresses by reserving bits for the 1738 Registrar-ID field in the address. 1740 IANA is asked need to assign a new "type" for each new addressing 1741 sub-scheme. With the current allocations, only 2 more schemes are 1742 possible, so the last addressing scheme should consider to be 1743 extensible in itself (eg: by reserving bits from it for further 1744 extensions. 1746 6.11. Routing in the ACP 1748 Once ULA address are set up all autonomic entities should run a 1749 routing protocol within the autonomic control plane context. This 1750 routing protocol distributes the ULA created in the previous section 1751 for reachability. The use of the autonomic control plane specific 1752 context eliminates the probable clash with the global routing table 1753 and also secures the ACP from interference from the configuration 1754 mismatch or incorrect routing updates. 1756 The establishment of the routing plane and its parameters are 1757 automatic and strictly within the confines of the autonomic control 1758 plane. Therefore, no manual configuration is required. 1760 All routing updates are automatically secured in transit as the 1761 channels of the autonomic control plane are by default secured, and 1762 this routing runs only inside the ACP. 1764 The routing protocol inside the ACP is RPL ([RFC6550]). See 1765 Section 10.3 for more details on the choice of RPL. 1767 RPL adjacencies are set up across all ACP channels in the same domain 1768 including all its routing subdomains. See Section 10.5 for more 1769 details. 1771 6.11.1. RPL Profile 1773 The following is a description of the RPL profile that ACP nodes need 1774 to support by default. The format of this section is derived from 1775 draft-ietf-roll-applicability-template. 1777 6.11.1.1. Summary 1779 In summary, the profile chosen for RPL is one that expects a fairly 1780 reliable network reasonable fast links so that RPL convergence will 1781 be triggered immediately upon recognition of link failure/recovery. 1783 The key limitation of the chosen profile is that it is designed to 1784 not require any dataplane artifacts (such as [RFC6553]). While the 1785 senders/receivers of ACP packets can be legacy NOC devices connected 1786 via "ACP connect" (see Section 8.1.1 to the ACP, their connectivity 1787 can be handled as non-RPL-aware leafs (or "Internet") accoding to the 1788 dataplane architecture explained in [I-D.ietf-roll-useofrplinfo]. 1789 This non-artifact profile is largely driven by the desire to avoid 1790 introducing the required Hop-by-Hop headers into the ACP VRF control 1791 plane. Many devices will have their VRF forwarding code designed 1792 into silicon. 1794 In this profile choice, RPL has no dataplane artifacts. A simple 1795 destination prefix based upon the routing table is used. A 1796 consequence of supporting only a single instanceID (containing one 1797 DODAG), the ACP will only accomodate only a single class of routing 1798 table and can not create optimized routing paths to accomplish 1799 latency or energy goals. 1801 Consider a network that has multiple NOCs in different locations. 1802 Only one NOC will become the DODAG root. Other NOCs will have to 1803 send traffic through the DODAG (tree) rooted in the primary NOC. 1805 Depending on topology, this can be an annoyance from a latency point 1806 of view, but it does not represent a single point of failure, as the 1807 DODAG can reconfigure itself when it detects data plane forwarding 1808 failures. 1810 The lack of a RPI (the header defined by [RFC6553]), means that the 1811 dataplane will have no rank value that can be used to detect loops. 1812 As a result, traffic may loop until the TTL of the packet reaches 1813 zero. This the same behavior as that of other IGPs that do not have 1814 the data plane options as RPPL. There are a variety of heuristics 1815 that can be used to signal from the data plane to the RPL control 1816 plane that a new route is needed. 1818 Additionally, failed ACP tunnels will be detected by IKEv2 Dead Peer 1819 Detection (which can function as a replacement for an LLN's ETX). A 1820 failure of an ACP tunnel should signal the RPL control plane to pick 1821 a different parent. 1823 Future Extensions to this RPL profile can provide optimality for 1824 multiple NOCs. This requires utilizing data plane artifact including 1825 IPinIP encap/decap on ACP routers and processing of IPv6 RPI headers. 1826 Alternatively (Src,Dst) routing table entries could be used. A 1827 decision for the preferred technology would have to be done when such 1828 extension is defined. 1830 6.11.1.2. RPL Instances 1832 Single RPL instance. Default RPLInstanceID = 0. 1834 6.11.1.3. Storing vs. Non-Storing Mode 1836 RPL Mode of Operations (MOP): mode 3 "Storing Mode of Operations with 1837 multicast support". Implementations should support also other modes. 1838 Note: Root indicates mode in DIO flow. 1840 6.11.1.4. DAO Policy 1842 Proactive, aggressive DAO state maintenance: 1844 o Use K-flag in unsolicited DAO indicating change from previous 1845 information (to require DAO-ACK). 1847 o Retry such DAO DAO-RETRIES(3) times with DAO- ACK_TIME_OUT(256ms) 1848 in between. 1850 6.11.1.5. Path Metric 1852 Hopcount. 1854 6.11.1.6. Objective Function 1856 Objective Function (OF): Use OF0 [RFC6552]. No use of metric 1857 containers. 1859 rank_factor: Derived from link speed: <= 100Mbps: 1860 LOW_SPEED_FACTOR(5), else HIGH_SPEED_FACTOR(1) 1862 6.11.1.7. DODAG Repair 1864 Global Repair: we assume stable links and ranks (metrics), so no need 1865 to periodically rebuild DODAG. DODAG version only incremented under 1866 catastrophic events (eg: administrative action). 1868 Local Repair: As soon as link breakage is detected, send No-Path DAO 1869 for all the targets that where reachable only via this link. As soon 1870 as link repair is detected, validate if this link provides you a 1871 better parent. If so, compute your new rank, and send new DIO that 1872 advertises your new rank. Then send a DAO with a new path sequence 1873 about yourself. 1875 stretch_rank: none provided ("not stretched"). 1877 Data Path Validation: Not used. 1879 Trickle: Not used. 1881 6.11.1.8. Multicast 1883 Not used yet but possible because of the seleced mode of operations. 1885 6.11.1.9. Security 1887 [RFC6550] security not used, substituted by ACP security. 1889 6.11.1.10. P2P communications 1891 Not used. 1893 6.11.1.11. IPv6 address configuration 1895 Every ACP device (RPL node) announces an IPv6 prefix covering the 1896 address(es) used internally in the ACP device. The prefix length 1897 depends on the choosen addressing sub-scheme of the ACP address 1898 provisioned into the certificate of the ACP device, eg: /127 for Zone 1899 addressing sub-scheme or /112 or /120 for Vlong addressing sub- 1900 scheme. See Section 6.10 for more details. 1902 Every ACP device MUST install a blackhole (aka null route) route for 1903 whatever ACP address space that it advertises (i.e: the /96 or /127). 1904 This is avoid routing loops for addresses that an ACP node has not 1905 (yet) used. 1907 6.11.1.12. Administrative parameters 1909 Administrative Preference ([RFC6552], 3.2.6 - to become root): 1910 Indicated in DODAGPreference field of DIO message. 1912 o Explicit configured "root": 0b100 1914 o Registrar (Default): 0b011 1916 o AN-connect (non registrar): 0b010 1918 o Default: 0b001. 1920 6.11.1.13. RPL Dataplane artifacts 1922 RPI (RPL Packet Information [RFC6553]): Not used as there is only a 1923 single instance, and data path validation is not being used. 1925 SRH (RPL Source Routing - RFC6552): Not used. Storing mode is being 1926 used. 1928 6.11.1.14. Unknown Destinations 1930 Because RPL minimizes the size of the routing and forwarding table, 1931 prefixes reachable through the same interface as the RPL root are not 1932 known on every ACP device. Therefore traffic to unknown destination 1933 addresses can only be discovered at the RPL root. The RPL root 1934 SHOULD have attach safe mechanisms to operationally discover and log 1935 such packets. 1937 6.12. General ACP Considerations 1939 Since channels are by default established between adjacent neighbors, 1940 the resulting overlay network does hop by hop encryption. Each node 1941 decrypts incoming traffic from the ACP, and encrypts outgoing traffic 1942 to its neighbors in the ACP. Routing is discussed in Section 6.11. 1944 6.12.1. Performance 1946 There are no performance requirements against ACP implementations 1947 defined in this document because the performance requirements depend 1948 on the intended use case. It is expected that full autonomic devices 1949 with a wide range of ASA can require high forwarding plane 1950 performance in the ACP, for example for telemetry, but that 1951 determination is for future work. Implementations of ACP to solely 1952 support traditional/SDN style use cases can benefit from ACP at lower 1953 performance, especially if the ACP is used only for critical 1954 operations, eg: when the data plane is not available. See 1955 [I-D.ietf-anima-stable-connectivity] for more details. 1957 6.12.2. Addressing of Secure Channels in the data plane 1959 In order to be independent of the Data Plane configuration of global 1960 IPv6 subnet addresses (that may not exist when the ACP is brought 1961 up), Link-local secure channels MUST use IPv6 link local addresses 1962 between adjacent neighbors. The fully autonomic mechanisms in this 1963 document only specify these link-local secure channels. Section 8.2 1964 specifies extensions in which secure channels are tunnels. For 1965 those, this requirement does not apply. 1967 The Link-local secure channels specified in this document therefore 1968 depend on basic IPv6 link-local functionality to be auto-enabled by 1969 the ACP and prohibiting the Data Plane from disabling it. The ACP 1970 also depends on being able to operate the secure channel protocol 1971 (eg: IPsec / dTLS) across IPv6 link-local addresses, something that 1972 may be an uncommon profile. Functionaly, these are the only 1973 interactions with the Data Plane that the ACP needs to have. 1975 To mitigate these interactions with the Data Plane, extensions to 1976 this document may specify additional layer 2 or layer encapsulations 1977 for ACP secure channels as well as other protocols to auto-discover 1978 peer endpoints for such encapsulations (eg: tunneling across L3 or 1979 use of L2 only encapsulations). 1981 6.12.3. MTU 1983 The MTU for ACP secure channels must be derived locally from the 1984 underlying link MTU minus the secure channel encapsulation overhead. 1986 ACP secure Channel protocols do not need to perform MTU discovery 1987 because they are built across L2 adjacencies - the MTU on both sides 1988 connecting to the L2 connection are assumed to be consistent. 1989 Extensions to ACP where the ACP is for example tunneled need to 1990 consider how to guarantee MTU consistency. This is a standard issue 1991 with tunneling, not specific to running the ACP across it. Transport 1992 stacks running across ACP can perform normal PMTUD (Path MTU 1993 Discovery). Because the ACP is meant to be prioritize reliability 1994 over performance, they MAY opt to only expect IPv6 minimum MTU (1280) 1995 to avoid running into PMTUD implementation bugs or underlying link 1996 MTU mismatch problems. 1998 6.12.4. Multiple links between nodes 2000 If two nodes are connected via several links, the ACP SHOULD be 2001 established across every link, but it is possible to establish the 2002 ACP only on a sub-set of links. Having an ACP channel on every link 2003 has a number of advantages, for example it allows for a faster 2004 failover in case of link failure, and it reflects the physical 2005 topology more closely. Using a subset of links (for example, a 2006 single link), reduces resource consumption on the devices, because 2007 state needs to be kept per ACP channel. The negotiation scheme 2008 explained in Section 6.5 allows Alice (the node with the higher ACP 2009 address) to drop all but the desired ACP channels to Bob - and Bob 2010 will not re-try to build these secure channels from his side unless 2011 Alice shows up with a previously unknown GRASP announcement (eg: on a 2012 different link or with a different address announced in GRASP). 2014 6.12.5. ACP interfaces 2016 The ACP VRF has conceptually two type of interfaces: The ACP loopback 2017 interface(s) to which the ACP ULA address(es) are assigned and the 2018 "ACP virtual interfaces" that are mapped to the ACP secure channels. 2020 The term "loopback interface" is commonly used to refer to internal 2021 pseudo interfaces through which the device can only reach itself. In 2022 network devices these interfaces are used to hold addresses used by 2023 the transport stack of the system when an address should be reliable 2024 reachable in the presence of arbitrary link failures. As long as 2025 addresses on a loopback interface are routeable in the routing 2026 protocol used, they will be reachable as long as there is at least 2027 one working network path. This is opposed to routeable address 2028 assigned to an externally connected interface. That address will 2029 become unreachable when that interface goes down. For this reason, 2030 the ACP (ULA) address(es) are assigned to loopback type interface(s). 2032 ACP secure channels, eg: IPsec, dTLS or other future security 2033 associations with neighboring ACP devices can be mapped to ACP 2034 virtual interfaces in different ways: 2036 ACP point-to-point virtual interface: 2038 Each ACP secure channel is mapped into a separate point-to-point ACP 2039 virtual interface. If a physical subnet has more than two ACP 2040 capable nodes (in the same domain), this implementation approach will 2041 lead to a full mesh of ACP virtual interfaces between them. 2043 ACP multi-access virtual interface: 2045 In a more advanced implementation approach, the ACP will construct a 2046 single multi-access ACP virtual interface for all ACP secure channels 2047 to ACP capable nodes reachable across the same underlying (physical) 2048 subnet. IPv6 link-local multicast packets sent into an ACP multi- 2049 access virtual interface are replicated to every ACP secure channel 2050 mapped into the ACP multicast-access virtual interface. IPv6 unicast 2051 packets sent into an ACP multi-access virtual interface are sent to 2052 the ACP secure channel that belongs to the ACP neighbor that is the 2053 next-hop in the ACP forwarding table entry used to reach the packets 2054 destination address. 2056 There is no requirement for all ACP devices on the same physical 2057 multi-access subnet to use the same type of ACP virtual interface. 2058 This is purely a node local decision. 2060 ACP devices MUST perform standard IPv6 operations across ACP virtual 2061 interfaces including SLAAC (Stateless Address AutoConfiguration - 2062 [RFC4862]) to assign their IPv6 link local address on the ACP virtual 2063 interface and ND (Neighbor Discovery - [RFC4861]) to discover which 2064 IPv6 link-local neighbor address belongs to which ACP secure channel 2065 mapped to the ACP virtual interface. This is independent of whether 2066 the ACP virtual interface is point-to-point or multi-access. 2068 ACP devices MAY reduce the amount of link-local IPv6 multicast 2069 packets from ND by learning the IPv6 link-local neighbor address to 2070 ACP secure channel mapping from other messages such as the source 2071 address of IPv6 link-local multicast RPL messages - and therefore 2072 forego the need to send Neighbor Solication messages. 2074 ACP devices MUST NOT derive their ACP virtual interface IPv6 link 2075 local address from their IPv6 link-local address used on the 2076 underlying interface (e.g.: the address that is used as the 2077 encapsulation address in the ACP secure channel protocols defined in 2078 this document). This ensures that the ACP virtual interface 2079 operations will not depend on the specifics of the encapsulation used 2080 by the ACP secure channel and that attacks against SLAAC on the 2081 physical interface will not impact the operations of the ACP virtal 2082 interface. 2084 The link-layer address of an ACP virtual interface is the address 2085 used for the underlying interface across which the secure tunnels are 2086 built, typically Ethernet addresses. Because unicast IPv6 packets 2087 sent to an ACP virtual interface are not sent to a link-layer 2088 destination address but rather the correct ACP secure channel, the 2089 link-layer address fields SHOULD be ignored on reception and instead 2090 the ACP secure channel remembered from which the message was 2091 received. 2093 Multi-access ACP virtual interfaces are preferrable implementations 2094 when the underlying interface is a (broadcast) multi-access subnet 2095 because they do reflect the presence of the underlying multi-access 2096 subnet into the virtual interfaces of the ACP. This makes it for 2097 example simpler to build services with topology awareness inside the 2098 ACP VRF in the same way as they could have been built running 2099 natively on the multi-access interfaces. 2101 Consider also the impact of point-to-point vs. multicaccess virtual 2102 interface on the efficiency of flooding via link local multicasted 2103 messages: 2105 Assume a LAN with three ACP neighbors, Alice, Bob and Carol. Alices 2106 ACP GRASP wants to send a link-local GRASP multicast message to Bob 2107 and Carol. If Alices ACP emulates the LAN as one point-to-point 2108 interface to Bob and one to Carol, The sending applications itself 2109 will send two copies, if Alices ACP emulates a LAN, GRASP will send 2110 one packet and the ACP will replicate it. The result is the same. 2111 The difference happens when Bob and Carol receive their packet. If 2112 they use point-to-point ACP virtual interfaces, their GRASP instance 2113 would forward the packet from Alice to each other as part of the 2114 GRASP flooding procedure. These packets are unnecessary and would be 2115 discarded by GRASP on receipt as duplicates (by use of the GRASP 2116 Session ID). If Bob and Charlies ACP would emulate a multi-acccess 2117 virtual interface, then this would not happen, because GRASPs 2118 flooding procedure does not replicate back packets to the interface 2119 that they where received from. 2121 Note that link-local GRASP multicast messages are not sent directly 2122 as IPv6 link-local multicast UDP messages into ACP virtual 2123 interfaces, but instead into ACP GRASP virtual interfaces, that are 2124 layered on top of ACP virtual interfaces to add TCP reliability to 2125 link-local multicast GRASP messages. Nevertheless, these ACP GRASP 2126 virtual interfaces perform the same replication of message and 2127 therefore result in the same impact on flooding. See Section 6.8.2 2128 for more details. 2130 RPL does support operations and correct routing table construction 2131 across non-broadcast multi-access (NBMA) subnets. This is common 2132 when using many radio technologies. When such NBMA subnets are used, 2133 they MUST NOT be represented as ACP multi-access virtual interfaces 2134 because the replication of IPv6 link-local multicast multicast 2135 messages will not reach all NBMA subnet neighbors. In result, GRASP 2136 message flooding would fail. Instead, each ACP secure channel across 2137 such an interface MUST be represented as a ACP point-to-point virtual 2138 interface. These requirements can be avoided by coupling the ACP 2139 flooding mechanism for GRASP messages directly to RPL (flood GRASP 2140 across DODAG), but such an enhancement is subjet for future work. 2142 Care must also be taken when creating multi-access ACP virtual 2143 interfaces across ACP secure channels between ACP devices in 2144 different domains or routing subdomains. The policies to be 2145 negotiated may be described as peer-to-peer policies in which case it 2146 is easier to create ACP point-to-point virtual interfaces for these 2147 secure channels. 2149 7. ACP support on L2 switches/ports (Normative) 2151 7.1. Why 2153 ANrtr1 ------ ANswitch1 --- ANswitch2 ------- ANrtr2 2154 .../ \ \ ... 2155 ANrtrM ------ \ ------- ANrtrN 2156 ANswitchM ... 2158 Figure 7 2160 Consider a large L2 LAN with ANrtr1...ANrtrN connected via some 2161 topology of L2 switches. Examples include large enterprise campus 2162 networks with an L2 core, IoT networks or broadband aggregation 2163 networks which often have even a multi-level L2 switched topology. 2165 If the discovery protocol used for the ACP is operating at the subnet 2166 level, every AN router will see all other AN routers on the LAN as 2167 neighbors and a full mesh of ACP channels will be built. If some or 2168 all of the AN switches are autonomic with the same discovery 2169 protocol, then the full mesh would include those switches as well. 2171 A full mesh of ACP connections like this can creates fundamental 2172 scale challenges. The number of security associations of the secure 2173 channel protocols will likely not scale arbitrarily, especially when 2174 they leverage platform accelerated encryption/decryption. Likewise, 2175 any other ACP operations (such as routing) needs to scale to the 2176 number of direct ACP neigbors. An AN router with just 4 interfaces 2177 might be deployed into a LAN with hundreds of neighbors connected via 2178 switches. Introducing such a new unpredictable scaling factor 2179 requirement makes it harder to support the ACP on arbitrary platforms 2180 and in arbitrary deployments. 2182 Predictable scaling requirements for ACP neighbors can most easily be 2183 achieved if in topologies like these, AN capable L2 switches can 2184 ensure that discovery messages terminate on them so that neighboring 2185 AN routers and switches will only find the physically connected AN L2 2186 switches as their candidate ACP neighbors. With such a discovery 2187 mechanism in place, the ACP and its security associations will only 2188 need to scale to the number of physical interfaces instead of a 2189 potentially much larger number of "LAN-connected" neighbors. And the 2190 ACP topology will follow directly the physical topology, something 2191 which can then also be leveraged in management operations or by ASAs. 2193 In the example above, consider ANswitch1 and ANswitchM are AN 2194 capable, and ANswitch2 is not AN capable. The desired ACP topology 2195 is therefore that ANrtr1 and ANrtrM only have an ACP connetion to 2196 ANswitch1, and that ANswitch1, ANrtr2, ANrtrN have a full mesh of ACP 2197 connection amongst each other. ANswitch1 also has an ACP connection 2198 with ANswitchM and ANswitchM has ACP connections to anything else 2199 behind it. 2201 7.2. How (per L2 port DULL GRASP) 2203 To support ACP on L2 switches or L2 switched ports of an L3 device, 2204 it is necessary to make those L2 ports look like L3 interfaces for 2205 the ACP implementation. This primarily involves the creation of a 2206 separate DULL GRASP instance/domain on every such L2 port. Because 2207 GRASP has a dedicated link-local IPv6 multicast address 2208 (ALL_GRASP_NEIGHBORS), it is sufficient that all packets for this 2209 address are being extracted at the port level and passed to that DULL 2210 GRASP instance. Likewise the IPv6 link-local multicast packets sent 2211 by that DULL GRASP instance need to be sent only towards the L2 port 2212 for this DULL GRASP instance. 2214 If the device with L2 ports is supporting per L2 port ACP DULL GRASP 2215 as well as MLD snooping ([RFC4541]), then MLD snooping must be 2216 changed to never forward packets for ALL_GRASP_NEIGHBORS because that 2217 would cause the problem that per L2 port ACP DULL GRASP is meant to 2218 overcome (forwarding DULL GRASP packets across L2 ports). 2220 The rest of ACP operations can operate in the same way as in L3 2221 devices: Assume for example that the device is an L3/L2 hybrid device 2222 where L3 interfaces are assigned to VLANs and each VLAN has 2223 potentially multiple ports. DULL GRASP is run as described 2224 individually on each L2 port. When it discovers a candidate ACP 2225 neighbor, it passes its IPv6 link-local address and supported secure 2226 channel protocols to the ACP secure channel negotiation that can be 2227 bound to the L3 (VLAN) interface. It will simply use link-local IPv6 2228 multicast packets to the candidate ACP neighbor. Once a secure 2229 channel is established to such a neighbor, the virtual interface to 2230 which this secure channel is mapped should then actually be the L2 2231 port and not the L3 interface to best map the actual physical 2232 topology into the ACP virtual interfaces. See Section 6.12.5 for 2233 more details about how to map secure channels into ACP virtual 2234 interfaces. Note that a single L2 port can still have multiple ACP 2235 neighbors if it connect for example to multiple ACP neighbors via a 2236 non-ACP enabled switch. The per L2 port ACP virtual interface can 2237 threfore still be a multi-access virtual LAN. 2239 For example, in the above picture, ANswitch1 would run separate DULL 2240 GRASP instances on its ports to ANrtr1, ANswitch2 and ANswitchI, even 2241 though all those three ports may be in the data plane in the same 2242 (V)LAN and perfom L2 switching between these ports, ANswitch1 would 2243 perform ACP L3 routing between them. 2245 The description in the previous paragraph was specifically meant to 2246 illustrate that on hybrid L3/L2 devices that are common in 2247 enterprise, IoT and broadband aggregation, there is only the GRASP 2248 packet extraction (by ethernet address) and GRASP link-local 2249 multicast per L2-port packet injection that has to consider L2 ports 2250 at the hardware forwarding level. The remaining operations are 2251 purely ACP control plane and setup of secure channels across the L3 2252 interface. This hopefully makes support for per-L2 port ACP on those 2253 hybrid devices easy. 2255 This L2/L3 optimized approach is subject to "address stealing", eg: 2256 where a device on one port uses addresses of a device on another 2257 port. This is a generic issue in L2 LANs and switches often already 2258 have some form of "port security" to prohibit this. They rely on NDP 2259 or DHCP learning of which port/MAC-address and IPv6 address belong 2260 together and block duplicates. This type of function needs to be 2261 enabled to prohibit DoS attacks. Likewise the GRASP DULL instance 2262 needs to ensure that the IPv6 address in the locator-option matches 2263 the source IPv6 address of the DULL GRASP packet. 2265 In devices without such a mix of L2 port/interfaces and L3 interfaces 2266 (to terminate any transport layer connections), implementation 2267 details will differ. Logically most simply every L2 port is 2268 considered and used as a separate L3 subnet for all ACP operations. 2269 The fact that the ACP only requires IPv6 link-local unicast and 2270 multicast should make support for it on any type of L2 devices as 2271 simple as possible, but the need to support secure channel protocols 2272 may be a limiting factor to supporting ACP on such devices. Future 2273 options such as 802.1ae could improve that situation. 2275 A generic issue with ACP in L2 switched networks is the interaction 2276 with the Spanning Tree Protocol. Ideally, the ACP should be built 2277 also across ports that are blocked in STP so that the ACP does not 2278 depend on STP and can continue to run unaffected across STP topology 2279 changes (where reconvergence can be quite slow). The above described 2280 simple implementation options are not sufficient for this. Instead 2281 they would simply have the ACP run across the active STP topology and 2282 therefore the ACP would equally be interrupted and reconverge with 2283 STP changes. 2285 8. Support for Non-Autonomic Components (Normative) 2287 8.1. ACP Connect 2289 8.1.1. Non-Autonomic Controller / NMS system 2291 The Autonomic Control Plane can be used by management systems, such 2292 as controllers or network management system (NMS) hosts (henceforth 2293 called simply "NMS hosts"), to connect to devices through it. For 2294 this, an NMS host must have access to the ACP. The ACP is a self- 2295 protecting overlay network, which allows by default access only to 2296 trusted, autonomic systems. Therefore, a traditional, non-autonomic 2297 NMS system does not have access to the ACP by default, just like any 2298 other external device. 2300 If the NMS host is not autonomic, i.e., it does not support autonomic 2301 negotiation of the ACP, then it can be brought into the ACP by 2302 explicit configuration. To support connections to adjacent non- 2303 autonomic nodes, an autonomic node with ACP must support "ACP 2304 connect" (sometimes also connect "autonomic connect"): 2306 "ACP connect" is a function on an autonomic device that is called an 2307 "ACP edge device". With "ACP connect", interfaces on the device can 2308 be configured to be put into the ACP VRF. The ACP is then accessible 2309 to other (NOC) systems on such an interface without those systems 2310 having to support any ACP discovery or ACP channel setup. This is 2311 also called "native" access to the ACP because to those (NOC) systems 2312 the interface looks like a normal network interface (without any 2313 encryption/novel-signaling). 2315 data-plane "native" (no ACP) 2316 . 2317 +--------+ +----------------+ . +-------------+ 2318 | ACP | |ACP Edge Device | . | | 2319 | Device | | | v | | 2320 | |-------|...[ACP VRF]....+-----------------| |+ 2321 | | ^ |. | | NOC Device || 2322 | | . | .[Data Plane]..+-----------------| "NMS hosts" || 2323 | | . | [ VRF ] | . ^ | || 2324 +--------+ . +----------------+ . . +-------------+| 2325 . . . +-------------+ 2326 . . . 2327 data-plane "native" . ACP "native" (unencrypted) 2328 + ACP auto-negotiated . "ACP connect subnet" 2329 and encrypted . 2330 ACP connect interface 2331 eg: "vrf ACP native" (config) 2333 Figure 8: ACP connect 2335 ACP connect has security consequences: All systems and processes 2336 connected via ACP connect have access to all autonomic nodes on the 2337 entire ACP, without further authentication. Thus, the ACP connect 2338 interface and (NOC) systems connected to it must be physically 2339 controlled/secured. For this reason the mechanisms described here do 2340 explicitly not include options to allow for a non-ACP router to be 2341 connected across an ACP connect interface and addresses behind such a 2342 router routed inside the ACP. 2344 An ACP connect interface provides exclusively access to only the ACP. 2345 This is likely insufficient for many NMS hosts. Instead, they would 2346 require a second "data-plane" interface outside the ACP for 2347 connections between the NMS host and administrators, or Internet 2348 based services, or for direct access to the data plane. The document 2349 "Autonomic Network Stable Connectivity" 2350 [I-D.ietf-anima-stable-connectivity] explains in more detail how the 2351 ACP can be integrated in a mixed NOC environment. 2353 The ACP connect interface must be (auto-)configured with an IPv6 2354 address prefix. Is prefix SHOULD be covered by one of the (ULA) 2355 prefix(es) used in the ACP. If using non-autonomic configuration, it 2356 SHOULD use the ACP Manual Addressing Sub-Scheme (Section 6.10.4). It 2357 SHOULD NOT use a prefix that is also routed outside the ACP so that 2358 the addresses clearly indicate whether it is used inside the ACP or 2359 not. 2361 The prefix of ACP connect subnets MUST be distributed by the ACP edge 2362 device into the ACP routing protocol (RPL). The NMS hosts MUST 2363 connect to prefixes in the ACP routing table via its ACP connect 2364 interface. In the simple case where the ACP usesonly one ULA prefix 2365 and all ACP connect subnets have prefixes covered by that ULA prefix, 2366 NMS hosts can rely on [RFC6724] - The NMS host will select the ACP 2367 connect interface because any ACP destination address is best matched 2368 by the address on the ACP connect interface. If the NMS hosts ACP 2369 connect interface uses another prefix or if the ACP uses multiple ULA 2370 prefixes, then the NMS hosts require (static) routes towards the ACP 2371 interface. 2373 ACP Edge Device MUST only forward IPv6 packets received from an ACP 2374 connect interface into the ACP that has an IPv6 address from the ACP 2375 prefix assigned to this interface (sometimes called "RPF filtering"). 2376 This MAY be changed through administrative measures. 2378 To limit the security impact of ACP connect, devices supporting it 2379 SHOULD implement a security mechanism to allow configuration/use of 2380 ACP connect interfaces only on devices explicitly targeted to be 2381 deployed with it (such as those physically secure locations like a 2382 NOC). For example, the certificate of such devices could include an 2383 extension required to permit configuration of ACP connect interfaces. 2384 This prohibits that a random ACP device with easy physical access 2385 that is not meant to run ACP connect could start leaking the ACP when 2386 it becomes compromised and the intruder configures ACP connect on it. 2387 The full workflow including the mechanism by which a registrar would 2388 select which device to give such a certificate to is subject to 2389 future work. 2391 8.1.2. Software Components 2393 The ACP connect mechanism be only be used to connect physically 2394 external systems (NMS hosts) to the ACP but also other applications, 2395 containers or virtual machines. In fact, one possible way to 2396 eliminate the security issue of the external ACP connect interface is 2397 to collocate an ACP edge device and an NMS host by making one a 2398 virtual machine or container inside the other - and therefore 2399 converting the unprotected external ACP subnet into an internal 2400 virtual subnet in a single device. This would ultimately result in a 2401 fully autonomic NMS host with minimum impact to the NMS hosts 2402 software architecture. This approach is not limited to NMS hosts but 2403 could equally be applied to devices consisting of one or more VNF 2404 (virtual network functions): An internal virtual subnet connecting 2405 out-of-band-management interfaces of the VNFs to an ACP edge router 2406 VNF. 2408 The core requirement is that the software components need to have a 2409 network stack that permits access to the ACP and optionally also the 2410 data plane. Like in the physical setup for NMS hosts this can be 2411 realized via two internal virtual subnets. One that is connecting to 2412 the ACP (which could be a container or virtual machine by itself), 2413 and one (or more) connecting into the data plane. 2415 This "internal" use of ACP connect approach should not considered to 2416 be a "workaround" because in this case it is possible to build a 2417 correct security model: It is not necessary to rely on unprovable 2418 external physical security mechanisms as in the case of external NMS 2419 hosts. Instead, the orchestration of the ACP, the virtual subnets 2420 and the software components can be done by trusted software that 2421 could be considered to be part of the ANI (or even an extended ACP). 2422 This software component is responsible to ensure that only trusted 2423 software components will get access to that virtual subnet and that 2424 only even more trusted software components will get access to both 2425 the ACP virtual subnet and the data plane (because those ACP users 2426 could leak traffic between ACP and data plane). This trust could be 2427 established for example through cryptographic means such signed 2428 software packages. The specification of these mechanisms is subject 2429 to future work. 2431 Note that ASA (Autonomic Software Agents) could also be software 2432 components as described in this section, but further details of ASAs 2433 are subject to future work. 2435 8.1.3. Auto Configuration 2437 ACP edge devices, NMS hosts and software components that as describd 2438 in the previous section are meant to be composed via virtual 2439 interfaces SHOULD support on the ACP connect subnet Stateless Address 2440 Autoconfiguration (SLAAC - [RFC4862]) and route autoconfiguration 2441 according to [RFC4191]. 2443 The ACP edge device acts as the router on the ACP connect subnet, 2444 providing the (auto-)configured prefix for the ACP connect subnet to 2445 NMS hosts and/or software components. The ACP edge device uses route 2446 prefix option of RFC4191 to announce the default route (::/) with a 2447 lifetime of 0 and aggregated prefixes for routes in the ACP routing 2448 table with normal lifetimes. This will ensure that the ACP edge 2449 device does not become a default router, but that the NMS hosts and 2450 software components will route the prefixes used in the ACP to the 2451 ACP edge device. 2453 Aggregated prefix means that the ACP edge device needs to only 2454 announce the /48 ULA prefixes used in the ACP but none of the actual 2455 /64 (Manual Addressing Sub-Scheme), /127 (Zone Addressing Sub- 2456 Scheme), /112 or /120 (Vlong Addressing Sub-Scheme) routes of actual 2457 ACP devices. If ACP interfaces are configured with non ULA prefixes, 2458 then those prefixes can not be aggreged without further configured 2459 policy on the ACP edge device. This explains the above 2460 recommendation to use ACP ULA prefix covered prefixes for ACP connect 2461 interfaces: They allow for a shorter list of prefixes to be signalled 2462 via RFC4191 to NMS hosts and software components. 2464 The ACP edge devices that have a Vlong ACP address MAY allocate a 2465 subset of their /112 or /120 address prefix to ACP connect 2466 interface(s) to eliminate the need to non-autonomically configure/ 2467 provision the address prefixes for such ACP connect interfaces. See 2468 Section 11 for considerations how this updates the IPv6 address 2469 architecture and ULA specification. 2471 8.1.4. Combined ACP and Data Data Plane Interface (VRF Select) 2473 Combined ACP and Data Plane interface 2474 . 2475 +--------+ +--------------------+ . +--------------+ 2476 | ACP | |ACP Edge Device | . | NMS Host(s) | 2477 | Device | | | . | / Software | 2478 | | | [ACP ]. | . | |+ 2479 | | | .[VRF ] .[VRF ] | v | "ACP address"|| 2480 | +-------+. .[Select].+--------+ "Date Plane || 2481 | | ^ | .[Data ]. | | Address(es)"|| 2482 | | . | [Plane] | | || 2483 | | . | [VRF ] | +--------------+| 2484 +--------+ . +--------------------+ +--------------+ 2485 . 2486 data-plane "native" and + ACP auto-negotiated/encrypted 2488 Figure 9: VRF select 2490 Using two physical and/or virtual subnets (and therefore interfaces) 2491 into NMS Hosts (as per Section 8.1.1) or Software (as per 2492 Section 8.1.2) may be seen as additional complexity, for example with 2493 legacy NMS Hosts that support only one IP interface. 2495 To provide a single subnet into both ACP and Data Plane, the ACP Edge 2496 device needs to demultiplex packets from NMS hosts into ACP VRF and 2497 Data Plane VRF. This is sometimes called "VRF select". If the ACP 2498 VRF has no overlapping IPv6 addresses with the Data Plane (as it 2499 should), then this function can use the IPv6 Destination address. 2500 The problem is Source Address Selection on the NMS Host(s) according 2501 to RFC6724. 2503 Consider the simple case: The ACP uses only one ULA prefix, the ACP 2504 IPv6 prefix for the Combined ACP and Data Plane interface is covered 2505 by that ULA prefix. The ACP edge device announces both the ACP IPv6 2506 prefix and one (or more) prefixes for the data plane. Without 2507 further policy configurations on the NMS Host(s), it may select its 2508 ACP address as a source address for Data Plane ULA destinations 2509 because of Rule 8 of RFC6724. The ACP edge device can pass on the 2510 packet to the Data Plane, but the ACP source address should not be 2511 used for Data Plane traffic, and return traffic may fail. 2513 If the ACP carries multiple ULA prefixes or non-ULA ACP connect 2514 prefixes, then the correct source address selection becomes even more 2515 problematic. 2517 With separate ACP connect and Data Plane subnets and RFC4191 prefix 2518 announcements that are to be routed across the ACP connect interface, 2519 RFC6724 source address selection Rule 5 (use address of outgoing 2520 interface) will be used, so that above problems do not occur, even in 2521 more complex cases of multiple ULA and non-ULA prefixes in the ACP 2522 routing table. 2524 To achieve the same behavior with a Combined ACP and Data Plane 2525 interface, the ACP Edge Device needs to behave as two separate 2526 routers on the interface: One link-local IPv6 address/router for its 2527 ACP reachability, and one link-local IPv6 address/router for its Data 2528 Plane reachability. The Router Advertisements for both are as 2529 described above (Section 8.1.3): For the ACP, the ACP prefix is 2530 announced together with RFC4191 option for the prefixes routed across 2531 the ACP and lifetime=0 to disqualify this next-hop as a default 2532 router. For the Data Plane, the Data Plane prefix(es) are announced 2533 together with whatever dafault router parameters are used for the 2534 Data Plane. 2536 In result, RFC6724 source address selection Rule 5.5 may result in 2537 the same correct source address selection behavior of NMS hosts 2538 without further configuration on it as the separate ACP connect and 2539 Data Plane interfaces. As described in the text for Rule 5.5, this 2540 is only a may, because IPv6 hosts are not required to track next-hop 2541 information. If an NMS Host does not do this, then separate ACP 2542 connect and Data Plane interfaces are the preferrable method of 2543 attachment. 2545 ACP edge devices MAY support the Combined ACP and Data Plane 2546 interface. 2548 8.1.5. Use of GRASP 2550 GRASP can and should be possible to use across ACP connect 2551 interfaces, especially in the architectural correct solution when it 2552 is used as a mechanism to connect Software (eg: ASA or legacy NMS 2553 applications) to the ACP. Given how the ACP is the security and 2554 transport substrate for GRASP, the trustworthyness of devices/ 2555 software allowed to participate in the ACP GRASP domain is one of the 2556 main reasons why the ACP section describes no solution with non-ACP 2557 routers participating in the ACP routing table. 2559 ACP connect interfaces can be dealt with in the GRASP ACP domain like 2560 any other ACP interface assuming that any physical ACP connect 2561 interface is physically protected from attacks and that the connected 2562 Software or NMS Hosts are equally trusted as that on other ACP 2563 devices. ACP edge devices SHOULD have options to filter GRASP 2564 messages in and out of ACP connect interfaces (permit/deny) and MAY 2565 have more fine-grained filtering (eg: based on IPv6 address of 2566 originator or objective). 2568 When using "Combined ACP and Data Plane Interfaces", care must be 2569 taken that only GRASP messages intended for the ACP GRASP domain 2570 received from Software or NMS Hosts are forwarded by ACP edge 2571 devices. Currently there is no definition for a GRASP security and 2572 transport substrate beside the ACP, so there is no definition how 2573 such Software/NMS Host could participate in two separate GRASP 2574 Domains across the same subnet (ACP and Data Plane domains). At 2575 current it is therefore assumed that all GRASP packets on a Combined 2576 ACP and Data Plane interface belong to the GRASP ACP Domain. They 2577 must therefore all use the ACP IPv6 addresses of the Software/NMS 2578 Hosts. The link-local IPv6 addresses of Software/NMS Hosts (used for 2579 GRASP M_DISCOVERY and M_FLOOD messages) are also assumed to belong to 2580 the ACP address space. 2582 8.2. ACP through Non-Autonomic L3 Clouds (Remote ACP neighbors) 2584 Not all devices in a network may support the ACP. If non-ACP Layer-2 2585 devices are between ACP nodes, the ACP will work across it since it 2586 is IP based. However, the autonomic discovery of ACP neigbhors via 2587 DULL GRASP is only intended to work across L2 connections, so it is 2588 not sufficient to autonomically create ACP connections across non-ACP 2589 Layer-3 devices. 2591 8.2.1. Configured Remote ACP neighbor 2593 On the autonomic device remote ACP neighbors are configured as 2594 follows: 2596 remote-peer = [ local-address, method, remote-address ] 2597 local-address = ip-address 2598 remote-address = transport-address 2599 transport-address = 2600 [ (ip-address | pattern) ?( , protocol ?(, port)) (, pmtu) ] 2601 ip-address = (ipv4-address | ipv6-address ) 2602 method = "IKEv2" / "dTLS" / .. 2603 pattern = some IP address set 2605 For each candidate configured remote ACP neighbor, the secure channel 2606 protocol "method" is configured with its expected local IP address 2607 and remote transport endpoint (transport protocol and port number for 2608 the remote transport endpoint are usually not necessary to configure 2609 if defaults for the secure channel protocol method exist. 2611 This is the same information that would be communicated via DULL for 2612 L2 adjacent candidate ACP neighbors. DULL is not used because the 2613 remote IP address would need to be configured anyhow and if the 2614 remote transport address would not be configured but learned via DULL 2615 then this would create a third party attack vector. 2617 The secure channel method leverages the configuration to filter 2618 incoming connection requests by the remote IP address. This is 2619 suplemental security. The primary security is via the mutual domain 2620 certificate based authentication of the secure channel protocol. 2622 On a hub device, the remote IP address may be set to some pattern 2623 instead of explicit IP addresses. In this case, the device does not 2624 attempt to initiate secure channel connections but only acts as their 2625 responder. This allows for simple hub&spoke setups for the ACP where 2626 some method (subject to further specification) provisions the 2627 transport-address of hubs into spokes and hubs accept connections 2628 from any spokes. The typical use case for this are spokes connecting 2629 via the Internet to hubs. For example, this would be simple 2630 extension to BRSKI to allow zero-touch security across the Internet. 2632 Unlike adjacent ACP neighbor connections, configured remote ACP 2633 neighbor connections can also be across IPv4. Not all (future) 2634 secure channel methods may support running IPv6 (as used in the ACP 2635 across the secure channel connection) over IPv4 encapsulation. 2637 Unless the secure channel method supports PMTUD, it needs to be set 2638 up with minimum MTU or the path mtu (pmtu) should be configured. 2640 8.2.2. Tunneled Remote ACP Neighbor 2642 An IPinIP, GRE or other form of pre-existing tunnel is configured 2643 between two remote ACP peers and the virtual interfaces representing 2644 the tunnel are configured to "ACP enable". This will enable IPv6 2645 link local addresses and DULL on this tunnel. In result, the tunnel 2646 is used for normal "L2 adjacent" candidate ACP neighbor discovery 2647 with DULL and secure channel setup procedures described in this 2648 document. 2650 Tunneled Remote ACP Neighbor requires two encapsulations: the 2651 configured tunnel and the secure channel inside of that tunnel. This 2652 makes it in general less desirable than Configured Remote ACP 2653 Neighbor. Benefits of tunnels are that it may be easier to implement 2654 because there is no change to the ACP functionality - just running it 2655 over a virtual (tunnel) interface instead of only physical 2656 interfaces. The tunnel itself may also provide PMTUD while the 2657 secure channel method may not. Or the tunnel mechanism is permitted/ 2658 possible through some firewall while the secure channel method may 2659 not. 2661 8.2.3. Summary 2663 Configured/Tunneled Remote ACP neighbors are less "indestructible" 2664 than L2 adjacent ACP neighbors based on link local addressing, since 2665 they depend on more correct data plane operations, such as routing 2666 and global addressing. 2668 Nevertheless, these options may be crucial to incrementally deploy 2669 the ACP, especially if it is meant to connect islands across the 2670 Internet. Implementations SHOULD support at least Tunneled Remote 2671 ACP Neighbors via GRE tunnels - which is likely the most common 2672 router-to-router tunneling protocol in use today. 2674 Future work could envisage an option where the edge devices of the L3 2675 cloud is configured to automatically forward ACP discovery messages 2676 to the right exit point. This optimisation is not considered in this 2677 document. 2679 9. Benefits (Informative) 2681 9.1. Self-Healing Properties 2683 The ACP is self-healing: 2685 o New neighbors will automatically join the ACP after successful 2686 validation and will become reachable using their unique ULA 2687 address across the ACP. 2689 o When any changes happen in the topology, the routing protocol used 2690 in the ACP will automatically adapt to the changes and will 2691 continue to provide reachability to all devices. 2693 o If an existing device gets revoked, it will automatically be 2694 denied access to the ACP as its domain certificate will be 2695 validated against a Certificate Revocation List during 2696 authentication. Since the revocation check is only done at the 2697 establishment of a new security association, existing ones are not 2698 automatically torn down. If an immediate disconnect is required, 2699 existing sessions to a freshly revoked device can be re-set. 2701 The ACP can also sustain network partitions and mergers. Practically 2702 all ACP operations are link local, where a network partition has no 2703 impact. Devices authenticate each other using the domain 2704 certificates to establish the ACP locally. Addressing inside the ACP 2705 remains unchanged, and the routing protocol inside both parts of the 2706 ACP will lead to two working (although partitioned) ACPs. 2708 There are few central dependencies: A certificate revocation list 2709 (CRL) may not be available during a network partition; a suitable 2710 policy to not immediately disconnect neighbors when no CRL is 2711 available can address this issue. Also, a registrar or Certificate 2712 Authority might not be available during a partition. This may delay 2713 renewal of certificates that are to expire in the future, and it may 2714 prevent the enrolment of new devices during the partition. 2716 After a network partition, a re-merge will just establish the 2717 previous status, certificates can be renewed, the CRL is available, 2718 and new devices can be enrolled everywhere. Since all devices use 2719 the same trust anchor, a re-merge will be smooth. 2721 Merging two networks with different trust anchors requires the trust 2722 anchors to mutually trust each other (for example, by cross-signing). 2723 As long as the domain names are different, the addressing will not 2724 overlap (see Section 6.10). 2726 It is also highly desirable for implementation of the ACP to be able 2727 to run it over interfaces that are administratively down. If this is 2728 not feasible, then it might instead be possible to request explicit 2729 operator override upon administrative actions that would 2730 administratively bring down an interface across whicht the ACP is 2731 running. Especially if bringing down the ACP is known to disconnect 2732 the operator from the device. For example any such down 2733 administrative action could perform a dependency check to see if the 2734 transport connection across which this action is performed is 2735 affected by the down action (with default RPL routing used, packet 2736 forwarding will be symmetric, so this is actually possible to check). 2738 9.2. Self-Protection Properties 2740 9.2.1. From the outside 2742 As explained in Section 6, the ACP is based on secure channels built 2743 between devices that have mutually authenticated each other with 2744 their domain certificates. The channels themselves are protected 2745 using standard encryption technologies like DTLS or IPsec which 2746 provide additional authentication during channel establishment, data 2747 integrity and data confidentiality protection of data inside the ACP 2748 and in addition, provide replay protection. 2750 An attacker will therefore not be able to join the ACP unless having 2751 a valid domain certificate, also packet injection and sniffing 2752 traffic will not be possible due to the security provided by the 2753 encryption protocol. 2755 The ACP also serves as protection (through authentication and 2756 encryption) for protocols relevant to OAM that may not have secured 2757 protocol stack options or where implementation or deployment of those 2758 options fails on some vendor/product/customer limitations. This 2759 includes protocols such as SNMP, NTP/PTP, DNS, DHCP, syslog, 2760 Radius/Diameter/Tacacs, IPFIX/Netflow - just to name a few. 2761 Protection via the ACP secure hop-by-hop channels for these protocols 2762 is meant to be only a stopgap though: The ultimate goal is for these 2763 and other protocols to use end-to-end encryption utilizing the domain 2764 certificate and rely on the ACP secure channels primarily for zero- 2765 touch reliable connectivity, but not primarily for security. 2767 The remaining attack vector would be to attack the underlying AN 2768 protocols themselves, either via directed attacks or by denial-of- 2769 service attacks. However, as the ACP is built using link-local IPv6 2770 address, remote attacks are impossible. The ULA addresses are only 2771 reachable inside the ACP context, therefore unreachable from the data 2772 plane. Also, the ACP protocols should be implemented to be attack 2773 resistant and not consume unnecessary resources even while under 2774 attack. 2776 9.2.2. From the inside 2778 The security model of the ACP is based on trusting all members of the 2779 group of devices that do receive an ACP domain certificate for the 2780 same domain. Attacks from the inside by a compromised group member 2781 are therefore the biggest challenge. 2783 Group members must overall the secured so that there are no easy way 2784 to compromise them, such as data plane accessible privilege level 2785 with simple passwords. This is a lot easier to do in devices whose 2786 software is designed from the ground up with security in mind than 2787 with legacy software based system where ACP is added on as another 2788 feature. 2790 As explained above, traffic across the ACP SHOULD still be end-to-end 2791 encrypted whenever possible. This includes traffic such as GRASP, 2792 EST and BRSKI inside the ACP. This minimizes man in the middle 2793 attacks by compromised ACP group members. Such attackers can not 2794 eavesdrop or modify communications, they can just filter them (which 2795 is unavoidable by any means). 2797 Further security can be achieved by constraining communication 2798 patterns inside the ACP, for example through roles that could be 2799 encoded into the domain certificates. This is subject for future 2800 work. 2802 9.3. The Administrator View 2804 An ACP is self-forming, self-managing and self-protecting, therefore 2805 has minimal dependencies on the administrator of the network. 2806 Specifically, since it is independent of configuration, there is no 2807 scope for configuration errors on the ACP itself. The administrator 2808 may have the option to enable or disable the entire approach, but 2809 detailed configuration is not possible. This means that the ACP must 2810 not be reflected in the running configuration of devices, except a 2811 possible on/off switch. 2813 While configuration is not possible, an administrator must have full 2814 visibility of the ACP and all its parameters, to be able to do 2815 trouble-shooting. Therefore, an ACP must support all show and debug 2816 options, as for any other network function. Specifically, a network 2817 management system or controller must be able to discover the ACP, and 2818 monitor its health. This visibility of ACP operations must clearly 2819 be separated from visibility of data plane so automated systems will 2820 never have to deal with ACP aspect unless they explicitly desire to 2821 do so. 2823 Since an ACP is self-protecting, a device not supporting the ACP, or 2824 without a valid domain certificate cannot connect to it. This means 2825 that by default a traditional controller or network management system 2826 cannot connect to an ACP. See Section 8.1.1 for more details on how 2827 to connect an NMS host into the ACP. 2829 10. Further Considerations (Informative) 2831 The following sections cover topics that are beyond the primary cope 2832 of this document (eg: bootstrap), that explain decisions made in this 2833 document (eg: choice of GRASP) or that explain desirable extensions 2834 to the behavior of the ACP that are not far enough worked out to be 2835 already standardized in this document. 2837 10.1. Domain Certificate provisioning / enrollment 2839 [I-D.ietf-anima-bootstrapping-keyinfra] (BRSKI) describes how devices 2840 with an IDevID certificate can securely and zero-touch enroll with a 2841 domain certificate to support the ACP. BRSKI also leverages the ACP 2842 to enable zero touch bootstrap of new devices across networks without 2843 any configuration requirements across the transit devices (eg: no 2844 DHCP/DS forwarding/server setup). This includes otherwise 2845 unconfigured networks as described in Section 3.2. Therefore BRSKI 2846 in conjunction with ACP provides for a secure and zero-touch 2847 management solution for complete networks. Devices supporting such 2848 an infrastructure (BRSKI and ACP) are called ANI devices (Autonomic 2849 Networking Infrstructure), see [I-D.ietf-anima-reference-model]. 2850 Devices that do not support an IDevID but only an (insecure) vendor 2851 specific Unique Device Identifier (UDI) or devices whose manufacturer 2852 does not support a MASA could use some future security reduced 2853 version of BRSKI. 2855 When BRSKI is used to provision a domain certificate (which is called 2856 enrollment), the registrar (acting as an EST server) MUST include the 2857 subjectAltName / rfc822Name encoded ACP address and domain name to 2858 the enrolling device (called pledge) via its response to the pledges 2859 EST CSR Attribute request that is mandatory in BRSKI. 2861 The Certificate Authority in an ACP network MUST not change this, and 2862 create the respective subjectAltName / rfc822Name in the certificate. 2863 The ACP nodes can therefore find their ACP address and domain using 2864 this field in the domain certificate, both for themselves, as well as 2865 for other nodes. 2867 The use of BRSKI in conjunction with the ACP can also help to further 2868 simplify maintenance and renewal of domain certificates. Instead of 2869 relying on CRL, the lifetime of certificates can be made extremely 2870 small, for example in the order of hours. When a device fails to 2871 connect to the ACP within its certificate lifetime, it can not 2872 connect to the ACP to renew its certificate across it, but it can 2873 still renew its certificate as an "enrolled/expired pledge" via the 2874 BRSKI bootstrap proxy. This requires only that the enhanced EST 2875 server that is part of BRSKI honors expired domain certificates and 2876 that the pledge first attempts to perform TLS authentication for 2877 BRSKI bootstrap with its expired domain certificate - and only 2878 reverts to its IDevID when this fails. This mechanism also replaces 2879 CRLs because the EST server (in conunction with the CA) would not 2880 renew revoked certficates - but in this scheme only the EST-server 2881 need to know which certificate was revoked. 2883 In the absence of BRSKI or less secure variants thereof, provisioning 2884 of certificates may involve one or more touches or non-standardized 2885 automation. Device vendors usually support provisioning of 2886 certificates into devices via PKCS#7 (see [RFC2315]) and may support 2887 this provisioning through vendor specific models via Netconf 2888 ([RFC6241]). If such devices also support Netconf Zerotouch 2889 ([I-D.ietf-netconf-zerotouch]) then this can be combined to zero- 2890 touch provisioning of domain certificates into devices. Unless there 2891 are equivalent integration of Netconf connections across the ACP as 2892 there is in BRSKI, this combination would not support zero-touch 2893 bootstrap across an unconfigured network though. 2895 10.2. ACP Neighbor discovery protocol selection 2897 This section discusses why GRASP DULL was choosen as the discovery 2898 protocol for L2 adjacent candidate ACP neighbors. The contenders 2899 considered where GRASP, mDNS or LLDP. 2901 10.2.1. LLDP 2903 LLDP (and Cisco's similar CDP) are example of L2 discovery protocols 2904 that terminate their messages on L2 ports. If those protocols would 2905 be chosen for ACP neighbor discovery, ACP neighbor discovery would 2906 therefore also terminate on L2 ports. This would prevent ACP 2907 construction over non-ACP capable but LLDP or CDP enabled L2 2908 switches. LLDP has extensions using different MAC addresses and this 2909 could have been an option for ACP discovery as well, but the 2910 additional required IEEE standardization and definition of a profile 2911 for such a modified instance of LLDP seemed to be more work than the 2912 benefit of "reusing the existing protocol" LLDP for this very simple 2913 purpose. 2915 10.2.2. mDNS and L2 support 2917 mDNS [RFC6762] with DNS-SD RRs (Resource Records) as defined in 2918 [RFC6763] is a key contender as an ACP discovery protocol. because it 2919 relies on link-local IP multicast, it does operates at the subnet 2920 level, and is also found in L2 switches. The authors of this 2921 document are not aware of mDNS implementation that terminate their 2922 mDNS messages on L2 ports instead of the subnet level. If mDNS was 2923 used as the ACP discovery mechanism on an ACP capable (L3)/L2 switch 2924 as outlined in Section 7, then this would be necessary to implement. 2925 It is likely that termination of mDNS messages could only be applied 2926 to all mDNS messages from such a port, which would then make it 2927 necessary to software forward any non-ACP related mDNS messages to 2928 maintain prior non-ACP mDNS functionality. Adding support for ACP 2929 into such L2 switches with mDNS could therefore create regression 2930 problems for prior mDNS functionality on those devices. With low 2931 performance of software forwarding in many L2 switches, this could 2932 also make the ACP risky to support on such L2 switches. 2934 10.2.3. Why DULL GRASP 2936 LLDP was not considered because of the above mentioned issues. mDNS 2937 was not selected because of the above L2 mDNS considerations and 2938 because of the following additional points: 2940 If mDNS was not already existing in a device, it would be more work 2941 to implement than DULL GRASP, and if an existing implementation of 2942 mDNS was used, it would likely be more code space than a separate 2943 implementation of DULL GRASP or a shared implementation of DULL GRASP 2944 and GRASP in the ACP. 2946 10.3. Choice of routing protocol (RPL) 2948 This Appendix explains why RPL - "IPv6 Routing Protocol for Low-Power 2949 and Lossy Networks ([RFC6550] was chosen as the default (and in this 2950 specification only) routing protocol for the ACP. The choice and 2951 above explained profile was derived from a pre-standard 2952 implementation of ACP that was successfully deployed in operational 2953 networks. 2955 Requirements for routing in the ACP are: 2957 o Self-management: The ACP must build automatically, without human 2958 intervention. Therefore routing protocol must also work 2959 completely automatically. RPL is a simple, self-managing 2960 protocol, which does not require zones or areas; it is also self- 2961 configuring, since configuration is carried as part of the 2962 protocol (see Section 6.7.6 of [RFC6550]). 2964 o Scale: The ACP builds over an entire domain, which could be a 2965 large enterprise or service provider network. The routing 2966 protocol must therefore support domains of 100,000 nodes or more, 2967 ideally without the need for zoning or separation into areas. RPL 2968 has this scale property. This is based on extensive use of 2969 default routing. RPL also has other scalability improvements, 2970 such as selecting only a subset of peers instead of all possible 2971 ones, and trickle support for information synchronisation. 2973 o Low resource consumption: The ACP supports traditional network 2974 infrastructure, thus runs in addition to traditional protocols. 2975 The ACP, and specifically the routing protocol must have low 2976 resource consumption both in terms of memory and CPU requirements. 2977 Specifically, at edge nodes, where memory and CPU are scarce, 2978 consumption should be minimal. RPL builds a destination-oriented 2979 directed acyclic graph (DODAG), where the main resource 2980 consumption is at the root of the DODAG. The closer to the edge 2981 of the network, the less state needs to be maintained. This 2982 adapts nicely to the typical network design. Also, all changes 2983 below a common parent node are kept below that parent node. 2985 o Support for unstructured address space: In the Autonomic 2986 Networking Infrastructure, node addresses are identifiers, and may 2987 not be assigned in a topological way. Also, nodes may move 2988 topologically, without changing their address. Therefore, the 2989 routing protocol must support completely unstructured address 2990 space. RPL is specifically made for mobile ad-hoc networks, with 2991 no assumptions on topologically aligned addressing. 2993 o Modularity: To keep the initial implementation small, yet allow 2994 later for more complex methods, it is highly desirable that the 2995 routing protocol has a simple base functionality, but can import 2996 new functional modules if needed. RPL has this property with the 2997 concept of "objective function", which is a plugin to modify 2998 routing behaviour. 3000 o Extensibility: Since the Autonomic Networking Infrastructure is a 3001 new concept, it is likely that changes in the way of operation 3002 will happen over time. RPL allows for new objective functions to 3003 be introduced later, which allow changes to the way the routing 3004 protocol creates the DAGs. 3006 o Multi-topology support: It may become necessary in the future to 3007 support more than one DODAG for different purposes, using 3008 different objective functions. RPL allow for the creation of 3009 several parallel DODAGs, should this be required. This could be 3010 used to create different topologies to reach different roots. 3012 o No need for path optimisation: RPL does not necessarily compute 3013 the optimal path between any two nodes. However, the ACP does not 3014 require this today, since it carries mainly non-delay-sensitive 3015 feedback loops. It is possible that different optimisation 3016 schemes become necessary in the future, but RPL can be expanded 3017 (see point "Extensibility" above). 3019 10.4. Extending ACP channel negotiation (via GRASP) 3021 The mechanism described in the normative part of this document to 3022 support multiple different ACP secure channel protocols without a 3023 single network wide MTI protocol is important to allow extending 3024 secure ACP channel protocols beyond what is specified in this 3025 document, but it will run into problem if it would be used for 3026 multiple protocols: 3028 The need to potentially have multiple of these security associations 3029 even temporarily run in parallel to determine which of them works 3030 best does not support the most lightweight implementation options. 3032 The simple policy of letting one side (Alice) decide what is best may 3033 not lead to the mutual best result. 3035 The two limitations can easier be solved if the solution was more 3036 modular and as few as possible initial secure channel negotiation 3037 protocols would be used, and these protocols would then take on the 3038 responsibility to support more flexible objectives to negotiate the 3039 mutually preferred ACP security channel protocol. 3041 IKEv2 is the IETF standard protocol to negotiate network security 3042 associations. It is meant to be extensible, but it is unclear 3043 whether it would be feasible to extend IKEv2 to support possible 3044 future requirements for ACP secure channel negotiation: 3046 Consider the simple case where the use of native IPsec vs. IPsec via 3047 GRE is to be negotiated and the objective is the maximum throughput. 3048 Both sides would indicate some agreed upon performance metric and the 3049 preferred encapsulation is the one with the higher performance of the 3050 slower side. IKEv2 does not support negotiation with this objective. 3052 Consider dTLS and some form of 802.1AE (MacSEC) are to be added as 3053 negotiation options - and the performance objective should work 3054 across all IPsec, dDTLS and 802.1AE options. In the case of MacSEC, 3055 the negotiation would also need to determine a key for the peering. 3056 It is unclear if it would be even appropriate to consider extending 3057 the scope of negotiation in IKEv2 to those cases. Even if feasible 3058 to define, it is unclear if implementations of IKEv2 would be eager 3059 to adopt those type of extension given the long cycles of security 3060 testing that necessarily goes along with core security protocols such 3061 as IKEv2 implementations. 3063 A more modular alternative to extending IKEv2 could be to layer a 3064 modular negotiation mechanism on top of the multitide of existing or 3065 possible future secure channel protocols. For this, GRASP over TLS 3066 could be considered as a first ACP secure channel negotiation 3067 protocol. The following are initial considerations for such an 3068 approach. A full specification is subject to a separate document: 3070 To explicitly allow negotiation of the ACP channel protocol, GRASP 3071 over a TLS connection using the GRASP_LISTEN_PORT and the devices and 3072 peers link-local IPv6 address is used. When Alice and Bob support 3073 GRASP negotiation, they do prefer it over any other non-explicitly 3074 negotiated security association protocol and should wait trying any 3075 non-negotiated ACP channel protocol until after it is clear that 3076 GRASP/TLS will not work to the peer. 3078 When Alice and Bob successfully establish the GRASP/TSL session, they 3079 will negotiate the channel mechanism to use using objectives such as 3080 performance and perceived quality of the security. After agreeing on 3081 a channel mechanism, Alice and Bob start the selected Channel 3082 protocol. Once the secure channel protocol is successfully running, 3083 the GRASP/TLS connection can be kept alive or timed out as long as 3084 the selected channel protocol has a secure association between Alice 3085 and Bob. When it terminates, it needs to be re-negotiated via GRASP/ 3086 TLS. 3088 Notes: 3090 o Negotiation of a channel type may require IANA assignments of code 3091 points. 3093 o TLS is subject to reset attacks, which IKEv2 is not. Normally, 3094 ACP connections (as specified in this document) will be over link- 3095 local addresses so the attack surface for this one issue in TCP 3096 should be reduced (note that this may not be true when ACP is 3097 tunneled as described in Section 8.2.2. 3099 o GRASP packets received inside a TLS connection established for 3100 GRASP/TLS ACP negotiation are assigned to a separate GRASP domain 3101 unique to that TLS connection. 3103 10.5. CAs, domains and routing subdomains 3105 There is a wide range of setting up different ACP solution by 3106 appropriately using CAs and the domain and rsub elements in the ACP 3107 information field of the domain certificate. We summarize these 3108 options here as they have been explained in different parts of the 3109 document in before and discuss possible and desirable extensions: 3111 An ACP domain is the set of all ACP devices using certificates from 3112 the same CA using the same domain field. GRASP inside the ACP is run 3113 across all transitively connected ACP devices in a domain. 3115 The rsub element in the ACP information field primarily allows to use 3116 addresses from different ULA prefixes. One use case is to create 3117 multiple networks that initially may be separated, but where it 3118 should be possible to connect them without further extensions to ACP 3119 when necessary. 3121 Another use case for routing subdomains is as the starting point for 3122 structuring routing inside an ACP. For example, different routing 3123 subdomains could run different routing protocols or different 3124 instances of RPL and auto-aggregation / distribution of routes could 3125 be done across inter routing subdomain ACP channels based on 3126 negotiation (eg: via GRASP). This is subject for further work. 3128 RPL scales very well. It is not necessary to use multiple routing 3129 subdomains to scale autonomic domains in a way it would be possible 3130 if other routing protocols where used. They exist only as options 3131 for the above mentioned reasons. 3133 If different ACP domains are to be created that should not allow to 3134 connect to each other by default, these ACP domains simply need to 3135 have different domain elements in the ACP information field. These 3136 domain elements can be arbitrary, including subdomains of one 3137 another: Domains "example.com" and "research.example.com" are 3138 separate domains if both are domain elements in the ACP information 3139 element of certificates. 3141 It is not necessary to have a sparate CA for different ACP domains: 3142 an operator can use a single CA to sign certificates for multiple ACP 3143 domains that are not allowed to connect to each other because the 3144 checks for ACP adjacencies includes comparison of the domain part. 3146 If multiple independent networks choose the same domain name but had 3147 their own CA, these would not form a single ACP domain because of CA 3148 mismatch. Therefore there is no problem in choosing domain names 3149 that are potentially also used by others. Nevertheless it is highly 3150 recommended to use domain names that one can have high probability to 3151 be unique. It is recommended to use domain names that start with a 3152 DNS domain names owned by the assigning organization and unique 3153 within it. For example "acp.example.com" if you own "example.com". 3155 Future extensions, primarily through intent can create more flexible 3156 options how to build ACP domains. 3158 Intent could modify the ACP connection check to permit connections 3159 between different domains. 3161 If different domains use the same CA one would change the ACP setup 3162 to permit for the ACP to be established between the two ACP devices, 3163 but no routing nor ACP GRASP to be built across this adjacency. The 3164 main difference over routing subdomains is to not permit for the ACP 3165 GRASP instance to be build across the adjacency. Instead, one would 3166 only build a point to point GRASP instance between those peers to 3167 negotiate what type of exchanges are desired across that connection. 3168 This would include routing negotiation, how much GRASP information to 3169 transit and what data-plane forwarding should be done. This approach 3170 could also allow for for Intent to only be injected into the network 3171 from one side and propagate via this GRASP connection. 3173 If different domains have different CAs, they should start to trust 3174 each other by intent injected into both domains that would add the 3175 other domains CA as a trust point during the ACP connection setup - 3176 and then following up with the previous point of inter-domain 3177 connections across domains with the same CA (eg: GRASP negotiation). 3179 11. RFC4291/RFC4193 Updates Considerations 3181 This document may be considered to be updating the IPv6 addressing 3182 architecture ([RFC4291]) and/or the Unique Local IPv6 Unicast 3183 addresses ([RFC4193]) depending on how strict specific statements in 3184 those specs are to be interpreted. This section summarized and 3185 explains the necessity and benefits of these changes. The normative 3186 parts of this document cover the actual updates. 3188 ACP addresses (Section 6.10) are used by network devices supporting 3189 the ACP. They are assigned during bootstrap of the device or initial 3190 provisioning of the ACP. They are encoded in the Domain Certificate 3191 of the device and are primarily used internally within the network 3192 device. In that role they can be thought of as loopback addresses. 3194 Each ACP domain assigns ACP addresses from one or more ULA prefixes. 3195 Within an ACP network, addresses are assigned by nodes called 3196 registrars. A unique Registrar-ID(entifier) is used in ACP addresses 3197 to allow multiple registrars to assign addresses autonomously and 3198 uncoordinated from each other. Typically these Registrar-IDs are 3199 derived from the IEEE 802 48-bit MAC addresses of registrars. 3201 In the ACP Zone Addressing Sub-Scheme (Section 6.10.3), the registrar 3202 assigns a unique 15 bit value to an ACP device. The ACP address has 3203 a 64-bit Device-ID(entifier) composed of the 48-bit Registrar-ID, the 3204 registrar assigned 15-bit Device-Number and 1 V(irtualization) bit 3205 that allows for an ACP device to have two addresses. 3207 The 64-bit Device-Identifier in the ACP Zone Addressing Sub-Scheme 3208 matches the 64 bit Interface Identifier (IID) address part as 3209 specified in RFC4291 section 2.5.1. IIDs are unique across ACP 3210 devices, but all ACP devices with the same ULA prefix that use the 3211 ACP Zone Addressing Sub-Scheme will share the same subnet prefix 3212 (according to the definition of that term in RFC4291). Each ACP 3213 device injects a /127 route into the ACP routing table to cover its 3214 two assigned addresses (V(irtual) bit being 0 or 1). This approach 3215 is used because these ACP addresses are identifiers and not locators. 3216 The ACP device can connect anywhere in the autonomic domain without 3217 having to change its addresses. A lightweight, highly scaleable 3218 routing protocol (RPL) is used to allow for large scale ACP networks. 3220 It is possible, that this scheme constitutes an update to RFC4191 3221 because the same 64 bit subnet prefix is used across many ACP 3222 devices. The ACP Zone addressing Sub-Scheme is very similar to the 3223 common operational practices of assigning /128 loopback addresses to 3224 network devices from the same /48 or /64 subnet prefix. 3226 In the ACP Vlong Addressing Sub-Scheme (Section 6.10.5), the address 3227 elements are the same as described for the Zone Addressing Sub- 3228 Scheme, but the V field is expanded from 1 bit to 8 or 16 bits. The 3229 ACP device with ACP Vlong addressing therefore injects /120 or /112 3230 prefixes into the ACP routing table to cover its internal addresses. 3232 The goal for the 8 or 16-bit addresses available to an ACP device in 3233 this scheme is to assign them as required to software components, 3234 which in autonomic networking are called ASA (Autonomic Service 3235 Agents). It could equally be used for existing software components 3236 such as VNFs (Virtual Networking Functions). The ACP interface would 3237 then be the out-of-band management interface of such a VNF software 3238 component. It should especially be possible to use these software 3239 components in a variety of contexts to allow standardized modular 3240 system composition: Native applications (in some VRF context if 3241 available), containers, virtual machines or other future ones. To 3242 modularily compose a system with containers and virtual machines and 3243 avoid problems such as port space collision or NAT, it is necessary 3244 not only to assign separate addresses to those contexts, but also to 3245 use the notion of virtual interfaces between these contexts to 3246 compose the system. 3248 In practical terms, the ACP should be enabled to create from its /8 3249 or /16 prefix one or more device internal virtual subnets and to 3250 start software components connected to those virtual subnets. 3251 Ideally, these software components should be able to autoconfigure 3252 their addresses on these virtual interfaces. Future work has to 3253 determine whether this address autoconfiguration for the virtual 3254 interface is best done with DHCPv6, if SLAAC should be recommended 3255 for these /8 or /16 virtual interfaces, or if some additional 3256 standardized method would be required. 3258 In the ACP Vlong Addressing scheme, the Device-ID does not match the 3259 RFC4291/RFC4193 64 bith length for the Interface Identifier, so this 3260 addressing Sub-Scheme in the ACP is an update to both standards. 3262 This document also specifies the workaround solution of exposing the 3263 ACP on physical interfaces in support of adoption by existing 3264 hardware and software solutions. A NOC based NMS host could for 3265 example be configured with a second physical interface connecting to 3266 an ACP device that exposes the ACP to that NMS host (called ACP edge 3267 device). The desired evolution of this workaround is that those two 3268 functions would merge into a single device, for example by making the 3269 ACP router a container/virtual machine inside the NMS host or vice 3270 versa. The addressing for those physical interfaces allows for 3271 manually configured address prefixes but it could be fully autonomous 3272 if it could leverage the Vlong addressing format. That would result 3273 in a non /64 IID boundary on those external interfaces (but instead 3274 in /112 or /120 subnet prefixes). 3276 Note that both in the internal as well as the workaround external use 3277 of ACP addresses, all ACP addresses are meant to be used exclusively 3278 by components that are part of network control and OAM, but not for 3279 network users such as normal hosts. This implies that for example no 3280 requirements for privacy addressing have been identified for ACP 3281 addresses. 3283 12. Security Considerations 3285 An ACP is self-protecting and there is no need to apply configuration 3286 to make it secure. Its security therefore does not depend on 3287 configuration. 3289 However, the security of the ACP depends on a number of other 3290 factors: 3292 o The usage of domain certificates depends on a valid supporting PKI 3293 infrastructure. If the chain of trust of this PKI infrastructure 3294 is compromised, the security of the ACP is also compromised. This 3295 is typically under the control of the network administrator. 3297 o Security can be compromised by implementation errors (bugs), as in 3298 all products. 3300 There is no prevention of source-address spoofing inside the ACP. 3301 This implies that if an attacker gains access to the ACP, it can 3302 spoof all addresses inside the ACP and fake messages from any other 3303 device. 3305 Fundamentally, security depends on correct operation, implementation 3306 and architecture. Autonomic approaches such as the ACP largely 3307 eliminate the dependency on correct operation; implementation and 3308 architectural mistakes are still possible, as in all networking 3309 technologies. 3311 Many design details of ACP are designed with security in mind and 3312 discussed elsehwere in the document: 3314 IPv6 addresses used by devices in the ACP are covered as part of the 3315 Device AN domain certificate as described in Section 6.1.1. This 3316 allows even verification of ownership of a peers IPv6 address when 3317 using a connection authenticated with the AN domain certificate. 3319 The ACP acts as a security (and transport) substrate for GRASP inside 3320 the ACP such that GRASP is not only protected by atacks from the 3321 outside, but also by attacks from compromised inside attackers - by 3322 relying not only on hop-by-hop security of ACP secure channels, but 3323 adding end-to-end security for those GRASP messages. See 3324 Section 6.8.2. 3326 ACP provides for secure, resilient zero-touch discovery of EST 3327 servers for certificate renewal. See Section 6.1.2. 3329 ACP provides extensible, auto-configuring hop-by-hop protection of 3330 the ACP infrastructure via the negotiation of hop-by-hop secure 3331 channel protocols. See Section 6.5 and Section 10.4. 3333 The ACP is designed to minimize attacks from the outside by 3334 minimizing its dependency against any non-ACP operations on a network 3335 device. The only dependency in the specification in this document is 3336 the need to share link-local addresses for the ACP secure channel 3337 encapsulation with the data plane. See Section 6.12.2. 3339 In combination with BRSKI, ACP enables a resilient, fully zero-touch 3340 network solution for short-lived certificates that can be renewed or 3341 re-enrolled even after unintential expiry (eg: because of interrupted 3342 connectivity). See Section 10.1. 3344 13. IANA Considerations 3346 This document defines the "Autonomic Control Plane". 3348 The IANA is requested to create an ACP Parameter Registry with 3349 currently one registry table - the "ACP Address Type" table. 3351 "ACP Address Type" Table. The value in this table are numeric values 3352 0...3 paired with a name (string). Future values values MUST be 3353 assigned using the Standards Action policy defined by [RFC8126]. The 3354 following initial values are assigned by this document: 3356 0: ACP Zone Addressing Sub-Scheme (ACP RFC Figure 4) / ACP Manual 3357 Addressing Sub-Scheme (ACP RFC Section 6.10.4) 3358 1: ACP Vlong Addressing Sub-Scheme (ACP RFC Section 6.10.5) 3360 14. Acknowledgements 3362 This work originated from an Autonomic Networking project at Cisco 3363 Systems, which started in early 2010. Many people contributed to 3364 this project and the idea of the Autonomic Control Plane, amongst 3365 which (in alphabetical order): Ignas Bagdonas, Parag Bhide, Balaji 3366 BL, Alex Clemm, Yves Hertoghs, Bruno Klauser, Max Pritikin, Michael 3367 Richardson, Ravi Kumar Vadapalli. 3369 Special thanks to Pascal Thubert and Michael Richardson to provide 3370 the details for the recommendations of the use of RPL in the ACP 3372 Further input and suggestions were received from: Rene Struik, Brian 3373 Carpenter, Benoit Claise. 3375 15. Change log [RFC Editor: Please remove] 3377 15.1. Initial version 3379 First version of this document: draft-behringer-autonomic-control- 3380 plane 3382 15.2. draft-behringer-anima-autonomic-control-plane-00 3384 Initial version of the anima document; only minor edits. 3386 15.3. draft-behringer-anima-autonomic-control-plane-01 3388 o Clarified that the ACP should be based on, and support only IPv6. 3390 o Clarified in intro that ACP is for both, between devices, as well 3391 as for access from a central entity, such as an NMS. 3393 o Added a section on how to connect an NMS system. 3395 o Clarified the hop-by-hop crypto nature of the ACP. 3397 o Added several references to GDNP as a candidate protocol. 3399 o Added a discussion on network split and merge. Although, this 3400 should probably go into the certificate management story longer 3401 term. 3403 15.4. draft-behringer-anima-autonomic-control-plane-02 3405 Addresses (numerous) comments from Brian Carpenter. See mailing list 3406 for details. The most important changes are: 3408 o Introduced a new section "overview", to ease the understanding of 3409 the approach. 3411 o Merged the previous "problem statement" and "use case" sections 3412 into a mostly re-written "use cases" section, since they were 3413 overlapping. 3415 o Clarified the relationship with draft-ietf-anima-stable- 3416 connectivity 3418 15.5. draft-behringer-anima-autonomic-control-plane-03 3420 o Took out requirement for IPv6 --> that's in the reference doc. 3422 o Added requirement section. 3424 o Changed focus: more focus on autonomic functions, not only virtual 3425 out of band. This goes a bit throughout the document, starting 3426 with a changed abstract and intro. 3428 15.6. draft-ietf-anima-autonomic-control-plane-00 3430 No changes; re-submitted as WG document. 3432 15.7. draft-ietf-anima-autonomic-control-plane-01 3434 o Added some paragraphs in addressing section on "why IPv6 only", to 3435 reflect the discussion on the list. 3437 o Moved the data-plane ACP out of the main document, into an 3438 appendix. The focus is now the virtually separated ACP, since it 3439 has significant advantages, and isn't much harder to do. 3441 o Changed the self-creation algorithm: Part of the initial steps go 3442 into the reference document. This document now assumes an 3443 adjacency table, and domain certificate. How those get onto the 3444 device is outside scope for this document. 3446 o Created a new section 6 "workarounds for non-autonomic nodes", and 3447 put the previous controller section (5.9) into this new section. 3448 Now, section 5 is "autonomic only", and section 6 explains what to 3449 do with non-autonomic stuff. Much cleaner now. 3451 o Added an appendix explaining the choice of RPL as a routing 3452 protocol. 3454 o Formalised the creation process a bit more. Now, we create a 3455 "candidate peer list" from the adjacency table, and form the ACP 3456 with those candidates. Also it explains now better that policy 3457 (Intent) can influence the peer selection. (section 4 and 5) 3459 o Introduce a section for the capability negotiation protocol 3460 (section 7). This needs to be worked out in more detail. This 3461 will likely be based on GRASP. 3463 o Introduce a new parameter: ACP tunnel type. And defines it in the 3464 IANA considerations section. Suggest GRE protected with IPSec 3465 transport mode as the default tunnel type. 3467 o Updated links, lots of small edits. 3469 15.8. draft-ietf-anima-autonomic-control-plane-02 3471 o Added explicitly text for the ACP channel negotiation. 3473 o Merged draft-behringer-anima-autonomic-addressing-02 into this 3474 document, as suggested by WG chairs. 3476 15.9. draft-ietf-anima-autonomic-control-plane-03 3478 o Changed Neighbor discovery protocol from GRASP to mDNS. Bootstrap 3479 protocol team decided to go with mDNS to discover bootstrap proxy, 3480 and ACP should be consistent with this. Reasons to go with mDNS 3481 in bootstrap were a) Bootstrap should be reuseable also outside of 3482 full anima solutions and introduce as few as possible new 3483 elements. mDNS was considered well-known and very-likely even pre- 3484 existing in low-end devices (IoT). b) Using GRASP both for the 3485 insecure neighbor discovery and secure ACP operatations raises the 3486 risk of introducing security issues through implementation issues/ 3487 non-isolation between those two instances of GRASP. 3489 o Shortened the section on GRASP instances, because with mDNS being 3490 used for discovery, there is no insecure GRASP session any longer, 3491 simplifying the GRASP considerations. 3493 o Added certificate requirements for ANIMA in section 5.1.1, 3494 specifically how the ANIMA information is encoded in 3495 subjectAltName. 3497 o Deleted the appendix on "ACP without separation", as originally 3498 planned, and the paragraph in the main text referring to it. 3500 o Deleted one sub-addressing scheme, focusing on a single scheme 3501 now. 3503 o Included information on how ANIMA information must be encoded in 3504 the domain certificate in section "preconditions". 3506 o Editorial changes, updated draft references, etc. 3508 15.10. draft-ietf-anima-autonomic-control-plane-04 3510 Changed discovery of ACP neighbor back from mDNS to GRASP after 3511 revisiting the L2 problem. Described problem in discovery section 3512 itself to justify. Added text to explain how ACP discovery relates 3513 to BRSKY (bootstrap) discovery and pointed to Michael Richardsons 3514 draft detailing it. Removed appendix section that contained the 3515 original explanations why GRASP would be useful (current text is 3516 meant to be better). 3518 15.11. draft-ietf-anima-autonomic-control-plane-05 3520 o Section 5.3 (candidate ACP neighbor selection): Add that Intent 3521 can override only AFTER an initial default ACP establishment. 3523 o Section 6.10.1 (addressing): State that addresses in the ACP are 3524 permanent, and do not support temporary addresses as defined in 3525 RFC4941. 3527 o Modified Section 6.3 to point to the GRASP objective defined in 3528 draft-carpenter-anima-ani-objectives. (and added that reference) 3530 o Section 6.10.2: changed from MD5 for calculating the first 40 bits 3531 to SHA256; reason is MD5 should not be used any more. 3533 o Added address sub-scheme to the IANA section. 3535 o Made the routing section more prescriptive. 3537 o Clarified in Section 8.1.1 the ACP Connect port, and defined that 3538 term "ACP Connect". 3540 o Section 8.2: Added some thoughts (from mcr) on how traversing a L3 3541 cloud could be automated. 3543 o Added a CRL check in Section 6.7. 3545 o Added a note on the possibility of source-address spoofing into 3546 the security considerations section. 3548 o Other editoral changes, including those proposed by Michael 3549 Richardson on 30 Nov 2016 (see ANIMA list). 3551 15.12. draft-ietf-anima-autonomic-control-plane-06 3553 o Added proposed RPL profile. 3555 o detailed dTLS profile - dTLS with any additional negotiation/ 3556 signaling channel. 3558 o Fixed up text for ACP/GRE encap. Removed text claiming its 3559 incompatible with non-GRE IPsec and detailled it. 3561 o Added text to suggest admin down interfaces should still run ACP. 3563 15.13. draft-ietf-anima-autonomic-control-plane-07 3565 o Changed author association. 3567 o Improved ACP connect setion (after confusion about term came up in 3568 the stable connectivity draft review). Added picture, defined 3569 complete terminology. 3571 o Moved ACP channel negotiation from normative section to appendix 3572 because it can in the timeline of this document not be fully 3573 specified to be implementable. Aka: work for future document. 3574 That work would also need to include analysing IKEv2 and describin 3575 the difference of a proposed GRASP/TLS solution to it. 3577 o Removed IANA request to allocate registry for GRASP/TLS. This 3578 would come with future draft (see above). 3580 o Gave the name "ACP information field" to the field in the 3581 certificate carrying the ACP address and domain name. 3583 o Changed the rules for mutual authentication of certificates to 3584 rely on the domain in the ACP information field of the certificate 3585 instead of the OU in the certificate. Also renewed the text 3586 pointing out that the ACP information field in the certificate is 3587 meant to be in a form that it does not disturb other uses of the 3588 certificate. As long as the ACP expected to rely on a common OU 3589 across all certificates in a domain, this was not really true: 3590 Other uses of the certificates might require different OUs for 3591 different areas/type of devices. With the rules in this draft 3592 version, the ACP authentication does not rely on any other fields 3593 in the certificate. 3595 o Added an extension field to the ACP information field so that in 3596 the future additional fields like a subdomain could be inserted. 3597 An example using such a subdomain field was added to the pre- 3598 existing text suggesting sub-domains. This approach is necessary 3599 so that there can be a single (main) domain in the ACP information 3600 field, because that is used for mutual authentication of the 3601 certificate. Also clarified that only the register(s) SHOULD/MUST 3602 use that the ACP address was generated from the domain name - so 3603 that we can easier extend change this in extensions. 3605 o Took the text for the GRASP discovery of ACP neighbors from Brians 3606 grasp-ani-objectives draft. Alas, that draft was behind the 3607 latest GRASP draft, so i had to overhaul. The mayor change is to 3608 describe in the ACP draft the whole format of the M_FLOOD message 3609 (and not only the actual objective). This should make it a lot 3610 easier to read (without having to go back and forth to the GRASP 3611 RFC/draft). It was also necessary because the locator in the 3612 M_FLOOD messages has an important role and its not coded inside 3613 the objective. The specification of how to format the M_FLOOD 3614 message shuold now be complete, the text may be some duplicate 3615 with the DULL specificateion in GRASP, but no contradiction. 3617 o One of the main outcomes of reworking the GRASP section was the 3618 notion that GRASP announces both the candidate peers IPv6 link 3619 local address but also the support ACP security protocol including 3620 the port it is running on. In the past we shied away from using 3621 this information because it is not secured, but i think the 3622 additional attack vectors possible by using this information are 3623 negligible: If an attacker on an L2 subnet can fake another 3624 devices GRASP message then it can already provide a similar amount 3625 of attack by purely faking the link-local address. 3627 o Removed the section on discovery and BRSKI. This can be revived 3628 in the BRSKI document, but it seems mood given how we did remove 3629 mDNS from the latest BRSKI document (aka: this section discussed 3630 discrepancies between GRASP and mDNS discovery which should not 3631 exist anymore with latest BRSKI. 3633 o Tried to resolve the EDNOTE about CRL vs. OCSP by pointing out we 3634 do not specify which one is to be used but that the ACP should be 3635 used to reach the URL included in the certificate to get to the 3636 CRL storage or OCSP server. 3638 o Changed ACP via IPsec to ACP via IKEv2 and restructured the 3639 sections to make IPsec native and IPsec via GRE subsections. 3641 o No need for any assigned dTLS port if ACP is run across dTLS 3642 because it is signalled via GRASP. 3644 15.14. draft-ietf-anima-autonomic-control-plane-08 3646 Modified mentioning of BRSKI to make it consistent with current 3647 (07/2017) target for BRSKI: MASA and IDevID are mandatory. Devices 3648 with only insecure UDI would need a security reduced variant of 3649 BRSKI. Also added mentioning of Netconf Zerotouch. Made BRSKI non- 3650 normative for ACP because wrt. ACP it is just one option how the 3651 domain certificate can be provisioned. Instead, BRSKI is mandatory 3652 when a device implements ANI which is ACP+BRSKI. 3654 Enhanced text for ACP across tunnels to decribe two options: one 3655 across configured tunnels (GRE, IPinIP etc) a more efficient one via 3656 directed DULL. 3658 Moved decription of BRSKI to appendex to emphasize that BRSKI is not 3659 a (normative) dependency of GRASP, enhanced text to indicate other 3660 options how Domain Certificates can be provisioned. 3662 Added terminology section. 3664 Separated references into normative and non-normative. 3666 Enhanced section about ACP via "tunnels". Defined an option to run 3667 ACP secure channel without an outer tunnel, discussed PMTU, benefits 3668 of tunneling, potential of using this with BRSKI, made ACP via GREP a 3669 SHOULD requirement. 3671 Moved appendix sections up before IANA section because there where 3672 concerns about appendices to be to far on the bottom to be read. 3673 Added (Informative) / (Normative) to section titles to clarify which 3674 sections are informative and which are normative 3676 Moved explanation of ACP with L2 from precondition to separate 3677 section before workarounds, made it instructive enough to explain how 3678 to implement ACP on L2 ports for L3/L2 switches and made this part of 3679 normative requirement (L2/L3 switches SHOULD support this). 3681 Rewrote section "GRASP in the ACP" to define GRASP in ACP as 3682 mandatory (and why), and define the ACP as security and transport 3683 substrate to GRASP in ACP. And how it works. 3685 Enhanced "self-protection" properties section: protect legacy 3686 management protocols. Security in ACP is for protection from outside 3687 and those legacy protocols. Otherwise need end-to-end encryption 3688 also inside ACP, eg: with domain certificate. 3690 Enhanced initial domain certificate section to include requirements 3691 for maintenance (renewal/revocation) of certificates. Added 3692 explanation to BRSKI informative section how to handle very short 3693 lived certificates (renewal via BRSKI with expired cert). 3695 Modified the encoding of the ACP address to better fit RFC822 simple 3696 local-parts (":" as required by RFC5952 are not permitted in simple 3697 dot-atoms according to RFC5322. Removed reference to RFC5952 as its 3698 now not needed anymore. 3700 Introduced a sub-domain field in the ACP information in the 3701 certificate to allow defining such subdomains with depending on 3702 future Intent definitions. It also makes it clear what the "main 3703 domain" is. Scheme is called "routing subdomain" to have a unique 3704 name. 3706 Added V8 (now called Vlong) addressing sub-scheme according to 3707 suggestion from mcr in his mail from 30 Nov 2016 3708 (https://mailarchive.ietf.org/arch/msg/anima/ 3709 nZpEphrTqDCBdzsKMpaIn2gsIzI). Also modified the explanation of the 3710 single V bit in the first sub-scheme now renamed to Zone sub-scheme 3711 to distinguish it. 3713 15.15. draft-ietf-anima-autonomic-control-plane-09 3715 Added reference to RFC4191 and explained how it should be used on ACP 3716 edge routers to allow autoconfiguration of routing by NMS hosts. 3717 This came after review of stable connectivity draft where ACP connect 3718 is being referred to. 3720 V8 addressing Sub-Scheme was modified to allow not only /8 device- 3721 local address space but also /16. This was in response to the 3722 possible need to have maybe as much as 2^12 local addresses for 3723 future encaps in BRSKI like IPinIP. It also would allow fully 3724 autonomic address assignment for ACP connect interfaces from this 3725 local address space (on an ACP edge device), subject to approval of 3726 the implied update to rfc4291/rfc4193 (IID length). Changed name to 3727 Vlong addressing sub-scheme. 3729 Added text in response to Brian Carpenters review of draft-ietf- 3730 anima-stable-connectivity-04. 3732 o The stable connectivity draft was vaguely describing ACP connect 3733 behavior that is better standardized in this ACP draft. 3735 o Added new ACP "Manual" addressing sub-scheme with /64 subnets for 3736 use with ACP connect interfaces. Being covered by the ACP ULA 3737 prefix, these subnets do not require additional routing entries 3738 for NMS hosts. They also are fully 64-bit IID length compliant 3739 and therefore not subject to 4191bis considerations. And they 3740 avoid that operators manually assign prefixes from the ACP ULA 3741 prefixes that might later be assigned autonomiously. 3743 o ACP connect auto-configuration: Defined that ACP edge devices, NMS 3744 hosts should use RFC4191 to automatically learn ACP prefixes. 3745 This is especially necessary when the ACP uses multiple ULA 3746 prefixes (via eg: the rsub domain certificate option), or if ACP 3747 connect subinterfaces use manually configured prefixes NOT covered 3748 by the ACP ULA prefixes. 3750 o Explained how rfc6724 is (only) sufficient when the NMS host has a 3751 separate ACP connect and data plane interface. But not when there 3752 is a single interface. 3754 o Added a separate subsection to talk about "software" instead of 3755 "NMS hosts" connecting to the ACP via the "ACP connect" method. 3756 The reason is to point out that the "ACP connect" method is not 3757 only a workaround (for NMS hosts), but an actual desirable long 3758 term architectural component to modularily build software (eg: ASA 3759 or OAM for VNF) into ACP devices. 3761 o Added a section to define how to run ACP connect across the same 3762 interface as the Data Plane. This turns out to be quite 3763 challenging because we only want to rely on existing standards for 3764 the network stack in the NMS host/software and only define what 3765 features the ACP edge device needs. 3767 o Added section about use of GRASP over ACP connect. 3769 o Added text to indicate packet processing/filtering for security: 3770 filter incorrect packets arriving on ACP connect interfaces, 3771 diagnose on RPL root packets to incorrect destination address (not 3772 in ACP connect section, but because of it). 3774 o Reaffirm security goal of ACP: Do not permit non-ACP routers into 3775 ACP routing domain. 3777 Made this ACP document be an update to RFC4291 and RFC4193. At the 3778 core, some of the ACP addressing sub-schemes do effectively not use 3779 64-bit IIDs as required by RFC4191 and debated in rfc4191bis. During 3780 6man in prague, it was suggested that all documents that do not do 3781 this should be classified as such updates. Add a rather long section 3782 that summarizes the relevant parts of ACP addressing and usage and. 3783 Aka: This section is meant to be the primary review section for 3784 readers interested in these changes (eg: 6man WG.). 3786 Added changes from Michael Richardsons review https://github.com/ 3787 anima-wg/autonomic-control-plane/pull/3/commits, textual and: 3789 o ACP discovery inside ACP is bad *doh*!. 3791 o Better CA trust and revocation sentences. 3793 o More details about RPL behavior in ACP. 3795 o blackhole route to avoid loops in RPL. 3797 Added requirement to terminate ACP channels upon cert expiry/ 3798 revocation. 3800 Added fixes from 08-mcr-review-reply.txt (on github): 3802 o AN Domain Names are FQDNs. 3804 o Fixed bit length of schemes, numerical writing of bits (00b/01b). 3806 o Lets use US american english. 3808 15.16. draft-ietf-anima-autonomic-control-plane-10 3810 Used the term routing subdomain more consistently where previously 3811 only subdomain was used. Clarified use of routing subdomain in 3812 creation of ULA "global ID" addressing prefix. 3814 6.7.1.* Changed native IPsec encapsulation to tunnel mode 3815 (necessary), explaned why. Added notion that ESP is used, added 3816 explanations why tunnel/transport mode in native vs. GRE cases. 3818 6.10.3/6.10.5 Added term "ACP address range/set" to be able to better 3819 explain how the address in the ACP certificate is actually the base 3820 address (lowest address) of a range/set that is available to the 3821 device. 3823 6.10.4 Added note that manual address sub-scheme addresses must not 3824 be used within domain certificates (only for explicit configuration). 3826 6.12.5 Refined explanation of how ACP virtual interfaces work (p2p 3827 and multipoint). Did seek for pre-existing RFCs that explain how to 3828 built a multi-access interface on top of a full mesh of p2p 3829 connections (6man WG, anima WG mailing lists), but could not find any 3830 prior work that had a succinct explanation. So wrote up an 3831 explanation here. Added hopefully all necessary and sufficient 3832 details how to map ACP unicast packets to ACP secure channel, how to 3833 deal with ND packet details. Added verbage for ACP not to assign the 3834 virtual interface link-local address from the underlying interface. 3835 Addd note that GRAP link-local messages are treated specially but 3836 logically the same. Added paragraph about NBMA interfaces. 3838 remaining changes from Brian Carpenters review. See Github file 3839 draft-ietf-anima-autonomic-control-plane/08-carpenter-review-reply.tx 3840 for more detailst: 3842 Added multiple new RFC references for terms/technologies used. 3844 Fixed verbage in several places. 3846 2. (terminology) Added 802.1AR as reference. 3848 2. Fixed up definition of ULA. 3850 6.1.1 Changed definition of ACP information in cert into ABNF format. 3851 Added warning about maximum size of ACP address field due to domain- 3852 name limitations. 3854 6.2 Mentioned API requirement between ACP and clients leveraging 3855 adjacency table. 3857 6.3 Fixed TTL in GRASP example: msec, not hop-count!. 3859 6.8.2 MAYOR: expanded security/transport substrate text: 3861 Introduced term ACP GRASP virtual interface to explain how GRASP 3862 link-local multicast messages are encapsulated and replicated to 3863 neighbors. Explain how ACP knows when to use TLS vs. TCP (TCP only 3864 for link-local address (sockets). Introduced "ladder" picture to 3865 visualize stack. 3867 6.8.2.1 Expanded discussion/explanation of security model. TLS for 3868 GRASP unicsast connections across ACP is double encryption (plus 3869 underlying ACP secure channel), but highly necessary to avoid very 3870 simple man-in-the-middle attacks by compromised ACP members on-path. 3871 Ultimately, this is done to ensure that any apps using GRASP can get 3872 full end-to-end secrecy for information sent across GRASP. But for 3873 publically known ASA services, even this will not provide 100% 3874 security (this is discussed). Also why double encryption is the 3875 better/easier solution than trying to optimize this. 3877 6.10.1 Added discussion about pseudo-random addressing, scanning- 3878 attaacks (not an issue for ACP). 3880 6.12.2 New performance requirements section added. 3882 6.10.1 Added notion to first experiment with existing addressing 3883 schemes before defining new ones - we should be flexible enough. 3885 6.3/7.2 clarified the interactions between MLD and DULL GRASP and 3886 specified what needs to be done (eg: in 2 switches doing ACP per L2 3887 port). 3889 12. Added explanations and cross-references to various security 3890 aspects of ACP discussed elsewhere in the document. 3892 13. Added IANA requirements. 3894 Added RFC2119 boilerplate. 3896 15.17. draft-ietf-anima-autonomic-control-plane-11 3898 Same text as -10 Unfortunately when uploading -10 .xml/.txt to 3899 datatracker, a wrong version of .txt got uploaded, only the .xml was 3900 correct. This impacts the -10 html version on datatracker and the 3901 PDF versions as well. Because rfcdiff also compares the .txt 3902 version, this -11 version was created so that one can compare changes 3903 from -09 and changes to the next version (-12). 3905 16. References 3907 16.1. Normative References 3909 [I-D.ietf-anima-grasp] 3910 Bormann, C., Carpenter, B., and B. Liu, "A Generic 3911 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 3912 grasp-15 (work in progress), July 2017. 3914 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 3915 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 3916 . 3918 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3919 Requirement Levels", BCP 14, RFC 2119, 3920 DOI 10.17487/RFC2119, March 1997, 3921 . 3923 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 3924 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 3925 DOI 10.17487/RFC3810, June 2004, 3926 . 3928 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 3929 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 3930 November 2005, . 3932 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 3933 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 3934 . 3936 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 3937 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 3938 2006, . 3940 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 3941 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 3942 DOI 10.17487/RFC4861, September 2007, 3943 . 3945 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 3946 Address Autoconfiguration", RFC 4862, 3947 DOI 10.17487/RFC4862, September 2007, 3948 . 3950 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 3951 (TLS) Protocol Version 1.2", RFC 5246, 3952 DOI 10.17487/RFC5246, August 2008, 3953 . 3955 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 3956 Housley, R., and W. Polk, "Internet X.509 Public Key 3957 Infrastructure Certificate and Certificate Revocation List 3958 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 3959 . 3961 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 3962 DOI 10.17487/RFC5322, October 2008, 3963 . 3965 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 3966 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 3967 January 2012, . 3969 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 3970 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 3971 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 3972 Low-Power and Lossy Networks", RFC 6550, 3973 DOI 10.17487/RFC6550, March 2012, 3974 . 3976 [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing 3977 Protocol for Low-Power and Lossy Networks (RPL)", 3978 RFC 6552, DOI 10.17487/RFC6552, March 2012, 3979 . 3981 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 3982 "Enrollment over Secure Transport", RFC 7030, 3983 DOI 10.17487/RFC7030, October 2013, 3984 . 3986 [RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support 3987 for Generic Routing Encapsulation (GRE)", RFC 7676, 3988 DOI 10.17487/RFC7676, October 2015, 3989 . 3991 16.2. Informative References 3993 [AR8021] IEEE SA-Standards Board, "IEEE Standard for Local and 3994 metropolitan area networks - Secure Device Identity", 3995 December 2009, . 3998 [I-D.ietf-anima-bootstrapping-keyinfra] 3999 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 4000 S., and K. Watsen, "Bootstrapping Remote Secure Key 4001 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 4002 keyinfra-07 (work in progress), July 2017. 4004 [I-D.ietf-anima-reference-model] 4005 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 4006 Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A 4007 Reference Model for Autonomic Networking", draft-ietf- 4008 anima-reference-model-04 (work in progress), July 2017. 4010 [I-D.ietf-anima-stable-connectivity] 4011 Eckert, T. and M. Behringer, "Using Autonomic Control 4012 Plane for Stable Connectivity of Network OAM", draft-ietf- 4013 anima-stable-connectivity-06 (work in progress), September 4014 2017. 4016 [I-D.ietf-netconf-zerotouch] 4017 Watsen, K., Abrahamsson, M., and I. Farrer, "Zero Touch 4018 Provisioning for NETCONF or RESTCONF based Management", 4019 draft-ietf-netconf-zerotouch-17 (work in progress), 4020 September 2017. 4022 [I-D.ietf-roll-useofrplinfo] 4023 Robles, I., Richardson, M., and P. Thubert, "When to use 4024 RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll- 4025 useofrplinfo-16 (work in progress), July 2017. 4027 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 4028 RFC 1112, DOI 10.17487/RFC1112, August 1989, 4029 . 4031 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 4032 and E. Lear, "Address Allocation for Private Internets", 4033 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 4034 . 4036 [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax 4037 Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998, 4038 . 4040 [RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", 4041 RFC 2821, DOI 10.17487/RFC2821, April 2001, 4042 . 4044 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 4045 "Considerations for Internet Group Management Protocol 4046 (IGMP) and Multicast Listener Discovery (MLD) Snooping 4047 Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, 4048 . 4050 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 4051 Group Management Protocol Version 3 (IGMPv3) and Multicast 4052 Listener Discovery Protocol Version 2 (MLDv2) for Source- 4053 Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, 4054 August 2006, . 4056 [RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol 4057 Independent Multicast (PIM)", RFC 4610, 4058 DOI 10.17487/RFC4610, August 2006, 4059 . 4061 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 4062 Extensions for Stateless Address Autoconfiguration in 4063 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 4064 . 4066 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 4067 Specifications: ABNF", STD 68, RFC 5234, 4068 DOI 10.17487/RFC5234, January 2008, 4069 . 4071 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 4072 DOI 10.17487/RFC5321, October 2008, 4073 . 4075 [RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet 4076 Group Management Protocol Version 3 (IGMPv3) and Multicast 4077 Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, 4078 DOI 10.17487/RFC5790, February 2010, 4079 . 4081 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 4082 and A. Bierman, Ed., "Network Configuration Protocol 4083 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 4084 . 4086 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 4087 Power and Lossy Networks (RPL) Option for Carrying RPL 4088 Information in Data-Plane Datagrams", RFC 6553, 4089 DOI 10.17487/RFC6553, March 2012, 4090 . 4092 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 4093 "Default Address Selection for Internet Protocol Version 6 4094 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 4095 . 4097 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 4098 DOI 10.17487/RFC6762, February 2013, 4099 . 4101 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 4102 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 4103 . 4105 [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local 4106 Addressing inside an IPv6 Network", RFC 7404, 4107 DOI 10.17487/RFC7404, November 2014, 4108 . 4110 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 4111 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 4112 Networking: Definitions and Design Goals", RFC 7575, 4113 DOI 10.17487/RFC7575, June 2015, 4114 . 4116 [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap 4117 Analysis for Autonomic Networking", RFC 7576, 4118 DOI 10.17487/RFC7576, June 2015, 4119 . 4121 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 4122 Considerations for IPv6 Address Generation Mechanisms", 4123 RFC 7721, DOI 10.17487/RFC7721, March 2016, 4124 . 4126 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 4127 Writing an IANA Considerations Section in RFCs", BCP 26, 4128 RFC 8126, DOI 10.17487/RFC8126, June 2017, 4129 . 4131 Authors' Addresses 4133 Michael H. Behringer (editor) 4135 Email: michael.h.behringer@gmail.com 4137 Toerless Eckert (editor) 4138 Futurewei Technologies Inc. 4139 2330 Central Expy 4140 Santa Clara 95050 4141 USA 4143 Email: tte+ietf@cs.fau.de 4145 Steinthor Bjarnason 4146 Arbor Networks 4147 2727 South State Street, Suite 200 4148 Ann Arbor MI 48104 4149 United States 4151 Email: sbjarnason@arbor.net