idnits 2.17.1 draft-ietf-anima-autonomic-control-plane-10.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 document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 444: '... ACP1: The ACP SHOULD provide robust...' RFC 2119 keyword, line 449: '... ACP2: The ACP MUST have a separate ...' RFC 2119 keyword, line 453: '... ACP3: The ACP MUST use autonomicall...' RFC 2119 keyword, line 458: '... ACP4: The ACP MUST be generic. Usa...' RFC 2119 keyword, line 459: '...rastructure. It MUST NOT be tied to a...' (76 more instances...) -- The draft header indicates that this document updates RFC4291, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4193, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 674 has weird spacing: '... called anim...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The Certificate Authority in an ACP network MUST not change this, and create the respective subjectAltName / rfc822Name in the certificate. The ACP nodes can therefore find their ACP address and domain using this field in the domain certificate, both for themselves, as well as for other nodes. (Using the creation date from RFC4193, updated by this document, for RFC5378 checks: 2003-08-27) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 15, 2017) is 2386 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 2168, but not defined == Missing Reference: 'Select' is mentioned on line 2328, but not defined == Missing Reference: 'Plane' is mentioned on line 2330, but not defined ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-07 == Outdated reference: A later version (-10) exists of draft-ietf-anima-reference-model-04 == Outdated reference: A later version (-10) exists of draft-ietf-anima-stable-connectivity-05 == 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: 3 errors (**), 0 flaws (~~), 12 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: March 19, 2018 S. Bjarnason 7 Arbor Networks 8 September 15, 2017 10 An Autonomic Control Plane (ACP) 11 draft-ietf-anima-autonomic-control-plane-10 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 March 19, 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 . . . . . . . . 8 61 3.2. Secure Bootstrap over an Unconfigured Network . . . . . . 8 62 3.3. Data Plane Independent Permanent Reachability . . . . . . 9 63 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 10 64 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 12 66 6.1. Domain Certificate . . . . . . . . . . . . . . . . . . . 12 67 6.1.1. ACP information . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . 20 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 . . . . . . . . . . . . . . . . . . . . 24 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 26 81 6.9. Context Separation . . . . . . . . . . . . . . . . . . . 28 82 6.10. Addressing inside the ACP . . . . . . . . . . . . . . . . 28 83 6.10.1. Fundamental Concepts of Autonomic Addressing . . . . 28 84 6.10.2. The ACP Addressing Base Scheme . . . . . . . . . . . 29 85 6.10.3. ACP Zone Addressing Sub-Scheme . . . . . . . . . . . 30 86 6.10.4. ACP Manual Addressing Sub-Scheme . . . . . . . . . . 32 87 6.10.5. ACP Vlong Addressing Sub-Scheme . . . . . . . . . . 33 88 6.10.6. Other ACP Addressing Sub-Schemes . . . . . . . . . . 34 89 6.11. Routing in the ACP . . . . . . . . . . . . . . . . . . . 35 90 6.11.1. RPL Profile . . . . . . . . . . . . . . . . . . . . 35 91 6.12. General ACP Considerations . . . . . . . . . . . . . . . 39 92 6.12.1. Performance . . . . . . . . . . . . . . . . . . . . 39 93 6.12.2. Addressing of Secure Channels in the data plane . . 39 94 6.12.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . 40 95 6.12.4. Multiple links between nodes . . . . . . . . . . . . 40 96 6.12.5. ACP interfaces . . . . . . . . . . . . . . . . . . . 40 98 7. ACP support on L2 switches/ports (Normative) . . . . . . . . 43 99 7.1. Why . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 100 7.2. How (per L2 port DULL GRASP) . . . . . . . . . . . . . . 44 101 8. Support for Non-Autonomic Components (Normative) . . . . . . 46 102 8.1. ACP Connect . . . . . . . . . . . . . . . . . . . . . . . 46 103 8.1.1. Non-Autonomic Controller / NMS system . . . . . . . . 46 104 8.1.2. Software Components . . . . . . . . . . . . . . . . . 48 105 8.1.3. Auto Configuration . . . . . . . . . . . . . . . . . 49 106 8.1.4. Combined ACP and Data Data Plane Interface (VRF 107 Select) . . . . . . . . . . . . . . . . . . . . . . . 50 108 8.1.5. Use of GRASP . . . . . . . . . . . . . . . . . . . . 52 109 8.2. ACP through Non-Autonomic L3 Clouds (Remote ACP 110 neighbors) . . . . . . . . . . . . . . . . . . . . . . . 52 111 8.2.1. Configured Remote ACP neighbor . . . . . . . . . . . 52 112 8.2.2. Tunneled Remote ACP Neighbor . . . . . . . . . . . . 54 113 8.2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 54 114 9. Benefits (Informative) . . . . . . . . . . . . . . . . . . . 54 115 9.1. Self-Healing Properties . . . . . . . . . . . . . . . . . 54 116 9.2. Self-Protection Properties . . . . . . . . . . . . . . . 56 117 9.2.1. From the outside . . . . . . . . . . . . . . . . . . 56 118 9.2.2. From the inside . . . . . . . . . . . . . . . . . . . 56 119 9.3. The Administrator View . . . . . . . . . . . . . . . . . 57 120 10. Further Considerations (Informative) . . . . . . . . . . . . 57 121 10.1. Domain Certificate provisioning / enrollment . . . . . . 58 122 10.2. ACP Neighbor discovery protocol selection . . . . . . . 59 123 10.2.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 59 124 10.2.2. mDNS and L2 support . . . . . . . . . . . . . . . . 59 125 10.2.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 60 126 10.3. Choice of routing protocol (RPL) . . . . . . . . . . . . 60 127 10.4. Extending ACP channel negotiation (via GRASP) . . . . . 61 128 10.5. CAs, domains and routing subdomains . . . . . . . . . . 63 129 11. RFC4291/RFC4193 Updates Considerations . . . . . . . . . . . 65 130 12. Security Considerations . . . . . . . . . . . . . . . . . . . 67 131 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 68 132 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 68 133 15. Change log [RFC Editor: Please remove] . . . . . . . . . . . 68 134 15.1. Initial version . . . . . . . . . . . . . . . . . . . . 68 135 15.2. draft-behringer-anima-autonomic-control-plane-00 . . . . 68 136 15.3. draft-behringer-anima-autonomic-control-plane-01 . . . . 68 137 15.4. draft-behringer-anima-autonomic-control-plane-02 . . . . 69 138 15.5. draft-behringer-anima-autonomic-control-plane-03 . . . . 69 139 15.6. draft-ietf-anima-autonomic-control-plane-00 . . . . . . 69 140 15.7. draft-ietf-anima-autonomic-control-plane-01 . . . . . . 69 141 15.8. draft-ietf-anima-autonomic-control-plane-02 . . . . . . 70 142 15.9. draft-ietf-anima-autonomic-control-plane-03 . . . . . . 70 143 15.10. draft-ietf-anima-autonomic-control-plane-04 . . . . . . 71 144 15.11. draft-ietf-anima-autonomic-control-plane-05 . . . . . . 71 145 15.12. draft-ietf-anima-autonomic-control-plane-06 . . . . . . 72 146 15.13. draft-ietf-anima-autonomic-control-plane-07 . . . . . . 72 147 15.14. draft-ietf-anima-autonomic-control-plane-08 . . . . . . 74 148 15.15. draft-ietf-anima-autonomic-control-plane-09 . . . . . . 75 149 15.16. draft-ietf-anima-autonomic-control-plane-10 . . . . . . 77 150 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 78 151 16.1. Normative References . . . . . . . . . . . . . . . . . . 78 152 16.2. Informative References . . . . . . . . . . . . . . . . . 80 153 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 82 155 1. Introduction 157 Autonomic Networking is a concept of self-management: Autonomic 158 functions self-configure, and negotiate parameters and settings 159 across the network.[RFC7575] defines the fundamental ideas and design 160 goals of Autonomic Networking. A gap analysis of Autonomic 161 Networking is given in [RFC7576]. The reference architecture for 162 Autonomic Networking in the IETF is currently being defined in the 163 document [I-D.ietf-anima-reference-model] 165 Autonomic functions need a stable and robust infrastructure to 166 communicate on. This infrastructure should be as robust as possible, 167 and it should be re-usable by all autonomic functions.[RFC7575] calls 168 it the "Autonomic Control Plane". This document defines the 169 Autonomic Control Plane. 171 Today, the management and control plane of networks typically runs in 172 the global routing table, which is dependent on correct configuration 173 and routing. Misconfigurations or routing problems can therefore 174 disrupt management and control channels. Traditionally, an out of 175 band network has been used to recover from such problems, or 176 personnel is sent on site to access devices through console ports 177 (craft ports). However, both options are operationally expensive. 179 In increasingly automated networks either controllers or distributed 180 autonomic service agents in the network require a control plane which 181 is independent of the network they manage, to avoid impacting their 182 own operations. 184 This document describes options for a self-forming, self-managing and 185 self-protecting "Autonomic Control Plane" (ACP) which is inband on 186 the network, yet as independent as possible of configuration, 187 addressing and routing problems (for details how this achieved, see 188 Section 6). It therefore remains operational even in the presence of 189 configuration errors, addressing or routing issues, or where policy 190 could inadvertently affect control plane connectivity. The Autonomic 191 Control Plane serves several purposes at the same time: 193 o Autonomic functions communicate over the ACP. The ACP therefore 194 supports directly Autonomic Networking functions, as described in 195 [I-D.ietf-anima-reference-model]. For example, GRASP 196 [I-D.ietf-anima-grasp] runs securely inside the ACP and depends on 197 the ACP as its "security and transport substrate". 199 o An operator can use it to log into remote devices, even if the 200 data plane is misconfigured or unconfigured. 202 o A controller or network management system can use it to securely 203 bootstrap network devices in remote locations, even if the network 204 in between is not yet configured; no data-plane dependent 205 bootstrap configuration is required. An example of such a secure 206 bootstrap process is described in 207 [I-D.ietf-anima-bootstrapping-keyinfra] 209 This document describes some use cases for the ACP in Section 3, it 210 defines the requirements in Section 4, Section 5 gives an overview 211 how an Autonomic Control Plane is constructed, and in Section 6 the 212 detailed process is explained.Section 8 explains how non-autonomic 213 nodes and networks can be integrated, and Section 6.7 the first 214 channel types for the ACP. 216 The document "Autonomic Network Stable Connectivity" 217 [I-D.ietf-anima-stable-connectivity] describes how the ACP can be 218 used to provide stable connectivity for OAM applications. It also 219 explains on how existing management solutions can leverage the ACP in 220 parallel with traditional management models, when to use the ACP 221 versus the data plane, how to integrate IPv4 based management, etc. 223 2. Terminology 225 This document uses the following terms (sorted alphabetically): 227 ACP "Autonomic Control Plane". The Autonomic Function defined in 228 this document. It provides secure zero-touch network wide IPv6 229 connectivity between devices supporting it. The ACP is primarily 230 meant to be used as a component of the ANI to enable Autonomic 231 Networks but it can equally be used in simple ANI networks (with 232 no other Autonomic Functions) or completely by itself. 234 ACP address An IPv6 ULA address assigned to the ACP device. It is 235 stored in the ACP information field of an ACP devices certificate 236 (LDevID). 238 (Device) ACP address range/set The ACP address may imply a range or 239 set of addresses that the device can assign for different 240 purposes. This address range/set is derived by the device from 241 the format of the ACP address called the "addressing sub-scheme". 243 ACP connect A physical interface on an ACP device providing access 244 to the ACP for non ACP capable devices. See Section 8.1.1. 246 ACP device A device supporting the ACP according to this document. 248 ACP information (field) An rfc822Name information element (eg: 249 field) in the Domain Certificate in which the ACP relevant 250 information is encoded: the AN Domain Name and the ACP address. 252 ACP (loopback) interface The loopback interface in the ACP VRF that 253 hosts the ACP address. 255 ACP (ULA) prefix(es) The prefixes routed across the ACP. In the 256 normal/simple case, the ACP has one ULA prefix, see Section 6.10. 257 The ACP routing table may include multiple ULA prefixes if the 258 "rsub" option is used to create addresses from more than one ULA 259 prefix. See Section 6.1.1. The ACP may also include non-ULA 260 prefixes if those are configured on ACP connect interfaces. See 261 Section 8.1.1. 263 ACP secure channel A virtual subinterface/tunnel established hop-by- 264 hop between adjacent ACP devices to carry traffic of the ACP VRF 265 separated from Data Plane traffic inband over the same links as 266 the Data Plane. 268 ACP secure channel protocol The protocol used to build an ACP secure 269 channel, eg: IKEv2/IPsec or dTLS. 271 ACP virtual interface An interface in the ACP VRF mapped to one or 272 more ACP secure channels. See Section 6.12.5. 274 ACP VRF The ACP is modelled in this document as a "Virtual Routing 275 and Forwarding" (VRF) component in a network device. 277 AN "Autonomic Network". A network according to 278 [I-D.ietf-anima-reference-model]. Its main components are Intent, 279 Autonomic Functions and ANI. 281 AN Domain Name An FQDN (Fully Qualified Domain Name) identifying an 282 Autonomic Network. It is stored in the ACP information field of 283 an ANI devices LDevID. See Section 6.1.1. 285 ANI (device/network) "Autonomic Network Infrastructure". A device 286 with ANI supports ACP, BRSKI and GRASP. The ANI is the 287 infrastructure to enable autonomic functions. An ANI network or 288 device is a most basic Autonomic Network or device: it does not 289 need to have ASAs other than the ones implementing ACP, BRSKI and 290 GRASP nor Intent support. A simple ANI network (without further 291 autonomic functions) can for example support secure zero touch 292 bootstrap and stble connectivity for SDN networks - see 293 [I-D.ietf-anima-stable-connectivity]. 295 ANIMA "Autonomic Networking Integrated Model and Approach". ACP, 296 BRSKI and GRASP are work products of ANIMA. 298 ASA "Autonomic Service Agent". Autonomic software modules running 299 on an ANI device. The components making up the ANI (BRSKI, ACP, 300 GRASP) are also described as ASAs. 302 Autonomic Function A function/service in an Autonomic Network (AN) 303 composed of one or more ASA across one or more ANI Devices. 305 BRSKI "Bootstrapping Remote Secure Key Infrastructures" 306 ([I-D.ietf-anima-bootstrapping-keyinfra]. A protocol extending 307 EST to enable secure zero touch bootstrap in conjunction with ACP. 308 ANI devices use ACP and BRSKI. 310 Data Plane The counterpoint to the ACP in an ACP device: all VRFs 311 other than the ACP. In a simple ACP or ANI device, the Data Plane 312 is typically provisioned non-autonomic, for example manually 313 (including across the ACP) or via SDN controllers. In a full 314 Autonomic Network Device, the Data Plane is managed autonomically 315 via Autonomic Functions and Intent. 317 Domain Certificate An LDevID with an information element defined in 318 this document used by the ACP to derive and cryptographically 319 assert its membership in an autonomic domain. 321 enrollment The process where a device presents identification (for 322 example through keying material such as the private key of an 323 IDevID) to a network and acquires a network specific identity and 324 trust anchor such as an LDevID. 326 EST "Enrollment over Secure Transport" ([RFC7030]). IETF standard 327 protocol for enrollment of a device with an LDevID. BRSKI is 328 based on EST. 330 GRASP "Generic Autonomic Signaling Protocol". An extensible 331 signaling protocol required by the ACP for ACP neighbor discovery. 332 The ACP also provides the "security and transport substrate" for 333 the "ACP instance of GRASP" which is run inside the ACP to support 334 BRSKI and other future Autonomic Functions. See 335 [I-D.ietf-anima-grasp]. 337 IDevID An "Initial Device IDentity" X.509 certificate installed by 338 the vendor on new equipment. Contains information that 339 establishes the identity of the device in the context of its 340 vendor/manufacturer such as device model/type and serial number. 341 See [AR8021]. 343 LDevID A "Local Device IDentity" X.509 certificate installed during 344 an "enrollment". The ACP depends on a Domain Certificate which is 345 an LDevID. See [AR8021]. 347 MIC "Manufacturer Installed Certificate". Another word not used in 348 this document to describe an IDevID. 350 RPL "IPv6 Routing Protocol for Low-Power and Lossy Networks". The 351 routing protocol used in the ACP. 353 MASA (service) "Manufacturer Authorized Signing Authority". A 354 vendor/manufacturer or delegated cloud service on the Internet 355 used as part of the BRSKI protocol. 357 sUDI "secured Unique Device Identifier". Another term not used in 358 this document to refer to an IDevID. 360 UDI "Unique Device Identifier". In the context of this document 361 unsecured identity information of a device typically consisting of 362 at least device model/type and serial number, often in a vendor 363 specific format. See sUDI and LDevID. 365 ULA A "Unique Local Address" (ULA) is an IPv6 address in the block 366 fc00::/7, defined in [RFC4193]. It is the approximate IPv6 367 counterpart of the IPv4 private address ([RFC1918]). 369 3. Use Cases for an Autonomic Control Plane 371 3.1. An Infrastructure for Autonomic Functions 373 Autonomic Functions need a stable infrastructure to run on, and all 374 autonomic functions should use the same infrastructure to minimise 375 the complexity of the network. This way, there is only need for a 376 single discovery mechanism, a single security mechanism, and other 377 processes that distributed functions require. 379 3.2. Secure Bootstrap over an Unconfigured Network 381 Today, bootstrapping a new device typically requires all devices 382 between a controlling node (such as an SDN controller) and the new 383 device to be completely and correctly addressed, configured and 384 secured. Therefore, bootstrapping a network happens in layers around 385 the controller. Without console access (for example through an out 386 of band network) it is not possible today to make devices securely 387 reachable before having configured the entire network leading up to 388 them. 390 With the ACP, secure bootstrap of new devices can happen without 391 requiring any configuration on the network. A new device can 392 automatically be bootstrapped in a secure fashion and be deployed 393 with a domain certificate. This does not require any configuration 394 on intermediate nodes, because they can communicate securely through 395 the ACP. 397 3.3. Data Plane Independent Permanent Reachability 399 Today, most critical control plane protocols and network management 400 protocols are running in the data plane (global routing table) of the 401 network. This leads to undesirable dependencies between control and 402 management plane on one side and the data plane on the other: Only if 403 the data plane is operational, will the other planes work as 404 expected. 406 Data plane connectivity can be affected by errors and faults, for 407 example certain AAA misconfigurations can lock an administrator out 408 of a device; routing or addressing issues can make a device 409 unreachable; shutting down interfaces over which a current management 410 session is running can lock an admin irreversibly out of the device. 411 Traditionally only console access can help recover from such issues. 413 Data plane dependencies also affect NOC/SDN controller applications: 414 Certain network changes are today hard to operate, because the change 415 itself may affect reachability of the devices. Examples are address 416 or mask changes, routing changes, or security policies. Today such 417 changes require precise hop-by-hop planning. 419 The ACP provides reachability that is largely independent of the data 420 plane, which allows control plane and management plane to operate 421 more robustly: 423 o For management plane protocols, the ACP provides the functionality 424 of a "Virtual-out-of-band (VooB) channel", by providing 425 connectivity to all devices regardless of their configuration or 426 global routing table. 428 o For control plane protocols, the ACP allows their operation even 429 when the data plane is temporarily faulty, or during transitional 430 events, such as routing changes, which may affect the control 431 plane at least temporarily. This is specifically important for 432 autonomic service agents, which could affect data plane 433 connectivity. 435 The document "Autonomic Network Stable Connectivity" 436 [I-D.ietf-anima-stable-connectivity] explains the use cases for the 437 ACP in significantly more detail and explains how the ACP can be used 438 in practical network operations. 440 4. Requirements 442 The Autonomic Control Plane has the following requirements: 444 ACP1: The ACP SHOULD provide robust connectivity: As far as 445 possible, it should be independent of configured addressing, 446 configuration and routing. Requirements 2 and 3 build on this 447 requirement, but also have value on their own. 449 ACP2: The ACP MUST have a separate address space from the data 450 plane. Reason: traceability, debug-ability, separation from 451 data plane, security (can block easily at edge). 453 ACP3: The ACP MUST use autonomically managed address space. Reason: 454 easy bootstrap and setup ("autonomic"); robustness (admin 455 can't mess things up so easily). This document suggests to 456 use ULA addressing for this purpose. 458 ACP4: The ACP MUST be generic. Usable by all the functions and 459 protocols of the AN infrastructure. It MUST NOT be tied to a 460 particular application or transport protocol. 462 ACP5: The ACP MUST provide security: Messages coming through the ACP 463 MUST be authenticated to be from a trusted node, and SHOULD 464 (very strong SHOULD) be encrypted. 466 The default mode of operation of the ACP is hop-by-hop, because this 467 interaction can be built on IPv6 link local addressing, which is 468 autonomic, and has no dependency on configuration (requirement 1). 469 It may be necessary to have ACP connectivity over non-autonomic 470 nodes, for example to link autonomic nodes over the general Internet. 471 This is possible, but then has a dependency on routing over the non- 472 autonomic hops (see Section 8.2). 474 5. Overview 476 The Autonomic Control Plane is constructed in the following way (for 477 details, see Section 6): 479 1. An autonomic node creates a virtual routing and forwarding (VRF) 480 instance, or a similar virtual context. 482 2. It determines, following a policy, a candidate peer list. This 483 is the list of nodes to which it should establish an Autonomic 484 Control Plane. Default policy is: To all link-layer adjacent 485 nodes in the same autonomic domain. 487 3. For each node in the candidate peer list, it authenticates that 488 node and negotiates a mutually acceptable channel type. 490 4. It then establishes a secure tunnel of the negotiated channel 491 type. These tunnels are placed into the previously set up VRF. 492 This creates an overlay network with hop-by-hop tunnels. 494 5. Inside the ACP VRF, each node sets up a virtual (loopback) 495 interface with its ULA IPv6 address. 497 6. Each node runs a lightweight routing protocol, to announce 498 reachability of the virtual addresses inside the ACP. 500 Note: 502 o Non-autonomic NMS systems or controllers have to be manually 503 connected into the ACP. 505 o Connecting over non-autonomic Layer-3 clouds initially requires a 506 tunnel between autonomic nodes. 508 o None of the above operations (except manual ones) is reflected in 509 the configuration of the device. 511 The following figure illustrates the ACP. 513 autonomic node 1 autonomic node 2 514 ................... ................... 515 secure . . secure . . secure 516 tunnel : +-----------+ : tunnel : +-----------+ : tunnel 517 ..--------| ACP VRF |---------------------| ACP VRF |---------.. 518 : / \ / \ <--routing--> / \ / \ : 519 : \ / \ / \ / \ / : 520 ..--------| virtual |---------------------| virtual |---------.. 521 : | interface | : : | interface | : 522 : +-----------+ : : +-----------+ : 523 : : : : 524 : data plane :...............: data plane : 525 : : link : : 526 :.................: :.................: 528 Figure 1 530 The resulting overlay network is normally based exclusively on hop- 531 by-hop tunnels. This is because addressing used on links is IPv6 532 link local addressing, which does not require any prior set-up. This 533 way the ACP can be built even if there is no configuration on the 534 devices, or if the data plane has issues such as addressing or 535 routing problems. 537 6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 539 This section describes the steps to set up an Autonomic Control Plane 540 (ACP), and highlights the key properties which make it 541 "indestructible" against many inadvert changes to the data plane, for 542 example caused by misconfigurations. 544 An ACP device can be a router, switch, controller, NMS host, or any 545 other IP device. Initially, it must have a globally unique domain 546 certificate (LDevID), as well as an adjacency table. It then can 547 start to discover ACP neighbors and build the ACP. This is described 548 step by step in the following sections: 550 6.1. Domain Certificate 552 To establish an ACP securely, an ACP device MUST have a globally 553 unique domain certificate (LDevID), with which it can 554 cryptographically assert its membership in the domain as well as the 555 CA certificate chain used to sign the LDevID. This CA certificate 556 chain is used to verify the LDevID of candidate ACP peers (see 557 Section 6.6). The ACP does not mandate specific mechanism by which 558 this certificate information is provisioned onto the ACP device, it 559 only requires the following ACP specific information field in its 560 LDevID as well as the LDevIDs of candidate ACP peers. See 561 Section 10.1 for more information about enrollment or provisioning 562 options. 564 6.1.1. ACP information 566 The domain certificate (LDevID) of an autonomic node MUST contain ACP 567 specific information, specifically the domain name, and the ACP 568 address of the device. This information MUST be encoded in the 569 LDevID in the subjectAltName / rfc822Name field according to the 570 following ABNF definition ([RFC5234]): 572 anima.acp+[+{+}}@ 574 acp-information = acp-device-info "@" acp-domain 576 acp-device-info = "ani.acp+" acp-address [ "+" rsub extensions ] 578 acp-address = 32hex-dig 580 hex-dig = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" 582 rsub = [ domain-name ] ; empty if not used 584 acp-domain = domain-name 586 routing-subdomain = [ rsub " ." ] acp-domain 588 domain-name = ; according to section 3.5 of [RFC1034] 590 extensions = *( "+" extension ) 592 extension = ; future definition. Must fit into [RFC5322] simple dot- 593 atom format. 595 Example: 597 acp-information = anima.acp+fda379A6f6ee00000200000064000000+area51 598 .research@acp.example.com 600 routing-subdomain = area51.research.acp.example.com 602 "acp-address" can not use standard IPv6 address formats because it 603 must match the simple dot-atom format of [RFC5322]. ":" are not 604 allowed in that format. 606 "acp-domain" is used to indicate the Autonomic Domain across which 607 all ACP nodes trust each other and are willing to build ACP channel 608 with each other. See Section 6.6. It SHOULD be the FQDN of a domain 609 owned by the operator assigning the certificate. This is a simple 610 method to ensure that the acp-domain is globally unique and collision 611 of ACP addresses would therefore only happen due to ULA hash 612 collisions. If the operator does not own any FQDN, it should choose 613 a string in FQDN format that intends to be equally unique. 615 "routing-subdomain" is the autonomic "routing subdomain" that is used 616 used in addressing to calculate the hash used in the creation of the 617 ACP address of the device. As the name implies, every routing 618 subdomain is also a separate routing subdomain. "rsub" is optional 619 and should only used when its impacts are understood. When "rsub" is 620 not used, "routing-subdomain" is "acp-domain". 622 The optional "extensions" field is used for future extensions to this 623 specification. It MUST be ignored if present and not understood. 625 Note that the maximum size of "acp-information" is 254 characters and 626 the maximum size of acp-device-info is 64 characters according to 627 [RFC5280] that is referring to [RFC2821] (superceeded by [RFC5321]). 629 The subjectAlName / rfc822Name encoding of the ACP domain name and 630 ACP address is used for the following reasons: 632 o There are a wide range of pre-existing protocols/services where 633 authentication with LDevID is desirable. Enrolling and 634 maintaining separate LDevIDs for each of these protocols/services 635 is often undesirable overhead. Therefore, the information element 636 required for the ACP in the domain certificate should be encoded 637 in a way that minimizes the possibility of creating 638 incompatibilites with such other uses beside the authentication 639 for the ACP. 641 o The elements in the LDevID required for the ACP should not cause 642 incompatibilities with any pre-existing ASN.1 software potentially 643 in use in those other pre-existing SW systems. This eliminates 644 the use of novel information elements because those require 645 extensions to those pre-existing ASN.1 parsers. 647 o subjectAltname / rfc822Name is a pre-existing element that must be 648 supported by all existing ASN.1 parsers for LDevID. 650 o The elements in the LDevID required for the ACP should also not be 651 misinterpreted by any pre-existing protocol/service that might use 652 the LDevID. If the elements used for the ACP are interpreted by 653 other protocols/services, then the impact should be benign. 655 o Using an IP address format encoding could result in non-benign 656 misinterpretation of the ACP information, for example other 657 protocol/services unaware of the ACP could try to do something 658 with the ACP address that would fail to work correctly. For 659 example, the address could be interpreted to be an address of the 660 device in a VRF other than the ACP VRF. 662 o At minimum, both the AN domain name and the non-domain name 663 derived part of the ACP address need to be encoded in one or more 664 appropriate fields of the certificate, so there are not many 665 alternatives with pre-existing fields where the only possible 666 conflicts would likely be beneficial. 668 o rfc822Name encoding is quite flexible. We choose to encode the 669 full ACP address AND the domain name with sub part into a single 670 rfc822Name information element it, so that it is easier to 671 examine/use the encoded "ACP information (field)". 673 o The format of the rfc822Name is choosen so that an operator can 674 set up a mailbox called anima.acp@ that would receive 675 emails sent towards the rfc822Name of any AN device inside a 676 domain. This is possible because in many modern mail systems, 677 components behind a plus symbol are considered part of a single 678 mailbox. In other words, it is not necessary to set up a separate 679 mailbox for every autonomic devices ACP information field, but 680 only one for the whole domain. 682 o In result, if any unexpected use of the ACP addressing information 683 in a certificate happens, it is benign and detectable: it would be 684 mail to that mailbox. 686 See section 4.2.1.6 of [RFC5280] for details on the subjectAltName 687 field. 689 6.1.2. Maintenance 691 The ACP network MUST have one or more nodes that support EST server 692 ([RFC7030] functionality (eg: as an ASA) through which ACP nodes can 693 renew their domain certificate. The ACP address of at least one such 694 EST server SHOULD have been enrolled/provisioned into the ACP device 695 during initial installation of the domain certificate. 697 EST servers MUST announce their service via GRASP in the ACP through 698 M_FLOOD messages: 700 Example: 702 [M_FLOOD, 12340815, h'fda379a6f6ee0000200000064000001', 180000, 703 ["AN_join_registrar", 4, 255, "EST-TLS"], 704 [O_IPv6_LOCATOR, 705 h'fda379a6f6ee0000200000064000001', TCP, 80] 706 ] 708 The formal CDDL definition is: 710 flood-message = [M_FLOOD, session-id, initiator, ttl, 711 +[objective, (locator-option / [])]] 713 objective = ["AN_join_registrar", objective-flags, loop-count, 714 objective-value] 716 objective-flags = sync-only ; as in GRASP spec 717 sync-only = 4 ; M_FLOOD only requires synchronization 718 loop-count = 255 ; mandatory maximum 719 objective-value = text ; name of the (list of) of supported 720 ; protocols: "EST-TLS" for RFC7030. 722 The M_FLOOD message MUST be sent periodically. The period is subject 723 to network administrator policy (EST server configuration). It must 724 be so low that the aggregate amount of periodic M_FLOODs from all EST 725 servers causes negligible traffic across the ACP. 727 In the above (recommended) example the period could be 60 seconds and 728 the indicated ttl of 180000 msec means that the objective would 729 continuously be cached by ACP devices even when two out of three 730 messages are dropped in transit (which is unlikely because GRASP hop- 731 by-hop forwarding is realiable). 733 The locator-option indicates the ACP transport address for the EST 734 server. The loop-count MUST be sete to 255. When an ACP node 735 receives the M_FLOOD, it will have been reduced by the number of hops 736 from the EST server. 738 When it is time for domain certificate reneal, the ACP device MUST 739 attempt to connect to the EST server(s) learned via GRASP starting 740 with the one that has the highest remaining loop-count (closest one). 741 If certificate renewal does not succeed, the device MUST attempt to 742 use the EST server(s) learned during initial provisioning/enrollment 743 of the certificate. After successful renewal of the domain 744 certificate, the ACP address from the certificate of the EST server 745 (as learned during the TLS handshake) is added to the top of the list 746 or provisioned/configured EST-server(s). 748 This logic of selecting an EST server for renewal is choosen to allow 749 for distributed EST servers to be used effectively but to also allow 750 fallback to the most reliably learned EST server - those that 751 performed already successful enrollment in before. A compromised 752 (non EST-server) ACP device for example can filter or fake GRASP 753 announcements, but it can not successfully renew a certificate and 754 can only prohibit traffic to a valid EST server when it is on the 755 path between the ACP device and the EST server. 757 The ACP device MUST support Certificate Revocation Lists via HTTPs 758 from one or more Certificate Distribution Points. These CDPs MUST be 759 indicated in the Domain Certificate when used. If the CDP URL uses 760 an IPv6 ULA, the ACP device will try to reach it via the ACP. In 761 that case the ACP address in the domain certificate of the CDP as 762 learned by the ACP device during the HTTPs TLS handshake MUST match 763 that ULA address in the HTTPs URL. 765 Renewal of certificates SHOULD start after less than 50% of the 766 domain certificate lifetime so that network operations has ample time 767 to investigate and resolve any problems that cause a device to not 768 renew its domain certificate in time - and to allow prolonged periods 769 of running parts of a network disconnected from any CA. 771 Certificate lifetime should be set to be as short as feasible. Given 772 how certificate renewal is fully automated via ACP and EST, the 773 primarily imiting factor for shorter certificate lifetimes (than the 774 typical one year) is load on the EST server(s) and CA. It is 775 therefore recommended that ACP domain certificates are managed via a 776 CA chain where the assigning CA has enough peformance to manage short 777 lived certificates. 779 See Section 10.1 for further optimizationss of certificate 780 optimizations when BRSKI can be used. 782 6.2. AN Adjacency Table 784 To know to which nodes to establish an ACP channel, every autonomic 785 node maintains an adjacency table. The adjacency table contains 786 information about adjacent autonomic nodes, at a minimum: node-ID, 787 Link-local IPv6 address (discovered by GRASP as explained below), 788 domain, certificate. An autonomic device MUST maintain this 789 adjacency table up to date. This table is used to determine to which 790 neighbor an ACP connection is established. 792 Where the next autonomic device is not directly adjacent, the 793 information in the adjacency table can be supplemented by 794 configuration. For example, the node-ID and IP address could be 795 configured. 797 The adjacency table MAY contain information about the validity and 798 trust of the adjacent autonomic node's certificate. However, 799 subsequent steps MUST always start with authenticating the peer. 801 The adjacency table contains information about adjacent autonomic 802 nodes in general, independently of their domain and trust status. 803 The next step determines to which of those autonomic nodes an ACP 804 connection should be established. 806 Interaction between ACP and other autonomic elements like GRASP (see 807 below) or ASAs should be via an API that allows (appropriately access 808 controlled) read/write access to the AN Adjacency Table. 809 Specification of such an API is subject to future work. 811 6.3. Neighbor Discovery with DULL GRASP 813 Because of the the considerations in Section 10.2, the ACP uses DULL 814 (Discovery Unsolicited Link-Local) insecure instances of GRASP for 815 discovery of ACP neighbors. See section 3.5.2.2 of 816 [I-D.ietf-anima-grasp] for its formal definition. 818 The ACP uses one instance of DULL GRASP for every physical L2 subnet 819 of the ACP device to discovery physically adjacent candidate ACP 820 neighbors. Ideally, all physical interfaces SHOULD be brought up 821 enough so that ACP discovery can be performed and any physically 822 connected interfaces with ACP neighbors can then be brought into the 823 ACP even if the interface is otherwise not configured. Reception of 824 packets on such otherwise unconfigure interfaces MUST be limited so 825 that at first only IPv6 link-local address assignment (SLAAC) and 826 DULL GRASP works and then only the following ACP secure channel setup 827 packets - but not any other unnecessary traffic (eg: no other link- 828 local IPv6 transport stack responders for example). 830 ACP discovery MUST NOT be enabled by default on any non-physical 831 interfaces. In particular, ACP discovery MUST NOT run inside the 832 ACP. See Section 8.2.2 how to enable and use ACP with auto-discovery 833 across configured tunnels. 835 See Section 7 for how ACP should be extended on L3/L2 devices. 837 Note: If an ACP device also implements BRSKI (see Section 10.1) then 838 the above considerations also apply to discovery for BRSKI. Each 839 DULL instance of GRASP set up for ACP is then also used for the 840 discovery of a bootstrap proxy via BRSKI when the device does not 841 have a domain certificate. Discovery of ACP neighbors happens only 842 when the device does have the certificate. The device therefore 843 never needs to discover both a bootstrap proxy and ACP neighbor at 844 the same time. 846 An autonomic node announces itself to potential ACP peers by use of 847 the "AN_ACP" objective. This is a synchronization objective intended 848 to be flooded on a single link using the GRASP Flood Synchronization 849 (M_FLOOD) message. In accordance with the design of the Flood 850 message, a locator consisting of a specific link-local IP address, IP 851 protocol number and port number will be distributed with the flooded 852 objective. An example of the message is informally: 854 Example: 856 [M_FLOOD, 12340815, h'fe80000000000000c0011001FEEF0000, 180000, 857 ["AN_ACP", 4, 1, "IKEv2"], 858 [O_IPv6_LOCATOR, 859 h'fe80000000000000c0011001FEEF0000, UDP, 15000] 860 ] 862 The formal CDDL definition is: 864 flood-message = [M_FLOOD, session-id, initiator, ttl, 865 +[objective, (locator-option / [])]] 867 objective = ["AN_ACP", objective-flags, loop-count, 868 objective-value] 870 objective-flags = sync-only ; as in the GRASP specification 871 sync-only = 4 ; M_FLOOD only requires synchronization 872 loop-count = 1 ; limit to link-local operation 873 objective-value = text ; name of the (list of) secure 874 ; channel negotiation protocol(s) 876 The objective-flags field is set to indicate synchronization. 878 The loop-count is fixed at 1 since this is a link-local operation. 880 In the above (recommended) example the period of sending of the 881 objective could be 60 seconds the indicated ttl of 180000 msec means 882 that the objective would be cached by ACP devices even when two out 883 of three messages are dropped in transit. 885 The session-id is a random number used for loop prevention 886 (distinguishing a message from a prior instance of the same message). 887 In DULL this field is irrelevant but must still be set according to 888 the GRASP specification. 890 The originator MUST be the IPv6 link local address of the originating 891 autonomic node on the sending interface. 893 The 'objective-value' parameter is (normally) a string indicating the 894 secure channel protocol available at the specified or implied 895 locator. 897 The locator is optional and only required when the secure channel 898 protocol is not offered at a well-defined port number, or if there is 899 no well defined port number. For example, "IKEv2" has a well defined 900 port number 500, but in the above example, the candidate ACP neighbor 901 is offering ACP secure channel negotiation via IKEv2 on port 15000 902 (for the sake of creating a non-standard example). 904 If a locator is included, it MUST be an O_IPv6_LOCATOR, and the IPv6 905 address MUST be the same as the initiator address (these are DULL 906 requirements to minimize third party DoS attacks). 908 The secure channel methods defined in this document use the objective 909 values of "IKEv2" and "dTLS". There is no distinction between IKEv2 910 native and GRE-IKEv2 because this is purely negotiated via IKEv2. 912 A node that supports more than one secure channel protocol needs to 913 flood multiple versions of the "AN_ACP" objective, each accompanied 914 by its own locator. This can be in a single GRASP M_FLOOD message. 916 If multiple secure channel protocols are supported that all are run 917 on well-defined ports, then they can be announced via a single AN_ACP 918 objective using a list of string names as the objective value without 919 a following locator-option. 921 Note that a node serving both as an ACP node and BRSKI Join Proxy may 922 choose to distribute the "AN_ACP" objective and "AN_join_proxy" 923 objective in the same flood message, since GRASP allows multiple 924 objectives in one Flood message. This may be impractical though if 925 ACP and BRSKI operations are implemented via separate software 926 modules / ASAs though. 928 The result of the discovery is the IPv6 link-local address of the 929 neighbor as well as its supported secure channel protocols (and non- 930 standard port they are running on). It is stored in the AN Adjacency 931 Table, see Section 6.2 which then drives the further building of the 932 ACP to that neighbor. 934 6.4. Candidate ACP Neighbor Selection 936 An autonomic node must determine to which other autonomic nodes in 937 the adjacency table it should build an ACP connection. This is based 938 on the information in the AN Adjacency table. 940 The ACP is by default established exclusively between nodes in the 941 same domain. This includes all routing subdomains.Section 10.5 942 explains how ACP connections across routing subdomains are special. 944 Future extensions to this document including Intent can change this 945 default behaviour. Examples include: 947 o Build the ACP across all domains that have a common parent domain. 948 For example ACP nodes with domain "example.com", nodes of 949 "example.com", "access.example.com", "core.example.com" and 950 "city.core.example.com" could all establish one single ACP. 952 o ACP connections across domains with different CA (certificate 953 authorities) could establish a common ACP by installing the 954 alternate domains' CA into the trusted anchor store. This is an 955 executive management action that could easily be accomplished 956 through the control channel created by the ACP. 958 Since Intent is transported over the ACP, the first ACP connection a 959 node establishes is always following the default behaviour. See 960 Section 10.5 for more details. 962 The result of the candidate ACP neighbor selection process is a list 963 of adjacent or configured autonomic neighbors to which an ACP channel 964 should be established. The next step begins that channel 965 establishment. 967 6.5. Channel Selection 969 To avoid attacks, initial discovery of candidate ACP peers can not 970 include any non-protected negotiation. To avoid re-inventing and 971 validating security association mechanisms, the next step after 972 discoving the address of a candidate neighbor can only be to try 973 first to establish a security association with that neighbor using a 974 well-known security association method. 976 At this time in the lifecycle of autonomic devices, it is unclear 977 whether it is feasible to even decide on a single MTI (mandatory to 978 implement) security association protocol across all autonomic 979 devices: 981 From the use-cases it seems clear that not all type of autonomic 982 devices can or need to connect directly to each other or are able to 983 support or prefer all possible mechanisms. For example, code space 984 limited IoT devices may only support dTLS (because that code exists 985 already on them for end-to-end security use-cases), but low-end in- 986 ceiling L2 switches may only want to support MacSec because that is 987 also supported in HW, and only a more flexible gateway device may 988 need to support both of these mechanisms and potentially more. 990 To support extensible secure channel protocol selection without a 991 single common MTI protocol, autonomic devices must try all the ACP 992 secure channel protocols it supports and that are feasible because 993 the candidate ACP neighbor also announced them via its AN_ACP GRASP 994 parameters (these are called the "feasible" ACP secure channel 995 protocols). 997 To ensure that the selection of the secure channel protocols always 998 succeeds in a predictable fashion without blocking, the following 999 rules apply: 1001 An autonomic device may choose to attempt initiate the different 1002 feasible ACP secure channel protocol it supports according to its 1003 local policies sequentially or in parallel, but it MUST support 1004 acting as a responder to all of them in parallel. 1006 Once the first secure channel protocol succeeds, the two peers know 1007 each others certificates (because that must be used by all secure 1008 channel protocols for mutual authentication. The device with the 1009 lower Device-ID in the ACP address becomes Bob, the one with the 1010 higher Device-ID in the certificate Alice. 1012 Bob becomes passive, he does not attempt to further initiate ACP 1013 secure channel protocols with Alice and does not consider it to be an 1014 error when Alice closes secure channels. Alice becomes the active 1015 party, continues to attempt setting up secure channel protocols with 1016 Bob until she arrives at the best one (from her view) that also works 1017 with Bob. 1019 For example, originally Bob could have been the initiator of one ACP 1020 secure channel protocol that Bob preferred and the security 1021 association succeeded. The roles of Bob abd Alice are then assigned. 1022 At this stage, the protocol may not even have completed negotiating a 1023 common security profile. The protocol could for example have been 1024 IPsec. It is not up to Alice to devide how to proceed. Even if the 1025 IPsec connecting determined a working profile with Bob, Alice might 1026 prefer some other secure protocol (eg: dTLS) and try to set that up 1027 with Bob. If that succeeds, she would close the IPsec connection. If 1028 no better protocol attempt succeeds, she would keep the IPsec 1029 connection. 1031 All this negotiation is in the context of an "L2 interface". Alice 1032 and Bob will build ACP connections to each other on every "L2 1033 interface" that they both connect to. An autonomic device must not 1034 assume that neighbors with the same L2 or link-local IPv6 addresses 1035 on different L2 interfaces are the ame devices. This can only be 1036 determined after examining the certificate after a successful 1037 security association attempt. 1039 6.6. Candidate ACP Neighbor certificate verification 1041 Independent of the security association protocol choosen, candidate 1042 ACP neighbors need to be authenticated based on their autonomic 1043 domain certificate. This implies that any security association 1044 protocol MUST support certificate based authentication that can 1045 support the following verification steps: 1047 o The certificate is valid as proven by the security associations 1048 protocol exchanges. 1050 o The peers certificate is signed by the same CA as the devices 1051 domain certificate. 1053 o If the device certificates indicate a CDP or OCSP then the peer's 1054 certificate must be valid occording to those criteria. eg: OCSP 1055 check across the ACP or not listed in the CRL. 1057 o The peers certificate has a valid ACP information field 1058 (subjectAltName / rfc822Name) and the domain name in that peers 1059 ACP information field is the same as in the devices certificate. 1060 Note that future Intent rules may modify this for example in 1061 support of subdomains. See Section 10.5. 1063 If the peers certificate fails any of these checks, the connection 1064 attempt is aborted and an error logged (with throttling). 1066 6.7. Security Association protocols 1068 The following sections define the security association protocols that 1069 we consider to be important and feasible to specify in this document: 1071 6.7.1. ACP via IKEv2 1073 An autonomic device announces its ability to support IKEv2 as the ACP 1074 secure channel protcol in GRASP as "IKEv2". 1076 6.7.1.1. Native IPsec 1078 To run ACP via IPsec natively, no further IANA assignments/ 1079 definitions are required. An ACP devices supporting native IPsec 1080 MUST use IPsec security setup via IKEv2, tunnel mode, local and peer 1081 link-local IPv6 addresses used for encapsuation, ESP with AES256 for 1082 encryption and SHA256 hash. 1084 In terms of IKEv2, this means the initiator will offer to support 1085 IPsec tunnel mode with next protocol equal 41 (IPv6). 1087 IPsec tunnel mode is required because the ACP will route/forward 1088 packets received from any other ACP device across the ACP secure 1089 channels, and not only its own generated ACP packets. With IPsec 1090 transport mode, it would only be possible to send packets originated 1091 by the ACP device itself. 1093 ESP is used because ACP mandates the use of encryption for ACP secure 1094 channels. 1096 6.7.1.2. IPsec with GRE encapsulation 1098 In network devices it is often more common to implement high 1099 performance virtual interfaces on top of GRE encapsulation than 1100 natively on top of a native IPsec association. On those devices it 1101 may be beneficial to run the ACP secure channel on top of GRE 1102 protected by the IPsec association. 1104 To run ACP via GRE/IPsec, no further IANA assignments/definitions are 1105 required. The ACP device MUST support IPsec security setup via 1106 IKEv2, IPsec transport mode, local and peer link-local IPv6 addresses 1107 used for encapsuation, ESP with AES256 encryption and SHA256 hash. 1109 When GRE is used, transport mode is sufficient because the routed ACP 1110 packets are not "tunneled" by IPsec but rather by GRE: IPsec only has 1111 to deal with the GRE/IP packet which always uses the local and peer 1112 link-local IPv6 addresses and is therefore applicable to transport 1113 mode. 1115 ESP is used because ACP mandates the use of encryption for ACP secure 1116 channels. 1118 In terms of IKEv2 negotiation, this means the initiator must offer to 1119 support IPsec transport mode with next protocol equal to GRE (47) 1120 followed by the offer for native IPsec as described above (because 1121 that option is mandatory to support). 1123 If IKEv2 initiator and responder support GRE, it will be selected. 1124 The version of GRE to be used must the according to [RFC7676]. 1126 6.7.2. ACP via dTLS 1128 We define the use of ACP via dTLS in the assumption that it is likely 1129 the first transport encryption code basis supported in some classes 1130 of constrained devices. 1132 To run ACP via UDP and dTLS v1.2 [RFC6347] a locally assigned UDP 1133 port is used that is announced as a parameter in the GRASP AN_ACP 1134 objective to candidate neighbors. All autonomic devices supporting 1135 ACP via dTLS MUST support AES256 encryption and not permit weaker 1136 crypto options. 1138 There is no additional session setup or other security association 1139 besides this simple dTLS setup. As soon as the dTLS session is 1140 functional, the ACP peers will exchange ACP IPv6 packets as the 1141 payload of the dTLS transport connection. Any dTLS defined security 1142 association mechanisms such as re-keying are used as they would be 1143 for any transport application relying solely on dTLS. 1145 6.7.3. ACP Secure Channel Requirements 1147 A baseline autonomic device MUST support IPsec natively and MAY 1148 support IPsec via GRE. A constrained autonomic device MUST support 1149 dTLS. Autonomic edge device connecting constrained areas with 1150 baseline areas MUST therefore support IPsec and dTLS. 1152 Autonomic devices need to specify in documentation the set of secure 1153 ACP mechanisms they suppport. 1155 ACP secure channel MUST imediately be terminated when the lifetime of 1156 any certificate in the chain used to authenticate the neighbor 1157 expires or becomes revoked. Note that is is not standard behavior in 1158 secure channel protocols such as IPsec because the certificate 1159 authentication only influences the setup of the secure channel in 1160 these protocols. 1162 6.8. GRASP in the ACP 1164 6.8.1. GRASP as a core service of the ACP 1166 The ACP MUST run an instance of GRASP inside of it. It is a key part 1167 of the ACP services. They function in GRASP that makes it 1168 fundamental as a service is the ability for ACP wide service 1169 discovery (called objectives in GRASP). In most other solution 1170 designs such distributed discovery does not exist at all or was added 1171 as an afterthought and relied upon inconsistently. 1173 The ACP does not use IP multicast routing nor does it provide generic 1174 IP multicast services, but only IP unicast which is realized via the 1175 RPL routing protocol (described below). Instead of IP multicast 1176 routing, the ACP provides objective discovery and negotiation 1177 realized via the ACP instance of GRASP. We consider this to be a 1178 more lightweight, modular and easier to extend approach than trying 1179 to put service announcement and discovery onto some autoconfigured 1180 network wide IP multicast layer (for which so far there is no good 1181 definition) or embed it into some IGP flooding mechanism (which makes 1182 it less modular and agile to improve upon). 1184 6.8.2. ACP as the Security and Transport substrate for GRASP 1186 In the terminology of GRASP ([I-D.ietf-anima-grasp]), the ACP is the 1187 security and transport substrate for the GRASP instance run inside 1188 the ACP ("ACP GRASP"). 1190 This means that the ACP is responsible to ensure that this instance 1191 of GRASP is only using the virtual interfaces created by the ACP for 1192 ACP GRASP. Whenever the ACP adds or deletes such an interface 1193 (because of new ACP secure channels or loss thereof), the ACP needs 1194 to indicate this to the ACP instance of GRASP. The ACP exists also 1195 in the absence of any active ACP neighbors. It is created when the 1196 device has a domain certificate. In this case ASAs using GRASP 1197 running on the same device would still need to be able to discover 1198 each others objectives. When the ACP does not exist, ASAs leveraging 1199 the ACP instance of GRASP via APIs MUST still be able to operate, and 1200 MUST be able to understand that there is no ACP and that therefore 1201 the ACP instance of GRASP can not provide services. 1203 GRASP unicast messages inside the ACP to a non-link-local ACP peer 1204 address use TLS 1.2 ([RFC5246]) connections with AES256 encryption 1205 and SHA256. Mutual authentication is via the domain certificates 1206 using the same rules as for secure channels (Section 6.6). GRASP 1207 unicast messages inside the ACP to link-local ACP neighbor addresses 1208 use TCP. 1210 GRASP link-local multicast messages are targeted for a specific ACP 1211 virtual interface (as defined Section 6.12.5) but are sent by the ACP 1212 into an equally built ACP GRASP virtual interface constructed from 1213 the TCP connection(s) to the IPv6 link-local neighbor address(es) on 1214 the underlying ACP virtual interface. If the ACP GRASP virtual 1215 interface has two or more neighbors, the GRASP link-local multicast 1216 messages are replicated to all neighbor TCP connections. 1218 TLS and TLS connections for GRASP in the ACP use the IANA assigned 1219 TCP port for GRASP (7107). Effectively the transport stack is 1220 expected to be TLS for connections from/to the ULA address and TCP 1221 for connections from/to link-local addreses on the ACP virtual 1222 interfaces. 1224 6.8.2.1. Discussion 1226 TCP encapsulation for GRASP M_DISCOVERY and M_FLOOD link local 1227 messages is used because these messages are flooded across 1228 potentially many hops to all ACP devices and a single link with even 1229 temporary packet loss issues (eg: WiFi/Powerline link) can reduce the 1230 probability for loss free transmission so much that applications 1231 would want to increase the frequency with which they send these 1232 messages. This would result in more traffic flooding than hop-by-hop 1233 reliable retransmission as provided for by TCP. 1235 TLS is mandated for GRASP non-link-local unicast because the ACP 1236 secure channel mandatory authentication and encryption protects only 1237 against attacks from the outside but not against attacks from the 1238 inside: Compromised ACP members that have (not yet) been detected and 1239 removed (eg: via domain certificate revocation / expiry). 1241 If GRASP peer connections would just use TCP, compromised ACP members 1242 could simply eavesdrop passively on GRASP peer connections for whom 1243 they are onpath (man in the middle). Or intercept and modify them. 1244 With TLS, it is not possible to completely eliminate problems with 1245 compromised ACP members, but it is a lot more complex for them. 1247 With TLS, eavesdropping/spoofing by a compromised ACP device is still 1248 possible because the provider and consumer of an objective have no 1249 unique information about the other side that would allow them to 1250 distinguish a benevolent from a compromised peer. The compromised 1251 ACP device would simply announce the objective as well, potentially 1252 filter the original objective in GRASP when it is a Man In The Middle 1253 (MITM) and act as an application level proxy. This of course 1254 requires that the compromised ACP node understand the semantic of the 1255 GRASP negotiation to an extend that allows it to proxy it without 1256 being detected, but in an AN environment this is quite likely. 1258 The GRASP TLS connections are run like any other ACP traffic through 1259 the ACP secure channels. This leads to double authentication/ 1260 encryption. Future work optimizations can minimize could run GRASP 1261 beside the secure channel to avoid this but it is unclear how 1262 beneficial/feasible this is: 1264 o The security considerations for GRASP change against attacks from 1265 non-ACP (eg: "outside") nodes: TLS is subject to reset attacks 1266 while secure channel protocols may be not (eg: IPsec is not). 1268 o The secure channel method may leverage hardware acceleration and 1269 there may be little or no gain in eliminating it. 1271 o The GRASP TLS connections need to implement any additional 1272 security options that are required for secure channels. For 1273 example the closing of connections when the peers certificate has 1274 expired. 1276 6.9. Context Separation 1278 The ACP is in a separate context from the normal data plane of the 1279 device. This context includes the ACP channels IPv6 forwarding and 1280 routing as well as any required higher layer ACP functions. 1282 In classical network device platforms, a dedicated so called "Virtual 1283 routing and forwarding instance" (VRF) is one logical implementation 1284 option for the ACP. If possible by the platform SW architecture, 1285 separation options that minimize shared components are preferred, 1286 such as a logical container or virtual machine instance. The context 1287 for the ACP needs to be established automatically during bootstrap of 1288 a device. As much as possible it should be protected from being 1289 modified unintentionally by data plane configuration. 1291 Context separation improves security, because the ACP is not 1292 reachable from the global routing table. Also, configuration errors 1293 from the data plane setup do not affect the ACP. 1295 6.10. Addressing inside the ACP 1297 The channels explained above typically only establish communication 1298 between two adjacent nodes. In order for communication to happen 1299 across multiple hops, the autonomic control plane requires internal 1300 network wide valid addresses and routing. Each autonomic node must 1301 create a virtual interface with a network wide unique address inside 1302 the ACP context mentioned in Section 6.9. This address may be used 1303 also in other virtual contexts. 1305 With the algorithm introduced here, all ACP devices in the same 1306 subdomain have the same /48 prefix. Conversely, global IDs from 1307 different domains are unlikely to clash, such that two networks can 1308 be merged, as long as the policy allows that merge. See also 1309 Section 9.1 for a discussion on merging domains. 1311 Links inside the ACP only use link-local IPv6 addressing, such that 1312 each node only requires one routable virtual address. 1314 6.10.1. Fundamental Concepts of Autonomic Addressing 1316 o Usage: Autonomic addresses are exclusively used for self- 1317 management functions inside a trusted domain. They are not used 1318 for user traffic. Communications with entities outside the 1319 trusted domain use another address space, for example normally 1320 managed routable address space (called "Data Plane" in this 1321 document). 1323 o Separation: Autonomic address space is used separately from user 1324 address space and other address realms. This supports the 1325 robustness requirement. 1327 o Loopback-only: Only loopback interfaces of autonomic nodes carry 1328 routable address(es); all other interfaces exclusively use IPv6 1329 link local for autonomic functions. The usage of IPv6 link local 1330 addressing is discussed in [RFC7404]. 1332 o Use-ULA: For loopback interfaces of autonomic nodes, we use Unique 1333 Local Addresses (ULA), as specified in [RFC4193]. An alternative 1334 scheme was discussed, using assigned ULA addressing. The 1335 consensus was to use ULA-random [[RFC4193] with L=1], because it 1336 was deemed to be sufficient. 1338 o No external connectivity: They do not provide access to the 1339 Internet. If a node requires further reaching connectivity, it 1340 should use another, traditionally managed address scheme in 1341 parallel. 1343 o Addresses in the ACP are permanent, and do not support temporary 1344 addresses as defined in [RFC4941]. 1346 The ACP is based exclusively on IPv6 addressing, for a variety of 1347 reasons: 1349 o Simplicity, reliability and scale: If other network layer 1350 protocols were supported, each would have to have its own set of 1351 security associations, routing table and process, etc. 1353 o Autonomic functions do not require IPv4: Autonomic functions and 1354 autonomic service agents are new concepts. They can be 1355 exclusively built on IPv6 from day one. There is no need for 1356 backward compatibility. 1358 o OAM protocols no not require IPv4: The ACP may carry OAM 1359 protocols. All relevant protocols (SNMP, TFTP, SSH, SCP, Radius, 1360 Diameter, ...) are available in IPv6. 1362 6.10.2. The ACP Addressing Base Scheme 1364 The Base ULA addressing scheme for autonomic nodes has the following 1365 format: 1367 8 40 2 78 1368 +--+-----------------+------+--------------------------------------+ 1369 |FD| hash(subdomain) | Type | (sub-scheme) | 1370 +--+-----------------+------+--------------------------------------+ 1372 Figure 2: ACP Addressing Base Scheme 1374 The first 48 bits follow the ULA scheme, as defined in [RFC4193], to 1375 which a type field is added: 1377 o "FD" identifies a locally defined ULA address. 1379 o The ULA "global ID" (term from [RFC4193]) is set here to be a hash 1380 of the subdomain name, which results in a pseudo-random 40 bit 1381 value. It is calculated as the first 40 bits of the SHA256 hash 1382 of the subdomain name, in the example of Section 6.1.1 1383 "area51.research.acp.example.com". 1385 o To allow for extensibility, the fact that the ULA "global ID" is a 1386 hash of the subdomain name SHOULD NOT be assumed by any autonomic 1387 device during normal operations. The hash function is only 1388 executed during the creation of the certificate. If BRSKI is used 1389 then the registrar will create the ACP information field in 1390 response to the CSR Attribute Request by the pledge. 1392 o Type: This field allows different address sub-schemes. This 1393 addresses the "upgradability" requirement. Assignment of types 1394 for this field should be maintained by IANA. 1396 The sub-scheme may imply a range or set of addresses assigned to the 1397 device, this is called the ACP address range/set and explained in 1398 each sub-scheme. 1400 6.10.3. ACP Zone Addressing Sub-Scheme 1402 The sub-scheme defined here is defined by the Type value 00b (zero) 1403 in the base scheme. 1405 64 64 1406 +-----------------+---------+---++-----------------------------+---+ 1407 | (base scheme) | Zone-ID | Z || Device-ID | 1408 | | | || Registrar-ID | Device-Number| V | 1409 +-----------------+---------+---++--------------+--------------+---+ 1410 50 13 1 48 15 1 1412 Figure 3: ACP Zone Addressing Sub-Scheme 1414 The fields are defined as follows: 1416 o Zone-ID: If set to all zero bits: The Device-ID bits are used as 1417 an identifier (as opposed to a locator). This results in a non- 1418 hierarchical, flat addressing scheme. Any other value indicates a 1419 zone. See section Section 6.10.3.1 on how this field is used in 1420 detail. 1422 o Z: MUST be 0. 1424 o Device-ID: A unique value for each device. 1426 The 64 bit Device-ID is derived and composed as follows: 1428 o Registrar-ID (48 bit): A number unique inside the domain that 1429 identifies the registrar which assigned the Device-ID to the 1430 device. A MAC address of the registrar can be used for this 1431 purpose. 1433 o Device-Number (Device-Number): A number which is unique for a 1434 given registrar, to identify the device. This can be a 1435 sequentially assigned number. 1437 o V (1 bit): Virtualization bit: 0: Indicates the ACP itself 1438 ("autonomic node base system); 1: Indicates the optional "host" 1439 context on the ACP device (see below). 1441 In the Zone addressing sub-scheme, the ACP address in the certificate 1442 has Zone and V fields as all zero bits. The ACP address set includes 1443 addresses with any Zone value and any V value. 1445 The "Device-ID" itself is unique in a domain (i.e., the Zone-ID is 1446 not required for uniqueness). Therefore, a device can be addressed 1447 either as part of a flat hierarchy (zone ID = 0), or with an 1448 aggregation scheme (any other zone ID). A address with zone-ID = 0 1449 is an identifier, with another zone-ID as a locator. See 1450 Section 6.10.3.1 for a description of the zone bits. 1452 The Virtual bit in this sub-scheme allows to easily add the ACP as a 1453 component to existing systems without causing problems in the port 1454 number space between the services in the ACP and the existing system. 1455 V:0 is the ACP router (autonomous node base system), V:1 is the host 1456 with pre-existing transport endpoints on it that could collide with 1457 the transport endpoints used by the ACP router. The ACP host could 1458 for example have a virtual p2p interface with the V:0 address as its 1459 router into the ACP. Depending on the SW design of ASA (outside the 1460 scope of this specification), they may use the V:0 or V:1 address. 1462 The location of the V bit(s) at the end of the address allows to 1463 announce a single prefix for each autonomic node. For example, in a 1464 network with 20,000 ACP devices, this avoid 20,000 additional routes 1465 in the routing table. 1467 6.10.3.1. Usage of the Zone Field 1469 The "Zone-ID" allows for the introduction of structure in the 1470 addressing scheme. 1472 Zone = zero is the default addressing scheme in an autonomic domain. 1473 Every autonomic node MUST respond to its ACP address with zone=0. 1474 Used on its own this leads to a non-hierarchical address scheme, 1475 which is suitable for networks up to a certain size. In this case, 1476 the addresses primarily act as identifiers for the nodes, and 1477 aggregation is not possible. 1479 If aggregation is required, the 13 bit value allows for up to 8192 1480 zones. The allocation of zone numbers may either happen 1481 automatically through a to-be-defined algorithm; or it could be 1482 configured and maintained manually. 1484 If a device learns through an autonomic method or through 1485 configuration that it is part of a zone, it MUST also respond to its 1486 ACP address with that zone number. In this case the ACP loopback is 1487 configured with two ACP addresses: One for zone 0 and one for the 1488 assigned zone. This method allows for a smooth transition between a 1489 flat addressing scheme and an hierarchical one. 1491 (Theoretically, the 13 bits for the Zone-ID would allow also for two 1492 levels of zones, introducing a sub-hierarchy. We do not think this 1493 is required at this point, but a new type could be used in the future 1494 to support such a scheme.) 1496 Note: The Zone-ID is one method to introduce structure or hierarchy 1497 into the ACP. Another way is the use of the routing subdomain field 1498 in the ACP that leads to different /40 ULA prefixes within an 1499 autonomic domain. This gives followup work two options to consider. 1501 6.10.4. ACP Manual Addressing Sub-Scheme 1503 The sub-scheme defined here is defined by the Type value 00b (zero) 1504 in the base scheme. 1506 64 64 1507 +---------------------+---------+---++-----------------------------+ 1508 | (base scheme) |Subnet-ID| Z || Interface Identifier | 1509 +---------------------+---------+---++-----------------------------+ 1510 50 13 1 1512 Figure 4: ACP Manual Addressing Sub-Scheme 1514 The fields are defined as follows: 1516 o Subnet-ID: Configured subnet identifier. 1518 o Z: MUST be 1. 1520 o Interface Identifier. 1522 This sub-scheme is meant for "manual" allocation to subnets where the 1523 other addressing schemes can not be used. The primary use case is 1524 for assignment to ACP connect subnets (see Section 8.1.1). 1526 "Manual" means that allocations of the Subnet-ID need to be done 1527 today with pre-existing, non-autonomic mechanisms. Every subnet that 1528 uses this addressing sub-scheme needs to use a unique Subnet-ID 1529 (unless some anycast setup is done). Future work may define 1530 mechanisms for auto-coordination between ACP devices and auto- 1531 allocation of Subnet-IDs between them. 1533 The Z field is following the Subnet-ID field so that future work 1534 could allocate/coordinate both Zone-ID and Subnet-ID consistently and 1535 use an integrated aggregateable routing approach across them. Z=0 1536 (Zone sub-scheme) would then be used for network wide unique, 1537 registrar assigned (and certificate protected) Device-IDs primarily 1538 for ACP devices while Z=1 would be used for device-level assigned 1539 Interface Identifiers primarily for non-ACP-devices. 1541 Manual addressing sub-scheme addresses are not assumed to be used the 1542 ACP information field in certificates. If they are used, then value 1543 of the Interface Identifier is left for future definitions. 1545 6.10.5. ACP Vlong Addressing Sub-Scheme 1547 The sub-scheme defined here is defined by the Type value 01b (one) in 1548 the base scheme. 1550 50 78 1551 +---------------------++-----------------------------+----------+ 1552 | (base scheme) || Device-ID | 1553 | || Registrar-ID | Device-Number| V | 1554 +---------------------++--------------+--------------+----------+ 1555 46 33/17 8/16 1557 Figure 5: ACP Vlong Addressing Sub-Scheme 1559 This addressing scheme foregoes the Zone field to allow for larger, 1560 flatter routed networks (eg: as in IoT) with more than 2^32 Device- 1561 Numbers. It also allows for up to 2^16 - 65536 different virtualized 1562 adddresses, which could be used to address individual software 1563 components in an ACP device. 1565 The fields are the same as in the Zone sub-scheme with the following 1566 refinements: 1568 o V: Virtualization bit: Values 0 and 1 as in Zone sub-scheme, 1569 further values use via definition in followup work. 1571 o Registrar-ID: To maximize Device-Number and V, the Registrar-ID is 1572 reduced to 46 bits. This still allows to use the MAC address of a 1573 registrar by removing the V and U bits from the 48 bits of a MAC 1574 address (those two bits are never unique, so they can not be used 1575 to distinguish MAC addresses). 1577 o If the first bit of the "Device-Number" is "1", then the Device 1578 number is 17 bit long and the V field is 16 bit long. Otherwise 1579 the Device-Number is 33 bit long and the V field is 8 bit long. 1580 "0" bit Device-Numbers are intended to be used for "general 1581 purpose" ACP devices that would potentially have a limited number 1582 (< 256) of internal users of the ACP that require separate 1583 V(irtual) addresses. "1" bit Device-Numbers are intended for ACP 1584 devices that are ACP edge devices (see Section 8.1.1) or that have 1585 a large number of internal ACP users requiring separate V(irtual) 1586 addresses. For example large SDN controllers with container 1587 modular software architecture (see Section 8.1.2). 1589 In the Vlong addressing sub-scheme, the ACP address in the 1590 certificate has all V field bits as zero. The ACP address set 1591 includes address for the device includes any V value. 1593 6.10.6. Other ACP Addressing Sub-Schemes 1595 Other ACP addressing sub-schemes can be defined if and when required. 1596 IANA would need to assign a new "type" for each new addressing sub- 1597 scheme. With the current allocations, 5 more schemes are possible 1598 without further reducing the number of bits in a future scheme. 1600 6.11. Routing in the ACP 1602 Once ULA address are set up all autonomic entities should run a 1603 routing protocol within the autonomic control plane context. This 1604 routing protocol distributes the ULA created in the previous section 1605 for reachability. The use of the autonomic control plane specific 1606 context eliminates the probable clash with the global routing table 1607 and also secures the ACP from interference from the configuration 1608 mismatch or incorrect routing updates. 1610 The establishment of the routing plane and its parameters are 1611 automatic and strictly within the confines of the autonomic control 1612 plane. Therefore, no manual configuration is required. 1614 All routing updates are automatically secured in transit as the 1615 channels of the autonomic control plane are by default secured, and 1616 this routing runs only inside the ACP. 1618 The routing protocol inside the ACP is RPL ([RFC6550]). See 1619 Section 10.3 for more details on the choice of RPL. 1621 RPL adjacencies are set up across all ACP channels in the same domain 1622 including all its routing subdomains. See Section 10.5 for more 1623 details. 1625 6.11.1. RPL Profile 1627 The following is a description of the RPL profile that ACP nodes need 1628 to support by default. The format of this section is derived from 1629 draft-ietf-roll-applicability-template. 1631 6.11.1.1. Summary 1633 In summary, the profile chosen for RPL is one that expects a fairly 1634 reliable network reasonable fast links so that RPL convergence will 1635 be triggered immediately upon recognition of link failure/recovery. 1637 The key limitation of the chosen profile is that it is designed to 1638 not require any dataplane artifacts (such as [RFC6553]). While the 1639 senders/receivers of ACP packets can be legacy NOC devices connected 1640 via "ACP connect" (see Section 8.1.1 to the ACP, their connectivity 1641 can be handled as non-RPL-aware leafs (or "Internet") accoding to the 1642 dataplane architecture explained in [I-D.ietf-roll-useofrplinfo]. 1643 This non-artifact profile is largely driven by the desire to avoid 1644 introducing the required Hop-by-Hop headers into the ACP VRF control 1645 plane. Many devices will have their VRF forwarding code designed 1646 into silicon. 1648 In this profile choice, RPL has no dataplane artifacts. A simple 1649 destination prefix based upon the routing table is used. A 1650 consequence of supporting only a single instanceID (containing one 1651 DODAG), the ACP will only accomodate only a single class of routing 1652 table and can not create optimized routing paths to accomplish 1653 latency or energy goals. 1655 Consider a network that has multiple NOCs in different locations. 1656 Only one NOC will become the DODAG root. Other NOCs will have to 1657 send traffic through the DODAG (tree) rooted in the primary NOC. 1658 Depending on topology, this can be an annoyance from a latency point 1659 of view, but it does not represent a single point of failure, as the 1660 DODAG can reconfigure itself when it detects data plane forwarding 1661 failures. 1663 The lack of a RPI (the header defined by [RFC6553]), means that the 1664 dataplane will have no rank value that can be used to detect loops. 1665 As a result, traffic may loop until the TTL of the packet reaches 1666 zero. This the same behavior as that of other IGPs that do not have 1667 the data plane options as RPPL. There are a variety of heuristics 1668 that can be used to signal from the data plane to the RPL control 1669 plane that a new route is needed. 1671 Additionally, failed ACP tunnels will be detected by IKEv2 Dead Peer 1672 Detection (which can function as a replacement for an LLN's ETX). A 1673 failure of an ACP tunnel should signal the RPL control plane to pick 1674 a different parent. 1676 Future Extensions to this RPL profile can provide optimality for 1677 multiple NOCs. This requires utilizing data plane artifact including 1678 IPinIP encap/decap on ACP routers and processing of IPv6 RPI headers. 1679 Alternatively (Src,Dst) routing table entries could be used. A 1680 decision for the preferred technology would have to be done when such 1681 extension is defined. 1683 6.11.1.2. RPL Instances 1685 Single RPL instance. Default RPLInstanceID = 0. 1687 6.11.1.3. Storing vs. Non-Storing Mode 1689 RPL Mode of Operations (MOP): mode 3 "Storing Mode of Operations with 1690 multicast support". Implementations should support also other modes. 1691 Note: Root indicates mode in DIO flow. 1693 6.11.1.4. DAO Policy 1695 Proactive, aggressive DAO state maintenance: 1697 o Use K-flag in unsolicited DAO indicating change from previous 1698 information (to require DAO-ACK). 1700 o Retry such DAO DAO-RETRIES(3) times with DAO- ACK_TIME_OUT(256ms) 1701 in between. 1703 6.11.1.5. Path Metric 1705 Hopcount. 1707 6.11.1.6. Objective Function 1709 Objective Function (OF): Use OF0 [RFC6552]. No use of metric 1710 containers. 1712 rank_factor: Derived from link speed: <= 100Mbps: 1713 LOW_SPEED_FACTOR(5), else HIGH_SPEED_FACTOR(1) 1715 6.11.1.7. DODAG Repair 1717 Global Repair: we assume stable links and ranks (metrics), so no need 1718 to periodically rebuild DODAG. DODAG version only incremented under 1719 catastrophic events (eg: administrative action). 1721 Local Repair: As soon as link breakage is detected, send No-Path DAO 1722 for all the targets that where reachable only via this link. As soon 1723 as link repair is detected, validate if this link provides you a 1724 better parent. If so, compute your new rank, and send new DIO that 1725 advertises your new rank. Then send a DAO with a new path sequence 1726 about yourself. 1728 stretch_rank: none provided ("not stretched"). 1730 Data Path Validation: Not used. 1732 Trickle: Not used. 1734 6.11.1.8. Multicast 1736 Not used yet but possible because of the seleced mode of operations. 1738 6.11.1.9. Security 1740 [RFC6550] security not used, substituted by ACP security. 1742 6.11.1.10. P2P communications 1744 Not used. 1746 6.11.1.11. IPv6 address configuration 1748 Every ACP device (RPL node) announces an IPv6 prefix covering the 1749 address(es) used internally in the ACP device. The prefix length 1750 depends on the choosen addressing sub-scheme of the ACP address 1751 provisioned into the certificate of the ACP device, eg: /127 for Zone 1752 addressing sub-scheme or /112 or /120 for Vlong addressing sub- 1753 scheme. See Section 6.10 for more details. 1755 Every ACP device MUST install a blackhole (aka null route) route for 1756 whatever ACP address space that it advertises (i.e: the /96 or /127). 1757 This is avoid routing loops for addresses that an ACP node has not 1758 (yet) used. 1760 6.11.1.12. Administrative parameters 1762 Administrative Preference ([RFC6552], 3.2.6 - to become root): 1763 Indicated in DODAGPreference field of DIO message. 1765 o Explicit configured "root": 0b100 1767 o Registrar (Default): 0b011 1769 o AN-connect (non registrar): 0b010 1771 o Default: 0b001. 1773 6.11.1.13. RPL Dataplane artifacts 1775 RPI (RPL Packet Information [RFC6553]): Not used as there is only a 1776 single instance, and data path validation is not being used. 1778 SRH (RPL Source Routing - RFC6552): Not used. Storing mode is being 1779 used. 1781 6.11.1.14. Unknown Destinations 1783 Because RPL minimizes the size of the routing and forwarding table, 1784 prefixes reachable through the same interface as the RPL root are not 1785 known on every ACP device. Therefore traffic to unknown destination 1786 addresses can only be discovered at the RPL root. The RPL root 1787 SHOULD have attach safe mechanisms to operationally discover and log 1788 such packets. 1790 6.12. General ACP Considerations 1792 Since channels are by default established between adjacent neighbors, 1793 the resulting overlay network does hop by hop encryption. Each node 1794 decrypts incoming traffic from the ACP, and encrypts outgoing traffic 1795 to its neighbors in the ACP. Routing is discussed in Section 6.11. 1797 6.12.1. Performance 1799 There are no performance requirements against ACP implementations 1800 defined in this document because the performance requirements depend 1801 on the intended use case. It is expected that full autonomic devices 1802 with a wide range of ASA can require high forwarding plane 1803 performance in the ACP, for example for telemetry, but that 1804 determination is for future work. Implementations of ACP to solely 1805 support traditional/SDN style use cases can benefit from ACP at lower 1806 performance, especially if the ACP is used only for critical 1807 operations, eg: when the data plane is not available. See 1808 [I-D.ietf-anima-stable-connectivity] for more details. 1810 6.12.2. Addressing of Secure Channels in the data plane 1812 In order to be independent of the Data Plane configuration of global 1813 IPv6 subnet addresses (that may not exist when the ACP is brought 1814 up), Link-local secure channels MUST use IPv6 link local addresses 1815 between adjacent neighbors. The fully autonomic mechanisms in this 1816 document only specify these link-local secure channels. Section 8.2 1817 specifies extensions in which secure channels are tunnels. For 1818 those, this requirement does not apply. 1820 The Link-local secure channels specified in this document therefore 1821 depend on basic IPv6 link-local functionality to be auto-enabled by 1822 the ACP and prohibiting the Data Plane from disabling it. The ACP 1823 also depends on being able to operate the secure channel protocol 1824 (eg: IPsec / dTLS) across IPv6 link-local addresses, something that 1825 may be an uncommon profile. Functionaly, these are the only 1826 interactions with the Data Plane that the ACP needs to have. 1828 To mitigate these interactions with the Data Plane, extensions to 1829 this document may specify additional layer 2 or layer encapsulations 1830 for ACP secure channels as well as other protocols to auto-discover 1831 peer endpoints for such encapsulations (eg: tunneling across L3 or 1832 use of L2 only encapsulations). 1834 6.12.3. MTU 1836 The MTU for ACP secure channels must be derived locally from the 1837 underlying link MTU minus the secure channel encapsulation overhead. 1839 ACP secure Channel protocols do not need to perform MTU discovery 1840 because they are built across L2 adjacencies - the MTU on both sides 1841 connecting to the L2 connection are assumed to be consistent. 1842 Extensions to ACP where the ACP is for example tunneled need to 1843 consider how to guarantee MTU consistency. This is a standard issue 1844 with tunneling, not specific to running the ACP across it. Transport 1845 stacks running across ACP can perform normal PMTUD (Path MTU 1846 Discovery). Because the ACP is meant to be prioritize reliability 1847 over performance, they MAY opt to only expect IPv6 minimum MTU (1280) 1848 to avoid running into PMTUD implementation bugs or underlying link 1849 MTU mismatch problems. 1851 6.12.4. Multiple links between nodes 1853 If two nodes are connected via several links, the ACP SHOULD be 1854 established across every link, but it is possible to establish the 1855 ACP only on a sub-set of links. Having an ACP channel on every link 1856 has a number of advantages, for example it allows for a faster 1857 failover in case of link failure, and it reflects the physical 1858 topology more closely. Using a subset of links (for example, a 1859 single link), reduces resource consumption on the devices, because 1860 state needs to be kept per ACP channel. The negotiation scheme 1861 explained in Section 6.5 allows Alice (the node with the higher ACP 1862 address) to drop all but the desired ACP channels to Bob - and Bob 1863 will not re-try to build these secure channels from his side unless 1864 Alice shows up with a previously unknown GRASP announcement (eg: on a 1865 different link or with a different address announced in GRASP). 1867 6.12.5. ACP interfaces 1869 The ACP VRF has conceptually two type of interfaces: The ACP loopback 1870 interface(s) to which the ACP ULA address(es) are assigned and the 1871 "ACP virtual interfaces" that are mapped to the ACP secure channels. 1873 The term "loopback interface" is commonly used to refer to internal 1874 pseudo interfaces through which the device can only reach itself. In 1875 network devices these interfaces are used to hold addresses used by 1876 the transport stack of the system when an address should be reliable 1877 reachable in the presence of arbitrary link failures. As long as 1878 addresses on a loopback interface are routeable in the routing 1879 protocol used, they will be reachable as long as there is at least 1880 one working network path. This is opposed to routeable address 1881 assigned to an externally connected interface. That address will 1882 become unreachable when that interface goes down. For this reason, 1883 the ACP (ULA) address(es) are assigned to loopback type interface(s). 1885 ACP secure channels, eg: IPsec, dTLS or other future security 1886 associations with neighboring ACP devices can be mapped to ACP 1887 virtual interfaces in different ways: 1889 ACP point-to-point virtual interface: 1891 Each ACP secure channel is mapped into a separate point-to-point ACP 1892 virtual interface. If a physical subnet has more than two ACP 1893 capable nodes (in the same domain), this implementation approach will 1894 lead to a full mesh of ACP virtual interfaces between them. 1896 ACP multi-access virtual interface: 1898 In a more advanced implementation approach, the ACP will construct a 1899 single multi-access ACP virtual interface for all ACP secure channels 1900 to ACP capable nodes reachable across the same underlying (physical) 1901 subnet. IPv6 link-local multicast packets sent into an ACP multi- 1902 access virtual interface are replicated to every ACP secure channel 1903 mapped into the ACP multicast-access virtual interface. IPv6 unicast 1904 packets sent into an ACP multi-access virtual interface are sent to 1905 the ACP secure channel that belongs to the ACP neighbor that is the 1906 next-hop in the ACP forwarding table entry used to reach the packets 1907 destination address. 1909 There is no requirement for all ACP devices on the same physical 1910 multi-access subnet to use the same type of ACP virtual interface. 1911 This is purely a node local decision. 1913 ACP devices MUST perform standard IPv6 operations across ACP virtual 1914 interfaces including SLAAC (Stateless Address AutoConfiguration - 1915 [RFC4862]) to assign their IPv6 link local address on the ACP virtual 1916 interface and ND (Neighbor Discovery - [RFC4861]) to discover which 1917 IPv6 link-local neighbor address belongs to which ACP secure channel 1918 mapped to the ACP virtual interface. This is independent of whether 1919 the ACP virtual interface is point-to-point or multi-access. 1921 ACP devices MAY reduce the amount of link-local IPv6 multicast 1922 packets from ND by learning the IPv6 link-local neighbor address to 1923 ACP secure channel mapping from other messages such as the source 1924 address of IPv6 link-local multicast RPL messages - and therefore 1925 forego the need to send Neighbor Solication messages. 1927 ACP devices MUST NOT derive their ACP virtual interface IPv6 link 1928 local address from their IPv6 link-local address used on the 1929 underlying interface (e.g.: the address that is used as the 1930 encapsulation address in the ACP secure channel protocols defined in 1931 this document). This ensures that the ACP virtual interface 1932 operations will not depend on the specifics of the encapsulation used 1933 by the ACP secure channel and that attacks against SLAAC on the 1934 physical interface will not impact the operations of the ACP virtal 1935 interface. 1937 The link-layer address of an ACP virtual interface is the address 1938 used for the underlying interface across which the secure tunnels are 1939 built, typically Ethernet addresses. Because unicast IPv6 packets 1940 sent to an ACP virtual interface are not sent to a link-layer 1941 destination address but rather the correct ACP secure channel, the 1942 link-layer address fields SHOULD be ignored on reception and instead 1943 the ACP secure channel remembered from which the message was 1944 received. 1946 Multi-access ACP virtual interfaces are preferrable implementations 1947 when the underlying interface is a (broadcast) multi-access subnet 1948 because they do reflect the presence of the underlying multi-access 1949 subnet into the virtual interfaces of the ACP. This makes it for 1950 example simpler to build services with topology awareness inside the 1951 ACP VRF in the same way as they could have been built running 1952 natively on the multi-access interfaces. 1954 Consider also the impact of point-to-point vs. multicaccess virtual 1955 interface on the efficiency of flooding via link local multicasted 1956 messages: 1958 Assume a LAN with three ACP neighbors, Alice, Bob and Carol. Alices 1959 ACP GRASP wants to send a link-local GRASP multicast message to Bob 1960 and Carol. If Alices ACP emulates the LAN as one point-to-point 1961 interface to Bob and one to Carol, The sending applications itself 1962 will send two copies, if Alices ACP emulates a LAN, GRASP will send 1963 one packet and the ACP will replicate it. The result is the same. 1964 The difference happens when Bob and Carol receive their packet. If 1965 they use point-to-point ACP virtual interfaces, their GRASP instance 1966 would forward the packet from Alice to each other as part of the 1967 GRASP flooding procedure. These packets are unnecessary and would be 1968 discarded by GRASP on receipt as duplicates. If Bob and Charlies ACP 1969 would emulate a multi-acccess virtual interface, then this would not 1970 happen, because GRASPs flooding procedure does not replicate back 1971 packets to the interface that they where received from. 1973 Note that link-local GRASP multicast messages are not sent directly 1974 as IPv6 link-local multicast UDP messages into ACP virtual 1975 interfaces, but instead into ACP GRASP virtual interfaces, that are 1976 layered on top of ACP virtual interfaces to add TCP reliability to 1977 link-local multicast GRASP messages. Nevertheless, these ACP GRASP 1978 virtual interfaces perform the same replication of message and 1979 therefore result in the same impact on flooding. See Section 6.8.2 1980 for more details. 1982 RPL does support operations and correct routing table construction 1983 across non-broadcast multi-access (NBMA) subnets. This is common 1984 when using many radio technologies. When such NBMA subnets are used, 1985 they MUST NOT be represented as ACP multi-access virtual interfaces 1986 because the replication of IPv6 link-local multicast multicast 1987 messages will not reach all NBMA subnet neighbors. In result, GRASP 1988 message flooding would fail. Instead, each ACP secure channel across 1989 such an interface MUST be represented as a ACP point-to-point virtual 1990 interface. These requirements can be avoided by coupling the ACP 1991 flooding mechanism for GRASP messages directly to RPL (flood GRASP 1992 across DODAG), but such an enhancement is subjet for future work. 1994 Care must also be taken when creating multi-access ACP virtual 1995 interfaces across ACP secure channels between ACP devices in 1996 different domains or routing subdomains. The policies to be 1997 negotiated may be described as peer-to-peer policies in which case it 1998 is easier to create ACP point-to-point virtual interfaces for these 1999 secure channels. 2001 7. ACP support on L2 switches/ports (Normative) 2003 7.1. Why 2005 ANrtr1 ------ ANswitch1 --- ANswitch2 ------- ANrtr2 2006 .../ \ \ ... 2007 ANrtrM ------ \ ------- ANrtrN 2008 ANswitchM ... 2010 Figure 6 2012 Consider a large L2 LAN with ANrtr1...ANrtrN connected via some 2013 topology of L2 switches. Examples include large enterprise campus 2014 networks with an L2 core, IoT networks or broadband aggregation 2015 networks which often have even a multi-level L2 switched topology. 2017 If the discovery protocol used for the ACP is operating at the subnet 2018 level, every AN router will see all other AN routers on the LAN as 2019 neighbors and a full mesh of ACP channels will be built. If some or 2020 all of the AN switches are autonomic with the same discovery 2021 protocol, then the full mesh would include those switches as well. 2023 A full mesh of ACP connections like this can creates fundamental 2024 scale challenges. The number of security associations of the secure 2025 channel protocols will likely not scale arbitrarily, especially when 2026 they leverage platform accelerated encryption/decryption. Likewise, 2027 any other ACP operations (such as routing) needs to scale to the 2028 number of direct ACP neigbors. An AN router with just 4 interfaces 2029 might be deployed into a LAN with hundreds of neighbors connected via 2030 switches. Introducing such a new unpredictable scaling factor 2031 requirement makes it harder to support the ACP on arbitrary platforms 2032 and in arbitrary deployments. 2034 Predictable scaling requirements for ACP neighbors can most easily be 2035 achieved if in topologies like these, AN capable L2 switches can 2036 ensure that discovery messages terminate on them so that neighboring 2037 AN routers and switches will only find the physically connected AN L2 2038 switches as their candidate ACP neighbors. With such a discovery 2039 mechanism in place, the ACP and its security associations will only 2040 need to scale to the number of physical interfaces instead of a 2041 potentially much larger number of "LAN-connected" neighbors. And the 2042 ACP topology will follow directly the physical topology, something 2043 which can then also be leveraged in management operations or by ASAs. 2045 In the example above, consider ANswitch1 and ANswitchM are AN 2046 capable, and ANswitch2 is not AN capable. The desired ACP topology 2047 is therefore that ANrtr1 and ANrtrM only have an ACP connetion to 2048 ANswitch1, and that ANswitch1, ANrtr2, ANrtrN have a full mesh of ACP 2049 connection amongst each other. ANswitch1 also has an ACP connection 2050 with ANswitchM and ANswitchM has ACP connections to anything else 2051 behind it. 2053 7.2. How (per L2 port DULL GRASP) 2055 To support ACP on L2 switches or L2 switches ports of an L3 device, 2056 it is necessary to to make those L2 ports look like L3 interfaces for 2057 the ACP implementation. This primarily involves the creation of a 2058 separate DULL GRASP instance/domain on every such L2 port. Because 2059 GRASP has a dedicated IPv6 link-local multicast address, it is 2060 sufficient that all ethernet packets for this address are being 2061 extracted at the port level and passed to that DULL GRASP instance. 2062 Likewise the IPv6 link-local multicast packets sent by that DULL 2063 GRASP instance need to be sent only towards the L2 port for this DULL 2064 GRASP instance. 2066 The rest of ACP operations can operate in the same way as in L3 2067 devices: Assume for example that the device is an L3/L2 hybrid device 2068 where L3 interfaces are assigned to VLANs and each VLAN has 2069 potentially multiple ports. DULL GRASP is run as described 2070 individually on each L2 port. When it discovers a candidate ACP 2071 neighbor, it passes its IPv6 link-local address and supported secure 2072 channel protocols to the ACP secure channel negotiation that can be 2073 bound to the L3 (VLAN) interface. It will simply use link-local IPv6 2074 multicast packets to the candidate ACP neighbor. Once a secure 2075 channel is established to such a neighbor, the virtual interface to 2076 which this secure channel is mapped should then actually be the L2 2077 port and not the L3 interface to best map the actual physical 2078 topology into the ACP virtual interfaces. See Section 6.12.5 for 2079 more details about how to map secure channels into ACP virtual 2080 interfaces. Note that a single L2 port can still have multiple ACP 2081 neighbors if it connect for example to multiple ACP neighbors via a 2082 non-ACP enabled switch. The per L2 port ACP virtual interface can 2083 threfore still be a multi-access virtual LAN. 2085 For example, in the above picture, ANswitch1 would run separate DULL 2086 GRASP instances on its ports to ANrtr1, ANswitch2 and ANswitchI, even 2087 though all those three ports may be in the data plane in the same 2088 (V)LAN and perfom L2 switching between these ports, ANswitch1 would 2089 perform ACP L3 routing between them. 2091 The description in the previous paragraph was specifically meant to 2092 illustrate that on hybrid L3/L2 devices that are common in 2093 enterprise, IoT and broadband aggregation, there is only the GRASP 2094 packet extraction (by ethernet address) and GRASP link-local 2095 multicast per L2-port packet injection that has to consider L2 ports 2096 at the hardware forwarding level. The remaining operations are 2097 purely ACP control plane and setup of secure channels across the L3 2098 interface. This hopefully makes support for per-L2 port ACP on those 2099 hybrid devices easy. 2101 This L2/L3 optimized approach is subject to "address stealing", eg: 2102 where a device on one port uses addresses of a device on another 2103 port. This is a generic issue in L2 LANs and switches often already 2104 have some form of "port security" to prohibit this. They rely on NDP 2105 or DHCP learning of which port/MAC-address and IPv6 address belong 2106 together and block duplicates. This type of function needs to be 2107 enabled to prohibit DoS attacks. Likewise the GRASP DULL instance 2108 needs to ensure that the IPv6 address in the locator-option matches 2109 the source IPv6 address of the DULL GRASP packet. 2111 In devices without such a mix of L2 port/interfaces and L3 interfaces 2112 (to terminate any transport layer connections), implementation 2113 details will differ. Logically most simply every L2 port is 2114 considered and used as a separate L3 subnet for all ACP operations. 2115 The fact that the ACP only requires IPv6 link-local unicast and 2116 multicast should make support for it on any type of L2 devices as 2117 simple as possible, but the need to support secure channel protocols 2118 may be a limiting factor to supporting ACP on such devices. Future 2119 options such as 802.1ae could improve that situation. 2121 A generic issue with ACP in L2 switched networks is the interaction 2122 with the Spanning Tree Protocol. Ideally, the ACP should be built 2123 also across ports that are blocked in STP so that the ACP does not 2124 depend on STP and can continue to run unaffected across STP topology 2125 changes (where reconvergence can be quite slow). The above described 2126 simple implementation options are not sufficient for this. Instead 2127 they would simply have the ACP run across the active STP topology and 2128 therefore the ACP would equally be interrupted and reconverge with 2129 STP changes. 2131 L3/L2 devices SHOULD support per-L2 port ACP. 2133 8. Support for Non-Autonomic Components (Normative) 2135 8.1. ACP Connect 2137 8.1.1. Non-Autonomic Controller / NMS system 2139 The Autonomic Control Plane can be used by management systems, such 2140 as controllers or network management system (NMS) hosts (henceforth 2141 called simply "NMS hosts"), to connect to devices through it. For 2142 this, an NMS host must have access to the ACP. The ACP is a self- 2143 protecting overlay network, which allows by default access only to 2144 trusted, autonomic systems. Therefore, a traditional, non-autonomic 2145 NMS system does not have access to the ACP by default, just like any 2146 other external device. 2148 If the NMS host is not autonomic, i.e., it does not support autonomic 2149 negotiation of the ACP, then it can be brought into the ACP by 2150 explicit configuration. To support connections to adjacent non- 2151 autonomic nodes, an autonomic node with ACP must support "ACP 2152 connect" (sometimes also connect "autonomic connect"): 2154 "ACP connect" is a function on an autonomic device that is called an 2155 "ACP edge device". With "ACP connect", interfaces on the device can 2156 be configured to be put into the ACP VRF. The ACP is then accessible 2157 to other (NOC) systems on such an interface without those systems 2158 having to support any ACP discovery or ACP channel setup. This is 2159 also called "native" access to the ACP because to those (NOC) systems 2160 the interface looks like a normal network interface (without any 2161 encryption/novel-signaling). 2163 data-plane "native" (no ACP) 2164 . 2165 +--------+ +----------------+ . +-------------+ 2166 | ACP | |ACP Edge Device | . | | 2167 | Device | | | v | | 2168 | |-------|...[ACP VRF]....+-----------------| |+ 2169 | | ^ |. | | NOC Device || 2170 | | . | .[Data Plane]..+-----------------| "NMS hosts" || 2171 | | . | [ VRF ] | . ^ | || 2172 +--------+ . +----------------+ . . +-------------+| 2173 . . . +-------------+ 2174 . . . 2175 data-plane "native" . ACP "native" (unencrypted) 2176 + ACP auto-negotiated . "ACP connect subnet" 2177 and encrypted . 2178 ACP connect interface 2179 eg: "vrf ACP native" (config) 2181 Figure 7: ACP connect 2183 ACP connect has security consequences: All systems and processes 2184 connected via ACP connect have access to all autonomic nodes on the 2185 entire ACP, without further authentication. Thus, the ACP connect 2186 interface and (NOC) systems connected to it must be physically 2187 controlled/secured. For this reason the mechanisms described here do 2188 explicitly not include options to allow for a non-ACP router to be 2189 connected across an ACP connect interface and addresses behind such a 2190 router routed inside the ACP. 2192 An ACP connect interface provides exclusively access to only the ACP. 2193 This is likely insufficient for many NMS hosts. Instead, they would 2194 require a second "data-plane" interface outside the ACP for 2195 connections between the NMS host and administrators, or Internet 2196 based services, or for direct access to the data plane. The document 2197 "Autonomic Network Stable Connectivity" 2198 [I-D.ietf-anima-stable-connectivity] explains in more detail how the 2199 ACP can be integrated in a mixed NOC environment. 2201 The ACP connect interface must be (auto-)configured with an IPv6 2202 address prefix. Is prefix SHOULD be covered by one of the (ULA) 2203 prefix(es) used in the ACP. If using non-autonomic configuration, it 2204 SHOULD use the ACP Manual Addressing Sub-Scheme (Section 6.10.4). It 2205 SHOULD NOT use a prefix that is also routed outside the ACP so that 2206 the addresses clearly indicate whether it is used inside the ACP or 2207 not. 2209 The prefix of ACP connect subnets MUST be distributed by the ACP edge 2210 device into the ACP routing protocol (RPL). The NMS hosts MUST 2211 connect to prefixes in the ACP routing table via its ACP connect 2212 interface. In the simple case where the ACP usesonly one ULA prefix 2213 and all ACP connect subnets have prefixes covered by that ULA prefix, 2214 NMS hosts can rely on [RFC6724] - The NMS host will select the ACP 2215 connect interface because any ACP destination address is best matched 2216 by the address on the ACP connect interface. If the NMS hosts ACP 2217 connect interface uses another prefix or if the ACP uses multiple ULA 2218 prefixes, then the NMS hosts require (static) routes towards the ACP 2219 interface. 2221 ACP Edge Device MUST only forward IPv6 packets received from an ACP 2222 connect interface into the ACP that has an IPv6 address from the ACP 2223 prefix assigned to this interface (sometimes called "RPF filtering"). 2224 This MAY be changed through administrative measures. 2226 To limit the security impact of ACP connect, devices supporting it 2227 SHOULD implement a security mechanism to allow configuration/use of 2228 ACP connect interfaces only on devices explicitly targeted to be 2229 deployed with it (such as those physically secure locations like a 2230 NOC). For example, the certificate of such devices could include an 2231 extension required to permit configuration of ACP connect interfaces. 2232 This prohibits that a random ACP device with easy physical access 2233 that is not meant to run ACP connect could start leaking the ACP when 2234 it becomes compromised and the intruder configures ACP connect on it. 2235 The full workflow including the mechanism by which a registrar would 2236 select which device to give such a certificate to is subject to 2237 future work. 2239 8.1.2. Software Components 2241 The ACP connect mechanism be only be used to connect physically 2242 external systems (NMS hosts) to the ACP but also other applications, 2243 containers or virtual machines. In fact, one possible way to 2244 eliminate the security issue of the external ACP connect interface is 2245 to collocate an ACP edge device and an NMS host by making one a 2246 virtual machine or container inside the other - and therefore 2247 converting the unprotected external ACP subnet into an internal 2248 virtual subnet in a single device. This would ultimately result in a 2249 fully autonomic NMS host with minimum impact to the NMS hosts 2250 software architecture. This approach is not limited to NMS hosts but 2251 could equally be applied to devices consisting of one or more VNF 2252 (virtual network functions): An internal virtual subnet connecting 2253 out-of-band-management interfaces of the VNFs to an ACP edge router 2254 VNF. 2256 The core requirement is that the software components need to have a 2257 network stack that permits access to the ACP and optionally also the 2258 data plane. Like in the physical setup for NMS hosts this can be 2259 realized via two internal virtual subnets. One that is connecting to 2260 the ACP (which could be a container or virtual machine by itself), 2261 and one (or more) connecting into the data plane. 2263 This "internal" use of ACP connect approach should not considered to 2264 be a "workaround" because in this case it is possible to build a 2265 correct security model: It is not necessary to rely on unprovable 2266 external physical security mechanisms as in the case of external NMS 2267 hosts. Instead, the orchestration of the ACP, the virtual subnets 2268 and the software components can be done by trusted software that 2269 could be considered to be part of the ANI (or even an extended ACP). 2270 This software component is responsible to ensure that only trusted 2271 software components will get access to that virtual subnet and that 2272 only even more trusted software components will get access to both 2273 the ACP virtual subnet and the data plane (because those ACP users 2274 could leak traffic between ACP and data plane). This trust could be 2275 established for example through cryptographic means such signed 2276 software packages. The specification of these mechanisms is subject 2277 to future work. 2279 Note that ASA (Autonomic Software Agents) could also be software 2280 components as described in this section, but further details of ASAs 2281 are subject to future work. 2283 8.1.3. Auto Configuration 2285 ACP edge devices, NMS hosts and software components that as describd 2286 in the previous section are meant to be composed via virtual 2287 interfaces SHOULD support on the ACP connect subnet Stateless Address 2288 Autoconfiguration (SLAAC - [RFC4862]) and route autoconfiguration 2289 according to [RFC4191]. 2291 The ACP edge device acts as the router on the ACP connect subnet, 2292 providing the (auto-)configured prefix for the ACP connect subnet to 2293 NMS hosts and/or software components. The ACP edge device uses route 2294 prefix option of RFC4191 to announce the default route (::/) with a 2295 lifetime of 0 and aggregated prefixes for routes in the ACP routing 2296 table with normal lifetimes. This will ensure that the ACP edge 2297 device does not become a default router, but that the NMS hosts and 2298 software components will route the prefixes used in the ACP to the 2299 ACP edge device. 2301 Aggregated prefix means that the ACP edge device needs to only 2302 announce the /48 ULA prefixes used in the ACP but none of the actual 2303 /64 (Manual Addressing Sub-Scheme), /127 (Zone Addressing Sub- 2304 Scheme), /112 or /120 (Vlong Addressing Sub-Scheme) routes of actual 2305 ACP devices. If ACP interfaces are configured with non ULA prefixes, 2306 then those prefixes can not be aggreged without further configured 2307 policy on the ACP edge device. This explains the above 2308 recommendation to use ACP ULA prefix covered prefixes for ACP connect 2309 interfaces: They allow for a shorter list of prefixes to be signalled 2310 via RFC4191 to NMS hosts and software components. 2312 The ACP edge devices that have a Vlong ACP address MAY allocate a 2313 subset of their /112 or /120 address prefix to ACP connect 2314 interface(s) to eliminate the need to non-autonomically configure/ 2315 provision the address prefixes for such ACP connect interfaces. See 2316 Section 11 for considerations how this updates the IPv6 address 2317 architecture and ULA specification. 2319 8.1.4. Combined ACP and Data Data Plane Interface (VRF Select) 2321 Combined ACP and Data Plane interface 2322 . 2323 +--------+ +--------------------+ . +--------------+ 2324 | ACP | |ACP Edge Device | . | NMS Host(s) | 2325 | Device | | | . | / Software | 2326 | | | [ACP ]. | . | |+ 2327 | | | .[VRF ] .[VRF ] | v | "ACP address"|| 2328 | +-------+. .[Select].+--------+ "Date Plane || 2329 | | ^ | .[Data ]. | | Address(es)"|| 2330 | | . | [Plane] | | || 2331 | | . | [VRF ] | +--------------+| 2332 +--------+ . +--------------------+ +--------------+ 2333 . 2334 data-plane "native" and + ACP auto-negotiated/encrypted 2336 Figure 8: VRF select 2338 Using two physical and/or virtual subnets (and therefore interfaces) 2339 into NMS Hosts (as per Section 8.1.1) or Software (as per 2340 Section 8.1.2) may be seen as additional complexity, for example with 2341 legacy NMS Hosts that support only one IP interface. 2343 To provide a single subnet into both ACP and Data Plane, the ACP Edge 2344 device needs to demultiplex packets from NMS hosts into ACP VRF and 2345 Data Plane VRF. This is sometimes called "VRF select". If the ACP 2346 VRF has no overlapping IPv6 addresses with the Data Plane (as it 2347 should), then this function can use the IPv6 Destination address. 2348 The problem is Source Address Selection on the NMS Host(s) according 2349 to RFC6724. 2351 Consider the simple case: The ACP uses only one ULA prefix, the ACP 2352 IPv6 prefix for the Combined ACP and Data Plane interface is covered 2353 by that ULA prefix. The ACP edge device announces both the ACP IPv6 2354 prefix and one (or more) prefixes for the data plane. Without 2355 further policy configurations on the NMS Host(s), it may select its 2356 ACP address as a source address for Data Plane ULA destinations 2357 because of Rule 8 of RFC6724. The ACP edge device can pass on the 2358 packet to the Data Plane, but the ACP source address should not be 2359 used for Data Plane traffic, and return traffic may fail. 2361 If the ACP carries multiple ULA prefixes or non-ULA ACP connect 2362 prefixes, then the correct source address selection becomes even more 2363 problematic. 2365 With separate ACP connect and Data Plane subnets and RFC4191 prefix 2366 announcements that are to be routed across the ACP connect interface, 2367 RFC6724 source address selection Rule 5 (use address of outgoing 2368 interface) will be used, so that above problems do not occur, even in 2369 more complex cases of multiple ULA and non-ULA prefixes in the ACP 2370 routing table. 2372 To achieve the same behavior with a Combined ACP and Data Plane 2373 interface, the ACP Edge Device needs to behave as two separate 2374 routers on the interface: One link-local IPv6 address/router for its 2375 ACP reachability, and one link-local IPv6 address/router for its Data 2376 Plane reachability. The Router Advertisements for both are as 2377 described above (Section 8.1.3): For the ACP, the ACP prefix is 2378 announced together with RFC4191 option for the prefixes routed across 2379 the ACP and lifetime=0 to disqualify this next-hop as a default 2380 router. For the Data Plane, the Data Plane prefix(es) are announced 2381 together with whatever dafault router parameters are used for the 2382 Data Plane. 2384 In result, RFC6724 source address selection Rule 5.5 may result in 2385 the same correct source address selection behavior of NMS hosts 2386 without further configuration on it as the separate ACP connect and 2387 Data Plane interfaces. As described in the text for Rule 5.5, this 2388 is only a may, because IPv6 hosts are not required to track next-hop 2389 information. If an NMS Host does not do this, then separate ACP 2390 connect and Data Plane interfaces are the preferrable method of 2391 attachment. 2393 ACP edge devices MAY support the Combined ACP and Data Plane 2394 interface. 2396 8.1.5. Use of GRASP 2398 GRASP can and should be possible to use across ACP connect 2399 interfaces, especially in the architectural correct solution when it 2400 is used as a mechanism to connect Software (eg: ASA or legacy NMS 2401 applications) to the ACP. Given how the ACP is the security and 2402 transport substrate for GRASP, the trustworthyness of devices/ 2403 software allowed to participate in the ACP GRASP domain is one of the 2404 main reasons why the ACP section describes no solution with non-ACP 2405 routers participating in the ACP routing table. 2407 ACP connect interfaces can be dealt with in the GRASP ACP domain like 2408 any other ACP interface assuming that any physical ACP connect 2409 interface is physically protected from attacks and that the connected 2410 Software or NMS Hosts are equally trusted as that on other ACP 2411 devices. ACP edge devices SHOULD have options to filter GRASP 2412 messages in and out of ACP connect interfaces (permit/deny) and MAY 2413 have more fine-grained filtering (eg: based on IPv6 address of 2414 originator or objective). 2416 When using "Combined ACP and Data Plane Interfaces", care must be 2417 taken that only GRASP messages intended for the ACP GRASP domain 2418 received from Software or NMS Hosts are forwarded by ACP edge 2419 devices. Currently there is no definition for a GRASP security and 2420 transport substrate beside the ACP, so there is no definition how 2421 such Software/NMS Host could participate in two separate GRASP 2422 Domains across the same subnet (ACP and Data Plane domains). At 2423 current it is therefore assumed that all GRASP packets on a Combined 2424 ACP and Data Plane interface belong to the GRASP ACP Domain. They 2425 must therefore all use the ACP IPv6 addresses of the Software/NMS 2426 Hosts. The link-local IPv6 addresses of Software/NMS Hosts (used for 2427 GRASP M_DISCOVERY and M_FLOOD messages) are also assumed to belong to 2428 the ACP address space. 2430 8.2. ACP through Non-Autonomic L3 Clouds (Remote ACP neighbors) 2432 Not all devices in a network may support the ACP. If non-ACP Layer-2 2433 devices are between ACP nodes, the ACP will work across it since it 2434 is IP based. However, the autonomic discovery of ACP neigbhors via 2435 DULL GRASP is only intended to work across L2 connections, so it is 2436 not sufficient to autonomically create ACP connections across non-ACP 2437 Layer-3 devices. 2439 8.2.1. Configured Remote ACP neighbor 2441 On the autonomic device remote ACP neighbors are configured as 2442 follows: 2444 remote-peer = [ local-address, method, remote-address ] 2445 local-address = ip-address 2446 remote-address = transport-address 2447 transport-address = 2448 [ (ip-address | pattern) ?( , protocol ?(, port)) (, pmtu) ] 2449 ip-address = (ipv4-address | ipv6-address ) 2450 method = "IKEv2" / "dTLS" / .. 2451 pattern = some IP address set 2453 For each candidate configured remote ACP neighbor, the secure channel 2454 protocol "method" is configured with its expected local IP address 2455 and remote transport endpoint (transport protocol and port number for 2456 the remote transport endpoint are usually not necessary to configure 2457 if defaults for the secure channel protocol method exist. 2459 This is the same information that would be communicated via DULL for 2460 L2 adjacent candidate ACP neighbors. DULL is not used because the 2461 remote IP address would need to be configured anyhow and if the 2462 remote transport address would not be configured but learned via DULL 2463 then this would create a third party attack vector. 2465 The secure channel method leverages the configuration to filter 2466 incoming connection requests by the remote IP address. This is 2467 suplemental security. The primary security is via the mutual domain 2468 certificate based authentication of the secure channel protocol. 2470 On a hub device, the remote IP address may be set to some pattern 2471 instead of explicit IP addresses. In this case, the device does not 2472 attempt to initiate secure channel connections but only acts as their 2473 responder. This allows for simple hub&spoke setups for the ACP where 2474 some method (subject to further specification) provisions the 2475 transport-address of hubs into spokes and hubs accept connections 2476 from any spokes. The typical use case for this are spokes connecting 2477 via the Internet to hubs. For example, this would be simple 2478 extension to BRSKI to allow zero-touch security across the Internet. 2480 Unlike adjacent ACP neighbor connections, configured remote ACP 2481 neighbor connections can also be across IPv4. Not all (future) 2482 secure channel methods may support running IPv6 (as used in the ACP 2483 across the secure channel connection) over IPv4 encapsulation. 2485 Unless the secure channel method supports PMTUD, it needs to be set 2486 up with minimum MTU or the path mtu (pmtu) should be configured. 2488 8.2.2. Tunneled Remote ACP Neighbor 2490 An IPinIP, GRE or other form of pre-existing tunnel is configured 2491 between two remote ACP peers and the virtual interfaces representing 2492 the tunnel are configured to "ACP enable". This will enable IPv6 2493 link local addresses and DULL on this tunnel. In result, the tunnel 2494 is used for normal "L2 adjacent" candidate ACP neighbor discovery 2495 with DULL and secure channel setup procedures described in this 2496 document. 2498 Tunneled Remote ACP Neighbor requires two encapsulations: the 2499 configured tunnel and the secure channel inside of that tunnel. This 2500 makes it in general less desirable than Configured Remote ACP 2501 Neighbor. Benefits of tunnels are that it may be easier to implement 2502 because there is no change to the ACP functionality - just running it 2503 over a virtual (tunnel) interface instead of only physical 2504 interfaces. The tunnel itself may also provide PMTUD while the 2505 secure channel method may not. Or the tunnel mechanism is permitted/ 2506 possible through some firewall while the secure channel method may 2507 not. 2509 8.2.3. Summary 2511 Configured/Tunneled Remote ACP neighbors are less "indestructible" 2512 than L2 adjacent ACP neighbors based on link local addressing, since 2513 they depend on more correct data plane operations, such as routing 2514 and global addressing. 2516 Nevertheless, these options may be crucial to incrementally deploy 2517 the ACP, especially if it is meant to connect islands across the 2518 Internet. Implementations SHOULD support at least Tunneled Remote 2519 ACP Neighbors via GRE tunnels - which is likely the most common 2520 router-to-router tunneling protocol in use today. 2522 Future work could envisage an option where the edge devices of the L3 2523 cloud is configured to automatically forward ACP discovery messages 2524 to the right exit point. This optimisation is not considered in this 2525 document. 2527 9. Benefits (Informative) 2529 9.1. Self-Healing Properties 2531 The ACP is self-healing: 2533 o New neighbors will automatically join the ACP after successful 2534 validation and will become reachable using their unique ULA 2535 address across the ACP. 2537 o When any changes happen in the topology, the routing protocol used 2538 in the ACP will automatically adapt to the changes and will 2539 continue to provide reachability to all devices. 2541 o If an existing device gets revoked, it will automatically be 2542 denied access to the ACP as its domain certificate will be 2543 validated against a Certificate Revocation List during 2544 authentication. Since the revocation check is only done at the 2545 establishment of a new security association, existing ones are not 2546 automatically torn down. If an immediate disconnect is required, 2547 existing sessions to a freshly revoked device can be re-set. 2549 The ACP can also sustain network partitions and mergers. Practically 2550 all ACP operations are link local, where a network partition has no 2551 impact. Devices authenticate each other using the domain 2552 certificates to establish the ACP locally. Addressing inside the ACP 2553 remains unchanged, and the routing protocol inside both parts of the 2554 ACP will lead to two working (although partitioned) ACPs. 2556 There are few central dependencies: A certificate revocation list 2557 (CRL) may not be available during a network partition; a suitable 2558 policy to not immediately disconnect neighbors when no CRL is 2559 available can address this issue. Also, a registrar or Certificate 2560 Authority might not be available during a partition. This may delay 2561 renewal of certificates that are to expire in the future, and it may 2562 prevent the enrolment of new devices during the partition. 2564 After a network partition, a re-merge will just establish the 2565 previous status, certificates can be renewed, the CRL is available, 2566 and new devices can be enrolled everywhere. Since all devices use 2567 the same trust anchor, a re-merge will be smooth. 2569 Merging two networks with different trust anchors requires the trust 2570 anchors to mutually trust each other (for example, by cross-signing). 2571 As long as the domain names are different, the addressing will not 2572 overlap (see Section 6.10). 2574 It is also highly desirable for implementation of the ACP to be able 2575 to run it over interfaces that are administratively down. If this is 2576 not feasible, then it might instead be possible to request explicit 2577 operator override upon administrative actions that would 2578 administratively bring down an interface across whicht the ACP is 2579 running. Especially if bringing down the ACP is known to disconnect 2580 the operator from the device. For example any such down 2581 administrative action could perform a dependency check to see if the 2582 transport connection across which this action is performed is 2583 affected by the down action (with default RPL routing used, packet 2584 forwarding will be symmetric, so this is actually possible to check). 2586 9.2. Self-Protection Properties 2588 9.2.1. From the outside 2590 As explained in Section 6, the ACP is based on secure channels built 2591 between devices that have mutually authenticated each other with 2592 their domain certificates. The channels themselves are protected 2593 using standard encryption technologies like DTLS or IPsec which 2594 provide additional authentication during channel establishment, data 2595 integrity and data confidentiality protection of data inside the ACP 2596 and in addition, provide replay protection. 2598 An attacker will therefore not be able to join the ACP unless having 2599 a valid domain certificate, also packet injection and sniffing 2600 traffic will not be possible due to the security provided by the 2601 encryption protocol. 2603 The ACP also serves as protection (through authentication and 2604 encryption) for protocols relevant to OAM that may not have secured 2605 protocol stack options or where implementation or deployment of those 2606 options fails on some vendor/product/customer limitations. This 2607 includes protocols such as SNMP, NTP/PTP, DNS, DHCP, syslog, 2608 Radius/Diameter/Tacacs, IPFIX/Netflow - just to name a few. 2609 Protection via the ACP secure hop-by-hop channels for these protocols 2610 is meant to be only a stopgap though: The ultimate goal is for these 2611 and other protocols to use end-to-end encryption utilizing the domain 2612 certificate and rely on the ACP secure channels primarily for zero- 2613 touch reliable connectivity, but not primarily for security. 2615 The remaining attack vector would be to attack the underlying AN 2616 protocols themselves, either via directed attacks or by denial-of- 2617 service attacks. However, as the ACP is built using link-local IPv6 2618 address, remote attacks are impossible. The ULA addresses are only 2619 reachable inside the ACP context, therefore unreachable from the data 2620 plane. Also, the ACP protocols should be implemented to be attack 2621 resistant and not consume unnecessary resources even while under 2622 attack. 2624 9.2.2. From the inside 2626 The security model of the ACP is based on trusting all members of the 2627 group of devices that do receive an ACP domain certificate for the 2628 same domain. Attacks from the inside by a compromised group member 2629 are therefore the biggest challenge. 2631 Group members must overall the secured so that there are no easy way 2632 to compromise them, such as data plane accessible privilege level 2633 with simple passwords. This is a lot easier to do in devices whose 2634 software is designed from the ground up with security in mind than 2635 with legacy software based system where ACP is added on as another 2636 feature. 2638 As explained above, traffic across the ACP SHOULD still be end-to-end 2639 encrypted whenever possible. This includes traffic such as GRASP, 2640 EST and BRSKI inside the ACP. This minimizes man in the middle 2641 attacks by compromised ACP group members. Such attackers can not 2642 eavesdrop or modify communications, they can just filter them (which 2643 is unavoidable by any means). 2645 Further security can be achieved by constraining communication 2646 patterns inside the ACP, for example through roles that could be 2647 encoded into the domain certificates. This is subject for future 2648 work. 2650 9.3. The Administrator View 2652 An ACP is self-forming, self-managing and self-protecting, therefore 2653 has minimal dependencies on the administrator of the network. 2654 Specifically, since it is independent of configuration, there is no 2655 scope for configuration errors on the ACP itself. The administrator 2656 may have the option to enable or disable the entire approach, but 2657 detailed configuration is not possible. This means that the ACP must 2658 not be reflected in the running configuration of devices, except a 2659 possible on/off switch. 2661 While configuration is not possible, an administrator must have full 2662 visibility of the ACP and all its parameters, to be able to do 2663 trouble-shooting. Therefore, an ACP must support all show and debug 2664 options, as for any other network function. Specifically, a network 2665 management system or controller must be able to discover the ACP, and 2666 monitor its health. This visibility of ACP operations must clearly 2667 be separated from visibility of data plane so automated systems will 2668 never have to deal with ACP aspect unless they explicitly desire to 2669 do so. 2671 Since an ACP is self-protecting, a device not supporting the ACP, or 2672 without a valid domain certificate cannot connect to it. This means 2673 that by default a traditional controller or network management system 2674 cannot connect to an ACP. See Section 8.1.1 for more details on how 2675 to connect an NMS host into the ACP. 2677 10. Further Considerations (Informative) 2679 The following sections cover topics that are beyond the primary cope 2680 of this document (eg: bootstrap), that explain decisions made in this 2681 document (eg: choice of GRASP) or that explain desirable extensions 2682 to the behavior of the ACP that are not far enough worked out to be 2683 already standardized in this document. 2685 10.1. Domain Certificate provisioning / enrollment 2687 [I-D.ietf-anima-bootstrapping-keyinfra] (BRSKI) describes how devices 2688 with an IDevID certificate can securely and zero-touch enroll with a 2689 domain certificate to support the ACP. BRSKI also leverages the ACP 2690 to enable zero touch bootstrap of new devices across networks without 2691 any configuration requirements across the transit devices (eg: no 2692 DHCP/DS forwarding/server setup). This includes otherwise 2693 unconfigured networks as described in Section 3.2. Therefore BRSKI 2694 in conjunction with ACP provides for a secure and zero-touch 2695 management solution for complete networks. Devices supporting such 2696 an infrastructure (BRSKI and ACP) are called ANI devices (Autonomic 2697 Networking Infrstructure), see [I-D.ietf-anima-reference-model]. 2698 Devices that do not support an IDevID but only an (insecure) vendor 2699 specific Unique Device Identifier (UDI) or devices whose manufacturer 2700 does not support a MASA could use some future security reduced 2701 version of BRSKI. 2703 When BRSKI is used to provision a domain certificate (which is called 2704 enrollment), the registrar (acting as an EST server) MUST include the 2705 subjectAltName / rfc822Name encoded ACP address and domain name to 2706 the enrolling device (called pledge) via its response to the pledges 2707 EST CSR Attribute request that is mandatory in BRSKI. 2709 The Certificate Authority in an ACP network MUST not change this, and 2710 create the respective subjectAltName / rfc822Name in the certificate. 2711 The ACP nodes can therefore find their ACP address and domain using 2712 this field in the domain certificate, both for themselves, as well as 2713 for other nodes. 2715 The use of BRSKI in conjunction with the ACP can also help to further 2716 simplify maintenance and renewal of domain certificates. Instead of 2717 relying on CRL, the lifetime of certificates can be made extremely 2718 small, for example in the order of hours. When a device fails to 2719 connect to the ACP within its certificate lifetime, it can not 2720 connect to the ACP to renew its certificate across it, but it can 2721 still renew its certificate as an "enrolled/expired pledge" via the 2722 BRSKI bootstrap proxy. This requires only that the enhanced EST 2723 server that is part of BRSKI honors expired domain certificates and 2724 that the pledge first attempts to perform TLS authentication for 2725 BRSKI bootstrap with its expired domain certificate - and only 2726 reverts to its IDevID when this fails. This mechanism also replaces 2727 CRLs because the EST server (in conunction with the CA) would not 2728 renew revoked certficates - but in this scheme only the EST-server 2729 need to know which certificate was revoked. 2731 In the absence of BRSKI or less secure variants thereof, provisioning 2732 of certificates may involve one or more touches or non-standardized 2733 automation. Device vendors usually support provisioning of 2734 certificates into devices via PKCS#7 (see [RFC2315]) and may support 2735 this provisioning through vendor specific models via Netconf 2736 ([RFC6241]). If such devices also support Netconf Zerotouch 2737 ([I-D.ietf-netconf-zerotouch]) then this can be combined to zero- 2738 touch provisioning of domain certificates into devices. Unless there 2739 are equivalent integration of Netconf connections across the ACP as 2740 there is in BRSKI, this combination would not support zero-touch 2741 bootstrap across an unconfigured network though. 2743 10.2. ACP Neighbor discovery protocol selection 2745 This section discusses why GRASP DULL was choosen as the discovery 2746 protocol for L2 adjacent candidate ACP neighbors. The contenders 2747 considered where GRASP, mDNS or LLDP. 2749 10.2.1. LLDP 2751 LLDP (and Cisco's similar CDP) are example of L2 discovery protocols 2752 that terminate their messages on L2 ports. If those protocols would 2753 be chosen for ACP neighbor discovery, ACP neighbor discovery would 2754 therefore also terminate on L2 ports. This would prevent ACP 2755 construction over non-ACP capable but LLDP or CDP enabled L2 2756 switches. LLDP has extensions using different MAC addresses and this 2757 could have been an option for ACP discovery as well, but the 2758 additional required IEEE standardization and definition of a profile 2759 for such a modified instance of LLDP seemed to be more work than the 2760 benefit of "reusing the existing protocol" LLDP for this very simple 2761 purpose. 2763 10.2.2. mDNS and L2 support 2765 mDNS [RFC6762] with DNS-SD RRs (Resource Records) as defined in 2766 [RFC6763] is a key contender as an ACP discovery protocol. because it 2767 relies on link-local IP multicast, it does operates at the subnet 2768 level, and is also found in L2 switches. The authors of this 2769 document are not aware of mDNS implementation that terminate their 2770 mDNS messages on L2 ports instead of the subnet level. If mDNS was 2771 used as the ACP discovery mechanism on an ACP capable (L3)/L2 switch 2772 as outlined in Section 7, then this would be necessary to implement. 2773 It is likely that termination of mDNS messages could only be applied 2774 to all mDNS messages from such a port, which would then make it 2775 necessary to software forward any non-ACP related mDNS messages to 2776 maintain prior non-ACP mDNS functionality. Adding support for ACP 2777 into such L2 switches with mDNS could therefore create regression 2778 problems for prior mDNS functionality on those devices. With low 2779 performance of software forwarding in many L2 switches, this could 2780 also make the ACP risky to support on such L2 switches. 2782 10.2.3. Why DULL GRASP 2784 LLDP was not considered because of the above mentioned issues. mDNS 2785 was not selected because of the above L2 mDNS considerations and 2786 because of the following additional points: 2788 If mDNS was not already existing in a device, it would be more work 2789 to implement than DULL GRASP, and if an existing implementation of 2790 mDNS was used, it would likely be more code space than a separate 2791 implementation of DULL GRASP or a shared implementation of DULL GRASP 2792 and GRASP in the ACP. 2794 10.3. Choice of routing protocol (RPL) 2796 This Appendix explains why RPL - "IPv6 Routing Protocol for Low-Power 2797 and Lossy Networks ([RFC6550] was chosen as the default (and in this 2798 specification only) routing protocol for the ACP. The choice and 2799 above explained profile was derived from a pre-standard 2800 implementation of ACP that was successfully deployed in operational 2801 networks. 2803 Requirements for routing in the ACP are: 2805 o Self-management: The ACP must build automatically, without human 2806 intervention. Therefore routing protocol must also work 2807 completely automatically. RPL is a simple, self-managing 2808 protocol, which does not require zones or areas; it is also self- 2809 configuring, since configuration is carried as part of the 2810 protocol (see Section 6.7.6 of [RFC6550]). 2812 o Scale: The ACP builds over an entire domain, which could be a 2813 large enterprise or service provider network. The routing 2814 protocol must therefore support domains of 100,000 nodes or more, 2815 ideally without the need for zoning or separation into areas. RPL 2816 has this scale property. This is based on extensive use of 2817 default routing. RPL also has other scalability improvements, 2818 such as selecting only a subset of peers instead of all possible 2819 ones, and trickle support for information synchronisation. 2821 o Low resource consumption: The ACP supports traditional network 2822 infrastructure, thus runs in addition to traditional protocols. 2823 The ACP, and specifically the routing protocol must have low 2824 resource consumption both in terms of memory and CPU requirements. 2825 Specifically, at edge nodes, where memory and CPU are scarce, 2826 consumption should be minimal. RPL builds a destination-oriented 2827 directed acyclic graph (DODAG), where the main resource 2828 consumption is at the root of the DODAG. The closer to the edge 2829 of the network, the less state needs to be maintained. This 2830 adapts nicely to the typical network design. Also, all changes 2831 below a common parent node are kept below that parent node. 2833 o Support for unstructured address space: In the Autonomic 2834 Networking Infrastructure, node addresses are identifiers, and may 2835 not be assigned in a topological way. Also, nodes may move 2836 topologically, without changing their address. Therefore, the 2837 routing protocol must support completely unstructured address 2838 space. RPL is specifically made for mobile ad-hoc networks, with 2839 no assumptions on topologically aligned addressing. 2841 o Modularity: To keep the initial implementation small, yet allow 2842 later for more complex methods, it is highly desirable that the 2843 routing protocol has a simple base functionality, but can import 2844 new functional modules if needed. RPL has this property with the 2845 concept of "objective function", which is a plugin to modify 2846 routing behaviour. 2848 o Extensibility: Since the Autonomic Networking Infrastructure is a 2849 new concept, it is likely that changes in the way of operation 2850 will happen over time. RPL allows for new objective functions to 2851 be introduced later, which allow changes to the way the routing 2852 protocol creates the DAGs. 2854 o Multi-topology support: It may become necessary in the future to 2855 support more than one DODAG for different purposes, using 2856 different objective functions. RPL allow for the creation of 2857 several parallel DODAGs, should this be required. This could be 2858 used to create different topologies to reach different roots. 2860 o No need for path optimisation: RPL does not necessarily compute 2861 the optimal path between any two nodes. However, the ACP does not 2862 require this today, since it carries mainly non-delay-sensitive 2863 feedback loops. It is possible that different optimisation 2864 schemes become necessary in the future, but RPL can be expanded 2865 (see point "Extensibility" above). 2867 10.4. Extending ACP channel negotiation (via GRASP) 2869 The mechanism described in the normative part of this document to 2870 support multiple different ACP secure channel protocols without a 2871 single network wide MTI protocol is important to allow extending 2872 secure ACP channel protocols beyond what is specified in this 2873 document, but it will run into problem if it would be used for 2874 multiple protocols: 2876 The need to potentially have multiple of these security associations 2877 even temporarily run in parallel to determine which of them works 2878 best does not support the most lightweight implementation options. 2880 The simple policy of letting one side (Alice) decide what is best may 2881 not lead to the mutual best result. 2883 The two limitations can easier be solved if the solution was more 2884 modular and as few as possible initial secure channel negotiation 2885 protocols would be used, and these protocols would then take on the 2886 responsibility to support more flexible objectives to negotiate the 2887 mutually preferred ACP security channel protocol. 2889 IKEv2 is the IETF standard protocol to negotiate network security 2890 associations. It is meant to be extensible, but it is unclear 2891 whether it would be feasible to extend IKEv2 to support possible 2892 future requirements for ACP secure channel negotiation: 2894 Consider the simple case where the use of native IPsec vs. IPsec via 2895 GRE is to be negotiated and the objective is the maximum throughput. 2896 Both sides would indicate some agreed upon performance metric and the 2897 preferred encapsulation is the one with the higher performance of the 2898 slower side. IKEv2 does not support negotiation with this objective. 2900 Consider dTLS and some form of 802.1AE (MacSEC) are to be added as 2901 negotiation options - and the performance objective should work 2902 across all IPsec, dDTLS and 802.1AE options. In the case of MacSEC, 2903 the negotiation would also need to determine a key for the peering. 2904 It is unclear if it would be even appropriate to consider extending 2905 the scope of negotiation in IKEv2 to those cases. Even if feasible 2906 to define, it is unclear if implementations of IKEv2 would be eager 2907 to adopt those type of extension given the long cycles of security 2908 testing that necessarily goes along with core security protocols such 2909 as IKEv2 implementations. 2911 A more modular alternative to extending IKEv2 could be to layer a 2912 modular negotiation mechanism on top of the multitide of existing or 2913 possible future secure channel protocols. For this, GRASP over TLS 2914 could be considered as a first ACP secure channel negotiation 2915 protocol. The following are initial considerations for such an 2916 approach. A full specification is subject to a separate document: 2918 To explicitly allow negotiation of the ACP channel protocol, GRASP 2919 over a TLS connection using the GRASP_LISTEN_PORT and the devices and 2920 peers link-local IPv6 address is used. When Alice and Bob support 2921 GRASP negotiation, they do prefer it over any other non-explicitly 2922 negotiated security association protocol and should wait trying any 2923 non-negotiated ACP channel protocol until after it is clear that 2924 GRASP/TLS will not work to the peer. 2926 When Alice and Bob successfully establish the GRASP/TSL session, they 2927 will negotiate the channel mechanism to use using objectives such as 2928 performance and perceived quality of the security. After agreeing on 2929 a channel mechanism, Alice and Bob start the selected Channel 2930 protocol. Once the secure channel protocol is successfully running, 2931 the GRASP/TLS connection can be kept alive or timed out as long as 2932 the selected channel protocol has a secure association between Alice 2933 and Bob. When it terminates, it needs to be re-negotiated via GRASP/ 2934 TLS. 2936 Notes: 2938 o Negotiation of a channel type may require IANA assignments of code 2939 points. 2941 o TLS is subject to reset attacks, which IKEv2 is not. Normally, 2942 ACP connections (as specified in this document) will be over link- 2943 local addresses so the attack surface for this one issue in TCP 2944 should be reduced (note that this may not be true when ACP is 2945 tunneled as described in Section 8.2.2. 2947 o GRASP packets received inside a TLS connection established for 2948 GRASP/TLS ACP negotiation are assigned to a separate GRASP domain 2949 unique to that TLS connection. 2951 10.5. CAs, domains and routing subdomains 2953 There is a wide range of setting up different ACP solution by 2954 appropriately using CAs and the domain and rsub elements in the ACP 2955 information field of the domain certificate. We summarize these 2956 options here as they have been explained in different parts of the 2957 document in before and discuss possible and desirable extensions: 2959 An ACP domain is the set of all ACP devices using certificates from 2960 the same CA using the same domain field. GRASP inside the ACP is run 2961 across all transitively connected ACP devices in a domain. 2963 The rsub element in the ACP information field primarily allows to use 2964 addresses from different ULA prefixes. One use case is to create 2965 multiple networks that initially may be separated, but where it 2966 should be possible to connect them without further extensions to ACP 2967 when necessary. 2969 Another use case for routing subdomains is as the starting point for 2970 structuring routing inside an ACP. For example, different routing 2971 subdomains could run different routing protocols or different 2972 instances of RPL and auto-aggregation / distribution of routes could 2973 be done across inter routing subdomain ACP channels based on 2974 negotiation (eg: via GRASP). This is subject for further work. 2976 RPL scales very well. It is not necessary to use multiple routing 2977 subdomains to scale autonomic domains in a way it would be possible 2978 if other routing protocols where used. They exist only as options 2979 for the above mentioned reasons. 2981 If different ACP domains are to be created that should not allow to 2982 connect to each other by default, these ACP domains simply need to 2983 have different domain elements in the ACP information field. These 2984 domain elements can be arbitrary, including subdomains of one 2985 another: Domains "example.com" and "research.example.com" are 2986 separate domains if both are domain elements in the ACP information 2987 element of certificates. 2989 It is not necessary to have a sparate CA for different ACP domains: 2990 an operator can use a single CA to sign certificates for multiple ACP 2991 domains that are not allowed to connect to each other because the 2992 checks for ACP adjacencies includes comparison of the domain part. 2994 If multiple independent networks choose the same domain name but had 2995 their own CA, these would not form a single ACP domain because of CA 2996 mismatch. Therefore there is no problem in choosing domain names 2997 that are potentially also used by others. Nevertheless it is highly 2998 recommended to use domain names that one can have high probability to 2999 be unique. It is recommended to use domain names that start with a 3000 DNS domain names owned by the assigning organization and unique 3001 within it. For example "acp.example.com" if you own "example.com". 3003 Future extensions, primarily through intent can create more flexible 3004 options how to build ACP domains. 3006 Intent could modify the ACP connection check to permit connections 3007 between different domains. 3009 If different domains use the same CA one would change the ACP setup 3010 to permit for the ACP to be established between the two ACP devices, 3011 but no routing nor ACP GRASP to be built across this adjacency. The 3012 main difference over routing subdomains is to not permit for the ACP 3013 GRASP instance to be build across the adjacency. Instead, one would 3014 only build a point to point GRASP instance between those peers to 3015 negotiate what type of exchanges are desired across that connection. 3016 This would include routing negotiation, how much GRASP information to 3017 transit and what data-plane forwarding should be done. This approach 3018 could also allow for for Intent to only be injected into the network 3019 from one side and propagate via this GRASP connection. 3021 If different domains have different CAs, they should start to trust 3022 each other by intent injected into both domains that would add the 3023 other domains CA as a trust point during the ACP connection setup - 3024 and then following up with the previous point of inter-domain 3025 connections across domains with the same CA (eg: GRASP negotiation). 3027 11. RFC4291/RFC4193 Updates Considerations 3029 This document may be considered to be updating the IPv6 addressing 3030 architecture ([RFC4291]) and/or the Unique Local IPv6 Unicast 3031 addresses ([RFC4193]) depending on how strict specific statements in 3032 those specs are to be interpreted. This section summarized and 3033 explains the necessity and benefits of these changes. The normative 3034 parts of this document cover the actual updates. 3036 ACP addresses (Section 6.10) are used by network devices supporting 3037 the ACP. They are assigned during bootstrap of the device or initial 3038 provisioning of the ACP. They are encoded in the Domain Certificate 3039 of the device and are primarily used internally within the network 3040 device. In that role they can be thought of as loopback addresses. 3042 Each ACP domain assigns ACP addresses from one or more ULA prefixes. 3043 Within an ACP network, addresses are assigned by nodes called 3044 registrars. A unique Registrar-ID(entifier) is used in ACP addresses 3045 to allow multiple registrars to assign addresses autonomously and 3046 uncoordinated from each other. Typically these Registrar-IDs are 3047 derived from the IEEE 802 48-bit MAC addresses of registrars. 3049 In the ACP Zone Addressing Sub-Scheme (Section 6.10.3), the registrar 3050 assigns a unique 15 bit value to an ACP device. The ACP address has 3051 a 64-bit Device-ID(entifier) composed of the 48-bit Registrar-ID, the 3052 registrar assigned 15-bit Device-Number and 1 V(irtualization) bit 3053 that allows for an ACP device to have two addresses. 3055 The 64-bit Device-Identifier in the ACP Zone Addressing Sub-Scheme 3056 matches the 64 bit Interface Identifier (IID) address part as 3057 specified in RFC4291 section 2.5.1. IIDs are unique across ACP 3058 devices, but all ACP devices with the same ULA prefix that use the 3059 ACP Zone Addressing Sub-Scheme will share the same subnet prefix 3060 (according to the definition of that term in RFC4291). Each ACP 3061 device injects a /127 route into the ACP routing table to cover its 3062 two assigned addresses (V(irtual) bit being 0 or 1). This approach 3063 is used because these ACP addresses are identifiers and not locators. 3064 The ACP device can connect anywhere in the autonomic domain without 3065 having to change its addresses. A lightweight, highly scaleable 3066 routing protocol (RPL) is used to allow for large scale ACP networks. 3068 It is possible, that this scheme constitutes an update to RFC4191 3069 because the same 64 bit subnet prefix is used across many ACP 3070 devices. The ACP Zone addressing Sub-Scheme is very similar to the 3071 common operational practices of assigning /128 loopback addresses to 3072 network devices from the same /48 or /64 subnet prefix. 3074 In the ACP Vlong Addressing Sub-Scheme (Section 6.10.5), the address 3075 elements are the same as described for the Zone Addressing Sub- 3076 Scheme, but the V field is expanded from 1 bit to 8 or 16 bits. The 3077 ACP device with ACP Vlong addressing therefore injects /120 or /112 3078 prefixes into the ACP routing table to cover its internal addresses. 3080 The goal for the 8 or 16-bit addresses available to an ACP device in 3081 this scheme is to assign them as required to software components, 3082 which in autonomic networking are called ASA (Autonomic Service 3083 Agents). It could equally be used for existing software components 3084 such as VNFs (Virtual Networking Functions). The ACP interface would 3085 then be the out-of-band management interface of such a VNF software 3086 component. It should especially be possible to use these software 3087 components in a variety of contexts to allow standardized modular 3088 system composition: Native applications (in some VRF context if 3089 available), containers, virtual machines or other future ones. To 3090 modularily compose a system with containers and virtual machines and 3091 avoid problems such as port space collision or NAT, it is necessary 3092 not only to assign separate addresses to those contexts, but also to 3093 use the notion of virtual interfaces between these contexts to 3094 compose the system. 3096 In practical terms, the ACP should be enabled to create from its /8 3097 or /16 prefix one or more device internal virtual subnets and to 3098 start software components connected to those virtual subnets. 3099 Ideally, these software components should be able to autoconfigure 3100 their addresses on these virtual interfaces. Future work has to 3101 determine whether this address autoconfiguration for the virtual 3102 interface is best done with DHCPv6, if SLAAC should be recommended 3103 for these /8 or /16 virtual interfaces, or if some additional 3104 standardized method would be required. 3106 In the ACP Vlong Addressing scheme, the Device-ID does not match the 3107 RFC4291/RFC4193 64 bith length for the Interface Identifier, so this 3108 addressing Sub-Scheme in the ACP is an update to both standards. 3110 This document also specifies the workaround solution of exposing the 3111 ACP on physical interfaces in support of adoption by existing 3112 hardware and software solutions. A NOC based NMS host could for 3113 example be configured with a second physical interface connecting to 3114 an ACP device that exposes the ACP to that NMS host (called ACP edge 3115 device). The desired evolution of this workaround is that those two 3116 functions would merge into a single device, for example by making the 3117 ACP router a container/virtual machine inside the NMS host or vice 3118 versa. The addressing for those physical interfaces allows for 3119 manually configured address prefixes but it could be fully autonomous 3120 if it could leverage the Vlong addressing format. That would result 3121 in a non /64 IID boundary on those external interfaces (but instead 3122 in /112 or /120 subnet prefixes). 3124 Note that both in the internal as well as the workaround external use 3125 of ACP addresses, all ACP addresses are meant to be used exclusively 3126 by components that are part of network control and OAM, but not for 3127 network users such as normal hosts. This implies that for example no 3128 requirements for privacy addressing have been identified for ACP 3129 addresses. 3131 12. Security Considerations 3133 An ACP is self-protecting and there is no need to apply configuration 3134 to make it secure. Its security therefore does not depend on 3135 configuration. 3137 However, the security of the ACP depends on a number of other 3138 factors: 3140 o The usage of domain certificates depends on a valid supporting PKI 3141 infrastructure. If the chain of trust of this PKI infrastructure 3142 is compromised, the security of the ACP is also compromised. This 3143 is typically under the control of the network administrator. 3145 o Security can be compromised by implementation errors (bugs), as in 3146 all products. 3148 There is no prevention of source-address spoofing inside the ACP. 3149 This implies that if an attacker gains access to the ACP, it can 3150 spoof all addresses inside the ACP and fake messages from any other 3151 device. 3153 Fundamentally, security depends on correct operation, implementation 3154 and architecture. Autonomic approaches such as the ACP largely 3155 eliminate the dependency on correct operation; implementation and 3156 architectural mistakes are still possible, as in all networking 3157 technologies. 3159 13. IANA Considerations 3161 14. Acknowledgements 3163 This work originated from an Autonomic Networking project at Cisco 3164 Systems, which started in early 2010. Many people contributed to 3165 this project and the idea of the Autonomic Control Plane, amongst 3166 which (in alphabetical order): Ignas Bagdonas, Parag Bhide, Balaji 3167 BL, Alex Clemm, Yves Hertoghs, Bruno Klauser, Max Pritikin, Michael 3168 Richardson, Ravi Kumar Vadapalli. 3170 Special thanks to Pascal Thubert and Michael Richardson to provide 3171 the details for the recommendations of the use of RPL in the ACP 3173 Further input and suggestions were received from: Rene Struik, Brian 3174 Carpenter, Benoit Claise. 3176 15. Change log [RFC Editor: Please remove] 3178 15.1. Initial version 3180 First version of this document: draft-behringer-autonomic-control- 3181 plane 3183 15.2. draft-behringer-anima-autonomic-control-plane-00 3185 Initial version of the anima document; only minor edits. 3187 15.3. draft-behringer-anima-autonomic-control-plane-01 3189 o Clarified that the ACP should be based on, and support only IPv6. 3191 o Clarified in intro that ACP is for both, between devices, as well 3192 as for access from a central entity, such as an NMS. 3194 o Added a section on how to connect an NMS system. 3196 o Clarified the hop-by-hop crypto nature of the ACP. 3198 o Added several references to GDNP as a candidate protocol. 3200 o Added a discussion on network split and merge. Although, this 3201 should probably go into the certificate management story longer 3202 term. 3204 15.4. draft-behringer-anima-autonomic-control-plane-02 3206 Addresses (numerous) comments from Brian Carpenter. See mailing list 3207 for details. The most important changes are: 3209 o Introduced a new section "overview", to ease the understanding of 3210 the approach. 3212 o Merged the previous "problem statement" and "use case" sections 3213 into a mostly re-written "use cases" section, since they were 3214 overlapping. 3216 o Clarified the relationship with draft-ietf-anima-stable- 3217 connectivity 3219 15.5. draft-behringer-anima-autonomic-control-plane-03 3221 o Took out requirement for IPv6 --> that's in the reference doc. 3223 o Added requirement section. 3225 o Changed focus: more focus on autonomic functions, not only virtual 3226 out of band. This goes a bit throughout the document, starting 3227 with a changed abstract and intro. 3229 15.6. draft-ietf-anima-autonomic-control-plane-00 3231 No changes; re-submitted as WG document. 3233 15.7. draft-ietf-anima-autonomic-control-plane-01 3235 o Added some paragraphs in addressing section on "why IPv6 only", to 3236 reflect the discussion on the list. 3238 o Moved the data-plane ACP out of the main document, into an 3239 appendix. The focus is now the virtually separated ACP, since it 3240 has significant advantages, and isn't much harder to do. 3242 o Changed the self-creation algorithm: Part of the initial steps go 3243 into the reference document. This document now assumes an 3244 adjacency table, and domain certificate. How those get onto the 3245 device is outside scope for this document. 3247 o Created a new section 6 "workarounds for non-autonomic nodes", and 3248 put the previous controller section (5.9) into this new section. 3249 Now, section 5 is "autonomic only", and section 6 explains what to 3250 do with non-autonomic stuff. Much cleaner now. 3252 o Added an appendix explaining the choice of RPL as a routing 3253 protocol. 3255 o Formalised the creation process a bit more. Now, we create a 3256 "candidate peer list" from the adjacency table, and form the ACP 3257 with those candidates. Also it explains now better that policy 3258 (Intent) can influence the peer selection. (section 4 and 5) 3260 o Introduce a section for the capability negotiation protocol 3261 (section 7). This needs to be worked out in more detail. This 3262 will likely be based on GRASP. 3264 o Introduce a new parameter: ACP tunnel type. And defines it in the 3265 IANA considerations section. Suggest GRE protected with IPSec 3266 transport mode as the default tunnel type. 3268 o Updated links, lots of small edits. 3270 15.8. draft-ietf-anima-autonomic-control-plane-02 3272 o Added explicitly text for the ACP channel negotiation. 3274 o Merged draft-behringer-anima-autonomic-addressing-02 into this 3275 document, as suggested by WG chairs. 3277 15.9. draft-ietf-anima-autonomic-control-plane-03 3279 o Changed Neighbor discovery protocol from GRASP to mDNS. Bootstrap 3280 protocol team decided to go with mDNS to discover bootstrap proxy, 3281 and ACP should be consistent with this. Reasons to go with mDNS 3282 in bootstrap were a) Bootstrap should be reuseable also outside of 3283 full anima solutions and introduce as few as possible new 3284 elements. mDNS was considered well-known and very-likely even pre- 3285 existing in low-end devices (IoT). b) Using GRASP both for the 3286 insecure neighbor discovery and secure ACP operatations raises the 3287 risk of introducing security issues through implementation issues/ 3288 non-isolation between those two instances of GRASP. 3290 o Shortened the section on GRASP instances, because with mDNS being 3291 used for discovery, there is no insecure GRASP session any longer, 3292 simplifying the GRASP considerations. 3294 o Added certificate requirements for ANIMA in section 5.1.1, 3295 specifically how the ANIMA information is encoded in 3296 subjectAltName. 3298 o Deleted the appendix on "ACP without separation", as originally 3299 planned, and the paragraph in the main text referring to it. 3301 o Deleted one sub-addressing scheme, focusing on a single scheme 3302 now. 3304 o Included information on how ANIMA information must be encoded in 3305 the domain certificate in section "preconditions". 3307 o Editorial changes, updated draft references, etc. 3309 15.10. draft-ietf-anima-autonomic-control-plane-04 3311 Changed discovery of ACP neighbor back from mDNS to GRASP after 3312 revisiting the L2 problem. Described problem in discovery section 3313 itself to justify. Added text to explain how ACP discovery relates 3314 to BRSKY (bootstrap) discovery and pointed to Michael Richardsons 3315 draft detailing it. Removed appendix section that contained the 3316 original explanations why GRASP would be useful (current text is 3317 meant to be better). 3319 15.11. draft-ietf-anima-autonomic-control-plane-05 3321 o Section 5.3 (candidate ACP neighbor selection): Add that Intent 3322 can override only AFTER an initial default ACP establishment. 3324 o Section 6.10.1 (addressing): State that addresses in the ACP are 3325 permanent, and do not support temporary addresses as defined in 3326 RFC4941. 3328 o Modified Section 6.3 to point to the GRASP objective defined in 3329 draft-carpenter-anima-ani-objectives. (and added that reference) 3331 o Section 6.10.2: changed from MD5 for calculating the first 40 bits 3332 to SHA256; reason is MD5 should not be used any more. 3334 o Added address sub-scheme to the IANA section. 3336 o Made the routing section more prescriptive. 3338 o Clarified in Section 8.1.1 the ACP Connect port, and defined that 3339 term "ACP Connect". 3341 o Section 8.2: Added some thoughts (from mcr) on how traversing a L3 3342 cloud could be automated. 3344 o Added a CRL check in Section 6.7. 3346 o Added a note on the possibility of source-address spoofing into 3347 the security considerations section. 3349 o Other editoral changes, including those proposed by Michael 3350 Richardson on 30 Nov 2016 (see ANIMA list). 3352 15.12. draft-ietf-anima-autonomic-control-plane-06 3354 o Added proposed RPL profile. 3356 o detailed dTLS profile - dTLS with any additional negotiation/ 3357 signaling channel. 3359 o Fixed up text for ACP/GRE encap. Removed text claiming its 3360 incompatible with non-GRE IPsec and detailled it. 3362 o Added text to suggest admin down interfaces should still run ACP. 3364 15.13. draft-ietf-anima-autonomic-control-plane-07 3366 o Changed author association. 3368 o Improved ACP connect setion (after confusion about term came up in 3369 the stable connectivity draft review). Added picture, defined 3370 complete terminology. 3372 o Moved ACP channel negotiation from normative section to appendix 3373 because it can in the timeline of this document not be fully 3374 specified to be implementable. Aka: work for future document. 3375 That work would also need to include analysing IKEv2 and describin 3376 the difference of a proposed GRASP/TLS solution to it. 3378 o Removed IANA request to allocate registry for GRASP/TLS. This 3379 would come with future draft (see above). 3381 o Gave the name "ACP information field" to the field in the 3382 certificate carrying the ACP address and domain name. 3384 o Changed the rules for mutual authentication of certificates to 3385 rely on the domain in the ACP information field of the certificate 3386 instead of the OU in the certificate. Also renewed the text 3387 pointing out that the ACP information field in the certificate is 3388 meant to be in a form that it does not disturb other uses of the 3389 certificate. As long as the ACP expected to rely on a common OU 3390 across all certificates in a domain, this was not really true: 3391 Other uses of the certificates might require different OUs for 3392 different areas/type of devices. With the rules in this draft 3393 version, the ACP authentication does not rely on any other fields 3394 in the certificate. 3396 o Added an extension field to the ACP information field so that in 3397 the future additional fields like a subdomain could be inserted. 3398 An example using such a subdomain field was added to the pre- 3399 existing text suggesting sub-domains. This approach is necessary 3400 so that there can be a single (main) domain in the ACP information 3401 field, because that is used for mutual authentication of the 3402 certificate. Also clarified that only the register(s) SHOULD/MUST 3403 use that the ACP address was generated from the domain name - so 3404 that we can easier extend change this in extensions. 3406 o Took the text for the GRASP discovery of ACP neighbors from Brians 3407 grasp-ani-objectives draft. Alas, that draft was behind the 3408 latest GRASP draft, so i had to overhaul. The mayor change is to 3409 describe in the ACP draft the whole format of the M_FLOOD message 3410 (and not only the actual objective). This should make it a lot 3411 easier to read (without having to go back and forth to the GRASP 3412 RFC/draft). It was also necessary because the locator in the 3413 M_FLOOD messages has an important role and its not coded inside 3414 the objective. The specification of how to format the M_FLOOD 3415 message shuold now be complete, the text may be some duplicate 3416 with the DULL specificateion in GRASP, but no contradiction. 3418 o One of the main outcomes of reworking the GRASP section was the 3419 notion that GRASP announces both the candidate peers IPv6 link 3420 local address but also the support ACP security protocol including 3421 the port it is running on. In the past we shied away from using 3422 this information because it is not secured, but i think the 3423 additional attack vectors possible by using this information are 3424 negligible: If an attacker on an L2 subnet can fake another 3425 devices GRASP message then it can already provide a similar amount 3426 of attack by purely faking the link-local address. 3428 o Removed the section on discovery and BRSKI. This can be revived 3429 in the BRSKI document, but it seems mood given how we did remove 3430 mDNS from the latest BRSKI document (aka: this section discussed 3431 discrepancies between GRASP and mDNS discovery which should not 3432 exist anymore with latest BRSKI. 3434 o Tried to resolve the EDNOTE about CRL vs. OCSP by pointing out we 3435 do not specify which one is to be used but that the ACP should be 3436 used to reach the URL included in the certificate to get to the 3437 CRL storage or OCSP server. 3439 o Changed ACP via IPsec to ACP via IKEv2 and restructured the 3440 sections to make IPsec native and IPsec via GRE subsections. 3442 o No need for any assigned dTLS port if ACP is run across dTLS 3443 because it is signalled via GRASP. 3445 15.14. draft-ietf-anima-autonomic-control-plane-08 3447 Modified mentioning of BRSKI to make it consistent with current 3448 (07/2017) target for BRSKI: MASA and IDevID are mandatory. Devices 3449 with only insecure UDI would need a security reduced variant of 3450 BRSKI. Also added mentioning of Netconf Zerotouch. Made BRSKI non- 3451 normative for ACP because wrt. ACP it is just one option how the 3452 domain certificate can be provisioned. Instead, BRSKI is mandatory 3453 when a device implements ANI which is ACP+BRSKI. 3455 Enhanced text for ACP across tunnels to decribe two options: one 3456 across configured tunnels (GRE, IPinIP etc) a more efficient one via 3457 directed DULL. 3459 Moved decription of BRSKI to appendex to emphasize that BRSKI is not 3460 a (normative) dependency of GRASP, enhanced text to indicate other 3461 options how Domain Certificates can be provisioned. 3463 Added terminology section. 3465 Separated references into normative and non-normative. 3467 Enhanced section about ACP via "tunnels". Defined an option to run 3468 ACP secure channel without an outer tunnel, discussed PMTU, benefits 3469 of tunneling, potential of using this with BRSKI, made ACP via GREP a 3470 SHOULD requirement. 3472 Moved appendix sections up before IANA section because there where 3473 concerns about appendices to be to far on the bottom to be read. 3474 Added (Informative) / (Normative) to section titles to clarify which 3475 sections are informative and which are normative 3477 Moved explanation of ACP with L2 from precondition to separate 3478 section before workarounds, made it instructive enough to explain how 3479 to implement ACP on L2 ports for L3/L2 switches and made this part of 3480 normative requirement (L2/L3 switches SHOULD support this). 3482 Rewrote section "GRASP in the ACP" to define GRASP in ACP as 3483 mandatory (and why), and define the ACP as security and transport 3484 substrate to GRASP in ACP. And how it works. 3486 Enhanced "self-protection" properties section: protect legacy 3487 management protocols. Security in ACP is for protection from outside 3488 and those legacy protocols. Otherwise need end-to-end encryption 3489 also inside ACP, eg: with domain certificate. 3491 Enhanced initial domain certificate section to include requirements 3492 for maintenance (renewal/revocation) of certificates. Added 3493 explanation to BRSKI informative section how to handle very short 3494 lived certificates (renewal via BRSKI with expired cert). 3496 Modified the encoding of the ACP address to better fit RFC822 simple 3497 local-parts (":" as required by RFC5952 are not permitted in simple 3498 dot-atoms according to RFC5322. Removed reference to RFC5952 as its 3499 now not needed anymore. 3501 Introduced a sub-domain field in the ACP information in the 3502 certificate to allow defining such subdomains with depending on 3503 future Intent definitions. It also makes it clear what the "main 3504 domain" is. Scheme is called "routing subdomain" to have a unique 3505 name. 3507 Added V8 (now called Vlong) addressing sub-scheme according to 3508 suggestion from mcr in his mail from 30 Nov 2016 3509 (https://mailarchive.ietf.org/arch/msg/anima/ 3510 nZpEphrTqDCBdzsKMpaIn2gsIzI). Also modified the explanation of the 3511 single V bit in the first sub-scheme now renamed to Zone sub-scheme 3512 to distinguish it. 3514 15.15. draft-ietf-anima-autonomic-control-plane-09 3516 Added reference to RFC4191 and explained how it should be used on ACP 3517 edge routers to allow autoconfiguration of routing by NMS hosts. 3518 This came after review of stable connectivity draft where ACP connect 3519 is being referred to. 3521 V8 addressing Sub-Scheme was modified to allow not only /8 device- 3522 local address space but also /16. This was in response to the 3523 possible need to have maybe as much as 2^12 local addresses for 3524 future encaps in BRSKI like IPinIP. It also would allow fully 3525 autonomic address assignment for ACP connect interfaces from this 3526 local address space (on an ACP edge device), subject to approval of 3527 the implied update to rfc4291/rfc4193 (IID length). Changed name to 3528 Vlong addressing sub-scheme. 3530 Added text in response to Brian Carpenters review of draft-ietf- 3531 anima-stable-connectivity-04. The stable connectivity draft was 3532 vaguely describing ACP connect behavior that is better standardized 3533 in this ACP draft. 3535 o Added new ACP "Manual" addressing sub-scheme with /64 subnets for 3536 use with ACP connect interfaces. Being covered by the ACP ULA 3537 prefix, these subnets do not require additional routing entries 3538 for NMS hosts. They also are fully 64-bit IID length compliant 3539 and therefore not subject to 4191bis considerations. And they 3540 avoid that operators manually assign prefixes from the ACP ULA 3541 prefixes that might later be assigned autonomiously. 3543 o ACP connect auto-configuration: Defined that ACP edge devices, NMS 3544 hosts should use RFC4191 to automatically learn ACP prefixes. 3545 This is especially necessary when the ACP uses multiple ULA 3546 prefixes (via eg: the rsub domain certificate option), or if ACP 3547 connect subinterfaces use manually configured prefixes NOT covered 3548 by the ACP ULA prefixes. 3550 o Explained how rfc6724 is (only) sufficient when the NMS host has a 3551 separate ACP connect and data plane interface. But not when there 3552 is a single interface. 3554 o Added a separate subsection to talk about "software" instead of 3555 "NMS hosts" connecting to the ACP via the "ACP connect" method. 3556 The reason is to point out that the "ACP connect" method is not 3557 only a workaround (for NMS hosts), but an actual desirable long 3558 term architectural component to modularily build software (eg: ASA 3559 or OAM for VNF) into ACP devices. 3561 o Added a section to define how to run ACP connect across the same 3562 interface as the Data Plane. This turns out to be quite 3563 challenging because we only want to rely on existing standards for 3564 the network stack in the NMS host/software and only define what 3565 features the ACP edge device needs. 3567 o Added section about use of GRASP over ACP connect. 3569 o Added text to indicate packet processing/filtering for security: 3570 filter incorrect packets arriving on ACP connect interfaces, 3571 diagnose on RPL root packets to incorrect destination address (not 3572 in ACP connect section, but because of it). 3574 o Reaffirm security goal of ACP: Do not permit non-ACP routers into 3575 ACP routing domain. 3577 Made this ACP document be an update to RFC4291 and RFC4193. At the 3578 core, some of the ACP addressing sub-schemes do effectively not use 3579 64-bit IIDs as required by RFC4191 and debated in rfc4191bis. During 3580 6man in prague, it was suggested that all documents that do not do 3581 this should be classified as such updates. Add a rather long section 3582 that summarizes the relevant parts of ACP addressing and usage and. 3583 Aka: This section is meant to be the primary review section for 3584 readers interested in these changes (eg: 6man WG.). 3586 Added changes from Michael Richardsons review https://github.com/ 3587 anima-wg/autonomic-control-plane/pull/3/commits, textual and: 3589 o ACP discovery inside ACP is bad *doh*!. 3591 o Better CA trust and revocation sentences. 3593 o More details about RPL behavior in ACP. 3595 o blackhole route to avoid loops in RPL. 3597 Added requirement to terminate ACP channels upon cert expiry/ 3598 revocation. 3600 Added fixes from 08-mcr-review-reply.txt (on github): 3602 o AN Domain Names are FQDNs. 3604 o Fixed bit length of schemes, numerical writing of bits (00b/01b). 3606 o Lets use US american english. 3608 15.16. draft-ietf-anima-autonomic-control-plane-10 3610 6.7.1.* Changed native IPsec encapsulation to tunnel mode 3611 (necessary), explaned why. Added notion that ESP is used, added 3612 explanations why tunnel/transport mode in native vs. GRE cases. 3614 6.10.3/6.10.5 Added term "ACP address range/set" to be able to better 3615 explain how the address in the ACP certificate is actually the base 3616 address (lowest address) of a range/set that is available to the 3617 device. 3619 6.10.4 Added note that manual address sub-scheme addresses must not 3620 be used within domain certificates (only for explicit configuration). 3622 6.12.5 Refined explanation of how ACP virtual interfaces work (p2p 3623 and multipoint). Did seek for pre-existing RFCs that explain how to 3624 built a multi-access interface on top of a full mesh of p2p 3625 connections (6man WG, anima WG mailing lists), but could not find any 3626 prior work that had a succinct explanation. So wrote up an 3627 explanation here. Added hopefully all necessary and sufficient 3628 details how to map ACP unicast packets to ACP secure channel, how to 3629 deal with ND packet details. Added verbage for ACP not to assign the 3630 virtual interface link-local address from the underlying interface. 3631 Addd note that GRAP link-local messages are treated specially but 3632 logically the same. Added paragraph about NBMA interfaces. 3634 From Brian Carpenters review: 3636 Added multiple new RFC references for terms/technologies used. 3638 Fixed verbage in several places. 3640 2. (terminology) Added 802.1AR as reference. 3642 2. Fixed up definition of ULA. 3644 6.1.1 Changed definition of ACP information in cert into ABNF format. 3645 Added warning about maximum size of ACP address field due to domain- 3646 name limitations. 3648 6.2 Mentioned API requirement between ACP and clients leveraging 3649 adjacency table. 3651 6.3 Fixed TTL in GRASP example: msec, not hop-count!. 3653 6.8.2 MAYOR: expanded security/transport substrate text: 3655 Introduced term ACP GRASP virtual interface to explain how GRASP 3656 link-local multicast messages are encapsulated and replicated to 3657 neighbors. Explain how ACP knows when to use TLS vs. TCP (TCP only 3658 for link-local address (sockets). 3660 6.8.2.1 Expanded discussion/explanation of security model. TLS for 3661 GRASP unicsast connections across ACP is double encryption (plus 3662 underlying ACP secure channel), but highly necessary to avoid very 3663 simple man-in-the-middle attacks by compromised ACP members on-path. 3664 Ultimately, this is done to ensure that any apps using GRASP can get 3665 full end-to-end secrecy for information sent across GRASP. But for 3666 publically known ASA services, even this will not provide 100% 3667 security (this is discussed). Also why double encryption is the 3668 better/easier solution than trying to optimize this. 3670 6.12.2 New performance requirements section added. 3672 16. References 3674 16.1. Normative References 3676 [I-D.ietf-anima-grasp] 3677 Bormann, C., Carpenter, B., and B. Liu, "A Generic 3678 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 3679 grasp-15 (work in progress), July 2017. 3681 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 3682 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 3683 . 3685 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 3686 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 3687 November 2005, . 3689 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 3690 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 3691 . 3693 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 3694 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 3695 2006, . 3697 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 3698 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 3699 DOI 10.17487/RFC4861, September 2007, 3700 . 3702 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 3703 Address Autoconfiguration", RFC 4862, 3704 DOI 10.17487/RFC4862, September 2007, 3705 . 3707 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 3708 (TLS) Protocol Version 1.2", RFC 5246, 3709 DOI 10.17487/RFC5246, August 2008, 3710 . 3712 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 3713 Housley, R., and W. Polk, "Internet X.509 Public Key 3714 Infrastructure Certificate and Certificate Revocation List 3715 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 3716 . 3718 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 3719 DOI 10.17487/RFC5322, October 2008, 3720 . 3722 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 3723 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 3724 January 2012, . 3726 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 3727 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 3728 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 3729 Low-Power and Lossy Networks", RFC 6550, 3730 DOI 10.17487/RFC6550, March 2012, 3731 . 3733 [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing 3734 Protocol for Low-Power and Lossy Networks (RPL)", 3735 RFC 6552, DOI 10.17487/RFC6552, March 2012, 3736 . 3738 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 3739 "Enrollment over Secure Transport", RFC 7030, 3740 DOI 10.17487/RFC7030, October 2013, 3741 . 3743 [RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support 3744 for Generic Routing Encapsulation (GRE)", RFC 7676, 3745 DOI 10.17487/RFC7676, October 2015, 3746 . 3748 16.2. Informative References 3750 [AR8021] IEEE SA-Standards Board, "IEEE Standard for Local and 3751 metropolitan area networks - Secure Device Identity", 3752 December 2009, . 3755 [I-D.ietf-anima-bootstrapping-keyinfra] 3756 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 3757 S., and K. Watsen, "Bootstrapping Remote Secure Key 3758 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 3759 keyinfra-07 (work in progress), July 2017. 3761 [I-D.ietf-anima-reference-model] 3762 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 3763 Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A 3764 Reference Model for Autonomic Networking", draft-ietf- 3765 anima-reference-model-04 (work in progress), July 2017. 3767 [I-D.ietf-anima-stable-connectivity] 3768 Eckert, T. and M. Behringer, "Using Autonomic Control 3769 Plane for Stable Connectivity of Network OAM", draft-ietf- 3770 anima-stable-connectivity-05 (work in progress), August 3771 2017. 3773 [I-D.ietf-netconf-zerotouch] 3774 Watsen, K., Abrahamsson, M., and I. Farrer, "Zero Touch 3775 Provisioning for NETCONF or RESTCONF based Management", 3776 draft-ietf-netconf-zerotouch-17 (work in progress), 3777 September 2017. 3779 [I-D.ietf-roll-useofrplinfo] 3780 Robles, I., Richardson, M., and P. Thubert, "When to use 3781 RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll- 3782 useofrplinfo-16 (work in progress), July 2017. 3784 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 3785 and E. Lear, "Address Allocation for Private Internets", 3786 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 3787 . 3789 [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax 3790 Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998, 3791 . 3793 [RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", 3794 RFC 2821, DOI 10.17487/RFC2821, April 2001, 3795 . 3797 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 3798 Extensions for Stateless Address Autoconfiguration in 3799 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 3800 . 3802 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 3803 Specifications: ABNF", STD 68, RFC 5234, 3804 DOI 10.17487/RFC5234, January 2008, 3805 . 3807 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 3808 DOI 10.17487/RFC5321, October 2008, 3809 . 3811 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 3812 and A. Bierman, Ed., "Network Configuration Protocol 3813 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 3814 . 3816 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 3817 Power and Lossy Networks (RPL) Option for Carrying RPL 3818 Information in Data-Plane Datagrams", RFC 6553, 3819 DOI 10.17487/RFC6553, March 2012, 3820 . 3822 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 3823 "Default Address Selection for Internet Protocol Version 6 3824 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 3825 . 3827 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 3828 DOI 10.17487/RFC6762, February 2013, 3829 . 3831 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 3832 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 3833 . 3835 [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local 3836 Addressing inside an IPv6 Network", RFC 7404, 3837 DOI 10.17487/RFC7404, November 2014, 3838 . 3840 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 3841 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 3842 Networking: Definitions and Design Goals", RFC 7575, 3843 DOI 10.17487/RFC7575, June 2015, 3844 . 3846 [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap 3847 Analysis for Autonomic Networking", RFC 7576, 3848 DOI 10.17487/RFC7576, June 2015, 3849 . 3851 Authors' Addresses 3853 Michael H. Behringer (editor) 3855 Email: michael.h.behringer@gmail.com 3857 Toerless Eckert (editor) 3858 Futurewei Technologies Inc. 3859 2330 Central Expy 3860 Santa Clara 95050 3861 USA 3863 Email: tte+ietf@cs.fau.de 3865 Steinthor Bjarnason 3866 Arbor Networks 3867 2727 South State Street, Suite 200 3868 Ann Arbor MI 48104 3869 United States 3871 Email: sbjarnason@arbor.net