idnits 2.17.1 draft-ietf-anima-autonomic-control-plane-14.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 7 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 980 has weird spacing: '... called rfcS...' == Line 1704 has weird spacing: '...k-local unic...' == Line 1705 has weird spacing: '...lticast messa...' -- The document date (June 6, 2018) is 2145 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 2936, but not defined == Missing Reference: 'Data-Plane' is mentioned on line 2938, but not defined == Missing Reference: 'Select' is mentioned on line 3093, but not defined == Missing Reference: 'Plane' is mentioned on line 3095, but not defined == Missing Reference: 'RFCxxxx' is mentioned on line 5776, but not defined == Unused Reference: 'RFC1034' is defined on line 5796, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-applicability-template' is defined on line 5922, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-cbor-cddl-02 ** 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-15 == Outdated reference: A later version (-10) exists of draft-ietf-anima-reference-model-06 == Outdated reference: A later version (-29) exists of draft-ietf-netconf-zerotouch-21 == Outdated reference: A later version (-44) exists of draft-ietf-roll-useofrplinfo-23 -- Obsolete informational reference (is this intentional?): RFC 2821 (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 2 errors (**), 0 flaws (~~), 17 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANIMA WG T. Eckert, Ed. 3 Internet-Draft Huawei 4 Intended status: Standards Track M. Behringer, Ed. 5 Expires: December 8, 2018 6 S. Bjarnason 7 Arbor Networks 8 June 6, 2018 10 An Autonomic Control Plane (ACP) 11 draft-ietf-anima-autonomic-control-plane-14 13 Abstract 15 Autonomic functions need a control plane to communicate, which 16 depends on some addressing and routing. This Autonomic Management 17 and Control Plane should ideally be self-managing, and as independent 18 as possible of configuration. This document defines such a plane and 19 calls it the "Autonomic Control Plane", with the primary use as a 20 control plane for autonomic functions. It also serves as a "virtual 21 out-of-band channel" for Operations Administration and Management 22 (OAM) communications over a network that is secure and reliable even 23 when the network is not configured, or misconfigured. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on December 8, 2018. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.1. Applicability and Scope . . . . . . . . . . . . . . . . . 7 61 2. Acronyms and Terminology . . . . . . . . . . . . . . . . . . 8 62 3. Use Cases for an Autonomic Control Plane . . . . . . . . . . 13 63 3.1. An Infrastructure for Autonomic Functions . . . . . . . . 13 64 3.2. Secure Bootstrap over a not configured Network . . . . . 13 65 3.3. Data-Plane Independent Permanent Reachability . . . . . . 14 66 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 15 67 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 16 68 6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 17 69 6.1. ACP Domain, Certificate and Network . . . . . . . . . . . 17 70 6.1.1. Certificate Domain Information Field . . . . . . . . 19 71 6.1.2. ACP domain membership check . . . . . . . . . . . . . 21 72 6.1.3. Certificate Maintenance . . . . . . . . . . . . . . . 22 73 6.2. ACP Adjacency Table . . . . . . . . . . . . . . . . . . . 27 74 6.3. Neighbor Discovery with DULL GRASP . . . . . . . . . . . 27 75 6.4. Candidate ACP Neighbor Selection . . . . . . . . . . . . 30 76 6.5. Channel Selection . . . . . . . . . . . . . . . . . . . . 31 77 6.6. Candidate ACP Neighbor verification . . . . . . . . . . . 33 78 6.7. Security Association protocols . . . . . . . . . . . . . 33 79 6.7.1. ACP via IKEv2 . . . . . . . . . . . . . . . . . . . . 33 80 6.7.2. ACP via DTLS . . . . . . . . . . . . . . . . . . . . 34 81 6.7.3. ACP Secure Channel Requirements . . . . . . . . . . . 35 82 6.8. GRASP in the ACP . . . . . . . . . . . . . . . . . . . . 35 83 6.8.1. GRASP as a core service of the ACP . . . . . . . . . 35 84 6.8.2. ACP as the Security and Transport substrate for GRASP 36 85 6.9. Context Separation . . . . . . . . . . . . . . . . . . . 39 86 6.10. Addressing inside the ACP . . . . . . . . . . . . . . . . 39 87 6.10.1. Fundamental Concepts of Autonomic Addressing . . . . 40 88 6.10.2. The ACP Addressing Base Scheme . . . . . . . . . . . 41 89 6.10.3. ACP Zone Addressing Sub-Scheme . . . . . . . . . . . 42 90 6.10.4. ACP Manual Addressing Sub-Scheme . . . . . . . . . . 44 91 6.10.5. ACP Vlong Addressing Sub-Scheme . . . . . . . . . . 46 92 6.10.6. Other ACP Addressing Sub-Schemes . . . . . . . . . . 47 93 6.10.7. ACP Registrars . . . . . . . . . . . . . . . . . . . 47 94 6.11. Routing in the ACP . . . . . . . . . . . . . . . . . . . 50 95 6.11.1. RPL Profile . . . . . . . . . . . . . . . . . . . . 51 96 6.12. General ACP Considerations . . . . . . . . . . . . . . . 54 97 6.12.1. Performance . . . . . . . . . . . . . . . . . . . . 55 98 6.12.2. Addressing of Secure Channels in the Data-Plane . . 55 99 6.12.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . 55 100 6.12.4. Multiple links between nodes . . . . . . . . . . . . 56 101 6.12.5. ACP interfaces . . . . . . . . . . . . . . . . . . . 56 102 7. ACP support on L2 switches/ports (Normative) . . . . . . . . 59 103 7.1. Why . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 104 7.2. How (per L2 port DULL GRASP) . . . . . . . . . . . . . . 60 105 8. Support for Non-ACP Components (Normative) . . . . . . . . . 62 106 8.1. ACP Connect . . . . . . . . . . . . . . . . . . . . . . . 62 107 8.1.1. Non-ACP Controller / NMS system . . . . . . . . . . . 62 108 8.1.2. Software Components . . . . . . . . . . . . . . . . . 64 109 8.1.3. Auto Configuration . . . . . . . . . . . . . . . . . 65 110 8.1.4. Combined ACP/Data-Plane Interface (VRF Select) . . . 66 111 8.1.5. Use of GRASP . . . . . . . . . . . . . . . . . . . . 67 112 8.2. ACP through Non-ACP L3 Clouds (Remote ACP neighbors) . . 68 113 8.2.1. Configured Remote ACP neighbor . . . . . . . . . . . 68 114 8.2.2. Tunneled Remote ACP Neighbor . . . . . . . . . . . . 70 115 8.2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 70 116 9. Benefits (Informative) . . . . . . . . . . . . . . . . . . . 70 117 9.1. Self-Healing Properties . . . . . . . . . . . . . . . . . 70 118 9.2. Self-Protection Properties . . . . . . . . . . . . . . . 72 119 9.2.1. From the outside . . . . . . . . . . . . . . . . . . 72 120 9.2.2. From the inside . . . . . . . . . . . . . . . . . . . 73 121 9.3. The Administrator View . . . . . . . . . . . . . . . . . 73 122 10. Further Considerations (Informative) . . . . . . . . . . . . 74 123 10.1. BRSKI Bootstrap (ANI) . . . . . . . . . . . . . . . . . 74 124 10.2. ACP (and BRSKI) Diagnostics . . . . . . . . . . . . . . 75 125 10.3. ACP Registrar Considerations . . . . . . . . . . . . . . 80 126 10.3.1. Registrar interactions . . . . . . . . . . . . . . . 80 127 10.3.2. Registrar Parameter . . . . . . . . . . . . . . . . 81 128 10.3.3. Certificate renewal and limitations . . . . . . . . 82 129 10.3.4. ACP Registrars with sub-CA . . . . . . . . . . . . . 83 130 10.3.5. Centralized Policy Control . . . . . . . . . . . . . 83 131 10.4. Address Space Considerations . . . . . . . . . . . . . . 84 132 10.5. Enabling and disabling ACP/ANI . . . . . . . . . . . . . 85 133 10.5.1. Filtering for non-ACP/ANI packets . . . . . . . . . 85 134 10.5.2. Admin Down State . . . . . . . . . . . . . . . . . . 86 135 10.5.3. Interface level ACP/ANI enable . . . . . . . . . . . 88 136 10.5.4. Which interfaces to auto-enable? . . . . . . . . . . 89 137 10.5.5. Node Level ACP/ANI enable . . . . . . . . . . . . . 90 138 10.5.6. Undoing ANI/ACP enable . . . . . . . . . . . . . . . 92 139 10.5.7. Summary . . . . . . . . . . . . . . . . . . . . . . 92 140 10.6. ACP Neighbor discovery protocol selection . . . . . . . 92 141 10.6.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 93 142 10.6.2. mDNS and L2 support . . . . . . . . . . . . . . . . 93 143 10.6.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 93 144 10.7. Choice of routing protocol (RPL) . . . . . . . . . . . . 94 145 10.8. ACP Information Distribution and multicast . . . . . . . 95 146 10.9. Extending ACP channel negotiation (via GRASP) . . . . . 96 147 10.10. CAs, domains and routing subdomains . . . . . . . . . . 98 148 10.11. Adopting ACP concepts for other environments . . . . . . 99 149 11. Security Considerations . . . . . . . . . . . . . . . . . . . 101 150 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 103 151 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 103 152 14. Change log [RFC Editor: Please remove] . . . . . . . . . . . 104 153 14.1. Initial version . . . . . . . . . . . . . . . . . . . . 104 154 14.2. draft-behringer-anima-autonomic-control-plane-00 . . . . 104 155 14.3. draft-behringer-anima-autonomic-control-plane-01 . . . . 104 156 14.4. draft-behringer-anima-autonomic-control-plane-02 . . . . 104 157 14.5. draft-behringer-anima-autonomic-control-plane-03 . . . . 104 158 14.6. draft-ietf-anima-autonomic-control-plane-00 . . . . . . 105 159 14.7. draft-ietf-anima-autonomic-control-plane-01 . . . . . . 105 160 14.8. draft-ietf-anima-autonomic-control-plane-02 . . . . . . 106 161 14.9. draft-ietf-anima-autonomic-control-plane-03 . . . . . . 106 162 14.10. draft-ietf-anima-autonomic-control-plane-04 . . . . . . 106 163 14.11. draft-ietf-anima-autonomic-control-plane-05 . . . . . . 107 164 14.12. draft-ietf-anima-autonomic-control-plane-06 . . . . . . 107 165 14.13. draft-ietf-anima-autonomic-control-plane-07 . . . . . . 108 166 14.14. draft-ietf-anima-autonomic-control-plane-08 . . . . . . 109 167 14.15. draft-ietf-anima-autonomic-control-plane-09 . . . . . . 111 168 14.16. draft-ietf-anima-autonomic-control-plane-10 . . . . . . 113 169 14.17. draft-ietf-anima-autonomic-control-plane-11 . . . . . . 115 170 14.18. draft-ietf-anima-autonomic-control-plane-12 . . . . . . 115 171 14.19. draft-ietf-anima-autonomic-control-plane-13 . . . . . . 116 172 14.20. draft-ietf-anima-autonomic-control-plane-14 . . . . . . 118 173 14.21. wish-list . . . . . . . . . . . . . . . . . . . . . . . 122 174 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 122 175 15.1. Normative References . . . . . . . . . . . . . . . . . . 122 176 15.2. Informative References . . . . . . . . . . . . . . . . . 125 177 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 129 179 1. Introduction 181 Autonomic Networking is a concept of self-management: Autonomic 182 functions self-configure, and negotiate parameters and settings 183 across the network. [RFC7575] defines the fundamental ideas and 184 design goals of Autonomic Networking. A gap analysis of Autonomic 185 Networking is given in [RFC7576]. The reference architecture for 186 Autonomic Networking in the IETF is specified in the document 187 [I-D.ietf-anima-reference-model] 189 Autonomic functions need an autonomically built communications 190 infrastructure. This infrastructure needs to be secure, resilient 191 and re-usable by all autonomic functions. Section 5 of [RFC7575] 192 introduces that infrastructure and calls it the Autonomic Control 193 Plane (ACP). More descriptively it would be the "Autonomic 194 communications infrastructure for Management and Control". For 195 naming consistency with that prior document, this document continues 196 to use the name ACP though. 198 Today, the management and control plane of networks typically uses 199 the global routing table, which is dependent on correct configuration 200 and routing. Misconfigurations or routing problems can therefore 201 disrupt management and control channels. Traditionally, an out-of- 202 band network has been used to avoid or allow recovery from such 203 problems, or personnel are sent on site to access devices through 204 console ports (craft ports). However, both options are expensive. 206 In increasingly automated networks either centralized management 207 systems or distributed autonomic service agents in the network 208 require a control plane which is independent of the configuration of 209 the network they manage, to avoid impacting their own operations 210 through the configuration actions they take. 212 This document describes a modular design for a self-forming, self- 213 managing and self-protecting Autonomic Control Plane (ACP), which is 214 a virtual in-band network designed to be as independent as possible 215 of configuration, addressing and routing problems. The details how 216 this achieved are defined in Section 6. The ACP is designed to 217 remains operational even in the presence of configuration errors, 218 addressing or routing issues, or where policy could inadvertently 219 affect connectivity of both data packets or control packets. 221 This document uses the term "Data-Plane" to refer to anything in the 222 network nodes that is not the ACP, and therefore considered to be 223 dependent on (mis-)configuration. This Data-Plane includes both the 224 traditional forwarding-plane, as well as any pre-existing control- 225 plane, such as routing protocols that establish routing tables for 226 the forwarding plane. 228 The Autonomic Control Plane serves several purposes at the same time: 230 1. Autonomic functions communicate over the ACP. The ACP therefore 231 supports directly Autonomic Networking functions, as described in 232 [I-D.ietf-anima-reference-model]. For example, Generic Autonomic 233 Signaling Protocol (GRASP - [I-D.ietf-anima-grasp]) runs securely 234 inside the ACP and depends on the ACP as its "security and 235 transport substrate". 237 2. A controller or network management system can use it to securely 238 bootstrap network devices in remote locations, even if the 239 network in between is not yet configured; no Data-Plane dependent 240 bootstrap configuration is required. An example of such a secure 241 bootstrap process is described in 242 [I-D.ietf-anima-bootstrapping-keyinfra] 244 3. An operator can use it to log into remote devices, even if the 245 network is misconfigured or not configured. 247 This document describes these purposes as use cases for the ACP in 248 Section 3, it defines the requirements in Section 4. Section 5 gives 249 an overview how the ACP is constructed, and in Section 6 the process 250 is defined in detail. Section 7 defines how to support ACP on L2 251 switches. Section 8 explains how non-ACP nodes and networks can be 252 integrated. 254 The following sections are non-normative: Section 9 reviews benefits 255 of the ACP (after all the details have been defined), Section 10 256 provides additional explanations and describes additional details or 257 future work possibilities that where considered not to be appropriate 258 for standardization in this document but nevertheless assumed to be 259 helpful for candidate adopters of the ACP. 261 The ACP provides secure IPv6 connectivity, therefore it can not only 262 be used as the secure connectivity for self-management as required 263 for the ACP in [RFC7575], but it can also be used as the secure 264 connectivity for traditional (centralized) management. The ACP can 265 be implemented and operated without any other components of autonomic 266 networks, except for the GRASP protocol which it leverages. 268 The document "Using Autonomic Control Plane for Stable Connectivity 269 of Network OAM" [RFC8368] describes how the ACP alone can be used to 270 provide secure and stable connectivity for autonomic and non- 271 autonomic Operations Administration and Management (OAM) 272 applications. That document also explains how existing management 273 solutions can leverage the ACP in parallel with traditional 274 management models, when to use the ACP and how to integrate with 275 potentially IPv4 only OAM backends. 277 Combining ACP with Bootstrapping Remote Secure Key Infrastructures 278 (BRSKI), see [I-D.ietf-anima-bootstrapping-keyinfra]) results in the 279 "Autonomic Network Infrastructure" as defined in 280 [I-D.ietf-anima-reference-model], which provides autonomic 281 connectivity (from ACP) with fully secure zero-touch (automated) 282 bootstrap from BRSKI. The ANI itself does not constitute an 283 Autonomic Network, but it allows the building of more or less 284 autonomic networks on top of it - using either centralized, Software 285 Defined Networking (SDN) (see [RFC7426]), style automation or 286 distributed automation via Autonomic Service Agents (ASA) / Autonomic 287 Functions (AF) - or a mixture of both. See 288 [I-D.ietf-anima-reference-model] for more information. 290 1.1. Applicability and Scope 292 Please see the following Terminology section (Section 2) for 293 explanations of terms used in this section. 295 The design of the ACP as defined in this document is considered to be 296 applicable to all types of "professionally managed" networks: Service 297 Provider, Local Area Network (LAN), Metro(politan networks), Wide 298 Area Network (WAN), Enterprise Information Technology (IT) and 299 Operational Technology (OT) networks. The ACP can operate equally on 300 layer 3 equipment and on layer 2 equipment such a bridges (see 301 Section 7). The encryption mechanism used by the ACP is defined to 302 be negotiable, therefore it can be extended to environments with 303 different encryption protocol preferences. The minimum 304 implementation requirements in this document attempt to achieve 305 maximum interoperability by requiring support for few options: IPsec, 306 DTLS - depending on type of device. 308 The implementation footprint of the ACP consists of Public Key 309 Infrastructure (PKI) code for the ACP certificate, the GRASP 310 protocol, UDP, TCP and TLS (for security and reliability of GRASP), 311 the ACP secure channel protocol used (such as IPsec or DTLS), and an 312 instance of IPv6 packet forwarding and routing via the RPL routing 313 protocol ([RFC6550]) that is separate from routing and forwarding for 314 the Data-Plane (user traffic). 316 The ACP uses only IPv6 to avoid complexity of dual-stack ACP 317 operations (IPv6/IPv4). Nevertheless, it can without any changes be 318 integrated into even otherwise IPv4-only network devices. The Data- 319 Plane itself would not need to change, it could continue to be IPv4 320 only. For such IPv4 only devices, the IPv6 protocol itself would be 321 additional implementation footprint only used for the ACP. 323 The protocol choices of the ACP are primarily based on wide use and 324 support in networks and devices, well understood security properties 325 and required scalability. The ACP design is an attempt to produce 326 the lowest risk combination of existing technologies and protocols to 327 build a widely applicable operational network management solution: 329 RPL was chosen because it requires a smaller routing table footprint 330 in large networks compared to other routing protocols with an 331 autonomically configured single area. The deployment experience of 332 large scale Internet of Things (IoT) networks serves as the basis for 333 wide deployment experience with RPL. The profile chosen for RPL in 334 the ACP does not not leverage any RPL specific forwarding plane 335 features (IPv6 extension headers), making its implementation a pure 336 control plane software requirement. 338 GRASP is the only completely novel protocol used in the ACP, and this 339 choice was necessary because there is no existing suitable protocol 340 to provide the necessary functions to the ACP, so GRASP was developed 341 to fill that gap. 343 The ACP design can be applicable to (cpu, memory) constrained devices 344 and (bitrate, reliability) constrained networks, but this document 345 does not attempt to define the most constrained type of devices or 346 networks to which the ACP is applicable. RPL and DTLS are two 347 protocol choices already making ACP more applicable to constrained 348 environments. See Section 10.11 for discussions about how variations 349 of the ACP could be defined in the future to better meet different 350 expectations from those on which the current design is based. 352 2. Acronyms and Terminology 354 In the rest of the document we will refer to systems using the ACP as 355 "nodes". Typically such a node is a physical (network equipment) 356 device, but it can equally be some virtualized system. Therefore, we 357 do not refer to them as devices unless the context specifically calls 358 for a physical system. 360 This document introduces or uses the following terms (sorted 361 alphabetically). Terms introduced are explained on first use, so 362 this list is for reference only. 364 ACP: "Autonomic Control Plane". The Autonomic Function as defined 365 in this document. It provides secure zero-touch (automated) 366 transitive (network wide) IPv6 connectivity for all nodes in the 367 same ACP domain as well as a GRASP instance running across this 368 ACP IPv6 connectivity. The ACP is primarily meant to be used as a 369 component of the ANI to enable Autonomic Networks but it can 370 equally be used in simple ANI networks (with no other Autonomic 371 Functions) or completely by itself. 373 ACP address: An IPv6 address assigned to the ACP node. It is stored 374 in the domain information field of the ->"ACP domain certificate" 375 (). 377 ACP address range/set: The ACP address may imply a range or set of 378 addresses that the node can assign for different purposes. This 379 address range/set is derived by the node from the format of the 380 ACP address called the "addressing sub-scheme". 382 ACP connect interface: An interface on an ACP node providing access 383 to the ACP for non ACP capable nodes without using an ACP secure 384 channel. See Section 8.1.1. 386 ACP domain: The ACP domain is the set of nodes with ->"ACP domain 387 certificates" that allow them to authenticate each other as 388 members of the ACP domain. See also Section 6.1.2. 390 ACP (ANI/AN) Domain Certificate: A provisioned [RFC5280] certificate 391 (LDevID) carrying the domain information field which is used by 392 the ACP to learn its address in the ACP and to derive and 393 cryptographically assert its membership in the ACP domain. 395 domain information (field): An rfc822Name information element (e.g., 396 field) in the domain certificate in which the ACP relevant 397 information is encoded: the domain name and the ACP address. 399 ACP Loopback interface: The Loopback interface in the ACP VRF that 400 has the ACP address assigned to it. 402 ACP network: The ACP network constitutes all the nodes that have 403 access to the ACP. It is the set of active and transitively 404 connected nodes of an ACP domain plus all nodes that get access to 405 the ACP of that domain via ACP edge nodes. 407 ACP (ULA) prefix(es): The /48 IPv6 address prefixes used across the 408 ACP. In the normal/simple case, the ACP has one ULA prefix, see 409 Section 6.10. The ACP routing table may include multiple ULA 410 prefixes if the "rsub" option is used to create addresses from 411 more than one ULA prefix. See Section 6.1.1. The ACP may also 412 include non-ULA prefixes if those are configured on ACP connect 413 interfaces. See Section 8.1.1. 415 ACP secure channel: A security association established hop-by-hop 416 between adjacent ACP nodes to carry traffic of the ACP VRF 417 separated from Data-Plane traffic in-band over the same links as 418 the Data-Plane. 420 ACP secure channel protocol: The protocol used to build an ACP 421 secure channel, e.g., Internet Key Exchange Protocol version 2 422 (IKEv2) with IPsec or Datagram Transport Layer Security (DTLS). 424 ACP virtual interface: An interface in the ACP VRF mapped to one or 425 more ACP secure channels. See Section 6.12.5. 427 AN "Autonomic Network": A network according to 428 [I-D.ietf-anima-reference-model]. Its main components are ANI, 429 Autonomic Functions and Intent. 431 (AN) Domain Name: An FQDN (Fully Qualified Domain Name) in the 432 domain information field of the Domain Certificate. See 433 Section 6.1.1. 435 ANI (nodes/network): "Autonomic Network Infrastructure". The ANI is 436 the infrastructure to enable Autonomic Networks. It includes ACP, 437 BRSKI and GRASP. Every Autonomic Network includes the ANI, but 438 not every ANI network needs to include autonomic functions beyond 439 the ANI (nor intent). An ANI network without further autonomic 440 functions can for example support secure zero-touch (automated) 441 bootstrap and stable connectivity for SDN networks - see 442 [RFC8368]. 444 ANIMA: "Autonomic Networking Integrated Model and Approach". ACP, 445 BRSKI and GRASP are products of the IETF ANIMA working group. 447 ASA: "Autonomic Service Agent". Autonomic software modules running 448 on an ANI device. The components making up the ANI (BRSKI, ACP, 449 GRASP) are also described as ASAs. 451 Autonomic Function: A function/service in an Autonomic Network (AN) 452 composed of one or more ASA across one or more ANI nodes. 454 BRSKI: "Bootstrapping Remote Secure Key Infrastructures" 455 ([I-D.ietf-anima-bootstrapping-keyinfra]. A protocol extending 456 EST to enable secure zero-touch bootstrap in conjunction with ACP. 457 ANI nodes use ACP, BRSKI and GRASP. 459 Data-Plane: The counterpoint to the ACP VRF in an ACP node: all 460 routing and forwarding in the node other than the ACP VRF. In a 461 simple ACP or ANI node, the Data-Plane is typically provisioned 462 non-autonomic, for example manually (including across the ACP) or 463 via SDN controllers. In a fully Autonomic Network node, the Data- 464 Plane is managed autonomically via Autonomic Functions and Intent. 465 Note that other (non-ANIMA) RFC use the Data-Plane to refer to 466 what is better called the forwarding plane. This is not the way 467 the term is used in this document! 469 device: A physical system, or physical node. 471 Enrollment: The process where a node presents identification (for 472 example through keying material such as the private key of an 473 IDevID) to a network and acquires a network specific identity and 474 trust anchor such as an LDevID. 476 EST: "Enrollment over Secure Transport" ([RFC7030]). IETF standard 477 protocol for enrollment of a node with an LDevID. BRSKI is based 478 on EST. 480 GRASP: "Generic Autonomic Signaling Protocol". An extensible 481 signaling protocol required by the ACP for ACP neighbor discovery. 482 The ACP also provides the "security and transport substrate" for 483 the "ACP instance of GRASP". This instance of GRASP runs across 484 the ACP secure channels to support BRSKI and other future 485 Autonomic Functions. See [I-D.ietf-anima-grasp]. 487 IDevID: An "Initial Device IDentity" X.509 certificate installed by 488 the vendor on new equipment. Contains information that 489 establishes the identity of the node in the context of its vendor/ 490 manufacturer such as device model/type and serial number. See 491 [AR8021]. IDevID can not be used for the ACP because they are not 492 provisioned by the owner of the network, so they can not directly 493 indicate an ACP domain they belong to. 495 in-band (management): The type of management used predominantly in 496 IP based networks, not leveraging an ->"out-of-band network" (). 497 In in-band management, access to the managed equipment depends on 498 the configuration of this equipment itself: interface, addressing, 499 forwarding, routing, policy, security, management. This 500 dependency makes in-band management fragile because the 501 configuration actions performed may break in-band management 502 connectivity. Breakage can not only be unintentional, it can 503 simply be an unavoidable side effect of being unable to create 504 configuration schemes where in-band management connectivity 505 configuration is unaffected by Data-Plane configuration. See also 506 ->"(virtual) out-of-band network" (). 508 Intent: Policy language of an autonomic network according to 509 [I-D.ietf-anima-reference-model]. 511 Loopback interface: The conventional name for an internal IP 512 interface to which addresses may be assigned, but which transmits 513 no external traffic. 515 LDevID: A "Local Device IDentity" is an X.509 certificate installed 516 during "enrollment". The Domain Certificate used by the ACP is an 517 LDevID. See [AR8021]. 519 MIC: "Manufacturer Installed Certificate". Another word not used in 520 this document to describe an IDevID. 522 native interface: Interfaces existing on a node without 523 configuration of the already running node. On physical nodes 524 these are usually physical interfaces. On virtual nodes their 525 equivalent. 527 node: A system, e.g., supporting the ACP according to this document. 528 Can be virtual or physical. Physical nodes are called devices. 530 Node-ID: The identifier of an ACP node inside that ACP. It is the 531 last 64 (see Section 6.10.3) or 78 bit (see xref target="Vlong"/>) 532 of the ACP address. 534 (virtual) out-of-band network: An out-of-band network is a secondary 535 network used to manage a primary network. The equipment of the 536 primary network is connected to the out-of-band network via 537 dedicated management ports on the primary network equipment. 538 Serial (console) management ports are most common, higher end 539 network equipment also has ethernet ports dedicated only for 540 management. An out-of-band network provides management access to 541 the primary network independent of the configuration state of the 542 primary network. One of the goals of the ACP is to provide this 543 benefit of out-of-band networks virtually on the primary network 544 equipment. The ACP VRF acts as a virtual out of band network 545 device providing configuration independent management access. The 546 ACP secure channels are the virtual links of the ACP virtual out- 547 of-band network, meant to be operating independent of the 548 configuration of the primary network. See also ->"in-band 549 (management)" (). 551 RPL: "IPv6 Routing Protocol for Low-Power and Lossy Networks". The 552 routing protocol used in the ACP. See [RFC6550]. 554 MASA (service): "Manufacturer Authorized Signing Authority". A 555 vendor/manufacturer or delegated cloud service on the Internet 556 used as part of the BRSKI protocol. 558 (ACP/ANI/BRSKI) Registrar: An ACP registrar is an entity (software 559 and/or person) that is orchestrating the enrollment of ACP nodes 560 with the ACP domain certificate. ANI nodes use BRSKI, so ANI 561 registrars are also called BRSKI registrars. For non-ANI ACP 562 nodes, the registrar mechanisms are undefined by this document. 563 See Section 6.10.7. Renewal and other maintenance (such as 564 revocation) of ACP domain certificates may be performed by other 565 entities than registrars. EST must be supported for ACP domain 566 certificate renewal (see Section 6.1.3). BRSKI is an extension of 567 EST, so ANI/BRSKI registrars can easily support ACP domain 568 certificate renewal in addition to initial enrollment. 570 sUDI: "secured Unique Device Identifier". Another term not used in 571 this document to refer to an IDevID. 573 UDI: "Unique Device Identifier". In the context of this document 574 unsecured identity information of a node typically consisting of 575 at least device model/type and serial number, often in a vendor 576 specific format. See sUDI and LDevID. 578 ULA: (Global ID prefix) A "Unique Local Address" (ULA) is an IPv6 579 address in the block fc00::/7, defined in [RFC4193]. It is the 580 approximate IPv6 counterpart of the IPv4 private address 581 ([RFC1918]). The ULA Global ID prefix are the first 48 bit of a 582 ULA address. In this document it is abbreviated as "ULA prefix". 584 (ACP) VRF: The ACP is modeled in this document as a "Virtual Routing 585 and Forwarding" instance (VRF). This means that it is based on a 586 "virtual router" consisting of a separate IPv6 forwarding table to 587 which the ACP virtual interfaces are attached and an associated 588 separate IPv6 routing table. Unlike the VRFs on MPLS/VPN-PE 589 ([RFC4364]) or LISP XTR ([RFC6830]), the ACP VRF does not have any 590 special "core facing" functionality or routing/mapping protocols 591 shared across multiple VRFs. In vendor products a VRF such as the 592 ACP-VRF may also be referred to as a so called VRF-lite. 594 (ACP) Zone: An ACP zone is a connected region of the ACP where nodes 595 derive from their non-aggregatable ACP address (identifier 596 address) an aggregatable ACP zone address (locator address). See 597 the definition of the ACP Zone Addressing Sub-Scheme 598 (Section 6.10.3). The complete definition of zones is subject to 599 future work because this document does not describe the routing 600 protocols details for aggregation of ACP zone addresses, but only 601 their addressing scheme. 603 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 604 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 605 "OPTIONAL" in this document are to be interpreted as described in 606 [RFC8174] when they appear in ALL CAPS. When these words are not in 607 ALL CAPS (such as "should" or "Should"), they have their usual 608 English meanings, and are not to be interpreted as [RFC8174] key 609 words. 611 3. Use Cases for an Autonomic Control Plane 613 3.1. An Infrastructure for Autonomic Functions 615 Autonomic Functions need a stable infrastructure to run on, and all 616 autonomic functions should use the same infrastructure to minimize 617 the complexity of the network. This way, there is only need for a 618 single discovery mechanism, a single security mechanism, and other 619 processes that distributed functions require. 621 3.2. Secure Bootstrap over a not configured Network 623 Today, bootstrapping a new node typically requires all nodes between 624 a controlling node such as an SDN controller ("Software Defined 625 Networking", see [RFC7426]) and the new node to be completely and 626 correctly addressed, configured and secured. Bootstrapping and 627 configuration of a network happens in rings around the controller - 628 configuring each ring of devices before the next one can be 629 bootstrapped. Without console access (for example through an out-of- 630 band network) it is not possible today to make devices securely 631 reachable before having configured the entire network leading up to 632 them. 634 With the ACP, secure bootstrap of new devices can happen without 635 requiring any configuration such as the transit connectivity to 636 bootstrap further devices. A new device can automatically be 637 bootstrapped in a secure fashion and be deployed with a domain 638 certificate. This does not require any configuration on intermediate 639 nodes, because they can communicate zero-touch and securely through 640 the ACP. 642 3.3. Data-Plane Independent Permanent Reachability 644 Today, most critical control plane protocols and network management 645 protocols are using the Data-Plane (global routing table) of the 646 network. This leads to undesirable dependencies between control and 647 management plane on one side and the Data-Plane on the other: Only if 648 the Data-Plane is operational, will the other planes work as 649 expected. 651 Data-Plane connectivity can be affected by errors and faults, for 652 example misconfigurations that make AAA (Authentication, 653 Authorization and Accounting) servers unreachable or can lock an 654 administrator out of a device; routing or addressing issues can make 655 a device unreachable; shutting down interfaces over which a current 656 management session is running can lock an admin irreversibly out of 657 the device. Traditionally only console access can help recover from 658 such issues. 660 Data-Plane dependencies also affect applications in a Network 661 Operations Center (NOC) such as SDN controller applications: Certain 662 network changes are today hard to operate, because the change itself 663 may affect reachability of the devices. Examples are address or mask 664 changes, routing changes, or security policies. Today such changes 665 require precise hop-by-hop planning. 667 The ACP provides reachability that is independent of the Data-Plane 668 (except for the dependency discussed in Section 6.12.2 which can be 669 removed through future work), which allows the control plane and 670 management plane to operate more robustly: 672 o For management plane protocols, the ACP provides the functionality 673 of a Virtual out of Band (VooB) channel, by providing connectivity 674 to all nodes regardless of their configuration or global routing 675 table. 677 o For control plane protocols, the ACP allows their operation even 678 when the Data-Plane is temporarily faulty, or during transitional 679 events, such as routing changes, which may affect the control 680 plane at least temporarily. This is specifically important for 681 autonomic service agents, which could affect Data-Plane 682 connectivity. 684 The document "Using Autonomic Control Plane for Stable Connectivity 685 of Network OAM" [RFC8368] explains this use case for the ACP in 686 significantly more detail and explains how the ACP can be used in 687 practical network operations. 689 4. Requirements 691 The Autonomic Control Plane has the following requirements: 693 ACP1: The ACP SHOULD provide robust connectivity: As far as 694 possible, it should be independent of configured addressing, 695 configuration and routing. Requirements 2 and 3 build on this 696 requirement, but also have value on their own. 698 ACP2: The ACP MUST have a separate address space from the Data- 699 Plane. Reason: traceability, debug-ability, separation from 700 Data-Plane, security (can block easily at edge). 702 ACP3: The ACP MUST use autonomically managed address space. Reason: 703 easy bootstrap and setup ("autonomic"); robustness (admin 704 can't mess things up so easily). This document suggests using 705 ULA addressing for this purpose ("Unique Local Address", see 706 [RFC4193]). 708 ACP4: The ACP MUST be generic. Usable by all the functions and 709 protocols of the ANI. Clients of the ACP MUST NOT be tied to 710 a particular application or transport protocol. 712 ACP5: The ACP MUST provide security: Messages coming through the ACP 713 MUST be authenticated to be from a trusted node, and SHOULD 714 (very strong SHOULD) be encrypted. 716 Explanation for ACP4: In a fully autonomic network (AN), newly 717 written ASA could potentially all communicate exclusively via GRASP 718 with each other, and if that was assumed to be the only requirement 719 against the ACP, it would not need to provide IPv6 layer connectivity 720 between nodes, but only GRASP connectivity. Nevertheless, because 721 ACP also intends to support non-AN networks, it it is crucial to 722 support IPv6 layer connectivity across the ACP to support any 723 transport and application layer protocols. 725 Th eACP operates hop-by-hop, because this interaction can be built on 726 IPv6 link local addressing, which is autonomic, and has no dependency 727 on configuration (requirement 1). It may be necessary to have ACP 728 connectivity across non-ACP nodes, for example to link ACP nodes over 729 the general Internet. This is possible, but introduces a dependency 730 against stable/resilient routing over the non-ACP hops (see 731 Section 8.2). 733 5. Overview 735 The Autonomic Control Plane is constructed in the following way (for 736 details, see Section 6): 738 1. An ACP node creates a Virtual Routing and Forwarding (VRF) 739 instance, or a similar virtual context. 741 2. It determines, following a policy, a candidate peer list. This 742 is the list of nodes to which it should establish an Autonomic 743 Control Plane. Default policy is: To all link-layer adjacent 744 nodes supporting ACP. 746 3. For each node in the candidate peer list, it authenticates that 747 node and negotiates a mutually acceptable channel type. 749 4. For each node in the candidate peer list, it then establishes a 750 secure tunnel of the negotiated type. The resulting tunnels are 751 then placed into the previously set up VRF. This creates an 752 overlay network with hop-by-hop tunnels. 754 5. Inside the ACP VRF, each node assigns its ULA IPv6 address to a 755 Loopback interface assigned to the ACP VRF. 757 6. Each node runs a lightweight routing protocol, to announce 758 reachability of the virtual addresses inside the ACP (see 759 Section 6.12.5). 761 Note: 763 o Non-autonomic NMS ("Network Management Systems") or SDN 764 controllers have to be explicitly configured for connection into 765 the ACP. 767 o Connecting over non-ACP Layer-3 clouds requires explicit 768 configuration. See Section 8.2. This may be automated in the 769 future through auto discovery mechanisms across L3. 771 o None of the above operations (except explicit configured ones) are 772 reflected in the configuration of the node. 774 The following figure illustrates the ACP. 776 ACP node 1 ACP node 2 777 ................... ................... 778 secure . . secure . . secure 779 channel: +-----------+ : channel : +-----------+ : channel 780 ..--------| ACP VRF |---------------------| ACP VRF |---------.. 781 : / \ / \ <--routing--> / \ / \ : 782 : \ / \ / \ / \ / : 783 ..--------| Loopback |---------------------| Loopback |---------.. 784 : | interface | : : | interface | : 785 : +-----------+ : : +-----------+ : 786 : : : : 787 : Data-Plane :...............: Data-Plane : 788 : : link : : 789 :.................: :.................: 791 Figure 1: ACP VRF and secure channels 793 The resulting overlay network is normally based exclusively on hop- 794 by-hop tunnels. This is because addressing used on links is IPv6 795 link local addressing, which does not require any prior set-up. This 796 way the ACP can be built even if there is no configuration on the 797 node, or if the Data-Plane has issues such as addressing or routing 798 problems. 800 6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 802 This section describes the components and steps to set up an 803 Autonomic Control Plane (ACP), and highlights the key properties 804 which make it "indestructible" against many inadvertent changes to 805 the Data-Plane, for example caused by misconfigurations. 807 An ACP node can be a router, switch, controller, NMS host, or any 808 other IP capable node. Initially, it must have its ACP domain 809 certificate, as well as an (empty) ACP Adjacency Table (described in 810 Section 6.2). It then can start to discover ACP neighbors and build 811 the ACP. This is described step by step in the following sections: 813 6.1. ACP Domain, Certificate and Network 815 The ACP relies on group security. An ACP domain is a group of nodes 816 that trust each other to participate in ACP operations. To establish 817 trust, each ACP member requires keying material: An ACP node MUST 818 have a certificate (LDevID) and a Trust Anchor (TA) consisting of a 819 certificate (chain) used to sign the LDevID of all ACP domain 820 members. The LDevID is used to cryptographically authenticate the 821 membership of its owner node in the ACP domain to other ACP domain 822 members, the TA is used to authenticate the ACP domain membership of 823 other nodes (see Section 6.1.2). 825 The LDevID is called the ACP domain certificate, the TA is the 826 Certificate Authority (CA) of the ACP domain. 828 The ACP does not mandate specific mechanisms by which this keying 829 material is provisioned into the ACP node, it only requires the 830 Domain information field as specified in Section 6.1.1 in its domain 831 certificate as well as those of candidate ACP peers. See 832 Section 10.1 for more information about enrollment or provisioning 833 options. 835 This document uses the term ACP in many places where the Autonomic 836 Networking reference documents [RFC7575] and 837 [I-D.ietf-anima-reference-model] use the word autonomic. This is 838 done because those reference documents consider (only) fully 839 autonomic networks and nodes, but support of ACP does not require 840 support for other components of autonomic networks. Therefore the 841 word autonomic might be misleading to operators interested in only 842 the ACP: 844 [RFC7575] defines the term "Autonomic Domain" as a collection of 845 autonomic nodes. ACP nodes do not need to be fully autonomic, but 846 when they are, then the ACP domain is an autonomic domain. Likewise, 847 [I-D.ietf-anima-reference-model] defines the term "Domain 848 Certificate" as the certificate used in an autonomic domain. The ACP 849 domain certificate is that domain certificate when ACP nodes are 850 (fully) autonomic nodes. Finally, this document uses the term ACP 851 network to refer to the network created by active ACP nodes in an ACP 852 domain. The ACP network itself can extend beyond ACP nodes through 853 the mechanisms described in Section 8.1). 855 The ACP domain certificate can and should be used for any 856 authentication between ACP nodes where the required security is 857 domain membership. Section 6.1.2 defines this "ACP domain membership 858 check". The uses of this check that are standardized in this 859 document are for the establishment of ACP secure channels 860 (Section 6.6) and for ACP GRASP (Section 6.8.2). Other uses are 861 subject to future work, but it is recommended that it is the default 862 security check for any end-to-end connections between ASA. It is 863 equally useable by other functions such as legacy OAM functions. 865 6.1.1. Certificate Domain Information Field 867 Information about the domain MUST be encoded in the domain 868 certificate in a subjectAltName / rfc822Name field according to the 869 following ABNF definition ([RFC5234]): 871 [RFC Editor: Please substitute SELF in all occurences of rfcSELF in 872 this document with the RFC number assigned to this document and 873 remove this comment line] 875 domain-information = local-part "@" domain 876 local-part = key [ "." local-info ] 877 key = "rfcSELF" 878 local-info = [ acp-address ] [ "+" rsub extensions ] 879 acp-address = 32hex-dig 880 hex-dig = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" 881 rsub = [ domain-name ] ; empty if not used 882 domain = domain-name 883 routing-subdomain = [ rsub " ." ] domain 884 domain-name = ; ; as of RFC 1034, section 3.5 885 extensions = *( "+" extension ) 886 extension = ; future definition. 887 ; Must fit RFC5322 simple dot-atom format. 889 Example: 890 domain-information = rfcSELF+fd89b714f3db00000200000064000000 891 +area51.research@acp.example.com 892 routing-subdomain = area51.research.acp.example.com 894 Figure 2: ACP Domain Information Field ABNF 896 "acp-address" MUST be the ACP address of the node. It is optional to 897 support variations of the ACP mechanisms, for example other means for 898 nodes to assign ACP addresses to themselves. Such methods are 899 subject to future work though. 901 Note: "acp-address" cannot use standard IPv6 address formats because 902 it must match the simple dot-atom format of [RFC5322]. ":" are not 903 allowed in that format. 905 "domain" is used to indicate the ACP Domain across which all ACP 906 nodes trust each other and are willing to build ACP channel to each 907 other. See Section 6.1.2. Domain SHOULD be the FQDN of a domain 908 owned by the operator assigning the certificate. This is a simple 909 method to ensure that the domain is globally unique and collision of 910 ACP addresses would therefore only happen due to ULA hash collisions. 911 If the operator does not own any FQDN, it should choose a string in 912 FQDN format that intends to be equally unique. 914 "routing-subdomain" is the autonomic subdomain that is used to 915 calculate the hash for the ULA Global ID of the ACP address of the 916 node. "rsub" is optional; its syntax is defined in this document, 917 but its semantics are for further study. Understanding the benefits 918 of using rsub may depend on the results of future work on enhancing 919 routing for the ACP. When "rsub" is not used, "routing-subdomain" is 920 the same as "domain". "rsub" needs to be in the "local-part"; it 921 could not syntactically be separated from "domain-name" if "domain" 922 is just a domain name. It also makes it easier for domain name to be 923 a valid e-mail target. 925 The optional "extensions" field is used for future extensions to this 926 specification. It MUST be ignored if present and not understood. 928 In this specification, the "acp-address" field is REQUIRED, but 929 future variations (see Section 10.11) may use local information to 930 derive the ACP address. In this case, "acp-address" could be empty. 931 Such a variation would be indicated by an appropriate "extension". 932 If "acp-address" is empty, and "rsub" is empty too, the "local-part" 933 will have the format "rfcSELF + + extension(s)". The two plus 934 characters are necessary so the node can unambiguously parse that 935 both "acp-address" and "rsub" are empty. 937 Note that the maximum size of "domain-information" is 254 characters 938 and the maximum size of node-info is 64 characters according to 939 [RFC5280] that is referring to [RFC2821] (superseded by [RFC5321]). 941 The subjectAltName / rfc822Name encoding of the ACP domain name and 942 ACP address is used for the following reasons: 944 o It should be possible to share the LDevID with other uses beside 945 the ACP. Therefore, the information element required for the ACP 946 should be encoded so that it minimizes the possibility of creating 947 incompatibilities with such other uses. 949 o The information for the ACP should not cause incompatibilities 950 with any pre-existing ASN.1 software. This eliminates the 951 introduction of a novel information element because that could 952 require extensions to such pre-existing ASN.1 parsers. 954 o subjectAltName / rfc822Name is a pre-existing element that must be 955 supported by all existing ASN.1 parsers for LDevID. 957 o The element required for the ACP should not be misinterpreted by 958 any other uses of the LDevID. If the element used for the ACP is 959 interpreted by other uses, the impact should be benign. 961 o Using an IP address format encoding could result in non-benign 962 misinterpretation of the domain information field; other uses 963 unaware of the ACP could try to do something with the ACP address 964 that would fail to work correctly. For example, the address could 965 be interpreted to be an address of the node which does not belong 966 to the ACP VRF. 968 o At minimum, both the AN domain name and the non-domain name 969 derived part of the ACP address need to be encoded in one or more 970 appropriate fields of the certificate, so there are not many 971 alternatives with pre-existing fields where the only possible 972 conflicts would likely be beneficial. 974 o rfc822Name encoding is quite flexible. We choose to encode the 975 full ACP address AND the domain name with sub part into a single 976 rfc822Name information element it, so that it is easier to 977 examine/use the "domain information field". 979 o The format of the rfc822Name is chosen so that an operator can set 980 up a mailbox called rfcSELF@ that would receive emails 981 sent towards the rfc822Name of any node inside a domain. This is 982 possible because in many modern mail systems, components behind a 983 "+" character are considered part of a single mailbox. In other 984 words, it is not necessary to set up a separate mailbox for every 985 ACP node, but only one for the whole domain. 987 o In result, if any unexpected use of the ACP addressing information 988 in a certificate happens, it is benign and detectable: it would be 989 mail to that mailbox. 991 See section 4.2.1.6 of [RFC5280] for details on the subjectAltName 992 field. 994 6.1.2. ACP domain membership check 996 The following points constitute the ACP domain membership check: 998 o The peer certificate is valid as proven by the security 999 associations protocol exchange. 1001 o The peer's certificate is signed by one of the trust anchors 1002 associated with the ACP domain certificate. 1004 o If the node certificates indicates a Certificate Revocation List 1005 (CRL) Distribution Point (CDP) ([RFC5280], section 4.2.1.13) or 1006 Online Certificate Status Protocol (OCSP) responder ([RFC5280], 1007 section 4.2.2.1), then the peer's certificate must be valid 1008 according to those criteria: An OCSP check for the peers 1009 certificate across the ACP must succeed or the peer certificate 1010 must not be listed in the CRL retrieved from the CDP. 1012 o The peers certificate has a syntactically valid domain information 1013 field (subjectAltName / rfc822Name) and the domain name in that 1014 peers domain information field is the same as in this ACP node 1015 certificate. Note that future Intent rules may modify this. See 1016 Section 10.10. 1018 6.1.3. Certificate Maintenance 1020 ACP nodes MUST support certificate renewal via EST ("Enrollment over 1021 Secure Transport", see [RFC7030]) and MAY support other mechanisms. 1022 An ACP network MUST have at least one ACP node supporting EST server 1023 functionality across the ACP so that EST renewal is useable. 1025 ACP nodes SHOULD be able to remember the EST server from which they 1026 last renewed their ACP domain certificate and SHOULD provide the 1027 ability for this remembered EST server to also be set by the ACP 1028 Registrar (see Section 6.10.7) that initially enrolled the ACP device 1029 with its ACP domain certificate. When BRSKI (see 1030 [I-D.ietf-anima-bootstrapping-keyinfra]) is used, the ACP address of 1031 the BRSKI registrar from the BRSKI TLS connection SHOULD be 1032 remembered and used for the next renewal via EST if that registrar 1033 also announces itself as an EST server via GRASP (see next section) 1034 on its ACP address. 1036 6.1.3.1. GRASP objective for EST server 1038 ACP nodes that are EST servers MUST announce their service via GRASP 1039 in the ACP through M_FLOOD messages. See [I-D.ietf-anima-grasp], 1040 section 2.8.11 for the definition of this message type: 1042 Example: 1044 [M_FLOOD, 12340815, h'fd89b714f3db0000200000064000001', 210000, 1045 ["SRV.est", 4, 255 ], 1046 [O_IPv6_LOCATOR, 1047 h'fd89b714f3db0000200000064000001', TCP, 80] 1048 ] 1050 Figure 3: GRASP SRV.est example 1052 The formal definition of the objective in Concise data definition 1053 language (CDDL) (see [I-D.ietf-cbor-cddl]) is as follows: 1055 flood-message = [M_FLOOD, session-id, initiator, ttl, 1056 +[objective, (locator-option / [])]] 1058 objective = ["SRV.est", objective-flags, loop-count, 1059 objective-value] 1061 objective-flags = sync-only ; as in GRASP spec 1062 sync-only = 4 ; M_FLOOD only requires synchronization 1063 loop-count = 255 ; recommended 1064 objective-value = ; Not used (yet) 1066 Figure 4: GRASP SRV.est definition 1068 The objective value "SRV.est" indicates that the objective is an 1069 [RFC7030] compliant EST server because "est" is an [RFC6335] 1070 registered service name for [RFC7030]. Future backward compatible 1071 extensions/alternatives to [RFC7030] may be indicated through 1072 objective-value. Future non-backward compatible certificate renewal 1073 options must use a different objective-name. 1075 The M_FLOOD message MUST be sent periodically. The default SHOULD be 1076 60 seconds, the value SHOULD be operator configurable. The frequency 1077 of sending MUST be such that the aggregate amount of periodic 1078 M_FLOODs from all flooding sources causes only negligible traffic 1079 across the ACP. The ttl parameter SHOULD be 3.5 times the period so 1080 that up to three consecutive messages can be dropped before 1081 considering an announcement expired. In the example above, the ttl 1082 is 210000 msec, 3.5 times 60 seconds. When a service announcer using 1083 these parameters unexpectedly dies immediately after sending the 1084 M_FLOOD, receivers would consider it expired 210 seconds later. When 1085 a receiver tries to connect to this dead service before this timeout, 1086 it will experience a failing connection and use that as an indication 1087 that the service is dead and select another instance of the same 1088 service instead. 1090 6.1.3.2. Renewal 1092 When performing renewal, the node SHOULD attempt to connect to the 1093 remembered EST server. If that fails, it SHOULD attempt to connect 1094 to an EST server learned via GRASP. The server with which 1095 certificate renewal succeeds SHOULD be remembered for the next 1096 renewal. 1098 Remembering the last renewal server and preferring it provides 1099 stickiness which can help diagnostics. It also provides some 1100 protection against off-path compromised ACP members announcing bogus 1101 information into GRASP. 1103 Renewal of certificates SHOULD start after less than 50% of the 1104 domain certificate lifetime so that network operations has ample time 1105 to investigate and resolve any problems that causes a node to not 1106 renew its domain certificate in time - and to allow prolonged periods 1107 of running parts of a network disconnected from any CA. 1109 6.1.3.3. Certificate Revocation Lists (CRLs) 1111 The ACP node SHOULD support Certificate Revocation Lists (CRL) via 1112 HTTPs from one or more CRL Distribution Points (CDPs). The CDP(s) 1113 MUST be indicated in the Domain Certificate when used. If the CDP 1114 URL uses an IPv6 address (ULA address when using the addressing rules 1115 specified in this document), the ACP node will connect to the CDP via 1116 the ACP. If the CDP URL uses an IPv6 address (ULA address when using 1117 the addressing rules specified in this document), the ACP node will 1118 connect to the CDP via the ACP. If the CDP uses a domain name, the 1119 ACP node will connect to the CDP via the Data-Plane. 1121 It is common to use domain names for CDP(s), but there is no 1122 requirement for the ACP to support DNS. Any DNS lookup in the Data- 1123 Plane is not only a possible security issue, but it would also not 1124 indicate whether the resolved address is meant to be reachable across 1125 the ACP. Therefore, the use of an IPv6 address versus the use of a 1126 DNS name doubles as an indicator whether or not to reach the CDP via 1127 the ACP. 1129 A CDP can be reachable across the ACP either by running it on a node 1130 with ACP or by connecting its node via an ACP connect interface (see 1131 Section 8.1). The CDP SHOULD use an ACP domain certificate for its 1132 HTTPs connections. The connecting ACP node SHOULD verify that the 1133 CDP certificate used during the HTTPs connection has the same ACP 1134 address as indicated in the CDP URL of the nodes ACP domain 1135 certificate 1137 6.1.3.4. Lifetimes 1139 Certificate lifetime may be set to shorter lifetimes than customary 1140 (1 year) because certificate renewal is fully automated via ACP and 1141 EST. The primary limiting factor for shorter certificate lifetimes 1142 is load on the EST server(s) and CA. It is therefore recommended 1143 that ACP domain certificates are managed via a CA chain where the 1144 assigning CA has enough performance to manage short lived 1145 certificates. See also Section 10.3.4 for discussion about an 1146 example setup achieving this. 1148 When certificate lifetimes are sufficiently short, such as few hours, 1149 certificate revocation may not be necessary, allowing to simplify the 1150 overall certificate maintenance infrastructure. 1152 See Section 10.1 for further optimizations of certificate maintenance 1153 when BRSKI can be used ("Bootstrapping Remote Secure Key 1154 Infrastructures", see [I-D.ietf-anima-bootstrapping-keyinfra]). 1156 6.1.3.5. Re-enrollment 1158 An ACP node may determine that its ACP domain certificate has 1159 expired, for example because the ACP node was powered down or 1160 disconnected longer than its certificate lifetime. In this case, the 1161 ACP node SHOULD convert to a role of a re-enrolling candidate ACP 1162 node. 1164 In this role, the node does maintain the trust anchor and certificate 1165 chain associated with its ACP domain certificate exclusively for the 1166 purpose of re-enrollment, and attempts (or waits) to get re-enrolled 1167 with a new ACP certificate. The details depend on the mechanisms/ 1168 protocols used by the ACP registrars. 1170 Please refer to Section 6.10.7 for explanations about ACP registrars 1171 and vouchers as used in the following text. 1173 When BRSKI is used (aka: on ACP nodes that are ANI nodes), the re- 1174 enrolling candidate ACP node would attempt to enroll like a candidate 1175 ACP node (BRSKI pledge), but instead of using the ACP nodes IDevID, 1176 it SHOULD first attempt to use its ACP domain certificate in the 1177 BRSKI TLS authentication. The BRSKI registrar MAY honor this 1178 certificate beyond its expiration date purely for the purpose of re- 1179 enrollment. Using the ACP nodes domain certificate allows the BRSKI 1180 registrar to learn that nodes ACP domain information field, so that 1181 the BRSKI registrar can re-assign the same ACP address information to 1182 the ACP node in the new ACP domain certificate. 1184 If the BRSKI registrar denies the use of the old ACP domain 1185 certificate, the re-enrolling candidate ACP node MUST re-attempt re- 1186 enrollment using its IDevID as defined in BRSKI during the TLS 1187 connection setup. 1189 Both when the BRSKI connection is attempted with the old ACP domain 1190 certificate or the IDevID, the re-enrolling candidate ACP node SHOULD 1191 authenticate the BRSKI registrar during TLS connection setup based on 1192 its existing trust anchor/certificate chain information associated 1193 with its old ACP certificate. The re-enrolling candidate ACP node 1194 SHOULD only request a voucher from the BRSKI registrar when this 1195 authentication fails during TLS connection setup. 1197 When other mechanisms than BRSKI are used for ACP domain certificate 1198 enrollment, the principles of the re-enrolling candidate ACP node are 1199 the same. The re-enrolling candidate ACP node attempts to 1200 authenticate any ACP registrar peers during re-enrollment protocol/ 1201 mechanisms via its existing certificate chain/trust anchor and 1202 provides its existing ACP domain certificate and other identification 1203 (such as the IDevID) as necessary to the registrar. 1205 Maintaining existing trust anchor information is especially important 1206 when enrollment mechanisms are used that unlike BRSKI do not leverage 1207 a voucher mechanism to authenticate the ACP registrar and where 1208 therefore the injection of certificate failures could otherwise make 1209 the ACP node easily attackable remotely. 1211 When using BRSKI or other protocol/mechanisms supporting vouchers, 1212 maintaining existing trust anchor information allows for re- 1213 enrollment of expired ACP certificates to be more lightweight, 1214 especially in environments where repeated acquisition of vouchers 1215 during the lifetime of ACP nodes may be operationally expensive or 1216 otherwise undesirable. 1218 6.1.3.6. Failing Certificates 1220 An ACP domain certificate is called failing in this document, if/when 1221 the ACP node can determine that it was revoked (or explicitly not 1222 renewed), or in the absence of such explicit local diagnostics, when 1223 the ACP node fails to connect to other ACP nodes in the same ACP 1224 domain using its ACP certificate. For connection failures to 1225 determine the ACP domain certificate as the culprit, the peer should 1226 pass the domain membership check (Section 6.1.2) and other reasons 1227 for the connection failure can be excluded because of the connection 1228 error diagnostics. 1230 This type of failure can happen during setup/refresh of a secure ACP 1231 channel connections or any other use of the ACP domain certificate, 1232 such as for the TLS connection to an EST server for the renewal of 1233 the ACP domain certificate. 1235 Example reasons for failing certificates that the ACP node can only 1236 discover through connection failure are that the domain certificate 1237 or any of its signing certificates could have been revoked or may 1238 have expired, but the ACP node can not self-diagnose this condition 1239 directly. Revocation information or clock synchronization may only 1240 be available across the ACP, but the ACP node can not build ACP 1241 secure channels because ACP peers reject the ACP node's domain 1242 certificate. 1244 ACP nodes SHOULD support the option to determines whether its ACP 1245 certificate is failing, and when it does, put itself into the role of 1246 a re-enrolling candidate ACP node as explained above 1247 (Section 6.1.3.5). 1249 6.2. ACP Adjacency Table 1251 To know to which nodes to establish an ACP channel, every ACP node 1252 maintains an adjacency table. The adjacency table contains 1253 information about adjacent ACP nodes, at a minimum: Node-ID 1254 (identifier of the node inside the ACP, see Section 6.10.3 and 1255 Section 6.10.5), interface on which neighbor was discovered (by GRASP 1256 as explained below), link-local IPv6 address of neighbor on that 1257 interface, certificate (including domain information field). An ACP 1258 node MUST maintain this adjacency table up to date. This table is 1259 used to determine to which neighbor an ACP connection is established. 1261 Where the next ACP node is not directly adjacent (i.e., not on a link 1262 connected to this node), the information in the adjacency table can 1263 be supplemented by configuration. For example, the Node-ID and IP 1264 address could be configured. 1266 The adjacency table MAY contain information about the validity and 1267 trust of the adjacent ACP node's certificate. However, subsequent 1268 steps MUST always start with authenticating the peer. 1270 The adjacency table contains information about adjacent ACP nodes in 1271 general, independently of their domain and trust status. The next 1272 step determines to which of those ACP nodes an ACP connection should 1273 be established. 1275 Interaction between ACP and other autonomic elements like GRASP (see 1276 below) or ASAs should be via an API that allows (appropriately access 1277 controlled) read/write access to the ACP Adjacency Table. 1278 Specification of such an API is subject to future work. 1280 6.3. Neighbor Discovery with DULL GRASP 1282 [RFC Editor: GRASP draft is in RFC editor queue, waiting for 1283 dependencies, including ACP. Please ensure that references to I- 1284 D.ietf-anima-grasp that include section number references (throughout 1285 this document) will be updated in case any last-minute changes in 1286 GRASP would make those section references change. 1288 DULL GRASP is a limited subset of GRASP intended to operate across an 1289 insecure link-local scope. See section 2.5.2 of 1290 [I-D.ietf-anima-grasp] for its formal definition. The ACP uses one 1291 instance of DULL GRASP for every L2 interface of the ACP node to 1292 discover link level adjacent candidate ACP neighbors. Unless 1293 modified by policy as noted earlier (Section 5 bullet point 2.), 1294 native interfaces (e.g., physical interfaces on physical nodes) 1295 SHOULD be initialized automatically enough, so that ACP discovery can 1296 be performed and any native interfaces with ACP neighbors can then be 1297 brought into the ACP even if the interface is otherwise not 1298 configured. Reception of packets on such otherwise not configured 1299 interfaces MUST be limited so that at first only IPv6 State Less 1300 Address Auto Configuration (SLAAC - [RFC4862]) and DULL GRASP work 1301 and then only the following ACP secure channel setup packets - but 1302 not any other unnecessary traffic (e.g., no other link-local IPv6 1303 transport stack responders for example). 1305 Note that the use of the IPv6 link-local multicast address 1306 (ALL_GRASP_NEIGHBORS) implies the need to use Multicast Listener 1307 Discovery Version 2 (MLDv2, see [RFC3810]) to announce the desire to 1308 receive packets for that address. Otherwise DULL GRASP could fail to 1309 operate correctly in the presence of MLD snooping, non-ACP enabled L2 1310 switches - because those would stop forwarding DULL GRASP packets. 1311 Switches not supporting MLD snooping simply need to operate as pure 1312 L2 bridges for IPv6 multicast packets for DULL GRASP to work. 1314 ACP discovery SHOULD NOT be enabled by default on non-native 1315 interfaces. In particular, ACP discovery MUST NOT run inside the ACP 1316 across ACP virtual interfaces. See Section 10.5 for further, non- 1317 normative suggestions on how to enable/disable ACP at node and 1318 interface level. See Section 8.2.2 for more details about tunnels 1319 (typical non-native interfaces). See Section 7 for how ACP should be 1320 extended on devices operating (also) as L2 bridges. 1322 Note: If an ACP node also implements BRSKI to enroll its ACP domain 1323 certificate (see Section 10.1 for a summary), then the above 1324 considerations also apply to GRASP discovery for BRSKI. Each DULL 1325 instance of GRASP set up for ACP is then also used for the discovery 1326 of a bootstrap proxy via BRSKI when the node does not have a domain 1327 certificate. Discovery of ACP neighbors happens only when the node 1328 does have the certificate. The node therefore never needs to 1329 discover both a bootstrap proxy and ACP neighbor at the same time. 1331 An ACP node announces itself to potential ACP peers by use of the 1332 "AN_ACP" objective. This is a synchronization objective intended to 1333 be flooded on a single link using the GRASP Flood Synchronization 1334 (M_FLOOD) message. In accordance with the design of the Flood 1335 message, a locator consisting of a specific link-local IP address, IP 1336 protocol number and port number will be distributed with the flooded 1337 objective. An example of the message is informally: 1339 Example: 1341 [M_FLOOD, 12340815, h'fe80000000000000c0011001FEEF0000, 210000, 1342 ["AN_ACP", 4, 1, "IKEv2" ], 1343 [O_IPv6_LOCATOR, 1344 h'fe80000000000000c0011001FEEF0000, UDP, 15000] 1345 ["AN_ACP", 4, 1, "DTLS" ], 1346 [O_IPv6_LOCATOR, 1347 h'fe80000000000000c0011001FEEF0000, UDP, 17000] 1348 ] 1350 Figure 5: GRASP AN_ACP example 1352 The formal CDDL definition is: 1354 flood-message = [M_FLOOD, session-id, initiator, ttl, 1355 +[objective, (locator-option / [])]] 1357 objective = ["AN_ACP", objective-flags, loop-count, 1358 objective-value] 1360 objective-flags = sync-only ; as in the GRASP specification 1361 sync-only = 4 ; M_FLOOD only requires synchronization 1362 loop-count = 1 ; limit to link-local operation 1363 objective-value = method 1364 method = "IKEv2" / "DTLS" ; or future methods 1366 Figure 6: GRASP AN_ACP definition 1368 The objective-flags field is set to indicate synchronization. 1370 The loop-count is fixed at 1 since this is a link-local operation. 1372 In the above example the RECOMMENDED period of sending of the 1373 objective is 60 seconds. The indicated ttl of 210000 msec means that 1374 the objective would be cached by ACP nodes even when two out of three 1375 messages are dropped in transit. 1377 The session-id is a random number used for loop prevention 1378 (distinguishing a message from a prior instance of the same message). 1379 In DULL this field is irrelevant but must still be set according to 1380 the GRASP specification. 1382 The originator MUST be the IPv6 link local address of the originating 1383 ACP node on the sending interface. 1385 The 'objective-value' parameter is a string indicating the secure 1386 channel protocol available at the specified or implied locator. 1388 The locator-option is optional and only required when the secure 1389 channel protocol is not offered at a well-defined port number, or if 1390 there is no well-defined port number. 1392 "IKEv2" is the abbreviation for "Internet Key Exchange protocol 1393 version 2", as defined in [RFC7296]. It is the main protocol used by 1394 the Internet IP security architecture ("IPsec", see [RFC4301]). We 1395 therefore use the term "IKEv2" and not "IPsec" in the GRASP 1396 definitions and example above. "IKEv2" has a well-defined port 1397 number 500, but in the above example, the candidate ACP neighbor is 1398 offering ACP secure channel negotiation via IKEv2 on port 15000 (for 1399 the sake of creating a non-standard example). 1401 If a locator is included, it MUST be an O_IPv6_LOCATOR, and the IPv6 1402 address MUST be the same as the initiator address (these are DULL 1403 requirements to minimize third party DoS attacks). 1405 The secure channel methods defined in this document use the objective 1406 values of "IKEv2" and "DTLS". There is no distinction between IKEv2 1407 native and GRE-IKEv2 because this is purely negotiated via IKEv2. 1409 A node that supports more than one secure channel protocol method 1410 needs to flood multiple versions of the "AN_ACP" objective so that 1411 each method can be accompanied by its own locator-option. This can 1412 use a single GRASP M_FLOOD message as shown in Figure 5. 1414 Note that a node serving both as an ACP node and BRSKI Join Proxy may 1415 choose to distribute the "AN_ACP" objective and the respective BRSKI 1416 in the same M_FLOOD message, since GRASP allows multiple objectives 1417 in one message. This may be impractical though if ACP and BRSKI 1418 operations are implemented via separate software modules / ASAs. 1420 The result of the discovery is the IPv6 link-local address of the 1421 neighbor as well as its supported secure channel protocols (and non- 1422 standard port they are running on). It is stored in the ACP 1423 Adjacency Table, see Section 6.2 which then drives the further 1424 building of the ACP to that neighbor. 1426 6.4. Candidate ACP Neighbor Selection 1428 An ACP node must determine to which other ACP nodes in the adjacency 1429 table it should build an ACP connection. This is based on the 1430 information in the ACP Adjacency table. 1432 The ACP is by default established exclusively between nodes in the 1433 same domain. This includes all routing subdomains. Section 10.10 1434 explains how ACP connections across multiple routing subdomains are 1435 special. 1437 Future extensions to this document including Intent can change this 1438 default behavior. Examples include: 1440 o Build the ACP across all domains that have a common parent domain. 1441 For example ACP nodes with domain "example.com", nodes of 1442 "example.com", "access.example.com", "core.example.com" and 1443 "city.core.example.com" could all establish one single ACP. 1445 o ACP connections across domains with different Certificate 1446 Authorities (CA) could establish a common ACP by installing the 1447 alternate domains' CA into the trusted anchor store. This is an 1448 executive management action that could easily be accomplished 1449 through the control channel created by the ACP. 1451 Since Intent is transported over the ACP, the first ACP connection a 1452 node establishes is always following the default behavior. See 1453 Section 10.10 for more details. 1455 The result of the candidate ACP neighbor selection process is a list 1456 of adjacent or configured autonomic neighbors to which an ACP channel 1457 should be established. The next step begins that channel 1458 establishment. 1460 6.5. Channel Selection 1462 To avoid attacks, initial discovery of candidate ACP peers cannot 1463 include any non-protected negotiation. To avoid re-inventing and 1464 validating security association mechanisms, the next step after 1465 discovering the address of a candidate neighbor can only be to try 1466 first to establish a security association with that neighbor using a 1467 well-known security association method. 1469 At this time in the lifecycle of ACP nodes, it is unclear whether it 1470 is feasible to even decide on a single MTI (mandatory to implement) 1471 security association protocol across all ACP nodes. 1473 From the use-cases it seems clear that not all type of ACP nodes can 1474 or need to connect directly to each other or are able to support or 1475 prefer all possible mechanisms. For example, code space limited IoT 1476 devices may only support DTLS ("datagram Transport Layer Security 1477 version 1.2", see [RFC6347]) because that code exists already on them 1478 for end-to-end security, but low-end in-ceiling L2 switches may only 1479 want to support Media Access Control Security (MacSec, see 802.1AE 1480 ([MACSEC]) because that is also supported in their chips. Only a 1481 flexible gateway device may need to support both of these mechanisms 1482 and potentially more. 1484 To support extensible secure channel protocol selection without a 1485 single common MTI protocol, ACP nodes must try all the ACP secure 1486 channel protocols it supports and that are feasible because the 1487 candidate ACP neighbor also announced them via its AN_ACP GRASP 1488 parameters (these are called the "feasible" ACP secure channel 1489 protocols). 1491 To ensure that the selection of the secure channel protocols always 1492 succeeds in a predictable fashion without blocking, the following 1493 rules apply: 1495 o An ACP node may choose to attempt initiate the different feasible 1496 ACP secure channel protocols it supports according to its local 1497 policies sequentially or in parallel, but it MUST support acting 1498 as a responder to all of them in parallel. 1500 o Once the first secure channel protocol succeeds, the two peers 1501 know each other's certificates because they must be used by all 1502 secure channel protocols for mutual authentication. The node with 1503 the lower Node-ID in the ACP address becomes Bob, the one with the 1504 higher Node-ID in the certificate Alice. 1506 o Bob becomes passive, he does not attempt to further initiate ACP 1507 secure channel protocols with Alice and does not consider it to be 1508 an error when Alice closes secure channels. Alice becomes the 1509 active party, continues to attempt setting up secure channel 1510 protocols with Bob until she arrives at the best one from her view 1511 that also works with Bob. 1513 For example, originally Bob could have been the initiator of one ACP 1514 secure channel protocol that Bob prefers and the security association 1515 succeeded. The roles of Bob and Alice are then assigned. At this 1516 stage, the protocol may not even have completed negotiating a common 1517 security profile. The protocol could for example be IPsec via IKEv2 1518 ("IP security", see [RFC4301] and "Internet Key Exchange protocol 1519 version 2", see [RFC7296]. It is now up to Alice to decide how to 1520 proceed. Even if the IPsec connection from Bob succeeded, Alice 1521 might prefer another secure protocol over IPsec (e.g., FOOBAR), and 1522 try to set that up with Bob. If that preference of Alice succeeds, 1523 she would close the IPsec connection. If no better protocol attempt 1524 succeeds, she would keep the IPsec connection. 1526 All this negotiation is in the context of an "L2 interface". Alice 1527 and Bob will build ACP connections to each other on every "L2 1528 interface" that they both connect to. An autonomic node must not 1529 assume that neighbors with the same L2 or link-local IPv6 addresses 1530 on different L2 interfaces are the same node. This can only be 1531 determined after examining the certificate after a successful 1532 security association attempt. 1534 6.6. Candidate ACP Neighbor verification 1536 Independent of the security association protocol chosen, candidate 1537 ACP neighbors need to be authenticated based on their domain 1538 certificate. This implies that any secure channel protocol MUST 1539 support certificate based authentication that can support the ACP 1540 domain membership check as defined in Section 6.1.2. If it fails, 1541 the connection attempt is aborted and an error logged. Attempts to 1542 reconnect MUST be throttled. The RECOMMENDED default is exponential 1543 backoff with a a minimum delay of 10 seconds and a maximum delay of 1544 640 seconds. 1546 6.7. Security Association protocols 1548 The following sections define the security association protocols that 1549 we consider to be important and feasible to specify in this document: 1551 6.7.1. ACP via IKEv2 1553 An ACP node announces its ability to support IKEv2 as the ACP secure 1554 channel protocol in GRASP as "IKEv2". 1556 6.7.1.1. Native IPsec 1558 To run ACP via IPsec natively, no further IANA assignments/ 1559 definitions are required. An ACP node that is supporting native 1560 IPsec MUST use IPsec security setup via IKEv2, tunnel mode, local and 1561 peer link-local IPv6 addresses used for encapsulation. It MUST then 1562 support ESP with AES256 for encryption and SHA256 hash and MUST NOT 1563 permit weaker crypto options. 1565 In terms of IKEv2, this means the initiator will offer to support 1566 IPsec tunnel mode with next protocol equal 41 (IPv6). 1568 IPsec tunnel mode is required because the ACP will route/forward 1569 packets received from any other ACP node across the ACP secure 1570 channels, and not only its own generated ACP packets. With IPsec 1571 transport mode, it would only be possible to send packets originated 1572 by the ACP node itself. 1574 ESP is used because ACP mandates the use of encryption for ACP secure 1575 channels. 1577 6.7.1.2. IPsec with GRE encapsulation 1579 In network devices it is often more common to implement high 1580 performance virtual interfaces on top of GRE encapsulation than on 1581 top of a "native" IPsec association (without any other encapsulation 1582 than those defined by IPsec). On those devices it may be beneficial 1583 to run the ACP secure channel on top of GRE protected by the IPsec 1584 association. 1586 To run ACP via GRE/IPsec, no further IANA assignments/definitions are 1587 required. An ACP node that is supporting ACP via GRE/IPsec MUST then 1588 support IPsec security setup via IKEv2, IPsec transport mode, local 1589 and peer link-local IPv6 addresses used for encapsulation, ESP with 1590 AES256 encryption and SHA256 hash. 1592 When GRE is used, transport mode is sufficient because the routed ACP 1593 packets are not "tunneled" by IPsec but rather by GRE: IPsec only has 1594 to deal with the GRE/IP packet which always uses the local and peer 1595 link-local IPv6 addresses and is therefore applicable to transport 1596 mode. 1598 ESP is used because ACP mandates the use of encryption for ACP secure 1599 channels. 1601 In terms of IKEv2 negotiation, this means the initiator must offer to 1602 support IPsec transport mode with next protocol equal to GRE (47) 1603 followed by the offer for native IPsec as described above (because 1604 that option is mandatory to support). 1606 If IKEv2 initiator and responder support GRE, it will be selected. 1607 The version of GRE to be used must the according to [RFC7676]. 1609 6.7.2. ACP via DTLS 1611 We define the use of ACP via DTLS in the assumption that it is likely 1612 the first transport encryption code basis supported in some classes 1613 of constrained devices. 1615 To run ACP via UDP and DTLS v1.2 [RFC6347] a locally assigned UDP 1616 port is used that is announced as a parameter in the GRASP AN_ACP 1617 objective to candidate neighbors. All ACP nodes supporting DTLS as a 1618 secure channel protocol MUST support AES256 encryption and MUST NOT 1619 permit weaker crypto options. 1621 There is no additional session setup or other security association 1622 besides this simple DTLS setup. As soon as the DTLS session is 1623 functional, the ACP peers will exchange ACP IPv6 packets as the 1624 payload of the DTLS transport connection. Any DTLS defined security 1625 association mechanisms such as re-keying are used as they would be 1626 for any transport application relying solely on DTLS. 1628 6.7.3. ACP Secure Channel Requirements 1630 A baseline ACP node MUST support IPsec natively and MAY support IPsec 1631 via GRE. A constrained ACP node that can not support IPsec MUST 1632 support DTLS. ACP nodes connecting constrained areas with baseline 1633 areas MUST therefore support IPsec and DTLS. 1635 ACP nodes need to specify in documentation the set of secure ACP 1636 mechanisms they support. 1638 An ACP secure channel MUST immediately be terminated when the 1639 lifetime of any certificate in the chain used to authenticate the 1640 neighbor expires or becomes revoked. Note that this is not standard 1641 behavior in secure channel protocols such as IPsec because the 1642 certificate authentication only influences the setup of the secure 1643 channel in these protocols. 1645 6.8. GRASP in the ACP 1647 6.8.1. GRASP as a core service of the ACP 1649 The ACP MUST run an instance of GRASP inside of it. It is a key part 1650 of the ACP services. The function in GRASP that makes it fundamental 1651 as a service of the ACP is the ability to provide ACP wide service 1652 discovery (using objectives in GRASP). 1654 ACP provides IP unicast routing via the RPL routing protocol (see 1655 Section 6.11). 1657 The ACP does not use IP multicast routing nor does it provide generic 1658 IP multicast services (the handling of GRASP link-local multicast 1659 messages is explained in Section 6.8.2). Instead, the ACP provides 1660 service discovery via the objective discovery/announcement and 1661 negotiation mechanisms of the ACP GRASP instance (services are a form 1662 of objectives). These mechanisms use hop-by-hop reliable flooding of 1663 GRASP messages for both service discovery (GRASP M_DISCOVERY 1664 messages) and service announcement (GRASP M_FLOOD messages). 1666 See Section 10.8 for more discussion about this design choice of the 1667 ACP and considerations for possible future variations. 1669 6.8.2. ACP as the Security and Transport substrate for GRASP 1671 In the terminology of GRASP ([I-D.ietf-anima-grasp]), the ACP is the 1672 security and transport substrate for the GRASP instance run inside 1673 the ACP ("ACP GRASP"). 1675 This means that the ACP is responsible for ensuring that this 1676 instance of GRASP is only sending messages across the ACP GRASP 1677 virtual interfaces. Whenever the ACP adds or deletes such an 1678 interface because of new ACP secure channels or loss thereof, the ACP 1679 needs to indicate this to the ACP instance of GRASP. The ACP exists 1680 also in the absence of any active ACP neighbors. It is created when 1681 the node has a domain certificate, and continues to exist even if all 1682 of its neighbors cease operation. 1684 In this case ASAs using GRASP running on the same node would still 1685 need to be able to discover each other's objectives. When the ACP 1686 does not exist, ASAs leveraging the ACP instance of GRASP via APIs 1687 MUST still be able to operate, and MUST be able to understand that 1688 there is no ACP and that therefore the ACP instance of GRASP can not 1689 operate. 1691 The way ACP acts as the security and transport substrate for GRASP is 1692 visualized in the following picture: 1694 [RFC Editor: please try to put the following picture on a single page 1695 and remove this note. We cannot figure out how to do this with XML. 1696 The picture does fit on a single page.] 1698 ACP: 1699 ............................................................... 1700 . . 1701 . /-GRASP-flooding-\ ACP GRASP instance . 1702 . / \ . 1703 . GRASP GRASP GRASP . 1704 . link-local unicast link-local . 1705 . multicast messages multicast . 1706 . messages | messages . 1707 . | | | . 1708 ............................................................... 1709 . v v v ACP security and transport . 1710 . | | | substrate for GRASP . 1711 . | | | . 1712 . | ACP GRASP | - ACP GRASP . 1713 . | Loopback | Loopback interface . 1714 . | interface | - ACP-cert auth . 1715 . | TLS | . 1716 . ACP GRASP | ACP GRASP - ACP GRASP virtual . 1718 . subnet1 | subnet2 virtual interfaces . 1719 . TCP | TCP . 1720 . | | | . 1721 ............................................................... 1722 . | | | ^^^ Users of ACP (GRASP/ASA) . 1723 . | | | ACP interfaces/addressing . 1724 . | | | . 1725 . | | | . 1726 . | ACP-Loopback Interf.| <- ACP Loopback interface . 1727 . | ACP-address | - address (global ULA) . 1728 . subnet1 | subnet2 <- ACP virtual interfaces . 1729 . link-local | link-local - link-local addresses . 1730 ............................................................... 1731 . | | | ACP routing and forwarding . 1732 . | RPL-routing | . 1733 . | /IP-Forwarding\ | . 1734 . | / \ | . 1735 . ACP IPv6 packets ACP IPv6 packets . 1736 . |/ \| . 1737 . IPsec/DTLS IPsec/DTLS - ACP-cert auth . 1738 ............................................................... 1739 | | Data-Plane 1740 | | 1741 | | - ACP secure channel 1742 link-local link-local - encapsulation addresses 1743 subnet1 subnet2 - Data-Plane interfaces 1744 | | 1745 ACP-Nbr1 ACP-Nbr2 1747 Figure 7: ACP as security and transport substrate for GRASP 1749 GRASP unicast messages inside the ACP always use the ACP address. 1750 Link-local ACP addresses must not be used inside objectives. GRASP 1751 unicast messages inside the ACP are transported via TLS 1.2 1752 ([RFC5246]) connections with AES256 encryption and SHA256. Mutual 1753 authentication uses the ACP domain membership check defined in 1754 (Section 6.1.2). 1756 GRASP link-local multicast messages are targeted for a specific ACP 1757 virtual interface (as defined Section 6.12.5) but are sent by the ACP 1758 into an ACP GRASP virtual interface that is constructed from the TCP 1759 connection(s) to the IPv6 link-local neighbor address(es) on the 1760 underlying ACP virtual interface. If the ACP GRASP virtual interface 1761 has two or more neighbors, the GRASP link-local multicast messages 1762 are replicated to all neighbor TCP connections. 1764 TLS and TLS connections for GRASP in the ACP use the IANA assigned 1765 TCP port for GRASP (7107). Effectively the transport stack is 1766 expected to be TLS for connections from/to the ACP address (e.g., 1767 global scope address(es)) and TCP for connections from/to link-local 1768 addresses on the ACP virtual interfaces. The latter ones are only 1769 used for flooding of GRASP messages. 1771 6.8.2.1. Discussion 1773 TCP encapsulation for GRASP M_DISCOVERY and M_FLOOD link local 1774 messages is used because these messages are flooded across 1775 potentially many hops to all ACP nodes and a single link with even 1776 temporary packet loss issues (e.g., WiFi/Powerline link) can reduce 1777 the probability for loss free transmission so much that applications 1778 would want to increase the frequency with which they send these 1779 messages. Such shorter periodic retransmission of datagrams would 1780 result in more traffic and processing overhead in the ACP than the 1781 hop-by-hop reliable retransmission mechanism by TCP and duplicate 1782 elimination by GRASP. 1784 TLS is mandated for GRASP non-link-local unicast because the ACP 1785 secure channel mandatory authentication and encryption protects only 1786 against attacks from the outside but not against attacks from the 1787 inside: Compromised ACP members that have (not yet) been detected and 1788 removed (e.g., via domain certificate revocation / expiry). 1790 If GRASP peer connections would just use TCP, compromised ACP members 1791 could simply eavesdrop passively on GRASP peer connections for whom 1792 they are on-path ("Man In The Middle" - MITM). Or intercept and 1793 modify them. With TLS, it is not possible to completely eliminate 1794 problems with compromised ACP members, but attacks are a lot more 1795 complex: 1797 Eavesdropping/spoofing by a compromised ACP node is still possible 1798 because in the model of the ACP and GRASP, the provider and consumer 1799 of an objective have initially no unique information (such as an 1800 identity) about the other side which would allow them to distinguish 1801 a benevolent from a compromised peer. The compromised ACP node would 1802 simply announce the objective as well, potentially filter the 1803 original objective in GRASP when it is a MITM and act as an 1804 application level proxy. This of course requires that the 1805 compromised ACP node understand the semantics of the GRASP 1806 negotiation to an extent that allows it to proxy it without being 1807 detected, but in an ACP environment this is quite likely public 1808 knowledge or even standardized. 1810 The GRASP TLS connections are run like any other ACP traffic through 1811 the ACP secure channels. This leads to double authentication/ 1812 encryption. Future work optimizations could avoid this but it is 1813 unclear how beneficial/feasible this is: 1815 o The security considerations for GRASP change against attacks from 1816 non-ACP (e.g., "outside") nodes: TLS is subject to reset attacks 1817 while secure channel protocols may be not (e.g., IPsec is not). 1819 o The secure channel method may leverage hardware acceleration and 1820 there may be little or no gain in eliminating it. 1822 o The GRASP TLS connections need to implement any additional 1823 security options that are required for secure channels. For 1824 example the closing of connections when the peers certificate has 1825 expired. 1827 6.9. Context Separation 1829 The ACP is in a separate context from the normal Data-Plane of the 1830 node. This context includes the ACP channels' IPv6 forwarding and 1831 routing as well as any required higher layer ACP functions. 1833 In classical network system, a dedicated so called Virtual routing 1834 and forwarding instance (VRF) is one logical implementation option 1835 for the ACP. If possible by the systems software architecture, 1836 separation options that minimize shared components are preferred, 1837 such as a logical container or virtual machine instance. The context 1838 for the ACP needs to be established automatically during bootstrap of 1839 a node. As much as possible it should be protected from being 1840 modified unintentionally by ("Data-Plane") configuration. 1842 Context separation improves security, because the ACP is not 1843 reachable from the global routing table. Also, configuration errors 1844 from the Data-Plane setup do not affect the ACP. 1846 6.10. Addressing inside the ACP 1848 The channels explained above typically only establish communication 1849 between two adjacent nodes. In order for communication to happen 1850 across multiple hops, the autonomic control plane requires ACP 1851 network wide valid addresses and routing. Each ACP node must create 1852 a Loopback interface with an ACP network wide unique address inside 1853 the ACP context (as explained in in Section 6.9). This address may 1854 be used also in other virtual contexts. 1856 With the algorithm introduced here, all ACP nodes in the same routing 1857 subdomain have the same /48 ULA prefix. Conversely, ULA global IDs 1858 from different domains are unlikely to clash, such that two ACP 1859 networks can be merged, as long as the policy allows that merge. See 1860 also Section 9.1 for a discussion on merging domains. 1862 Links inside the ACP only use link-local IPv6 addressing, such that 1863 each nodes ACP only requires one routable virtual address. 1865 6.10.1. Fundamental Concepts of Autonomic Addressing 1867 o Usage: Autonomic addresses are exclusively used for self- 1868 management functions inside a trusted domain. They are not used 1869 for user traffic. Communications with entities outside the 1870 trusted domain use another address space, for example normally 1871 managed routable address space (called "Data-Plane" in this 1872 document). 1874 o Separation: Autonomic address space is used separately from user 1875 address space and other address realms. This supports the 1876 robustness requirement. 1878 o Loopback-only: Only ACP Loopback interfaces (and potentially those 1879 configured for "ACP connect", see Section 8.1) carry routable 1880 address(es); all other interfaces (called ACP virtual interfaces) 1881 only use IPv6 link local addresses. The usage of IPv6 link local 1882 addressing is discussed in [RFC7404]. 1884 o Use-ULA: For Loopback interfaces of ACP nodes, we use Unique Local 1885 Addresses (ULA), as defined in [RFC4193] with L=1 (as defined in 1886 section 3.1 of [RFC4193]). Note that the random hash for ACP 1887 Loopback addresses uses the definition in Section 6.10.2 and not 1888 the one of [RFC4193] section 3.2.2. 1890 o No external connectivity: They do not provide access to the 1891 Internet. If a node requires further reaching connectivity, it 1892 should use another, traditionally managed address scheme in 1893 parallel. 1895 o Addresses in the ACP are permanent, and do not support temporary 1896 addresses as defined in [RFC4941]. 1898 o Addresses in the ACP are not considered sensitive on privacy 1899 grounds because ACP nodes are not expected to be end-user devices. 1900 Therefore, ACP addresses do not need to be pseudo-random as 1901 discussed in [RFC7721]. Because they are not propagated to 1902 untrusted (non ACP) nodes and stay within a domain (of trust), we 1903 also consider them not to be subject to scanning attacks. 1905 The ACP is based exclusively on IPv6 addressing, for a variety of 1906 reasons: 1908 o Simplicity, reliability and scale: If other network layer 1909 protocols were supported, each would have to have its own set of 1910 security associations, routing table and process, etc. 1912 o Autonomic functions do not require IPv4: Autonomic functions and 1913 autonomic service agents are new concepts. They can be 1914 exclusively built on IPv6 from day one. There is no need for 1915 backward compatibility. 1917 o OAM protocols do not require IPv4: The ACP may carry OAM 1918 protocols. All relevant protocols (SNMP, TFTP, SSH, SCP, Radius, 1919 Diameter, ...) are available in IPv6. See also [RFC8368] for how 1920 ACP could be made to interoperate with IPv4 only OAM. 1922 6.10.2. The ACP Addressing Base Scheme 1924 The Base ULA addressing scheme for ACP nodes has the following 1925 format: 1927 8 40 2 78 1928 +--+-------------------------+------+------------------------------+ 1929 |fd| hash(routing-subdomain) | Type | (sub-scheme) | 1930 +--+-------------------------+------+------------------------------+ 1932 Figure 8: ACP Addressing Base Scheme 1934 The first 48 bits follow the ULA scheme, as defined in [RFC4193], to 1935 which a type field is added: 1937 o "fd" identifies a locally defined ULA address. 1939 o The 40 bits ULA "global ID" (term from [RFC4193]) for ACP 1940 addresses carried in the domain information field of domain 1941 certificates are the first 40 bits of the SHA256 hash of the 1942 routing subdomain from the same domain information field. In the 1943 example of Section 6.1.1, the routing subdomain is 1944 "area51.research.acp.example.com" and the 40 bits ULA "global ID" 1945 89b714f3db. 1947 o To allow for extensibility, the fact that the ULA "global ID" is a 1948 hash of the routing subdomain SHOULD NOT be assumed by any ACP 1949 node during normal operations. The hash function is only executed 1950 during the creation of the certificate. If BRSKI is used then the 1951 BRSKI registrar will create the domain information field in 1952 response to the EST Certificate Signing Request (CSR) Attribute 1953 Request message by the pledge. 1955 o Type: This field allows different address sub-schemes. This 1956 addresses the "upgradability" requirement. Assignment of types 1957 for this field will be maintained by IANA. 1959 The sub-scheme may imply a range or set of addresses assigned to the 1960 node, this is called the ACP address range/set and explained in each 1961 sub-scheme. 1963 Please refer to Section 6.10.7 and Section 10.4 for further 1964 explanations why the following Sub-Addressing schemes are used and 1965 why multiple are necessary. 1967 6.10.3. ACP Zone Addressing Sub-Scheme 1969 The sub-scheme defined here is defined by the Type value 00b (zero) 1970 in the base scheme and 0 in the Z bit. 1972 64 64 1973 +-----------------+---+---------++-----------------------------+---+ 1974 | (base scheme) | Z | Zone-ID || Node-ID | 1975 | | | || Registrar-ID | Node-Number| V | 1976 +-----------------+---+---------++--------------+--------------+---+ 1977 50 1 13 48 15 1 1979 Figure 9: ACP Zone Addressing Sub-Scheme 1981 The fields are defined as follows: 1983 o Zone-ID: If set to all zero bits: The Node-ID bits are used as an 1984 identifier (as opposed to a locator). This results in a non- 1985 hierarchical, flat addressing scheme. Any other value indicates a 1986 zone. See Section 6.10.3.1 on how this field is used in detail. 1988 o Z: MUST be 0. 1990 o Node-ID: A unique value for each node. 1992 The 64 bit Node-ID is derived and composed as follows: 1994 o Registrar-ID (48 bit): A number unique inside the domain that 1995 identifies the ACP registrar which assigned the Node-ID to the 1996 node. A MAC address of the ACP registrar can be used for this 1997 purpose. 1999 o Node-Number: A number which is unique for a given ACP registrar, 2000 to identify the node. This can be a sequentially assigned number. 2002 o V (1 bit): Virtualization bit: 0: Indicates the ACP itself ("ACP 2003 node base system); 1: Indicates the optional "host" context on the 2004 ACP node (see below). 2006 In the ACP Zone Addressing Sub-Scheme, the ACP address in the 2007 certificate has Zone-ID and V fields as all zero bits. The ACP 2008 address set includes addresses with any Zone-ID value and any V 2009 value. 2011 The "Node-ID" itself is unique in a domain (i.e., the Zone-ID is not 2012 required for uniqueness). Therefore, a node can be addressed either 2013 as part of a flat hierarchy (Zone-ID = 0), or with an aggregation 2014 scheme (any other Zone-ID). An address with Zone-ID = 0 is an 2015 identifier, with a Zone-ID !=0 it is a locator. See Section 6.10.3.1 2016 for more details. 2018 The Virtual bit in this sub-scheme allows the easy addition of the 2019 ACP as a component to existing systems without causing problems in 2020 the port number space between the services in the ACP and the 2021 existing system. V:0 is the ACP router (autonomic node base system), 2022 V:1 is the host with pre-existing transport endpoints on it that 2023 could collide with the transport endpoints used by the ACP router. 2024 The ACP host could for example have a p2p virtual interface with the 2025 V:0 address as its router into the ACP. Depending on the software 2026 design of ASAs, which is outside the scope of this specification, 2027 they may use the V:0 or V:1 address. 2029 The location of the V bit(s) at the end of the address allows the 2030 announcement of a single prefix for each ACP node. For example, in a 2031 network with 20,000 ACP nodes, this avoid 20,000 additional routes in 2032 the routing table. 2034 6.10.3.1. Usage of the Zone-ID Field 2036 The Zone-ID allows for the introduction of structure in the 2037 addressing scheme. 2039 Zone-ID = 0 is the default addressing scheme in an ACP domain. Every 2040 ACP node with a Zone Addressing Sub-Scheme address MUST respond to 2041 its ACP address with Zone-ID = 0. Used on its own this leads to a 2042 non-hierarchical address scheme, which is suitable for networks up to 2043 a certain size. Zone-ID = 0 addresses act as identifiers for the 2044 nodes, and aggregation of these address in the ACP routing table is 2045 not possible. 2047 If aggregation is required, the 13 bit Zone-ID value allows for up to 2048 8191 zones. The allocation of Zone-ID's may either happen 2049 automatically through a to-be-defined algorithm; or it could be 2050 configured and maintained explicitly. 2052 If a node learns through a future autonomic method or through 2053 configuration that it is part of a zone, it MUST also respond to its 2054 ACP address with that Zone-ID. In this case the ACP Loopback is 2055 configured with two ACP addresses: One for Zone-ID = 0 and one for 2056 the assigned Zone-ID. This method allows for a smooth transition 2057 between a flat addressing scheme and an hierarchical one. 2059 A node knowing it is in a zone MUST also use that Zone-ID != 0 2060 address in GRASP locator fields. This eliminates the use of the 2061 identifier address (Zone-ID = 0) in forwarding and the need for 2062 network wide reachability of those non-aggregatable identifier 2063 addresses. Zone-ID != 0 addresses are assumed to be aggregatable in 2064 routing/forwarding based on how they are allocated in the ACP 2065 topology (subject to future work). 2067 Note: Theoretically, the 13 bits for the Zone-ID would allow also for 2068 two levels of zones, introducing a sub-hierarchy. We do not think 2069 this is required at this point, but a new type could be used in the 2070 future to support such a scheme. 2072 Note: The Zone-ID is one method to introduce structure or hierarchy 2073 into the ACP. Another way is the use of the routing subdomain field 2074 in the ACP that leads to multiple /48 Global IDs within an ACP 2075 domain. This gives future work two options to consider. 2077 Note: Zones and Zone-ID as defined here are not related to [RFC4007] 2078 zones or zone_id. ACP zone addresses are not scoped (reachable only 2079 from within an RFC4007 zone) but reachable across the whole ACP. An 2080 RFC4007 zone_id is a zone index that has only local significance on a 2081 node, whereas an ACP Zone-ID is an identifier for an ACP zone that is 2082 unique across that ACP. 2084 6.10.4. ACP Manual Addressing Sub-Scheme 2086 The sub-scheme defined here is defined by the Type value 00b (zero) 2087 in the base scheme and 1 in the Z bit. 2089 64 64 2090 +---------------------+---+----------++-----------------------------+ 2091 | (base scheme) | Z | Subnet-ID|| Interface Identifier | 2092 +---------------------+---+----------++-----------------------------+ 2093 50 1 13 2095 Figure 10: ACP Manual Addressing Sub-Scheme 2097 The fields are defined as follows: 2099 o Subnet-ID: Configured subnet identifier. 2101 o Z: MUST be 1. 2103 o Interface Identifier. 2105 This sub-scheme is meant for "manual" allocation to subnets where the 2106 other addressing schemes cannot be used. The primary use case is for 2107 assignment to ACP connect subnets (see Section 8.1.1). 2109 "Manual" means that allocations of the Subnet-ID need to be done 2110 today with pre-existing, non-autonomic mechanisms. Every subnet that 2111 uses this addressing sub-scheme needs to use a unique Subnet-ID 2112 (unless some anycast setup is done). Future work may define 2113 mechanisms for auto-coordination between ACP nodes and auto- 2114 allocation of Subnet-IDs between them. 2116 The Z bit field was added to distinguish Zone addressing and manual 2117 addressing sub-schemes without requiring one more bit in the base 2118 scheme and therefore allowing for the Vlong scheme (described below) 2119 to have one more bit available. 2121 Manual addressing sub-scheme addresses SHOULD only be used in domain 2122 certificates assigned to nodes that cannot fully participate in the 2123 automatic establishment of ACP secure channels or ACP routing. The 2124 intended use are nodes connecting to the ACP via an ACP edge node and 2125 ACP connect interfaces (see Section 8.1) - such as legacy NOC 2126 equipment. They would not use their domain certificate for ACP 2127 secure channel creation and therefore do not need to participate in 2128 ACP routing either. They would use the certificate for 2129 authentication of any transport services. The value of the Interface 2130 Identifier is left for future definitions. 2132 6.10.5. ACP Vlong Addressing Sub-Scheme 2134 The sub-scheme defined here is defined by the Type value 01b (one) in 2135 the base scheme. 2137 50 78 2138 +---------------------++-----------------------------+----------+ 2139 | (base scheme) || Node-ID | 2140 | || Registrar-ID | Node-Number| V | 2141 +---------------------++--------------+--------------+----------+ 2142 50 46 24/16 8/16 2144 Figure 11: ACP Vlong Addressing Sub-Scheme 2146 This addressing scheme foregoes the Zone-ID field to allow for 2147 larger, flatter routed networks (e.g., as in IoT) with 8421376 Node- 2148 Numbers (2^23+2^15). It also allows for up to 2^16 (i.e. 65536) 2149 different virtualized addresses within a node, which could be used to 2150 address individual software components in an ACP node. 2152 The fields are the same as in the Zone-ID sub-scheme with the 2153 following refinements: 2155 o V: Virtualization bit: Values 0 and 1 are assigned in the same way 2156 as in the Zone-ID sub-scheme. 2158 o Registrar-ID: To maximize Node-Number and V, the Registrar-ID is 2159 reduced to 46 bits. This still permits the use of the MAC address 2160 of an ACP registrar by removing the V and U bits from the 48 bits 2161 of a MAC address (those two bits are never unique, so they cannot 2162 be used to distinguish MAC addresses). 2164 o If the first bit of the "Node-Number" is "1", then the Node-Number 2165 is 16 bit long and the V field is 16 bit long. Otherwise the 2166 Node-Number is 24 bit long and the V field is 8 bit long. 2168 "0" bit Node-Numbers are intended to be used for "general purpose" 2169 ACP nodes that would potentially have a limited number (< 256) of 2170 clients (ASA/Autonomic Functions or legacy services) of the ACP that 2171 require separate V(irtual) addresses. "1" bit Node-Numbers are 2172 intended for ACP nodes that are ACP edge nodes (see Section 8.1.1) or 2173 that have a large number of clients requiring separate V(irtual) 2174 addresses. For example large SDN controllers with container modular 2175 software architecture (see Section 8.1.2). 2177 In the Vlong addressing sub-scheme, the ACP address in the 2178 certificate has all V field bits as zero. The ACP address set for 2179 the node includes any V value. 2181 6.10.6. Other ACP Addressing Sub-Schemes 2183 Before further addressing sub-schemes are defined, experience with 2184 the schemes defined here should be collected. The schemes defined in 2185 this document have been devised to allow hopefully sufficiently 2186 flexible setup of ACPs for a variety of situation. These reasons 2187 also lead to the fairly liberal use of address space: The Zone 2188 Addressing Sub-Scheme is intended to enable optimized routing in 2189 large networks by reserving bits for Zone-ID's. The Vlong addressing 2190 sub-scheme enables the allocation of 8/16 bit of addresses inside 2191 individual ACP nodes. Both address spaces allow distributed, 2192 uncoordinated allocation of node addresses by reserving bits for the 2193 registrar-ID field in the address. 2195 IANA is asked need to assign a new "type" for each new addressing 2196 sub-scheme. With the current allocations, only 2 more schemes are 2197 possible, so the last addressing scheme should consider making 2198 provisions provision for further extensions (e.g., by reserving bits 2199 from it for further extensions). 2201 6.10.7. ACP Registrars 2203 The ACP address prefix is assigned to the ACP node during enrollment/ 2204 provisioning of the ACP domain certificate to the ACP node. It is 2205 intended to persist unchanged through the lifetime of the ACP node. 2207 Because of the ACP addressing sub-schemes explained above, ACP nodes 2208 for a single ACP domain can be enrolled by multiple distributed and 2209 uncoordinated entities called ACP registrars. These ACP registrars 2210 are responsible to enroll ACP domain certificates and associated 2211 trust anchor(s) to candidate ACP nodes and are also responsible that 2212 an ACP domain information field is included in the ACP domain 2213 certificate. 2215 6.10.7.1. Use of BRSKI or other Mechanism/Protocols 2217 Any protocols or mechanisms may be used as ACP registrars, as long as 2218 the resulting ACP certificate and trust anchors allow to perform the 2219 ACP domain membership described in Section 6.1.2 with other ACP 2220 domain members, and meet the ACP addressing requirements for its ACP 2221 domain information field as described further below in this section. 2223 An ACP registrar could be a person deciding whether to enroll a 2224 candidate ACP node and then orchestrating the enrollment of the ACP 2225 certificate and associated trust anchor, using command line or web 2226 based commands on the candidate ACP node and trust anchor to generate 2227 and sign the ACP domain certificate and configure certificate and 2228 trust anchors onto the node. 2230 The only currently defined protocol for ACP registrars is BRSKI 2231 ([I-D.ietf-anima-bootstrapping-keyinfra]). When BRSKI is used, the 2232 ACP nodes are called ANI nodes, and the ACP registrars are called 2233 BRSKI or ANI registrars. The BRSKI specification does not define the 2234 handling of the ACP domain information field because the rules do not 2235 depend on BRSKI but apply equally to any protocols/mechanisms an ACP 2236 registrar may use. 2238 6.10.7.2. Unique Address/Prefix allocation 2240 ACP registrars MUST NOT allocate ACP address prefixes to ACP nodes 2241 via the ACP domain information field that would collide with the ACP 2242 address prefixes of other ACP nodes in the same ACP domain. This 2243 includes both prefixes allocated by the same ACP registrar to 2244 different ACP nodes as well as prefixes allocated by other ACP 2245 registrars for the same ACP domain. 2247 For this purpose, an ACP registrar MUST have one or more unique 46 2248 bit identifiers called Registrar-IDs used to allocate ACP address 2249 prefixes. The lower 46 bits of a EUI-48 MAC addresses are globally 2250 unique 46 bit identifiers, so ACP registrars with known unique EUI-48 2251 MAC addresses can use these as Registrar-IDs. Registrar-IDs do not 2252 need to be globally unique but only unique across the set of ACP 2253 registrars for an ACP domain, so other means to assign unique 2254 Registrar-IDs to ACP registrars can be used, such as configuration on 2255 the ACP registrars. 2257 When the candidate ACP device (called Pledge in BRSKI) is to be 2258 enrolled into an ACP domain, the ACP registrar needs to allocate a 2259 unique ACP address to the node and ensure that the ACP certificate 2260 gets a domain information field (Section 6.1.1) with the appropriate 2261 information - ACP domain-name, ACP-address, and so on. If the ACP 2262 registrar uses BRSKI, it signals the ACP information field to the 2263 Pledge via the EST /csraddrs command (see 2264 [I-D.ietf-anima-bootstrapping-keyinfra], section 5.8.2 - "EST CSR 2265 Attributes"). 2267 [RFC editor: please update reference to section 5.8.2 accordingly 2268 with latest BRSKI draft at time of publishing, or RFC] 2270 6.10.7.3. Addressing Sub-Scheme Policies 2272 The ACP registrar selects for the candidate ACP node a unique address 2273 prefix from an appropriate ACP addressing sub-scheme, either a zone 2274 addressing sub-scheme prefix (see Section 6.10.3), or a Vlong 2275 addressing sub-scheme prefix (see Section 6.10.5). The assigned ACP 2276 address prefix encoded in the domain information field of the ACP 2277 domain certificate indicates to the ACP node its ACP address 2278 information. The sub-addressing scheme indicates the prefix length: 2279 /126 for zone address sub-scheme, /120 or /112 for Vlong address sub- 2280 scheme. The first address of the prefix is the ACP address, all 2281 other addresses in the prefix are for other uses by the ACP node as 2282 described in the zone and Vlong addressing sub scheme sections. The 2283 ACP address prefix itself is then signaled by the ACP node into the 2284 ACP routing protocol (see Section 6.11) to establish IPv6 2285 reachability across the ACP. 2287 The choice of addressing sub-scheme and prefix-length in the Vlong 2288 address sub-scheme is subject to ACP registrar policy. It could be 2289 an ACP domain wide policy, or a per ACP node or per ACP node type 2290 policy. For example, in BRSKI, the ACP registrar is aware of the 2291 IDevID of the candidate ACP node, which contains a serialNnumber that 2292 is typically indicating the nodes vendor and device type and can be 2293 used to drive a policy selecting an appropriate addressing sub-scheme 2294 for the (class of) node(s). 2296 ACP registrars SHOULD default to allocate ACP zone sub-address scheme 2297 addresses with Subnet-ID 0. Allocation and use of zone sub-addresses 2298 with Subnet-ID != 0 is outside the scope of this specification 2299 because it would need to go along with rules for extending ACP 2300 routing to multiple zones, which is outside the scope of this 2301 specification. 2303 ACP registrars that can use the IDevID of a candidate ACP device 2304 SHOULD be able to choose the zone vs. Vlong sub-address scheme for 2305 ACP nodes based on the serialNumber of the IDevID, for example by the 2306 PID (Product Identifier) part which identifies the product type, or 2307 the complete serialNumber. 2309 In a simple allocation scheme, an ACP registrar remembers 2310 persistently across reboots for its currently used Registrar-ID and 2311 for each addressing scheme (zone with Subnet-ID 0, Vlong with /112, 2312 Vlong with /120), the next Node-Number available for allocation and 2313 increases it after successful enrollment to an ACP node. In this 2314 simple allocation scheme, the ACP registrar would not recycle ACP 2315 address prefixes from no longer used ACP nodes. 2317 6.10.7.4. Address/Prefix Persistence 2319 When an ACP domain certificate is renewed or rekeyed via EST or other 2320 mechanisms, the ACP address/prefix in the ACP domain information 2321 field MUST be maintained unless security issues or violations of the 2322 unique address assignment requirements exist or are suspected by the 2323 ACP registrar. Even when the renewing/rekeying ACP registrar is not 2324 the same as the one that enrolled the prior ACP certificate. See 2325 Section 10.3.4 for an example. ACP address information SHOULD also 2326 be maintained even after an ACP certificate did expire or failed. 2327 See Section 6.1.3.5 and Section 6.1.3.6. 2329 6.10.7.5. Further Details 2331 Section 10.3 discusses further non-normative details of ACP 2332 registrars: What interactions registrars need, what parameters they 2333 require, certificate renewal and limitations, use of sub-CAs on 2334 registrars and centralized policy control. 2336 6.11. Routing in the ACP 2338 Once ULA address are set up all autonomic entities should run a 2339 routing protocol within the autonomic control plane context. This 2340 routing protocol distributes the ULA created in the previous section 2341 for reachability. The use of the autonomic control plane specific 2342 context eliminates the probable clash with the global routing table 2343 and also secures the ACP from interference from the configuration 2344 mismatch or incorrect routing updates. 2346 The establishment of the routing plane and its parameters are 2347 automatic and strictly within the confines of the autonomic control 2348 plane. Therefore, no explicit configuration is required. 2350 All routing updates are automatically secured in transit as the 2351 channels of the autonomic control plane are by default secured, and 2352 this routing runs only inside the ACP. 2354 The routing protocol inside the ACP is RPL ([RFC6550]). See 2355 Section 10.7 for more details on the choice of RPL. 2357 RPL adjacencies are set up across all ACP channels in the same domain 2358 including all its routing subdomains. See Section 10.10 for more 2359 details. 2361 6.11.1. RPL Profile 2363 The following is a description of the RPL profile that ACP nodes need 2364 to support by default. The format of this section is derived from 2365 draft-ietf-roll-applicability-template. 2367 6.11.1.1. Summary 2369 In summary, the profile chosen for RPL is one that expects a fairly 2370 reliable network reasonably fast links so that RPL convergence will 2371 be triggered immediately upon recognition of link failure/recovery. 2373 The key limitation of the chosen profile is that it is designed to 2374 not require any Data-Plane artifacts (such as [RFC6553]). While the 2375 senders/receivers of ACP packets can be legacy NOC devices connected 2376 via ACP connect (see Section 8.1.1 to the ACP, their connectivity can 2377 be handled as non-RPL-aware leafs (or "Internet") according to the 2378 Data-Plane architecture explained in [I-D.ietf-roll-useofrplinfo]. 2379 This non-artifact profile is largely driven by the desire to avoid 2380 introducing the required Hop-by-Hop headers into the ACP forwarding 2381 plane, especially to support devices with silicon forwarding planes 2382 that can not support insertion/removal of these headers in silicon. 2384 In this profile choice, RPL has no Data-Plane artifacts. A simple 2385 destination prefix based upon the routing table is used. A 2386 consequence of supporting only a single instanceID that is containing 2387 one Destination Oriented Directed Acyclic Graph (DODAG), the ACP will 2388 only accommodate only a single class of routing table and cannot 2389 create optimized routing paths to accomplish latency or energy goals. 2391 Consider a network that has multiple NOCs in different locations. 2392 Only one NOC will become the DODAG root. Other NOCs will have to 2393 send traffic through the DODAG (tree) rooted in the primary NOC. 2394 Depending on topology, this can be an annoyance from a latency point 2395 of view, but it does not represent a single point of failure, as the 2396 DODAG can reconfigure itself when it detects data plane forwarding 2397 failures. 2399 The lack of RPL Packet Information (RPI, the IPv6 header for RPL 2400 defined by [RFC6553]), means that the Data-Plane will have no rank 2401 value that can be used to detect loops. As a result, traffic may 2402 loop until the TTL of the packet reaches zero. This the same 2403 behavior as that of other IGPs that do not have the Data-Plane 2404 options as RPL. 2406 Since links in the ACP are assumed to be mostly reliable (or have 2407 link layer protection against loss) and because there is no stretch 2408 according to Section 6.11.1.7, loops should be exceedingly rare 2409 though. 2411 There are a variety of mechanisms possible in RPL to further avoid 2412 temporary loops: DODAG Information Objects (DIOs) SHOULD be sent 2413 2...3 times to inform children when losing the last parent. The 2414 technique in [RFC6550] section 8.2.2.6. (Detaching) SHOULD be 2415 favored over that in section 8.2.2.5., (Poisoning) because it allows 2416 local connectivity. Nodes SHOULD select more than one parent, at 2417 least 3 if possible, and send Destination Advertisement Objects 2418 (DAO)s to all of then in parallel. 2420 Additionally, failed ACP tunnels will be detected by IKEv2 Dead Peer 2421 Detection (which can function as a replacement for a Low-power and 2422 Lossy Networks' (LLN's) Expected Transmission Count (ETX). A failure 2423 of an ACP tunnel should signal the RPL control plane to pick a 2424 different parent. 2426 Future Extensions to this RPL profile can provide optimality for 2427 multiple NOCs. This requires utilizing Data-Plane artifact including 2428 IPinIP encap/decap on ACP routers and processing of IPv6 RPI headers. 2429 Alternatively, (Src,Dst) routing table entries could be used. A 2430 decision for the preferred technology would have to be done when such 2431 extension is defined. 2433 6.11.1.2. RPL Instances 2435 Single RPL instance. Default RPLInstanceID = 0. 2437 6.11.1.3. Storing vs. Non-Storing Mode 2439 RPL Mode of Operations (MOP): MUST support mode 2 - "Storing Mode of 2440 Operations with no multicast support". Implementations MAY support 2441 mode 3 ("... with multicast support" as that is a superset of mode 2442 2). Note: Root indicates mode in DIO flow. 2444 6.11.1.4. DAO Policy 2446 Proactive, aggressive DAO state maintenance: 2448 o Use K-flag in unsolicited DAO indicating change from previous 2449 information (to require DAO-ACK). 2451 o Retry such DAO DAO-RETRIES(3) times with DAO- ACK_TIME_OUT(256ms) 2452 in between. 2454 6.11.1.5. Path Metric 2456 Hopcount. 2458 6.11.1.6. Objective Function 2460 Objective Function (OF): Use OF0 [RFC6552]. No use of metric 2461 containers. 2463 rank_factor: Derived from link speed: <= 100Mbps: 2464 LOW_SPEED_FACTOR(5), else HIGH_SPEED_FACTOR(1) 2466 6.11.1.7. DODAG Repair 2468 Global Repair: we assume stable links and ranks (metrics), so no need 2469 to periodically rebuild DODAG. DODAG version only incremented under 2470 catastrophic events (e.g., administrative action). 2472 Local Repair: As soon as link breakage is detected, send No-Path DAO 2473 for all the targets that where reachable only via this link. As soon 2474 as link repair is detected, validate if this link provides you a 2475 better parent. If so, compute your new rank, and send new DIO that 2476 advertises your new rank. Then send a DAO with a new path sequence 2477 about yourself. 2479 stretch_rank: none provided ("not stretched"). 2481 Data Path Validation: Not used. 2483 Trickle: Not used. 2485 6.11.1.8. Multicast 2487 Not used yet but possible because of the selected mode of operations. 2489 6.11.1.9. Security 2491 [RFC6550] security not used, substituted by ACP security. 2493 6.11.1.10. P2P communications 2495 Not used. 2497 6.11.1.11. IPv6 address configuration 2499 Every ACP node (RPL node) announces an IPv6 prefix covering the 2500 address(es) used in the ACP node. The prefix length depends on the 2501 chosen addressing sub-scheme of the ACP address provisioned into the 2502 certificate of the ACP node, e.g., /127 for Zone Addressing Sub- 2503 Scheme or /112 or /120 for Vlong addressing sub-scheme. See 2504 Section 6.10 for more details. 2506 Every ACP node MUST install a black hole (aka null) route for 2507 whatever ACP address space that it advertises (i.e.: the /96 or 2508 /127). This is avoid routing loops for addresses that an ACP node 2509 has not (yet) used. 2511 6.11.1.12. Administrative parameters 2513 Administrative Preference ([RFC6550], 3.2.6 - to become root): 2514 Indicated in DODAGPreference field of DIO message. 2516 o Explicit configured "root": 0b100 2518 o ACP registrar (Default): 0b011 2520 o ACP-connect (non-registrar): 0b010 2522 o Default: 0b001. 2524 6.11.1.13. RPL Data-Plane artifacts 2526 RPI (RPL Packet Information [RFC6553]): Not used as there is only a 2527 single instance, and data path validation is not being used. 2529 SRH (RPL Source Routing - RFC6552): Not used. Storing mode is being 2530 used. 2532 6.11.1.14. Unknown Destinations 2534 Because RPL minimizes the size of the routing and forwarding table, 2535 prefixes reachable through the same interface as the RPL root are not 2536 known on every ACP node. Therefore traffic to unknown destination 2537 addresses can only be discovered at the RPL root. The RPL root 2538 SHOULD have attach safe mechanisms to operationally discover and log 2539 such packets. 2541 6.12. General ACP Considerations 2543 Since channels are by default established between adjacent neighbors, 2544 the resulting overlay network does hop by hop encryption. Each node 2545 decrypts incoming traffic from the ACP, and encrypts outgoing traffic 2546 to its neighbors in the ACP. Routing is discussed in Section 6.11. 2548 6.12.1. Performance 2550 There are no performance requirements against ACP implementations 2551 defined in this document because the performance requirements depend 2552 on the intended use case. It is expected that full autonomic node 2553 with a wide range of ASA can require high forwarding plane 2554 performance in the ACP, for example for telemetry, but that 2555 determination is for future work. Implementations of ACP to solely 2556 support traditional/SDN style use cases can benefit from ACP at lower 2557 performance, especially if the ACP is used only for critical 2558 operations, e.g., when the Data-Plane is not available. See 2559 [RFC8368] for more details. 2561 6.12.2. Addressing of Secure Channels in the Data-Plane 2563 In order to be independent of the Data-Plane configuration of global 2564 IPv6 subnet addresses (that may not exist when the ACP is brought 2565 up), Link-local secure channels MUST use IPv6 link local addresses 2566 between adjacent neighbors. The fully autonomic mechanisms in this 2567 document only specify these link-local secure channels. Section 8.2 2568 specifies extensions in which secure channels are tunnels. For 2569 those, this requirement does not apply. 2571 The Link-local secure channels specified in this document therefore 2572 depend on basic IPv6 link-local functionality to be auto-enabled by 2573 the ACP and prohibiting the Data-Plane from disabling it. The ACP 2574 also depends on being able to operate the secure channel protocol 2575 (e.g., IPsec / DTLS) across IPv6 link-local addresses, something that 2576 may be an uncommon profile. Functionally, these are the only 2577 interactions with the Data-Plane that the ACP needs to have. 2579 To mitigate these interactions with the Data-Plane, extensions to 2580 this document may specify additional layer 2 or layer encapsulations 2581 for ACP secure channels as well as other protocols to auto-discover 2582 peer endpoints for such encapsulations (e.g., tunneling across L3 or 2583 use of L2 only encapsulations). 2585 6.12.3. MTU 2587 The MTU for ACP secure channels must be derived locally from the 2588 underlying link MTU minus the secure channel encapsulation overhead. 2590 ACP secure Channel protocols do not need to perform MTU discovery 2591 because they are built across L2 adjacencies - the MTU on both sides 2592 connecting to the L2 connection are assumed to be consistent. 2593 Extensions to ACP where the ACP is for example tunneled need to 2594 consider how to guarantee MTU consistency. This is an issue of 2595 tunnels, not an issue of running the ACP across a tunnel. Transport 2596 stacks running across ACP can perform normal PMTUD (Path MTU 2597 Discovery). Because the ACP is meant to be prioritize reliability 2598 over performance, they MAY opt to only expect IPv6 minimum MTU (1280) 2599 to avoid running into PMTUD implementation bugs or underlying link 2600 MTU mismatch problems. 2602 6.12.4. Multiple links between nodes 2604 If two nodes are connected via several links, the ACP SHOULD be 2605 established across every link, but it is possible to establish the 2606 ACP only on a sub-set of links. Having an ACP channel on every link 2607 has a number of advantages, for example it allows for a faster 2608 failover in case of link failure, and it reflects the physical 2609 topology more closely. Using a subset of links (for example, a 2610 single link), reduces resource consumption on the node, because state 2611 needs to be kept per ACP channel. The negotiation scheme explained 2612 in Section 6.5 allows Alice (the node with the higher ACP address) to 2613 drop all but the desired ACP channels to Bob - and Bob will not re- 2614 try to build these secure channels from his side unless Alice shows 2615 up with a previously unknown GRASP announcement (e.g., on a different 2616 link or with a different address announced in GRASP). 2618 6.12.5. ACP interfaces 2620 The ACP VRF has conceptually two type of interfaces: The "ACP 2621 Loopback interface(s)" to which the ACP ULA address(es) are assigned 2622 and the "ACP virtual interfaces" that are mapped to the ACP secure 2623 channels. 2625 The term "Loopback interface" was introduced initially to refer to an 2626 internal interface on a node that would allow IP traffic between 2627 transport endpoints on the node in the absence or failure of any or 2628 all external interfaces, see [RFC4291] section 2.5.3. 2630 Even though Loopback interfaces were originally designed to hold only 2631 Loopback addresses not reachable from outside the node, these 2632 interfaces are also commonly used today to hold addresses reachable 2633 from the outside. They are meant to be reachable independent of any 2634 external interface being operational, and therefore to be more 2635 resilient. These addresses on Loopback interfaces can be thought of 2636 as "node addresses" instead of "interface addresses", and that is 2637 what ACP address(es) are. This construct makes it therefore possible 2638 to address ACP nodes with a well-defined set of addresses independent 2639 of the number of external interfaces. 2641 For these reason, the ACP (ULA) address(es) are assigned to Loopback 2642 interface(s). 2644 ACP secure channels, e.g., IPsec, DTLS or other future security 2645 associations with neighboring ACP nodes can be mapped to ACP virtual 2646 interfaces in different ways: 2648 ACP point-to-point virtual interface: 2650 Each ACP secure channel is mapped into a separate point-to-point ACP 2651 virtual interface. If a physical subnet has more than two ACP 2652 capable nodes (in the same domain), this implementation approach will 2653 lead to a full mesh of ACP virtual interfaces between them. 2655 ACP multi-access virtual interface: 2657 In a more advanced implementation approach, the ACP will construct a 2658 single multi-access ACP virtual interface for all ACP secure channels 2659 to ACP capable nodes reachable across the same underlying (physical) 2660 subnet. IPv6 link-local multicast packets sent into an ACP multi- 2661 access virtual interface are replicated to every ACP secure channel 2662 mapped into the ACP multicast-access virtual interface. IPv6 unicast 2663 packets sent into an ACP multi-access virtual interface are sent to 2664 the ACP secure channel that belongs to the ACP neighbor that is the 2665 next-hop in the ACP forwarding table entry used to reach the packets 2666 destination address. 2668 There is no requirement for all ACP nodes on the same multi-access 2669 subnet to use the same type of ACP virtual interface. This is purely 2670 a node local decision. 2672 ACP nodes MUST perform standard IPv6 operations across ACP virtual 2673 interfaces including SLAAC (Stateless Address Auto-Configuration) - 2674 [RFC4862]) to assign their IPv6 link local address on the ACP virtual 2675 interface and ND (Neighbor Discovery - [RFC4861]) to discover which 2676 IPv6 link-local neighbor address belongs to which ACP secure channel 2677 mapped to the ACP virtual interface. This is independent of whether 2678 the ACP virtual interface is point-to-point or multi-access. 2680 "Optimistic Duplicate Address Detection (DAD)" according to [RFC4429] 2681 is RECOMMENDED because the likelihood for duplicates between ACP 2682 nodes is highly improbable as long as the address can be formed from 2683 a globally unique local assigned identifier (e.g., EUI-48/EUI-64, see 2684 below). 2686 ACP nodes MAY reduce the amount of link-local IPv6 multicast packets 2687 from ND by learning the IPv6 link-local neighbor address to ACP 2688 secure channel mapping from other messages such as the source address 2689 of IPv6 link-local multicast RPL messages - and therefore forego the 2690 need to send Neighbor Solicitation messages. 2692 The ACP virtual interface IPv6 link local address can be derived from 2693 any appropriate local mechanism such as node local EUI-48 or EUI-64 2694 ("EUI" stands for "Extended Unique Identifier"). It MUST NOT depend 2695 on something that is attackable from the Data-Plane such as the IPv6 2696 link-local address of the underlying physical interface, which can be 2697 attacked by SLAAC, or parameters of the secure channel encapsulation 2698 header that may not be protected by the secure channel mechanism. 2700 The link-layer address of an ACP virtual interface is the address 2701 used for the underlying interface across which the secure tunnels are 2702 built, typically Ethernet addresses. Because unicast IPv6 packets 2703 sent to an ACP virtual interface are not sent to a link-layer 2704 destination address but rather an ACP secure channel, the link-layer 2705 address fields SHOULD be ignored on reception and instead the ACP 2706 secure channel from which the message was received should be 2707 remembered. 2709 Multi-access ACP virtual interfaces are preferable implementations 2710 when the underlying interface is a (broadcast) multi-access subnet 2711 because they do reflect the presence of the underlying multi-access 2712 subnet into the virtual interfaces of the ACP. This makes it for 2713 example simpler to build services with topology awareness inside the 2714 ACP VRF in the same way as they could have been built running 2715 natively on the multi-access interfaces. 2717 Consider also the impact of point-to-point vs. multi-access virtual 2718 interface on the efficiency of flooding via link local multicasted 2719 messages: 2721 Assume a LAN with three ACP neighbors, Alice, Bob and Carol. Alice's 2722 ACP GRASP wants to send a link-local GRASP multicast message to Bob 2723 and Carol. If Alice's ACP emulates the LAN as one point-to-point 2724 virtual interface to Bob and one to Carol, The sending applications 2725 itself will send two copies, if Alice's ACP emulates a LAN, GRASP 2726 will send one packet and the ACP will replicate it. The result is 2727 the same. The difference happens when Bob and Carol receive their 2728 packet. If they use ACP point-to-point virtual interfaces, their 2729 GRASP instance would forward the packet from Alice to each other as 2730 part of the GRASP flooding procedure. These packets are unnecessary 2731 and would be discarded by GRASP on receipt as duplicates (by use of 2732 the GRASP Session ID). If Bob and Charly's ACP would emulate a 2733 multi-access virtual interface, then this would not happen, because 2734 GRASPs flooding procedure does not replicate back packets to the 2735 interface that they were received from. 2737 Note that link-local GRASP multicast messages are not sent directly 2738 as IPv6 link-local multicast UDP messages into ACP virtual 2739 interfaces, but instead into ACP GRASP virtual interfaces, that are 2740 layered on top of ACP virtual interfaces to add TCP reliability to 2741 link-local multicast GRASP messages. Nevertheless, these ACP GRASP 2742 virtual interfaces perform the same replication of message and, 2743 therefore, result in the same impact on flooding. See Section 6.8.2 2744 for more details. 2746 RPL does support operations and correct routing table construction 2747 across non-broadcast multi-access (NBMA) subnets. This is common 2748 when using many radio technologies. When such NBMA subnets are used, 2749 they MUST NOT be represented as ACP multi-access virtual interfaces 2750 because the replication of IPv6 link-local multicast messages will 2751 not reach all NBMA subnet neighbors. In result, GRASP message 2752 flooding would fail. Instead, each ACP secure channel across such an 2753 interface MUST be represented as a ACP point-to-point virtual 2754 interface. These requirements can be avoided by coupling the ACP 2755 flooding mechanism for GRASP messages directly to RPL (flood GRASP 2756 across DODAG), but such an enhancement is subject for future work. 2758 Care must also be taken when creating multi-access ACP virtual 2759 interfaces across ACP secure channels between ACP nodes in different 2760 domains or routing subdomains. The policies to be negotiated may be 2761 described as peer-to-peer policies in which case it is easier to 2762 create ACP point-to-point virtual interfaces for these secure 2763 channels. 2765 7. ACP support on L2 switches/ports (Normative) 2767 7.1. Why 2769 ANrtr1 ------ ANswitch1 --- ANswitch2 ------- ANrtr2 2770 .../ \ \ ... 2771 ANrtrM ------ \ ------- ANrtrN 2772 ANswitchM ... 2774 Figure 12: Topology with L2 ACP switches 2776 Consider a large L2 LAN with ANrtr1...ANrtrN connected via some 2777 topology of L2 switches. Examples include large enterprise campus 2778 networks with an L2 core, IoT networks or broadband aggregation 2779 networks which often have even a multi-level L2 switched topology. 2781 If the discovery protocol used for the ACP is operating at the subnet 2782 level, every ACP router will see all other ACP routers on the LAN as 2783 neighbors and a full mesh of ACP channels will be built. If some or 2784 all of the AN switches are autonomic with the same discovery 2785 protocol, then the full mesh would include those switches as well. 2787 A full mesh of ACP connections like this can creates fundamental 2788 scale challenges. The number of security associations of the secure 2789 channel protocols will likely not scale arbitrarily, especially when 2790 they leverage platform accelerated encryption/decryption. Likewise, 2791 any other ACP operations (such as routing) needs to scale to the 2792 number of direct ACP neighbors. An ACP router with just 4 physical 2793 interfaces might be deployed into a LAN with hundreds of neighbors 2794 connected via switches. Introducing such a new unpredictable scaling 2795 factor requirement makes it harder to support the ACP on arbitrary 2796 platforms and in arbitrary deployments. 2798 Predictable scaling requirements for ACP neighbors can most easily be 2799 achieved if in topologies like these, ACP capable L2 switches can 2800 ensure that discovery messages terminate on them so that neighboring 2801 ACP routers and switches will only find the physically connected ACP 2802 L2 switches as their candidate ACP neighbors. With such a discovery 2803 mechanism in place, the ACP and its security associations will only 2804 need to scale to the number of physical interfaces instead of a 2805 potentially much larger number of "LAN-connected" neighbors. And the 2806 ACP topology will follow directly the physical topology, something 2807 which can then also be leveraged in management operations or by ASAs. 2809 In the example above, consider ANswitch1 and ANswitchM are ACP 2810 capable, and ANswitch2 is not ACP capable. The desired ACP topology 2811 is that ANrtr1 and ANrtrM only have an ACP connection to ANswitch1, 2812 and that ANswitch1, ANrtr2, ANrtrN have a full mesh of ACP connection 2813 amongst each other. ANswitch1 also has an ACP connection with 2814 ANswitchM and ANswitchM has ACP connections to anything else behind 2815 it. 2817 7.2. How (per L2 port DULL GRASP) 2819 To support ACP on L2 switches or L2 switched ports of an L3 device, 2820 it is necessary to make those L2 ports look like L3 interfaces for 2821 the ACP implementation. This primarily involves the creation of a 2822 separate DULL GRASP instance/domain on every such L2 port. Because 2823 GRASP has a dedicated link-local IPv6 multicast address 2824 (ALL_GRASP_NEIGHBORS), it is sufficient that all packets for this 2825 address are being extracted at the port level and passed to that DULL 2826 GRASP instance. Likewise the IPv6 link-local multicast packets sent 2827 by that DULL GRASP instance need to be sent only towards the L2 port 2828 for this DULL GRASP instance. 2830 If the device with L2 ports is supporting per L2 port ACP DULL GRASP 2831 as well as MLD snooping ([RFC4541]), then MLD snooping must be 2832 changed to never forward packets for ALL_GRASP_NEIGHBORS because that 2833 would cause the problem that per L2 port ACP DULL GRASP is meant to 2834 overcome (forwarding DULL GRASP packets across L2 ports). 2836 The rest of ACP operations can operate in the same way as in L3 2837 devices: Assume for example that the device is an L3/L2 hybrid device 2838 where L3 interfaces are assigned to VLANs and each VLAN has 2839 potentially multiple ports. DULL GRASP is run as described 2840 individually on each L2 port. When it discovers a candidate ACP 2841 neighbor, it passes its IPv6 link-local address and supported secure 2842 channel protocols to the ACP secure channel negotiation that can be 2843 bound to the L3 (VLAN) interface. It will simply use link-local IPv6 2844 multicast packets to the candidate ACP neighbor. Once a secure 2845 channel is established to such a neighbor, the virtual interface to 2846 which this secure channel is mapped should then actually be the L2 2847 port and not the L3 interface to best map the actual physical 2848 topology into the ACP virtual interfaces. See Section 6.12.5 for 2849 more details about how to map secure channels into ACP virtual 2850 interfaces. Note that a single L2 port can still have multiple ACP 2851 neighbors if it connect for example to multiple ACP neighbors via a 2852 non-ACP enabled switch. The per L2 port ACP virtual interface can 2853 therefore still be a multi-access virtual LAN. 2855 For example, in the above picture, ANswitch1 would run separate DULL 2856 GRASP instances on its ports to ANrtr1, ANswitch2 and ANswitchI, even 2857 though all those three ports may be in the data plane in the same 2858 (V)LAN and perform L2 switching between these ports, ANswitch1 would 2859 perform ACP L3 routing between them. 2861 The description in the previous paragraph was specifically meant to 2862 illustrate that on hybrid L3/L2 devices that are common in 2863 enterprise, IoT and broadband aggregation, there is only the GRASP 2864 packet extraction (by Ethernet address) and GRASP link-local 2865 multicast per L2-port packet injection that has to consider L2 ports 2866 at the hardware forwarding level. The remaining operations are 2867 purely ACP control plane and setup of secure channels across the L3 2868 interface. This hopefully makes support for per-L2 port ACP on those 2869 hybrid devices easy. 2871 This L2/L3 optimized approach is subject to "address stealing", e.g., 2872 where a device on one port uses addresses of a device on another 2873 port. This is a generic issue in L2 LANs and switches often already 2874 have some form of "port security" to prohibit this. They rely on NDP 2875 or DHCP learning of which port/MAC-address and IPv6 address belong 2876 together and block duplicates. This type of function needs to be 2877 enabled to prohibit DoS attacks. Likewise the GRASP DULL instance 2878 needs to ensure that the IPv6 address in the locator-option matches 2879 the source IPv6 address of the DULL GRASP packet. 2881 In devices without such a mix of L2 port/interfaces and L3 interfaces 2882 (to terminate any transport layer connections), implementation 2883 details will differ. Logically most simply every L2 port is 2884 considered and used as a separate L3 subnet for all ACP operations. 2885 The fact that the ACP only requires IPv6 link-local unicast and 2886 multicast should make support for it on any type of L2 devices as 2887 simple as possible, but the need to support secure channel protocols 2888 may be a limiting factor to supporting ACP on such devices. Future 2889 options such as MacSec could improve that situation. 2891 A generic issue with ACP in L2 switched networks is the interaction 2892 with the Spanning Tree Protocol. Ideally, the ACP should be built 2893 also across ports that are blocked in STP so that the ACP does not 2894 depend on STP and can continue to run unaffected across STP topology 2895 changes (where re-convergence can be quite slow). The above 2896 described simple implementation options are not sufficient for this. 2897 Instead they would simply have the ACP run across the active STP 2898 topology and the ACP would equally be interrupted and re-converge 2899 with STP changes. 2901 8. Support for Non-ACP Components (Normative) 2903 8.1. ACP Connect 2905 8.1.1. Non-ACP Controller / NMS system 2907 The Autonomic Control Plane can be used by management systems, such 2908 as controllers or network management system (NMS) hosts (henceforth 2909 called simply "NMS hosts"), to connect to devices (or other type of 2910 nodes) through it. For this, an NMS host must have access to the 2911 ACP. The ACP is a self-protecting overlay network, which allows by 2912 default access only to trusted, autonomic systems. Therefore, a 2913 traditional, non-ACP NMS system does not have access to the ACP by 2914 default, just like any other external node. 2916 If the NMS host is not autonomic, i.e., it does not support autonomic 2917 negotiation of the ACP, then it can be brought into the ACP by 2918 explicit configuration. To support connections to adjacent non-ACP 2919 nodes, an ACP node must support "ACP connect" (sometimes also called 2920 "autonomic connect"): 2922 "ACP connect" is a function on an autonomic node that is called an 2923 "ACP edge node". With "ACP connect", interfaces on the node can be 2924 configured to be put into the ACP VRF. The ACP is then accessible to 2925 other (NOC) systems on such an interface without those systems having 2926 to support any ACP discovery or ACP channel setup. This is also 2927 called "native" access to the ACP because to those (NOC) systems the 2928 interface looks like a normal network interface (without any 2929 encryption/novel-signaling). 2931 Data-Plane "native" (no ACP) 2932 . 2933 +--------+ +----------------+ . +-------------+ 2934 | ACP | |ACP Edge Node | . | | 2935 | Node | | | v | | 2936 | |-------|...[ACP VRF]....+-----------------| |+ 2937 | | ^ |. | | NOC Device || 2938 | | . | .[Data-Plane]..+-----------------| "NMS hosts" || 2939 | | . | [ ] | . ^ | || 2940 +--------+ . +----------------+ . . +-------------+| 2941 . . . +-------------+ 2942 . . . 2943 Data-Plane "native" . ACP "native" (unencrypted) 2944 + ACP auto-negotiated . "ACP connect subnet" 2945 and encrypted . 2946 ACP connect interface 2947 e.g., "vrf ACP native" (config) 2949 Figure 13: ACP connect 2951 ACP connect has security consequences: All systems and processes 2952 connected via ACP connect have access to all ACP nodes on the entire 2953 ACP, without further authentication. Thus, the ACP connect interface 2954 and (NOC) systems connected to it must be physically controlled/ 2955 secured. For this reason the mechanisms described here do explicitly 2956 not include options to allow for a non-ACP router to be connected 2957 across an ACP connect interface and addresses behind such a router 2958 routed inside the ACP. 2960 An ACP connect interface provides exclusively access to only the ACP. 2961 This is likely insufficient for many NMS hosts. Instead, they would 2962 require a second "Data-Plane" interface outside the ACP for 2963 connections between the NMS host and administrators, or Internet 2964 based services, or for direct access to the Data-Plane. The document 2965 "Using Autonomic Control Plane for Stable Connectivity of Network 2966 OAM" [RFC8368] explains in more detail how the ACP can be integrated 2967 in a mixed NOC environment. 2969 The ACP connect interface must be (auto-)configured with an IPv6 2970 address prefix. Is prefix SHOULD be covered by one of the (ULA) 2971 prefix(es) used in the ACP. If using non-autonomic configuration, it 2972 SHOULD use the ACP Manual Addressing Sub-Scheme (Section 6.10.4). It 2973 SHOULD NOT use a prefix that is also routed outside the ACP so that 2974 the addresses clearly indicate whether it is used inside the ACP or 2975 not. 2977 The prefix of ACP connect subnets MUST be distributed by the ACP edge 2978 node into the ACP routing protocol (RPL). The NMS hosts MUST connect 2979 to prefixes in the ACP routing table via its ACP connect interface. 2980 In the simple case where the ACP uses only one ULA prefix and all ACP 2981 connect subnets have prefixes covered by that ULA prefix, NMS hosts 2982 can rely on [RFC6724] - The NMS host will select the ACP connect 2983 interface because any ACP destination address is best matched by the 2984 address on the ACP connect interface. If the NMS hosts ACP connect 2985 interface uses another prefix or if the ACP uses multiple ULA 2986 prefixes, then the NMS hosts require (static) routes towards the ACP 2987 interface. 2989 ACP Edge Nodes MUST only forward IPv6 packets received from an ACP 2990 connect interface into the ACP that has an IPv6 address from the ACP 2991 prefix assigned to this interface (sometimes called "RPF filtering"). 2992 This MAY be changed through administrative measures. 2994 To limit the security impact of ACP connect, nodes supporting it 2995 SHOULD implement a security mechanism to allow configuration/use of 2996 ACP connect interfaces only on nodes explicitly targeted to be 2997 deployed with it (such as those physically secure locations like a 2998 NOC). For example, the certificate of such node could include an 2999 extension required to permit configuration of ACP connect interfaces. 3000 This prohibits that a random ACP node with easy physical access that 3001 is not meant to run ACP connect could start leaking the ACP when it 3002 becomes compromised and the intruder configures ACP connect on it. 3003 The full workflow including the mechanism by which an ACP registrar 3004 would select which node to give such a certificate to is subject to 3005 future work. 3007 8.1.2. Software Components 3009 The ACP connect mechanism be only be used to connect physically 3010 external systems (NMS hosts) to the ACP but also other applications, 3011 containers or virtual machines. In fact, one possible way to 3012 eliminate the security issue of the external ACP connect interface is 3013 to collocate an ACP edge node and an NMS host by making one a virtual 3014 machine or container inside the other; and therefore converting the 3015 unprotected external ACP subnet into an internal virtual subnet in a 3016 single device. This would ultimately result in a fully ACP enabled 3017 NMS host with minimum impact to the NMS hosts software architecture. 3018 This approach is not limited to NMS hosts but could equally be 3019 applied to devices consisting of one or more VNF (virtual network 3020 functions): An internal virtual subnet connecting out-of-band 3021 management interfaces of the VNFs to an ACP edge router VNF. 3023 The core requirement is that the software components need to have a 3024 network stack that permits access to the ACP and optionally also the 3025 Data-Plane. Like in the physical setup for NMS hosts this can be 3026 realized via two internal virtual subnets. One that is connecting to 3027 the ACP (which could be a container or virtual machine by itself), 3028 and one (or more) connecting into the Data-Plane. 3030 This "internal" use of ACP connect approach should not considered to 3031 be a "workaround" because in this case it is possible to build a 3032 correct security model: It is not necessary to rely on unprovable 3033 external physical security mechanisms as in the case of external NMS 3034 hosts. Instead, the orchestration of the ACP, the virtual subnets 3035 and the software components can be done by trusted software that 3036 could be considered to be part of the ANI (or even an extended ACP). 3037 This software component is responsible for ensuring that only trusted 3038 software components will get access to that virtual subnet and that 3039 only even more trusted software components will get access to both 3040 the ACP virtual subnet and the Data-Plane (because those ACP users 3041 could leak traffic between ACP and Data-Plane). This trust could be 3042 established for example through cryptographic means such signed 3043 software packages. The specification of these mechanisms is subject 3044 to future work. 3046 Note that ASA (Autonomic Software Agents) could also be software 3047 components as described in this section, but further details of ASAs 3048 are subject to future work. 3050 8.1.3. Auto Configuration 3052 ACP edge nodes, NMS hosts and software components that as described 3053 in the previous section are meant to be composed via virtual 3054 interfaces SHOULD support on the ACP connect subnet StateLess Address 3055 Autoconfiguration (SLAAC - [RFC4862]) and route auto configuration 3056 according to [RFC4191]. 3058 The ACP edge node acts as the router on the ACP connect subnet, 3059 providing the (auto-)configured prefix for the ACP connect subnet to 3060 NMS hosts and/or software components. The ACP edge node uses route 3061 prefix option of RFC4191 to announce the default route (::/) with a 3062 lifetime of 0 and aggregated prefixes for routes in the ACP routing 3063 table with normal lifetimes. This will ensure that the ACP edge node 3064 does not become a default router, but that the NMS hosts and software 3065 components will route the prefixes used in the ACP to the ACP edge 3066 node. 3068 Aggregated prefix means that the ACP edge node needs to only announce 3069 the /48 ULA prefixes used in the ACP but none of the actual /64 3070 (Manual Addressing Sub-Scheme), /127 (ACP Zone Addressing Sub- 3071 Scheme), /112 or /120 (Vlong Addressing Sub-Scheme) routes of actual 3072 ACP nodes. If ACP interfaces are configured with non ULA prefixes, 3073 then those prefixes cannot be aggregated without further configured 3074 policy on the ACP edge node. This explains the above recommendation 3075 to use ACP ULA prefix covered prefixes for ACP connect interfaces: 3076 They allow for a shorter list of prefixes to be signaled via RFC4191 3077 to NMS hosts and software components. 3079 The ACP edge nodes that have a Vlong ACP address MAY allocate a 3080 subset of their /112 or /120 address prefix to ACP connect 3081 interface(s) to eliminate the need to non-autonomically configure/ 3082 provision the address prefixes for such ACP connect interfaces. 3084 8.1.4. Combined ACP/Data-Plane Interface (VRF Select) 3086 Combined ACP and Data-Plane interface 3087 . 3088 +--------+ +--------------------+ . +--------------+ 3089 | ACP | |ACP Edge No | . | NMS Host(s) | 3090 | Node | | | . | / Software | 3091 | | | [ACP ]. | . | |+ 3092 | | | .[VRF ] .[VRF ] | v | "ACP address"|| 3093 | +-------+. .[Select].+--------+ "Date Plane || 3094 | | ^ | .[Data ]. | | Address(es)"|| 3095 | | . | [Plane] | | || 3096 | | . | [ ] | +--------------+| 3097 +--------+ . +--------------------+ +--------------+ 3098 . 3099 Data-Plane "native" and + ACP auto-negotiated/encrypted 3101 Figure 14: VRF select 3103 Using two physical and/or virtual subnets (and therefore interfaces) 3104 into NMS Hosts (as per Section 8.1.1) or Software (as per 3105 Section 8.1.2) may be seen as additional complexity, for example with 3106 legacy NMS Hosts that support only one IP interface. 3108 To provide a single subnet into both ACP and Data-Plane, the ACP Edge 3109 node needs to de-multiplex packets from NMS hosts into ACP VRF and 3110 Data-Plane. This is sometimes called "VRF select". If the ACP VRF 3111 has no overlapping IPv6 addresses with the Data-Plane (as it should), 3112 then this function can use the IPv6 Destination address. The problem 3113 is Source Address Selection on the NMS Host(s) according to RFC6724. 3115 Consider the simple case: The ACP uses only one ULA prefix, the ACP 3116 IPv6 prefix for the Combined ACP and Data-Plane interface is covered 3117 by that ULA prefix. The ACP edge node announces both the ACP IPv6 3118 prefix and one (or more) prefixes for the Data-Plane. Without 3119 further policy configurations on the NMS Host(s), it may select its 3120 ACP address as a source address for Data-Plane ULA destinations 3121 because of Rule 8 of RFC6724. The ACP edge node can pass on the 3122 packet to the Data-Plane, but the ACP source address should not be 3123 used for Data-Plane traffic, and return traffic may fail. 3125 If the ACP carries multiple ULA prefixes or non-ULA ACP connect 3126 prefixes, then the correct source address selection becomes even more 3127 problematic. 3129 With separate ACP connect and Data-Plane subnets and RFC4191 prefix 3130 announcements that are to be routed across the ACP connect interface, 3131 RFC6724 source address selection Rule 5 (use address of outgoing 3132 interface) will be used, so that above problems do not occur, even in 3133 more complex cases of multiple ULA and non-ULA prefixes in the ACP 3134 routing table. 3136 To achieve the same behavior with a Combined ACP and Data-Plane 3137 interface, the ACP Edge Node needs to behave as two separate routers 3138 on the interface: One link-local IPv6 address/router for its ACP 3139 reachability, and one link-local IPv6 address/router for its Data- 3140 Plane reachability. The Router Advertisements for both are as 3141 described above (Section 8.1.3): For the ACP, the ACP prefix is 3142 announced together with RFC4191 option for the prefixes routed across 3143 the ACP and lifetime=0 to disqualify this next-hop as a default 3144 router. For the Data-Plane, the Data-Plane prefix(es) are announced 3145 together with whatever dafault router parameters are used for the 3146 Data-Plane. 3148 In result, RFC6724 source address selection Rule 5.5 may result in 3149 the same correct source address selection behavior of NMS hosts 3150 without further configuration on it as the separate ACP connect and 3151 Data-Plane interfaces. As described in the text for Rule 5.5, this 3152 is only a may, because IPv6 hosts are not required to track next-hop 3153 information. If an NMS Host does not do this, then separate ACP 3154 connect and Data-Plane interfaces are the preferable method of 3155 attachment. Hosts implementing [RFC8028] should (instead of may) 3156 implement [RFC6724] Rule 5.5, so it is preferred for hosts to support 3157 [RFC8028]. 3159 ACP edge nodes MAY support the Combined ACP and Data-Plane interface. 3161 8.1.5. Use of GRASP 3163 GRASP can and should be possible to use across ACP connect 3164 interfaces, especially in the architectural correct solution when it 3165 is used as a mechanism to connect Software (e.g., ASA or legacy NMS 3166 applications) to the ACP. Given how the ACP is the security and 3167 transport substrate for GRASP, the trustworthiness of nodes/software 3168 allowed to participate in the ACP GRASP domain is one of the main 3169 reasons why the ACP section describes no solution with non-ACP 3170 routers participating in the ACP routing table. 3172 ACP connect interfaces can be dealt with in the GRASP ACP domain like 3173 any other ACP interface assuming that any physical ACP connect 3174 interface is physically protected from attacks and that the connected 3175 Software or NMS Hosts are equally trusted as that on other ACP nodes. 3176 ACP edge nodes SHOULD have options to filter GRASP messages in and 3177 out of ACP connect interfaces (permit/deny) and MAY have more fine- 3178 grained filtering (e.g., based on IPv6 address of originator or 3179 objective). 3181 When using "Combined ACP and Data-Plane Interfaces", care must be 3182 taken that only GRASP messages intended for the ACP GRASP domain 3183 received from Software or NMS Hosts are forwarded by ACP edge nodes. 3184 Currently there is no definition for a GRASP security and transport 3185 substrate beside the ACP, so there is no definition how such 3186 Software/NMS Host could participate in two separate GRASP Domains 3187 across the same subnet (ACP and Data-Plane domains). At current it 3188 is assumed that all GRASP packets on a Combined ACP and Data-Plane 3189 interface belong to the GRASP ACP Domain. They must all use the ACP 3190 IPv6 addresses of the Software/NMS Hosts. The link-local IPv6 3191 addresses of Software/NMS Hosts (used for GRASP M_DISCOVERY and 3192 M_FLOOD messages) are also assumed to belong to the ACP address 3193 space. 3195 8.2. ACP through Non-ACP L3 Clouds (Remote ACP neighbors) 3197 Not all nodes in a network may support the ACP. If non-ACP Layer-2 3198 devices are between ACP nodes, the ACP will work across it since it 3199 is IP based. However, the autonomic discovery of ACP neighbors via 3200 DULL GRASP is only intended to work across L2 connections, so it is 3201 not sufficient to autonomically create ACP connections across non-ACP 3202 Layer-3 devices. 3204 8.2.1. Configured Remote ACP neighbor 3206 On the ACP node, remote ACP neighbors are configured explicitly. The 3207 parameters of such a "connection" are described in the following 3208 ABNF. Future work could transform this into a YANG ([RFC7950]) data 3209 model. 3211 connection = [ method , local-addr, remote-addr, ?pmtu ] 3212 method = [ "IKEv2" , ?port ] 3213 method //= [ "DTLS", port ] 3214 local-addr = [ address , ?vrf ] 3215 remote-addr = [ address ] 3216 address = ("any" | ipv4-address | ipv6-address ) 3217 vrf = tstr ; Name of a VRF on this node with local-address 3219 ABNF for parameters of explicitly configured remote ACP neighbors 3221 Explicit configuration of a remote-peer according to this ABNF 3222 provides all the information to build a secure channel without 3223 requiring a tunnel to that peer and running DULL GRASP inside of it. 3225 The configuration includes the parameters otherwise signaled via DULL 3226 GRASP: local address, remote (peer) locator and method. The 3227 differences over DULL GRASP local neighbor discovery and secure 3228 channel creation are as follows: 3230 o The local and remote address can be IPv4 or IPv6 and are typically 3231 global scope addresses. 3233 o The vrf across which the connection is built (and in which local- 3234 addr exists) can to be specified. If vrf is not specified, it is 3235 the default vrf on the node. In DULL GRASP the VRF is implied by 3236 the interface across which DULL GRASP operates. 3238 o If local address is "any", the local address used when initiating 3239 a secure channel connection is decided by source address selection 3240 ([RFC6724] for IPv6). As a responder, the connection listens on 3241 all addresses of the node in the selected vrf. 3243 o Configuration of port is only required for methods where no 3244 defaults exist (e.g., "DTLS"). 3246 o If remote address is "any", the connection is only a responder. 3247 It is a "hub" that can be used by multiple remote peers to connect 3248 simultaneously - without having to know or configure their 3249 addresses. Example: Hub site for remote "spoke" sites reachable 3250 over the Internet. 3252 o Pmtu should be configurable to overcome issues/limitations of Path 3253 MTU Discovery (PMTUD). 3255 o IKEv2/IPsec to remote peers should support the optional NAT 3256 Traversal (NAT-T) procedures. 3258 8.2.2. Tunneled Remote ACP Neighbor 3260 An IPinIP, GRE or other form of pre-existing tunnel is configured 3261 between two remote ACP peers and the virtual interfaces representing 3262 the tunnel are configured to "ACP enable". This will enable IPv6 3263 link local addresses and DULL on this tunnel. In result, the tunnel 3264 is used for normal "L2 adjacent" candidate ACP neighbor discovery 3265 with DULL and secure channel setup procedures described in this 3266 document. 3268 Tunneled Remote ACP Neighbor requires two encapsulations: the 3269 configured tunnel and the secure channel inside of that tunnel. This 3270 makes it in general less desirable than Configured Remote ACP 3271 Neighbor. Benefits of tunnels are that it may be easier to implement 3272 because there is no change to the ACP functionality - just running it 3273 over a virtual (tunnel) interface instead of only native interfaces. 3274 The tunnel itself may also provide PMTUD while the secure channel 3275 method may not. Or the tunnel mechanism is permitted/possible 3276 through some firewall while the secure channel method may not. 3278 8.2.3. Summary 3280 Configured/Tunneled Remote ACP neighbors are less "indestructible" 3281 than L2 adjacent ACP neighbors based on link local addressing, since 3282 they depend on more correct Data-Plane operations, such as routing 3283 and global addressing. 3285 Nevertheless, these options may be crucial to incrementally deploy 3286 the ACP, especially if it is meant to connect islands across the 3287 Internet. Implementations SHOULD support at least Tunneled Remote 3288 ACP Neighbors via GRE tunnels - which is likely the most common 3289 router-to-router tunneling protocol in use today. 3291 Future work could envisage an option where the edge nodes of the L3 3292 cloud is configured to automatically forward ACP discovery messages 3293 to the right exit point. This optimization is not considered in this 3294 document. 3296 9. Benefits (Informative) 3298 9.1. Self-Healing Properties 3300 The ACP is self-healing: 3302 o New neighbors will automatically join the ACP after successful 3303 validation and will become reachable using their unique ULA 3304 address across the ACP. 3306 o When any changes happen in the topology, the routing protocol used 3307 in the ACP will automatically adapt to the changes and will 3308 continue to provide reachability to all nodes. 3310 o If the domain certificate of an existing ACP node gets revoked, it 3311 will automatically be denied access to the ACP as its domain 3312 certificate will be validated against a Certificate Revocation 3313 List during authentication. Since the revocation check is only 3314 done at the establishment of a new security association, existing 3315 ones are not automatically torn down. If an immediate disconnect 3316 is required, existing sessions to a freshly revoked node can be 3317 re-set. 3319 The ACP can also sustain network partitions and mergers. Practically 3320 all ACP operations are link local, where a network partition has no 3321 impact. Nodes authenticate each other using the domain certificates 3322 to establish the ACP locally. Addressing inside the ACP remains 3323 unchanged, and the routing protocol inside both parts of the ACP will 3324 lead to two working (although partitioned) ACPs. 3326 There are few central dependencies: A certificate revocation list 3327 (CRL) may not be available during a network partition; a suitable 3328 policy to not immediately disconnect neighbors when no CRL is 3329 available can address this issue. Also, an ACP registrar or 3330 Certificate Authority might not be available during a partition. 3331 This may delay renewal of certificates that are to expire in the 3332 future, and it may prevent the enrollment of new nodes during the 3333 partition. 3335 Highly resilient ACP designs can be built by using ACP registrars 3336 with embedded sub-CA, as outlined in Section 10.3.4. As long a a 3337 partition is left with one or more of such ACP registrars, it can 3338 continue to enroll new candidate ACP nodes as long as the ACP 3339 registrars sub-CA certificate does not expire. Because the ACP 3340 addressing relies on unique Registrar-IDs, a later re-merge of 3341 partitions will also not cause problems with ACP addresses assigned 3342 during partitioning. 3344 After a network partition, a re-merge will just establish the 3345 previous status, certificates can be renewed, the CRL is available, 3346 and new nodes can be enrolled everywhere. Since all nodes use the 3347 same trust anchor, a re-merge will be smooth. 3349 Merging two networks with different trust anchors requires the trust 3350 anchors to mutually trust each other (for example, by cross-signing). 3351 As long as the domain names are different, the addressing will not 3352 overlap (see Section 6.10). 3354 It is also highly desirable for implementation of the ACP to be able 3355 to run it over interfaces that are administratively down. If this is 3356 not feasible, then it might instead be possible to request explicit 3357 operator override upon administrative actions that would 3358 administratively bring down an interface across which the ACP is 3359 running. Especially if bringing down the ACP is known to disconnect 3360 the operator from the node. For example any such down administrative 3361 action could perform a dependency check to see if the transport 3362 connection across which this action is performed is affected by the 3363 down action (with default RPL routing used, packet forwarding will be 3364 symmetric, so this is actually possible to check). 3366 9.2. Self-Protection Properties 3368 9.2.1. From the outside 3370 As explained in Section 6, the ACP is based on secure channels built 3371 between nodes that have mutually authenticated each other with their 3372 domain certificates. The channels themselves are protected using 3373 standard encryption technologies like DTLS or IPsec which provide 3374 additional authentication during channel establishment, data 3375 integrity and data confidentiality protection of data inside the ACP 3376 and in addition, provide replay protection. 3378 An attacker will not be able to join the ACP unless having a valid 3379 domain certificate, also packet injection and sniffing traffic will 3380 not be possible due to the security provided by the encryption 3381 protocol. 3383 The ACP also serves as protection (through authentication and 3384 encryption) for protocols relevant to OAM that may not have secured 3385 protocol stack options or where implementation or deployment of those 3386 options fails on some vendor/product/customer limitations. This 3387 includes protocols such as SNMP, NTP/PTP, DNS, DHCP, syslog, 3388 Radius/Diameter/TACACS, IPFIX/Netflow - just to name a few. 3389 Protection via the ACP secure hop-by-hop channels for these protocols 3390 is meant to be only a stopgap though: The ultimate goal is for these 3391 and other protocols to use end-to-end encryption utilizing the domain 3392 certificate and rely on the ACP secure channels primarily for zero- 3393 touch reliable connectivity, but not primarily for security. 3395 The remaining attack vector would be to attack the underlying ACP 3396 protocols themselves, either via directed attacks or by denial-of- 3397 service attacks. However, as the ACP is built using link-local IPv6 3398 address, remote attacks are impossible. The ULA addresses are only 3399 reachable inside the ACP context, therefore, unreachable from the 3400 Data-Plane. Also, the ACP protocols should be implemented to be 3401 attack resistant and not consume unnecessary resources even while 3402 under attack. 3404 9.2.2. From the inside 3406 The security model of the ACP is based on trusting all members of the 3407 group of nodes that do receive an ACP domain certificate for the same 3408 domain. Attacks from the inside by a compromised group member are 3409 therefore the biggest challenge. 3411 Group members must be protected against attackers so that there is no 3412 easy way to compromise them, or use them as a proxy for attacking 3413 other devices across the ACP. For example, management plane 3414 functions (transport ports) should only be reachable from the ACP but 3415 not the Data-Plane. Especially for those management plane functions 3416 that have no good protection by themselves because they do not have 3417 secure end-to-end transport and to whom ACP does not only provides 3418 automatic reliable connectivity but also protection against attacks. 3419 Protection across all potential attack vectors is typically easier to 3420 do in devices whose software is designed from the ground up with 3421 security in mind than with legacy software based systems where the 3422 ACP is added on as another feature. 3424 As explained above, traffic across the ACP SHOULD still be end-to-end 3425 encrypted whenever possible. This includes traffic such as GRASP, 3426 EST and BRSKI inside the ACP. This minimizes man in the middle 3427 attacks by compromised ACP group members. Such attackers cannot 3428 eavesdrop or modify communications, they can just filter them (which 3429 is unavoidable by any means). 3431 Further security can be achieved by constraining communication 3432 patterns inside the ACP, for example through roles that could be 3433 encoded into the domain certificates. This is subject for future 3434 work. 3436 9.3. The Administrator View 3438 An ACP is self-forming, self-managing and self-protecting, therefore 3439 has minimal dependencies on the administrator of the network. 3440 Specifically, since it is independent of configuration, there is no 3441 scope for configuration errors on the ACP itself. The administrator 3442 may have the option to enable or disable the entire approach, but 3443 detailed configuration is not possible. This means that the ACP must 3444 not be reflected in the running configuration of nodes, except a 3445 possible on/off switch. 3447 While configuration is not possible, an administrator must have full 3448 visibility of the ACP and all its parameters, to be able to do 3449 trouble-shooting. Therefore, an ACP must support all show and debug 3450 options, as for any other network function. Specifically, a network 3451 management system or controller must be able to discover the ACP, and 3452 monitor its health. This visibility of ACP operations must clearly 3453 be separated from visibility of Data-Plane so automated systems will 3454 never have to deal with ACP aspect unless they explicitly desire to 3455 do so. 3457 Since an ACP is self-protecting, a node not supporting the ACP, or 3458 without a valid domain certificate cannot connect to it. This means 3459 that by default a traditional controller or network management system 3460 cannot connect to an ACP. See Section 8.1.1 for more details on how 3461 to connect an NMS host into the ACP. 3463 10. Further Considerations (Informative) 3465 The following sections cover topics that are beyond the primary scope 3466 of this document (e.g., bootstrap), that explain decisions made in 3467 this document (e.g.: choice of GRASP) or that explain desirable 3468 extensions or implementation details for the ACP that are not 3469 considered to be appropriate to standardize in this document. 3471 10.1. BRSKI Bootstrap (ANI) 3473 [I-D.ietf-anima-bootstrapping-keyinfra] (BRSKI) describes how nodes 3474 with an IDevID certificate can securely and zero-touch enroll with a 3475 domain certificate (LDevID) to support the ACP. BRSKI also leverages 3476 the ACP to enable zero-touch bootstrap of new nodes across networks 3477 without any configuration requirements across the transit nodes 3478 (e.g., no DHCP/DNS forwarding/server setup). This includes otherwise 3479 not configured networks as described in Section 3.2. Therefore BRSKI 3480 in conjunction with ACP provides for a secure and zero-touch 3481 management solution for complete networks. Nodes supporting such an 3482 infrastructure (BRSKI and ACP) are called ANI nodes (Autonomic 3483 Networking Infrastructure), see [I-D.ietf-anima-reference-model]. 3484 Nodes that do not support an IDevID but only an (insecure) vendor 3485 specific Unique Device Identifier (UDI) or nodes whose manufacturer 3486 does not support a MASA could use some future security reduced 3487 version of BRSKI. 3489 When BRSKI is used to provision a domain certificate (which is called 3490 enrollment), the BRSKI registrar (acting as an enhanced EST server) 3491 must include the subjectAltName / rfc822Name encoded ACP address and 3492 domain name to the enrolling node (called pledge) via its response to 3493 the pledges EST CSR Attribute request that is mandatory in BRSKI. 3495 The Certificate Authority in an ACP network must not change the 3496 subjectAltName / rfc822Name in the certificate. The ACP nodes can 3497 therefore find their ACP address and domain using this field in the 3498 domain certificate, both for themselves, as well as for other nodes. 3500 The use of BRSKI in conjunction with the ACP can also help to further 3501 simplify maintenance and renewal of domain certificates. Instead of 3502 relying on CRL, the lifetime of certificates can be made extremely 3503 small, for example in the order of hours. When a node fails to 3504 connect to the ACP within its certificate lifetime, it cannot connect 3505 to the ACP to renew its certificate across it (using just EST), but 3506 it can still renew its certificate as an "enrolled/expired pledge" 3507 via the BRSKI bootstrap proxy. This requires only that the BRSKI 3508 registrar honors expired domain certificates and that the pledge 3509 first attempts to perform TLS authentication for BRSKI bootstrap with 3510 its expired domain certificate - and only reverts to its IDevID when 3511 this fails. This mechanism could also render CRLs unnecessary 3512 because the BRSKI registrar in conjunction with the CA would not 3513 renew revoked certificates - only a "Do-not-renew" list would be 3514 necessary on BRSKI registrars/CA. 3516 In the absence of BRSKI or less secure variants thereof, provisioning 3517 of certificates may involve one or more touches or non-standardized 3518 automation. Node vendors usually support provisioning of 3519 certificates into nodes via PKCS#7 (see [RFC2315]) and may support 3520 this provisioning through vendor specific models via Netconf 3521 ([RFC6241]). If such nodes also support Netconf Zero-Touch 3522 ([I-D.ietf-netconf-zerotouch]) then this can be combined to zero- 3523 touch provisioning of domain certificates into nodes. Unless there 3524 are equivalent integration of Netconf connections across the ACP as 3525 there is in BRSKI, this combination would not support zero-touch 3526 bootstrap across a not configured network though. 3528 10.2. ACP (and BRSKI) Diagnostics 3530 Even though ACP and ANI in general are taking out many manual 3531 configuration mistakes through their automation, it is important to 3532 provide good diagnostics for them. 3534 The basic diagnostics is support of (yang) data models representing 3535 the complete (auto-)configuration and operational state of all 3536 components: BRSKI, GRASP, ACP and the infrastructure used by them: 3537 TLS/DTLS, IPsec, certificates, trust anchors, time, VRF and so on. 3538 While necessary, this is not sufficient: 3540 Simply representing the state of components does not allow operators 3541 to quickly take action - unless they do understand how to interpret 3542 the data, and that can mean a requirement for deep understanding of 3543 all components and how they interact in the ACP/ANI. 3545 Diagnostic supports should help to quickly answer the questions 3546 operators are expected to ask, such as "is the ACP working 3547 correctly?", or "why is there no ACP connection to a known 3548 neighboring node?" 3550 In current network management approaches, the logic to answer these 3551 questions is most often built as centralized diagnostics software 3552 that leverages the above mentioned data models. While this approach 3553 is feasible for components utilizing the ANI, it is not sufficient to 3554 diagnose the ANI itself: 3556 o Developing the logic to identify common issues requires 3557 operational experience with the components of the ANI. Letting 3558 each management system define its own analysis is inefficient. As 3559 much as possible, future work should attempt to standardize data 3560 models that support common error diagnostic. 3562 o When the ANI is not operating correctly, it may not be possible to 3563 run diagnostics from remote because of missing connectivity. The 3564 ANI should therefore have diagnostic capabilities available 3565 locally on the nodes themselves. 3567 o Certain operations are difficult or impossible to monitor in real- 3568 time, such as initial bootstrap issues in a network location where 3569 no capabilities exist to attach local diagnostics. Therefore it 3570 is important to also define means of capturing (logging) 3571 diagnostics locally for later retrieval. Ideally, these captures 3572 are also non-volatile so that they can survive extended power-off 3573 conditions - for example when a device that fails to be brought up 3574 zero-touch is being sent back for diagnostics at a more 3575 appropriate location. 3577 The most simple form of diagnostics answering questions like the 3578 above is to represent the relevant information sequentially in 3579 dependency order, so that the first non-expected/non-operational item 3580 is the most likely root cause. Or just log/highlight that item. For 3581 example: 3583 Q: Is ACP operational to accept neighbor connections: 3585 o Check if any potentially necessary configuration to make ACP/ANI 3586 operational are correct (see Section 10.5 for a discussion of such 3587 commands). 3589 o Does the system time look reasonable, or could it be the default 3590 system time after clock chip battery failure (certificate checks 3591 depend on reasonable notion of time). 3593 o Does the node have keying material - domain certificate, trust 3594 anchors. 3596 o If no keying material and ANI is supported/enabled, check the 3597 state of BRSKI (not detailed in this example). 3599 o Check the validity of the domain certificate: 3601 * Does the certificate authenticate against the trust anchor? 3603 * Has it been revoked? 3605 * Was the last scheduled attempt to retrieve a CRL successful 3606 (e.g., do we know that our CRL information is up to date). 3608 * Is the certificate valid: validity start time in the past, 3609 expiration time in the future? 3611 * Does the certificate have a correctly formatted ACP information 3612 field? 3614 o Was the ACP VRF successfully created? 3616 o Is ACP enabled on one or more interfaces that are up and running? 3618 If all this looks good, the ACP should be running locally "fine" - 3619 but we did not check any ACP neighbor relationships. 3621 Question: why does the node not create a working ACP connection to a 3622 neighbor on an interface? 3624 o Is the interface physically up? Does it have an IPv6 link-local 3625 address? 3627 o Is it enabled for ACP? 3629 o Do we successfully send DULL GRASP messages to the interface (link 3630 layer errors)? 3632 o Do we receive DULL GRASP messages on the interface? If not, some 3633 intervening L2 equipment performing bad MLD snooping could have 3634 caused problems. Provide e.g., diagnostics of the MLD querier 3635 IPv6 and MAC address. 3637 o Do we see the ACP objective in any DULL GRASP message from that 3638 interface? Diagnose the supported secure channel methods. 3640 o Do we know the MAC address of the neighbor with the ACP objective? 3641 If not, diagnose SLAAC/ND state. 3643 o When did we last attempt to build an ACP secure channel to the 3644 neighbor? 3646 o If it failed, why: 3648 * Did the neighbor close the connection on us or did we close the 3649 connection on it because the domain certificate membership 3650 failed? 3652 * If the neighbor closed the connection on us, provide any error 3653 diagnostics from the secure channel protocol. 3655 * If we failed the attempt, display our local reason: 3657 + There was no common secure channel protocol supported by the 3658 two neighbors (this could not happen on nodes supporting 3659 this specification because it mandates common support for 3660 IPsec). 3662 + The ACP domain certificate membership check (Section 6.1.2) 3663 fails: 3665 - The neighbors certificate does not have the required 3666 trust anchor. Provide diagnostics which trust anchor it 3667 has (can identify whom the device belongs to). 3669 - The neighbors certificate does not have the same domain 3670 (or no domain at all). Diagnose domain-name and 3671 potentially other other cert info. 3673 - The neighbors certificate has been revoked or could not 3674 be authenticated by OCSP. 3676 - The neighbors certificate has expired - or is not yet 3677 valid. 3679 * Any other connection issues in e.g., IKEv2 / IPsec, DTLS?. 3681 Question: Is the ACP operating correctly across its secure channels? 3683 o Are there one or more active ACP neighbors with secure channels? 3685 o Is the RPL routing protocol for the ACP running? 3687 o Is there a default route to the root in the ACP routing table? 3688 o Is there for each direct ACP neighbor not reachable over the ACP 3689 virtual interface to the root a route in the ACP routing table? 3691 o Is ACP GRASP running? 3693 o Is at least one SRV.est objective cached (to support certificate 3694 renewal)? 3696 o Is there at least one BRSKI registrar objective cached (in case 3697 BRSKI is supported) 3699 o Is BRSKI proxy operating normally on all interfaces where ACP is 3700 operating? 3702 o ... 3704 These lists are not necessarily complete, but illustrate the 3705 principle and show that there are variety of issues ranging from 3706 normal operational causes (a neighbor in another ACP domain) over 3707 problems in the credentials management (certificate lifetimes), 3708 explicit security actions (revocation) or unexpected connectivity 3709 issues (intervening L2 equipment). 3711 The items so far are illustrating how the ANI operations can be 3712 diagnosed with passive observation of the operational state of its 3713 components including historic/cached/counted events. This is not 3714 necessary sufficient to provide good enough diagnostics overall: 3716 The components of ACP and BRSKI are designed with security in mind 3717 but they do not attempt to provide diagnostics for building the 3718 network itself. Consider two examples: 3720 1. BRSKI does not allow for a neighboring device to identify the 3721 pledges certificate (IDevID). Only the selected BRSKI registrar 3722 can do this, but it may be difficult to disseminate information 3723 about undesired pledges from those BRSKI registrars to locations/ 3724 nodes where information about those pledges is desired. 3726 2. The Link Layer Discovery Protocol (LLDP, [LLDP]) disseminates 3727 information about nodes to their immediate neighbors, such as 3728 node model/type/software and interface name/number of the 3729 connection. This information is often helpful or even necessary 3730 in network diagnostics. It can equally considered to be too 3731 insecure to make this information available unprotected to all 3732 possible neighbors. 3734 An "interested adjacent party" can always determine the IDevID of a 3735 BRSKI pledge by behaving like a BRSKI proxy/registrar. Therefore the 3736 IDevID of a BRSKI pledge is not meant to be protected - it just has 3737 to be queried and is not signaled unsolicited (as it would be in 3738 LLDP) so that other observers on the same subnet can determine who is 3739 an "interested adjacent party". 3741 Desirable options for additional diagnostics subject to future work 3742 include: 3744 1. Determine if LLDP should be a recommended functionality for ANI 3745 devices to improve diagnostics, and if so, which information 3746 elements it should signal (insecure). 3748 2. In alternative to LLDP, A DULL GRASP diagnostics objective could 3749 be defined to carry these information elements. 3751 3. The IDevID of BRSKI pledges should be included in the selected 3752 insecure diagnostics option. 3754 4. A richer set of diagnostics information should be made available 3755 via the secured ACP channels, using either single-hop GRASP or 3756 network wide "topology discovery" mechanisms. 3758 10.3. ACP Registrar Considerations 3760 As described in Section 6.10.7, the ACP addressing mechanism is 3761 designed to enable lightweight, distributed and uncoordinated ACP 3762 registrars that are providing ACP address prefixes to candidate ACP 3763 nodes by enrolling them with an ACP domain certificate into an ACP 3764 domain via any appropriate mechanism/protocol, automated or not. 3766 This section discusses informatively more details and options for ACP 3767 registrars. 3769 10.3.1. Registrar interactions 3771 This section summarizes and discusses the interactions with other 3772 entities required by an ACP registrar. 3774 In a simple instance of an ACP network, no central NOC component 3775 beside a trust anchor (root CA) is required. One or more 3776 uncoordinated acting ACP registrar can be set up, performing the 3777 following interactions: 3779 To orchestrate enrolling a candidate ACP node autonomically, the ACP 3780 registrar can rely on the ACP and use Proxies to reach the candidate 3781 ACP node, therefore allowing minimum pre-existing (auto-)configured 3782 network services on the candidate ACP node. BRSKI defines the BRSKI 3783 proxy, a design that can be adopted for various protocols that 3784 Pledges/candidate ACP nodes could want to use, for example BRSKI over 3785 CoAP (Constrained Application Protocol), or proxying of Netconf. 3787 To reach a trust anchor unaware of the ACP, the ACP registrar would 3788 use the Data-Plane. ACP and Data-Plane in an ACP registrar could 3789 (and by default should be) completely isolated from each other at the 3790 network level. Only applications like the ACP registrar would need 3791 the ability for their transport stacks to access both. 3793 In non autonomic enrollment options, the data plane between a ACP 3794 registrar and the candidate ACP node needs to be configured first. 3795 This includes the ACP registrar and the candidate ACP node. Then any 3796 appropriate set of protocols can be used between ACP registrar and 3797 candidate ACP node to discover the other side, and then connect and 3798 enroll (configure) the candidate ACP node with an ACP domain 3799 certificate. Netconf ZeroTouch ([I-D.ietf-netconf-zerotouch]) is an 3800 example protocol that could be used for this. BRSKI using optional 3801 discovery mechanisms is equally a possibility for candidate ACP nodes 3802 attempting to be enrolled across non-ACP networks, such as the 3803 Internet. 3805 When candidate ACP nodes have secure bootstrap, like BRSKI Pledges, 3806 they will not trust to be configured/enrolled across the network, 3807 unless being presented with a voucher (see [RFC8366]) authorizing the 3808 network to take posession of the node. An ACP registrar will then 3809 need a method to retrieve such a voucher, either offline, or online 3810 from a MASA (Manufacturer Authorized Signing Authority). BRSKI and 3811 Netconf ZeroTouch are two protocols that include capabilities to 3812 present the voucher to the candidate ACP node. 3814 An ACP registrar could operate EST for ACP certificate renewal and/or 3815 act as a CRL Distribution point. A node performing these services 3816 does not need to support performing (initial) enrollment, but it does 3817 require the same above described connectivity as an ACP registrar: 3818 via the ACP to ACP nodes and via the Data-Plane to the trust anchor 3819 and other sources of CRL information. 3821 10.3.2. Registrar Parameter 3823 The interactions of an ACP registrar outlined Section 6.10.7 and 3824 Section 10.3.1 above depend on the following parameters: 3826 A URL to the trust anchor (root CA) and credentials so that the 3827 ACP registrar can let the trust anchor sign candidate ACP member 3828 certificates. 3830 The ACP domain-name. 3832 The Registrar-ID to use. This could default to a MAC address of 3833 the ACP registrar. 3835 For recovery, the next-useable Node-IDs for zone (Zone-ID=0) sub- 3836 addressing scheme, for Vlong /112 and for Vlong /1120 sub- 3837 addressing scheme. These IDs would only need to be provisioned 3838 after recovering from a crash. Some other mechanism would be 3839 required to remember these IDs in a backup location or to recover 3840 them from the set of currently known ACP nodes. 3842 Policies if candidate ACP nodes should receive a domain 3843 certificate or not, for example based on the devices LDevID as in 3844 BRSKI. The ACP registrar may have a whitelist or blacklist of 3845 devices serialNumbers from teir LDevID. 3847 Policies what type of address prefix to assign to a candidate ACP 3848 devices, based on likely the same information. 3850 For BRSKI or other mechanisms using vouchers: Parameters to 3851 determine how to retrieve vouchers for specific type of secure 3852 bootstrap candidate ACP nodes (such as MASA URLs), unless this 3853 information is automatically learned such as from the LDevID of 3854 candidate ACP nodes (as defined in BRSKI). 3856 10.3.3. Certificate renewal and limitations 3858 When an ACP node renews/rekeys its certificate, it may end up doing 3859 so via a different registrar (e.g., EST server) than the one it 3860 originally received its ACP domain certificate from, for example 3861 because that original ACP registrar is gone. The ACP registrar 3862 through which the renewal/rekeying is performed would by default 3863 trust the ACP domain information from the ACP nodes current ACP 3864 domain certificate and maintain this information so that the ACP node 3865 maintains its ACP address prefix. In EST renewal/rekeying, the ACP 3866 nodes current ACP domain certificate is signaled during the TLS 3867 handshake. 3869 This simple scenario has two limitations: 3871 1. The ACP registrars can not directly assign certificates to nodes 3872 and therefore needs an "online" connection to the trust anchor 3873 (root CA). 3875 2. Recovery from a compromised ACP registrar is difficult. When an 3876 ACP registrar is compromised, it can insert for example 3877 conflicting ACP domain information and create thereby an attack 3878 against other ACP nodes through the ACP routing protocol. 3880 Even when such a malicious ACP registrar is detected, resolving the 3881 problem may be difficult because it would require identifying all the 3882 wrong ACP domain certificates assigned via the ACP registrar after it 3883 was was compromised. And without additional centralized tracking of 3884 assigned certificates there is no way to do this - assuming one can 3885 not retrieve this information from the . 3887 10.3.4. ACP Registrars with sub-CA 3889 In situations, where either of the above two limitations are an 3890 issue, ACP registrars could also be sub-CAs. This removes the need 3891 for connectivity to a root-CA whenever an ACP node is enrolled, and 3892 reduces the need for connectivity of such an ACP registrar to a root- 3893 CA to only those times when it needs to renew its own certificate. 3894 The ACP registrar would also now use its own (sub-CA) certificate to 3895 enroll and sign the ACP nodes certificates, and therefore it is only 3896 necessary to revoke a compromised ACP registrars sub-CA certificate. 3897 Or let it expire and not renew it, when the certificate of the sub-CA 3898 is appropriately short-lived. 3900 As the ACP domain membership check verifies a peer ACP node's ACP 3901 domain certicate trust chain, it will also verify the signing 3902 certificate which is the compromised/revoked sub-CA certificate. 3903 Therefore ACP domain membership for an ACP node enrolled from a 3904 compromised ACP registrar will fail. 3906 ACP nodes enrolled by a compromised ACP registrar would automatically 3907 fail to establish ACP channels and ACP domain certificate renewal via 3908 EST and therefore revert to their role as a candidate ACP members and 3909 attempt to get a new ACP domain certificate from an ACP registrar - 3910 for example via BRSKI. In result, ACP registrars that have an 3911 associated sub-CA makes isolating and resolving issues with 3912 compromised registrars easier. 3914 Note that ACP registrars with sub-CA functionality also can control 3915 the lifetime of ACP domain certificates easier and therefore also be 3916 used as a tool to introduce short lived certificates and not rely on 3917 CRL, whereas the certificates for the sub-CAs themselves could be 3918 longer lived and subject to CRL. 3920 10.3.5. Centralized Policy Control 3922 When using multiple, uncoordinated ACP registrars, several advanced 3923 operations are potentially more complex than with a single, resilient 3924 policy control backend, for example including but not limited to: 3926 Which candidate ACP node is permitted or not permitted into an ACP 3927 domain. This may not be a decision to be taken upfront, so that a 3928 per-serialNumber policy can be loaded into ever ACP registrar. 3929 Instead, it may better be decided in real-time including 3930 potentially a human decision in a NOC. 3932 Tracking of all enrolled ACP nodes and their certificate 3933 information. For example in support of revoking individual ACP 3934 nodes certificates. 3936 More flexible policies what type of address prefix or even what 3937 specific address prefix to assign to a candidate ACP node. 3939 These and other operations could be introduced more easily by 3940 introducing a centralized Policy Management System (PMS) and 3941 modifying ACP registrar behavior so that it queries the PMS for any 3942 policy decision occuring during the candidate ACP node enrollment 3943 process and/or the ACP node certificate renewal process. For 3944 example, which ACP address prefix to assign. Likewise the ACP 3945 registrar would report any relevant state change information to the 3946 PMS as well, for example when a certificate was successfully enrolled 3947 onto a candidate ACP node. Such an ACP registrar PMS interface 3948 definition is subject to future work. 3950 10.4. Address Space Considerations 3952 This document defines the Zone, Vlong and Manual sub address schemes 3953 primarily to support address prefix assignment via distributed, 3954 potentially uncoordinated ACP registrars as defined in 3955 Section 6.10.7. This costs 48/46 bit identifier so that these ACP 3956 registrar can assign non-conflicting address prefixes. This design 3957 does not leave enough bits to simultaneously support a large number 3958 of nodes (Node-ID) plus a large prefix of local addresses for every 3959 node plus a large enough set of bits to identify a routing Zone. In 3960 result, Zone, Vlong 8/16 attempt to support all features, but in via 3961 separate prefixes. 3963 In networks that always expect to rely on a centralized PMS as 3964 described above (Section 10.3.5), the 48/46 bits for the Registrar-ID 3965 could be saved. Such variations of the ACP addressing mecchanisms 3966 could be introduct through future work in different ways. If the 3967 prefix rfcSELF in the ACP information field was changed, incompatible 3968 ACP variations could be created where every design aspect of the ACP 3969 could be changed. Including all addressing choices. If instead a 3970 new addressing sub-type would be defined, it could be a backward 3971 compatible extension of this ACP specification. Information such as 3972 the size of a zone-prefix and the length of the prefix assigned to 3973 the ACP node itself could be encoded via the extension field of the 3974 ACP domain information. 3976 Note that an explicitly defined "Manual" addressing sub-scheme is 3977 always beneficial to provide an easy way for ACP nodes to prohibit 3978 incorrect manual configuration of any non-"Manual" ACP address spaces 3979 and therefore ensure hat "Manual" operations will never impact 3980 correct routing for any non-"Manual" ACP addresses assigned via ACP 3981 domain certificates. 3983 10.5. Enabling and disabling ACP/ANI 3985 Both ACP and BRSKI require interfaces to be operational enough to 3986 support sending/receiving their packets. In node types where 3987 interfaces are by default (e.g., without operator configuration) 3988 enabled, such as most L2 switches, this would be less of a change in 3989 behavior than in most L3 devices (e.g.: routers), where interfaces 3990 are by default disabled. In almost all network devices it is common 3991 though for configuration to change interfaces to a physically 3992 disabled state and that would break the ACP. 3994 In this section, we discuss a suggested operational model to enable/ 3995 disable interfaces and nodes for ACP/ANI in a way that minimizes the 3996 risk of operator action to break the ACP in this way, and that also 3997 minimizes operator surprise when ACP/ANI becomes supported in node 3998 software. 4000 10.5.1. Filtering for non-ACP/ANI packets 4002 Whenever this document refers to enabling an interface for ACP (or 4003 BRSKI), it only requires to permit the interface to send/receive 4004 packets necessary to operate ACP (or BRSKI) - but not any other Data- 4005 Plane packets. Unless the Data-Plane is explicitly configured/ 4006 enabled, all packets not required for ACP/BRSKI should be filtered on 4007 input and output: 4009 Both BRSKI and ACP require link-local only IPv6 operations on 4010 interfaces and DULL GRASP. IPv6 link-local operations means the 4011 minimum signaling to auto-assign an IPv6 link-local address and talk 4012 to neighbors via their link-local address: SLAAC (Stateless Address 4013 Auto-Configuration - [RFC4862]) and ND (Neighbor Discovery - 4014 [RFC4861]). When the device is a BRSKI pledge, it may also require 4015 TCP/TLS connections to BRSKI proxies on the interface. When the 4016 device has keying material, and the ACP is running, it requires DULL 4017 GRASP packets and packets necessary for the secure-channel mechanism 4018 it supports, e.g., IKEv2 and IPsec ESP packets or DTLS packets to the 4019 IPv6 link-local address of an ACP neighbor on the interface. It also 4020 requires TCP/TLS packets for its BRSKI proxy functionality, if it 4021 does support BRSKI. 4023 10.5.2. Admin Down State 4025 Interfaces on most network equipment have at least two states: "up" 4026 and "down". These may have product specific names. "down" for 4027 example could be called "shutdown" and "up" could be called "no 4028 shutdown". The "down" state disables all interface operations down 4029 to the physical level. The "up" state enables the interface enough 4030 for all possible L2/L3 services to operate on top of it and it may 4031 also auto-enable some subset of them. More commonly, the operations 4032 of various L2/L3 services is controlled via additional node-wide or 4033 interface level options, but they all become only active when the 4034 interface is not "down". Therefore an easy way to ensure that all 4035 L2/L3 operations on an interface are inactive is to put the interface 4036 into "down" state. The fact that this also physically shuts down the 4037 interface is in many cases just a side effect, but it may be 4038 important in other cases (see below). 4040 To provide ACP/ANI resilience against operators configuring 4041 interfaces to "down" state, this document recommends to separate the 4042 "down" state of interfaces into an "admin down" state where the 4043 physical layer is kept running and ACP/ANI can use the interface and 4044 a "physical down" state. Any existing "down" configurations would 4045 map to "admin down". In "admin down", any existing L2/L3 services of 4046 the Data-Plane should see no difference to "physical down" state. To 4047 ensure that no Data-Plane packets could be sent/received, packet 4048 filtering could be established automatically as described above in 4049 Section 10.5.1. 4051 As necessary (see discussion below) new configuration options could 4052 be introduced to issue "physical down". The options should be 4053 provided with additional checks to minimize the risk of issuing them 4054 in a way that breaks the ACP without automatic restoration. For 4055 example they could be denied to be issued from a control connection 4056 (netconf/ssh) that goes across the interface itself ("do not 4057 disconnect yourself"). Or they could be performed only temporary and 4058 only be made permanent with additional later reconfirmation. 4060 In the following sub-sections important aspects to the introduction 4061 of "admin down" state are discussed. 4063 10.5.2.1. Security 4065 Interfaces are physically brought down (or left in default down 4066 state) as a form of security. "Admin down" state as described above 4067 provides also a high level of security because it only permits ACP/ 4068 ANI operations which are both well secured. Ultimately, it is 4069 subject to security review for the deployment whether "admin down" is 4070 a feasible replacement for "physical down". 4072 The need to trust into the security of ACP/ANI operations need to be 4073 weighed against the operational benefits of permitting this: Consider 4074 the typical example of a CPE (customer premises equipment) with no 4075 on-site network expert. User ports are in physical down state unless 4076 explicitly configured not to be. In a misconfiguration situation, 4077 the uplink connection is incorrectly plugged into such a user port. 4078 The device is disconnected from the network and therefore no 4079 diagnostics from the network side is possible anymore. 4080 Alternatively, all ports default to "admin down". The ACP (but not 4081 the Data-Plane) would still automatically form. Diagnostics from the 4082 network side is possible and operator reaction could include to 4083 either make this port the operational uplink port or to instruct re- 4084 cabling. Security wise, only ACP/ANI could be attacked, all other 4085 functions are filtered on interfaces in "admin down" state. 4087 10.5.2.2. Fast state propagation and Diagnostics 4089 "Physical down" state propagates on many interface types (e.g., 4090 Ethernet) to the other side. This can trigger fast L2/L3 protocol 4091 reaction on the other side and "admin down" would not have the same 4092 (fast) result. 4094 Bringing interfaces to "physical down" state is to the best of our 4095 knowledge always a result of operator action, but today, never the 4096 result of (autonomic) L2/L3 services running on the nodes. Therefore 4097 one option is to change the operator action to not rely on link-state 4098 propagation anymore. This may not be possible when both sides are 4099 under different operator control, but in that case it is unlikely 4100 that the ACP is running across the link and actually putting the 4101 interface into "physical down" state may still be a good option. 4103 Ideally, fast physical state propagation is replaced by fast software 4104 driven state propagation. For example a DULL GRASP "admin-state" 4105 objective could be used to auto configure a Bidirectional Forwarding 4106 Protocol (BFD, [RFC5880]) session between the two sides of the link 4107 that would be used to propagate the "up" vs. admin down state. 4109 Triggering physical down state may also be used as a mean of 4110 diagnosing cabling in the absence of easier methods. It is more 4111 complex than automated neighbor diagnostics because it requires 4112 coordinated remote access to both (likely) sides of a link to 4113 determine whether up/down toggling will cause the same reaction on 4114 the remote side. 4116 See Section 10.2 for a discussion about how LLDP and/or diagnostics 4117 via GRASP could be used to provide neighbor diagnostics, and 4118 therefore hopefully eliminating the need for "physical down" for 4119 neighbor diagnostics - as long as both neighbors support ACP/ANI. 4121 10.5.2.3. Low Level Link Diagnostics 4123 "Physical down" is performed to diagnose low-level interface behavior 4124 when higher layer services (e.g., IPv6) are not working. Especially 4125 Ethernet links are subject to a wide variety of possible wrong 4126 configuration/cablings if they do not support automatic selection of 4127 variable parameters such as speed (10/100/1000 Mbps), crossover 4128 (Auto-MDIX) and connector (fiber, copper - when interfaces have 4129 multiple but can only enable one at a time). The need for low level 4130 link diagnostic can therefore be minimized by using fully auto 4131 configuring links. 4133 In addition to "Physical down", low level diagnostics of Ethernet or 4134 other interfaces also involve the creation of other states on 4135 interfaces, such as physical Loopback (internal and/or external) or 4136 bringing down all packet transmissions for reflection/cable-length 4137 measurements. Any of these options would disrupt ACP as well. 4139 In cases where such low-level diagnostics of an operational link is 4140 desired but where the link could be a single point of failure for the 4141 ACP, ASA on both nodes of the link could perform a negotiated 4142 diagnostics that automatically terminates in a predetermined manner 4143 without dependence on external input ensuring the link will become 4144 operational again. 4146 10.5.2.4. Power Consumption 4148 Power consumption of "physical down" interfaces may be significantly 4149 lower than those in "admin down" state, for example on long range 4150 fiber interfaces. Assuming reasonable clocks on devices, mechanisms 4151 for infrequent periodic probing could allow to automatically 4152 establish ACP connectivity across such links. Bring up interfaces 4153 for 5 seconds to probe if there is an ACP neighbor on the remote end 4154 every 500 seconds = 1% power consumption. 4156 10.5.3. Interface level ACP/ANI enable 4158 The interface level configuration option "ACP enable" enables ACP 4159 operations on an interface, starting with ACP neighbor discovery via 4160 DULL GRAP. The interface level configuration option "ANI enable" on 4161 nodes supporting BRSKI and ACP starts with BRSKI pledge operations 4162 when there is no domain certificate on the node. On ACP/BRSKI nodes, 4163 "ACP enable" may not need to be supported, but only "ANI enable". 4164 Unless overridden by global configuration options (see later), "ACP/ 4165 ANI enable" will result in "down" state on an interface to behave as 4166 "admin down". 4168 10.5.4. Which interfaces to auto-enable? 4170 (Section 6.3) requires that "ACP enable" is automatically set on 4171 native interfaces, but not on non-native interfaces (reminder: a 4172 native interface is one that exists without operator configuration 4173 action such as physical interfaces in physical devices). 4175 Ideally, ACP enable is set automatically on all interfaces that 4176 provide access to additional connectivity that allows to reach more 4177 nodes of the ACP domain. The best set of interfaces necessary to 4178 achieve this is not possible to determine automatically. Native 4179 interfaces are the best automatic approximation. 4181 Consider an ACP domain of ACP nodes transitively connected via native 4182 interfaces. A Data-Plane tunnel between two of these nodes that are 4183 non-adjacent is created and "ACP enable" is set for that tunnel. ACP 4184 RPL sees this tunnel as just as a single hop. Routes in the ACP 4185 would use this hop as an attractive path element to connect regions 4186 adjacent to the tunnel nodes. In result, the actual hop-by-hop paths 4187 used by traffic in the ACP can become worse. In addition, correct 4188 forwarding in the ACP now depends on correct Data-Plane forwarding 4189 config including QoS, filtering and other security on the Data-Plane 4190 path across which this tunnel runs. This is the main issue why "ACP/ 4191 ANI enable" should not be set automatically on non-native interfaces. 4193 If the tunnel would connect two previously disjoint ACP regions, then 4194 it likely would be useful for the ACP. A Data-Plane tunnel could 4195 also run across nodes without ACP and provide additional connectivity 4196 for an already connected ACP network. The benefit of this additional 4197 ACP redundancy has to be weighed against the problems of relying on 4198 the Data-Plane. If a tunnel connects two separate ACP regions: how 4199 many tunnels should be created to connect these ACP regions reliably 4200 enough? Between which nodes? These are all standard tunneled 4201 network design questions not specific to the ACP, and there are no 4202 generic fully automated answers. 4204 Instead of automatically setting "ACP enable" on these type of 4205 interfaces, the decision needs to be based on the use purpose of the 4206 non-native interface and "ACP enable" needs to be set in conjunction 4207 with the mechanism through which the non-native interface is created/ 4208 configured. 4210 In addition to explicit setting of "ACP/ANI enable", non-native 4211 interfaces also need to support configuration of the ACP RPL cost of 4212 the link - to avoid the problems of attracting too much traffic to 4213 the link as described above. 4215 Even native interfaces may not be able to automatically perform BRSKI 4216 or ACP because they may require additional operator input to become 4217 operational. Example include DSL interfaces requiring PPPoE 4218 credentials or mobile interfaces requiring credentials from a SIM 4219 card. Whatever mechanism is used to provide the necessary config to 4220 the device to enable the interface can also be expanded to decide on 4221 whether or not to set "ACP/ANI enable". 4223 The goal of automatically setting "ACP/ANI enable" on interfaces 4224 (native or not) is to eliminate unnecessary "touches" to the node to 4225 make its operation as much as possible "zero-touch" with respect to 4226 ACP/ANI. If there are "unavoidable touches" such a creating/ 4227 configuring a non-native interface or provisioning credentials for a 4228 native interface, then "ACP/ANI enable" should be added as an option 4229 to that "touch". If a wrong "touch" is easily fixed (not creating 4230 another high-cost touch), then the default should be not to enable 4231 ANI/ACP, and if it is potentially expensive or slow to fix (e.g., 4232 parameters on SIM card shipped to remote location), then the default 4233 should be to enable ACP/ANI. 4235 10.5.5. Node Level ACP/ANI enable 4237 A node level command "ACP/ANI enable [up-if-only]" enables ACP or ANI 4238 on the node (ANI = ACP + BRSKI). Without this command set, any 4239 interface level "ACP/ANI enable" is ignored. Once set, ACP/ANI will 4240 operate interface where "ACP/ANI enable" is set. Setting of 4241 interface level "ACP/ANI enable" is either automatic (default) or 4242 explicit through operator action as described in the previous 4243 section. 4245 If the option "up-if-only" is selected, the behavior of "down" 4246 interfaces is unchanged, and ACP/ANI will only operate on interfaces 4247 where "ACP/ANI enable" is set and that are "up". When it is not set, 4248 then "down" state of interfaces with "ACP/ANI enable" is modified to 4249 behave as "admin down". 4251 10.5.5.1. Brownfield nodes 4253 A "brownfield" node is one that already has a configured Data-Plane. 4255 Executing global "ACP/ANI enable [up-if-only]" on each node is the 4256 only command necessary to create an ACP across a network of 4257 brownfield nodes once all the nodes have a domain certificate. When 4258 BRSKI is used ("ANI enable"), provisioning of the certificates only 4259 requires set-up of a single BRSKI registrar node which could also 4260 implement a CA for the network. This is the most simple way to 4261 introduce ACP/ANI into existing (== brownfield) networks. 4263 The need to explicitly enable ACP/ANI is especially important in 4264 brownfield nodes because otherwise software updates may introduce 4265 support for ACP/ANI: Automatic enablement of ACP/ANI in networks 4266 where the operator does not only not want ACP/ANI but where he likely 4267 never even heard of it could be quite irritating to him. Especially 4268 when "down" behavior is changed to "admin down". 4270 Automatically setting "ANI enable" on brownfield nodes where the 4271 operator is unaware of it could also be a critical security issue 4272 depending on the vouchers used by BRKSI on these nodes. An attacker 4273 could claim to be the owner of these devices and create an ACP that 4274 the attacker has access/control over. In network where the operator 4275 explicitly wants to enable the ANI this could not happen, because he 4276 would create a BRSKI registrar that would discover attack attempts. 4277 Nodes requiring "ownership vouchers" would not be subject to that 4278 attack. See [I-D.ietf-anima-bootstrapping-keyinfra] for more 4279 details. Note that a global "ACP enable" alone is not subject to 4280 these type of attacks, because it always depends on some other 4281 mechanism first to provision domain certificates into the device. 4283 10.5.5.2. Greenfield nodes 4285 A "greenfield" node is one that did not have any prior configuration. 4287 For greenfield nodes, only "ANI enable" is relevant. If another 4288 mechanism than BRSKI is used to (zero-touch) bootstrap a node, then 4289 it is up to that mechanism to provision domain certificates and to 4290 set global "ACP enable" as desired. 4292 Nodes supporting full ANI functionality set "ANI enable" 4293 automatically when they decide that they are greenfield, e.g., that 4294 they are powering on from factory condition. They will then put all 4295 native interfaces into "admin down" state and start to perform BRSKI 4296 pledge functionality - and once a domain certificate is enrolled they 4297 automatically enable ACP. 4299 Attempts for BRSKI pledge operations in greenfield state should 4300 terminate automatically when another method of configuring the node 4301 is used. Methods that indicate some form of physical possession of 4302 the device such as configuration via the serial console could lead to 4303 immediate termination of BRSKI, while other parallel auto 4304 configuration methods subject to remote attacks might lead to BRSKI 4305 termination only after they were successful. Details of this may 4306 vary widely over different type of nodes. When BRSKI pledge 4307 operation terminates, this will automatically unset "ANI enable" and 4308 should terminate any temporarily needed state on the device to 4309 perform BRSKI - DULL GRASP, BRSKI pledge and any IPv6 configuration 4310 on interfaces. 4312 10.5.6. Undoing ANI/ACP enable 4314 Disabling ANI/ACP by undoing "ACP/ANI enable" is a risk for the 4315 reliable operations of the ACP if it can be executed by mistake or 4316 unauthorized. This behavior could be influenced through some 4317 additional property in the certificate (e.g., in the domain 4318 information extension field) subject to future work: In an ANI 4319 deployment intended for convenience, disabling it could be allowed 4320 without further constraints. In an ANI deployment considered to be 4321 critical more checks would be required. One very controlled option 4322 would be to not permit these commands unless the domain certificate 4323 has been revoked or is denied renewal. Configuring this option would 4324 be a parameter on the BRSKI registrar(s). As long as the node did 4325 not receive a domain certificate, undoing "ANI/ACP enable" should not 4326 have any additional constraints. 4328 10.5.7. Summary 4330 Node-wide "ACP/ANI enable [up-if-only]" commands enable the operation 4331 of ACP/ANI. This is only auto-enabled on ANI greenfield devices, 4332 otherwise it must be configured explicitly. 4334 If the option "up-if-only" is not selected, interfaces enabled for 4335 ACP/ANI interpret "down" state as "admin down" and not "physical 4336 down". In "admin-down" all non-ACP/ANI packets are filtered, but the 4337 physical layer is kept running to permit ACP/ANI to operate. 4339 (New) commands that result in physical interruption ("physical down", 4340 "loopback") of ACP/ANI enabled interfaces should be built to protect 4341 continuance or reestablishment of ACP as much as possible. 4343 Interface level "ACP/ANI enable" control per-interface operations. 4344 It is enabled by default on native interfaces and has to be 4345 configured explicitly on other interfaces. 4347 Disabling "ACP/ANI enable" global and per-interface should have 4348 additional checks to minimize undesired breakage of ACP. The degree 4349 of control could be a domain wide parameter in the domain 4350 certificates. 4352 10.6. ACP Neighbor discovery protocol selection 4354 This section discusses why GRASP DULL was chosen as the discovery 4355 protocol for L2 adjacent candidate ACP neighbors. The contenders 4356 considered where GRASP, mDNS or LLDP. 4358 10.6.1. LLDP 4360 LLDP and Cisco's earlier Cisco Discovery Protocol (CDP) are example 4361 of L2 discovery protocols that terminate their messages on L2 ports. 4362 If those protocols would be chosen for ACP neighbor discovery, ACP 4363 neighbor discovery would therefore also terminate on L2 ports. This 4364 would prevent ACP construction over non-ACP capable but LLDP or CDP 4365 enabled L2 switches. LLDP has extensions using different MAC 4366 addresses and this could have been an option for ACP discovery as 4367 well, but the additional required IEEE standardization and definition 4368 of a profile for such a modified instance of LLDP seemed to be more 4369 work than the benefit of "reusing the existing protocol" LLDP for 4370 this very simple purpose. 4372 10.6.2. mDNS and L2 support 4374 Multicast DNNS (mDNS) [RFC6762] with DNS Service Discovery (DNS-SD) 4375 Resource Records (RRs) as defined in [RFC6763] is a key contender as 4376 an ACP discovery protocol. because it relies on link-local IP 4377 multicast, it does operates at the subnet level, and is also found in 4378 L2 switches. The authors of this document are not aware of mDNS 4379 implementation that terminate their mDNS messages on L2 ports instead 4380 of the subnet level. If mDNS was used as the ACP discovery mechanism 4381 on an ACP capable (L3)/L2 switch as outlined in Section 7, then this 4382 would be necessary to implement. It is likely that termination of 4383 mDNS messages could only be applied to all mDNS messages from such a 4384 port, which would then make it necessary to software forward any non- 4385 ACP related mDNS messages to maintain prior non-ACP mDNS 4386 functionality. Adding support for ACP into such L2 switches with 4387 mDNS could therefore create regression problems for prior mDNS 4388 functionality on those nodes. With low performance of software 4389 forwarding in many L2 switches, this could also make the ACP risky to 4390 support on such L2 switches. 4392 10.6.3. Why DULL GRASP 4394 LLDP was not considered because of the above mentioned issues. mDNS 4395 was not selected because of the above L2 mDNS considerations and 4396 because of the following additional points: 4398 If mDNS was not already existing in a node, it would be more work to 4399 implement than DULL GRASP, and if an existing implementation of mDNS 4400 was used, it would likely be more code space than a separate 4401 implementation of DULL GRASP or a shared implementation of DULL GRASP 4402 and GRASP in the ACP. 4404 10.7. Choice of routing protocol (RPL) 4406 This section motivates why RPL - "IPv6 Routing Protocol for Low-Power 4407 and Lossy Networks ([RFC6550] was chosen as the default (and in this 4408 specification only) routing protocol for the ACP. The choice and 4409 above explained profile was derived from a pre-standard 4410 implementation of ACP that was successfully deployed in operational 4411 networks. 4413 Requirements for routing in the ACP are: 4415 o Self-management: The ACP must build automatically, without human 4416 intervention. Therefore routing protocol must also work 4417 completely automatically. RPL is a simple, self-managing 4418 protocol, which does not require zones or areas; it is also self- 4419 configuring, since configuration is carried as part of the 4420 protocol (see Section 6.7.6 of [RFC6550]). 4422 o Scale: The ACP builds over an entire domain, which could be a 4423 large enterprise or service provider network. The routing 4424 protocol must therefore support domains of 100,000 nodes or more, 4425 ideally without the need for zoning or separation into areas. RPL 4426 has this scale property. This is based on extensive use of 4427 default routing. RPL also has other scalability improvements, 4428 such as selecting only a subset of peers instead of all possible 4429 ones, and trickle support for information synchronization. 4431 o Low resource consumption: The ACP supports traditional network 4432 infrastructure, thus runs in addition to traditional protocols. 4433 The ACP, and specifically the routing protocol must have low 4434 resource consumption both in terms of memory and CPU requirements. 4435 Specifically, at edge nodes, where memory and CPU are scarce, 4436 consumption should be minimal. RPL builds a destination-oriented 4437 directed acyclic graph (DODAG), where the main resource 4438 consumption is at the root of the DODAG. The closer to the edge 4439 of the network, the less state needs to be maintained. This 4440 adapts nicely to the typical network design. Also, all changes 4441 below a common parent node are kept below that parent node. 4443 o Support for unstructured address space: In the Autonomic 4444 Networking Infrastructure, node addresses are identifiers, and may 4445 not be assigned in a topological way. Also, nodes may move 4446 topologically, without changing their address. Therefore, the 4447 routing protocol must support completely unstructured address 4448 space. RPL is specifically made for mobile ad-hoc networks, with 4449 no assumptions on topologically aligned addressing. 4451 o Modularity: To keep the initial implementation small, yet allow 4452 later for more complex methods, it is highly desirable that the 4453 routing protocol has a simple base functionality, but can import 4454 new functional modules if needed. RPL has this property with the 4455 concept of "objective function", which is a plugin to modify 4456 routing behavior. 4458 o Extensibility: Since the Autonomic Networking Infrastructure is a 4459 new concept, it is likely that changes in the way of operation 4460 will happen over time. RPL allows for new objective functions to 4461 be introduced later, which allow changes to the way the routing 4462 protocol creates the DAGs. 4464 o Multi-topology support: It may become necessary in the future to 4465 support more than one DODAG for different purposes, using 4466 different objective functions. RPL allow for the creation of 4467 several parallel DODAGs, should this be required. This could be 4468 used to create different topologies to reach different roots. 4470 o No need for path optimization: RPL does not necessarily compute 4471 the optimal path between any two nodes. However, the ACP does not 4472 require this today, since it carries mainly non-delay-sensitive 4473 feedback loops. It is possible that different optimization 4474 schemes become necessary in the future, but RPL can be expanded 4475 (see point "Extensibility" above). 4477 10.8. ACP Information Distribution and multicast 4479 IP multicast is not used by the ACP because the ANI (Autonomic 4480 Networking Infrastructure) itself does not require IP multicast but 4481 only service announcement/discovery. Using IP multicast for that 4482 would have made it necessary to develop a zero-touch auto configuring 4483 solution for ASM (Any Source Multicast - the original form of IP 4484 multicast defined in [RFC1112]), which would be quite complex and 4485 difficult to justify. One aspect of complexity where no attempt at a 4486 solution has been described in IETF documents is the automatic- 4487 selection of routers that should be PIM Sparse Mode (PIM-SM) 4488 Rendezvous Points (RPs) (see [RFC7761]). The other aspects of 4489 complexity are the implementation of MLD ([RFC4604]), PIM-SM and 4490 Anycast-RP (see [RFC4610]). If those implementations already exist 4491 in a product, then they would be very likely tied to accelerated 4492 forwarding which consumes hardware resources, and that in return is 4493 difficult to justify as a cost of performing only service discovery. 4495 Some future ASA may need high performance in-network data 4496 replication. That is the case when the use of IP multicast is 4497 justified. Such an ASA can then use service discovery from ACP 4498 GRASP, and then they do not need ASM but only SSM (Source Specific 4499 Multicast, see [RFC4607]) for the IP multicast replication. SSM 4500 itself can simply be enabled in the Data-Plane (or even in an update 4501 to the ACP) without any other configuration than just enabling it on 4502 all nodes and only requires a simpler version of MLD (see [RFC5790]). 4504 LSP (Link State Protocol) based IGP routing protocols typically have 4505 a mechanism to flood information, and such a mechanism could be used 4506 to flood GRASP objectives by defining them to be information of that 4507 IGP. This would be a possible optimization in future variations of 4508 the ACP that do use an LSP routing protocol. Note though that such a 4509 mechanism would not work easily for GRASP M_DISCOVERY messages which 4510 are intelligently (constrained) flooded not across the whole ACP, but 4511 only up to a node where a responder is found. We do expect that many 4512 future services in ASA will have only few consuming ASA, and for 4513 those cases, M_DISCOVERY is the more efficient method than flooding 4514 across the whole domain. 4516 Because the ACP uses RPL, one desirable future extension is to use 4517 RPLs existing notion of loop-free distribution trees (DODAG) to make 4518 GRASPs flooding more efficient both for M_FLOOD and M_DISCOVERY) See 4519 Section 6.12.5 how this will be specifically beneficial when using 4520 NBMA interfaces. This is not currently specified in this document 4521 because it is not quite clear yet what exactly the implications are 4522 to make GRASP flooding depend on RPL DODAG convergence and how 4523 difficult it would be to let GRASP flooding access the DODAG 4524 information. 4526 10.9. Extending ACP channel negotiation (via GRASP) 4528 The mechanism described in the normative part of this document to 4529 support multiple different ACP secure channel protocols without a 4530 single network wide MTI protocol is important to allow extending 4531 secure ACP channel protocols beyond what is specified in this 4532 document, but it will run into problem if it would be used for 4533 multiple protocols: 4535 The need to potentially have multiple of these security associations 4536 even temporarily run in parallel to determine which of them works 4537 best does not support the most lightweight implementation options. 4539 The simple policy of letting one side (Alice) decide what is best may 4540 not lead to the mutual best result. 4542 The two limitations can easier be solved if the solution was more 4543 modular and as few as possible initial secure channel negotiation 4544 protocols would be used, and these protocols would then take on the 4545 responsibility to support more flexible objectives to negotiate the 4546 mutually preferred ACP security channel protocol. 4548 IKEv2 is the IETF standard protocol to negotiate network security 4549 associations. It is meant to be extensible, but it is unclear 4550 whether it would be feasible to extend IKEv2 to support possible 4551 future requirements for ACP secure channel negotiation: 4553 Consider the simple case where the use of native IPsec vs. IPsec via 4554 GRE is to be negotiated and the objective is the maximum throughput. 4555 Both sides would indicate some agreed upon performance metric and the 4556 preferred encapsulation is the one with the higher performance of the 4557 slower side. IKEv2 does not support negotiation with this objective. 4559 Consider DTLS and some form of MacSec are to be added as negotiation 4560 options - and the performance objective should work across all IPsec, 4561 dDTLS and MacSec options. In the case of MacSEC, the negotiation 4562 would also need to determine a key for the peering. It is unclear if 4563 it would be even appropriate to consider extending the scope of 4564 negotiation in IKEv2 to those cases. Even if feasible to define, it 4565 is unclear if implementations of IKEv2 would be eager to adopt those 4566 type of extension given the long cycles of security testing that 4567 necessarily goes along with core security protocols such as IKEv2 4568 implementations. 4570 A more modular alternative to extending IKEv2 could be to layer a 4571 modular negotiation mechanism on top of the multitude of existing or 4572 possible future secure channel protocols. For this, GRASP over TLS 4573 could be considered as a first ACP secure channel negotiation 4574 protocol. The following are initial considerations for such an 4575 approach. A full specification is subject to a separate document: 4577 To explicitly allow negotiation of the ACP channel protocol, GRASP 4578 over a TLS connection using the GRASP_LISTEN_PORT and the nodes and 4579 peers link-local IPv6 address is used. When Alice and Bob support 4580 GRASP negotiation, they do prefer it over any other non-explicitly 4581 negotiated security association protocol and should wait trying any 4582 non-negotiated ACP channel protocol until after it is clear that 4583 GRASP/TLS will not work to the peer. 4585 When Alice and Bob successfully establish the GRASP/TSL session, they 4586 will negotiate the channel mechanism to use using objectives such as 4587 performance and perceived quality of the security. After agreeing on 4588 a channel mechanism, Alice and Bob start the selected Channel 4589 protocol. Once the secure channel protocol is successfully running, 4590 the GRASP/TLS connection can be kept alive or timed out as long as 4591 the selected channel protocol has a secure association between Alice 4592 and Bob. When it terminates, it needs to be re-negotiated via GRASP/ 4593 TLS. 4595 Notes: 4597 o Negotiation of a channel type may require IANA assignments of code 4598 points. 4600 o TLS is subject to reset attacks, which IKEv2 is not. Normally, 4601 ACP connections (as specified in this document) will be over link- 4602 local addresses so the attack surface for this one issue in TCP 4603 should be reduced (note that this may not be true when ACP is 4604 tunneled as described in Section 8.2.2. 4606 o GRASP packets received inside a TLS connection established for 4607 GRASP/TLS ACP negotiation are assigned to a separate GRASP domain 4608 unique to that TLS connection. 4610 10.10. CAs, domains and routing subdomains 4612 There is a wide range of setting up different ACP solution by 4613 appropriately using CAs and the domain and rsub elements in the 4614 domain information field of the domain certificate. We summarize 4615 these options here as they have been explained in different parts of 4616 the document in before and discuss possible and desirable extensions: 4618 An ACP domain is the set of all ACP nodes using certificates from the 4619 same CA using the same domain field. GRASP inside the ACP is run 4620 across all transitively connected ACP nodes in a domain. 4622 The rsub element in the domain information field permits the use of 4623 addresses from different ULA prefixes. One use case is to create 4624 multiple networks that initially may be separated, but where it 4625 should be possible to connect them without further extensions to ACP 4626 when necessary. 4628 Another use case for routing subdomains is as the starting point for 4629 structuring routing inside an ACP. For example, different routing 4630 subdomains could run different routing protocols or different 4631 instances of RPL and auto-aggregation / distribution of routes could 4632 be done across inter routing subdomain ACP channels based on 4633 negotiation (e.g., via GRASP). This is subject for further work. 4635 RPL scales very well. It is not necessary to use multiple routing 4636 subdomains to scale ACP domains in a way it would be possible if 4637 other routing protocols where used. They exist only as options for 4638 the above mentioned reasons. 4640 If different ACP domains are to be created that should not allow to 4641 connect to each other by default, these ACP domains simply need to 4642 have different domain elements in the domain information field. 4643 These domain elements can be arbitrary, including subdomains of one 4644 another: Domains "example.com" and "research.example.com" are 4645 separate domains if both are domain elements in the domain 4646 information element of certificates. 4648 It is not necessary to have a separate CA for different ACP domains: 4649 an operator can use a single CA to sign certificates for multiple ACP 4650 domains that are not allowed to connect to each other because the 4651 checks for ACP adjacencies includes comparison of the domain part. 4653 If multiple independent networks choose the same domain name but had 4654 their own CA, these would not form a single ACP domain because of CA 4655 mismatch. Therefore there is no problem in choosing domain names 4656 that are potentially also used by others. Nevertheless it is highly 4657 recommended to use domain names that one can have high probability to 4658 be unique. It is recommended to use domain names that start with a 4659 DNS domain names owned by the assigning organization and unique 4660 within it. For example "acp.example.com" if you own "example.com". 4662 Future extensions, primarily through intent can create more flexible 4663 options how to build ACP domains. 4665 Intent could modify the ACP connection check to permit connections 4666 between different domains. 4668 If different domains use the same CA one would change the ACP setup 4669 to permit for the ACP to be established between the two ACP nodes, 4670 but no routing nor ACP GRASP to be built across this adjacency. The 4671 main difference over routing subdomains is to not permit for the ACP 4672 GRASP instance to be built across the adjacency. Instead, one would 4673 only build a point to point GRASP instance between those peers to 4674 negotiate what type of exchanges are desired across that connection. 4675 This would include routing negotiation, how much GRASP information to 4676 transit and what Data-Plane forwarding should be done. This approach 4677 could also allow for Intent to only be injected into the network from 4678 one side and propagate via this GRASP connection. 4680 If different domains have different CAs, they should start to trust 4681 each other by intent injected into both domains that would add the 4682 other domains CA as a trust point during the ACP connection setup - 4683 and then following up with the previous point of inter-domain 4684 connections across domains with the same CA (e.g., GRASP 4685 negotiation). 4687 10.11. Adopting ACP concepts for other environments 4689 The ACP as specified in this document is very explicit about the 4690 choice of options to allow interoperable implementations. The 4691 choices made may not be the best for all environments, but the 4692 concepts used by the ACP can be used to build derived solutions: 4694 The ACP specifies the use of ULA and deriving its prefix from the 4695 domain name so that no address allocation is required to deploy the 4696 ACP. The ACP will equally work not using ULA but any other /50 IPv6 4697 prefix. This prefix could simply be a configuration of the ACP 4698 registrars (for example when using BRSKI) to enroll the domain 4699 certificates - instead of the ACP registrar deriving the /50 ULA 4700 prefix from the AN domain name. 4702 Some solutions may already have an auto-addressing scheme, for 4703 example derived from existing unique device identifiers (e.g., MAC 4704 addresses). In those cases it may not be desirable to assign 4705 addresses to devices via the ACP address information field in the way 4706 described in this document. The certificate may simply serve to 4707 identify the ACP domain, and the address field could be empty/unused. 4708 The only fix required in the remaining way the ACP operate is to 4709 define another element in the domain certificate for the two peers to 4710 decide who is Alice and who is Bob during secure channel building. 4711 Note though that future work may leverage the acp address to 4712 authenticate "ownership" of the address by the device. If the 4713 address used by a device is derived from some pre-existing permanent 4714 local ID (such as MAC address), then it would be useful to store that 4715 address in the certificate using the format of the access address 4716 information field or in a similar way. 4718 The ACP is defined as a separate VRF because it intends to support 4719 well managed networks with a wide variety of configurations. 4720 Therefore, reliable, configuration-indestructible connectivity cannot 4721 be achieved from the Data-Plane itself. In solutions where all 4722 transit connectivity impacting functions are fully automated 4723 (including security), indestructible and resilient, it would be 4724 possible to eliminate the need for the ACP to be a separate VRF. 4725 Consider the most simple example system in which there is no separate 4726 Data-Plane, but the ACP is the Data-Plane. Add BRSKI, and it becomes 4727 a fully autonomic network - except that it does not support automatic 4728 addressing for user equipment. This gap can then be closed for 4729 example by adding a solution derived from 4730 [I-D.ietf-anima-prefix-management]. 4732 TCP/TLS as the protocols to provide reliability and security to GRASP 4733 in the ACP may not be the preferred choice in constrained networks. 4734 For example, CoAP/DTLS (Constrained Application Protocol) may be 4735 preferred where they are already used, allowing to reduce the 4736 additional code space footprint for the ACP on those devices. 4737 Because the transport for GRASP is not only hop-by-hop, but end-to- 4738 end across the ACP, this would require the definition of an 4739 incompatible variant of the ACP. Non-constrained devices could 4740 support both variants (the ACP as defined here, and one using CoAP/ 4741 DTLS for GRASP), and the variant used in a deployment could be chosen 4742 for example through a parameter of the domain certificate. 4744 The routing protocol chosen by the ACP design (RPL) does explicitly 4745 not optimize for shortest paths and fastest convergence. Variations 4746 of the ACP may want to use a different routing protocol or introduce 4747 more advanced RPL profiles. 4749 Variations such as what routing protocol to use, or whether to 4750 instantiate an ACP in a VRF or (as suggested above) as the actual 4751 Data-Plane, can be automatically chosen in implementations built to 4752 support multiple options by deriving them from future parameters in 4753 the certificate. Parameters in certificates should be limited to 4754 those that would not need to be changed more often than certificates 4755 would need to be updated anyhow; Or by ensuring that these parameters 4756 can be provisioned before the variation of an ACP is activated in a 4757 node. Using BRSKI, this could be done for example as additional 4758 follow-up signaling directly after the certificate enrollment, still 4759 leveraging the BRSKI TLS connection and therefore not introducing any 4760 additional connectivity requirements. 4762 Last but not least, secure channel protocols including their 4763 encapsulation are easily added to ACP solutions. Secure channels may 4764 even be replaced by simple neighbor authentication to create 4765 simplified ACP variations for environments where no real security is 4766 required but just protection against non-malicious misconfiguration. 4767 Or for environments where all traffic is known or forced to be end- 4768 to-end protected and other means for infrastructure protection are 4769 used. Any future network OAM should always use end-to-end security 4770 anyhow and can leverage the domain certificates and is therefore not 4771 dependent on security to be provided for by ACP secure channels. 4773 11. Security Considerations 4775 An ACP is self-protecting and there is no need to apply configuration 4776 to make it secure. Its security therefore does not depend on 4777 configuration. 4779 However, the security of the ACP depends on a number of other 4780 factors: 4782 o The usage of domain certificates depends on a valid supporting PKI 4783 infrastructure. If the chain of trust of this PKI infrastructure 4784 is compromised, the security of the ACP is also compromised. This 4785 is typically under the control of the network administrator. 4787 o Security can be compromised by implementation errors (bugs), as in 4788 all products. 4790 There is no prevention of source-address spoofing inside the ACP. 4791 This implies that if an attacker gains access to the ACP, it can 4792 spoof all addresses inside the ACP and fake messages from any other 4793 node. 4795 Fundamentally, security depends on correct operation, implementation 4796 and architecture. Autonomic approaches such as the ACP largely 4797 eliminate the dependency on correct operation; implementation and 4798 architectural mistakes are still possible, as in all networking 4799 technologies. 4801 Many details of ACP are designed with security in mind and discussed 4802 elsewhere in the document: 4804 IPv6 addresses used by nodes in the ACP are covered as part of the 4805 nodes domain certificate as described in Section 6.1.1. This allows 4806 even verification of ownership of a peers IPv6 address when using a 4807 connection authenticated with the domain certificate. 4809 The ACP acts as a security (and transport) substrate for GRASP inside 4810 the ACP such that GRASP is not only protected by attacks from the 4811 outside, but also by attacks from compromised inside attackers - by 4812 relying not only on hop-by-hop security of ACP secure channels, but 4813 adding end-to-end security for those GRASP messages. See 4814 Section 6.8.2. 4816 ACP provides for secure, resilient zero-touch discovery of EST 4817 servers for certificate renewal. See Section 6.1.3. 4819 ACP provides extensible, auto-configuring hop-by-hop protection of 4820 the ACP infrastructure via the negotiation of hop-by-hop secure 4821 channel protocols. See Section 6.5 and Section 10.9. 4823 The ACP is designed to minimize attacks from the outside by 4824 minimizing its dependency against any non-ACP operations on a node. 4825 The only dependency in the specification in this document is the need 4826 to share link-local addresses for the ACP secure channel 4827 encapsulation with the Data-Plane. See Section 6.12.2. 4829 In combination with BRSKI, ACP enables a resilient, fully zero-touch 4830 network solution for short-lived certificates that can be renewed or 4831 re-enrolled even after unintentional expiry (e.g., because of 4832 interrupted connectivity). See Section 10.1. 4834 12. IANA Considerations 4836 This document defines the "Autonomic Control Plane". 4838 The IANA is requested to register the value "AN_ACP" (without quotes) 4839 to the GRASP Objectives Names Table in the GRASP Parameter Registry. 4840 The specification for this value is this document, Section 6.3. 4842 The IANA is requested to register the value "SRV.est" (without 4843 quotes) to the GRASP Objectives Names Table in the GRASP Parameter 4844 Registry. The specification for this value is this document, 4845 Section 6.1.3. 4847 Note that the objective format "SRV." is intended to be 4848 used for any that is an [RFC6335] registered service 4849 name. This is a proposed update to the GRASP registry subject to 4850 future work and only mentioned here for informational purposed to 4851 explain the unique format of the objective name. 4853 The IANA is requested to create an ACP Parameter Registry with 4854 currently one registry table - the "ACP Address Type" table. 4856 "ACP Address Type" Table. The value in this table are numeric values 4857 0...3 paired with a name (string). Future values MUST be assigned 4858 using the Standards Action policy defined by [RFC8126]. The 4859 following initial values are assigned by this document: 4861 0: ACP Zone Addressing Sub-Scheme (ACP RFC Figure 9) / ACP Manual 4862 Addressing Sub-Scheme (ACP RFC Section 6.10.4) 4863 1: ACP Vlong Addressing Sub-Scheme (ACP RFC Section 6.10.5) 4865 13. Acknowledgements 4867 This work originated from an Autonomic Networking project at Cisco 4868 Systems, which started in early 2010. Many people contributed to 4869 this project and the idea of the Autonomic Control Plane, amongst 4870 which (in alphabetical order): Ignas Bagdonas, Parag Bhide, Balaji 4871 BL, Alex Clemm, Yves Hertoghs, Bruno Klauser, Max Pritikin, Michael 4872 Richardson, Ravi Kumar Vadapalli. 4874 Special thanks to Brian Carpenter, Elwyn Davies, Joel Halpern and 4875 Sheng Jiang for their thorough reviews and to Pascal Thubert and 4876 Michael Richardson to provide the details for the recommendations of 4877 the use of RPL in the ACP. 4879 Further input, review or suggestions were received from: Rene Struik, 4880 Brian Carpenter, Benoit Claise, William Atwood and Yongkang Zhang. 4882 14. Change log [RFC Editor: Please remove] 4884 14.1. Initial version 4886 First version of this document: draft-behringer-autonomic-control- 4887 plane 4889 14.2. draft-behringer-anima-autonomic-control-plane-00 4891 Initial version of the anima document; only minor edits. 4893 14.3. draft-behringer-anima-autonomic-control-plane-01 4895 o Clarified that the ACP should be based on, and support only IPv6. 4897 o Clarified in intro that ACP is for both, between devices, as well 4898 as for access from a central entity, such as an NMS. 4900 o Added a section on how to connect an NMS system. 4902 o Clarified the hop-by-hop crypto nature of the ACP. 4904 o Added several references to GDNP as a candidate protocol. 4906 o Added a discussion on network split and merge. Although, this 4907 should probably go into the certificate management story longer 4908 term. 4910 14.4. draft-behringer-anima-autonomic-control-plane-02 4912 Addresses (numerous) comments from Brian Carpenter. See mailing list 4913 for details. The most important changes are: 4915 o Introduced a new section "overview", to ease the understanding of 4916 the approach. 4918 o Merged the previous "problem statement" and "use case" sections 4919 into a mostly re-written "use cases" section, since they were 4920 overlapping. 4922 o Clarified the relationship with draft-ietf-anima-stable- 4923 connectivity 4925 14.5. draft-behringer-anima-autonomic-control-plane-03 4927 o Took out requirement for IPv6 --> that's in the reference doc. 4929 o Added requirement section. 4931 o Changed focus: more focus on autonomic functions, not only virtual 4932 out-of-band. This goes a bit throughout the document, starting 4933 with a changed abstract and intro. 4935 14.6. draft-ietf-anima-autonomic-control-plane-00 4937 No changes; re-submitted as WG document. 4939 14.7. draft-ietf-anima-autonomic-control-plane-01 4941 o Added some paragraphs in addressing section on "why IPv6 only", to 4942 reflect the discussion on the list. 4944 o Moved the Data-Plane ACP out of the main document, into an 4945 appendix. The focus is now the virtually separated ACP, since it 4946 has significant advantages, and isn't much harder to do. 4948 o Changed the self-creation algorithm: Part of the initial steps go 4949 into the reference document. This document now assumes an 4950 adjacency table, and domain certificate. How those get onto the 4951 device is outside scope for this document. 4953 o Created a new section 6 "workarounds for non-autonomic nodes", and 4954 put the previous controller section (5.9) into this new section. 4955 Now, section 5 is "autonomic only", and section 6 explains what to 4956 do with non-autonomic stuff. Much cleaner now. 4958 o Added an appendix explaining the choice of RPL as a routing 4959 protocol. 4961 o Formalised the creation process a bit more. Now, we create a 4962 "candidate peer list" from the adjacency table, and form the ACP 4963 with those candidates. Also it explains now better that policy 4964 (Intent) can influence the peer selection. (section 4 and 5) 4966 o Introduce a section for the capability negotiation protocol 4967 (section 7). This needs to be worked out in more detail. This 4968 will likely be based on GRASP. 4970 o Introduce a new parameter: ACP tunnel type. And defines it in the 4971 IANA considerations section. Suggest GRE protected with IPSec 4972 transport mode as the default tunnel type. 4974 o Updated links, lots of small edits. 4976 14.8. draft-ietf-anima-autonomic-control-plane-02 4978 o Added explicitly text for the ACP channel negotiation. 4980 o Merged draft-behringer-anima-autonomic-addressing-02 into this 4981 document, as suggested by WG chairs. 4983 14.9. draft-ietf-anima-autonomic-control-plane-03 4985 o Changed Neighbor discovery protocol from GRASP to mDNS. Bootstrap 4986 protocol team decided to go with mDNS to discover bootstrap proxy, 4987 and ACP should be consistent with this. Reasons to go with mDNS 4988 in bootstrap were a) Bootstrap should be reuseable also outside of 4989 full anima solutions and introduce as few as possible new 4990 elements. mDNS was considered well-known and very-likely even pre- 4991 existing in low-end devices (IoT). b) Using GRASP both for the 4992 insecure neighbor discovery and secure ACP operatations raises the 4993 risk of introducing security issues through implementation issues/ 4994 non-isolation between those two instances of GRASP. 4996 o Shortened the section on GRASP instances, because with mDNS being 4997 used for discovery, there is no insecure GRASP session any longer, 4998 simplifying the GRASP considerations. 5000 o Added certificate requirements for ANIMA in section 5.1.1, 5001 specifically how the ANIMA information is encoded in 5002 subjectAltName. 5004 o Deleted the appendix on "ACP without separation", as originally 5005 planned, and the paragraph in the main text referring to it. 5007 o Deleted one sub-addressing scheme, focusing on a single scheme 5008 now. 5010 o Included information on how ANIMA information must be encoded in 5011 the domain certificate in section "preconditions". 5013 o Editorial changes, updated draft references, etc. 5015 14.10. draft-ietf-anima-autonomic-control-plane-04 5017 Changed discovery of ACP neighbor back from mDNS to GRASP after 5018 revisiting the L2 problem. Described problem in discovery section 5019 itself to justify. Added text to explain how ACP discovery relates 5020 to BRSKY (bootstrap) discovery and pointed to Michael Richardsons 5021 draft detailing it. Removed appendix section that contained the 5022 original explanations why GRASP would be useful (current text is 5023 meant to be better). 5025 14.11. draft-ietf-anima-autonomic-control-plane-05 5027 o Section 5.3 (candidate ACP neighbor selection): Add that Intent 5028 can override only AFTER an initial default ACP establishment. 5030 o Section 6.10.1 (addressing): State that addresses in the ACP are 5031 permanent, and do not support temporary addresses as defined in 5032 RFC4941. 5034 o Modified Section 6.3 to point to the GRASP objective defined in 5035 draft-carpenter-anima-ani-objectives. (and added that reference) 5037 o Section 6.10.2: changed from MD5 for calculating the first 40 bits 5038 to SHA256; reason is MD5 should not be used any more. 5040 o Added address sub-scheme to the IANA section. 5042 o Made the routing section more prescriptive. 5044 o Clarified in Section 8.1.1 the ACP Connect port, and defined that 5045 term "ACP Connect". 5047 o Section 8.2: Added some thoughts (from mcr) on how traversing a L3 5048 cloud could be automated. 5050 o Added a CRL check in Section 6.7. 5052 o Added a note on the possibility of source-address spoofing into 5053 the security considerations section. 5055 o Other editoral changes, including those proposed by Michael 5056 Richardson on 30 Nov 2016 (see ANIMA list). 5058 14.12. draft-ietf-anima-autonomic-control-plane-06 5060 o Added proposed RPL profile. 5062 o detailed DTLS profile - DTLS with any additional negotiation/ 5063 signaling channel. 5065 o Fixed up text for ACP/GRE encap. Removed text claiming its 5066 incompatible with non-GRE IPsec and detailled it. 5068 o Added text to suggest admin down interfaces should still run ACP. 5070 14.13. draft-ietf-anima-autonomic-control-plane-07 5072 o Changed author association. 5074 o Improved ACP connect setion (after confusion about term came up in 5075 the stable connectivity draft review). Added picture, defined 5076 complete terminology. 5078 o Moved ACP channel negotiation from normative section to appendix 5079 because it can in the timeline of this document not be fully 5080 specified to be implementable. Aka: work for future document. 5081 That work would also need to include analysing IKEv2 and describin 5082 the difference of a proposed GRASP/TLS solution to it. 5084 o Removed IANA request to allocate registry for GRASP/TLS. This 5085 would come with future draft (see above). 5087 o Gave the name "ACP information field" to the field in the 5088 certificate carrying the ACP address and domain name. 5090 o Changed the rules for mutual authentication of certificates to 5091 rely on the domain in the ACP information field of the certificate 5092 instead of the OU in the certificate. Also renewed the text 5093 pointing out that the ACP information field in the certificate is 5094 meant to be in a form that it does not disturb other uses of the 5095 certificate. As long as the ACP expected to rely on a common OU 5096 across all certificates in a domain, this was not really true: 5097 Other uses of the certificates might require different OUs for 5098 different areas/type of devices. With the rules in this draft 5099 version, the ACP authentication does not rely on any other fields 5100 in the certificate. 5102 o Added an extension field to the ACP information field so that in 5103 the future additional fields like a subdomain could be inserted. 5104 An example using such a subdomain field was added to the pre- 5105 existing text suggesting sub-domains. This approach is necessary 5106 so that there can be a single (main) domain in the ACP information 5107 field, because that is used for mutual authentication of the 5108 certificate. Also clarified that only the register(s) SHOULD/MUST 5109 use that the ACP address was generated from the domain name - so 5110 that we can easier extend change this in extensions. 5112 o Took the text for the GRASP discovery of ACP neighbors from Brians 5113 grasp-ani-objectives draft. Alas, that draft was behind the 5114 latest GRASP draft, so i had to overhaul. The mayor change is to 5115 describe in the ACP draft the whole format of the M_FLOOD message 5116 (and not only the actual objective). This should make it a lot 5117 easier to read (without having to go back and forth to the GRASP 5118 RFC/draft). It was also necessary because the locator in the 5119 M_FLOOD messages has an important role and its not coded inside 5120 the objective. The specification of how to format the M_FLOOD 5121 message shuold now be complete, the text may be some duplicate 5122 with the DULL specificateion in GRASP, but no contradiction. 5124 o One of the main outcomes of reworking the GRASP section was the 5125 notion that GRASP announces both the candidate peers IPv6 link 5126 local address but also the support ACP security protocol including 5127 the port it is running on. In the past we shied away from using 5128 this information because it is not secured, but i think the 5129 additional attack vectors possible by using this information are 5130 negligible: If an attacker on an L2 subnet can fake another 5131 devices GRASP message then it can already provide a similar amount 5132 of attack by purely faking the link-local address. 5134 o Removed the section on discovery and BRSKI. This can be revived 5135 in the BRSKI document, but it seems mood given how we did remove 5136 mDNS from the latest BRSKI document (aka: this section discussed 5137 discrepancies between GRASP and mDNS discovery which should not 5138 exist anymore with latest BRSKI. 5140 o Tried to resolve the EDNOTE about CRL vs. OCSP by pointing out we 5141 do not specify which one is to be used but that the ACP should be 5142 used to reach the URL included in the certificate to get to the 5143 CRL storage or OCSP server. 5145 o Changed ACP via IPsec to ACP via IKEv2 and restructured the 5146 sections to make IPsec native and IPsec via GRE subsections. 5148 o No need for any assigned DTLS port if ACP is run across DTLS 5149 because it is signaled via GRASP. 5151 14.14. draft-ietf-anima-autonomic-control-plane-08 5153 Modified mentioning of BRSKI to make it consistent with current 5154 (07/2017) target for BRSKI: MASA and IDevID are mandatory. Devices 5155 with only insecure UDI would need a security reduced variant of 5156 BRSKI. Also added mentioning of Netconf Zero-Touch. Made BRSKI non- 5157 normative for ACP because wrt. ACP it is just one option how the 5158 domain certificate can be provisioned. Instead, BRSKI is mandatory 5159 when a device implements ANI which is ACP+BRSKI. 5161 Enhanced text for ACP across tunnels to decribe two options: one 5162 across configured tunnels (GRE, IPinIP etc) a more efficient one via 5163 directed DULL. 5165 Moved decription of BRSKI to appendex to emphasize that BRSKI is not 5166 a (normative) dependency of GRASP, enhanced text to indicate other 5167 options how Domain Certificates can be provisioned. 5169 Added terminology section. 5171 Separated references into normative and non-normative. 5173 Enhanced section about ACP via "tunnels". Defined an option to run 5174 ACP secure channel without an outer tunnel, discussed PMTU, benefits 5175 of tunneling, potential of using this with BRSKI, made ACP via GREP a 5176 SHOULD requirement. 5178 Moved appendix sections up before IANA section because there where 5179 concerns about appendices to be to far on the bottom to be read. 5180 Added (Informative) / (Normative) to section titles to clarify which 5181 sections are informative and which are normative 5183 Moved explanation of ACP with L2 from precondition to separate 5184 section before workarounds, made it instructive enough to explain how 5185 to implement ACP on L2 ports for L3/L2 switches and made this part of 5186 normative requirement (L2/L3 switches SHOULD support this). 5188 Rewrote section "GRASP in the ACP" to define GRASP in ACP as 5189 mandatory (and why), and define the ACP as security and transport 5190 substrate to GRASP in ACP. And how it works. 5192 Enhanced "self-protection" properties section: protect legacy 5193 management protocols. Security in ACP is for protection from outside 5194 and those legacy protocols. Otherwise need end-to-end encryption 5195 also inside ACP, e.g., with domain certificate. 5197 Enhanced initial domain certificate section to include requirements 5198 for maintenance (renewal/revocation) of certificates. Added 5199 explanation to BRSKI informative section how to handle very short 5200 lived certificates (renewal via BRSKI with expired cert). 5202 Modified the encoding of the ACP address to better fit RFC822 simple 5203 local-parts (":" as required by RFC5952 are not permitted in simple 5204 dot-atoms according to RFC5322. Removed reference to RFC5952 as its 5205 now not needed anymore. 5207 Introduced a sub-domain field in the ACP information in the 5208 certificate to allow defining such subdomains with depending on 5209 future Intent definitions. It also makes it clear what the "main 5210 domain" is. Scheme is called "routing subdomain" to have a unique 5211 name. 5213 Added V8 (now called Vlong) addressing sub-scheme according to 5214 suggestion from mcr in his mail from 30 Nov 2016 5215 (https://mailarchive.ietf.org/arch/msg/anima/ 5216 nZpEphrTqDCBdzsKMpaIn2gsIzI). Also modified the explanation of the 5217 single V bit in the first sub-scheme now renamed to Zone sub-scheme 5218 to distinguish it. 5220 14.15. draft-ietf-anima-autonomic-control-plane-09 5222 Added reference to RFC4191 and explained how it should be used on ACP 5223 edge routers to allow auto configuration of routing by NMS hosts. 5224 This came after review of stable connectivity draft where ACP connect 5225 is being referred to. 5227 V8 addressing Sub-Scheme was modified to allow not only /8 device- 5228 local address space but also /16. This was in response to the 5229 possible need to have maybe as much as 2^12 local addresses for 5230 future encaps in BRSKI like IPinIP. It also would allow fully 5231 autonomic address assignment for ACP connect interfaces from this 5232 local address space (on an ACP edge device), subject to approval of 5233 the implied update to rfc4291/rfc4193 (IID length). Changed name to 5234 Vlong addressing sub-scheme. 5236 Added text in response to Brian Carpenters review of draft-ietf- 5237 anima-stable-connectivity-04. 5239 o The stable connectivity draft was vaguely describing ACP connect 5240 behavior that is better standardized in this ACP draft. 5242 o Added new ACP "Manual" addressing sub-scheme with /64 subnets for 5243 use with ACP connect interfaces. Being covered by the ACP ULA 5244 prefix, these subnets do not require additional routing entries 5245 for NMS hosts. They also are fully 64-bit IID length compliant 5246 and therefore not subject to 4191bis considerations. And they 5247 avoid that operators manually assign prefixes from the ACP ULA 5248 prefixes that might later be assigned autonomiously. 5250 o ACP connect auto-configuration: Defined that ACP edge devices, NMS 5251 hosts should use RFC4191 to automatically learn ACP prefixes. 5252 This is especially necessary when the ACP uses multiple ULA 5253 prefixes (via e.g., the rsub domain certificate option), or if ACP 5254 connect subinterfaces use manually configured prefixes NOT covered 5255 by the ACP ULA prefixes. 5257 o Explained how rfc6724 is (only) sufficient when the NMS host has a 5258 separate ACP connect and Data-Plane interface. But not when there 5259 is a single interface. 5261 o Added a separate subsection to talk about "software" instead of 5262 "NMS hosts" connecting to the ACP via the "ACP connect" method. 5263 The reason is to point out that the "ACP connect" method is not 5264 only a workaround (for NMS hosts), but an actual desirable long 5265 term architectural component to modularily build software (e.g., 5266 ASA or OAM for VNF) into ACP devices. 5268 o Added a section to define how to run ACP connect across the same 5269 interface as the Data-Plane. This turns out to be quite 5270 challenging because we only want to rely on existing standards for 5271 the network stack in the NMS host/software and only define what 5272 features the ACP edge device needs. 5274 o Added section about use of GRASP over ACP connect. 5276 o Added text to indicate packet processing/filtering for security: 5277 filter incorrect packets arriving on ACP connect interfaces, 5278 diagnose on RPL root packets to incorrect destination address (not 5279 in ACP connect section, but because of it). 5281 o Reaffirm security goal of ACP: Do not permit non-ACP routers into 5282 ACP routing domain. 5284 Made this ACP document be an update to RFC4291 and RFC4193. At the 5285 core, some of the ACP addressing sub-schemes do effectively not use 5286 64-bit IIDs as required by RFC4191 and debated in rfc4191bis. During 5287 6man in prague, it was suggested that all documents that do not do 5288 this should be classified as such updates. Add a rather long section 5289 that summarizes the relevant parts of ACP addressing and usage and. 5290 Aka: This section is meant to be the primary review section for 5291 readers interested in these changes (e.g., 6man WG.). 5293 Added changes from Michael Richardsons review https://github.com/ 5294 anima-wg/autonomic-control-plane/pull/3/commits, textual and: 5296 o ACP discovery inside ACP is bad *doh*!. 5298 o Better CA trust and revocation sentences. 5300 o More details about RPL behavior in ACP. 5302 o black hole route to avoid loops in RPL. 5304 Added requirement to terminate ACP channels upon cert expiry/ 5305 revocation. 5307 Added fixes from 08-mcr-review-reply.txt (on github): 5309 o AN Domain Names are FQDNs. 5311 o Fixed bit length of schemes, numerical writing of bits (00b/01b). 5313 o Lets use US american english. 5315 14.16. draft-ietf-anima-autonomic-control-plane-10 5317 Used the term routing subdomain more consistently where previously 5318 only subdomain was used. Clarified use of routing subdomain in 5319 creation of ULA "global ID" addressing prefix. 5321 6.7.1.* Changed native IPsec encapsulation to tunnel mode 5322 (necessary), explaned why. Added notion that ESP is used, added 5323 explanations why tunnel/transport mode in native vs. GRE cases. 5325 6.10.3/6.10.5 Added term "ACP address range/set" to be able to better 5326 explain how the address in the ACP certificate is actually the base 5327 address (lowest address) of a range/set that is available to the 5328 device. 5330 6.10.4 Added note that manual address sub-scheme addresses must not 5331 be used within domain certificates (only for explicit configuration). 5333 6.12.5 Refined explanation of how ACP virtual interfaces work (p2p 5334 and multipoint). Did seek for pre-existing RFCs that explain how to 5335 built a multi-access interface on top of a full mesh of p2p 5336 connections (6man WG, anima WG mailing lists), but could not find any 5337 prior work that had a succinct explanation. So wrote up an 5338 explanation here. Added hopefully all necessary and sufficient 5339 details how to map ACP unicast packets to ACP secure channel, how to 5340 deal with ND packet details. Added verbage for ACP not to assign the 5341 virtual interface link-local address from the underlying interface. 5342 Addd note that GRAP link-local messages are treated specially but 5343 logically the same. Added paragraph about NBMA interfaces. 5345 remaining changes from Brian Carpenters review. See Github file 5346 draft-ietf-anima-autonomic-control-plane/08-carpenter-review-reply.tx 5347 for more detailst: 5349 Added multiple new RFC references for terms/technologies used. 5351 Fixed verbage in several places. 5353 2. (terminology) Added 802.1AR as reference. 5355 2. Fixed up definition of ULA. 5357 6.1.1 Changed definition of ACP information in cert into ABNF format. 5358 Added warning about maximum size of ACP address field due to domain- 5359 name limitations. 5361 6.2 Mentioned API requirement between ACP and clients leveraging 5362 adjacency table. 5364 6.3 Fixed TTL in GRASP example: msec, not hop-count!. 5366 6.8.2 MAYOR: expanded security/transport substrate text: 5368 Introduced term ACP GRASP virtual interface to explain how GRASP 5369 link-local multicast messages are encapsulated and replicated to 5370 neighbors. Explain how ACP knows when to use TLS vs. TCP (TCP only 5371 for link-local address (sockets). Introduced "ladder" picture to 5372 visualize stack. 5374 6.8.2.1 Expanded discussion/explanation of security model. TLS for 5375 GRASP unicsast connections across ACP is double encryption (plus 5376 underlying ACP secure channel), but highly necessary to avoid very 5377 simple man-in-the-middle attacks by compromised ACP members on-path. 5378 Ultimately, this is done to ensure that any apps using GRASP can get 5379 full end-to-end secrecy for information sent across GRASP. But for 5380 publically known ASA services, even this will not provide 100% 5381 security (this is discussed). Also why double encryption is the 5382 better/easier solution than trying to optimize this. 5384 6.10.1 Added discussion about pseudo-random addressing, scanning- 5385 attaacks (not an issue for ACP). 5387 6.12.2 New performance requirements section added. 5389 6.10.1 Added notion to first experiment with existing addressing 5390 schemes before defining new ones - we should be flexible enough. 5392 6.3/7.2 clarified the interactions between MLD and DULL GRASP and 5393 specified what needs to be done (e.g., in 2 switches doing ACP per L2 5394 port). 5396 12. Added explanations and cross-references to various security 5397 aspects of ACP discussed elsewhere in the document. 5399 13. Added IANA requirements. 5401 Added RFC2119 boilerplate. 5403 14.17. draft-ietf-anima-autonomic-control-plane-11 5405 Same text as -10 Unfortunately when uploading -10 .xml/.txt to 5406 datatracker, a wrong version of .txt got uploaded, only the .xml was 5407 correct. This impacts the -10 html version on datatra cker and the 5408 PDF versions as well. Because rfcdiff also compares the .txt 5409 version, this -11 version was crea ted so that one can compare 5410 changes from -09 and changes to the next version (-12). 5412 14.18. draft-ietf-anima-autonomic-control-plane-12 5414 Sheng Jiangs extensive review. Thanks! See Github file draft-ietf- 5415 anima-autonomic-control-plane/09-sheng-review-reply.txt for more 5416 details. Many of the larger changes listed below where inspired by 5417 the review. 5419 Removed the claim that the document is updating RFC4291,RFC4193 and 5420 the section detailling it. Done on suggestion of Michael Richardson 5421 - just try to describe use of addressing in a way that would not 5422 suggest a need claim update to architecture. 5424 Terminology cleanup: 5426 o Replaced "device" with "node" in text. Kept "device" only when 5427 referring to "physical node". Added definitions for those words. 5428 Includes changes of derived terms, especially in addressing: 5429 "Node-ID" and "Node-Number" in the addressing details. 5431 o Replaced term "autonomic FOOBAR" with "acp FOOBAR" as whereever 5432 appropriate: "autonomic" would imply that the node would need to 5433 support more than the ACP, but that is not correct in most of the 5434 cases. Wanted to make sure that implementers know they only need 5435 to support/implement ACP - unless stated otherwise. Includes 5436 "AN->ACP node", "AN->ACP adjacency table" and so on. 5438 1 Added explanation in the introduction about relationship between 5439 ACP, BRSKI, ANI and Autonomic Networks. 5441 6.1.1 Improved terminology and features of the certificate 5442 information field. Now called domain information field instead of 5443 ACP information field. The acp-address field in the domain 5444 information field is now optional, enabling easier introduction of 5445 various future options. 5447 6.1.2 Moved ACP domainer membership check from section 6.6 to (ACP 5448 secure channels setup) here because it is not only used for ACP 5449 secure channel setup. 5451 6.1.3 Fix text about certificate renewal after discussion with Max 5452 Pritikin/Michael Richardson/Brian Carpenter: 5454 o Version 10 erroneously assumed that the certificate itself could 5455 store a URL for renewal, but that is only possible for CRL URLs. 5456 Text now only refers to "remembered EST server" without implying 5457 that this is stored in the certificate. 5459 o Objective for RFC7030/EST domain certificate renewal was changed 5460 to "SRV.est" See also IANA section for explanation. 5462 o Removed detail of distance based service selection. This can be 5463 better done in future work because it would require a lot more 5464 detail for a good DNS-SD compatible approach. 5466 o Removed detail about trying to create more security by using ACP 5467 address from certificate of peer. After rethinking, this does not 5468 seem to buy additional security. 5470 6.10 Added reference to 6.12.5 in initial use of "loopback interface" 5471 in section 6.10 in result of email discussion michaelR/michaelB. 5473 10.2 Introduced informational section (diagnostics) because of 5474 operational experience - ACP/ANI undeployable without at least 5475 diagnostics like this. 5477 10.3 Introduced informational section (enabling/disabling) ACP. 5478 Important to discuss this for security reasons (e.g., why to never 5479 never auto-enable ANI on brownfield devices), for implementers and to 5480 answer ongoing questions during WG meetings about how to deal with 5481 shutdown interface. 5483 10.8 Added informational section discussing possible future 5484 variations of the ACP for potential adopters that cannot directly use 5485 the complete solution described in this document unmodified. 5487 14.19. draft-ietf-anima-autonomic-control-plane-13 5489 Swap author list (with permission). 5491 6.1.1. Eliminate blank lines in definition by making it a picture 5492 (reformatting only). 5494 6.10.3.1 New paragraph: Explained how nodes using Zone-ID != 0 need 5495 to use Zone-ID != 0 in GRASP so that we can avoid routing/forwarding 5496 of Zone-ID = 0 prefixes. 5498 Rest of feedback from review of -12, see 5499 https://raw.githubusercontent.com/anima-wg/autonomic-control- 5500 plane/master/draft-ietf-anima-autonomic-control-plane/12-feedback- 5501 reply.txt 5503 Review from Brian Carpenter: 5505 various: Autonomous -> autonomic(ally) in all remaining occurences. 5507 various: changed "manual (configured)" to "explicitly (configured)" 5508 to not exclude the option of (SDN controller) automatic configuration 5509 (no humans involved). 5511 1. Fixed reference to section 9. 5513 2. Added definition of loopback interface == internal interface. 5514 After discus on WG mailing lists, including 6man. 5516 6.1.2 Defined CDP/OCSP and pointed to RFC5280 for them. 5518 6.1.3 Removed "EST-TLS", no objective value needed or beneficial, 5519 added explanation paragraph why. 5521 6.2 Added to adjacency table the interface that a neighbor is 5522 discovered on. 5524 6.3 Simplified CDDL syntax: Only one method per AN_ACP objective 5525 (because of locators). Example with two objectives in GRASP message. 5527 6.8.1 Added note about link-local GRASP multicast message to avoid 5528 confusion. 5530 8.1.4 Added RFC8028 as recommended on hosts to better support VRF- 5531 select with ACP. 5533 8.2.1 Rewrote and Simplified CDDL for configured remote peer and 5534 explanations. Removed pattern option for remote peer. Not important 5535 enough to be mandated. 5537 Review thread started by William Atwood: 5539 2. Refined definition of VRF (vs. MPLS/VPN, LISP, VRF-LITE). 5541 2. Refined definition of ACP (ACP includes ACP GRASP instance). 5543 2. Added explanation for "zones" to terminology section and into 5544 Zone Addressing Sub Scheme section, relating it to RFC4007 zones 5545 (from Brian Carpenter). 5547 4. Fixed text for ACP4 requirement (Clients of the ACP must not be 5548 tied to specific protocol.). 5550 5. Fixed step 4. with proposed text. 5552 6.1.1 Included suggested explanation for rsub semantics. 5554 6.1.3 must->MUST for at least one EST server in ACP network to 5555 autonomically renew certs. 5557 6.7.2 normative: AND MUST NOT (permit weaker crypto options. 5559 6.7.1.1 also included text denying weaker IPsec profile options. 5561 6.8.2 Fixed description how to build ACP GRASP virtual interfaces. 5562 Added text that ACP continues to exist in absence of ACP neighbors. 5564 various: Make sure all "zone" words are used consistently. 5566 6.10.2/various: fixed 40 bit RFC4193 ULA prefix in all examples to 5567 89b714f3db (thanks MichaelR). 5569 6.10.1 Removed comment about assigned ULA addressing. Decision not 5570 to use it now ancient history of WG decision making process, not 5571 worth nothing anymore in the RFC. 5573 Review from Yongkang Zhang: 5575 6.10.5 Fixed length of Node-Numbers in ACP Vlong Addressing Sub- 5576 Scheme. 5578 14.20. draft-ietf-anima-autonomic-control-plane-14 5580 Disclaimer: All new text introduced by this revision provides only 5581 additional explanations/ details based on received reviews and 5582 analysis by the authors. No changes to beavior already specified in 5583 prior revisions. 5585 Joel Halpern, review part 3: 5587 Define/explain "ACP registrar" in reply to Joel Halpern review part 5588 3, resolving primarily 2 documentation issues:: 5590 1. Unclear how much ACP depends on BRSKI. ACP document was 5591 referring unqualified to registrars and Registrar-ID in the 5592 addressing section without explaining what a registrar is, 5593 leading to the assumption it must be a BRSKI Registrar. 5595 2. Unclear how the ACP addresses in ACP domain certificates are 5596 assigned because the BRSKI document does not defines this, but 5597 refers to this ACP document. 5599 Wrt. 1: ACP does NOT depend on BRSKI registrars, instead ANY 5600 appropriate automated or manual mechanism can be used to enroll ACP 5601 nodes with ACP domain certificates. This revision calls defines such 5602 mechanisms the "ACP registrar" and defines requirements. this is 5603 non-normative, because it does not define specific mechanisms that 5604 need to be support. In ANI devices, ACP Registrars are BRSKI 5605 Registrars. In non-ANI ACP networks, the registrar may simply be a 5606 person using CLI/web-interfaces to provision domain certificates and 5607 set the ACP address correctly in the ACP domain certificate. 5609 Wrt. 2.: The BRSKI document does rightfully not define how the ACP 5610 address assignment and creation of the ACP domain information field 5611 has to work because this is independent of BRSKI and needs to follow 5612 the same rules whatever protocol/mechanisms are used to implement an 5613 ACP Registrar. Another set of protocols that could be used instead 5614 of BRSKI is Netconf/Netconf-Call-Home, but such an alternative ACP 5615 Registrar solution would need to be speficied in it's own document. 5617 Additional text/sections had to be added to detail important 5618 conditions so that automatic certificate maintenance for ACP nodes 5619 (with BRSKI or other mechanisms) can be done in a way that as good as 5620 possible maintains ACP address information of ACP nodes across the 5621 nodes lifetime because that ACP address is intended as an identifier 5622 of the ACP node. 5624 Summary of sections added: 5626 6.1.3.5/6.1.3.6 (normative): re-enrollment of ACP nodes after 5627 certificate exiry/failure in a way that allows to maintain as much 5628 as possible ACP address information. 5630 6.10.7 (normative): defines "ACP Registrar" including requirements 5631 and how it can perform ACP address assignment. 5633 10.3 (informative): details / examples about registrars to help 5634 implementers and operators understand easier how they operate, and 5635 provide suggestion of models that a likely very ueful (sub-CA and/ 5636 or centralized policy manaement). 5638 10.4 (informative): Explains the need for the multiple address 5639 sub-spaces defined in response to discuss with Joel. 5641 Other changes: 5643 Updated references (RFC8366, RFC8368). 5645 Introduced sub-section headings for 6.1.3 (certificate maintenance) 5646 because section became too long with newly added sub-sections. Also 5647 some small text fixups/remove of duplicate text. 5649 Gen-ART review, Elwyn Davies: 5651 [RFC Editor: how can i raise the issue of problematic cross 5652 references of terms in the terminology section - rendering is 5653 problematic. ]. 5655 4. added explanation for ACP4 (finally). 5657 6.1.1 Simplified text in bullet list explaining rfc822 encoding. 5659 6.1.3 refined second paragraph defining remembering of previous EST 5660 server and explaiing how to do this with BRSKI. 5662 9.1 Added paragraph outlining the benefit of the sub-CA Registrar 5663 option for supporting partitioned networks. 5665 Roughly 100 more nits/minor fixes throughout the document. See: 5666 https://raw.githubusercontent.com/anima-wg/autonomic-control- 5667 plane/master/draft-ietf-anima-autonomic-control-plane/13-elwynd- 5668 reply.txt 5670 Joel Halpern, review part 2: 5672 6.1.1: added note about "+ +" format in address field when acp- 5673 address and rsub are empty. 5675 6.5.10 - clarified text about V bit in Vlong addressing scheme. 5677 6.10.3/6.10.4 - moved the Z bit field up front (directly after base 5678 scheme) and indicated more explicitly Z is part of selecting of the 5679 sub-addressing scheme. 5681 Refined text about reaching CRL Distribution Point, explain why 5682 address as indicator to use ACP. 5684 Note from Brian Carpenter: RFC Editor note for section reference into 5685 GRASP. 5687 IOT directorate review from Pascal Thubert: 5689 Various Nits/typos. 5691 TBD: Punted wish for mentioning RFC reference titles to RFC editor 5692 for now. 5694 1. Added section 1.1 - applicability, discussing protocol choices 5695 re. applicability to constrained devices (or not). Added notion of 5696 TCP/TLS va CoAP/DTLS to section 10.4 in support of this. 5698 2. Added in-band / out-of-band into terminology. 5700 5. Referenced section 8.2 for remote ACP channel configuration. 5702 6.3 made M_FLOOD periods RECOMMENDED (less guesswork) 5704 6.7.x Clarified conditional nature of MUST for the profile details of 5705 IPsec parameters (aka: onlt 6.7.3 defines actual MUST for nodes, 5706 prior notions only define the requirements for IPsec profiles IF 5707 IPsec is supported. 5709 6.8.1 Moved discussion about IP multicast, IGP, RPL for GRASP into a 5710 new subsection in the informative part (section 10) to tighten up 5711 text in normative part. 5713 6.10.1 added another reference to stable-connectivity for interop 5714 with IPv4 management. 5716 6.10.1 removed mentioning of ULA-Random, term was used in email 5717 discus of ULA with L=1, but term actually not defined in rfc4193, so 5718 mentioning it is just confusing/redundant. Also added note about the 5719 random hash being defined in this document, not using SHA1 from 5720 rfc4193. 5722 6.11.1.1 added suggested text about mechanisms to further reduce 5723 opportunities for loop during reconvergence (active signaling options 5724 from RFC6550). 5726 6.11.1.3 made mode 2 MUST and mode 2 MAY (RPL MOP - mode of 5727 operations). Removes ambiguity ambiguity. 5729 6.12.5 Added recommendation for RFC4429 (optimistic DAD). 5731 Nits from Benjamin Kaduk: dTLS -> DTLS: 5733 Review from Joel Halpern: 5735 1. swapped order of "purposes" for ACP to match order in section 3. 5737 1. Added notion about manageability of ACP gong beyond RFC7575 5738 (before discussion of stable connectivity). 5740 2. Changed definition of Intent to be same as reference model 5741 (policy lanuage instead of API). 5743 6.1.1 changed BNF specification so that a local-part without acp- 5744 address (for future extensions) would not be rfcSELF.+rsub but 5745 simpler rfcSELF+rsub. Added explanation why rsub is in local-part. 5747 Tried to eliminate unnecessary references to VRF to minimize 5748 assumption how system is designed. 5750 6.1.3 Explained how to make CDP reachable via ACP. 5752 6.7.2 Made it clearer that constrained devices MUST support DTLS if 5753 they can not support IPsec. 5755 6.8.2.1 clarified first paragraph (TCP restransmissions lightweight). 5757 6.11.1 fixed up RPL profile text - to remove "VRF". Text was also 5758 buggy. mentioned control plane, but its a forwarding/silicon issue to 5759 have these header. 5761 6.12.5 Clarified how link-local ACP channel address can be derived, 5762 and how not. 5764 8.2.1 Fixed up text to distinguish between configuration and model 5765 describing parameters of the configuration (spec only provides 5766 parameter model). 5768 Various Nits. 5770 14.21. wish-list 5772 From -13 review from Pascal Thubert: Picture to show dual-NOC routing 5773 limitation. 5775 [RFC Editor: Question: Is it possible to change the first occurences 5776 of [RFCxxxx] references to "rfcxxx title" [RFCxxxx]? the XML2RFC 5777 format does not seem to offer such a format, but i did not want to 5778 duplicate 50 first references to be duplicate - one reference for 5779 title mentioning and one for RFC number.] 5781 15. References 5783 15.1. Normative References 5785 [I-D.ietf-anima-grasp] 5786 Bormann, C., Carpenter, B., and B. Liu, "A Generic 5787 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 5788 grasp-15 (work in progress), July 2017. 5790 [I-D.ietf-cbor-cddl] 5791 Birkholz, H., Vigano, C., and C. Bormann, "Concise data 5792 definition language (CDDL): a notational convention to 5793 express CBOR data structures", draft-ietf-cbor-cddl-02 5794 (work in progress), February 2018. 5796 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 5797 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 5798 . 5800 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 5801 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 5802 DOI 10.17487/RFC3810, June 2004, 5803 . 5805 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 5806 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 5807 November 2005, . 5809 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 5810 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 5811 . 5813 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 5814 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 5815 2006, . 5817 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 5818 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 5819 December 2005, . 5821 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 5822 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 5823 DOI 10.17487/RFC4861, September 2007, 5824 . 5826 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 5827 Address Autoconfiguration", RFC 4862, 5828 DOI 10.17487/RFC4862, September 2007, 5829 . 5831 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 5832 Specifications: ABNF", STD 68, RFC 5234, 5833 DOI 10.17487/RFC5234, January 2008, 5834 . 5836 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 5837 (TLS) Protocol Version 1.2", RFC 5246, 5838 DOI 10.17487/RFC5246, August 2008, 5839 . 5841 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 5842 Housley, R., and W. Polk, "Internet X.509 Public Key 5843 Infrastructure Certificate and Certificate Revocation List 5844 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 5845 . 5847 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 5848 DOI 10.17487/RFC5322, October 2008, 5849 . 5851 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 5852 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 5853 January 2012, . 5855 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 5856 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 5857 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 5858 Low-Power and Lossy Networks", RFC 6550, 5859 DOI 10.17487/RFC6550, March 2012, 5860 . 5862 [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing 5863 Protocol for Low-Power and Lossy Networks (RPL)", 5864 RFC 6552, DOI 10.17487/RFC6552, March 2012, 5865 . 5867 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 5868 Power and Lossy Networks (RPL) Option for Carrying RPL 5869 Information in Data-Plane Datagrams", RFC 6553, 5870 DOI 10.17487/RFC6553, March 2012, 5871 . 5873 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 5874 "Enrollment over Secure Transport", RFC 7030, 5875 DOI 10.17487/RFC7030, October 2013, 5876 . 5878 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 5879 Kivinen, "Internet Key Exchange Protocol Version 2 5880 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 5881 2014, . 5883 [RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support 5884 for Generic Routing Encapsulation (GRE)", RFC 7676, 5885 DOI 10.17487/RFC7676, October 2015, 5886 . 5888 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 5889 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 5890 May 2017, . 5892 15.2. Informative References 5894 [AR8021] IEEE SA-Standards Board, "IEEE Standard for Local and 5895 metropolitan area networks - Secure Device Identity", 5896 December 2009, . 5899 [I-D.ietf-anima-bootstrapping-keyinfra] 5900 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 5901 S., and K. Watsen, "Bootstrapping Remote Secure Key 5902 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 5903 keyinfra-15 (work in progress), April 2018. 5905 [I-D.ietf-anima-prefix-management] 5906 Jiang, S., Du, Z., Carpenter, B., and Q. Sun, "Autonomic 5907 IPv6 Edge Prefix Management in Large-scale Networks", 5908 draft-ietf-anima-prefix-management-07 (work in progress), 5909 December 2017. 5911 [I-D.ietf-anima-reference-model] 5912 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 5913 and J. Nobre, "A Reference Model for Autonomic 5914 Networking", draft-ietf-anima-reference-model-06 (work in 5915 progress), February 2018. 5917 [I-D.ietf-netconf-zerotouch] 5918 Watsen, K., Abrahamsson, M., and I. Farrer, "Zero Touch 5919 Provisioning for Networking Devices", draft-ietf-netconf- 5920 zerotouch-21 (work in progress), March 2018. 5922 [I-D.ietf-roll-applicability-template] 5923 Richardson, M., "ROLL Applicability Statement Template", 5924 draft-ietf-roll-applicability-template-09 (work in 5925 progress), May 2016. 5927 [I-D.ietf-roll-useofrplinfo] 5928 Robles, I., Richardson, M., and P. Thubert, "When to use 5929 RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll- 5930 useofrplinfo-23 (work in progress), May 2018. 5932 [LLDP] IEEE SA-Standards Board, "IEEE Standard for Local and 5933 Metropolitan Area Networks: Station and Media Access 5934 Control Connectivity Discovery", June 2016, 5935 . 5938 [MACSEC] IEEE SA-Standards Board, "IEEE Standard for Local and 5939 Metropolitan Area Networks: Media Access Control (MAC) 5940 Security", June 2006, 5941 . 5944 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 5945 RFC 1112, DOI 10.17487/RFC1112, August 1989, 5946 . 5948 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 5949 and E. Lear, "Address Allocation for Private Internets", 5950 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 5951 . 5953 [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax 5954 Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998, 5955 . 5957 [RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", 5958 RFC 2821, DOI 10.17487/RFC2821, April 2001, 5959 . 5961 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 5962 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 5963 DOI 10.17487/RFC4007, March 2005, 5964 . 5966 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 5967 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 5968 2006, . 5970 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 5971 for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, 5972 . 5974 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 5975 "Considerations for Internet Group Management Protocol 5976 (IGMP) and Multicast Listener Discovery (MLD) Snooping 5977 Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, 5978 . 5980 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 5981 Group Management Protocol Version 3 (IGMPv3) and Multicast 5982 Listener Discovery Protocol Version 2 (MLDv2) for Source- 5983 Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, 5984 August 2006, . 5986 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 5987 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 5988 . 5990 [RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol 5991 Independent Multicast (PIM)", RFC 4610, 5992 DOI 10.17487/RFC4610, August 2006, 5993 . 5995 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 5996 Extensions for Stateless Address Autoconfiguration in 5997 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 5998 . 6000 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 6001 DOI 10.17487/RFC5321, October 2008, 6002 . 6004 [RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet 6005 Group Management Protocol Version 3 (IGMPv3) and Multicast 6006 Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, 6007 DOI 10.17487/RFC5790, February 2010, 6008 . 6010 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 6011 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 6012 . 6014 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 6015 and A. Bierman, Ed., "Network Configuration Protocol 6016 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 6017 . 6019 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 6020 Cheshire, "Internet Assigned Numbers Authority (IANA) 6021 Procedures for the Management of the Service Name and 6022 Transport Protocol Port Number Registry", BCP 165, 6023 RFC 6335, DOI 10.17487/RFC6335, August 2011, 6024 . 6026 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 6027 "Default Address Selection for Internet Protocol Version 6 6028 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 6029 . 6031 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 6032 DOI 10.17487/RFC6762, February 2013, 6033 . 6035 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 6036 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 6037 . 6039 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 6040 Locator/ID Separation Protocol (LISP)", RFC 6830, 6041 DOI 10.17487/RFC6830, January 2013, 6042 . 6044 [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local 6045 Addressing inside an IPv6 Network", RFC 7404, 6046 DOI 10.17487/RFC7404, November 2014, 6047 . 6049 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 6050 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 6051 Defined Networking (SDN): Layers and Architecture 6052 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 6053 2015, . 6055 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 6056 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 6057 Networking: Definitions and Design Goals", RFC 7575, 6058 DOI 10.17487/RFC7575, June 2015, 6059 . 6061 [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap 6062 Analysis for Autonomic Networking", RFC 7576, 6063 DOI 10.17487/RFC7576, June 2015, 6064 . 6066 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 6067 Considerations for IPv6 Address Generation Mechanisms", 6068 RFC 7721, DOI 10.17487/RFC7721, March 2016, 6069 . 6071 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 6072 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 6073 Multicast - Sparse Mode (PIM-SM): Protocol Specification 6074 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 6075 2016, . 6077 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 6078 RFC 7950, DOI 10.17487/RFC7950, August 2016, 6079 . 6081 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 6082 Hosts in a Multi-Prefix Network", RFC 8028, 6083 DOI 10.17487/RFC8028, November 2016, 6084 . 6086 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 6087 Writing an IANA Considerations Section in RFCs", BCP 26, 6088 RFC 8126, DOI 10.17487/RFC8126, June 2017, 6089 . 6091 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 6092 "A Voucher Artifact for Bootstrapping Protocols", 6093 RFC 8366, DOI 10.17487/RFC8366, May 2018, 6094 . 6096 [RFC8368] Eckert, T., Ed. and M. Behringer, "Using an Autonomic 6097 Control Plane for Stable Connectivity of Network 6098 Operations, Administration, and Maintenance (OAM)", 6099 RFC 8368, DOI 10.17487/RFC8368, May 2018, 6100 . 6102 Authors' Addresses 6104 Toerless Eckert (editor) 6105 Huawei USA - Futurewei Technologies Inc. 6106 2330 Central Expy 6107 Santa Clara 95050 6108 USA 6110 Email: tte+ietf@cs.fau.de 6111 Michael H. Behringer (editor) 6113 Email: michael.h.behringer@gmail.com 6115 Steinthor Bjarnason 6116 Arbor Networks 6117 2727 South State Street, Suite 200 6118 Ann Arbor MI 48104 6119 United States 6121 Email: sbjarnason@arbor.net