idnits 2.17.1 draft-ietf-anima-autonomic-control-plane-17.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 1081 has weird spacing: '... called rfcS...' == Line 1807 has weird spacing: '...k-local unic...' == Line 1808 has weird spacing: '...lticast messa...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (August 07, 2018) is 2087 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: 'RFCxxxx' is mentioned on line 426, but not defined -- Looks like a reference, but probably isn't: '1' on line 5805 == Missing Reference: 'RFC2119' is mentioned on line 691, but not defined == Missing Reference: 'ACP VRF' is mentioned on line 3029, but not defined == Missing Reference: 'Data-Plane' is mentioned on line 3031, but not defined == Missing Reference: 'Select' is mentioned on line 3176, but not defined == Missing Reference: 'Plane' is mentioned on line 3178, but not defined -- Looks like a reference, but probably isn't: '2' on line 6376 == Unused Reference: 'RFC1034' is defined on line 5490, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-applicability-template' is defined on line 5616, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-cbor-cddl-03 ** 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-16 == 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-22 == 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 (~~), 19 warnings (==), 6 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: February 8, 2019 6 S. Bjarnason 7 Arbor Networks 8 August 07, 2018 10 An Autonomic Control Plane (ACP) 11 draft-ietf-anima-autonomic-control-plane-17 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 February 8, 2019. 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 (Informative) . . . . . . . . . . . . . . . . . 5 60 1.1. Applicability and Scope . . . . . . . . . . . . . . . . . 8 61 2. Acronyms and Terminology (Informative) . . . . . . . . . . . 9 62 3. Use Cases for an Autonomic Control Plane (Informative) . . . 15 63 3.1. An Infrastructure for Autonomic Functions . . . . . . . . 15 64 3.2. Secure Bootstrap over a not configured Network . . . . . 15 65 3.3. Data-Plane Independent Permanent Reachability . . . . . . 16 66 4. Requirements (Informative) . . . . . . . . . . . . . . . . . 17 67 5. Overview (Informative) . . . . . . . . . . . . . . . . . . . 18 68 6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 19 69 6.1. ACP Domain, Certificate and Network . . . . . . . . . . . 20 70 6.1.1. Certificate Domain Information Field . . . . . . . . 21 71 6.1.2. ACP domain membership check . . . . . . . . . . . . . 23 72 6.1.3. Certificate Maintenance . . . . . . . . . . . . . . . 24 73 6.1.3.1. GRASP objective for EST server . . . . . . . . . 25 74 6.1.3.2. Renewal . . . . . . . . . . . . . . . . . . . . . 26 75 6.1.3.3. Certificate Revocation Lists (CRLs) . . . . . . . 26 76 6.1.3.4. Lifetimes . . . . . . . . . . . . . . . . . . . . 27 77 6.1.3.5. Re-enrollment . . . . . . . . . . . . . . . . . . 27 78 6.1.3.6. Failing Certificates . . . . . . . . . . . . . . 29 79 6.2. ACP Adjacency Table . . . . . . . . . . . . . . . . . . . 29 80 6.3. Neighbor Discovery with DULL GRASP . . . . . . . . . . . 30 81 6.4. Candidate ACP Neighbor Selection . . . . . . . . . . . . 33 82 6.5. Channel Selection . . . . . . . . . . . . . . . . . . . . 34 83 6.6. Candidate ACP Neighbor verification . . . . . . . . . . . 35 84 6.7. Security Association protocols . . . . . . . . . . . . . 35 85 6.7.1. ACP via IKEv2 . . . . . . . . . . . . . . . . . . . . 35 86 6.7.1.1. Native IPsec . . . . . . . . . . . . . . . . . . 36 87 6.7.1.2. IPsec with GRE encapsulation . . . . . . . . . . 36 88 6.7.2. ACP via DTLS . . . . . . . . . . . . . . . . . . . . 37 89 6.7.3. ACP Secure Channel Requirements . . . . . . . . . . . 37 90 6.8. GRASP in the ACP . . . . . . . . . . . . . . . . . . . . 38 91 6.8.1. GRASP as a core service of the ACP . . . . . . . . . 38 92 6.8.2. ACP as the Security and Transport substrate for GRASP 38 93 6.8.2.1. Discussion . . . . . . . . . . . . . . . . . . . 40 94 6.9. Context Separation . . . . . . . . . . . . . . . . . . . 41 95 6.10. Addressing inside the ACP . . . . . . . . . . . . . . . . 42 96 6.10.1. Fundamental Concepts of Autonomic Addressing . . . . 42 97 6.10.2. The ACP Addressing Base Scheme . . . . . . . . . . . 43 98 6.10.3. ACP Zone Addressing Sub-Scheme . . . . . . . . . . . 44 99 6.10.3.1. Usage of the Zone-ID Field . . . . . . . . . . . 46 100 6.10.4. ACP Manual Addressing Sub-Scheme . . . . . . . . . . 47 101 6.10.5. ACP Vlong Addressing Sub-Scheme . . . . . . . . . . 48 102 6.10.6. Other ACP Addressing Sub-Schemes . . . . . . . . . . 49 103 6.10.7. ACP Registrars . . . . . . . . . . . . . . . . . . . 49 104 6.10.7.1. Use of BRSKI or other Mechanism/Protocols . . . 49 105 6.10.7.2. Unique Address/Prefix allocation . . . . . . . . 50 106 6.10.7.3. Addressing Sub-Scheme Policies . . . . . . . . . 51 107 6.10.7.4. Address/Prefix Persistence . . . . . . . . . . . 52 108 6.10.7.5. Further Details . . . . . . . . . . . . . . . . 52 109 6.11. Routing in the ACP . . . . . . . . . . . . . . . . . . . 52 110 6.11.1. RPL Profile . . . . . . . . . . . . . . . . . . . . 53 111 6.11.1.1. Summary . . . . . . . . . . . . . . . . . . . . 53 112 6.11.1.2. RPL Instances . . . . . . . . . . . . . . . . . 54 113 6.11.1.3. Storing vs. Non-Storing Mode . . . . . . . . . . 54 114 6.11.1.4. DAO Policy . . . . . . . . . . . . . . . . . . . 54 115 6.11.1.5. Path Metric . . . . . . . . . . . . . . . . . . 54 116 6.11.1.6. Objective Function . . . . . . . . . . . . . . . 54 117 6.11.1.7. DODAG Repair . . . . . . . . . . . . . . . . . . 55 118 6.11.1.8. Multicast . . . . . . . . . . . . . . . . . . . 55 119 6.11.1.9. Security . . . . . . . . . . . . . . . . . . . . 55 120 6.11.1.10. P2P communications . . . . . . . . . . . . . . . 55 121 6.11.1.11. IPv6 address configuration . . . . . . . . . . . 55 122 6.11.1.12. Administrative parameters . . . . . . . . . . . 56 123 6.11.1.13. RPL Data-Plane artifacts . . . . . . . . . . . . 56 124 6.11.1.14. Unknown Destinations . . . . . . . . . . . . . . 56 125 6.12. General ACP Considerations . . . . . . . . . . . . . . . 56 126 6.12.1. Performance . . . . . . . . . . . . . . . . . . . . 56 127 6.12.2. Addressing of Secure Channels . . . . . . . . . . . 57 128 6.12.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . 57 129 6.12.4. Multiple links between nodes . . . . . . . . . . . . 58 130 6.12.5. ACP interfaces . . . . . . . . . . . . . . . . . . . 58 131 7. ACP support on L2 switches/ports (Normative) . . . . . . . . 61 132 7.1. Why . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 133 7.2. How (per L2 port DULL GRASP) . . . . . . . . . . . . . . 62 134 8. Support for Non-ACP Components (Normative) . . . . . . . . . 64 135 8.1. ACP Connect . . . . . . . . . . . . . . . . . . . . . . . 64 136 8.1.1. Non-ACP Controller / NMS system . . . . . . . . . . . 64 137 8.1.2. Software Components . . . . . . . . . . . . . . . . . 66 138 8.1.3. Auto Configuration . . . . . . . . . . . . . . . . . 67 139 8.1.4. Combined ACP/Data-Plane Interface (VRF Select) . . . 68 140 8.1.5. Use of GRASP . . . . . . . . . . . . . . . . . . . . 69 141 8.2. ACP through Non-ACP L3 Clouds (Remote ACP neighbors) . . 70 142 8.2.1. Configured Remote ACP neighbor . . . . . . . . . . . 70 143 8.2.2. Tunneled Remote ACP Neighbor . . . . . . . . . . . . 71 144 8.2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 72 146 9. Benefits (Informative) . . . . . . . . . . . . . . . . . . . 72 147 9.1. Self-Healing Properties . . . . . . . . . . . . . . . . . 72 148 9.2. Self-Protection Properties . . . . . . . . . . . . . . . 73 149 9.2.1. From the outside . . . . . . . . . . . . . . . . . . 73 150 9.2.2. From the inside . . . . . . . . . . . . . . . . . . . 74 151 9.3. The Administrator View . . . . . . . . . . . . . . . . . 75 152 10. ACP Operations (Informative) . . . . . . . . . . . . . . . . 75 153 10.1. ACP (and BRSKI) Diagnostics . . . . . . . . . . . . . . 76 154 10.2. ACP Registrars . . . . . . . . . . . . . . . . . . . . . 80 155 10.2.1. Registrar interactions . . . . . . . . . . . . . . . 81 156 10.2.2. Registrar Parameter . . . . . . . . . . . . . . . . 82 157 10.2.3. Certificate renewal and limitations . . . . . . . . 83 158 10.2.4. ACP Registrars with sub-CA . . . . . . . . . . . . . 83 159 10.2.5. Centralized Policy Control . . . . . . . . . . . . . 84 160 10.3. Enabling and disabling ACP/ANI . . . . . . . . . . . . . 85 161 10.3.1. Filtering for non-ACP/ANI packets . . . . . . . . . 85 162 10.3.2. Admin Down State . . . . . . . . . . . . . . . . . . 85 163 10.3.2.1. Security . . . . . . . . . . . . . . . . . . . . 86 164 10.3.2.2. Fast state propagation and Diagnostics . . . . . 87 165 10.3.2.3. Low Level Link Diagnostics . . . . . . . . . . . 87 166 10.3.2.4. Power Consumption Issues . . . . . . . . . . . . 88 167 10.3.3. Interface level ACP/ANI enable . . . . . . . . . . . 88 168 10.3.4. Which interfaces to auto-enable? . . . . . . . . . . 88 169 10.3.5. Node Level ACP/ANI enable . . . . . . . . . . . . . 90 170 10.3.5.1. Brownfield nodes . . . . . . . . . . . . . . . . 90 171 10.3.5.2. Greenfield nodes . . . . . . . . . . . . . . . . 91 172 10.3.6. Undoing ANI/ACP enable . . . . . . . . . . . . . . . 91 173 10.3.7. Summary . . . . . . . . . . . . . . . . . . . . . . 92 174 11. Security Considerations . . . . . . . . . . . . . . . . . . . 92 175 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 94 176 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 94 177 14. Change log [RFC Editor: Please remove] . . . . . . . . . . . 95 178 14.1. Initial version . . . . . . . . . . . . . . . . . . . . 95 179 14.2. draft-behringer-anima-autonomic-control-plane-00 . . . . 95 180 14.3. draft-behringer-anima-autonomic-control-plane-01 . . . . 95 181 14.4. draft-behringer-anima-autonomic-control-plane-02 . . . . 95 182 14.5. draft-behringer-anima-autonomic-control-plane-03 . . . . 95 183 14.6. draft-ietf-anima-autonomic-control-plane-00 . . . . . . 96 184 14.7. draft-ietf-anima-autonomic-control-plane-01 . . . . . . 96 185 14.8. draft-ietf-anima-autonomic-control-plane-02 . . . . . . 97 186 14.9. draft-ietf-anima-autonomic-control-plane-03 . . . . . . 97 187 14.10. draft-ietf-anima-autonomic-control-plane-04 . . . . . . 97 188 14.11. draft-ietf-anima-autonomic-control-plane-05 . . . . . . 98 189 14.12. draft-ietf-anima-autonomic-control-plane-06 . . . . . . 98 190 14.13. draft-ietf-anima-autonomic-control-plane-07 . . . . . . 99 191 14.14. draft-ietf-anima-autonomic-control-plane-08 . . . . . . 100 192 14.15. draft-ietf-anima-autonomic-control-plane-09 . . . . . . 102 193 14.16. draft-ietf-anima-autonomic-control-plane-10 . . . . . . 104 194 14.17. draft-ietf-anima-autonomic-control-plane-11 . . . . . . 106 195 14.18. draft-ietf-anima-autonomic-control-plane-12 . . . . . . 106 196 14.19. draft-ietf-anima-autonomic-control-plane-13 . . . . . . 107 197 14.20. draft-ietf-anima-autonomic-control-plane-14 . . . . . . 109 198 14.21. draft-ietf-anima-autonomic-control-plane-15 . . . . . . 113 199 14.22. draft-ietf-anima-autonomic-control-plane-16 . . . . . . 114 200 14.23. draft-ietf-anima-autonomic-control-plane-17 . . . . . . 114 201 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 116 202 15.1. Normative References . . . . . . . . . . . . . . . . . . 116 203 15.2. Informative References . . . . . . . . . . . . . . . . . 119 204 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 123 205 Appendix A. Background and Futures (Informative) . . . . . . . . 123 206 A.1. ACP Address Space Schemes . . . . . . . . . . . . . . . . 124 207 A.2. BRSKI Bootstrap (ANI) . . . . . . . . . . . . . . . . . . 124 208 A.3. ACP Neighbor discovery protocol selection . . . . . . . . 126 209 A.3.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 126 210 A.3.2. mDNS and L2 support . . . . . . . . . . . . . . . . . 126 211 A.3.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 126 212 A.4. Choice of routing protocol (RPL) . . . . . . . . . . . . 127 213 A.5. ACP Information Distribution and multicast . . . . . . . 128 214 A.6. Extending ACP channel negotiation (via GRASP) . . . . . . 129 215 A.7. CAs, domains and routing subdomains . . . . . . . . . . . 131 216 A.8. Intent for the ACP . . . . . . . . . . . . . . . . . . . 132 217 A.9. Adopting ACP concepts for other environments . . . . . . 133 218 A.10. Further options / futures . . . . . . . . . . . . . . . . 135 219 A.10.1. Auto-aggregation of routes . . . . . . . . . . . . . 135 220 A.10.2. More options for avoiding IPv6 Data-Plane dependency 135 221 A.10.3. ACP APIs and operational models (YANG) . . . . . . . 136 222 A.10.4. RPL enhancements . . . . . . . . . . . . . . . . . . 136 223 A.10.5. Role assignments . . . . . . . . . . . . . . . . . . 137 224 A.10.6. Autonomic L3 transit . . . . . . . . . . . . . . . . 137 225 A.10.7. Diagnostics . . . . . . . . . . . . . . . . . . . . 137 226 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 138 228 1. Introduction (Informative) 230 Autonomic Networking is a concept of self-management: Autonomic 231 functions self-configure, and negotiate parameters and settings 232 across the network. [RFC7575] defines the fundamental ideas and 233 design goals of Autonomic Networking. A gap analysis of Autonomic 234 Networking is given in [RFC7576]. The reference architecture for 235 Autonomic Networking in the IETF is specified in the document 236 [I-D.ietf-anima-reference-model]. 238 Autonomic functions need an autonomically built communications 239 infrastructure. This infrastructure needs to be secure, resilient 240 and re-usable by all autonomic functions. Section 5 of [RFC7575] 241 introduces that infrastructure and calls it the Autonomic Control 242 Plane (ACP). More descriptively it would be the "Autonomic 243 communications infrastructure for Management and Control". For 244 naming consistency with that prior document, this document continues 245 to use the name ACP though. 247 Today, the management and control plane of networks typically uses a 248 routing and forwarding table which is dependent on correct 249 configuration and routing. Misconfigurations or routing problems can 250 therefore disrupt management and control channels. Traditionally, an 251 out-of-band network has been used to avoid or allow recovery from 252 such problems, or personnel are sent on site to access devices 253 through out-of-band management ports (also called craft ports, serial 254 console, management ethernet port). However, both options are 255 expensive. 257 In increasingly automated networks either centralized management 258 systems or distributed autonomic service agents in the network 259 require a control plane which is independent of the configuration of 260 the network they manage, to avoid impacting their own operations 261 through the configuration actions they take. 263 This document describes a modular design for a self-forming, self- 264 managing and self-protecting Autonomic Control Plane (ACP), which is 265 a virtual in-band network designed to be as independent as possible 266 of configuration, addressing and routing problems. The details how 267 this are achieved as described in Section 6. The ACP is designed to 268 remain operational even in the presence of configuration errors, 269 addressing or routing issues, or where policy could inadvertently 270 affect connectivity of both data packets or control packets. 272 This document uses the term "Data-Plane" to refer to anything in the 273 network nodes that is not the ACP, and therefore considered to be 274 dependent on (mis-)configuration. This Data-Plane includes both the 275 traditional forwarding-plane, as well as any pre-existing control- 276 plane, such as routing protocols that establish routing tables for 277 the forwarding plane. 279 The Autonomic Control Plane serves several purposes at the same time: 281 1. Autonomic functions communicate over the ACP. The ACP therefore 282 directly supports Autonomic Networking functions, as described in 283 [I-D.ietf-anima-reference-model]. For example, Generic Autonomic 284 Signaling Protocol (GRASP - [I-D.ietf-anima-grasp]) runs securely 285 inside the ACP and depends on the ACP as its "security and 286 transport substrate". 288 2. A controller or network management system can use it to securely 289 bootstrap network devices in remote locations, even if the (Data- 290 Plane) network in between is not yet configured; no Data-Plane 291 dependent bootstrap configuration is required. An example of 292 such a secure bootstrap process is described in 293 [I-D.ietf-anima-bootstrapping-keyinfra]. 295 3. An operator can use it to log into remote devices, even if the 296 network is misconfigured or not configured. 298 This document describes these purposes as use cases for the ACP in 299 Section 3, it defines the requirements in Section 4. Section 5 gives 300 an overview how the ACP is constructed. 302 The normative part of this document starts with Section 6, where the 303 the ACP is specified. Section 7 defines normative how to support ACP 304 on L2 switches. Section 8 explains normative how non-ACP nodes and 305 networks can be integrated. 307 The remaining sections are non-normative: Section 9 reviews benefits 308 of the ACP (after all the details have been defined), Section 10 309 provides operational recommendations, Appendix A provides additional 310 explanations and describes additional details or future standard or 311 propriety extensions that were considered not to be appropriate for 312 standardization in this document but were considered important to 313 document. There are no dependencies against Appendix A to build a 314 complete working and interoperable ACP according to this document. 316 The ACP provides secure IPv6 connectivity, therefore it can not only 317 be used as the secure connectivity for self-management as required 318 for the ACP in [RFC7575], but it can also be used as the secure 319 connectivity for traditional (centralized) management. The ACP can 320 be implemented and operated without any other components of autonomic 321 networks, except for the GRASP protocol which it leverages. 323 The document "Using Autonomic Control Plane for Stable Connectivity 324 of Network OAM" [RFC8368] describes how the ACP alone can be used to 325 provide secure and stable connectivity for autonomic and non- 326 autonomic Operations Administration and Management (OAM) 327 applications. That document also explains how existing management 328 solutions can leverage the ACP in parallel with traditional 329 management models, when to use the ACP and how to integrate with 330 potentially IPv4 only OAM backends. 332 Combining ACP with Bootstrapping Remote Secure Key Infrastructures 333 (BRSKI), see [I-D.ietf-anima-bootstrapping-keyinfra]) results in the 334 "Autonomic Network Infrastructure" as defined in 335 [I-D.ietf-anima-reference-model], which provides autonomic 336 connectivity (from ACP) with fully secure zero-touch (automated) 337 bootstrap from BRSKI. The ANI itself does not constitute an 338 Autonomic Network, but it allows the building of more or less 339 autonomic networks on top of it - using either centralized, Software 340 Defined Networking- (SDN-)style (see [RFC7426]) automation or 341 distributed automation via Autonomic Service Agents (ASA) / Autonomic 342 Functions (AF) - or a mixture of both. See 343 [I-D.ietf-anima-reference-model] for more information. 345 1.1. Applicability and Scope 347 Please see the following Terminology section (Section 2) for 348 explanations of terms used in this section. 350 The design of the ACP as defined in this document is considered to be 351 applicable to all types of "professionally managed" networks: Service 352 Provider, Local Area Network (LAN), Metro(politan networks), Wide 353 Area Network (WAN), Enterprise Information Technology (IT) and 354 ->"Operational Technology" () (OT) networks. The ACP can operate 355 equally on layer 3 equipment and on layer 2 equipment such a bridges 356 (see Section 7). The encryption mechanism used by the ACP is defined 357 to be negotiable, therefore it can be extended to environments with 358 different encryption protocol preferences. The minimum 359 implementation requirements in this document attempt to achieve 360 maximum interoperability by requiring support for few options: IP 361 security (IPsec), see [RFC4301]) and datagram Transport Layer 362 Security version 1.2 (DTLS), see [RFC6347]), depending on type of 363 device. 365 The implementation footprint of the ACP consists of Public Key 366 Infrastructure (PKI) code for the ACP certificate, the GRASP 367 protocol, UDP, TCP and TLS (for security and reliability of GRASP), 368 the ACP secure channel protocol used (such as IPsec or DTLS), and an 369 instance of IPv6 packet forwarding and routing via the Routing 370 Protocol for Low-power and Lossy Networks (RPL), see [RFC6550], that 371 is separate from routing and forwarding for the Data-Plane (user 372 traffic). 374 The ACP uses only IPv6 to avoid complexity of dual-stack ACP 375 operations (IPv6/IPv4). Nevertheless, it can without any changes be 376 integrated into even otherwise IPv4-only network devices. The Data- 377 Plane itself would not need to change, it could continue to be IPv4 378 only. For such IPv4 only devices, the IPv6 protocol itself would be 379 additional implementation footprint only used for the ACP. 381 The protocol choices of the ACP are primarily based on wide use and 382 support in networks and devices, well understood security properties 383 and required scalability. The ACP design is an attempt to produce 384 the lowest risk combination of existing technologies and protocols to 385 build a widely applicable operational network management solution: 387 RPL was chosen because it requires a smaller routing table footprint 388 in large networks compared to other routing protocols with an 389 autonomically configured single area. The deployment experience of 390 large scale Internet of Things (IoT) networks serves as the basis for 391 wide deployment experience with RPL. The profile chosen for RPL in 392 the ACP does not not leverage any RPL specific forwarding plane 393 features (IPv6 extension headers), making its implementation a pure 394 control plane software requirement. 396 GRASP is the only completely novel protocol used in the ACP, and this 397 choice was necessary because there is no existing suitable protocol 398 to provide the necessary functions to the ACP, so GRASP was developed 399 to fill that gap. 401 The ACP design can be applicable to (cpu, memory) constrained devices 402 and (bitrate, reliability) constrained networks, but this document 403 does not attempt to define the most constrained type of devices or 404 networks to which the ACP is applicable. RPL and DTLS are two 405 protocol choices already making ACP more applicable to constrained 406 environments. See Appendix A.9 for discussions about how future 407 standards or proprietary extensions/variations variations of the ACP 408 could better meet different expectations from those on which the 409 current design is based. 411 2. Acronyms and Terminology (Informative) 413 [RFC Editor: WG/IETF/IESG review of the terms below asked for 414 references betwen these terms when they refer to each other. The 415 only option in RFC/XML i found to point to a hanging text acronym 416 definition that also displays the actual term is the format="title" 417 version, which leads to references such as '->"ACP domain 418 certificate" ()'. I found no reasonable way to eliminate the 419 trailing '()' generated by this type of cross references. Can you 420 please take care of removing these artefacts during editing (after 421 conversion to nroff ?). Also created ticket to ask for xml2rfc 422 enhancement to avoid this in the future: 423 https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/347. 425 [RFC Editor: Question: Is it possible to change the first occurences 426 of [RFCxxxx] references to "rfcxxx title" [RFCxxxx]? the XML2RFC 427 format does not seem to offer such a format, but i did not want to 428 duplicate 50 first references to be duplicate - one reference for 429 title mentioning and one for RFC number.] 431 In the rest of the document we will refer to systems using the ACP as 432 "nodes". Typically such a node is a physical (network equipment) 433 device, but it can equally be some virtualized system. Therefore, we 434 do not refer to them as devices unless the context specifically calls 435 for a physical system. 437 This document introduces or uses the following terms (sorted 438 alphabetically). Terms introduced are explained on first use, so 439 this list is for reference only. 441 ACP: "Autonomic Control Plane". The Autonomic Function as defined 442 in this document. It provides secure zero-touch (automated) 443 transitive (network wide) IPv6 connectivity for all nodes in the 444 same ACP domain as well as a GRASP instance running across this 445 ACP IPv6 connectivity. The ACP is primarily meant to be used as a 446 component of the ANI to enable Autonomic Networks but it can 447 equally be used in simple ANI networks (with no other Autonomic 448 Functions) or completely by itself. 450 ACP address: An IPv6 address assigned to the ACP node. It is stored 451 in the domain information field of the ->"ACP domain certificate" 452 (). 454 ACP address range/set: The ACP address may imply a range or set of 455 addresses that the node can assign for different purposes. This 456 address range/set is derived by the node from the format of the 457 ACP address called the "addressing sub-scheme". 459 ACP connect interface: An interface on an ACP node providing access 460 to the ACP for non ACP capable nodes without using an ACP secure 461 channel. See Section 8.1.1. 463 ACP domain: The ACP domain is the set of nodes with ->"ACP domain 464 certificates" that allow them to authenticate each other as 465 members of the ACP domain. See also Section 6.1.2. 467 ACP (ANI/AN) Domain Certificate: A provisioned [RFC5280] certificate 468 (LDevID) carrying the domain information field which is used by 469 the ACP to learn its address in the ACP and to derive and 470 cryptographically assert its membership in the ACP domain. 472 domain information (field): An rfc822Name information element (e.g., 473 field) in the domain certificate in which the ACP relevant 474 information is encoded: the domain name and the ACP address. 476 ACP Loopback interface: The Loopback interface in the ACP Virtual 477 Routing and Forwarding (VRF) that has the ACP address assigned to 478 it. 480 ACP network: The ACP network constitutes all the nodes that have 481 access to the ACP. It is the set of active and transitively 482 connected nodes of an ACP domain plus all nodes that get access to 483 the ACP of that domain via ACP edge nodes. 485 ACP (ULA) prefix(es): The /48 IPv6 address prefixes used across the 486 ACP. In the normal/simple case, the ACP has one ULA prefix, see 487 Section 6.10. The ACP routing table may include multiple ULA 488 prefixes if the "rsub" option is used to create addresses from 489 more than one ULA prefix. See Section 6.1.1. The ACP may also 490 include non-ULA prefixes if those are configured on ACP connect 491 interfaces. See Section 8.1.1. 493 ACP secure channel: A cryptographically authenticated and encrypted 494 data connection established between (normally) adjacent ACP nodes 495 to carry traffic of the ACP VRF secure and isolated from Data- 496 Plane traffic in-band over the same link/path as the Data-Plane. 498 ACP secure channel protocol: The protocol used to build an ACP 499 secure channel, e.g., Internet Key Exchange Protocol version 2 500 (IKEv2) with IPsec or Datagram Transport Layer Security (DTLS). 502 ACP virtual interface: An interface in the ACP VRF mapped to one or 503 more ACP secure channels. See Section 6.12.5. 505 AN "Autonomic Network": A network according to 506 [I-D.ietf-anima-reference-model]. Its main components are ANI, 507 Autonomic Functions and Intent. 509 (AN) Domain Name: An FQDN (Fully Qualified Domain Name) in the 510 domain information field of the Domain Certificate. See 511 Section 6.1.1. 513 ANI (nodes/network): "Autonomic Network Infrastructure". The ANI is 514 the infrastructure to enable Autonomic Networks. It includes ACP, 515 BRSKI and GRASP. Every Autonomic Network includes the ANI, but 516 not every ANI network needs to include autonomic functions beyond 517 the ANI (nor Intent). An ANI network without further autonomic 518 functions can for example support secure zero-touch (automated) 519 bootstrap and stable connectivity for SDN networks - see 520 [RFC8368]. 522 ANIMA: "Autonomic Networking Integrated Model and Approach". ACP, 523 BRSKI and GRASP are products of the IETF ANIMA working group. 525 ASA: "Autonomic Service Agent". Autonomic software modules running 526 on an ANI device. The components making up the ANI (BRSKI, ACP, 527 GRASP) are also described as ASAs. 529 Autonomic Function: A function/service in an Autonomic Network (AN) 530 composed of one or more ASA across one or more ANI nodes. 532 BRSKI: "Bootstrapping Remote Secure Key Infrastructures" 533 ([I-D.ietf-anima-bootstrapping-keyinfra]. A protocol extending 534 EST to enable secure zero-touch bootstrap in conjunction with ACP. 535 ANI nodes use ACP, BRSKI and GRASP. 537 Data-Plane: The counterpoint to the ACP VRF in an ACP node: all 538 routing and forwarding in the node other than the ACP VRF. In a 539 simple ACP or ANI node, the Data-Plane is typically provisioned by 540 means other than autonomically, for example manually (including 541 across the ACP) or via SDN controllers. In a fully Autonomic 542 Network node, the Data-Plane is managed autonomically via 543 Autonomic Functions and Intent. Note that other (non-ANIMA) RFC 544 use the Data-Plane to refer to what is better called the 545 forwarding plane. This is not the way the term is used in this 546 document! 548 device: A physical system, or physical node. 550 Enrollment: The process where a node presents identification (for 551 example through keying material such as the private key of an 552 IDevID) to a network and acquires a network specific identity and 553 trust anchor such as an LDevID. 555 EST: "Enrollment over Secure Transport" ([RFC7030]). IETF standard 556 protocol for enrollment of a node with an LDevID. BRSKI is based 557 on EST. 559 GRASP: "Generic Autonomic Signaling Protocol". An extensible 560 signaling protocol required by the ACP for ACP neighbor discovery. 561 The ACP also provides the "security and transport substrate" for 562 the "ACP instance of GRASP". This instance of GRASP runs across 563 the ACP secure channels to support BRSKI and other NOC/OAM or 564 Autonomic Functions. See [I-D.ietf-anima-grasp]. 566 IDevID: An "Initial Device IDentity" X.509 certificate installed by 567 the vendor on new equipment. Contains information that 568 establishes the identity of the node in the context of its vendor/ 569 manufacturer such as device model/type and serial number. See 570 [AR8021]. IDevID can not be used for the ACP because they are not 571 provisioned by the owner of the network, so they can not directly 572 indicate an ACP domain they belong to. 574 in-band (management): The type of management used predominantly in 575 IP based networks, not leveraging an ->"out-of-band network" (). 576 In in-band management, access to the managed equipment depends on 577 the configuration of this equipment itself: interface, addressing, 578 forwarding, routing, policy, security, management. This 579 dependency makes in-band management fragile because the 580 configuration actions performed may break in-band management 581 connectivity. Breakage can not only be unintentional, it can 582 simply be an unavoidable side effect of being unable to create 583 configuration schemes where in-band management connectivity 584 configuration is unaffected by Data-Plane configuration. See also 585 ->"(virtual) out-of-band network" (). 587 Intent: Policy language of an autonomic network according to 588 [I-D.ietf-anima-reference-model]. 590 Loopback interface: The conventional name for an internal IP 591 interface to which addresses may be assigned, but which transmits 592 no external traffic. 594 LDevID: A "Local Device IDentity" is an X.509 certificate installed 595 during "enrollment". The Domain Certificate used by the ACP is an 596 LDevID. See [AR8021]. 598 MIC: "Manufacturer Installed Certificate". Another word not used in 599 this document to describe an IDevID. 601 native interface: Interfaces existing on a node without 602 configuration of the already running node. On physical nodes 603 these are usually physical interfaces. On virtual nodes their 604 equivalent. 606 node: A system, e.g., supporting the ACP according to this document. 607 Can be virtual or physical. Physical nodes are called devices. 609 Node-ID: The identifier of an ACP node inside that ACP. It is the 610 last 64 (see Section 6.10.3) or 78 bits (see Section 6.10.5) of 611 the ACP address. 613 Operational Technology (OT): "https://en.wikipedia.org/wiki/ 614 Operational_Technology" [1]: "The hardware and software dedicated 615 to detecting or causing changes in physical processes through 616 direct monitoring and/or control of physical devices such as 617 valves, pumps, etc". OT networks are today in most cases well 618 separated from Information Technology (IT) networks. 620 (virtual) out-of-band network: An out-of-band network is a secondary 621 network used to manage a primary network. The equipment of the 622 primary network is connected to the out-of-band network via 623 dedicated management ports on the primary network equipment. 624 Serial (console) management ports were historically most common, 625 higher end network equipment now also has ethernet ports dedicated 626 only for management. An out-of-band network provides management 627 access to the primary network independent of the configuration 628 state of the primary network. One of the goals of the ACP is to 629 provide this benefit of out-of-band networks virtually on the 630 primary network equipment. The ACP VRF acts as a virtual out of 631 band network device providing configuration independent management 632 access. The ACP secure channels are the virtual links of the ACP 633 virtual out-of-band network, meant to be operating independent of 634 the configuration of the primary network. See also ->"in-band 635 (management)" (). 637 RPL: "IPv6 Routing Protocol for Low-Power and Lossy Networks". The 638 routing protocol used in the ACP. See [RFC6550]. 640 MASA (service): "Manufacturer Authorized Signing Authority". A 641 vendor/manufacturer or delegated cloud service on the Internet 642 used as part of the BRSKI protocol. 644 (ACP/ANI/BRSKI) Registrar: An ACP registrar is an entity (software 645 and/or person) that is orchestrating the enrollment of ACP nodes 646 with the ACP domain certificate. ANI nodes use BRSKI, so ANI 647 registrars are also called BRSKI registrars. For non-ANI ACP 648 nodes, the registrar mechanisms are undefined by this document. 649 See Section 6.10.7. Renewal and other maintenance (such as 650 revocation) of ACP domain certificates may be performed by other 651 entities than registrars. EST must be supported for ACP domain 652 certificate renewal (see Section 6.1.3). BRSKI is an extension of 653 EST, so ANI/BRSKI registrars can easily support ACP domain 654 certificate renewal in addition to initial enrollment. 656 sUDI: "secured Unique Device Identifier". Another term not used in 657 this document to refer to an IDevID. 659 UDI: "Unique Device Identifier". In the context of this document 660 unsecured identity information of a node typically consisting of 661 at least device model/type and serial number, often in a vendor 662 specific format. See sUDI and LDevID. 664 ULA: (Global ID prefix) A "Unique Local Address" (ULA) is an IPv6 665 address in the block fc00::/7, defined in [RFC4193]. It is the 666 approximate IPv6 counterpart of the IPv4 private address 667 ([RFC1918]). The ULA Global ID prefix are the first 48 bits of a 668 ULA address. In this document it is abbreviated as "ULA prefix". 670 (ACP) VRF: The ACP is modeled in this document as a "Virtual Routing 671 and Forwarding" instance (VRF). This means that it is based on a 672 "virtual router" consisting of a separate IPv6 forwarding table to 673 which the ACP virtual interfaces are attached and an associated 674 IPv6 routing table separate from the Data-Plane. Unlike the VRFs 675 on MPLS/VPN-PE ([RFC4364]) or LISP XTR ([RFC6830]), the ACP VRF 676 does not have any special "core facing" functionality or routing/ 677 mapping protocols shared across multiple VRFs. In vendor products 678 a VRF such as the ACP-VRF may also be referred to as a so called 679 VRF-lite. 681 (ACP) Zone: An ACP zone is a set of ACP nodes using the same zone 682 field value in their ACP address according to Section 6.10.3. 683 Zones are a mechanism to support structured addressing of ACP 684 addresses within the same /48 bit ULA prefix. 686 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 687 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 688 "OPTIONAL" in this document are to be interpreted as described in BCP 689 14 [RFC2119],[RFC8174] when, and only when, they appear in all 690 capitals, as shown here. 692 3. Use Cases for an Autonomic Control Plane (Informative) 694 3.1. An Infrastructure for Autonomic Functions 696 Autonomic Functions need a stable infrastructure to run on, and all 697 autonomic functions should use the same infrastructure to minimize 698 the complexity of the network. In this way, there is only need for a 699 single discovery mechanism, a single security mechanism, and single 700 instances of other processes that distributed functions require. 702 3.2. Secure Bootstrap over a not configured Network 704 Today, bootstrapping a new node typically requires all nodes between 705 a controlling node such as an SDN controller ("Software Defined 706 Networking", see [RFC7426]) and the new node to be completely and 707 correctly addressed, configured and secured. Bootstrapping and 708 configuration of a network happens in rings around the controller - 709 configuring each ring of devices before the next one can be 710 bootstrapped. Without console access (for example through an out-of- 711 band network) it is not possible today to make devices securely 712 reachable before having configured the entire network leading up to 713 them. 715 With the ACP, secure bootstrap of new devices and whole new networks 716 can happen without requiring any configuration of unconfigured 717 devices along the path: As long as all devices along the path support 718 ACP and a zero-touch bootstrap mechanism such as BRSKI, the ACP 719 across a whole network of unconfigured devices can be brought up 720 without operator/provisioning intervention. The ACP also provides 721 additional security for any bootstrap mechanism, because it encrypts 722 the traffic along the path hop-by-hop. 724 3.3. Data-Plane Independent Permanent Reachability 726 Today, most critical control plane protocols and network management 727 protocols are using the Data-Plane of the network. This leads to 728 often undesirable dependencies between control and management plane 729 on one side and the Data-Plane on the other: Only if the forwarding 730 and control plane of the Data-Plane are configured correctly, will 731 the Data-Plane and the management plane work as expected. 733 Data-Plane connectivity can be affected by errors and faults, for 734 example misconfigurations that make AAA (Authentication, 735 Authorization and Accounting) servers unreachable or can lock an 736 administrator out of a device; routing or addressing issues can make 737 a device unreachable; shutting down interfaces over which a current 738 management session is running can lock an admin irreversibly out of 739 the device. Traditionally only out-of-band access can help recover 740 from such issues (such as serial console or ethernet management 741 port). 743 Data-Plane dependencies also affect applications in a Network 744 Operations Center (NOC) such as SDN controller applications: Certain 745 network changes are today hard to implement, because the change 746 itself may affect reachability of the devices. Examples are address 747 or mask changes, routing changes, or security policies. Today such 748 changes require precise hop-by-hop planning. 750 Note that specific control plane functions for the Data-Plane often 751 want to depend on forwarding of their packets via the Data-Plane: 752 Aliveness and routing protocol signaling packets across the Data- 753 Plane to verify reachability across the Data-Plane, using IPv4 754 signaling packets for IPv4 routing vs. IPv6 signaling packets for 755 IPv6 routing. 757 Assuming appropriate implementation (see Section 6.12.2 for more 758 details), the ACP provides reachability that is independent of the 759 Data-Plane. This allows the control plane and management plane to 760 operate more robustly: 762 o For management plane protocols, the ACP provides the functionality 763 of a Virtual out-of-band (VooB) channel, by providing connectivity 764 to all nodes regardless of their Data-Plane configuration, routing 765 and forwarding tables. 767 o For control plane protocols, the ACP allows their operation even 768 when the Data-Plane is temporarily faulty, or during transitional 769 events, such as routing changes, which may affect the control 770 plane at least temporarily. This is specifically important for 771 autonomic service agents, which could affect Data-Plane 772 connectivity. 774 The document "Using Autonomic Control Plane for Stable Connectivity 775 of Network OAM" [RFC8368] explains this use case for the ACP in 776 significantly more detail and explains how the ACP can be used in 777 practical network operations. 779 4. Requirements (Informative) 781 The following requirements where identified as the basis for the 782 design of the ACP based on the above use-cases (Section 3). These 783 requirements are informative for this specification because they 784 (merely) represent the use-case requirements. The keywords are 785 therefore highlighted to be different from RFC2119. The ACP as 786 specified in the normative parts of this document is meeting or 787 exceeding these use-case requirements: 789 ACP1: The ACP _SHOULD_ provide robust connectivity: As far as 790 possible, it should be independent of configured addressing, 791 configuration and routing. Requirements 2 and 3 build on this 792 requirement, but also have value on their own. 794 ACP2: The ACP _MUST_ have a separate address space from the Data- 795 Plane. Reason: traceability, debug-ability, separation from 796 Data-Plane, infrastructure security (filtering based on known 797 address space). 799 ACP3: The ACP _MUST_ use autonomically managed address space. 800 Reason: easy bootstrap and setup ("autonomic"); robustness 801 (admin can't mess things up so easily). This document 802 suggests using ULA addressing for this purpose ("Unique Local 803 Address", see [RFC4193]). 805 ACP4: The ACP _MUST_ be generic, that is it MUST be usable by all 806 the functions and protocols of the ANI. Clients of the ACP 807 MUST NOT be tied to a particular application or transport 808 protocol. 810 ACP5: The ACP _MUST_ provide security: Messages coming through the 811 ACP MUST be authenticated to be from a trusted node, and 812 SHOULD (very strong SHOULD) be encrypted. 814 Explanation for ACP4: In a fully autonomic network (AN), newly 815 written ASA could potentially all communicate exclusively via GRASP 816 with each other, and if that was assumed to be the only requirement 817 against the ACP, it would not need to provide IPv6 layer connectivity 818 between nodes, but only GRASP connectivity. Nevertheless, because 819 ACP also intends to support non-AN networks, it it is crucial to 820 support IPv6 layer connectivity across the ACP to support any 821 transport and application layer protocols. 823 The ACP operates hop-by-hop, because this interaction can be built on 824 IPv6 link local addressing, which is autonomic, and has no dependency 825 on configuration (requirement 1). It may be necessary to have ACP 826 connectivity across non-ACP nodes, for example to link ACP nodes over 827 the general Internet. This is possible, but introduces a dependency 828 against stable/resilient routing over the non-ACP hops (see 829 Section 8.2). 831 5. Overview (Informative) 833 The Autonomic Control Plane is constructed in the following way (for 834 details, see Section 6): 836 1. An ACP node creates a Virtual Routing and Forwarding (VRF) 837 instance, or a similar virtual context. 839 2. It determines, following a policy, a candidate peer list. This 840 is the list of nodes to which it should establish an Autonomic 841 Control Plane. Default policy is: To all link-layer adjacent 842 nodes supporting ACP. 844 3. For each node in the candidate peer list, it authenticates that 845 node and negotiates a mutually acceptable channel type. 847 4. For each node in the candidate peer list, it then establishes a 848 secure tunnel of the negotiated type. The resulting tunnels are 849 then placed into the previously set up VRF. This creates an 850 overlay network with hop-by-hop tunnels. 852 5. Inside the ACP VRF, each node assigns its ULA IPv6 address to a 853 Loopback interface assigned to the ACP VRF. 855 6. Each node runs a lightweight routing protocol, to announce 856 reachability of the virtual addresses inside the ACP (see 857 Section 6.12.5). 859 Note: 861 o Non-autonomic NMS ("Network Management Systems") or SDN 862 controllers have to be explicitly configured for connection into 863 the ACP. 865 o Connecting over non-ACP Layer-3 clouds requires explicit 866 configuration. See Section 8.2. 868 o None of the above operations (except explicit configured ones) are 869 reflected in the configuration of the node. 871 The following figure illustrates the ACP. 873 ACP node 1 ACP node 2 874 ................... ................... 875 secure . . secure . . secure 876 channel: +-----------+ : channel : +-----------+ : channel 877 ..--------| ACP VRF |---------------------| ACP VRF |---------.. 878 : / \ / \ <--routing--> / \ / \ : 879 : \ / \ / \ / \ / : 880 ..--------| Loopback |---------------------| Loopback |---------.. 881 : | interface | : : | interface | : 882 : +-----------+ : : +-----------+ : 883 : : : : 884 : Data-Plane :...............: Data-Plane : 885 : : link : : 886 :.................: :.................: 888 Figure 1: ACP VRF and secure channels 890 The resulting overlay network is normally based exclusively on hop- 891 by-hop tunnels. This is because addressing used on links is IPv6 892 link local addressing, which does not require any prior set-up. In 893 this way the ACP can be built even if there is no configuration on 894 the node, or if the Data-Plane has issues such as addressing or 895 routing problems. 897 6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 899 This section describes the components and steps to set up an 900 Autonomic Control Plane (ACP), and highlights the key properties 901 which make it "indestructible" against many inadvertent changes to 902 the Data-Plane, for example caused by misconfigurations. 904 An ACP node can be a router, switch, controller, NMS host, or any 905 other IP capable node. Initially, it must have its ACP domain 906 certificate, as well as an (empty) ACP Adjacency Table (described in 907 Section 6.2). It then can start to discover ACP neighbors and build 908 the ACP. This is described step by step in the following sections: 910 6.1. ACP Domain, Certificate and Network 912 The ACP relies on group security. An ACP domain is a group of nodes 913 that trust each other to participate in ACP operations. To establish 914 trust, each ACP member requires keying material: An ACP node MUST 915 have a certificate (LDevID) and a Trust Anchor (TA) consisting of a 916 certificate (chain) used to sign the LDevID of all ACP domain 917 members. The LDevID is used to cryptographically authenticate the 918 membership of its owner node in the ACP domain to other ACP domain 919 members, the TA is used to authenticate the ACP domain membership of 920 other nodes (see Section 6.1.2). 922 The LDevID is called the ACP domain certificate, the TA is the 923 Certificate Authority (CA) of the ACP domain. 925 The ACP does not mandate specific mechanisms by which this keying 926 material is provisioned into the ACP node, it only requires the 927 Domain information field as specified in Section 6.1.1 in its domain 928 certificate as well as those of candidate ACP peers. See 929 Appendix A.2 for more information about enrollment or provisioning 930 options. 932 This document uses the term ACP in many places where the Autonomic 933 Networking reference documents [RFC7575] and 934 [I-D.ietf-anima-reference-model] use the word autonomic. This is 935 done because those reference documents consider (only) fully 936 autonomic networks and nodes, but support of ACP does not require 937 support for other components of autonomic networks. Therefore the 938 word autonomic might be misleading to operators interested in only 939 the ACP. 941 [RFC7575] defines the term "Autonomic Domain" as a collection of 942 autonomic nodes. ACP nodes do not need to be fully autonomic, but 943 when they are, then the ACP domain is an autonomic domain. Likewise, 944 [I-D.ietf-anima-reference-model] defines the term "Domain 945 Certificate" as the certificate used in an autonomic domain. The ACP 946 domain certificate is that domain certificate when ACP nodes are 947 (fully) autonomic nodes. Finally, this document uses the term ACP 948 network to refer to the network created by active ACP nodes in an ACP 949 domain. The ACP network itself can extend beyond ACP nodes through 950 the mechanisms described in Section 8.1. 952 The ACP domain certificate SHOULD be used for any authentication 953 between nodes with ACP domain certificates (ACP nodes and NOC nodes) 954 where the required condition is ACP domain membership, such as ACP 955 node to NOC/OAM end-to-en security and ASA to ASA end-to-end 956 security. Section 6.1.2 defines this "ACP domain membership check". 957 The uses of this check that are standardized in this document are for 958 the establishment of ACP secure channels (Section 6.6) and for ACP 959 GRASP (Section 6.8.2). 961 6.1.1. Certificate Domain Information Field 963 Information about the domain MUST be encoded in the domain 964 certificate in a subjectAltName / rfc822Name field according to the 965 following ABNF definition ([RFC5234]): 967 [RFC Editor: Please substitute SELF in all occurences of rfcSELF in 968 this document with the RFC number assigned to this document and 969 remove this comment line] 971 domain-information = local-part "@" acp-domain-name 972 local-part = key [ "." local-info ] 973 key = "rfcSELF" 974 local-info = [ acp-address ] [ "+" rsub extensions ] 975 acp-address = 32hex-dig | 0 976 hex-dig = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" 977 rsub = [ ] ; as of RFC1034, section 3.5 978 routing-subdomain = [ rsub " ." ] acp-domain-name 979 acp-domain-name = ; ; as of RFC 1034, section 3.5 980 extensions = *( "+" extension ) 981 extension = ; future standard definition. 982 ; Must fit RFC5322 simple dot-atom format. 984 Example: 985 domain-information = rfcSELF+fd89b714f3db00000200000064000000 986 +area51.research@acp.example.com 987 acp-domain-name = acp.example.com 988 routing-subdomain = area51.research.acp.example.com 990 Figure 2: ACP Domain Information Field ABNF 992 Nodes complying with this specification MUST be able to receive their 993 ACP address through the domain certificate, in which case their own 994 ACP domain certificate MUST have the 32hex-dig "acp-address" field. 995 Nodes complying with this specification MUST also be able to 996 authenticate nodes as ACP domain members / ACP secure channel peers 997 when they have an empty or 0-value acp-address field. See 998 Section 6.1.2. 1000 "acp-domain-name" is used to indicate the ACP Domain across which all 1001 ACP nodes trust each other and are willing to build ACP channels to 1002 each other. See Section 6.1.2. Acp-domain-name SHOULD be the FQDN 1003 of a DNS domain owned by the operator assigning the certificate. 1004 This is a simple method to ensure that the domain is globally unique 1005 and collision of ACP addresses would therefore only happen due to ULA 1006 hash collisions. If the operator does not own any FQDN, it should 1007 choose a string (in FQDN format) that it intends to be equally 1008 unique. 1010 "routing-subdomain" is the autonomic subdomain composed of "rsub" and 1011 "acp-domain-name". "rsub" is optional. When not present, "routing- 1012 subdomain" is the same as "acp-domain-name". "routing-subdomain" 1013 determines the /48 ULA prefix for ACP addresses. "rsub" therefore 1014 allows to use multiple /48 ULA prefixes in an ACP domain. See 1015 Appendix A.7 for example use-cases. 1017 The optional "extensions" field is used for future standardized 1018 extensions to this specification. It MUST be ignored if present and 1019 not understood. 1021 Formatting notes: 1023 o "rsub" needs to be in the "local-part": If the format just had 1024 routing-subdomain as the domain part of the domain-information, 1025 rsub and acp-domain-name could not be separated from each other. 1026 It also makes acp-domain-name a valid e-mail target across all 1027 routing-subdomains. 1029 o "acp-address" cannot use standard IPv6 address formats because it 1030 must match the simple dot-atom format of [RFC5322]. The character 1031 ":" is not allowed in that format. 1033 o If "acp-address" is empty, and "rsub" is empty too, the "local- 1034 part" will have the format "rfcSELF + + extension(s)". The two 1035 plus characters are necessary so the node can unambiguously parse 1036 that both "acp-address" and "rsub" are empty. 1038 o The maximum size of "domain-information" is 254 characters and the 1039 maximum size of node-info is 64 characters according to [RFC5280] 1040 that is referring to [RFC2821] (superseded by [RFC5321]). 1042 The subjectAltName / rfc822Name encoding of the ACP domain name and 1043 ACP address is used for the following reasons: 1045 o It should be possible to share the LDevID with other uses beside 1046 the ACP. Therefore, the information element required for the ACP 1047 should be encoded so that it minimizes the possibility of creating 1048 incompatibilities with such other uses. 1050 o The information for the ACP should not cause incompatibilities 1051 with any pre-existing ASN.1 software. This eliminates the 1052 introduction of a novel information element because that could 1053 require extensions to such pre-existing ASN.1 parsers. 1055 o subjectAltName / rfc822Name is a pre-existing element that must be 1056 supported by all existing ASN.1 parsers for LDevID. 1058 o The element required for the ACP should not be misinterpreted by 1059 any other uses of the LDevID. If the element used for the ACP is 1060 interpreted by other uses, the impact should be benign. 1062 o Using an IP address format encoding could result in non-benign 1063 misinterpretation of the domain information field; other uses 1064 unaware of the ACP could try to do something with the ACP address 1065 that would fail to work correctly. For example, the address could 1066 be interpreted to be an address of the node which does not belong 1067 to the ACP VRF. 1069 o At minimum, both the AN domain name and the non-domain name 1070 derived part of the ACP address need to be encoded in one or more 1071 appropriate fields of the certificate, so there are not many 1072 alternatives with pre-existing fields where the only possible 1073 conflicts would likely be beneficial. 1075 o rfc822Name encoding is quite flexible. The ACP information field 1076 encodes the full ACP address AND the domain name with rsub part, 1077 so that it is easier to examine/use the "domain information 1078 field". 1080 o The format of the rfc822Name is chosen so that an operator can set 1081 up a mailbox called rfcSELF@ that would receive emails 1082 sent towards the rfc822Name of any node inside a domain. This is 1083 possible because in many modern mail systems, components behind a 1084 "+" character are considered part of a single mailbox. In other 1085 words, it is not necessary to set up a separate mailbox for every 1086 ACP node, but only one for the whole domain. 1088 o In result, if any unexpected use of the ACP addressing information 1089 in a certificate happens, it is benign and detectable: it would be 1090 mail to that mailbox. 1092 See section 4.2.1.6 of [RFC5280] for details on the subjectAltName 1093 field. 1095 6.1.2. ACP domain membership check 1097 The following points constitute the ACP domain membership check of a 1098 candidate peer certificate, independent of the protocol used: 1100 1: The peer certificate is valid (lifetime). 1102 2: The peer has proved ownership of the private key associated with 1103 the certifictes public key. 1105 3: The peer's certificate is signed by one of the trust anchors 1106 associated with the ACP domain certificate. 1108 4: If the node certificate indicates a Certificate Revocation List 1109 (CRL) Distribution Point (CDP) ([RFC5280], section 4.2.1.13) or 1110 Online Certificate Status Protocol (OCSP) responder ([RFC5280], 1111 section 4.2.2.1), then the peer's certificate must be valid 1112 according to those criteria: An OCSP check for the peer's 1113 certificate across the ACP must succeed or the peer certificate 1114 must not be listed in the CRL retrieved from the CDP. 1116 5: The peer's certificate has a syntactically valid ACP domain 1117 information field (encoded as subjectAltName / rfc822Name) and the 1118 acp-domain-name in that peer's domain information field is the 1119 same as in this ACP node's certificate. 1121 Only when checking a candidate peer's certificate for the purpose of 1122 establishing an ACP secure channel, one additional check is 1123 performed: 1125 6: The candidate peer certificate's ACP domain information field 1126 has a non-empty acp-address field (either 32hex-dig or 0, 1127 according to Figure 2). 1129 Rule 6: for the establishment of ACP secure channels ensures that 1130 they will only be built between nodes which indicate through the acp- 1131 address in their ACP domain certificate indicate ability and 1132 permission by the Registrar to participate in ACP secure-channels. 1133 Nodes without an empty acp-adress field can only use it for non-ACP- 1134 secure channel authentication purposes. The special value 0 in an 1135 ACP certificates acp-address field is used for nodes that can and 1136 should determine their ACP address through other mechanisms than 1137 learning it through their ACP domain certificate, but which are still 1138 permitted to establish ACP secure channels. Mechanisms for those 1139 nodes to determine their ACP address are outside the scope of this 1140 specification. 1142 6.1.3. Certificate Maintenance 1144 ACP nodes MUST support certificate renewal via EST ("Enrollment over 1145 Secure Transport", see [RFC7030]) and MAY support other mechanisms. 1146 An ACP network MUST have at least one ACP node supporting EST server 1147 functionality across the ACP so that EST renewal is useable. 1149 ACP nodes SHOULD be able to remember the EST server from which they 1150 last renewed their ACP domain certificate and SHOULD provide the 1151 ability for this remembered EST server to also be set by the ACP 1152 Registrar (see Section 6.10.7) that initially enrolled the ACP device 1153 with its ACP domain certificate. When BRSKI (see 1154 [I-D.ietf-anima-bootstrapping-keyinfra]) is used, the ACP address of 1155 the BRSKI registrar from the BRSKI TLS connection SHOULD be 1156 remembered and used for the next renewal via EST if that registrar 1157 also announces itself as an EST server via GRASP (see next section) 1158 on its ACP address. 1160 6.1.3.1. GRASP objective for EST server 1162 ACP nodes that are EST servers MUST announce their service via GRASP 1163 in the ACP through M_FLOOD messages. See [I-D.ietf-anima-grasp], 1164 section 2.8.11 for the definition of this message type: 1166 Example: 1168 [M_FLOOD, 12340815, h'fd89b714f3db0000200000064000001', 210000, 1169 ["SRV.est", 4, 255 ], 1170 [O_IPv6_LOCATOR, 1171 h'fd89b714f3db0000200000064000001', TCP, 80] 1172 ] 1174 Figure 3: GRASP SRV.est example 1176 The formal definition of the objective in Concise data definition 1177 language (CDDL) (see [I-D.ietf-cbor-cddl]) is as follows: 1179 flood-message = [M_FLOOD, session-id, initiator, ttl, 1180 +[objective, (locator-option / [])]] 1182 objective = ["SRV.est", objective-flags, loop-count, 1183 objective-value] 1185 objective-flags = sync-only ; as in GRASP spec 1186 sync-only = 4 ; M_FLOOD only requires synchronization 1187 loop-count = 255 ; recommended 1188 objective-value = any ; Not used (yet) 1190 Figure 4: GRASP SRV.est definition 1192 The objective value "SRV.est" indicates that the objective is an 1193 [RFC7030] compliant EST server because "est" is an [RFC6335] 1194 registered service name for [RFC7030]. Objective-value MUST be 1195 ignored if present. Backward compatible extensions to [RFC7030] MAY 1196 be indicated through objective-value. Non [RFC7030] compatible 1197 certificate renewal options MUST use a different objective-name. 1199 The M_FLOOD message MUST be sent periodically. The default SHOULD be 1200 60 seconds, the value SHOULD be operator configurable but SHOULD be 1201 not smaller than 60 seconds. The frequency of sending MUST be such 1202 that the aggregate amount of periodic M_FLOODs from all flooding 1203 sources causes only negligible traffic across the ACP. The time-to- 1204 live (ttl) parameter SHOULD be 3.5 times the period so that up to 1205 three consecutive messages can be dropped before considering an 1206 announcement expired. In the example above, the ttl is 210000 msec, 1207 3.5 times 60 seconds. When a service announcer using these 1208 parameters unexpectedly dies immediately after sending the M_FLOOD, 1209 receivers would consider it expired 210 seconds later. When a 1210 receiver tries to connect to this dead service before this timeout, 1211 it will experience a failing connection and use that as an indication 1212 that the service is dead and select another instance of the same 1213 service instead. 1215 6.1.3.2. Renewal 1217 When performing renewal, the node SHOULD attempt to connect to the 1218 remembered EST server. If that fails, it SHOULD attempt to connect 1219 to an EST server learned via GRASP. The server with which 1220 certificate renewal succeeds SHOULD be remembered for the next 1221 renewal. 1223 Remembering the last renewal server and preferring it provides 1224 stickiness which can help diagnostics. It also provides some 1225 protection against off-path compromised ACP members announcing bogus 1226 information into GRASP. 1228 Renewal of certificates SHOULD start after less than 50% of the 1229 domain certificate lifetime so that network operations has ample time 1230 to investigate and resolve any problems that causes a node to not 1231 renew its domain certificate in time - and to allow prolonged periods 1232 of running parts of a network disconnected from any CA. 1234 6.1.3.3. Certificate Revocation Lists (CRLs) 1236 The ACP node SHOULD support Certificate Revocation Lists (CRL) via 1237 HTTPs from one or more CRL Distribution Points (CDPs). The CDP(s) 1238 MUST be indicated in the Domain Certificate when used. If the CDP 1239 URL uses an IPv6 address (ULA address when using the addressing rules 1240 specified in this document), the ACP node will connect to the CDP via 1241 the ACP. If the CDP URL uses an IPv6 address (ULA address when using 1242 the addressing rules specified in this document), the ACP node will 1243 connect to the CDP via the ACP. If the CDP uses a domain name, the 1244 ACP node will connect to the CDP via the Data-Plane. 1246 It is common to use domain names for CDP(s), but there is no 1247 requirement for the ACP to support DNS. Any DNS lookup in the Data- 1248 Plane is not only a possible security issue, but it would also not 1249 indicate whether the resolved address is meant to be reachable across 1250 the ACP. Therefore, the use of an IPv6 address versus the use of a 1251 DNS name doubles as an indicator whether or not to reach the CDP via 1252 the ACP. 1254 A CDP can be reachable across the ACP either by running it on a node 1255 with ACP or by connecting its node via an ACP connect interface (see 1256 Section 8.1). The CDP SHOULD use an ACP domain certificate for its 1257 HTTPs connections. The connecting ACP node SHOULD verify that the 1258 CDP certificate used during the HTTPs connection has the same ACP 1259 address as indicated in the CDP URL of the nodes ACP domain 1260 certificate 1262 6.1.3.4. Lifetimes 1264 Certificate lifetime may be set to shorter lifetimes than customary 1265 (1 year) because certificate renewal is fully automated via ACP and 1266 EST. The primary limiting factor for shorter certificate lifetimes 1267 is load on the EST server(s) and CA. It is therefore recommended 1268 that ACP domain certificates are managed via a CA chain where the 1269 assigning CA has enough performance to manage short lived 1270 certificates. See also Section 10.2.4 for discussion about an 1271 example setup achieving this. 1273 When certificate lifetimes are sufficiently short, such as few hours, 1274 certificate revocation may not be necessary, allowing to simplify the 1275 overall certificate maintenance infrastructure. 1277 See Appendix A.2 for further optimizations of certificate maintenance 1278 when BRSKI can be used ("Bootstrapping Remote Secure Key 1279 Infrastructures", see [I-D.ietf-anima-bootstrapping-keyinfra]). 1281 6.1.3.5. Re-enrollment 1283 An ACP node may determine that its ACP domain certificate has 1284 expired, for example because the ACP node was powered down or 1285 disconnected longer than its certificate lifetime. In this case, the 1286 ACP node SHOULD convert to a role of a re-enrolling candidate ACP 1287 node. 1289 In this role, the node does maintain the trust anchor and certificate 1290 chain associated with its ACP domain certificate exclusively for the 1291 purpose of re-enrollment, and attempts (or waits) to get re-enrolled 1292 with a new ACP certificate. The details depend on the mechanisms/ 1293 protocols used by the ACP registrars. 1295 Please refer to Section 6.10.7 for explanations about ACP registrars 1296 and vouchers as used in the following text. 1298 When BRSKI is used (aka: on ACP nodes that are ANI nodes), the re- 1299 enrolling candidate ACP node would attempt to enroll like a candidate 1300 ACP node (BRSKI pledge), but instead of using the ACP nodes IDevID, 1301 it SHOULD first attempt to use its ACP domain certificate in the 1302 BRSKI TLS authentication. The BRSKI registrar MAY honor this 1303 certificate beyond its expiration date purely for the purpose of re- 1304 enrollment. Using the ACP node's domain certificate allows the BRSKI 1305 registrar to learn that nodes ACP domain information field, so that 1306 the BRSKI registrar can re-assign the same ACP address information to 1307 the ACP node in the new ACP domain certificate. 1309 If the BRSKI registrar denies the use of the old ACP domain 1310 certificate, the re-enrolling candidate ACP node MUST re-attempt re- 1311 enrollment using its IDevID as defined in BRSKI during the TLS 1312 connection setup. 1314 Both when the BRSKI connection is attempted with the old ACP domain 1315 certificate or the IDevID, the re-enrolling candidate ACP node SHOULD 1316 authenticate the BRSKI registrar during TLS connection setup based on 1317 its existing trust anchor/certificate chain information associated 1318 with its old ACP certificate. The re-enrolling candidate ACP node 1319 SHOULD only request a voucher from the BRSKI registrar when this 1320 authentication fails during TLS connection setup. 1322 When other mechanisms than BRSKI are used for ACP domain certificate 1323 enrollment, the principles of the re-enrolling candidate ACP node are 1324 the same. The re-enrolling candidate ACP node attempts to 1325 authenticate any ACP registrar peers during re-enrollment protocol/ 1326 mechanisms via its existing certificate chain/trust anchor and 1327 provides its existing ACP domain certificate and other identification 1328 (such as the IDevID) as necessary to the registrar. 1330 Maintaining existing trust anchor information is especially important 1331 when enrollment mechanisms are used that unlike BRSKI do not leverage 1332 a voucher mechanism to authenticate the ACP registrar and where 1333 therefore the injection of certificate failures could otherwise make 1334 the ACP node easily attackable remotely. 1336 When using BRSKI or other protocol/mechanisms supporting vouchers, 1337 maintaining existing trust anchor information allows for re- 1338 enrollment of expired ACP certificates to be more lightweight, 1339 especially in environments where repeated acquisition of vouchers 1340 during the lifetime of ACP nodes may be operationally expensive or 1341 otherwise undesirable. 1343 6.1.3.6. Failing Certificates 1345 An ACP domain certificate is called failing in this document, if/when 1346 the ACP node can determine that it was revoked (or explicitly not 1347 renewed), or in the absence of such explicit local diagnostics, when 1348 the ACP node fails to connect to other ACP nodes in the same ACP 1349 domain using its ACP certificate. For connection failures to 1350 determine the ACP domain certificate as the culprit, the peer should 1351 pass the domain membership check (Section 6.1.2) and other reasons 1352 for the connection failure can be excluded because of the connection 1353 error diagnostics. 1355 This type of failure can happen during setup/refresh of a secure ACP 1356 channel connections or any other use of the ACP domain certificate, 1357 such as for the TLS connection to an EST server for the renewal of 1358 the ACP domain certificate. 1360 Example reasons for failing certificates that the ACP node can only 1361 discover through connection failure are that the domain certificate 1362 or any of its signing certificates could have been revoked or may 1363 have expired, but the ACP node can not self-diagnose this condition 1364 directly. Revocation information or clock synchronization may only 1365 be available across the ACP, but the ACP node can not build ACP 1366 secure channels because ACP peers reject the ACP node's domain 1367 certificate. 1369 ACP nodes SHOULD support the option to determines whether its ACP 1370 certificate is failing, and when it does, put itself into the role of 1371 a re-enrolling candidate ACP node as explained above 1372 (Section 6.1.3.5). 1374 6.2. ACP Adjacency Table 1376 To know to which nodes to establish an ACP channel, every ACP node 1377 maintains an adjacency table. The adjacency table contains 1378 information about adjacent ACP nodes, at a minimum: Node-ID 1379 (identifier of the node inside the ACP, see Section 6.10.3 and 1380 Section 6.10.5), interface on which neighbor was discovered (by GRASP 1381 as explained below), link-local IPv6 address of neighbor on that 1382 interface, certificate (including domain information field). An ACP 1383 node MUST maintain this adjacency table up to date. This table is 1384 used to determine to which neighbor an ACP connection is established. 1386 Where the next ACP node is not directly adjacent (i.e., not on a link 1387 connected to this node), the information in the adjacency table can 1388 be supplemented by configuration. For example, the Node-ID and IP 1389 address could be configured. 1391 The adjacency table MAY contain information about the validity and 1392 trust of the adjacent ACP node's certificate. However, subsequent 1393 steps MUST always start with authenticating the peer. 1395 The adjacency table contains information about adjacent ACP nodes in 1396 general, independently of their domain and trust status. The next 1397 step determines to which of those ACP nodes an ACP connection should 1398 be established. 1400 6.3. Neighbor Discovery with DULL GRASP 1402 [RFC Editor: GRASP draft is in RFC editor queue, waiting for 1403 dependencies, including ACP. Please ensure that references to I- 1404 D.ietf-anima-grasp that include section number references (throughout 1405 this document) will be updated in case any last-minute changes in 1406 GRASP would make those section references change. 1408 DULL GRASP is a limited subset of GRASP intended to operate across an 1409 insecure link-local scope. See section 2.5.2 of 1410 [I-D.ietf-anima-grasp] for its formal definition. The ACP uses one 1411 instance of DULL GRASP for every L2 interface of the ACP node to 1412 discover link level adjacent candidate ACP neighbors. Unless 1413 modified by policy as noted earlier (Section 5 bullet point 2.), 1414 native interfaces (e.g., physical interfaces on physical nodes) 1415 SHOULD be initialized automatically to a state in which ACP discovery 1416 can be performed and any native interfaces with ACP neighbors can 1417 then be brought into the ACP even if the interface is otherwise not 1418 configured. Reception of packets on such otherwise not configured 1419 interfaces MUST be limited so that at first only IPv6 StateLess 1420 Address Auto Configuration (SLAAC - [RFC4862]) and DULL GRASP work 1421 and then only the following ACP secure channel setup packets - but 1422 not any other unnecessary traffic (e.g., no other link-local IPv6 1423 transport stack responders for example). 1425 Note that the use of the IPv6 link-local multicast address 1426 (ALL_GRASP_NEIGHBORS) implies the need to use Multicast Listener 1427 Discovery Version 2 (MLDv2, see [RFC3810]) to announce the desire to 1428 receive packets for that address. Otherwise DULL GRASP could fail to 1429 operate correctly in the presence of MLD snooping, non-ACP enabled L2 1430 switches - because those would stop forwarding DULL GRASP packets. 1431 Switches not supporting MLD snooping simply need to operate as pure 1432 L2 bridges for IPv6 multicast packets for DULL GRASP to work. 1434 ACP discovery SHOULD NOT be enabled by default on non-native 1435 interfaces. In particular, ACP discovery MUST NOT run inside the ACP 1436 across ACP virtual interfaces. See Section 10.3 for further, non- 1437 normative suggestions on how to enable/disable ACP at node and 1438 interface level. See Section 8.2.2 for more details about tunnels 1439 (typical non-native interfaces). See Section 7 for how ACP should be 1440 extended on devices operating (also) as L2 bridges. 1442 Note: If an ACP node also implements BRSKI to enroll its ACP domain 1443 certificate (see Appendix A.2 for a summary), then the above 1444 considerations also apply to GRASP discovery for BRSKI. Each DULL 1445 instance of GRASP set up for ACP is then also used for the discovery 1446 of a bootstrap proxy via BRSKI when the node does not have a domain 1447 certificate. Discovery of ACP neighbors happens only when the node 1448 does have the certificate. The node therefore never needs to 1449 discover both a bootstrap proxy and ACP neighbor at the same time. 1451 An ACP node announces itself to potential ACP peers by use of the 1452 "AN_ACP" objective. This is a synchronization objective intended to 1453 be flooded on a single link using the GRASP Flood Synchronization 1454 (M_FLOOD) message. In accordance with the design of the Flood 1455 message, a locator consisting of a specific link-local IP address, IP 1456 protocol number and port number will be distributed with the flooded 1457 objective. An example of the message is informally: 1459 [M_FLOOD, 12340815, h'fe80000000000000c0011001FEEF0000, 210000, 1460 ["AN_ACP", 4, 1, "IKEv2" ], 1461 [O_IPv6_LOCATOR, 1462 h'fe80000000000000c0011001FEEF0000, UDP, 15000] 1463 ["AN_ACP", 4, 1, "DTLS" ], 1464 [O_IPv6_LOCATOR, 1465 h'fe80000000000000c0011001FEEF0000, UDP, 17000] 1466 ] 1468 Figure 5: GRASP AN_ACP example 1470 The formal CDDL definition is: 1472 flood-message = [M_FLOOD, session-id, initiator, ttl, 1473 +[objective, (locator-option / [])]] 1475 objective = ["AN_ACP", objective-flags, loop-count, 1476 objective-value] 1478 objective-flags = sync-only ; as in the GRASP specification 1479 sync-only = 4 ; M_FLOOD only requires synchronization 1480 loop-count = 1 ; limit to link-local operation 1481 objective-value = method 1482 method = "IKEv2" / "DTLS" ; or future standard methods 1484 Figure 6: GRASP AN_ACP definition 1486 The objective-flags field is set to indicate synchronization. 1488 The loop-count is fixed at 1 since this is a link-local operation. 1490 In the above example the RECOMMENDED period of sending of the 1491 objective is 60 seconds. The indicated ttl of 210000 msec means that 1492 the objective would be cached by ACP nodes even when two out of three 1493 messages are dropped in transit. 1495 The session-id is a random number used for loop prevention 1496 (distinguishing a message from a prior instance of the same message). 1497 In DULL this field is irrelevant but must still be set according to 1498 the GRASP specification. 1500 The originator MUST be the IPv6 link local address of the originating 1501 ACP node on the sending interface. 1503 The 'objective-value' parameter is a string indicating the secure 1504 channel protocol available at the specified or implied locator. 1506 The locator-option is optional and only required when the secure 1507 channel protocol is not offered at a well-defined port number, or if 1508 there is no well-defined port number. 1510 "IKEv2" is the abbreviation for "Internet Key Exchange protocol 1511 version 2", as defined in [RFC7296]. It is the main protocol used by 1512 the Internet IP security architecture (IPsec). We therefore use the 1513 term "IKEv2" and not "IPsec" in the GRASP definitions and example 1514 above. "IKEv2" has a well-defined port number 500, but in the above 1515 example, the candidate ACP neighbor is offering ACP secure channel 1516 negotiation via IKEv2 on port 15000 (for the sake of creating a non- 1517 standard example). 1519 "DTLS" indicates datagram Transport Layer Security version 1.2. 1520 There is no default UDP port, it must always be locally assigned by 1521 the node. See Section 6.7.2. 1523 If a locator is included, it MUST be an O_IPv6_LOCATOR, and the IPv6 1524 address MUST be the same as the initiator address (these are DULL 1525 requirements to minimize third party DoS attacks). 1527 The secure channel methods defined in this document use the objective 1528 values of "IKEv2" and "DTLS". There is no distinction between IKEv2 1529 native and GRE-IKEv2 because this is purely negotiated via IKEv2. 1531 A node that supports more than one secure channel protocol method 1532 needs to flood multiple versions of the "AN_ACP" objective so that 1533 each method can be accompanied by its own locator-option. This can 1534 use a single GRASP M_FLOOD message as shown in Figure 5. 1536 Note that a node serving both as an ACP node and BRSKI Join Proxy may 1537 choose to distribute the "AN_ACP" objective and the respective BRSKI 1538 in the same M_FLOOD message, since GRASP allows multiple objectives 1539 in one message. This may be impractical though if ACP and BRSKI 1540 operations are implemented via separate software modules / ASAs. 1542 The result of the discovery is the IPv6 link-local address of the 1543 neighbor as well as its supported secure channel protocols (and non- 1544 standard port they are running on). It is stored in the ACP 1545 Adjacency Table, see Section 6.2 which then drives the further 1546 building of the ACP to that neighbor. 1548 6.4. Candidate ACP Neighbor Selection 1550 An ACP node must determine to which other ACP nodes in the adjacency 1551 table it should build an ACP connection. This is based on the 1552 information in the ACP Adjacency table. 1554 The ACP is established exclusively between nodes in the same domain. 1555 This includes all routing subdomains. Appendix A.7 explains how ACP 1556 connections across multiple routing subdomains are special. 1558 The result of the candidate ACP neighbor selection process is a list 1559 of adjacent or configured autonomic neighbors to which an ACP channel 1560 should be established. The next step begins that channel 1561 establishment. 1563 6.5. Channel Selection 1565 To avoid attacks, initial discovery of candidate ACP peers cannot 1566 include any non-protected negotiation. To avoid re-inventing and 1567 validating security association mechanisms, the next step after 1568 discovering the address of a candidate neighbor can only be to try 1569 first to establish a security association with that neighbor using a 1570 well-known security association method. 1572 At this time in the lifecycle of ACP nodes, it is unclear whether it 1573 is feasible to even decide on a single MTI (mandatory to implement) 1574 security association protocol across all ACP nodes. 1576 From the use-cases it seems clear that not all type of ACP nodes can 1577 or need to connect directly to each other or are able to support or 1578 prefer all possible mechanisms. For example, code space limited IoT 1579 devices may only support DTLS because that code exists already on 1580 them for end-to-end security, but low-end in-ceiling L2 switches may 1581 only want to support Media Access Control Security (MacSec, see 1582 802.1AE ([MACSEC]) because that is also supported in their chips. 1583 Only a flexible gateway device may need to support both of these 1584 mechanisms and potentially more. 1586 To support extensible secure channel protocol selection without a 1587 single common MTI protocol, ACP nodes must try all the ACP secure 1588 channel protocols it supports and that are feasible because the 1589 candidate ACP neighbor also announced them via its AN_ACP GRASP 1590 parameters (these are called the "feasible" ACP secure channel 1591 protocols). 1593 To ensure that the selection of the secure channel protocols always 1594 succeeds in a predictable fashion without blocking, the following 1595 rules apply: 1597 o An ACP node may choose to attempt initiate the different feasible 1598 ACP secure channel protocols it supports according to its local 1599 policies sequentially or in parallel, but it MUST support acting 1600 as a responder to all of them in parallel. 1602 o Once the first secure channel protocol succeeds, the two peers 1603 know each other's certificates because they must be used by all 1604 secure channel protocols for mutual authentication. The node with 1605 the lower Node-ID in the ACP address becomes Bob, the one with the 1606 higher Node-ID in the certificate Alice. 1608 o Bob becomes passive, he does not attempt to further initiate ACP 1609 secure channel protocols with Alice and does not consider it to be 1610 an error when Alice closes secure channels. Alice becomes the 1611 active party, continues to attempt setting up secure channel 1612 protocols with Bob until she arrives at the best one from her view 1613 that also works with Bob. 1615 For example, originally Bob could have been the initiator of one ACP 1616 secure channel protocol that Bob prefers and the security association 1617 succeeded. The roles of Bob and Alice are then assigned. At this 1618 stage, the protocol may not even have completed negotiating a common 1619 security profile. The protocol could for example be IPsec via IKEv2 1620 ("IP security", see [RFC4301] and "Internet Key Exchange protocol 1621 version 2", see [RFC7296]. It is now up to Alice to decide how to 1622 proceed. Even if the IPsec connection from Bob succeeded, Alice 1623 might prefer another secure protocol over IPsec (e.g., FOOBAR), and 1624 try to set that up with Bob. If that preference of Alice succeeds, 1625 she would close the IPsec connection. If no better protocol attempt 1626 succeeds, she would keep the IPsec connection. 1628 All this negotiation is in the context of an "L2 interface". Alice 1629 and Bob will build ACP connections to each other on every "L2 1630 interface" that they both connect to. An autonomic node must not 1631 assume that neighbors with the same L2 or link-local IPv6 addresses 1632 on different L2 interfaces are the same node. This can only be 1633 determined after examining the certificate after a successful 1634 security association attempt. 1636 6.6. Candidate ACP Neighbor verification 1638 Independent of the security association protocol chosen, candidate 1639 ACP neighbors need to be authenticated based on their domain 1640 certificate. This implies that any secure channel protocol MUST 1641 support certificate based authentication that can support the ACP 1642 domain membership check as defined in Section 6.1.2. If it fails, 1643 the connection attempt is aborted and an error logged. Attempts to 1644 reconnect MUST be throttled. The RECOMMENDED default is exponential 1645 backoff with a a minimum delay of 10 seconds and a maximum delay of 1646 640 seconds. 1648 6.7. Security Association protocols 1650 The following sections define the security association protocols that 1651 we consider to be important and feasible to specify in this document: 1653 6.7.1. ACP via IKEv2 1655 An ACP node announces its ability to support IKEv2 as the ACP secure 1656 channel protocol in GRASP as "IKEv2". 1658 6.7.1.1. Native IPsec 1660 To run ACP via IPsec natively, no further IANA assignments/ 1661 definitions are required. An ACP node that is supporting native 1662 IPsec MUST use IPsec security setup via IKEv2, tunnel mode, local and 1663 peer link-local IPv6 addresses used for encapsulation. It MUST then 1664 support ESP with AES256 for encryption and SHA256 hash and MUST NOT 1665 permit weaker crypto options. 1667 In terms of IKEv2, this means the initiator will offer to support 1668 IPsec tunnel mode with next protocol equal 41 (IPv6). 1670 IPsec tunnel mode is required because the ACP will route/forward 1671 packets received from any other ACP node across the ACP secure 1672 channels, and not only its own generated ACP packets. With IPsec 1673 transport mode, it would only be possible to send packets originated 1674 by the ACP node itself. 1676 ESP is used because ACP mandates the use of encryption for ACP secure 1677 channels. 1679 6.7.1.2. IPsec with GRE encapsulation 1681 In network devices it is often more common to implement high 1682 performance virtual interfaces on top of GRE encapsulation than on 1683 top of a "native" IPsec association (without any other encapsulation 1684 than those defined by IPsec). On those devices it may be beneficial 1685 to run the ACP secure channel on top of GRE protected by the IPsec 1686 association. 1688 To run ACP via GRE/IPsec, no further IANA assignments/definitions are 1689 required. An ACP node that is supporting ACP via GRE/IPsec MUST then 1690 support IPsec security setup via IKEv2, IPsec transport mode, local 1691 and peer link-local IPv6 addresses used for encapsulation, ESP with 1692 AES256 encryption and SHA256 hash. 1694 When GRE is used, transport mode is sufficient because the routed ACP 1695 packets are not "tunneled" by IPsec but rather by GRE: IPsec only has 1696 to deal with the GRE/IP packet which always uses the local and peer 1697 link-local IPv6 addresses and is therefore applicable to transport 1698 mode. 1700 ESP is used because ACP mandates the use of encryption for ACP secure 1701 channels. 1703 In terms of IKEv2 negotiation, this means the initiator must offer to 1704 support IPsec transport mode with next protocol equal to GRE (47) 1705 followed by the offer for native IPsec as described above (because 1706 that option is mandatory to support). 1708 If IKEv2 initiator and responder support GRE, it will be selected. 1709 The version of GRE to be used must the according to [RFC7676]. 1711 6.7.2. ACP via DTLS 1713 We define the use of ACP via DTLS in the assumption that it is likely 1714 the first transport encryption code basis supported in some classes 1715 of constrained devices. 1717 To run ACP via UDP and DTLS v1.2 [RFC6347] a locally assigned UDP 1718 port is used that is announced as a parameter in the GRASP AN_ACP 1719 objective to candidate neighbors. All ACP nodes supporting DTLS as a 1720 secure channel protocol MUST support AES256 encryption and MUST NOT 1721 permit weaker crypto options. 1723 There is no additional session setup or other security association 1724 besides this simple DTLS setup. As soon as the DTLS session is 1725 functional, the ACP peers will exchange ACP IPv6 packets as the 1726 payload of the DTLS transport connection. Any DTLS defined security 1727 association mechanisms such as re-keying are used as they would be 1728 for any transport application relying solely on DTLS. 1730 6.7.3. ACP Secure Channel Requirements 1732 As explained in the beginning of Section 6.5, there is no single 1733 secure channel mechanism mandated for all ACP nodes. Instead, this 1734 section defines two ACP profiles (baseline and constrained) for ACP 1735 nodes that do introduce such requirements. 1737 A baseline ACP node MUST support IPsec natively and MAY support IPsec 1738 via GRE. A constrained ACP node that can not support IPsec MUST 1739 support DTLS. An ACP node connecting an area of constrained ACP 1740 nodes with an area of baseline ACP nodes MUST therefore support IPsec 1741 and DTLS and supports threefore the baseline and constrained profile. 1743 ACP nodes need to specify in documentation the set of secure ACP 1744 mechanisms they support and should declare which profile they support 1745 according to above requirements. 1747 An ACP secure channel MUST immediately be terminated when the 1748 lifetime of any certificate in the chain used to authenticate the 1749 neighbor expires or becomes revoked. Note that this is not standard 1750 behavior in secure channel protocols such as IPsec because the 1751 certificate authentication only influences the setup of the secure 1752 channel in these protocols. 1754 6.8. GRASP in the ACP 1756 6.8.1. GRASP as a core service of the ACP 1758 The ACP MUST run an instance of GRASP inside of it. It is a key part 1759 of the ACP services. The function in GRASP that makes it fundamental 1760 as a service of the ACP is the ability to provide ACP wide service 1761 discovery (using objectives in GRASP). 1763 ACP provides IP unicast routing via the RPL routing protocol (see 1764 Section 6.11). 1766 The ACP does not use IP multicast routing nor does it provide generic 1767 IP multicast services (the handling of GRASP link-local multicast 1768 messages is explained in Section 6.8.2). Instead, the ACP provides 1769 service discovery via the objective discovery/announcement and 1770 negotiation mechanisms of the ACP GRASP instance (services are a form 1771 of objectives). These mechanisms use hop-by-hop reliable flooding of 1772 GRASP messages for both service discovery (GRASP M_DISCOVERY 1773 messages) and service announcement (GRASP M_FLOOD messages). 1775 See Appendix A.5 for discussion about this design choice of the ACP. 1777 6.8.2. ACP as the Security and Transport substrate for GRASP 1779 In the terminology of GRASP ([I-D.ietf-anima-grasp]), the ACP is the 1780 security and transport substrate for the GRASP instance run inside 1781 the ACP ("ACP GRASP"). 1783 This means that the ACP is responsible for ensuring that this 1784 instance of GRASP is only sending messages across the ACP GRASP 1785 virtual interfaces. Whenever the ACP adds or deletes such an 1786 interface because of new ACP secure channels or loss thereof, the ACP 1787 needs to indicate this to the ACP instance of GRASP. The ACP exists 1788 also in the absence of any active ACP neighbors. It is created when 1789 the node has a domain certificate, and continues to exist even if all 1790 of its neighbors cease operation. 1792 In this case ASAs using GRASP running on the same node would still 1793 need to be able to discover each other's objectives. When the ACP 1794 does not exist, ASAs leveraging the ACP instance of GRASP via APIs 1795 MUST still be able to operate, and MUST be able to understand that 1796 there is no ACP and that therefore the ACP instance of GRASP can not 1797 operate. 1799 The way ACP acts as the security and transport substrate for GRASP is 1800 visualized in the following picture: 1802 ..............................ACP.............................. 1803 . . 1804 . /-GRASP-flooding-\ ACP GRASP instance . 1805 . / \ A 1806 . GRASP GRASP GRASP C 1807 . link-local unicast link-local P 1808 . multicast messages multicast . 1809 . messages | messages . 1810 . | | | . 1811 ............................................................... 1812 . v v v ACP security and transport . 1813 . | | | substrate for GRASP . 1814 . | | | . 1815 . | ACP GRASP | - ACP GRASP A 1816 . | Loopback | Loopback interface C 1817 . | interface | - ACP-cert auth P 1818 . | TLS | . 1819 . ACP GRASP | ACP GRASP - ACP GRASP virtual . 1820 . subnet1 | subnet2 virtual interfaces . 1821 . TCP | TCP . 1822 . | | | . 1823 ............................................................... 1824 . | | | ^^^ Users of ACP (GRASP/ASA) . 1825 . | | | ACP interfaces/addressing . 1826 . | | | . 1827 . | | | A 1828 . | ACP-Loopback Interf.| <- ACP Loopback interface C 1829 . | ACP-address | - address (global ULA) P 1830 . subnet1 | subnet2 <- ACP virtual interfaces . 1831 . link-local | link-local - link-local addresses . 1832 ............................................................... 1833 . | | | ACP routing and forwarding . 1834 . | RPL-routing | . 1835 . | /IP-Forwarding\ | A 1836 . | / \ | C 1837 . ACP IPv6 packets ACP IPv6 packets P 1838 . |/ \| . 1839 . IPsec/DTLS IPsec/DTLS - ACP-cert auth . 1840 ............................................................... 1841 | | Data-Plane 1842 | | 1843 | | - ACP secure channel 1844 link-local link-local - encapsulation addresses 1845 subnet1 subnet2 - Data-Plane interfaces 1846 | | 1847 ACP-Nbr1 ACP-Nbr2 1849 Figure 7: ACP as security and transport substrate for GRASP 1851 GRASP unicast messages inside the ACP always use the ACP address. 1852 Link-local ACP addresses must not be used inside objectives. GRASP 1853 unicast messages inside the ACP are transported via TLS 1.2 1854 ([RFC5246]) connections with AES256 encryption and SHA256. Mutual 1855 authentication uses the ACP domain membership check defined in 1856 (Section 6.1.2). 1858 GRASP link-local multicast messages are targeted for a specific ACP 1859 virtual interface (as defined Section 6.12.5) but are sent by the ACP 1860 into an ACP GRASP virtual interface that is constructed from the TCP 1861 connection(s) to the IPv6 link-local neighbor address(es) on the 1862 underlying ACP virtual interface. If the ACP GRASP virtual interface 1863 has two or more neighbors, the GRASP link-local multicast messages 1864 are replicated to all neighbor TCP connections. 1866 TLS and TLS connections for GRASP in the ACP use the IANA assigned 1867 TCP port for GRASP (7107). Effectively the transport stack is 1868 expected to be TLS for connections from/to the ACP address (e.g., 1869 global scope address(es)) and TCP for connections from/to link-local 1870 addresses on the ACP virtual interfaces. The latter ones are only 1871 used for flooding of GRASP messages. 1873 6.8.2.1. Discussion 1875 TCP encapsulation for GRASP M_DISCOVERY and M_FLOOD link local 1876 messages is used because these messages are flooded across 1877 potentially many hops to all ACP nodes and a single link with even 1878 temporary packet loss issues (e.g., WiFi/Powerline link) can reduce 1879 the probability for loss free transmission so much that applications 1880 would want to increase the frequency with which they send these 1881 messages. Such shorter periodic retransmission of datagrams would 1882 result in more traffic and processing overhead in the ACP than the 1883 hop-by-hop reliable retransmission mechanism by TCP and duplicate 1884 elimination by GRASP. 1886 TLS is mandated for GRASP non-link-local unicast because the ACP 1887 secure channel mandatory authentication and encryption protects only 1888 against attacks from the outside but not against attacks from the 1889 inside: Compromised ACP members that have (not yet) been detected and 1890 removed (e.g., via domain certificate revocation / expiry). 1892 If GRASP peer connections would just use TCP, compromised ACP members 1893 could simply eavesdrop passively on GRASP peer connections for whom 1894 they are on-path ("Man In The Middle" - MITM). Or intercept and 1895 modify them. With TLS, it is not possible to completely eliminate 1896 problems with compromised ACP members, but attacks are a lot more 1897 complex: 1899 Eavesdropping/spoofing by a compromised ACP node is still possible 1900 because in the model of the ACP and GRASP, the provider and consumer 1901 of an objective have initially no unique information (such as an 1902 identity) about the other side which would allow them to distinguish 1903 a benevolent from a compromised peer. The compromised ACP node would 1904 simply announce the objective as well, potentially filter the 1905 original objective in GRASP when it is a MITM and act as an 1906 application level proxy. This of course requires that the 1907 compromised ACP node understand the semantics of the GRASP 1908 negotiation to an extent that allows it to proxy it without being 1909 detected, but in an ACP environment this is quite likely public 1910 knowledge or even standardized. 1912 The GRASP TLS connections are run the same as any other ACP traffic 1913 through the ACP secure channels. This leads to double 1914 authentication/encryption, which has the following benefits: 1916 o Secure channel methods such as IPsec may provide protecation 1917 against additional attacks from such as reset-attacks. 1919 o The secure channel method may leverage hardware acceleration and 1920 there may be little or no gain in eliminating it. 1922 o There is no different security model for ACP GRASP from other ACP 1923 traffic. Instead, there is just another layer of protection 1924 against certain attacks from the inside which is important due to 1925 the role of GRASP in the ACP. 1927 6.9. Context Separation 1929 The ACP is in a separate context from the normal Data-Plane of the 1930 node. This context includes the ACP channels' IPv6 forwarding and 1931 routing as well as any required higher layer ACP functions. 1933 In classical network system, a dedicated so called Virtual routing 1934 and forwarding instance (VRF) is one logical implementation option 1935 for the ACP. If possible by the systems software architecture, 1936 separation options that minimize shared components are preferred, 1937 such as a logical container or virtual machine instance. The context 1938 for the ACP needs to be established automatically during bootstrap of 1939 a node. As much as possible it should be protected from being 1940 modified unintentionally by ("Data-Plane") configuration. 1942 Context separation improves security, because the ACP is not 1943 reachable from the Data-Plane routing or forwarding table(s). Also, 1944 configuration errors from the Data-Plane setup do not affect the ACP. 1946 6.10. Addressing inside the ACP 1948 The channels explained above typically only establish communication 1949 between two adjacent nodes. In order for communication to happen 1950 across multiple hops, the autonomic control plane requires ACP 1951 network wide valid addresses and routing. Each ACP node must create 1952 a Loopback interface with an ACP network wide unique address inside 1953 the ACP context (as explained in in Section 6.9). This address may 1954 be used also in other virtual contexts. 1956 With the algorithm introduced here, all ACP nodes in the same routing 1957 subdomain have the same /48 ULA prefix. Conversely, ULA global IDs 1958 from different domains are unlikely to clash, such that two ACP 1959 networks can be merged, as long as the policy allows that merge. See 1960 also Section 9.1 for a discussion on merging domains. 1962 Links inside the ACP only use link-local IPv6 addressing, such that 1963 each nodes ACP only requires one routable virtual address. 1965 6.10.1. Fundamental Concepts of Autonomic Addressing 1967 o Usage: Autonomic addresses are exclusively used for self- 1968 management functions inside a trusted domain. They are not used 1969 for user traffic. Communications with entities outside the 1970 trusted domain use another address space, for example normally 1971 managed routable address space (called "Data-Plane" in this 1972 document). 1974 o Separation: Autonomic address space is used separately from user 1975 address space and other address realms. This supports the 1976 robustness requirement. 1978 o Loopback-only: Only ACP Loopback interfaces (and potentially those 1979 configured for "ACP connect", see Section 8.1) carry routable 1980 address(es); all other interfaces (called ACP virtual interfaces) 1981 only use IPv6 link local addresses. The usage of IPv6 link local 1982 addressing is discussed in [RFC7404]. 1984 o Use-ULA: For Loopback interfaces of ACP nodes, we use Unique Local 1985 Addresses (ULA), as defined in [RFC4193] with L=1 (as defined in 1986 section 3.1 of [RFC4193]). Note that the random hash for ACP 1987 Loopback addresses uses the definition in Section 6.10.2 and not 1988 the one of [RFC4193] section 3.2.2. 1990 o No external connectivity: They do not provide access to the 1991 Internet. If a node requires further reaching connectivity, it 1992 should use another, traditionally managed address scheme in 1993 parallel. 1995 o Addresses in the ACP are permanent, and do not support temporary 1996 addresses as defined in [RFC4941]. 1998 o Addresses in the ACP are not considered sensitive on privacy 1999 grounds because ACP nodes are not expected to be end-user devices. 2000 Therefore, ACP addresses do not need to be pseudo-random as 2001 discussed in [RFC7721]. Because they are not propagated to 2002 untrusted (non ACP) nodes and stay within a domain (of trust), we 2003 also consider them not to be subject to scanning attacks. 2005 The ACP is based exclusively on IPv6 addressing, for a variety of 2006 reasons: 2008 o Simplicity, reliability and scale: If other network layer 2009 protocols were supported, each would have to have its own set of 2010 security associations, routing table and process, etc. 2012 o Autonomic functions do not require IPv4: Autonomic functions and 2013 autonomic service agents are new concepts. They can be 2014 exclusively built on IPv6 from day one. There is no need for 2015 backward compatibility. 2017 o OAM protocols do not require IPv4: The ACP may carry OAM 2018 protocols. All relevant protocols (SNMP, TFTP, SSH, SCP, Radius, 2019 Diameter, ...) are available in IPv6. See also [RFC8368] for how 2020 ACP could be made to interoperate with IPv4 only OAM. 2022 6.10.2. The ACP Addressing Base Scheme 2024 The Base ULA addressing scheme for ACP nodes has the following 2025 format: 2027 8 40 2 78 2028 +--+-------------------------+------+------------------------------+ 2029 |fd| hash(routing-subdomain) | Type | (sub-scheme) | 2030 +--+-------------------------+------+------------------------------+ 2032 Figure 8: ACP Addressing Base Scheme 2034 The first 48 bits follow the ULA scheme, as defined in [RFC4193], to 2035 which a type field is added: 2037 o "fd" identifies a locally defined ULA address. 2039 o The 40 bits ULA "global ID" (term from [RFC4193]) for ACP 2040 addresses carried in the domain information field of domain 2041 certificates are the first 40 bits of the SHA256 hash of the 2042 routing subdomain from the same domain information field. In the 2043 example of Section 6.1.1, the routing subdomain is 2044 "area51.research.acp.example.com" and the 40 bits ULA "global ID" 2045 89b714f3db. 2047 o To allow for extensibility, the fact that the ULA "global ID" is a 2048 hash of the routing subdomain SHOULD NOT be assumed by any ACP 2049 node during normal operations. The hash function is only executed 2050 during the creation of the certificate. If BRSKI is used then the 2051 BRSKI registrar will create the domain information field in 2052 response to the EST Certificate Signing Request (CSR) Attribute 2053 Request message by the pledge. 2055 o Type: This field allows different address sub-schemes. This 2056 addresses the "upgradability" requirement. Assignment of types 2057 for this field will be maintained by IANA. 2059 The sub-scheme may imply a range or set of addresses assigned to the 2060 node, this is called the ACP address range/set and explained in each 2061 sub-scheme. 2063 Please refer to Section 6.10.7 and Appendix A.1 for further 2064 explanations why the following Sub-Addressing schemes are used and 2065 why multiple are necessary. 2067 6.10.3. ACP Zone Addressing Sub-Scheme 2069 The sub-scheme defined here is defined by the Type value 00b (zero) 2070 in the base scheme and 0 in the Z bit. 2072 64 64 2073 +-----------------+---+---------++-----------------------------+---+ 2074 | (base scheme) | Z | Zone-ID || Node-ID | 2075 | | | || Registrar-ID | Node-Number| V | 2076 +-----------------+---+---------++--------------+--------------+---+ 2077 50 1 13 48 15 1 2079 Figure 9: ACP Zone Addressing Sub-Scheme 2081 The fields are defined as follows: 2083 o Zone-ID: If set to all zero bits: The Node-ID bits are used as an 2084 identifier (as opposed to a locator). This results in a non- 2085 hierarchical, flat addressing scheme. Any other value indicates a 2086 zone. See Section 6.10.3.1 on how this field is used in detail. 2088 o Z: MUST be 0. 2090 o Node-ID: A unique value for each node. 2092 The 64 bit Node-ID is derived and composed as follows: 2094 o Registrar-ID (48 bit): A number unique inside the domain that 2095 identifies the ACP registrar which assigned the Node-ID to the 2096 node. A MAC address of the ACP registrar can be used for this 2097 purpose. 2099 o Node-Number: A number which is unique for a given ACP registrar, 2100 to identify the node. This can be a sequentially assigned number. 2102 o V (1 bit): Virtualization bit: 0: Indicates the ACP itself ("ACP 2103 node base system); 1: Indicates the optional "host" context on the 2104 ACP node (see below). 2106 In the ACP Zone Addressing Sub-Scheme, the ACP address in the 2107 certificate has Zone-ID and V fields as all zero bits. The ACP 2108 address set includes addresses with any Zone-ID value and any V 2109 value. 2111 The "Node-ID" itself is unique in a domain (i.e., the Zone-ID is not 2112 required for uniqueness). Therefore, a node can be addressed either 2113 as part of a flat hierarchy (Zone-ID = 0), or with an aggregation 2114 scheme (any other Zone-ID). An address with Zone-ID = 0 is an 2115 identifier, with a Zone-ID !=0 it is a locator. See Section 6.10.3.1 2116 for more details. 2118 The Virtual bit in this sub-scheme allows the easy addition of the 2119 ACP as a component to existing systems without causing problems in 2120 the port number space between the services in the ACP and the 2121 existing system. V:0 is the ACP router (autonomic node base system), 2122 V:1 is the host with pre-existing transport endpoints on it that 2123 could collide with the transport endpoints used by the ACP router. 2124 The ACP host could for example have a p2p virtual interface with the 2125 V:0 address as its router into the ACP. Depending on the software 2126 design of ASAs, which is outside the scope of this specification, 2127 they may use the V:0 or V:1 address. 2129 The location of the V bit(s) at the end of the address allows the 2130 announcement of a single prefix for each ACP node. For example, in a 2131 network with 20,000 ACP nodes, this avoid 20,000 additional routes in 2132 the routing table. 2134 6.10.3.1. Usage of the Zone-ID Field 2136 The Zone-ID allows for the introduction of route prefixes in the 2137 addressing scheme. 2139 Zone-ID = 0 is the default addressing scheme in an ACP domain. Every 2140 ACP node with a Zone Addressing Sub-Scheme address MUST respond to 2141 its ACP address with Zone-ID = 0. Used on its own this leads to a 2142 non-hierarchical address scheme, which is suitable for networks up to 2143 a certain size. Zone-ID = 0 addresses act as identifiers for the 2144 nodes, and aggregation of these address in the ACP routing table is 2145 not possible. 2147 If aggregation is required, the 13 bit Zone-ID value allows for up to 2148 8191 zones. The allocation of Zone-ID's may either happen 2149 automatically through a to-be-defined algorithm; or it could be 2150 configured and maintained explicitly. 2152 If a node learns (see Appendix A.10.1) that it is part of a zone, it 2153 MUST also respond to its ACP address with that Zone-ID. In this case 2154 the ACP Loopback is configured with two ACP addresses: One for Zone- 2155 ID = 0 and one for the assigned Zone-ID. This method allows for a 2156 smooth transition between a flat addressing scheme and a hierarchical 2157 one. 2159 A node knowing it is in a zone MUST also use that Zone-ID != 0 2160 address in GRASP locator fields. This eliminates the use of the 2161 identifier address (Zone-ID = 0) in forwarding and the need for 2162 network wide reachability of those non-aggregatable identifier 2163 addresses. Zone-ID != 0 addresses are assumed to be aggregatable in 2164 routing/forwarding based on how they are allocated in the ACP 2165 topology. 2167 Note: The Zone-ID is one method to introduce structure or hierarchy 2168 into the ACP. Another way is the use of the routing subdomain field 2169 in the ACP that leads to multiple /48 Global IDs within an ACP 2170 domain. 2172 Note: Zones and Zone-ID as defined here are not related to [RFC4007] 2173 zones or zone_id. ACP zone addresses are not scoped (reachable only 2174 from within an RFC4007 zone) but reachable across the whole ACP. An 2175 RFC4007 zone_id is a zone index that has only local significance on a 2176 node, whereas an ACP Zone-ID is an identifier for an ACP zone that is 2177 unique across that ACP. 2179 6.10.4. ACP Manual Addressing Sub-Scheme 2181 The sub-scheme defined here is defined by the Type value 00b (zero) 2182 in the base scheme and 1 in the Z bit. 2184 64 64 2185 +---------------------+---+----------++-----------------------------+ 2186 | (base scheme) | Z | Subnet-ID|| Interface Identifier | 2187 +---------------------+---+----------++-----------------------------+ 2188 50 1 13 2190 Figure 10: ACP Manual Addressing Sub-Scheme 2192 The fields are defined as follows: 2194 o Subnet-ID: Configured subnet identifier. 2196 o Z: MUST be 1. 2198 o Interface Identifier. 2200 This sub-scheme is meant for "manual" allocation to subnets where the 2201 other addressing schemes cannot be used. The primary use case is for 2202 assignment to ACP connect subnets (see Section 8.1.1). 2204 "Manual" means that allocations of the Subnet-ID need to be done 2205 today with pre-existing, non-autonomic mechanisms. Every subnet that 2206 uses this addressing sub-scheme needs to use a unique Subnet-ID 2207 (unless some anycast setup is done). 2209 The Z bit field was added to distinguish Zone addressing and manual 2210 addressing sub-schemes without requiring one more bit in the base 2211 scheme and therefore allowing for the Vlong scheme (described below) 2212 to have one more bit available. 2214 Manual addressing sub-scheme addresses SHOULD NOT be used in ACP 2215 domain certificates. Any node capable to build ACP secure channels 2216 and permitted by Registrar policy to participate in building ACP 2217 secure channels SHOULD receive an ACP address (prefix) from one of 2218 the other ACP addressing sub-schemes. Nodes not capable (or 2219 permitted) to participate in ACP secure channels can connect to the 2220 ACP via ACP connect interfaces of ACP edge nodes (see xref 2221 target="ACPconnect"/>), without setting up an ACP secure channel. 2222 Their ACP domain certificate MUST include an empty acp-address to 2223 indicate that their ACP domain certificate is only usable for non- 2224 ACP secure channel authentication, such as end-to-end transport 2225 connections across the ACP or Data-Plane. 2227 Address management of ACP connect subnets is done using traditional 2228 assignment methods and existing IPv6 protocols. See Section 8.1.3 2229 for details. 2231 6.10.5. ACP Vlong Addressing Sub-Scheme 2233 The sub-scheme defined here is defined by the Type value 01b (one) in 2234 the base scheme. 2236 50 78 2237 +---------------------++-----------------------------+----------+ 2238 | (base scheme) || Node-ID | 2239 | || Registrar-ID | Node-Number| V | 2240 +---------------------++--------------+--------------+----------+ 2241 50 46 24/16 8/16 2243 Figure 11: ACP Vlong Addressing Sub-Scheme 2245 This addressing scheme foregoes the Zone-ID field to allow for 2246 larger, flatter routed networks (e.g., as in IoT) with 8421376 Node- 2247 Numbers (2^23+2^15). It also allows for up to 2^16 (i.e. 65536) 2248 different virtualized addresses within a node, which could be used to 2249 address individual software components in an ACP node. 2251 The fields are the same as in the Zone-ID sub-scheme with the 2252 following refinements: 2254 o V: Virtualization bit: Values 0 and 1 are assigned in the same way 2255 as in the Zone-ID sub-scheme. 2257 o Registrar-ID: To maximize Node-Number and V, the Registrar-ID is 2258 reduced to 46 bits. This still permits the use of the MAC address 2259 of an ACP registrar by removing the V and U bits from the 48 bits 2260 of a MAC address (those two bits are never unique, so they cannot 2261 be used to distinguish MAC addresses). 2263 o If the first bit of the "Node-Number" is "1", then the Node-Number 2264 is 16 bit long and the V field is 16 bit long. Otherwise the 2265 Node-Number is 24 bit long and the V field is 8 bit long. 2267 "0" bit Node-Numbers are intended to be used for "general purpose" 2268 ACP nodes that would potentially have a limited number (< 256) of 2269 clients (ASA/Autonomic Functions or legacy services) of the ACP that 2270 require separate V(irtual) addresses. "1" bit Node-Numbers are 2271 intended for ACP nodes that are ACP edge nodes (see Section 8.1.1) or 2272 that have a large number of clients requiring separate V(irtual) 2273 addresses. For example large SDN controllers with container modular 2274 software architecture (see Section 8.1.2). 2276 In the Vlong addressing sub-scheme, the ACP address in the 2277 certificate has all V field bits as zero. The ACP address set for 2278 the node includes any V value. 2280 6.10.6. Other ACP Addressing Sub-Schemes 2282 Before further addressing sub-schemes are defined, experience with 2283 the schemes defined here should be collected. The schemes defined in 2284 this document have been devised to allow hopefully sufficiently 2285 flexible setup of ACPs for a variety of situation. These reasons 2286 also lead to the fairly liberal use of address space: The Zone 2287 Addressing Sub-Scheme is intended to enable optimized routing in 2288 large networks by reserving bits for Zone-ID's. The Vlong addressing 2289 sub-scheme enables the allocation of 8/16 bit of addresses inside 2290 individual ACP nodes. Both address spaces allow distributed, 2291 uncoordinated allocation of node addresses by reserving bits for the 2292 registrar-ID field in the address. 2294 IANA is asked need to assign a new "type" for each new addressing 2295 sub-scheme. With the current allocations, only 2 more schemes are 2296 possible, so the last addressing scheme MUST provide further 2297 extensions (e.g., by reserving bits from it for further extensions). 2299 6.10.7. ACP Registrars 2301 The ACP address prefix is assigned to the ACP node during enrollment/ 2302 provisioning of the ACP domain certificate to the ACP node. It is 2303 intended to persist unchanged through the lifetime of the ACP node. 2305 Because of the ACP addressing sub-schemes explained above, ACP nodes 2306 for a single ACP domain can be enrolled by multiple distributed and 2307 uncoordinated entities called ACP registrars. These ACP registrars 2308 are responsible to enroll ACP domain certificates and associated 2309 trust anchor(s) to candidate ACP nodes and are also responsible that 2310 an ACP domain information field is included in the ACP domain 2311 certificate. 2313 6.10.7.1. Use of BRSKI or other Mechanism/Protocols 2315 Any protocols or mechanisms may be used as ACP registrars, as long as 2316 the resulting ACP certificate and trust anchors allow to perform the 2317 ACP domain membership described in Section 6.1.2 with other ACP 2318 domain members, and meet the ACP addressing requirements for its ACP 2319 domain information field as described further below in this section. 2321 An ACP registrar could be a person deciding whether to enroll a 2322 candidate ACP node and then orchestrating the enrollment of the ACP 2323 certificate and associated trust anchor, using command line or web 2324 based commands on the candidate ACP node and trust anchor to generate 2325 and sign the ACP domain certificate and configure certificate and 2326 trust anchors onto the node. 2328 The only currently defined protocol for ACP registrars is BRSKI 2329 ([I-D.ietf-anima-bootstrapping-keyinfra]). When BRSKI is used, the 2330 ACP nodes are called ANI nodes, and the ACP registrars are called 2331 BRSKI or ANI registrars. The BRSKI specification does not define the 2332 handling of the ACP domain information field because the rules do not 2333 depend on BRSKI but apply equally to any protocols/mechanisms an ACP 2334 registrar may use. 2336 6.10.7.2. Unique Address/Prefix allocation 2338 ACP registrars MUST NOT allocate ACP address prefixes to ACP nodes 2339 via the ACP domain information field that would collide with the ACP 2340 address prefixes of other ACP nodes in the same ACP domain. This 2341 includes both prefixes allocated by the same ACP registrar to 2342 different ACP nodes as well as prefixes allocated by other ACP 2343 registrars for the same ACP domain. 2345 For this purpose, an ACP registrar MUST have one or more unique 46 2346 bit identifiers called Registrar-IDs used to allocate ACP address 2347 prefixes. The lower 46 bits of a EUI-48 MAC addresses are globally 2348 unique 46 bit identifiers, so ACP registrars with known unique EUI-48 2349 MAC addresses can use these as Registrar-IDs. Registrar-IDs do not 2350 need to be globally unique but only unique across the set of ACP 2351 registrars for an ACP domain, so other means to assign unique 2352 Registrar-IDs to ACP registrars can be used, such as configuration on 2353 the ACP registrars. 2355 When the candidate ACP device (called Pledge in BRSKI) is to be 2356 enrolled into an ACP domain, the ACP registrar needs to allocate a 2357 unique ACP address to the node and ensure that the ACP certificate 2358 gets a domain information field (Section 6.1.1) with the appropriate 2359 information - ACP domain-name, ACP-address, and so on. If the ACP 2360 registrar uses BRSKI, it signals the ACP information field to the 2361 Pledge via the EST /csraddrs command (see 2362 [I-D.ietf-anima-bootstrapping-keyinfra], section 5.8.2 - "EST CSR 2363 Attributes"). 2365 [RFC Editor: please update reference to section 5.8.2 accordingly 2366 with latest BRSKI draft at time of publishing, or RFC] 2368 6.10.7.3. Addressing Sub-Scheme Policies 2370 The ACP registrar selects for the candidate ACP node a unique address 2371 prefix from an appropriate ACP addressing sub-scheme, either a zone 2372 addressing sub-scheme prefix (see Section 6.10.3), or a Vlong 2373 addressing sub-scheme prefix (see Section 6.10.5). The assigned ACP 2374 address prefix encoded in the domain information field of the ACP 2375 domain certificate indicates to the ACP node its ACP address 2376 information. The sub-addressing scheme indicates the prefix length: 2377 /127 for zone address sub-scheme, /120 or /112 for Vlong address sub- 2378 scheme. The first address of the prefix is the ACP address, all 2379 other addresses in the prefix are for other uses by the ACP node as 2380 described in the zone and Vlong addressing sub scheme sections. The 2381 ACP address prefix itself is then signaled by the ACP node into the 2382 ACP routing protocol (see Section 6.11) to establish IPv6 2383 reachability across the ACP. 2385 The choice of addressing sub-scheme and prefix-length in the Vlong 2386 address sub-scheme is subject to ACP registrar policy. It could be 2387 an ACP domain wide policy, or a per ACP node or per ACP node type 2388 policy. For example, in BRSKI, the ACP registrar is aware of the 2389 IDevID of the candidate ACP node, which contains a serialNnumber that 2390 is typically indicating the nodes vendor and device type and can be 2391 used to drive a policy selecting an appropriate addressing sub-scheme 2392 for the (class of) node(s). 2394 ACP registrars SHOULD default to allocate ACP zone sub-address scheme 2395 addresses with Subnet-ID 0. Allocation and use of zone sub-addresses 2396 with Subnet-ID != 0 is outside the scope of this specification 2397 because it would need to go along with rules for extending ACP 2398 routing to multiple zones, which is outside the scope of this 2399 specification. 2401 ACP registrars that can use the IDevID of a candidate ACP device 2402 SHOULD be able to choose the zone vs. Vlong sub-address scheme for 2403 ACP nodes based on the serialNumber of the IDevID, for example by the 2404 PID (Product Identifier) part which identifies the product type, or 2405 the complete serialNumber. 2407 In a simple allocation scheme, an ACP registrar remembers 2408 persistently across reboots for its currently used Registrar-ID and 2409 for each addressing scheme (zone with Subnet-ID 0, Vlong with /112, 2410 Vlong with /120), the next Node-Number available for allocation and 2411 increases it after successful enrollment to an ACP node. In this 2412 simple allocation scheme, the ACP registrar would not recycle ACP 2413 address prefixes from no longer used ACP nodes. 2415 6.10.7.4. Address/Prefix Persistence 2417 When an ACP domain certificate is renewed or rekeyed via EST or other 2418 mechanisms, the ACP address/prefix in the ACP domain information 2419 field MUST be maintained unless security issues or violations of the 2420 unique address assignment requirements exist or are suspected by the 2421 ACP registrar. Even when the renewing/rekeying ACP registrar is not 2422 the same as the one that enrolled the prior ACP certificate. See 2423 Section 10.2.4 for an example. ACP address information SHOULD also 2424 be maintained even after an ACP certificate did expire or failed. 2425 See Section 6.1.3.5 and Section 6.1.3.6. 2427 6.10.7.5. Further Details 2429 Section 10.2 discusses further informative details of ACP registrars: 2430 What interactions registrars need, what parameters they require, 2431 certificate renewal and limitations, use of sub-CAs on registrars and 2432 centralized policy control. 2434 6.11. Routing in the ACP 2436 Once ULA address are set up all autonomic entities should run a 2437 routing protocol within the autonomic control plane context. This 2438 routing protocol distributes the ULA created in the previous section 2439 for reachability. The use of the autonomic control plane specific 2440 context eliminates the probable clash with Data-Plane routing tables 2441 and also secures the ACP from interference from the configuration 2442 mismatch or incorrect routing updates. 2444 The establishment of the routing plane and its parameters are 2445 automatic and strictly within the confines of the autonomic control 2446 plane. Therefore, no explicit configuration is required. 2448 All routing updates are automatically secured in transit as the 2449 channels of the autonomic control plane are by default secured, and 2450 this routing runs only inside the ACP. 2452 The routing protocol inside the ACP is RPL ([RFC6550]). See 2453 Appendix A.4 for more details on the choice of RPL. 2455 RPL adjacencies are set up across all ACP channels in the same domain 2456 including all its routing subdomains. See Appendix A.7 for more 2457 details. 2459 6.11.1. RPL Profile 2461 The following is a description of the RPL profile that ACP nodes need 2462 to support by default. The format of this section is derived from 2463 draft-ietf-roll-applicability-template. 2465 6.11.1.1. Summary 2467 In summary, the profile chosen for RPL is one that expects a fairly 2468 reliable network with reasonably fast links so that RPL convergence 2469 will be triggered immediately upon recognition of link failure/ 2470 recovery. 2472 The key limitation of the chosen profile is that it is designed to 2473 not require any Data-Plane artifacts (such as [RFC6553]). While the 2474 senders/receivers of ACP packets can be legacy NOC devices connected 2475 via ACP connect (see Section 8.1.1 to the ACP, their connectivity can 2476 be handled as non-RPL-aware leafs (or "Internet") according to the 2477 Data-Plane architecture explained in [I-D.ietf-roll-useofrplinfo]. 2478 This non-artifact profile is largely driven by the desire to avoid 2479 introducing the required Hop-by-Hop headers into the ACP forwarding 2480 plane, especially to support devices with silicon forwarding planes 2481 that can not support insertion/removal of these headers in silicon. 2483 In this profile choice, RPL has no Data-Plane artifacts. A simple 2484 destination prefix based upon the routing table is used. A 2485 consequence of supporting only a single instanceID that is containing 2486 one Destination Oriented Directed Acyclic Graph (DODAG), the ACP will 2487 only accommodate only a single class of routing table and cannot 2488 create optimized routing paths to accomplish latency or energy goals. 2490 Consider a network that has multiple NOCs in different locations. 2491 Only one NOC will become the DODAG root. Other NOCs will have to 2492 send traffic through the DODAG (tree) rooted in the primary NOC. 2493 Depending on topology, this can be an annoyance from a latency point 2494 of view, but it does not represent a single point of failure, as the 2495 DODAG will reconfigure itself when it detects data plane forwarding 2496 failures. See Appendix A.10.4 for more details. 2498 The lack of RPL Packet Information (RPI, the IPv6 header for RPL 2499 defined by [RFC6553]), means that the Data-Plane will have no rank 2500 value that can be used to detect loops. As a result, traffic may 2501 loop until the time-to-live (TTL) of the packet reaches zero. This 2502 the same behavior as that of other IGPs that do not have the Data- 2503 Plane options as RPL. 2505 Since links in the ACP are assumed to be mostly reliable (or have 2506 link layer protection against loss) and because there is no stretch 2507 according to Section 6.11.1.7, loops should be exceedingly rare 2508 though. 2510 There are a variety of mechanisms possible in RPL to further avoid 2511 temporary loops: DODAG Information Objects (DIOs) SHOULD be sent 2512 2...3 times to inform children when losing the last parent. The 2513 technique in [RFC6550] section 8.2.2.6. (Detaching) SHOULD be 2514 favored over that in section 8.2.2.5., (Poisoning) because it allows 2515 local connectivity. Nodes SHOULD select more than one parent, at 2516 least 3 if possible, and send Destination Advertisement Objects 2517 (DAO)s to all of then in parallel. 2519 Additionally, failed ACP tunnels will be detected by IKEv2 Dead Peer 2520 Detection (which can function as a replacement for a Low-power and 2521 Lossy Networks' (LLN's) Expected Transmission Count (ETX). A failure 2522 of an ACP tunnel should signal the RPL control plane to pick a 2523 different parent. 2525 6.11.1.2. RPL Instances 2527 Single RPL instance. Default RPLInstanceID = 0. 2529 6.11.1.3. Storing vs. Non-Storing Mode 2531 RPL Mode of Operations (MOP): MUST support mode 2 - "Storing Mode of 2532 Operations with no multicast support". Implementations MAY support 2533 mode 3 ("... with multicast support" as that is a superset of mode 2534 2). Note: Root indicates mode in DIO flow. 2536 6.11.1.4. DAO Policy 2538 Proactive, aggressive DAO state maintenance: 2540 o Use K-flag in unsolicited DAO indicating change from previous 2541 information (to require DAO-ACK). 2543 o Retry such DAO DAO-RETRIES(3) times with DAO- ACK_TIME_OUT(256ms) 2544 in between. 2546 6.11.1.5. Path Metric 2548 Hopcount. 2550 6.11.1.6. Objective Function 2552 Objective Function (OF): Use OF0 [RFC6552]. No use of metric 2553 containers. 2555 rank_factor: Derived from link speed: <= 100Mbps: 2556 LOW_SPEED_FACTOR(5), else HIGH_SPEED_FACTOR(1) 2558 6.11.1.7. DODAG Repair 2560 Global Repair: we assume stable links and ranks (metrics), so no need 2561 to periodically rebuild DODAG. DODAG version only incremented under 2562 catastrophic events (e.g., administrative action). 2564 Local Repair: As soon as link breakage is detected, send No-Path DAO 2565 for all the targets that where reachable only via this link. As soon 2566 as link repair is detected, validate if this link provides you a 2567 better parent. If so, compute your new rank, and send new DIO that 2568 advertises your new rank. Then send a DAO with a new path sequence 2569 about yourself. 2571 stretch_rank: none provided ("not stretched"). 2573 Data Path Validation: Not used. 2575 Trickle: Not used. 2577 6.11.1.8. Multicast 2579 Not used yet but possible because of the selected mode of operations. 2581 6.11.1.9. Security 2583 [RFC6550] security not used, substituted by ACP security. 2585 6.11.1.10. P2P communications 2587 Not used. 2589 6.11.1.11. IPv6 address configuration 2591 Every ACP node (RPL node) announces an IPv6 prefix covering the 2592 address(es) used in the ACP node. The prefix length depends on the 2593 chosen addressing sub-scheme of the ACP address provisioned into the 2594 certificate of the ACP node, e.g., /127 for Zone Addressing Sub- 2595 Scheme or /112 or /120 for Vlong addressing sub-scheme. See 2596 Section 6.10 for more details. 2598 Every ACP node MUST install a black hole (aka null) route for 2599 whatever ACP address space that it advertises (i.e.: the /96 or 2600 /127). This is avoid routing loops for addresses that an ACP node 2601 has not (yet) used. 2603 6.11.1.12. Administrative parameters 2605 Administrative Preference ([RFC6550], 3.2.6 - to become root): 2606 Indicated in DODAGPreference field of DIO message. 2608 o Explicit configured "root": 0b100 2610 o ACP registrar (Default): 0b011 2612 o ACP-connect (non-registrar): 0b010 2614 o Default: 0b001. 2616 6.11.1.13. RPL Data-Plane artifacts 2618 RPI (RPL Packet Information [RFC6553]): Not used as there is only a 2619 single instance, and data path validation is not being used. 2621 SRH (RPL Source Routing - RFC6552): Not used. Storing mode is being 2622 used. 2624 6.11.1.14. Unknown Destinations 2626 Because RPL minimizes the size of the routing and forwarding table, 2627 prefixes reachable through the same interface as the RPL root are not 2628 known on every ACP node. Therefore traffic to unknown destination 2629 addresses can only be discovered at the RPL root. The RPL root 2630 SHOULD have attach safe mechanisms to operationally discover and log 2631 such packets. 2633 6.12. General ACP Considerations 2635 Since channels are by default established between adjacent neighbors, 2636 the resulting overlay network does hop-by-hop encryption. Each node 2637 decrypts incoming traffic from the ACP, and encrypts outgoing traffic 2638 to its neighbors in the ACP. Routing is discussed in Section 6.11. 2640 6.12.1. Performance 2642 There are no performance requirements against ACP implementations 2643 defined in this document because the performance requirements depend 2644 on the intended use case. It is expected that full autonomic node 2645 with a wide range of ASA can require high forwarding plane 2646 performance in the ACP, for example for telemetry. Implementations 2647 of ACP to solely support traditional/SDN style use cases can benefit 2648 from ACP at lower performance, especially if the ACP is used only for 2649 critical operations, e.g., when the Data-Plane is not available. The 2650 design of the ACP as specified in this document is intended to 2651 support a wide range of performance options: It is intended to allow 2652 software-only implementations at potentially low performance, but can 2653 also support high performance options. See [RFC8368] for more 2654 details. 2656 6.12.2. Addressing of Secure Channels 2658 In order to be independent of the Data-Plane (routing and addressing) 2659 the GRASP discovered (autonomic) ACP secure channels use IPv6 link 2660 local addresses between adjacent neighbors. Note: Section 8.2 2661 specifies extensions in which secure channels are configured tunnels 2662 operating over the Data-Plane, so those secure channels can not be 2663 independent of the Data-Plane. 2665 To avoid that Data-Plane configuration can impact the operations of 2666 the IPv6 (link-local) interface/address used for ACP channels, 2667 appropriate implementation considerations are required. If the IPv6 2668 interface/link-local address is shared with the Data-Plane it needs 2669 to be impossible to unconfigure/disable it through configuration. 2670 Instead of sharing the IPv6 interface/link-local address, a separate 2671 (virtual) interface with a separate IPv6 link-local addresss can be 2672 used. For example, the ACP interface could be run over a separate 2673 MAC addres of an underlying L2 (Ethernet) interface. For more 2674 details and options, see Appendix A.10.2. 2676 Note that other (non-ideal) implementation choices may introduce 2677 additional undesired dependencies against the Data-Plane. For 2678 example shared code and configuration of the secure channel protocols 2679 (IPsec / DTLS). 2681 6.12.3. MTU 2683 The MTU for ACP secure channels must be derived locally from the 2684 underlying link MTU minus the secure channel encapsulation overhead. 2686 ACP secure Channel protocols do not need to perform MTU discovery 2687 because they are built across L2 adjacencies - the MTU on both sides 2688 connecting to the L2 connection are assumed to be consistent. 2689 Extensions to ACP where the ACP is for example tunneled need to 2690 consider how to guarantee MTU consistency. This is an issue of 2691 tunnels, not an issue of running the ACP across a tunnel. Transport 2692 stacks running across ACP can perform normal PMTUD (Path MTU 2693 Discovery). Because the ACP is meant to be prioritize reliability 2694 over performance, they MAY opt to only expect IPv6 minimum MTU (1280) 2695 to avoid running into PMTUD implementation bugs or underlying link 2696 MTU mismatch problems. 2698 6.12.4. Multiple links between nodes 2700 If two nodes are connected via several links, the ACP SHOULD be 2701 established across every link, but it is possible to establish the 2702 ACP only on a sub-set of links. Having an ACP channel on every link 2703 has a number of advantages, for example it allows for a faster 2704 failover in case of link failure, and it reflects the physical 2705 topology more closely. Using a subset of links (for example, a 2706 single link), reduces resource consumption on the node, because state 2707 needs to be kept per ACP channel. The negotiation scheme explained 2708 in Section 6.5 allows Alice (the node with the higher ACP address) to 2709 drop all but the desired ACP channels to Bob - and Bob will not re- 2710 try to build these secure channels from his side unless Alice shows 2711 up with a previously unknown GRASP announcement (e.g., on a different 2712 link or with a different address announced in GRASP). 2714 6.12.5. ACP interfaces 2716 The ACP VRF has conceptually two type of interfaces: The "ACP 2717 Loopback interface(s)" to which the ACP ULA address(es) are assigned 2718 and the "ACP virtual interfaces" that are mapped to the ACP secure 2719 channels. 2721 The term "Loopback interface" was introduced initially to refer to an 2722 internal interface on a node that would allow IP traffic between 2723 transport endpoints on the node in the absence or failure of any or 2724 all external interfaces, see [RFC4291] section 2.5.3. 2726 Even though Loopback interfaces were originally designed to hold only 2727 Loopback addresses not reachable from outside the node, these 2728 interfaces are also commonly used today to hold addresses reachable 2729 from the outside. They are meant to be reachable independent of any 2730 external interface being operational, and therefore to be more 2731 resilient. These addresses on Loopback interfaces can be thought of 2732 as "node addresses" instead of "interface addresses", and that is 2733 what ACP address(es) are. This construct makes it therefore possible 2734 to address ACP nodes with a well-defined set of addresses independent 2735 of the number of external interfaces. 2737 For these reason, the ACP (ULA) address(es) are assigned to Loopback 2738 interface(s). 2740 Any type of ACP secure channels to another ACP node can be mapped to 2741 ACP virtual interfaces in tollowing ways. This is independent of the 2742 choosen secure channel protocol (IPsec, DTLS or other future protocol 2743 - standards or non-standards): 2745 ACP point-to-point virtual interface: 2747 Each ACP secure channel is mapped into a separate point-to-point ACP 2748 virtual interface. If a physical subnet has more than two ACP 2749 capable nodes (in the same domain), this implementation approach will 2750 lead to a full mesh of ACP virtual interfaces between them. 2752 ACP multi-access virtual interface: 2754 In a more advanced implementation approach, the ACP will construct a 2755 single multi-access ACP virtual interface for all ACP secure channels 2756 to ACP capable nodes reachable across the same underlying (physical) 2757 subnet. IPv6 link-local multicast packets sent into an ACP multi- 2758 access virtual interface are replicated to every ACP secure channel 2759 mapped into the ACP multicast-access virtual interface. IPv6 unicast 2760 packets sent into an ACP multi-access virtual interface are sent to 2761 the ACP secure channel that belongs to the ACP neighbor that is the 2762 next-hop in the ACP forwarding table entry used to reach the packets 2763 destination address. 2765 There is no requirement for all ACP nodes on the same multi-access 2766 subnet to use the same type of ACP virtual interface. This is purely 2767 a node local decision. 2769 ACP nodes MUST perform standard IPv6 operations across ACP virtual 2770 interfaces including SLAAC (Stateless Address Auto-Configuration) - 2771 [RFC4862]) to assign their IPv6 link local address on the ACP virtual 2772 interface and ND (Neighbor Discovery - [RFC4861]) to discover which 2773 IPv6 link-local neighbor address belongs to which ACP secure channel 2774 mapped to the ACP virtual interface. This is independent of whether 2775 the ACP virtual interface is point-to-point or multi-access. 2777 "Optimistic Duplicate Address Detection (DAD)" according to [RFC4429] 2778 is RECOMMENDED because the likelihood for duplicates between ACP 2779 nodes is highly improbable as long as the address can be formed from 2780 a globally unique local assigned identifier (e.g., EUI-48/EUI-64, see 2781 below). 2783 ACP nodes MAY reduce the amount of link-local IPv6 multicast packets 2784 from ND by learning the IPv6 link-local neighbor address to ACP 2785 secure channel mapping from other messages such as the source address 2786 of IPv6 link-local multicast RPL messages - and therefore forego the 2787 need to send Neighbor Solicitation messages. 2789 The ACP virtual interface IPv6 link local address can be derived from 2790 any appropriate local mechanism such as node local EUI-48 or EUI-64 2791 ("EUI" stands for "Extended Unique Identifier"). It MUST NOT depend 2792 on something that is attackable from the Data-Plane such as the IPv6 2793 link-local address of the underlying physical interface, which can be 2794 attacked by SLAAC, or parameters of the secure channel encapsulation 2795 header that may not be protected by the secure channel mechanism. 2797 The link-layer address of an ACP virtual interface is the address 2798 used for the underlying interface across which the secure tunnels are 2799 built, typically Ethernet addresses. Because unicast IPv6 packets 2800 sent to an ACP virtual interface are not sent to a link-layer 2801 destination address but rather an ACP secure channel, the link-layer 2802 address fields SHOULD be ignored on reception and instead the ACP 2803 secure channel from which the message was received should be 2804 remembered. 2806 Multi-access ACP virtual interfaces are preferable implementations 2807 when the underlying interface is a (broadcast) multi-access subnet 2808 because they do reflect the presence of the underlying multi-access 2809 subnet into the virtual interfaces of the ACP. This makes it for 2810 example simpler to build services with topology awareness inside the 2811 ACP VRF in the same way as they could have been built running 2812 natively on the multi-access interfaces. 2814 Consider also the impact of point-to-point vs. multi-access virtual 2815 interface on the efficiency of flooding via link local multicasted 2816 messages: 2818 Assume a LAN with three ACP neighbors, Alice, Bob and Carol. Alice's 2819 ACP GRASP wants to send a link-local GRASP multicast message to Bob 2820 and Carol. If Alice's ACP emulates the LAN as one point-to-point 2821 virtual interface to Bob and one to Carol, The sending applications 2822 itself will send two copies, if Alice's ACP emulates a LAN, GRASP 2823 will send one packet and the ACP will replicate it. The result is 2824 the same. The difference happens when Bob and Carol receive their 2825 packet. If they use ACP point-to-point virtual interfaces, their 2826 GRASP instance would forward the packet from Alice to each other as 2827 part of the GRASP flooding procedure. These packets are unnecessary 2828 and would be discarded by GRASP on receipt as duplicates (by use of 2829 the GRASP Session ID). If Bob and Charly's ACP would emulate a 2830 multi-access virtual interface, then this would not happen, because 2831 GRASPs flooding procedure does not replicate back packets to the 2832 interface that they were received from. 2834 Note that link-local GRASP multicast messages are not sent directly 2835 as IPv6 link-local multicast UDP messages into ACP virtual 2836 interfaces, but instead into ACP GRASP virtual interfaces, that are 2837 layered on top of ACP virtual interfaces to add TCP reliability to 2838 link-local multicast GRASP messages. Nevertheless, these ACP GRASP 2839 virtual interfaces perform the same replication of message and, 2840 therefore, result in the same impact on flooding. See Section 6.8.2 2841 for more details. 2843 RPL does support operations and correct routing table construction 2844 across non-broadcast multi-access (NBMA) subnets. This is common 2845 when using many radio technologies. When such NBMA subnets are used, 2846 they MUST NOT be represented as ACP multi-access virtual interfaces 2847 because the replication of IPv6 link-local multicast messages will 2848 not reach all NBMA subnet neighbors. In result, GRASP message 2849 flooding would fail. Instead, each ACP secure channel across such an 2850 interface MUST be represented as a ACP point-to-point virtual 2851 interface. See also Appendix A.10.4. 2853 Care must also be taken when creating multi-access ACP virtual 2854 interfaces across ACP secure channels between ACP nodes in different 2855 domains or routing subdomains. The policies to be negotiated may be 2856 described as peer-to-peer policies in which case it is easier to 2857 create ACP point-to-point virtual interfaces for these secure 2858 channels. 2860 7. ACP support on L2 switches/ports (Normative) 2862 7.1. Why 2864 ANrtr1 ------ ANswitch1 --- ANswitch2 ------- ANrtr2 2865 .../ \ \ ... 2866 ANrtrM ------ \ ------- ANrtrN 2867 ANswitchM ... 2869 Figure 12: Topology with L2 ACP switches 2871 Consider a large L2 LAN with ANrtr1...ANrtrN connected via some 2872 topology of L2 switches. Examples include large enterprise campus 2873 networks with an L2 core, IoT networks or broadband aggregation 2874 networks which often have even a multi-level L2 switched topology. 2876 If the discovery protocol used for the ACP is operating at the subnet 2877 level, every ACP router will see all other ACP routers on the LAN as 2878 neighbors and a full mesh of ACP channels will be built. If some or 2879 all of the AN switches are autonomic with the same discovery 2880 protocol, then the full mesh would include those switches as well. 2882 A full mesh of ACP connections can create fundamental scale 2883 challenges. The number of security associations of the secure 2884 channel protocols will likely not scale arbitrarily, especially when 2885 they leverage platform accelerated encryption/decryption. Likewise, 2886 any other ACP operations (such as routing) needs to scale to the 2887 number of direct ACP neighbors. An ACP router with just 4 physical 2888 interfaces might be deployed into a LAN with hundreds of neighbors 2889 connected via switches. Introducing such a new unpredictable scaling 2890 factor requirement makes it harder to support the ACP on arbitrary 2891 platforms and in arbitrary deployments. 2893 Predictable scaling requirements for ACP neighbors can most easily be 2894 achieved if in topologies such as these, ACP capable L2 switches can 2895 ensure that discovery messages terminate on them so that neighboring 2896 ACP routers and switches will only find the physically connected ACP 2897 L2 switches as their candidate ACP neighbors. With such a discovery 2898 mechanism in place, the ACP and its security associations will only 2899 need to scale to the number of physical interfaces instead of a 2900 potentially much larger number of "LAN-connected" neighbors. And the 2901 ACP topology will follow directly the physical topology, something 2902 which can then also be leveraged in management operations or by ASAs. 2904 In the example above, consider ANswitch1 and ANswitchM are ACP 2905 capable, and ANswitch2 is not ACP capable. The desired ACP topology 2906 is that ANrtr1 and ANrtrM only have an ACP connection to ANswitch1, 2907 and that ANswitch1, ANrtr2, ANrtrN have a full mesh of ACP connection 2908 amongst each other. ANswitch1 also has an ACP connection with 2909 ANswitchM and ANswitchM has ACP connections to anything else behind 2910 it. 2912 7.2. How (per L2 port DULL GRASP) 2914 To support ACP on L2 switches or L2 switched ports of an L3 device, 2915 it is necessary to make those L2 ports look like L3 interfaces for 2916 the ACP implementation. This primarily involves the creation of a 2917 separate DULL GRASP instance/domain on every such L2 port. Because 2918 GRASP has a dedicated link-local IPv6 multicast address 2919 (ALL_GRASP_NEIGHBORS), it is sufficient that all packets for this 2920 address are being extracted at the port level and passed to that DULL 2921 GRASP instance. Likewise the IPv6 link-local multicast packets sent 2922 by that DULL GRASP instance need to be sent only towards the L2 port 2923 for this DULL GRASP instance. 2925 If the device with L2 ports is supporting per L2 port ACP DULL GRASP 2926 as well as MLD snooping ([RFC4541]), then MLD snooping must be 2927 changed to never forward packets for ALL_GRASP_NEIGHBORS because that 2928 would cause the problem that per L2 port ACP DULL GRASP is meant to 2929 overcome (forwarding DULL GRASP packets across L2 ports). 2931 The rest of ACP operations can operate in the same way as in L3 2932 devices: Assume for example that the device is an L3/L2 hybrid device 2933 where L3 interfaces are assigned to VLANs and each VLAN has 2934 potentially multiple ports. DULL GRASP is run as described 2935 individually on each L2 port. When it discovers a candidate ACP 2936 neighbor, it passes its IPv6 link-local address and supported secure 2937 channel protocols to the ACP secure channel negotiation that can be 2938 bound to the L3 (VLAN) interface. It will simply use link-local IPv6 2939 multicast packets to the candidate ACP neighbor. Once a secure 2940 channel is established to such a neighbor, the virtual interface to 2941 which this secure channel is mapped should then actually be the L2 2942 port and not the L3 interface to best map the actual physical 2943 topology into the ACP virtual interfaces. See Section 6.12.5 for 2944 more details about how to map secure channels into ACP virtual 2945 interfaces. Note that a single L2 port can still have multiple ACP 2946 neighbors if it connect for example to multiple ACP neighbors via a 2947 non-ACP enabled switch. The per L2 port ACP virtual interface can 2948 therefore still be a multi-access virtual LAN. 2950 For example, in the above picture, ANswitch1 would run separate DULL 2951 GRASP instances on its ports to ANrtr1, ANswitch2 and ANswitchI, even 2952 though all those three ports may be in the data plane in the same 2953 (V)LAN and perform L2 switching between these ports, ANswitch1 would 2954 perform ACP L3 routing between them. 2956 The description in the previous paragraph was specifically meant to 2957 illustrate that on hybrid L3/L2 devices that are common in 2958 enterprise, IoT and broadband aggregation, there is only the GRASP 2959 packet extraction (by Ethernet address) and GRASP link-local 2960 multicast per L2-port packet injection that has to consider L2 ports 2961 at the hardware forwarding level. The remaining operations are 2962 purely ACP control plane and setup of secure channels across the L3 2963 interface. This hopefully makes support for per-L2 port ACP on those 2964 hybrid devices easy. 2966 This L2/L3 optimized approach is subject to "address stealing", e.g., 2967 where a device on one port uses addresses of a device on another 2968 port. This is a generic issue in L2 LANs and switches often already 2969 have some form of "port security" to prohibit this. They rely on NDP 2970 or DHCP learning of which port/MAC-address and IPv6 address belong 2971 together and block duplicates. This type of function needs to be 2972 enabled to prohibit DoS attacks. Likewise the GRASP DULL instance 2973 needs to ensure that the IPv6 address in the locator-option matches 2974 the source IPv6 address of the DULL GRASP packet. 2976 In devices without such a mix of L2 port/interfaces and L3 interfaces 2977 (to terminate any transport layer connections), implementation 2978 details will differ. Logically most simply every L2 port is 2979 considered and used as a separate L3 subnet for all ACP operations. 2980 The fact that the ACP only requires IPv6 link-local unicast and 2981 multicast should make support for it on any type of L2 devices as 2982 simple as possible. 2984 A generic issue with ACP in L2 switched networks is the interaction 2985 with the Spanning Tree Protocol. Ideally, the ACP should be built 2986 also across ports that are blocked in STP so that the ACP does not 2987 depend on STP and can continue to run unaffected across STP topology 2988 changes (where re-convergence can be quite slow). The above 2989 described simple implementation options are not sufficient for this. 2990 Instead they would simply have the ACP run across the active STP 2991 topology and the ACP would equally be interrupted and re-converge 2992 with STP changes. 2994 8. Support for Non-ACP Components (Normative) 2996 8.1. ACP Connect 2998 8.1.1. Non-ACP Controller / NMS system 3000 The Autonomic Control Plane can be used by management systems, such 3001 as controllers or network management system (NMS) hosts (henceforth 3002 called simply "NMS hosts"), to connect to devices (or other type of 3003 nodes) through it. For this, an NMS host must have access to the 3004 ACP. The ACP is a self-protecting overlay network, which allows by 3005 default access only to trusted, autonomic systems. Therefore, a 3006 traditional, non-ACP NMS system does not have access to the ACP by 3007 default, such as any other external node. 3009 If the NMS host is not autonomic, i.e., it does not support autonomic 3010 negotiation of the ACP, then it can be brought into the ACP by 3011 explicit configuration. To support connections to adjacent non-ACP 3012 nodes, an ACP node must support "ACP connect" (sometimes also called 3013 "autonomic connect"): 3015 "ACP connect" is a function on an autonomic node that is called an 3016 "ACP edge node". With "ACP connect", interfaces on the node can be 3017 configured to be put into the ACP VRF. The ACP is then accessible to 3018 other (NOC) systems on such an interface without those systems having 3019 to support any ACP discovery or ACP channel setup. This is also 3020 called "native" access to the ACP because to those (NOC) systems the 3021 interface looks like a normal network interface (without any 3022 encryption/novel-signaling). 3024 Data-Plane "native" (no ACP) 3025 . 3026 +--------+ +----------------+ . +-------------+ 3027 | ACP | |ACP Edge Node | . | | 3028 | Node | | | v | | 3029 | |-------|...[ACP VRF]....+-----------------| |+ 3030 | | ^ |. | | NOC Device || 3031 | | . | .[Data-Plane]..+-----------------| "NMS hosts" || 3032 | | . | [ ] | . ^ | || 3033 +--------+ . +----------------+ . . +-------------+| 3034 . . . +-------------+ 3035 . . . 3036 Data-Plane "native" . ACP "native" (unencrypted) 3037 + ACP auto-negotiated . "ACP connect subnet" 3038 and encrypted . 3039 ACP connect interface 3040 e.g., "VRF ACP native" (config) 3042 Figure 13: ACP connect 3044 ACP connect has security consequences: All systems and processes 3045 connected via ACP connect have access to all ACP nodes on the entire 3046 ACP, without further authentication. Thus, the ACP connect interface 3047 and (NOC) systems connected to it must be physically controlled/ 3048 secured. For this reason the mechanisms described here do explicitly 3049 not include options to allow for a non-ACP router to be connected 3050 across an ACP connect interface and addresses behind such a router 3051 routed inside the ACP. 3053 An ACP connect interface provides exclusively access to only the ACP. 3054 This is likely insufficient for many NMS hosts. Instead, they would 3055 require a second "Data-Plane" interface outside the ACP for 3056 connections between the NMS host and administrators, or Internet 3057 based services, or for direct access to the Data-Plane. The document 3058 "Using Autonomic Control Plane for Stable Connectivity of Network 3059 OAM" [RFC8368] explains in more detail how the ACP can be integrated 3060 in a mixed NOC environment. 3062 The ACP connect interface must be (auto-)configured with an IPv6 3063 address prefix. Is prefix SHOULD be covered by one of the (ULA) 3064 prefix(es) used in the ACP. If using non-autonomic configuration, it 3065 SHOULD use the ACP Manual Addressing Sub-Scheme (Section 6.10.4). It 3066 SHOULD NOT use a prefix that is also routed outside the ACP so that 3067 the addresses clearly indicate whether it is used inside the ACP or 3068 not. 3070 The prefix of ACP connect subnets MUST be distributed by the ACP edge 3071 node into the ACP routing protocol (RPL). The NMS hosts MUST connect 3072 to prefixes in the ACP routing table via its ACP connect interface. 3073 In the simple case where the ACP uses only one ULA prefix and all ACP 3074 connect subnets have prefixes covered by that ULA prefix, NMS hosts 3075 can rely on [RFC6724] - The NMS host will select the ACP connect 3076 interface because any ACP destination address is best matched by the 3077 address on the ACP connect interface. If the NMS hosts ACP connect 3078 interface uses another prefix or if the ACP uses multiple ULA 3079 prefixes, then the NMS hosts require (static) routes towards the ACP 3080 interface. 3082 ACP Edge Nodes MUST only forward IPv6 packets received from an ACP 3083 connect interface into the ACP that has an IPv6 address from the ACP 3084 prefix assigned to this interface (sometimes called "RPF filtering"). 3085 This MAY be changed through administrative measures. 3087 To limit the security impact of ACP connect, nodes supporting it 3088 SHOULD implement a security mechanism to allow configuration/use of 3089 ACP connect interfaces only on nodes explicitly targeted to be 3090 deployed with it (those in physically secure locations such as a 3091 NOC). For example, the registrar could disable the ability to enable 3092 ACP connect on devices during enrollment and that property could only 3093 be changed through re-enrollment. See also Appendix A.10.5. 3095 8.1.2. Software Components 3097 The ACP connect mechanism be only be used to connect physically 3098 external systems (NMS hosts) to the ACP but also other applications, 3099 containers or virtual machines. In fact, one possible way to 3100 eliminate the security issue of the external ACP connect interface is 3101 to collocate an ACP edge node and an NMS host by making one a virtual 3102 machine or container inside the other; and therefore converting the 3103 unprotected external ACP subnet into an internal virtual subnet in a 3104 single device. This would ultimately result in a fully ACP enabled 3105 NMS host with minimum impact to the NMS hosts software architecture. 3106 This approach is not limited to NMS hosts but could equally be 3107 applied to devices consisting of one or more VNF (virtual network 3108 functions): An internal virtual subnet connecting out-of-band 3109 management interfaces of the VNFs to an ACP edge router VNF. 3111 The core requirement is that the software components need to have a 3112 network stack that permits access to the ACP and optionally also the 3113 Data-Plane. Like in the physical setup for NMS hosts this can be 3114 realized via two internal virtual subnets. One that is connecting to 3115 the ACP (which could be a container or virtual machine by itself), 3116 and one (or more) connecting into the Data-Plane. 3118 This "internal" use of ACP connect approach should not considered to 3119 be a "workaround" because in this case it is possible to build a 3120 correct security model: It is not necessary to rely on unprovable 3121 external physical security mechanisms as in the case of external NMS 3122 hosts. Instead, the orchestration of the ACP, the virtual subnets 3123 and the software components can be done by trusted software that 3124 could be considered to be part of the ANI (or even an extended ACP). 3125 This software component is responsible for ensuring that only trusted 3126 software components will get access to that virtual subnet and that 3127 only even more trusted software components will get access to both 3128 the ACP virtual subnet and the Data-Plane (because those ACP users 3129 could leak traffic between ACP and Data-Plane). This trust could be 3130 established for example through cryptographic means such as signed 3131 software packages. 3133 8.1.3. Auto Configuration 3135 ACP edge nodes, NMS hosts and software components that as described 3136 in the previous section are meant to be composed via virtual 3137 interfaces SHOULD support on the ACP connect subnet StateLess Address 3138 Autoconfiguration (SLAAC - [RFC4862]) and route auto configuration 3139 according to [RFC4191]. 3141 The ACP edge node acts as the router on the ACP connect subnet, 3142 providing the (auto-)configured prefix for the ACP connect subnet to 3143 NMS hosts and/or software components. The ACP edge node uses route 3144 prefix option of RFC4191 to announce the default route (::/) with a 3145 lifetime of 0 and aggregated prefixes for routes in the ACP routing 3146 table with normal lifetimes. This will ensure that the ACP edge node 3147 does not become a default router, but that the NMS hosts and software 3148 components will route the prefixes used in the ACP to the ACP edge 3149 node. 3151 Aggregated prefix means that the ACP edge node needs to only announce 3152 the /48 ULA prefixes used in the ACP but none of the actual /64 3153 (Manual Addressing Sub-Scheme), /127 (ACP Zone Addressing Sub- 3154 Scheme), /112 or /120 (Vlong Addressing Sub-Scheme) routes of actual 3155 ACP nodes. If ACP interfaces are configured with non ULA prefixes, 3156 then those prefixes cannot be aggregated without further configured 3157 policy on the ACP edge node. This explains the above recommendation 3158 to use ACP ULA prefix covered prefixes for ACP connect interfaces: 3159 They allow for a shorter list of prefixes to be signaled via RFC4191 3160 to NMS hosts and software components. 3162 The ACP edge nodes that have a Vlong ACP address MAY allocate a 3163 subset of their /112 or /120 address prefix to ACP connect 3164 interface(s) to eliminate the need to non-autonomically configure/ 3165 provision the address prefixes for such ACP connect interfaces. 3167 8.1.4. Combined ACP/Data-Plane Interface (VRF Select) 3169 Combined ACP and Data-Plane interface 3170 . 3171 +--------+ +--------------------+ . +--------------+ 3172 | ACP | |ACP Edge No | . | NMS Host(s) | 3173 | Node | | | . | / Software | 3174 | | | [ACP ]. | . | |+ 3175 | | | .[VRF ] .[VRF ] | v | "ACP address"|| 3176 | +-------+. .[Select].+--------+ "Date Plane || 3177 | | ^ | .[Data ]. | | Address(es)"|| 3178 | | . | [Plane] | | || 3179 | | . | [ ] | +--------------+| 3180 +--------+ . +--------------------+ +--------------+ 3181 . 3182 Data-Plane "native" and + ACP auto-negotiated/encrypted 3184 Figure 14: VRF select 3186 Using two physical and/or virtual subnets (and therefore interfaces) 3187 into NMS Hosts (as per Section 8.1.1) or Software (as per 3188 Section 8.1.2) may be seen as additional complexity, for example with 3189 legacy NMS Hosts that support only one IP interface. 3191 To provide a single subnet into both ACP and Data-Plane, the ACP Edge 3192 node needs to de-multiplex packets from NMS hosts into ACP VRF and 3193 Data-Plane. This is sometimes called "VRF select". If the ACP VRF 3194 has no overlapping IPv6 addresses with the Data-Plane (as it should), 3195 then this function can use the IPv6 Destination address. The problem 3196 is Source Address Selection on the NMS Host(s) according to RFC6724. 3198 Consider the simple case: The ACP uses only one ULA prefix, the ACP 3199 IPv6 prefix for the Combined ACP and Data-Plane interface is covered 3200 by that ULA prefix. The ACP edge node announces both the ACP IPv6 3201 prefix and one (or more) prefixes for the Data-Plane. Without 3202 further policy configurations on the NMS Host(s), it may select its 3203 ACP address as a source address for Data-Plane ULA destinations 3204 because of Rule 8 of RFC6724. The ACP edge node can pass on the 3205 packet to the Data-Plane, but the ACP source address should not be 3206 used for Data-Plane traffic, and return traffic may fail. 3208 If the ACP carries multiple ULA prefixes or non-ULA ACP connect 3209 prefixes, then the correct source address selection becomes even more 3210 problematic. 3212 With separate ACP connect and Data-Plane subnets and RFC4191 prefix 3213 announcements that are to be routed across the ACP connect interface, 3214 RFC6724 source address selection Rule 5 (use address of outgoing 3215 interface) will be used, so that above problems do not occur, even in 3216 more complex cases of multiple ULA and non-ULA prefixes in the ACP 3217 routing table. 3219 To achieve the same behavior with a Combined ACP and Data-Plane 3220 interface, the ACP Edge Node needs to behave as two separate routers 3221 on the interface: One link-local IPv6 address/router for its ACP 3222 reachability, and one link-local IPv6 address/router for its Data- 3223 Plane reachability. The Router Advertisements for both are as 3224 described above (Section 8.1.3): For the ACP, the ACP prefix is 3225 announced together with RFC4191 option for the prefixes routed across 3226 the ACP and lifetime=0 to disqualify this next-hop as a default 3227 router. For the Data-Plane, the Data-Plane prefix(es) are announced 3228 together with whatever dafault router parameters are used for the 3229 Data-Plane. 3231 In result, RFC6724 source address selection Rule 5.5 may result in 3232 the same correct source address selection behavior of NMS hosts 3233 without further configuration on it as the separate ACP connect and 3234 Data-Plane interfaces. As described in the text for Rule 5.5, this 3235 is only a may, because IPv6 hosts are not required to track next-hop 3236 information. If an NMS Host does not do this, then separate ACP 3237 connect and Data-Plane interfaces are the preferable method of 3238 attachment. Hosts implementing [RFC8028] should (instead of may) 3239 implement [RFC6724] Rule 5.5, so it is preferred for hosts to support 3240 [RFC8028]. 3242 ACP edge nodes MAY support the Combined ACP and Data-Plane interface. 3244 8.1.5. Use of GRASP 3246 GRASP can and should be possible to use across ACP connect 3247 interfaces, especially in the architectural correct solution when it 3248 is used as a mechanism to connect Software (e.g., ASA or legacy NMS 3249 applications) to the ACP. Given how the ACP is the security and 3250 transport substrate for GRASP, the trustworthiness of nodes/software 3251 allowed to participate in the ACP GRASP domain is one of the main 3252 reasons why the ACP section describes no solution with non-ACP 3253 routers participating in the ACP routing table. 3255 ACP connect interfaces can be dealt with in the GRASP ACP domain the 3256 same as any other ACP interface assuming that any physical ACP 3257 connect interface is physically protected from attacks and that the 3258 connected Software or NMS Hosts are equally trusted as that on other 3259 ACP nodes. ACP edge nodes SHOULD have options to filter GRASP 3260 messages in and out of ACP connect interfaces (permit/deny) and MAY 3261 have more fine-grained filtering (e.g., based on IPv6 address of 3262 originator or objective). 3264 When using "Combined ACP and Data-Plane Interfaces", care must be 3265 taken that only GRASP messages intended for the ACP GRASP domain 3266 received from Software or NMS Hosts are forwarded by ACP edge nodes. 3267 Currently there is no definition for a GRASP security and transport 3268 substrate beside the ACP, so there is no definition how such 3269 Software/NMS Host could participate in two separate GRASP Domains 3270 across the same subnet (ACP and Data-Plane domains). At current it 3271 is assumed that all GRASP packets on a Combined ACP and Data-Plane 3272 interface belong to the GRASP ACP Domain. They must all use the ACP 3273 IPv6 addresses of the Software/NMS Hosts. The link-local IPv6 3274 addresses of Software/NMS Hosts (used for GRASP M_DISCOVERY and 3275 M_FLOOD messages) are also assumed to belong to the ACP address 3276 space. 3278 8.2. ACP through Non-ACP L3 Clouds (Remote ACP neighbors) 3280 Not all nodes in a network may support the ACP. If non-ACP Layer-2 3281 devices are between ACP nodes, the ACP will work across it since it 3282 is IP based. However, the autonomic discovery of ACP neighbors via 3283 DULL GRASP is only intended to work across L2 connections, so it is 3284 not sufficient to autonomically create ACP connections across non-ACP 3285 Layer-3 devices. 3287 8.2.1. Configured Remote ACP neighbor 3289 On the ACP node, remote ACP neighbors are configured explicitly. The 3290 parameters of such a "connection" are described in the following 3291 ABNF. 3293 connection = [ method , local-addr, remote-addr, ?pmtu ] 3294 method = [ "IKEv2" , ?port ] 3295 method //= [ "DTLS", port ] 3296 local-addr = [ address , ?vrf ] 3297 remote-addr = [ address ] 3298 address = ("any" | ipv4-address | ipv6-address ) 3299 vrf = tstr ; Name of a VRF on this node with local-address 3301 Figure 15: Parameters for remote ACP neighbors 3303 Explicit configuration of a remote-peer according to this ABNF 3304 provides all the information to build a secure channel without 3305 requiring a tunnel to that peer and running DULL GRASP inside of it. 3307 The configuration includes the parameters otherwise signaled via DULL 3308 GRASP: local address, remote (peer) locator and method. The 3309 differences over DULL GRASP local neighbor discovery and secure 3310 channel creation are as follows: 3312 o The local and remote address can be IPv4 or IPv6 and are typically 3313 global scope addresses. 3315 o The VRF across which the connection is built (and in which local- 3316 addr exists) can to be specified. If vrf is not specified, it is 3317 the default VRF on the node. In DULL GRASP the VRF is implied by 3318 the interface across which DULL GRASP operates. 3320 o If local address is "any", the local address used when initiating 3321 a secure channel connection is decided by source address selection 3322 ([RFC6724] for IPv6). As a responder, the connection listens on 3323 all addresses of the node in the selected VRF. 3325 o Configuration of port is only required for methods where no 3326 defaults exist (e.g., "DTLS"). 3328 o If remote address is "any", the connection is only a responder. 3329 It is a "hub" that can be used by multiple remote peers to connect 3330 simultaneously - without having to know or configure their 3331 addresses. Example: Hub site for remote "spoke" sites reachable 3332 over the Internet. 3334 o Pmtu should be configurable to overcome issues/limitations of Path 3335 MTU Discovery (PMTUD). 3337 o IKEv2/IPsec to remote peers should support the optional NAT 3338 Traversal (NAT-T) procedures. 3340 8.2.2. Tunneled Remote ACP Neighbor 3342 An IPinIP, GRE or other form of pre-existing tunnel is configured 3343 between two remote ACP peers and the virtual interfaces representing 3344 the tunnel are configured to "ACP enable". This will enable IPv6 3345 link local addresses and DULL on this tunnel. In result, the tunnel 3346 is used for normal "L2 adjacent" candidate ACP neighbor discovery 3347 with DULL and secure channel setup procedures described in this 3348 document. 3350 Tunneled Remote ACP Neighbor requires two encapsulations: the 3351 configured tunnel and the secure channel inside of that tunnel. This 3352 makes it in general less desirable than Configured Remote ACP 3353 Neighbor. Benefits of tunnels are that it may be easier to implement 3354 because there is no change to the ACP functionality - just running it 3355 over a virtual (tunnel) interface instead of only native interfaces. 3356 The tunnel itself may also provide PMTUD while the secure channel 3357 method may not. Or the tunnel mechanism is permitted/possible 3358 through some firewall while the secure channel method may not. 3360 8.2.3. Summary 3362 Configured/Tunneled Remote ACP neighbors are less "indestructible" 3363 than L2 adjacent ACP neighbors based on link local addressing, since 3364 they depend on more correct Data-Plane operations, such as routing 3365 and global addressing. 3367 Nevertheless, these options may be crucial to incrementally deploy 3368 the ACP, especially if it is meant to connect islands across the 3369 Internet. Implementations SHOULD support at least Tunneled Remote 3370 ACP Neighbors via GRE tunnels - which is likely the most common 3371 router-to-router tunneling protocol in use today. 3373 9. Benefits (Informative) 3375 9.1. Self-Healing Properties 3377 The ACP is self-healing: 3379 o New neighbors will automatically join the ACP after successful 3380 validation and will become reachable using their unique ULA 3381 address across the ACP. 3383 o When any changes happen in the topology, the routing protocol used 3384 in the ACP will automatically adapt to the changes and will 3385 continue to provide reachability to all nodes. 3387 o If the domain certificate of an existing ACP node gets revoked, it 3388 will automatically be denied access to the ACP as its domain 3389 certificate will be validated against a Certificate Revocation 3390 List during authentication. Since the revocation check is only 3391 done at the establishment of a new security association, existing 3392 ones are not automatically torn down. If an immediate disconnect 3393 is required, existing sessions to a freshly revoked node can be 3394 re-set. 3396 The ACP can also sustain network partitions and mergers. Practically 3397 all ACP operations are link local, where a network partition has no 3398 impact. Nodes authenticate each other using the domain certificates 3399 to establish the ACP locally. Addressing inside the ACP remains 3400 unchanged, and the routing protocol inside both parts of the ACP will 3401 lead to two working (although partitioned) ACPs. 3403 There are few central dependencies: A certificate revocation list 3404 (CRL) may not be available during a network partition; a suitable 3405 policy to not immediately disconnect neighbors when no CRL is 3406 available can address this issue. Also, an ACP registrar or 3407 Certificate Authority might not be available during a partition. 3408 This may delay renewal of certificates that are to expire in the 3409 future, and it may prevent the enrollment of new nodes during the 3410 partition. 3412 Highly resilient ACP designs can be built by using ACP registrars 3413 with embedded sub-CA, as outlined in Section 10.2.4. As long a a 3414 partition is left with one or more of such ACP registrars, it can 3415 continue to enroll new candidate ACP nodes as long as the ACP 3416 registrars sub-CA certificate does not expire. Because the ACP 3417 addressing relies on unique Registrar-IDs, a later re-merge of 3418 partitions will also not cause problems with ACP addresses assigned 3419 during partitioning. 3421 After a network partition, a re-merge will just establish the 3422 previous status, certificates can be renewed, the CRL is available, 3423 and new nodes can be enrolled everywhere. Since all nodes use the 3424 same trust anchor, a re-merge will be smooth. 3426 Merging two networks with different trust anchors requires the trust 3427 anchors to mutually trust each other (for example, by cross-signing). 3428 As long as the domain names are different, the addressing will not 3429 overlap (see Section 6.10). 3431 It is also highly desirable for implementation of the ACP to be able 3432 to run it over interfaces that are administratively down. If this is 3433 not feasible, then it might instead be possible to request explicit 3434 operator override upon administrative actions that would 3435 administratively bring down an interface across which the ACP is 3436 running. Especially if bringing down the ACP is known to disconnect 3437 the operator from the node. For example any such down administrative 3438 action could perform a dependency check to see if the transport 3439 connection across which this action is performed is affected by the 3440 down action (with default RPL routing used, packet forwarding will be 3441 symmetric, so this is actually possible to check). 3443 9.2. Self-Protection Properties 3445 9.2.1. From the outside 3447 As explained in Section 6, the ACP is based on secure channels built 3448 between nodes that have mutually authenticated each other with their 3449 domain certificates. The channels themselves are protected using 3450 standard encryption technologies such as DTLS or IPsec which provide 3451 additional authentication during channel establishment, data 3452 integrity and data confidentiality protection of data inside the ACP 3453 and in addition, provide replay protection. 3455 An attacker will not be able to join the ACP unless having a valid 3456 domain certificate, also packet injection and sniffing traffic will 3457 not be possible due to the security provided by the encryption 3458 protocol. 3460 The ACP also serves as protection (through authentication and 3461 encryption) for protocols relevant to OAM that may not have secured 3462 protocol stack options or where implementation or deployment of those 3463 options fails on some vendor/product/customer limitations. This 3464 includes protocols such as SNMP, NTP/PTP, DNS, DHCP, syslog, 3465 Radius/Diameter/TACACS, IPFIX/Netflow - just to name a few. 3466 Protection via the ACP secure hop-by-hop channels for these protocols 3467 is meant to be only a stopgap though: The ultimate goal is for these 3468 and other protocols to use end-to-end encryption utilizing the domain 3469 certificate and rely on the ACP secure channels primarily for zero- 3470 touch reliable connectivity, but not primarily for security. 3472 The remaining attack vector would be to attack the underlying ACP 3473 protocols themselves, either via directed attacks or by denial-of- 3474 service attacks. However, as the ACP is built using link-local IPv6 3475 address, remote attacks are impossible. The ULA addresses are only 3476 reachable inside the ACP context, therefore, unreachable from the 3477 Data-Plane. Also, the ACP protocols should be implemented to be 3478 attack resistant and not consume unnecessary resources even while 3479 under attack. 3481 9.2.2. From the inside 3483 The security model of the ACP is based on trusting all members of the 3484 group of nodes that do receive an ACP domain certificate for the same 3485 domain. Attacks from the inside by a compromised group member are 3486 therefore the biggest challenge. 3488 Group members must be protected against attackers so that there is no 3489 easy way to compromise them, or use them as a proxy for attacking 3490 other devices across the ACP. For example, management plane 3491 functions (transport ports) should only be reachable from the ACP but 3492 not the Data-Plane. Especially for those management plane functions 3493 that have no good protection by themselves because they do not have 3494 secure end-to-end transport and to whom ACP does not only provides 3495 automatic reliable connectivity but also protection against attacks. 3496 Protection across all potential attack vectors is typically easier to 3497 do in devices whose software is designed from the ground up with 3498 security in mind than with legacy software based systems where the 3499 ACP is added on as another feature. 3501 As explained above, traffic across the ACP SHOULD still be end-to-end 3502 encrypted whenever possible. This includes traffic such as GRASP, 3503 EST and BRSKI inside the ACP. This minimizes man in the middle 3504 attacks by compromised ACP group members. Such attackers cannot 3505 eavesdrop or modify communications, they can just filter them (which 3506 is unavoidable by any means). 3508 9.3. The Administrator View 3510 An ACP is self-forming, self-managing and self-protecting, therefore 3511 has minimal dependencies on the administrator of the network. 3512 Specifically, since it is independent of configuration, there is no 3513 scope for configuration errors on the ACP itself. The administrator 3514 may have the option to enable or disable the entire approach, but 3515 detailed configuration is not possible. This means that the ACP must 3516 not be reflected in the running configuration of nodes, except a 3517 possible on/off switch. 3519 While configuration is not possible, an administrator must have full 3520 visibility of the ACP and all its parameters, to be able to do 3521 trouble-shooting. Therefore, an ACP must support all show and debug 3522 options, as for any other network function. Specifically, a network 3523 management system or controller must be able to discover the ACP, and 3524 monitor its health. This visibility of ACP operations must clearly 3525 be separated from visibility of Data-Plane so automated systems will 3526 never have to deal with ACP aspect unless they explicitly desire to 3527 do so. 3529 Since an ACP is self-protecting, a node not supporting the ACP, or 3530 without a valid domain certificate cannot connect to it. This means 3531 that by default a traditional controller or network management system 3532 cannot connect to an ACP. See Section 8.1.1 for more details on how 3533 to connect an NMS host into the ACP. 3535 10. ACP Operations (Informative) 3537 The following sections document important operational aspects of the 3538 ACP. They are not normative because they do not impact the 3539 interoperability between components of the ACP, but they include 3540 recommendations/requirements for the internal operational model 3541 beneficial or necessary to achieve the desired use-case benefits of 3542 the ACP (see Section 3). 3544 o Section 10.1 describes recommended operator diagnostics 3545 capabilities of ACP nodes. The have been derived from diagnostic 3546 of a commercially available ACP implementation. 3548 o Section 10.2 describes high level how an ACP registrar needs to 3549 work, what its configuration parameters are and specific issues 3550 impacting the choices of deployment design due to renewal and 3551 revocation issues. It describes a model where ACP Registrars have 3552 their own sub-CA to provide the most disributed deployment option 3553 for ACP Registrars, and it describes considerations for 3554 centralized policy control of ACP Registrar operations. 3556 o Section 10.3 describes suggested ACP node behavior and operational 3557 interfaces (configuration options) to manage the ACP in so-called 3558 greenfield devices (previously unconfigured) and brownfield 3559 devices (preconfigured). 3561 The recommendations and suggestions of this chapter were derived from 3562 operational experience gained with a commercially available pre- 3563 standard ACP implementation. 3565 10.1. ACP (and BRSKI) Diagnostics 3567 Even though ACP and ANI in general are taking out many manual 3568 configuration mistakes through their automation, it is important to 3569 provide good diagnostics for them. 3571 The basic diagnostics is support of (yang) data models representing 3572 the complete (auto-)configuration and operational state of all 3573 components: BRSKI, GRASP, ACP and the infrastructure used by them: 3574 TLS/DTLS, IPsec, certificates, trust anchors, time, VRF and so on. 3575 While necessary, this is not sufficient: 3577 Simply representing the state of components does not allow operators 3578 to quickly take action - unless they do understand how to interpret 3579 the data, and that can mean a requirement for deep understanding of 3580 all components and how they interact in the ACP/ANI. 3582 Diagnostic supports should help to quickly answer the questions 3583 operators are expected to ask, such as "is the ACP working 3584 correctly?", or "why is there no ACP connection to a known 3585 neighboring node?" 3587 In current network management approaches, the logic to answer these 3588 questions is most often built as centralized diagnostics software 3589 that leverages the above mentioned data models. While this approach 3590 is feasible for components utilizing the ANI, it is not sufficient to 3591 diagnose the ANI itself: 3593 o Developing the logic to identify common issues requires 3594 operational experience with the components of the ANI. Letting 3595 each management system define its own analysis is inefficient. 3597 o When the ANI is not operating correctly, it may not be possible to 3598 run diagnostics from remote because of missing connectivity. The 3599 ANI should therefore have diagnostic capabilities available 3600 locally on the nodes themselves. 3602 o Certain operations are difficult or impossible to monitor in real- 3603 time, such as initial bootstrap issues in a network location where 3604 no capabilities exist to attach local diagnostics. Therefore it 3605 is important to also define means of capturing (logging) 3606 diagnostics locally for later retrieval. Ideally, these captures 3607 are also non-volatile so that they can survive extended power-off 3608 conditions - for example when a device that fails to be brought up 3609 zero-touch is being sent back for diagnostics at a more 3610 appropriate location. 3612 The most simple form of diagnostics answering questions such as the 3613 above is to represent the relevant information sequentially in 3614 dependency order, so that the first non-expected/non-operational item 3615 is the most likely root cause. Or just log/highlight that item. For 3616 example: 3618 Q: Is ACP operational to accept neighbor connections: 3620 o Check if any potentially necessary configuration to make ACP/ANI 3621 operational are correct (see Section 10.3 for a discussion of such 3622 commands). 3624 o Does the system time look reasonable, or could it be the default 3625 system time after clock chip battery failure (certificate checks 3626 depend on reasonable notion of time). 3628 o Does the node have keying material - domain certificate, trust 3629 anchors. 3631 o If no keying material and ANI is supported/enabled, check the 3632 state of BRSKI (not detailed in this example). 3634 o Check the validity of the domain certificate: 3636 * Does the certificate authenticate against the trust anchor? 3638 * Has it been revoked? 3639 * Was the last scheduled attempt to retrieve a CRL successful 3640 (e.g., do we know that our CRL information is up to date). 3642 * Is the certificate valid: validity start time in the past, 3643 expiration time in the future? 3645 * Does the certificate have a correctly formatted ACP information 3646 field? 3648 o Was the ACP VRF successfully created? 3650 o Is ACP enabled on one or more interfaces that are up and running? 3652 If all this looks good, the ACP should be running locally "fine" - 3653 but we did not check any ACP neighbor relationships. 3655 Question: why does the node not create a working ACP connection to a 3656 neighbor on an interface? 3658 o Is the interface physically up? Does it have an IPv6 link-local 3659 address? 3661 o Is it enabled for ACP? 3663 o Do we successfully send DULL GRASP messages to the interface (link 3664 layer errors)? 3666 o Do we receive DULL GRASP messages on the interface? If not, some 3667 intervening L2 equipment performing bad MLD snooping could have 3668 caused problems. Provide e.g., diagnostics of the MLD querier 3669 IPv6 and MAC address. 3671 o Do we see the ACP objective in any DULL GRASP message from that 3672 interface? Diagnose the supported secure channel methods. 3674 o Do we know the MAC address of the neighbor with the ACP objective? 3675 If not, diagnose SLAAC/ND state. 3677 o When did we last attempt to build an ACP secure channel to the 3678 neighbor? 3680 o If it failed, why: 3682 * Did the neighbor close the connection on us or did we close the 3683 connection on it because the domain certificate membership 3684 failed? 3686 * If the neighbor closed the connection on us, provide any error 3687 diagnostics from the secure channel protocol. 3689 * If we failed the attempt, display our local reason: 3691 + There was no common secure channel protocol supported by the 3692 two neighbors (this could not happen on nodes supporting 3693 this specification because it mandates common support for 3694 IPsec). 3696 + The ACP domain certificate membership check (Section 6.1.2) 3697 fails: 3699 - The neighbors certificate does not have the required 3700 trust anchor. Provide diagnostics which trust anchor it 3701 has (can identify whom the device belongs to). 3703 - The neighbors certificate does not have the same domain 3704 (or no domain at all). Diagnose domain-name and 3705 potentially other other cert info. 3707 - The neighbors certificate has been revoked or could not 3708 be authenticated by OCSP. 3710 - The neighbors certificate has expired - or is not yet 3711 valid. 3713 * Any other connection issues in e.g., IKEv2 / IPsec, DTLS?. 3715 Question: Is the ACP operating correctly across its secure channels? 3717 o Are there one or more active ACP neighbors with secure channels? 3719 o Is the RPL routing protocol for the ACP running? 3721 o Is there a default route to the root in the ACP routing table? 3723 o Is there for each direct ACP neighbor not reachable over the ACP 3724 virtual interface to the root a route in the ACP routing table? 3726 o Is ACP GRASP running? 3728 o Is at least one SRV.est objective cached (to support certificate 3729 renewal)? 3731 o Is there at least one BRSKI registrar objective cached (in case 3732 BRSKI is supported) 3734 o Is BRSKI proxy operating normally on all interfaces where ACP is 3735 operating? 3737 o ... 3739 These lists are not necessarily complete, but illustrate the 3740 principle and show that there are variety of issues ranging from 3741 normal operational causes (a neighbor in another ACP domain) over 3742 problems in the credentials management (certificate lifetimes), 3743 explicit security actions (revocation) or unexpected connectivity 3744 issues (intervening L2 equipment). 3746 The items so far are illustrating how the ANI operations can be 3747 diagnosed with passive observation of the operational state of its 3748 components including historic/cached/counted events. This is not 3749 necessary sufficient to provide good enough diagnostics overall: 3751 The components of ACP and BRSKI are designed with security in mind 3752 but they do not attempt to provide diagnostics for building the 3753 network itself. Consider two examples: 3755 1. BRSKI does not allow for a neighboring device to identify the 3756 pledges certificate (IDevID). Only the selected BRSKI registrar 3757 can do this, but it may be difficult to disseminate information 3758 about undesired pledges from those BRSKI registrars to locations/ 3759 nodes where information about those pledges is desired. 3761 2. The Link Layer Discovery Protocol (LLDP, [LLDP]) disseminates 3762 information about nodes to their immediate neighbors, such as 3763 node model/type/software and interface name/number of the 3764 connection. This information is often helpful or even necessary 3765 in network diagnostics. It can equally considered to be too 3766 insecure to make this information available unprotected to all 3767 possible neighbors. 3769 An "interested adjacent party" can always determine the IDevID of a 3770 BRSKI pledge by behaving like a BRSKI proxy/registrar. Therefore the 3771 IDevID of a BRSKI pledge is not meant to be protected - it just has 3772 to be queried and is not signaled unsolicited (as it would be in 3773 LLDP) so that other observers on the same subnet can determine who is 3774 an "interested adjacent party". 3776 10.2. ACP Registrars 3778 As described in Section 6.10.7, the ACP addressing mechanism is 3779 designed to enable lightweight, distributed and uncoordinated ACP 3780 registrars that are providing ACP address prefixes to candidate ACP 3781 nodes by enrolling them with an ACP domain certificate into an ACP 3782 domain via any appropriate mechanism/protocol, automated or not. 3784 This section discusses informatively more details and options for ACP 3785 registrars. 3787 10.2.1. Registrar interactions 3789 This section summarizes and discusses the interactions with other 3790 entities required by an ACP registrar. 3792 In a simple instance of an ACP network, no central NOC component 3793 beside a trust anchor (root CA) is required. One or more 3794 uncoordinated acting ACP registrar can be set up, performing the 3795 following interactions: 3797 To orchestrate enrolling a candidate ACP node autonomically, the ACP 3798 registrar can rely on the ACP and use Proxies to reach the candidate 3799 ACP node, therefore allowing minimum pre-existing (auto-)configured 3800 network services on the candidate ACP node. BRSKI defines the BRSKI 3801 proxy, a design that can be adopted for various protocols that 3802 Pledges/candidate ACP nodes could want to use, for example BRSKI over 3803 CoAP (Constrained Application Protocol), or proxying of Netconf. 3805 To reach a trust anchor unaware of the ACP, the ACP registrar would 3806 use the Data-Plane. ACP and Data-Plane in an ACP registrar could 3807 (and by default should be) completely isolated from each other at the 3808 network level. Only applications such as the ACP registrar would 3809 need the ability for their transport stacks to access both. 3811 In non autonomic enrollment options, the Data-Plane between a ACP 3812 registrar and the candidate ACP node needs to be configured first. 3813 This includes the ACP registrar and the candidate ACP node. Then any 3814 appropriate set of protocols can be used between ACP registrar and 3815 candidate ACP node to discover the other side, and then connect and 3816 enroll (configure) the candidate ACP node with an ACP domain 3817 certificate. Netconf ZeroTouch ([I-D.ietf-netconf-zerotouch]) is an 3818 example protocol that could be used for this. BRSKI using optional 3819 discovery mechanisms is equally a possibility for candidate ACP nodes 3820 attempting to be enrolled across non-ACP networks, such as the 3821 Internet. 3823 When candidate ACP nodes have secure bootstrap, such as BRSKI 3824 Pledges, they will not trust to be configured/enrolled across the 3825 network, unless being presented with a voucher (see [RFC8366]) 3826 authorizing the network to take possession of the node. An ACP 3827 registrar will then need a method to retrieve such a voucher, either 3828 offline, or online from a MASA (Manufacturer Authorized Signing 3829 Authority). BRSKI and Netconf ZeroTouch are two protocols that 3830 include capabilities to present the voucher to the candidate ACP 3831 node. 3833 An ACP registrar could operate EST for ACP certificate renewal and/or 3834 act as a CRL Distribution point. A node performing these services 3835 does not need to support performing (initial) enrollment, but it does 3836 require the same above described connectivity as an ACP registrar: 3837 via the ACP to ACP nodes and via the Data-Plane to the trust anchor 3838 and other sources of CRL information. 3840 10.2.2. Registrar Parameter 3842 The interactions of an ACP registrar outlined Section 6.10.7 and 3843 Section 10.2.1 above depend on the following parameters: 3845 A URL to the trust anchor (root CA) and credentials so that the 3846 ACP registrar can let the trust anchor sign candidate ACP member 3847 certificates. 3849 The ACP domain-name. 3851 The Registrar-ID to use. This could default to a MAC address of 3852 the ACP registrar. 3854 For recovery, the next-useable Node-IDs for zone (Zone-ID=0) sub- 3855 addressing scheme, for Vlong /112 and for Vlong /1120 sub- 3856 addressing scheme. These IDs would only need to be provisioned 3857 after recovering from a crash. Some other mechanism would be 3858 required to remember these IDs in a backup location or to recover 3859 them from the set of currently known ACP nodes. 3861 Policies if candidate ACP nodes should receive a domain 3862 certificate or not, for example based on the devices LDevID as in 3863 BRSKI. The ACP registrar may have a whitelist or blacklist of 3864 devices serialNumbers from teir LDevID. 3866 Policies what type of address prefix to assign to a candidate ACP 3867 devices, based on likely the same information. 3869 For BRSKI or other mechanisms using vouchers: Parameters to 3870 determine how to retrieve vouchers for specific type of secure 3871 bootstrap candidate ACP nodes (such as MASA URLs), unless this 3872 information is automatically learned such as from the LDevID of 3873 candidate ACP nodes (as defined in BRSKI). 3875 10.2.3. Certificate renewal and limitations 3877 When an ACP node renews/rekeys its certificate, it may end up doing 3878 so via a different registrar (e.g., EST server) than the one it 3879 originally received its ACP domain certificate from, for example 3880 because that original ACP registrar is gone. The ACP registrar 3881 through which the renewal/rekeying is performed would by default 3882 trust the ACP domain information from the ACP nodes current ACP 3883 domain certificate and maintain this information so that the ACP node 3884 maintains its ACP address prefix. In EST renewal/rekeying, the ACP 3885 nodes current ACP domain certificate is signaled during the TLS 3886 handshake. 3888 This simple scenario has two limitations: 3890 1. The ACP registrars can not directly assign certificates to nodes 3891 and therefore needs an "online" connection to the trust anchor 3892 (root CA). 3894 2. Recovery from a compromised ACP registrar is difficult. When an 3895 ACP registrar is compromised, it can insert for example 3896 conflicting ACP domain information and create thereby an attack 3897 against other ACP nodes through the ACP routing protocol. 3899 Even when such a malicious ACP registrar is detected, resolving the 3900 problem may be difficult because it would require identifying all the 3901 wrong ACP domain certificates assigned via the ACP registrar after it 3902 was was compromised. And without additional centralized tracking of 3903 assigned certificates there is no way to do this - assuming one can 3904 not retrieve this information from the . 3906 10.2.4. ACP Registrars with sub-CA 3908 In situations, where either of the above two limitations are an 3909 issue, ACP registrars could also be sub-CAs. This removes the need 3910 for connectivity to a root-CA whenever an ACP node is enrolled, and 3911 reduces the need for connectivity of such an ACP registrar to a root- 3912 CA to only those times when it needs to renew its own certificate. 3913 The ACP registrar would also now use its own (sub-CA) certificate to 3914 enroll and sign the ACP nodes certificates, and therefore it is only 3915 necessary to revoke a compromised ACP registrars sub-CA certificate. 3916 Or let it expire and not renew it, when the certificate of the sub-CA 3917 is appropriately short-lived. 3919 As the ACP domain membership check verifies a peer ACP node's ACP 3920 domain certicate trust chain, it will also verify the signing 3921 certificate which is the compromised/revoked sub-CA certificate. 3923 Therefore ACP domain membership for an ACP node enrolled from a 3924 compromised ACP registrar will fail. 3926 ACP nodes enrolled by a compromised ACP registrar would automatically 3927 fail to establish ACP channels and ACP domain certificate renewal via 3928 EST and therefore revert to their role as a candidate ACP members and 3929 attempt to get a new ACP domain certificate from an ACP registrar - 3930 for example via BRSKI. In result, ACP registrars that have an 3931 associated sub-CA makes isolating and resolving issues with 3932 compromised registrars easier. 3934 Note that ACP registrars with sub-CA functionality also can control 3935 the lifetime of ACP domain certificates easier and therefore also be 3936 used as a tool to introduce short lived certificates and not rely on 3937 CRL, whereas the certificates for the sub-CAs themselves could be 3938 longer lived and subject to CRL. 3940 10.2.5. Centralized Policy Control 3942 When using multiple, uncoordinated ACP registrars, several advanced 3943 operations are potentially more complex than with a single, resilient 3944 policy control backend, for example including but not limited to: 3946 Which candidate ACP node is permitted or not permitted into an ACP 3947 domain. This may not be a decision to be taken upfront, so that a 3948 per-serialNumber policy can be loaded into ever ACP registrar. 3949 Instead, it may better be decided in real-time including 3950 potentially a human decision in a NOC. 3952 Tracking of all enrolled ACP nodes and their certificate 3953 information. For example in support of revoking individual ACP 3954 nodes certificates. 3956 More flexible policies what type of address prefix or even what 3957 specific address prefix to assign to a candidate ACP node. 3959 These and other operations could be introduced more easily by 3960 introducing a centralized Policy Management System (PMS) and 3961 modifying ACP registrar behavior so that it queries the PMS for any 3962 policy decision occuring during the candidate ACP node enrollment 3963 process and/or the ACP node certificate renewal process. For 3964 example, which ACP address prefix to assign. Likewise the ACP 3965 registrar would report any relevant state change information to the 3966 PMS as well, for example when a certificate was successfully enrolled 3967 onto a candidate ACP node. 3969 10.3. Enabling and disabling ACP/ANI 3971 Both ACP and BRSKI require interfaces to be operational enough to 3972 support sending/receiving their packets. In node types where 3973 interfaces are by default (e.g., without operator configuration) 3974 enabled, such as most L2 switches, this would be less of a change in 3975 behavior than in most L3 devices (e.g.: routers), where interfaces 3976 are by default disabled. In almost all network devices it is common 3977 though for configuration to change interfaces to a physically 3978 disabled state and that would break the ACP. 3980 In this section, we discuss a suggested operational model to enable/ 3981 disable interfaces and nodes for ACP/ANI in a way that minimizes the 3982 risk of operator action to break the ACP in this way, and that also 3983 minimizes operator surprise when ACP/ANI becomes supported in node 3984 software. 3986 10.3.1. Filtering for non-ACP/ANI packets 3988 Whenever this document refers to enabling an interface for ACP (or 3989 BRSKI), it only requires to permit the interface to send/receive 3990 packets necessary to operate ACP (or BRSKI) - but not any other Data- 3991 Plane packets. Unless the Data-Plane is explicitly configured/ 3992 enabled, all packets not required for ACP/BRSKI should be filtered on 3993 input and output: 3995 Both BRSKI and ACP require link-local only IPv6 operations on 3996 interfaces and DULL GRASP. IPv6 link-local operations means the 3997 minimum signaling to auto-assign an IPv6 link-local address and talk 3998 to neighbors via their link-local address: SLAAC (Stateless Address 3999 Auto-Configuration - [RFC4862]) and ND (Neighbor Discovery - 4000 [RFC4861]). When the device is a BRSKI pledge, it may also require 4001 TCP/TLS connections to BRSKI proxies on the interface. When the 4002 device has keying material, and the ACP is running, it requires DULL 4003 GRASP packets and packets necessary for the secure-channel mechanism 4004 it supports, e.g., IKEv2 and IPsec ESP packets or DTLS packets to the 4005 IPv6 link-local address of an ACP neighbor on the interface. It also 4006 requires TCP/TLS packets for its BRSKI proxy functionality, if it 4007 does support BRSKI. 4009 10.3.2. Admin Down State 4011 Interfaces on most network equipment have at least two states: "up" 4012 and "down". These may have product specific names. "down" for 4013 example could be called "shutdown" and "up" could be called "no 4014 shutdown". The "down" state disables all interface operations down 4015 to the physical level. The "up" state enables the interface enough 4016 for all possible L2/L3 services to operate on top of it and it may 4017 also auto-enable some subset of them. More commonly, the operations 4018 of various L2/L3 services is controlled via additional node-wide or 4019 interface level options, but they all become only active when the 4020 interface is not "down". Therefore an easy way to ensure that all 4021 L2/L3 operations on an interface are inactive is to put the interface 4022 into "down" state. The fact that this also physically shuts down the 4023 interface is in many cases just a side effect, but it may be 4024 important in other cases (see below, Section 10.3.2.2). 4026 To provide ACP/ANI resilience against operators configuring 4027 interfaces to "down" state, this document recommends to separate the 4028 "down" state of interfaces into an "admin down" state where the 4029 physical layer is kept running and ACP/ANI can use the interface and 4030 a "physical down" state. Any existing "down" configurations would 4031 map to "admin down". In "admin down", any existing L2/L3 services of 4032 the Data-Plane should see no difference to "physical down" state. To 4033 ensure that no Data-Plane packets could be sent/received, packet 4034 filtering could be established automatically as described above in 4035 Section 10.3.1. 4037 As necessary (see discussion below) new configuration options could 4038 be introduced to issue "physical down". The options should be 4039 provided with additional checks to minimize the risk of issuing them 4040 in a way that breaks the ACP without automatic restoration. For 4041 example they could be denied to be issued from a control connection 4042 (netconf/ssh) that goes across the interface itself ("do not 4043 disconnect yourself"). Or they could be performed only temporary and 4044 only be made permanent with additional later reconfirmation. 4046 In the following sub-sections important aspects to the introduction 4047 of "admin down" state are discussed. 4049 10.3.2.1. Security 4051 Interfaces are physically brought down (or left in default down 4052 state) as a form of security. "Admin down" state as described above 4053 provides also a high level of security because it only permits ACP/ 4054 ANI operations which are both well secured. Ultimately, it is 4055 subject to security review for the deployment whether "admin down" is 4056 a feasible replacement for "physical down". 4058 The need to trust into the security of ACP/ANI operations need to be 4059 weighed against the operational benefits of permitting this: Consider 4060 the typical example of a CPE (customer premises equipment) with no 4061 on-site network expert. User ports are in physical down state unless 4062 explicitly configured not to be. In a misconfiguration situation, 4063 the uplink connection is incorrectly plugged into such a user port. 4064 The device is disconnected from the network and therefore no 4065 diagnostics from the network side is possible anymore. 4066 Alternatively, all ports default to "admin down". The ACP (but not 4067 the Data-Plane) would still automatically form. Diagnostics from the 4068 network side is possible and operator reaction could include to 4069 either make this port the operational uplink port or to instruct re- 4070 cabling. Security wise, only ACP/ANI could be attacked, all other 4071 functions are filtered on interfaces in "admin down" state. 4073 10.3.2.2. Fast state propagation and Diagnostics 4075 "Physical down" state propagates on many interface types (e.g., 4076 Ethernet) to the other side. This can trigger fast L2/L3 protocol 4077 reaction on the other side and "admin down" would not have the same 4078 (fast) result. 4080 Bringing interfaces to "physical down" state is to the best of our 4081 knowledge always a result of operator action, but today, never the 4082 result of (autonomic) L2/L3 services running on the nodes. Therefore 4083 one option is to change the operator action to not rely on link-state 4084 propagation anymore. This may not be possible when both sides are 4085 under different operator control, but in that case it is unlikely 4086 that the ACP is running across the link and actually putting the 4087 interface into "physical down" state may still be a good option. 4089 Ideally, fast physical state propagation is replaced by fast software 4090 driven state propagation. For example a DULL GRASP "admin-state" 4091 objective could be used to auto configure a Bidirectional Forwarding 4092 Protocol (BFD, [RFC5880]) session between the two sides of the link 4093 that would be used to propagate the "up" vs. admin down state. 4095 Triggering physical down state may also be used as a mean of 4096 diagnosing cabling in the absence of easier methods. It is more 4097 complex than automated neighbor diagnostics because it requires 4098 coordinated remote access to both (likely) sides of a link to 4099 determine whether up/down toggling will cause the same reaction on 4100 the remote side. 4102 See Section 10.1 for a discussion about how LLDP and/or diagnostics 4103 via GRASP could be used to provide neighbor diagnostics, and 4104 therefore hopefully eliminating the need for "physical down" for 4105 neighbor diagnostics - as long as both neighbors support ACP/ANI. 4107 10.3.2.3. Low Level Link Diagnostics 4109 "Physical down" is performed to diagnose low-level interface behavior 4110 when higher layer services (e.g., IPv6) are not working. Especially 4111 Ethernet links are subject to a wide variety of possible wrong 4112 configuration/cablings if they do not support automatic selection of 4113 variable parameters such as speed (10/100/1000 Mbps), crossover 4114 (Auto-MDIX) and connector (fiber, copper - when interfaces have 4115 multiple but can only enable one at a time). The need for low level 4116 link diagnostic can therefore be minimized by using fully auto 4117 configuring links. 4119 In addition to "Physical down", low level diagnostics of Ethernet or 4120 other interfaces also involve the creation of other states on 4121 interfaces, such as physical Loopback (internal and/or external) or 4122 bringing down all packet transmissions for reflection/cable-length 4123 measurements. Any of these options would disrupt ACP as well. 4125 In cases where such low-level diagnostics of an operational link is 4126 desired but where the link could be a single point of failure for the 4127 ACP, ASA on both nodes of the link could perform a negotiated 4128 diagnostics that automatically terminates in a predetermined manner 4129 without dependence on external input ensuring the link will become 4130 operational again. 4132 10.3.2.4. Power Consumption Issues 4134 Power consumption of "physical down" interfaces, may be significantly 4135 lower than those in "admin down" state, for example on long-range 4136 fiber interfaces. Bringing up interfaces, for example to probe 4137 reachabiliy, may also consume additional power. This can make these 4138 type of interfaces inappropriate to operate purely for the ACP when 4139 they are not currently needed for the Data-Plane. 4141 10.3.3. Interface level ACP/ANI enable 4143 The interface level configuration option "ACP enable" enables ACP 4144 operations on an interface, starting with ACP neighbor discovery via 4145 DULL GRAP. The interface level configuration option "ANI enable" on 4146 nodes supporting BRSKI and ACP starts with BRSKI pledge operations 4147 when there is no domain certificate on the node. On ACP/BRSKI nodes, 4148 "ACP enable" may not need to be supported, but only "ANI enable". 4149 Unless overridden by global configuration options (see later), "ACP/ 4150 ANI enable" will result in "down" state on an interface to behave as 4151 "admin down". 4153 10.3.4. Which interfaces to auto-enable? 4155 (Section 6.3) requires that "ACP enable" is automatically set on 4156 native interfaces, but not on non-native interfaces (reminder: a 4157 native interface is one that exists without operator configuration 4158 action such as physical interfaces in physical devices). 4160 Ideally, ACP enable is set automatically on all interfaces that 4161 provide access to additional connectivity that allows to reach more 4162 nodes of the ACP domain. The best set of interfaces necessary to 4163 achieve this is not possible to determine automatically. Native 4164 interfaces are the best automatic approximation. 4166 Consider an ACP domain of ACP nodes transitively connected via native 4167 interfaces. A Data-Plane tunnel between two of these nodes that are 4168 non-adjacent is created and "ACP enable" is set for that tunnel. ACP 4169 RPL sees this tunnel as just as a single hop. Routes in the ACP 4170 would use this hop as an attractive path element to connect regions 4171 adjacent to the tunnel nodes. In result, the actual hop-by-hop paths 4172 used by traffic in the ACP can become worse. In addition, correct 4173 forwarding in the ACP now depends on correct Data-Plane forwarding 4174 config including QoS, filtering and other security on the Data-Plane 4175 path across which this tunnel runs. This is the main issue why "ACP/ 4176 ANI enable" should not be set automatically on non-native interfaces. 4178 If the tunnel would connect two previously disjoint ACP regions, then 4179 it likely would be useful for the ACP. A Data-Plane tunnel could 4180 also run across nodes without ACP and provide additional connectivity 4181 for an already connected ACP network. The benefit of this additional 4182 ACP redundancy has to be weighed against the problems of relying on 4183 the Data-Plane. If a tunnel connects two separate ACP regions: how 4184 many tunnels should be created to connect these ACP regions reliably 4185 enough? Between which nodes? These are all standard tunneled 4186 network design questions not specific to the ACP, and there are no 4187 generic fully automated answers. 4189 Instead of automatically setting "ACP enable" on these type of 4190 interfaces, the decision needs to be based on the use purpose of the 4191 non-native interface and "ACP enable" needs to be set in conjunction 4192 with the mechanism through which the non-native interface is created/ 4193 configured. 4195 In addition to explicit setting of "ACP/ANI enable", non-native 4196 interfaces also need to support configuration of the ACP RPL cost of 4197 the link - to avoid the problems of attracting too much traffic to 4198 the link as described above. 4200 Even native interfaces may not be able to automatically perform BRSKI 4201 or ACP because they may require additional operator input to become 4202 operational. Example include DSL interfaces requiring PPPoE 4203 credentials or mobile interfaces requiring credentials from a SIM 4204 card. Whatever mechanism is used to provide the necessary config to 4205 the device to enable the interface can also be expanded to decide on 4206 whether or not to set "ACP/ANI enable". 4208 The goal of automatically setting "ACP/ANI enable" on interfaces 4209 (native or not) is to eliminate unnecessary "touches" to the node to 4210 make its operation as much as possible "zero-touch" with respect to 4211 ACP/ANI. If there are "unavoidable touches" such a creating/ 4212 configuring a non-native interface or provisioning credentials for a 4213 native interface, then "ACP/ANI enable" should be added as an option 4214 to that "touch". If a wrong "touch" is easily fixed (not creating 4215 another high-cost touch), then the default should be not to enable 4216 ANI/ACP, and if it is potentially expensive or slow to fix (e.g., 4217 parameters on SIM card shipped to remote location), then the default 4218 should be to enable ACP/ANI. 4220 10.3.5. Node Level ACP/ANI enable 4222 A node level command "ACP/ANI enable [up-if-only]" enables ACP or ANI 4223 on the node (ANI = ACP + BRSKI). Without this command set, any 4224 interface level "ACP/ANI enable" is ignored. Once set, ACP/ANI will 4225 operate interface where "ACP/ANI enable" is set. Setting of 4226 interface level "ACP/ANI enable" is either automatic (default) or 4227 explicit through operator action as described in the previous 4228 section. 4230 If the option "up-if-only" is selected, the behavior of "down" 4231 interfaces is unchanged, and ACP/ANI will only operate on interfaces 4232 where "ACP/ANI enable" is set and that are "up". When it is not set, 4233 then "down" state of interfaces with "ACP/ANI enable" is modified to 4234 behave as "admin down". 4236 10.3.5.1. Brownfield nodes 4238 A "brownfield" node is one that already has a configured Data-Plane. 4240 Executing global "ACP/ANI enable [up-if-only]" on each node is the 4241 only command necessary to create an ACP across a network of 4242 brownfield nodes once all the nodes have a domain certificate. When 4243 BRSKI is used ("ANI enable"), provisioning of the certificates only 4244 requires set-up of a single BRSKI registrar node which could also 4245 implement a CA for the network. This is the most simple way to 4246 introduce ACP/ANI into existing (== brownfield) networks. 4248 The need to explicitly enable ACP/ANI is especially important in 4249 brownfield nodes because otherwise software updates may introduce 4250 support for ACP/ANI: Automatic enablement of ACP/ANI in networks 4251 where the operator does not only not want ACP/ANI but where he likely 4252 never even heard of it could be quite irritating to him. Especially 4253 when "down" behavior is changed to "admin down". 4255 Automatically setting "ANI enable" on brownfield nodes where the 4256 operator is unaware of it could also be a critical security issue 4257 depending on the vouchers used by BRKSI on these nodes. An attacker 4258 could claim to be the owner of these devices and create an ACP that 4259 the attacker has access/control over. In network where the operator 4260 explicitly wants to enable the ANI this could not happen, because he 4261 would create a BRSKI registrar that would discover attack attempts. 4262 Nodes requiring "ownership vouchers" would not be subject to that 4263 attack. See [I-D.ietf-anima-bootstrapping-keyinfra] for more 4264 details. Note that a global "ACP enable" alone is not subject to 4265 these type of attacks, because it always depends on some other 4266 mechanism first to provision domain certificates into the device. 4268 10.3.5.2. Greenfield nodes 4270 A "greenfield" node is one that did not have any prior configuration. 4272 For greenfield nodes, only "ANI enable" is relevant. If another 4273 mechanism than BRSKI is used to (zero-touch) bootstrap a node, then 4274 it is up to that mechanism to provision domain certificates and to 4275 set global "ACP enable" as desired. 4277 Nodes supporting full ANI functionality set "ANI enable" 4278 automatically when they decide that they are greenfield, e.g., that 4279 they are powering on from factory condition. They will then put all 4280 native interfaces into "admin down" state and start to perform BRSKI 4281 pledge functionality - and once a domain certificate is enrolled they 4282 automatically enable ACP. 4284 Attempts for BRSKI pledge operations in greenfield state should 4285 terminate automatically when another method of configuring the node 4286 is used. Methods that indicate some form of physical possession of 4287 the device such as configuration via the serial console port could 4288 lead to immediate termination of BRSKI, while other parallel auto 4289 configuration methods subject to remote attacks might lead to BRSKI 4290 termination only after they were successful. Details of this may 4291 vary widely over different type of nodes. When BRSKI pledge 4292 operation terminates, this will automatically unset "ANI enable" and 4293 should terminate any temporarily needed state on the device to 4294 perform BRSKI - DULL GRASP, BRSKI pledge and any IPv6 configuration 4295 on interfaces. 4297 10.3.6. Undoing ANI/ACP enable 4299 Disabling ANI/ACP by undoing "ACP/ANI enable" is a risk for the 4300 reliable operations of the ACP if it can be executed by mistake or 4301 unauthorized. This behavior could be influenced through some 4302 additional property in the certificate (e.g., in the domain 4303 information extension field) subject to future work: In an ANI 4304 deployment intended for convenience, disabling it could be allowed 4305 without further constraints. In an ANI deployment considered to be 4306 critical more checks would be required. One very controlled option 4307 would be to not permit these commands unless the domain certificate 4308 has been revoked or is denied renewal. Configuring this option would 4309 be a parameter on the BRSKI registrar(s). As long as the node did 4310 not receive a domain certificate, undoing "ANI/ACP enable" should not 4311 have any additional constraints. 4313 10.3.7. Summary 4315 Node-wide "ACP/ANI enable [up-if-only]" commands enable the operation 4316 of ACP/ANI. This is only auto-enabled on ANI greenfield devices, 4317 otherwise it must be configured explicitly. 4319 If the option "up-if-only" is not selected, interfaces enabled for 4320 ACP/ANI interpret "down" state as "admin down" and not "physical 4321 down". In "admin-down" all non-ACP/ANI packets are filtered, but the 4322 physical layer is kept running to permit ACP/ANI to operate. 4324 (New) commands that result in physical interruption ("physical down", 4325 "loopback") of ACP/ANI enabled interfaces should be built to protect 4326 continuance or reestablishment of ACP as much as possible. 4328 Interface level "ACP/ANI enable" control per-interface operations. 4329 It is enabled by default on native interfaces and has to be 4330 configured explicitly on other interfaces. 4332 Disabling "ACP/ANI enable" global and per-interface should have 4333 additional checks to minimize undesired breakage of ACP. The degree 4334 of control could be a domain wide parameter in the domain 4335 certificates. 4337 11. Security Considerations 4339 An ACP is self-protecting and there is no need to apply configuration 4340 to make it secure. Its security therefore does not depend on 4341 configuration. See Section 9.2 for details of how the ACP protects 4342 itself against attacks from the outside and to a more limited degree 4343 from the inside as well. 4345 However, the security of the ACP depends on a number of other 4346 factors: 4348 o The usage of domain certificates depends on a valid supporting PKI 4349 infrastructure. If the chain of trust of this PKI infrastructure 4350 is compromised, the security of the ACP is also compromised. This 4351 is typically under the control of the network administrator. 4353 o Security can be compromised by implementation errors (bugs), as in 4354 all products. 4356 There is no prevention of source-address spoofing inside the ACP. 4357 This implies that if an attacker gains access to the ACP, it can 4358 spoof all addresses inside the ACP and fake messages from any other 4359 node. 4361 Fundamentally, security depends on correct operation, implementation 4362 and architecture. Autonomic approaches such as the ACP largely 4363 eliminate the dependency on correct operation; implementation and 4364 architectural mistakes are still possible, as in all networking 4365 technologies. 4367 Many details of ACP are designed with security in mind and discussed 4368 elsewhere in the document: 4370 IPv6 addresses used by nodes in the ACP are covered as part of the 4371 node's domain certificate as described in Section 6.1.1. This allows 4372 even verification of ownership of a peers IPv6 address when using a 4373 connection authenticated with the domain certificate. 4375 The ACP acts as a security (and transport) substrate for GRASP inside 4376 the ACP such that GRASP is not only protected by attacks from the 4377 outside, but also by attacks from compromised inside attackers - by 4378 relying not only on hop-by-hop security of ACP secure channels, but 4379 adding end-to-end security for those GRASP messages. See 4380 Section 6.8.2. 4382 ACP provides for secure, resilient zero-touch discovery of EST 4383 servers for certificate renewal. See Section 6.1.3. 4385 ACP provides extensible, auto-configuring hop-by-hop protection of 4386 the ACP infrastructure via the negotiation of hop-by-hop secure 4387 channel protocols. See Section 6.5 and Appendix A.6. 4389 The ACP is designed to minimize attacks from the outside by 4390 minimizing its dependency against any non-ACP (Data-Plane) 4391 operations/configuration on a node. See also Section 6.12.2. 4393 In combination with BRSKI, ACP enables a resilient, fully zero-touch 4394 network solution for short-lived certificates that can be renewed or 4395 re-enrolled even after unintentional expiry (e.g., because of 4396 interrupted connectivity). See Appendix A.2. 4398 12. IANA Considerations 4400 This document defines the "Autonomic Control Plane". 4402 The IANA is requested to register the value "AN_ACP" (without quotes) 4403 to the GRASP Objectives Names Table in the GRASP Parameter Registry. 4404 The specification for this value is this document, Section 6.3. 4406 The IANA is requested to register the value "SRV.est" (without 4407 quotes) to the GRASP Objectives Names Table in the GRASP Parameter 4408 Registry. The specification for this value is this document, 4409 Section 6.1.3. 4411 Note that the objective format "SRV." is intended to be 4412 used for any that is an [RFC6335] registered service 4413 name. This is a proposed update to the GRASP registry subject to 4414 future work and only mentioned here for informational purposed to 4415 explain the unique format of the objective name. 4417 The IANA is requested to create an ACP Parameter Registry with 4418 currently one registry table - the "ACP Address Type" table. 4420 "ACP Address Type" Table. The value in this table are numeric values 4421 0...3 paired with a name (string). Future values MUST be assigned 4422 using the Standards Action policy defined by [RFC8126]. The 4423 following initial values are assigned by this document: 4425 0: ACP Zone Addressing Sub-Scheme (ACP RFC Figure 9) / ACP Manual 4426 Addressing Sub-Scheme (ACP RFC Section 6.10.4) 4427 1: ACP Vlong Addressing Sub-Scheme (ACP RFC Section 6.10.5) 4429 13. Acknowledgements 4431 This work originated from an Autonomic Networking project at Cisco 4432 Systems, which started in early 2010. Many people contributed to 4433 this project and the idea of the Autonomic Control Plane, amongst 4434 which (in alphabetical order): Ignas Bagdonas, Parag Bhide, Balaji 4435 BL, Alex Clemm, Yves Hertoghs, Bruno Klauser, Max Pritikin, Michael 4436 Richardson, Ravi Kumar Vadapalli. 4438 Special thanks to Brian Carpenter, Elwyn Davies, Joel Halpern and 4439 Sheng Jiang for their thorough reviews and to Pascal Thubert and 4440 Michael Richardson to provide the details for the recommendations of 4441 the use of RPL in the ACP. 4443 Further input, review or suggestions were received from: Rene Struik, 4444 Brian Carpenter, Benoit Claise, William Atwood and Yongkang Zhang. 4446 14. Change log [RFC Editor: Please remove] 4448 14.1. Initial version 4450 First version of this document: draft-behringer-autonomic-control- 4451 plane 4453 14.2. draft-behringer-anima-autonomic-control-plane-00 4455 Initial version of the anima document; only minor edits. 4457 14.3. draft-behringer-anima-autonomic-control-plane-01 4459 o Clarified that the ACP should be based on, and support only IPv6. 4461 o Clarified in intro that ACP is for both, between devices, as well 4462 as for access from a central entity, such as an NMS. 4464 o Added a section on how to connect an NMS system. 4466 o Clarified the hop-by-hop crypto nature of the ACP. 4468 o Added several references to GDNP as a candidate protocol. 4470 o Added a discussion on network split and merge. Although, this 4471 should probably go into the certificate management story longer 4472 term. 4474 14.4. draft-behringer-anima-autonomic-control-plane-02 4476 Addresses (numerous) comments from Brian Carpenter. See mailing list 4477 for details. The most important changes are: 4479 o Introduced a new section "overview", to ease the understanding of 4480 the approach. 4482 o Merged the previous "problem statement" and "use case" sections 4483 into a mostly re-written "use cases" section, since they were 4484 overlapping. 4486 o Clarified the relationship with draft-ietf-anima-stable- 4487 connectivity 4489 14.5. draft-behringer-anima-autonomic-control-plane-03 4491 o Took out requirement for IPv6 --> that's in the reference doc. 4493 o Added requirement section. 4495 o Changed focus: more focus on autonomic functions, not only virtual 4496 out-of-band. This goes a bit throughout the document, starting 4497 with a changed abstract and intro. 4499 14.6. draft-ietf-anima-autonomic-control-plane-00 4501 No changes; re-submitted as WG document. 4503 14.7. draft-ietf-anima-autonomic-control-plane-01 4505 o Added some paragraphs in addressing section on "why IPv6 only", to 4506 reflect the discussion on the list. 4508 o Moved the Data-Plane ACP out of the main document, into an 4509 appendix. The focus is now the virtually separated ACP, since it 4510 has significant advantages, and isn't much harder to do. 4512 o Changed the self-creation algorithm: Part of the initial steps go 4513 into the reference document. This document now assumes an 4514 adjacency table, and domain certificate. How those get onto the 4515 device is outside scope for this document. 4517 o Created a new section 6 "workarounds for non-autonomic nodes", and 4518 put the previous controller section (5.9) into this new section. 4519 Now, section 5 is "autonomic only", and section 6 explains what to 4520 do with non-autonomic stuff. Much cleaner now. 4522 o Added an appendix explaining the choice of RPL as a routing 4523 protocol. 4525 o Formalised the creation process a bit more. Now, we create a 4526 "candidate peer list" from the adjacency table, and form the ACP 4527 with those candidates. Also it explains now better that policy 4528 (Intent) can influence the peer selection. (section 4 and 5) 4530 o Introduce a section for the capability negotiation protocol 4531 (section 7). This needs to be worked out in more detail. This 4532 will likely be based on GRASP. 4534 o Introduce a new parameter: ACP tunnel type. And defines it in the 4535 IANA considerations section. Suggest GRE protected with IPSec 4536 transport mode as the default tunnel type. 4538 o Updated links, lots of small edits. 4540 14.8. draft-ietf-anima-autonomic-control-plane-02 4542 o Added explicitly text for the ACP channel negotiation. 4544 o Merged draft-behringer-anima-autonomic-addressing-02 into this 4545 document, as suggested by WG chairs. 4547 14.9. draft-ietf-anima-autonomic-control-plane-03 4549 o Changed Neighbor discovery protocol from GRASP to mDNS. Bootstrap 4550 protocol team decided to go with mDNS to discover bootstrap proxy, 4551 and ACP should be consistent with this. Reasons to go with mDNS 4552 in bootstrap were a) Bootstrap should be reuseable also outside of 4553 full anima solutions and introduce as few as possible new 4554 elements. mDNS was considered well-known and very-likely even pre- 4555 existing in low-end devices (IoT). b) Using GRASP both for the 4556 insecure neighbor discovery and secure ACP operatations raises the 4557 risk of introducing security issues through implementation issues/ 4558 non-isolation between those two instances of GRASP. 4560 o Shortened the section on GRASP instances, because with mDNS being 4561 used for discovery, there is no insecure GRASP session any longer, 4562 simplifying the GRASP considerations. 4564 o Added certificate requirements for ANIMA in section 5.1.1, 4565 specifically how the ANIMA information is encoded in 4566 subjectAltName. 4568 o Deleted the appendix on "ACP without separation", as originally 4569 planned, and the paragraph in the main text referring to it. 4571 o Deleted one sub-addressing scheme, focusing on a single scheme 4572 now. 4574 o Included information on how ANIMA information must be encoded in 4575 the domain certificate in section "preconditions". 4577 o Editorial changes, updated draft references, etc. 4579 14.10. draft-ietf-anima-autonomic-control-plane-04 4581 Changed discovery of ACP neighbor back from mDNS to GRASP after 4582 revisiting the L2 problem. Described problem in discovery section 4583 itself to justify. Added text to explain how ACP discovery relates 4584 to BRSKY (bootstrap) discovery and pointed to Michael Richardsons 4585 draft detailing it. Removed appendix section that contained the 4586 original explanations why GRASP would be useful (current text is 4587 meant to be better). 4589 14.11. draft-ietf-anima-autonomic-control-plane-05 4591 o Section 5.3 (candidate ACP neighbor selection): Add that Intent 4592 can override only AFTER an initial default ACP establishment. 4594 o Section 6.10.1 (addressing): State that addresses in the ACP are 4595 permanent, and do not support temporary addresses as defined in 4596 RFC4941. 4598 o Modified Section 6.3 to point to the GRASP objective defined in 4599 draft-carpenter-anima-ani-objectives. (and added that reference) 4601 o Section 6.10.2: changed from MD5 for calculating the first 40 bits 4602 to SHA256; reason is MD5 should not be used any more. 4604 o Added address sub-scheme to the IANA section. 4606 o Made the routing section more prescriptive. 4608 o Clarified in Section 8.1.1 the ACP Connect port, and defined that 4609 term "ACP Connect". 4611 o Section 8.2: Added some thoughts (from mcr) on how traversing a L3 4612 cloud could be automated. 4614 o Added a CRL check in Section 6.7. 4616 o Added a note on the possibility of source-address spoofing into 4617 the security considerations section. 4619 o Other editoral changes, including those proposed by Michael 4620 Richardson on 30 Nov 2016 (see ANIMA list). 4622 14.12. draft-ietf-anima-autonomic-control-plane-06 4624 o Added proposed RPL profile. 4626 o detailed DTLS profile - DTLS with any additional negotiation/ 4627 signaling channel. 4629 o Fixed up text for ACP/GRE encap. Removed text claiming its 4630 incompatible with non-GRE IPsec and detailled it. 4632 o Added text to suggest admin down interfaces should still run ACP. 4634 14.13. draft-ietf-anima-autonomic-control-plane-07 4636 o Changed author association. 4638 o Improved ACP connect setion (after confusion about term came up in 4639 the stable connectivity draft review). Added picture, defined 4640 complete terminology. 4642 o Moved ACP channel negotiation from normative section to appendix 4643 because it can in the timeline of this document not be fully 4644 specified to be implementable. Aka: work for future document. 4645 That work would also need to include analysing IKEv2 and describin 4646 the difference of a proposed GRASP/TLS solution to it. 4648 o Removed IANA request to allocate registry for GRASP/TLS. This 4649 would come with future draft (see above). 4651 o Gave the name "ACP information field" to the field in the 4652 certificate carrying the ACP address and domain name. 4654 o Changed the rules for mutual authentication of certificates to 4655 rely on the domain in the ACP information field of the certificate 4656 instead of the OU in the certificate. Also renewed the text 4657 pointing out that the ACP information field in the certificate is 4658 meant to be in a form that it does not disturb other uses of the 4659 certificate. As long as the ACP expected to rely on a common OU 4660 across all certificates in a domain, this was not really true: 4661 Other uses of the certificates might require different OUs for 4662 different areas/type of devices. With the rules in this draft 4663 version, the ACP authentication does not rely on any other fields 4664 in the certificate. 4666 o Added an extension field to the ACP information field so that in 4667 the future additional fields like a subdomain could be inserted. 4668 An example using such a subdomain field was added to the pre- 4669 existing text suggesting sub-domains. This approach is necessary 4670 so that there can be a single (main) domain in the ACP information 4671 field, because that is used for mutual authentication of the 4672 certificate. Also clarified that only the register(s) SHOULD/MUST 4673 use that the ACP address was generated from the domain name - so 4674 that we can easier extend change this in extensions. 4676 o Took the text for the GRASP discovery of ACP neighbors from Brians 4677 grasp-ani-objectives draft. Alas, that draft was behind the 4678 latest GRASP draft, so i had to overhaul. The mayor change is to 4679 describe in the ACP draft the whole format of the M_FLOOD message 4680 (and not only the actual objective). This should make it a lot 4681 easier to read (without having to go back and forth to the GRASP 4682 RFC/draft). It was also necessary because the locator in the 4683 M_FLOOD messages has an important role and its not coded inside 4684 the objective. The specification of how to format the M_FLOOD 4685 message shuold now be complete, the text may be some duplicate 4686 with the DULL specificateion in GRASP, but no contradiction. 4688 o One of the main outcomes of reworking the GRASP section was the 4689 notion that GRASP announces both the candidate peers IPv6 link 4690 local address but also the support ACP security protocol including 4691 the port it is running on. In the past we shied away from using 4692 this information because it is not secured, but i think the 4693 additional attack vectors possible by using this information are 4694 negligible: If an attacker on an L2 subnet can fake another 4695 devices GRASP message then it can already provide a similar amount 4696 of attack by purely faking the link-local address. 4698 o Removed the section on discovery and BRSKI. This can be revived 4699 in the BRSKI document, but it seems mood given how we did remove 4700 mDNS from the latest BRSKI document (aka: this section discussed 4701 discrepancies between GRASP and mDNS discovery which should not 4702 exist anymore with latest BRSKI. 4704 o Tried to resolve the EDNOTE about CRL vs. OCSP by pointing out we 4705 do not specify which one is to be used but that the ACP should be 4706 used to reach the URL included in the certificate to get to the 4707 CRL storage or OCSP server. 4709 o Changed ACP via IPsec to ACP via IKEv2 and restructured the 4710 sections to make IPsec native and IPsec via GRE subsections. 4712 o No need for any assigned DTLS port if ACP is run across DTLS 4713 because it is signaled via GRASP. 4715 14.14. draft-ietf-anima-autonomic-control-plane-08 4717 Modified mentioning of BRSKI to make it consistent with current 4718 (07/2017) target for BRSKI: MASA and IDevID are mandatory. Devices 4719 with only insecure UDI would need a security reduced variant of 4720 BRSKI. Also added mentioning of Netconf Zero-Touch. Made BRSKI non- 4721 normative for ACP because wrt. ACP it is just one option how the 4722 domain certificate can be provisioned. Instead, BRSKI is mandatory 4723 when a device implements ANI which is ACP+BRSKI. 4725 Enhanced text for ACP across tunnels to decribe two options: one 4726 across configured tunnels (GRE, IPinIP etc) a more efficient one via 4727 directed DULL. 4729 Moved decription of BRSKI to appendex to emphasize that BRSKI is not 4730 a (normative) dependency of GRASP, enhanced text to indicate other 4731 options how Domain Certificates can be provisioned. 4733 Added terminology section. 4735 Separated references into normative and non-normative. 4737 Enhanced section about ACP via "tunnels". Defined an option to run 4738 ACP secure channel without an outer tunnel, discussed PMTU, benefits 4739 of tunneling, potential of using this with BRSKI, made ACP via GREP a 4740 SHOULD requirement. 4742 Moved appendix sections up before IANA section because there where 4743 concerns about appendices to be to far on the bottom to be read. 4744 Added (Informative) / (Normative) to section titles to clarify which 4745 sections are informative and which are normative 4747 Moved explanation of ACP with L2 from precondition to separate 4748 section before workarounds, made it instructive enough to explain how 4749 to implement ACP on L2 ports for L3/L2 switches and made this part of 4750 normative requirement (L2/L3 switches SHOULD support this). 4752 Rewrote section "GRASP in the ACP" to define GRASP in ACP as 4753 mandatory (and why), and define the ACP as security and transport 4754 substrate to GRASP in ACP. And how it works. 4756 Enhanced "self-protection" properties section: protect legacy 4757 management protocols. Security in ACP is for protection from outside 4758 and those legacy protocols. Otherwise need end-to-end encryption 4759 also inside ACP, e.g., with domain certificate. 4761 Enhanced initial domain certificate section to include requirements 4762 for maintenance (renewal/revocation) of certificates. Added 4763 explanation to BRSKI informative section how to handle very short 4764 lived certificates (renewal via BRSKI with expired cert). 4766 Modified the encoding of the ACP address to better fit RFC822 simple 4767 local-parts (":" as required by RFC5952 are not permitted in simple 4768 dot-atoms according to RFC5322. Removed reference to RFC5952 as its 4769 now not needed anymore. 4771 Introduced a sub-domain field in the ACP information in the 4772 certificate to allow defining such subdomains with depending on 4773 future Intent definitions. It also makes it clear what the "main 4774 domain" is. Scheme is called "routing subdomain" to have a unique 4775 name. 4777 Added V8 (now called Vlong) addressing sub-scheme according to 4778 suggestion from mcr in his mail from 30 Nov 2016 4779 (https://mailarchive.ietf.org/arch/msg/anima/ 4780 nZpEphrTqDCBdzsKMpaIn2gsIzI). Also modified the explanation of the 4781 single V bit in the first sub-scheme now renamed to Zone sub-scheme 4782 to distinguish it. 4784 14.15. draft-ietf-anima-autonomic-control-plane-09 4786 Added reference to RFC4191 and explained how it should be used on ACP 4787 edge routers to allow auto configuration of routing by NMS hosts. 4788 This came after review of stable connectivity draft where ACP connect 4789 is being referred to. 4791 V8 addressing Sub-Scheme was modified to allow not only /8 device- 4792 local address space but also /16. This was in response to the 4793 possible need to have maybe as much as 2^12 local addresses for 4794 future encaps in BRSKI like IPinIP. It also would allow fully 4795 autonomic address assignment for ACP connect interfaces from this 4796 local address space (on an ACP edge device), subject to approval of 4797 the implied update to rfc4291/rfc4193 (IID length). Changed name to 4798 Vlong addressing sub-scheme. 4800 Added text in response to Brian Carpenters review of draft-ietf- 4801 anima-stable-connectivity-04. 4803 o The stable connectivity draft was vaguely describing ACP connect 4804 behavior that is better standardized in this ACP draft. 4806 o Added new ACP "Manual" addressing sub-scheme with /64 subnets for 4807 use with ACP connect interfaces. Being covered by the ACP ULA 4808 prefix, these subnets do not require additional routing entries 4809 for NMS hosts. They also are fully 64-bit IID length compliant 4810 and therefore not subject to 4191bis considerations. And they 4811 avoid that operators manually assign prefixes from the ACP ULA 4812 prefixes that might later be assigned autonomiously. 4814 o ACP connect auto-configuration: Defined that ACP edge devices, NMS 4815 hosts should use RFC4191 to automatically learn ACP prefixes. 4816 This is especially necessary when the ACP uses multiple ULA 4817 prefixes (via e.g., the rsub domain certificate option), or if ACP 4818 connect subinterfaces use manually configured prefixes NOT covered 4819 by the ACP ULA prefixes. 4821 o Explained how rfc6724 is (only) sufficient when the NMS host has a 4822 separate ACP connect and Data-Plane interface. But not when there 4823 is a single interface. 4825 o Added a separate subsection to talk about "software" instead of 4826 "NMS hosts" connecting to the ACP via the "ACP connect" method. 4827 The reason is to point out that the "ACP connect" method is not 4828 only a workaround (for NMS hosts), but an actual desirable long 4829 term architectural component to modularily build software (e.g., 4830 ASA or OAM for VNF) into ACP devices. 4832 o Added a section to define how to run ACP connect across the same 4833 interface as the Data-Plane. This turns out to be quite 4834 challenging because we only want to rely on existing standards for 4835 the network stack in the NMS host/software and only define what 4836 features the ACP edge device needs. 4838 o Added section about use of GRASP over ACP connect. 4840 o Added text to indicate packet processing/filtering for security: 4841 filter incorrect packets arriving on ACP connect interfaces, 4842 diagnose on RPL root packets to incorrect destination address (not 4843 in ACP connect section, but because of it). 4845 o Reaffirm security goal of ACP: Do not permit non-ACP routers into 4846 ACP routing domain. 4848 Made this ACP document be an update to RFC4291 and RFC4193. At the 4849 core, some of the ACP addressing sub-schemes do effectively not use 4850 64-bit IIDs as required by RFC4191 and debated in rfc4191bis. During 4851 6man in prague, it was suggested that all documents that do not do 4852 this should be classified as such updates. Add a rather long section 4853 that summarizes the relevant parts of ACP addressing and usage and. 4854 Aka: This section is meant to be the primary review section for 4855 readers interested in these changes (e.g., 6man WG.). 4857 Added changes from Michael Richardsons review https://github.com/ 4858 anima-wg/autonomic-control-plane/pull/3/commits, textual and: 4860 o ACP discovery inside ACP is bad *doh*!. 4862 o Better CA trust and revocation sentences. 4864 o More details about RPL behavior in ACP. 4866 o black hole route to avoid loops in RPL. 4868 Added requirement to terminate ACP channels upon cert expiry/ 4869 revocation. 4871 Added fixes from 08-mcr-review-reply.txt (on github): 4873 o AN Domain Names are FQDNs. 4875 o Fixed bit length of schemes, numerical writing of bits (00b/01b). 4877 o Lets use US american english. 4879 14.16. draft-ietf-anima-autonomic-control-plane-10 4881 Used the term routing subdomain more consistently where previously 4882 only subdomain was used. Clarified use of routing subdomain in 4883 creation of ULA "global ID" addressing prefix. 4885 6.7.1.* Changed native IPsec encapsulation to tunnel mode 4886 (necessary), explaned why. Added notion that ESP is used, added 4887 explanations why tunnel/transport mode in native vs. GRE cases. 4889 6.10.3/6.10.5 Added term "ACP address range/set" to be able to better 4890 explain how the address in the ACP certificate is actually the base 4891 address (lowest address) of a range/set that is available to the 4892 device. 4894 6.10.4 Added note that manual address sub-scheme addresses must not 4895 be used within domain certificates (only for explicit configuration). 4897 6.12.5 Refined explanation of how ACP virtual interfaces work (p2p 4898 and multipoint). Did seek for pre-existing RFCs that explain how to 4899 built a multi-access interface on top of a full mesh of p2p 4900 connections (6man WG, anima WG mailing lists), but could not find any 4901 prior work that had a succinct explanation. So wrote up an 4902 explanation here. Added hopefully all necessary and sufficient 4903 details how to map ACP unicast packets to ACP secure channel, how to 4904 deal with ND packet details. Added verbage for ACP not to assign the 4905 virtual interface link-local address from the underlying interface. 4906 Addd note that GRAP link-local messages are treated specially but 4907 logically the same. Added paragraph about NBMA interfaces. 4909 remaining changes from Brian Carpenters review. See Github file 4910 draft-ietf-anima-autonomic-control-plane/08-carpenter-review-reply.tx 4911 for more detailst: 4913 Added multiple new RFC references for terms/technologies used. 4915 Fixed verbage in several places. 4917 2. (terminology) Added 802.1AR as reference. 4919 2. Fixed up definition of ULA. 4921 6.1.1 Changed definition of ACP information in cert into ABNF format. 4922 Added warning about maximum size of ACP address field due to domain- 4923 name limitations. 4925 6.2 Mentioned API requirement between ACP and clients leveraging 4926 adjacency table. 4928 6.3 Fixed TTL in GRASP example: msec, not hop-count!. 4930 6.8.2 MAYOR: expanded security/transport substrate text: 4932 Introduced term ACP GRASP virtual interface to explain how GRASP 4933 link-local multicast messages are encapsulated and replicated to 4934 neighbors. Explain how ACP knows when to use TLS vs. TCP (TCP only 4935 for link-local address (sockets). Introduced "ladder" picture to 4936 visualize stack. 4938 6.8.2.1 Expanded discussion/explanation of security model. TLS for 4939 GRASP unicsast connections across ACP is double encryption (plus 4940 underlying ACP secure channel), but highly necessary to avoid very 4941 simple man-in-the-middle attacks by compromised ACP members on-path. 4942 Ultimately, this is done to ensure that any apps using GRASP can get 4943 full end-to-end secrecy for information sent across GRASP. But for 4944 publically known ASA services, even this will not provide 100% 4945 security (this is discussed). Also why double encryption is the 4946 better/easier solution than trying to optimize this. 4948 6.10.1 Added discussion about pseudo-random addressing, scanning- 4949 attaacks (not an issue for ACP). 4951 6.12.2 New performance requirements section added. 4953 6.10.1 Added notion to first experiment with existing addressing 4954 schemes before defining new ones - we should be flexible enough. 4956 6.3/7.2 clarified the interactions between MLD and DULL GRASP and 4957 specified what needs to be done (e.g., in 2 switches doing ACP per L2 4958 port). 4960 12. Added explanations and cross-references to various security 4961 aspects of ACP discussed elsewhere in the document. 4963 13. Added IANA requirements. 4965 Added RFC2119 boilerplate. 4967 14.17. draft-ietf-anima-autonomic-control-plane-11 4969 Same text as -10 Unfortunately when uploading -10 .xml/.txt to 4970 datatracker, a wrong version of .txt got uploaded, only the .xml was 4971 correct. This impacts the -10 html version on datatra cker and the 4972 PDF versions as well. Because rfcdiff also compares the .txt 4973 version, this -11 version was crea ted so that one can compare 4974 changes from -09 and changes to the next version (-12). 4976 14.18. draft-ietf-anima-autonomic-control-plane-12 4978 Sheng Jiangs extensive review. Thanks! See Github file draft-ietf- 4979 anima-autonomic-control-plane/09-sheng-review-reply.txt for more 4980 details. Many of the larger changes listed below where inspired by 4981 the review. 4983 Removed the claim that the document is updating RFC4291,RFC4193 and 4984 the section detailling it. Done on suggestion of Michael Richardson 4985 - just try to describe use of addressing in a way that would not 4986 suggest a need claim update to architecture. 4988 Terminology cleanup: 4990 o Replaced "device" with "node" in text. Kept "device" only when 4991 referring to "physical node". Added definitions for those words. 4992 Includes changes of derived terms, especially in addressing: 4993 "Node-ID" and "Node-Number" in the addressing details. 4995 o Replaced term "autonomic FOOBAR" with "acp FOOBAR" as whereever 4996 appropriate: "autonomic" would imply that the node would need to 4997 support more than the ACP, but that is not correct in most of the 4998 cases. Wanted to make sure that implementers know they only need 4999 to support/implement ACP - unless stated otherwise. Includes 5000 "AN->ACP node", "AN->ACP adjacency table" and so on. 5002 1 Added explanation in the introduction about relationship between 5003 ACP, BRSKI, ANI and Autonomic Networks. 5005 6.1.1 Improved terminology and features of the certificate 5006 information field. Now called domain information field instead of 5007 ACP information field. The acp-address field in the domain 5008 information field is now optional, enabling easier introduction of 5009 various future options. 5011 6.1.2 Moved ACP domainer membership check from section 6.6 to (ACP 5012 secure channels setup) here because it is not only used for ACP 5013 secure channel setup. 5015 6.1.3 Fix text about certificate renewal after discussion with Max 5016 Pritikin/Michael Richardson/Brian Carpenter: 5018 o Version 10 erroneously assumed that the certificate itself could 5019 store a URL for renewal, but that is only possible for CRL URLs. 5020 Text now only refers to "remembered EST server" without implying 5021 that this is stored in the certificate. 5023 o Objective for RFC7030/EST domain certificate renewal was changed 5024 to "SRV.est" See also IANA section for explanation. 5026 o Removed detail of distance based service selection. This can be 5027 better done in future work because it would require a lot more 5028 detail for a good DNS-SD compatible approach. 5030 o Removed detail about trying to create more security by using ACP 5031 address from certificate of peer. After rethinking, this does not 5032 seem to buy additional security. 5034 6.10 Added reference to 6.12.5 in initial use of "loopback interface" 5035 in section 6.10 in result of email discussion michaelR/michaelB. 5037 10.2 Introduced informational section (diagnostics) because of 5038 operational experience - ACP/ANI undeployable without at least 5039 diagnostics like this. 5041 10.3 Introduced informational section (enabling/disabling) ACP. 5042 Important to discuss this for security reasons (e.g., why to never 5043 never auto-enable ANI on brownfield devices), for implementers and to 5044 answer ongoing questions during WG meetings about how to deal with 5045 shutdown interface. 5047 10.8 Added informational section discussing possible future 5048 variations of the ACP for potential adopters that cannot directly use 5049 the complete solution described in this document unmodified. 5051 14.19. draft-ietf-anima-autonomic-control-plane-13 5053 Swap author list (with permission). 5055 6.1.1. Eliminate blank lines in definition by making it a picture 5056 (reformatting only). 5058 6.10.3.1 New paragraph: Explained how nodes using Zone-ID != 0 need 5059 to use Zone-ID != 0 in GRASP so that we can avoid routing/forwarding 5060 of Zone-ID = 0 prefixes. 5062 Rest of feedback from review of -12, see 5063 https://raw.githubusercontent.com/anima-wg/autonomic-control- 5064 plane/master/draft-ietf-anima-autonomic-control-plane/12-feedback- 5065 reply.txt 5067 Review from Brian Carpenter: 5069 various: Autonomous -> autonomic(ally) in all remaining occurences. 5071 various: changed "manual (configured)" to "explicitly (configured)" 5072 to not exclude the option of (SDN controller) automatic configuration 5073 (no humans involved). 5075 1. Fixed reference to section 9. 5077 2. Added definition of loopback interface == internal interface. 5078 After discus on WG mailing lists, including 6man. 5080 6.1.2 Defined CDP/OCSP and pointed to RFC5280 for them. 5082 6.1.3 Removed "EST-TLS", no objective value needed or beneficial, 5083 added explanation paragraph why. 5085 6.2 Added to adjacency table the interface that a neighbor is 5086 discovered on. 5088 6.3 Simplified CDDL syntax: Only one method per AN_ACP objective 5089 (because of locators). Example with two objectives in GRASP message. 5091 6.8.1 Added note about link-local GRASP multicast message to avoid 5092 confusion. 5094 8.1.4 Added RFC8028 as recommended on hosts to better support VRF- 5095 select with ACP. 5097 8.2.1 Rewrote and Simplified CDDL for configured remote peer and 5098 explanations. Removed pattern option for remote peer. Not important 5099 enough to be mandated. 5101 Review thread started by William Atwood: 5103 2. Refined definition of VRF (vs. MPLS/VPN, LISP, VRF-LITE). 5105 2. Refined definition of ACP (ACP includes ACP GRASP instance). 5107 2. Added explanation for "zones" to terminology section and into 5108 Zone Addressing Sub Scheme section, relating it to RFC4007 zones 5109 (from Brian Carpenter). 5111 4. Fixed text for ACP4 requirement (Clients of the ACP must not be 5112 tied to specific protocol.). 5114 5. Fixed step 4. with proposed text. 5116 6.1.1 Included suggested explanation for rsub semantics. 5118 6.1.3 must->MUST for at least one EST server in ACP network to 5119 autonomically renew certs. 5121 6.7.2 normative: AND MUST NOT (permit weaker crypto options. 5123 6.7.1.1 also included text denying weaker IPsec profile options. 5125 6.8.2 Fixed description how to build ACP GRASP virtual interfaces. 5126 Added text that ACP continues to exist in absence of ACP neighbors. 5128 various: Make sure all "zone" words are used consistently. 5130 6.10.2/various: fixed 40 bit RFC4193 ULA prefix in all examples to 5131 89b714f3db (thanks MichaelR). 5133 6.10.1 Removed comment about assigned ULA addressing. Decision not 5134 to use it now ancient history of WG decision making process, not 5135 worth nothing anymore in the RFC. 5137 Review from Yongkang Zhang: 5139 6.10.5 Fixed length of Node-Numbers in ACP Vlong Addressing Sub- 5140 Scheme. 5142 14.20. draft-ietf-anima-autonomic-control-plane-14 5144 Disclaimer: All new text introduced by this revision provides only 5145 additional explanations/ details based on received reviews and 5146 analysis by the authors. No changes to beavior already specified in 5147 prior revisions. 5149 Joel Halpern, review part 3: 5151 Define/explain "ACP registrar" in reply to Joel Halpern review part 5152 3, resolving primarily 2 documentation issues:: 5154 1. Unclear how much ACP depends on BRSKI. ACP document was 5155 referring unqualified to registrars and Registrar-ID in the 5156 addressing section without explaining what a registrar is, 5157 leading to the assumption it must be a BRSKI Registrar. 5159 2. Unclear how the ACP addresses in ACP domain certificates are 5160 assigned because the BRSKI document does not defines this, but 5161 refers to this ACP document. 5163 Wrt. 1: ACP does NOT depend on BRSKI registrars, instead ANY 5164 appropriate automated or manual mechanism can be used to enroll ACP 5165 nodes with ACP domain certificates. This revision calls defines such 5166 mechanisms the "ACP registrar" and defines requirements. this is 5167 non-normative, because it does not define specific mechanisms that 5168 need to be support. In ANI devices, ACP Registrars are BRSKI 5169 Registrars. In non-ANI ACP networks, the registrar may simply be a 5170 person using CLI/web-interfaces to provision domain certificates and 5171 set the ACP address correctly in the ACP domain certificate. 5173 Wrt. 2.: The BRSKI document does rightfully not define how the ACP 5174 address assignment and creation of the ACP domain information field 5175 has to work because this is independent of BRSKI and needs to follow 5176 the same rules whatever protocol/mechanisms are used to implement an 5177 ACP Registrar. Another set of protocols that could be used instead 5178 of BRSKI is Netconf/Netconf-Call-Home, but such an alternative ACP 5179 Registrar solution would need to be speficied in it's own document. 5181 Additional text/sections had to be added to detail important 5182 conditions so that automatic certificate maintenance for ACP nodes 5183 (with BRSKI or other mechanisms) can be done in a way that as good as 5184 possible maintains ACP address information of ACP nodes across the 5185 nodes lifetime because that ACP address is intended as an identifier 5186 of the ACP node. 5188 Summary of sections added: 5190 o 6.1.3.5/6.1.3.6 (normative): re-enrollment of ACP nodes after 5191 certificate exiry/failure in a way that allows to maintain as much 5192 as possible ACP address information. 5194 o 6.10.7 (normative): defines "ACP Registrar" including requirements 5195 and how it can perform ACP address assignment. 5197 o 10.3 (informative): details / examples about registrars to help 5198 implementers and operators understand easier how they operate, and 5199 provide suggestion of models that a likely very ueful (sub-CA and/ 5200 or centralized policy manaement). 5202 o 10.4 (informative): Explains the need for the multiple address 5203 sub-spaces defined in response to discuss with Joel. 5205 Other changes: 5207 Updated references (RFC8366, RFC8368). 5209 Introduced sub-section headings for 6.1.3 (certificate maintenance) 5210 because section became too long with newly added sub-sections. Also 5211 some small text fixups/remove of duplicate text. 5213 Gen-ART review, Elwyn Davies: 5215 [RFC Editor: how can i raise the issue of problematic cross 5216 references of terms in the terminology section - rendering is 5217 problematic. ]. 5219 4. added explanation for ACP4 (finally). 5221 6.1.1 Simplified text in bullet list explaining rfc822 encoding. 5223 6.1.3 refined second paragraph defining remembering of previous EST 5224 server and explaiing how to do this with BRSKI. 5226 9.1 Added paragraph outlining the benefit of the sub-CA Registrar 5227 option for supporting partitioned networks. 5229 Roughly 100 more nits/minor fixes throughout the document. See: 5230 https://raw.githubusercontent.com/anima-wg/autonomic-control- 5231 plane/master/draft-ietf-anima-autonomic-control-plane/13-elwynd- 5232 reply.txt 5234 Joel Halpern, review part 2: 5236 6.1.1: added note about "+ +" format in address field when acp- 5237 address and rsub are empty. 5239 6.5.10 - clarified text about V bit in Vlong addressing scheme. 5241 6.10.3/6.10.4 - moved the Z bit field up front (directly after base 5242 scheme) and indicated more explicitly Z is part of selecting of the 5243 sub-addressing scheme. 5245 Refined text about reaching CRL Distribution Point, explain why 5246 address as indicator to use ACP. 5248 Note from Brian Carpenter: RFC Editor note for section reference into 5249 GRASP. 5251 IOT directorate review from Pascal Thubert: 5253 Various Nits/typos. 5255 TBD: Punted wish for mentioning RFC reference titles to RFC editor 5256 for now. 5258 1. Added section 1.1 - applicability, discussing protocol choices 5259 re. applicability to constrained devices (or not). Added notion of 5260 TCP/TLS va CoAP/DTLS to section 10.4 in support of this. 5262 2. Added in-band / out-of-band into terminology. 5264 5. Referenced section 8.2 for remote ACP channel configuration. 5266 6.3 made M_FLOOD periods RECOMMENDED (less guesswork) 5268 6.7.x Clarified conditional nature of MUST for the profile details of 5269 IPsec parameters (aka: onlt 6.7.3 defines actual MUST for nodes, 5270 prior notions only define the requirements for IPsec profiles IF 5271 IPsec is supported. 5273 6.8.1 Moved discussion about IP multicast, IGP, RPL for GRASP into a 5274 new subsection in the informative part (section 10) to tighten up 5275 text in normative part. 5277 6.10.1 added another reference to stable-connectivity for interop 5278 with IPv4 management. 5280 6.10.1 removed mentioning of ULA-Random, term was used in email 5281 discus of ULA with L=1, but term actually not defined in rfc4193, so 5282 mentioning it is just confusing/redundant. Also added note about the 5283 random hash being defined in this document, not using SHA1 from 5284 rfc4193. 5286 6.11.1.1 added suggested text about mechanisms to further reduce 5287 opportunities for loop during reconvergence (active signaling options 5288 from RFC6550). 5290 6.11.1.3 made mode 2 MUST and mode 2 MAY (RPL MOP - mode of 5291 operations). Removes ambiguity ambiguity. 5293 6.12.5 Added recommendation for RFC4429 (optimistic DAD). 5295 Nits from Benjamin Kaduk: dTLS -> DTLS: 5297 Review from Joel Halpern: 5299 1. swapped order of "purposes" for ACP to match order in section 3. 5301 1. Added notion about manageability of ACP gong beyond RFC7575 5302 (before discussion of stable connectivity). 5304 2. Changed definition of Intent to be same as reference model 5305 (policy lanuage instead of API). 5307 6.1.1 changed BNF specification so that a local-part without acp- 5308 address (for future extensions) would not be rfcSELF.+rsub but 5309 simpler rfcSELF+rsub. Added explanation why rsub is in local-part. 5311 Tried to eliminate unnecessary references to VRF to minimize 5312 assumption how system is designed. 5314 6.1.3 Explained how to make CDP reachable via ACP. 5316 6.7.2 Made it clearer that constrained devices MUST support DTLS if 5317 they can not support IPsec. 5319 6.8.2.1 clarified first paragraph (TCP restransmissions lightweight). 5321 6.11.1 fixed up RPL profile text - to remove "VRF". Text was also 5322 buggy. mentioned control plane, but its a forwarding/silicon issue to 5323 have these header. 5325 6.12.5 Clarified how link-local ACP channel address can be derived, 5326 and how not. 5328 8.2.1 Fixed up text to distinguish between configuration and model 5329 describing parameters of the configuration (spec only provides 5330 parameter model). 5332 Various Nits. 5334 14.21. draft-ietf-anima-autonomic-control-plane-15 5336 Only reshuffling and formatting changes, but wanted to allow 5337 reviewers later to easily compare -13 with -14, and these changes in 5338 -15 mess that up too much. 5340 increased TOC depth to 4. 5342 Separated and reordered section 10 into an operational and a 5343 background and futures section. The background and futures could 5344 also become appendices if the layout of appendices in RFC format 5345 wasn't so horrible that you really only want to avoid using them (all 5346 the way after a lot of text like references that stop most readers 5347 from proceeding any further). 5349 14.22. draft-ietf-anima-autonomic-control-plane-16 5351 Mirja Kuehlewind: 5353 Tightened requirements for ACP related GRASP objective timers. 5355 Better text to introduce/explaine baseline and constrained ACP 5356 profiles. 5358 IANA guideline: MUST only accept extensible last allocation for 5359 address sub-scheme. 5361 Moved section 11 into appendix. 5363 Warren Kumari: 5365 Removed "global routing table", replacced with "Data-Plane routing 5366 (and forwarding) tables. 5368 added text to indicate how routing protocols do like to have data- 5369 plane dependencies. 5371 Changed power consumption section re. admin-down state. Power needed 5372 to bring up such interfaces make t inappropriate to probe. Need to 5373 think more about best sugests -> beyond scope. 5375 Replaced "console" with out-of-band... (console/management ethernet). 5377 Various nits. 5379 Joel Halpern: 5381 Fixed up domain information field ABNF to eliminate confusion that 5382 rsub is not an FQDN but only a prefix to routing-subdomain. 5384 Corrected certcheck to separate out cert verification into lifetime 5385 validity and proof of ownership of private key. 5387 Fixed pagination for "ACP as security and transport substrate for 5388 GRASP" picture. 5390 14.23. draft-ietf-anima-autonomic-control-plane-17 5392 Review Alissa Cooper: 5394 Main discuss point fixed by untangling two specific node type cases: 5396 NOC nodes have ACP domain cert without acp-address field. Are ACP 5397 domain members, but can not build ACP secure channels (just end-to- 5398 end or nay other authentications. 5400 ACP nodes may have other methods to assign ACP address than getting 5401 it through the cert. This is indicated through new vlue 0 for acp- 5402 address in certificate. 5404 Accordingly modified texts in ABNF/explanation and Cert-Check 5405 section. 5407 Other: 5409 Better separation of normative text and considerations for "future" 5410 work: 5412 - Marked missing chapters as Informative. Reworded requirements 5413 section to indicate its informative nature, changed reqirements to 5414 _MUST_/_SHOULD_ to indicate these are not RFC2119 requirements but 5415 that this requirements section is really just in place of a separate 5416 solutions requirements document (that ANIMA was not allowed to 5417 produce). 5419 - removed ca. 20 instances of "futures" in normative part of 5420 document. 5422 - moved important instances of "futures" into new section A.10 (last 5423 section of appendix). These serve as reminder os work discussed 5424 dduring WG but not able to finish specifying it. 5426 Eliminated perception that "rsub" (routing subdomain) is only 5427 beneficial with future work. Example in A.7. 5429 Added RFC-editor note re formatting of references to terms defined in 5430 terminology section. 5432 Using now correct RFC 8174 boilerplate. 5434 Clarified semantic and use of manual ACP sub-scheme. Not used in 5435 certificates, only assigned via traditional methods. Use for ACP- 5436 connect subnets or the like. 5438 Corrected text about Data-Plane dependencies of ACP. Appropriate 5439 implementations can be fully data-plane independent (without more 5440 spec work) if not sharing link-local address with Data-Plane. 6.12.2 5441 text updated to discuss those (MAC address), A.10.2 discusses options 5442 that would require new standards work. 5444 Moved all text about Intent into A.8 to clearl mark it as futures. 5446 Changed suggestion of future insecure ACP option to future "end-to- 5447 end-security-only" option. 5449 Various textual fixes. 5451 Gen-ART review by Elwyn Davies: 5453 Some fixes also mentioned by Alissa. 5455 Added reference for OT. 5457 Fixed notion that secure channel is not only a security association. 5459 >20 good textual fixes. Thanks! 5461 Other: 5463 Added picture requested by Pascal Thubert about Dual-NOC (A.10.4). 5465 Moved RFC-editor request for better first RFC reference closer to the 5466 top of the document. 5468 Fixed typo /126 -> 127 for prefix length with zone address scheme. 5470 Overlooked early SecDir review from frank.xialiang@huawei.com: 5472 most issues fixed through other review in -16. Added reference to 5473 self-protection section 9.2 into security considerations section. 5475 15. References 5477 15.1. Normative References 5479 [I-D.ietf-anima-grasp] 5480 Bormann, C., Carpenter, B., and B. Liu, "A Generic 5481 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 5482 grasp-15 (work in progress), July 2017. 5484 [I-D.ietf-cbor-cddl] 5485 Birkholz, H., Vigano, C., and C. Bormann, "Concise data 5486 definition language (CDDL): a notational convention to 5487 express CBOR data structures", draft-ietf-cbor-cddl-03 5488 (work in progress), July 2018. 5490 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 5491 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 5492 . 5494 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 5495 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 5496 DOI 10.17487/RFC3810, June 2004, 5497 . 5499 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 5500 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 5501 November 2005, . 5503 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 5504 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 5505 . 5507 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 5508 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 5509 2006, . 5511 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 5512 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 5513 December 2005, . 5515 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 5516 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 5517 DOI 10.17487/RFC4861, September 2007, 5518 . 5520 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 5521 Address Autoconfiguration", RFC 4862, 5522 DOI 10.17487/RFC4862, September 2007, 5523 . 5525 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 5526 Specifications: ABNF", STD 68, RFC 5234, 5527 DOI 10.17487/RFC5234, January 2008, 5528 . 5530 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 5531 (TLS) Protocol Version 1.2", RFC 5246, 5532 DOI 10.17487/RFC5246, August 2008, 5533 . 5535 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 5536 Housley, R., and W. Polk, "Internet X.509 Public Key 5537 Infrastructure Certificate and Certificate Revocation List 5538 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 5539 . 5541 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 5542 DOI 10.17487/RFC5322, October 2008, 5543 . 5545 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 5546 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 5547 January 2012, . 5549 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 5550 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 5551 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 5552 Low-Power and Lossy Networks", RFC 6550, 5553 DOI 10.17487/RFC6550, March 2012, 5554 . 5556 [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing 5557 Protocol for Low-Power and Lossy Networks (RPL)", 5558 RFC 6552, DOI 10.17487/RFC6552, March 2012, 5559 . 5561 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 5562 Power and Lossy Networks (RPL) Option for Carrying RPL 5563 Information in Data-Plane Datagrams", RFC 6553, 5564 DOI 10.17487/RFC6553, March 2012, 5565 . 5567 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 5568 "Enrollment over Secure Transport", RFC 7030, 5569 DOI 10.17487/RFC7030, October 2013, 5570 . 5572 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 5573 Kivinen, "Internet Key Exchange Protocol Version 2 5574 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 5575 2014, . 5577 [RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support 5578 for Generic Routing Encapsulation (GRE)", RFC 7676, 5579 DOI 10.17487/RFC7676, October 2015, 5580 . 5582 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 5583 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 5584 May 2017, . 5586 15.2. Informative References 5588 [AR8021] IEEE SA-Standards Board, "IEEE Standard for Local and 5589 metropolitan area networks - Secure Device Identity", 5590 December 2009, . 5593 [I-D.ietf-anima-bootstrapping-keyinfra] 5594 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 5595 S., and K. Watsen, "Bootstrapping Remote Secure Key 5596 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 5597 keyinfra-16 (work in progress), June 2018. 5599 [I-D.ietf-anima-prefix-management] 5600 Jiang, S., Du, Z., Carpenter, B., and Q. Sun, "Autonomic 5601 IPv6 Edge Prefix Management in Large-scale Networks", 5602 draft-ietf-anima-prefix-management-07 (work in progress), 5603 December 2017. 5605 [I-D.ietf-anima-reference-model] 5606 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 5607 and J. Nobre, "A Reference Model for Autonomic 5608 Networking", draft-ietf-anima-reference-model-06 (work in 5609 progress), February 2018. 5611 [I-D.ietf-netconf-zerotouch] 5612 Watsen, K., Abrahamsson, M., and I. Farrer, "Zero Touch 5613 Provisioning for Networking Devices", draft-ietf-netconf- 5614 zerotouch-22 (work in progress), June 2018. 5616 [I-D.ietf-roll-applicability-template] 5617 Richardson, M., "ROLL Applicability Statement Template", 5618 draft-ietf-roll-applicability-template-09 (work in 5619 progress), May 2016. 5621 [I-D.ietf-roll-useofrplinfo] 5622 Robles, I., Richardson, M., and P. Thubert, "When to use 5623 RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll- 5624 useofrplinfo-23 (work in progress), May 2018. 5626 [IEEE-802.1X] 5627 IEEE SA-Standards Board, "IEEE Standard for Local and 5628 Metropolitan Area Networks: Port-Based Network Access 5629 Control", February 2010, 5630 . 5633 [LLDP] IEEE SA-Standards Board, "IEEE Standard for Local and 5634 Metropolitan Area Networks: Station and Media Access 5635 Control Connectivity Discovery", June 2016, 5636 . 5639 [MACSEC] IEEE SA-Standards Board, "IEEE Standard for Local and 5640 Metropolitan Area Networks: Media Access Control (MAC) 5641 Security", June 2006, 5642 . 5645 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 5646 RFC 1112, DOI 10.17487/RFC1112, August 1989, 5647 . 5649 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 5650 and E. Lear, "Address Allocation for Private Internets", 5651 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 5652 . 5654 [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax 5655 Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998, 5656 . 5658 [RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", 5659 RFC 2821, DOI 10.17487/RFC2821, April 2001, 5660 . 5662 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 5663 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 5664 DOI 10.17487/RFC4007, March 2005, 5665 . 5667 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 5668 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 5669 2006, . 5671 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 5672 for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, 5673 . 5675 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 5676 "Considerations for Internet Group Management Protocol 5677 (IGMP) and Multicast Listener Discovery (MLD) Snooping 5678 Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, 5679 . 5681 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 5682 Group Management Protocol Version 3 (IGMPv3) and Multicast 5683 Listener Discovery Protocol Version 2 (MLDv2) for Source- 5684 Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, 5685 August 2006, . 5687 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 5688 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 5689 . 5691 [RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol 5692 Independent Multicast (PIM)", RFC 4610, 5693 DOI 10.17487/RFC4610, August 2006, 5694 . 5696 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 5697 Extensions for Stateless Address Autoconfiguration in 5698 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 5699 . 5701 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 5702 DOI 10.17487/RFC5321, October 2008, 5703 . 5705 [RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet 5706 Group Management Protocol Version 3 (IGMPv3) and Multicast 5707 Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, 5708 DOI 10.17487/RFC5790, February 2010, 5709 . 5711 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 5712 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 5713 . 5715 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 5716 and A. Bierman, Ed., "Network Configuration Protocol 5717 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 5718 . 5720 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 5721 Cheshire, "Internet Assigned Numbers Authority (IANA) 5722 Procedures for the Management of the Service Name and 5723 Transport Protocol Port Number Registry", BCP 165, 5724 RFC 6335, DOI 10.17487/RFC6335, August 2011, 5725 . 5727 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 5728 "Default Address Selection for Internet Protocol Version 6 5729 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 5730 . 5732 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 5733 DOI 10.17487/RFC6762, February 2013, 5734 . 5736 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 5737 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 5738 . 5740 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 5741 Locator/ID Separation Protocol (LISP)", RFC 6830, 5742 DOI 10.17487/RFC6830, January 2013, 5743 . 5745 [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local 5746 Addressing inside an IPv6 Network", RFC 7404, 5747 DOI 10.17487/RFC7404, November 2014, 5748 . 5750 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 5751 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 5752 Defined Networking (SDN): Layers and Architecture 5753 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 5754 2015, . 5756 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 5757 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 5758 Networking: Definitions and Design Goals", RFC 7575, 5759 DOI 10.17487/RFC7575, June 2015, 5760 . 5762 [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap 5763 Analysis for Autonomic Networking", RFC 7576, 5764 DOI 10.17487/RFC7576, June 2015, 5765 . 5767 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 5768 Considerations for IPv6 Address Generation Mechanisms", 5769 RFC 7721, DOI 10.17487/RFC7721, March 2016, 5770 . 5772 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 5773 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 5774 Multicast - Sparse Mode (PIM-SM): Protocol Specification 5775 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 5776 2016, . 5778 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 5779 RFC 7950, DOI 10.17487/RFC7950, August 2016, 5780 . 5782 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 5783 Hosts in a Multi-Prefix Network", RFC 8028, 5784 DOI 10.17487/RFC8028, November 2016, 5785 . 5787 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 5788 Writing an IANA Considerations Section in RFCs", BCP 26, 5789 RFC 8126, DOI 10.17487/RFC8126, June 2017, 5790 . 5792 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 5793 "A Voucher Artifact for Bootstrapping Protocols", 5794 RFC 8366, DOI 10.17487/RFC8366, May 2018, 5795 . 5797 [RFC8368] Eckert, T., Ed. and M. Behringer, "Using an Autonomic 5798 Control Plane for Stable Connectivity of Network 5799 Operations, Administration, and Maintenance (OAM)", 5800 RFC 8368, DOI 10.17487/RFC8368, May 2018, 5801 . 5803 15.3. URIs 5805 [1] https://en.wikipedia.org/wiki/Operational_Technology 5807 [2] https://en.wikipedia.org/wiki/Single-root_input/ 5808 output_virtualization 5810 Appendix A. Background and Futures (Informative) 5812 The following sections discuss additional background information 5813 about aspects of the normative parts of this document or associated 5814 mechanisms such as BRSKI (such as why specific choices where made by 5815 the ACP) and they provide discussion about possble future variations 5816 of the ACP. 5818 A.1. ACP Address Space Schemes 5820 This document defines the Zone, Vlong and Manual sub address schemes 5821 primarily to support address prefix assignment via distributed, 5822 potentially uncoordinated ACP registrars as defined in 5823 Section 6.10.7. This costs 48/46 bit identifier so that these ACP 5824 registrar can assign non-conflicting address prefixes. This design 5825 does not leave enough bits to simultaneously support a large number 5826 of nodes (Node-ID) plus a large prefix of local addresses for every 5827 node plus a large enough set of bits to identify a routing Zone. In 5828 result, Zone, Vlong 8/16 attempt to support all features, but in via 5829 separate prefixes. 5831 In networks that always expect to rely on a centralized PMS as 5832 described above (Section 10.2.5), the 48/46 bits for the Registrar-ID 5833 could be saved. Such variations of the ACP addressing mecchanisms 5834 could be introduct through future work in different ways. If the 5835 prefix rfcSELF in the ACP information field was changed, incompatible 5836 ACP variations could be created where every design aspect of the ACP 5837 could be changed. Including all addressing choices. If instead a 5838 new addressing sub-type would be defined, it could be a backward 5839 compatible extension of this ACP specification. Information such as 5840 the size of a zone-prefix and the length of the prefix assigned to 5841 the ACP node itself could be encoded via the extension field of the 5842 ACP domain information. 5844 Note that an explicitly defined "Manual" addressing sub-scheme is 5845 always beneficial to provide an easy way for ACP nodes to prohibit 5846 incorrect manual configuration of any non-"Manual" ACP address spaces 5847 and therefore ensure hat "Manual" operations will never impact 5848 correct routing for any non-"Manual" ACP addresses assigned via ACP 5849 domain certificates. 5851 A.2. BRSKI Bootstrap (ANI) 5853 [I-D.ietf-anima-bootstrapping-keyinfra] (BRSKI) describes how nodes 5854 with an IDevID certificate can securely and zero-touch enroll with a 5855 domain certificate (LDevID) to support the ACP. BRSKI also leverages 5856 the ACP to enable zero-touch bootstrap of new nodes across networks 5857 without any configuration requirements across the transit nodes 5858 (e.g., no DHCP/DNS forwarding/server setup). This includes otherwise 5859 not configured networks as described in Section 3.2. Therefore BRSKI 5860 in conjunction with ACP provides for a secure and zero-touch 5861 management solution for complete networks. Nodes supporting such an 5862 infrastructure (BRSKI and ACP) are called ANI nodes (Autonomic 5863 Networking Infrastructure), see [I-D.ietf-anima-reference-model]. 5864 Nodes that do not support an IDevID but only an (insecure) vendor 5865 specific Unique Device Identifier (UDI) or nodes whose manufacturer 5866 does not support a MASA could use some future security reduced 5867 version of BRSKI. 5869 When BRSKI is used to provision a domain certificate (which is called 5870 enrollment), the BRSKI registrar (acting as an enhanced EST server) 5871 must include the subjectAltName / rfc822Name encoded ACP address and 5872 domain name to the enrolling node (called pledge) via its response to 5873 the pledges EST CSR Attribute request that is mandatory in BRSKI. 5875 The Certificate Authority in an ACP network must not change the 5876 subjectAltName / rfc822Name in the certificate. The ACP nodes can 5877 therefore find their ACP address and domain using this field in the 5878 domain certificate, both for themselves, as well as for other nodes. 5880 The use of BRSKI in conjunction with the ACP can also help to further 5881 simplify maintenance and renewal of domain certificates. Instead of 5882 relying on CRL, the lifetime of certificates can be made extremely 5883 small, for example in the order of hours. When a node fails to 5884 connect to the ACP within its certificate lifetime, it cannot connect 5885 to the ACP to renew its certificate across it (using just EST), but 5886 it can still renew its certificate as an "enrolled/expired pledge" 5887 via the BRSKI bootstrap proxy. This requires only that the BRSKI 5888 registrar honors expired domain certificates and that the pledge 5889 first attempts to perform TLS authentication for BRSKI bootstrap with 5890 its expired domain certificate - and only reverts to its IDevID when 5891 this fails. This mechanism could also render CRLs unnecessary 5892 because the BRSKI registrar in conjunction with the CA would not 5893 renew revoked certificates - only a "Do-not-renew" list would be 5894 necessary on BRSKI registrars/CA. 5896 In the absence of BRSKI or less secure variants thereof, provisioning 5897 of certificates may involve one or more touches or non-standardized 5898 automation. Node vendors usually support provisioning of 5899 certificates into nodes via PKCS#7 (see [RFC2315]) and may support 5900 this provisioning through vendor specific models via Netconf 5901 ([RFC6241]). If such nodes also support Netconf Zero-Touch 5902 ([I-D.ietf-netconf-zerotouch]) then this can be combined to zero- 5903 touch provisioning of domain certificates into nodes. Unless there 5904 are equivalent integration of Netconf connections across the ACP as 5905 there is in BRSKI, this combination would not support zero-touch 5906 bootstrap across a not configured network though. 5908 A.3. ACP Neighbor discovery protocol selection 5910 This section discusses why GRASP DULL was chosen as the discovery 5911 protocol for L2 adjacent candidate ACP neighbors. The contenders 5912 considered where GRASP, mDNS or LLDP. 5914 A.3.1. LLDP 5916 LLDP and Cisco's earlier Cisco Discovery Protocol (CDP) are example 5917 of L2 discovery protocols that terminate their messages on L2 ports. 5918 If those protocols would be chosen for ACP neighbor discovery, ACP 5919 neighbor discovery would therefore also terminate on L2 ports. This 5920 would prevent ACP construction over non-ACP capable but LLDP or CDP 5921 enabled L2 switches. LLDP has extensions using different MAC 5922 addresses and this could have been an option for ACP discovery as 5923 well, but the additional required IEEE standardization and definition 5924 of a profile for such a modified instance of LLDP seemed to be more 5925 work than the benefit of "reusing the existing protocol" LLDP for 5926 this very simple purpose. 5928 A.3.2. mDNS and L2 support 5930 Multicast DNNS (mDNS) [RFC6762] with DNS Service Discovery (DNS-SD) 5931 Resource Records (RRs) as defined in [RFC6763] is a key contender as 5932 an ACP discovery protocol. because it relies on link-local IP 5933 multicast, it does operates at the subnet level, and is also found in 5934 L2 switches. The authors of this document are not aware of mDNS 5935 implementation that terminate their mDNS messages on L2 ports instead 5936 of the subnet level. If mDNS was used as the ACP discovery mechanism 5937 on an ACP capable (L3)/L2 switch as outlined in Section 7, then this 5938 would be necessary to implement. It is likely that termination of 5939 mDNS messages could only be applied to all mDNS messages from such a 5940 port, which would then make it necessary to software forward any non- 5941 ACP related mDNS messages to maintain prior non-ACP mDNS 5942 functionality. Adding support for ACP into such L2 switches with 5943 mDNS could therefore create regression problems for prior mDNS 5944 functionality on those nodes. With low performance of software 5945 forwarding in many L2 switches, this could also make the ACP risky to 5946 support on such L2 switches. 5948 A.3.3. Why DULL GRASP 5950 LLDP was not considered because of the above mentioned issues. mDNS 5951 was not selected because of the above L2 mDNS considerations and 5952 because of the following additional points: 5954 If mDNS was not already existing in a node, it would be more work to 5955 implement than DULL GRASP, and if an existing implementation of mDNS 5956 was used, it would likely be more code space than a separate 5957 implementation of DULL GRASP or a shared implementation of DULL GRASP 5958 and GRASP in the ACP. 5960 A.4. Choice of routing protocol (RPL) 5962 This section motivates why RPL - "IPv6 Routing Protocol for Low-Power 5963 and Lossy Networks ([RFC6550] was chosen as the default (and in this 5964 specification only) routing protocol for the ACP. The choice and 5965 above explained profile was derived from a pre-standard 5966 implementation of ACP that was successfully deployed in operational 5967 networks. 5969 Requirements for routing in the ACP are: 5971 o Self-management: The ACP must build automatically, without human 5972 intervention. Therefore routing protocol must also work 5973 completely automatically. RPL is a simple, self-managing 5974 protocol, which does not require zones or areas; it is also self- 5975 configuring, since configuration is carried as part of the 5976 protocol (see Section 6.7.6 of [RFC6550]). 5978 o Scale: The ACP builds over an entire domain, which could be a 5979 large enterprise or service provider network. The routing 5980 protocol must therefore support domains of 100,000 nodes or more, 5981 ideally without the need for zoning or separation into areas. RPL 5982 has this scale property. This is based on extensive use of 5983 default routing. RPL also has other scalability improvements, 5984 such as selecting only a subset of peers instead of all possible 5985 ones, and trickle support for information synchronization. 5987 o Low resource consumption: The ACP supports traditional network 5988 infrastructure, thus runs in addition to traditional protocols. 5989 The ACP, and specifically the routing protocol must have low 5990 resource consumption both in terms of memory and CPU requirements. 5991 Specifically, at edge nodes, where memory and CPU are scarce, 5992 consumption should be minimal. RPL builds a destination-oriented 5993 directed acyclic graph (DODAG), where the main resource 5994 consumption is at the root of the DODAG. The closer to the edge 5995 of the network, the less state needs to be maintained. This 5996 adapts nicely to the typical network design. Also, all changes 5997 below a common parent node are kept below that parent node. 5999 o Support for unstructured address space: In the Autonomic 6000 Networking Infrastructure, node addresses are identifiers, and may 6001 not be assigned in a topological way. Also, nodes may move 6002 topologically, without changing their address. Therefore, the 6003 routing protocol must support completely unstructured address 6004 space. RPL is specifically made for mobile ad-hoc networks, with 6005 no assumptions on topologically aligned addressing. 6007 o Modularity: To keep the initial implementation small, yet allow 6008 later for more complex methods, it is highly desirable that the 6009 routing protocol has a simple base functionality, but can import 6010 new functional modules if needed. RPL has this property with the 6011 concept of "objective function", which is a plugin to modify 6012 routing behavior. 6014 o Extensibility: Since the Autonomic Networking Infrastructure is a 6015 new concept, it is likely that changes in the way of operation 6016 will happen over time. RPL allows for new objective functions to 6017 be introduced later, which allow changes to the way the routing 6018 protocol creates the DAGs. 6020 o Multi-topology support: It may become necessary in the future to 6021 support more than one DODAG for different purposes, using 6022 different objective functions. RPL allow for the creation of 6023 several parallel DODAGs, should this be required. This could be 6024 used to create different topologies to reach different roots. 6026 o No need for path optimization: RPL does not necessarily compute 6027 the optimal path between any two nodes. However, the ACP does not 6028 require this today, since it carries mainly non-delay-sensitive 6029 feedback loops. It is possible that different optimization 6030 schemes become necessary in the future, but RPL can be expanded 6031 (see point "Extensibility" above). 6033 A.5. ACP Information Distribution and multicast 6035 IP multicast is not used by the ACP because the ANI (Autonomic 6036 Networking Infrastructure) itself does not require IP multicast but 6037 only service announcement/discovery. Using IP multicast for that 6038 would have made it necessary to develop a zero-touch auto configuring 6039 solution for ASM (Any Source Multicast - the original form of IP 6040 multicast defined in [RFC1112]), which would be quite complex and 6041 difficult to justify. One aspect of complexity where no attempt at a 6042 solution has been described in IETF documents is the automatic- 6043 selection of routers that should be PIM Sparse Mode (PIM-SM) 6044 Rendezvous Points (RPs) (see [RFC7761]). The other aspects of 6045 complexity are the implementation of MLD ([RFC4604]), PIM-SM and 6046 Anycast-RP (see [RFC4610]). If those implementations already exist 6047 in a product, then they would be very likely tied to accelerated 6048 forwarding which consumes hardware resources, and that in return is 6049 difficult to justify as a cost of performing only service discovery. 6051 Some future ASA may need high performance in-network data 6052 replication. That is the case when the use of IP multicast is 6053 justified. Such an ASA can then use service discovery from ACP 6054 GRASP, and then they do not need ASM but only SSM (Source Specific 6055 Multicast, see [RFC4607]) for the IP multicast replication. SSM 6056 itself can simply be enabled in the Data-Plane (or even in an update 6057 to the ACP) without any other configuration than just enabling it on 6058 all nodes and only requires a simpler version of MLD (see [RFC5790]). 6060 LSP (Link State Protocol) based IGP routing protocols typically have 6061 a mechanism to flood information, and such a mechanism could be used 6062 to flood GRASP objectives by defining them to be information of that 6063 IGP. This would be a possible optimization in future variations of 6064 the ACP that do use an LSP routing protocol. Note though that such a 6065 mechanism would not work easily for GRASP M_DISCOVERY messages which 6066 are intelligently (constrained) flooded not across the whole ACP, but 6067 only up to a node where a responder is found. We do expect that many 6068 future services in ASA will have only few consuming ASA, and for 6069 those cases, M_DISCOVERY is the more efficient method than flooding 6070 across the whole domain. 6072 Because the ACP uses RPL, one desirable future extension is to use 6073 RPLs existing notion of loop-free distribution trees (DODAG) to make 6074 GRASPs flooding more efficient both for M_FLOOD and M_DISCOVERY) See 6075 Section 6.12.5 how this will be specifically beneficial when using 6076 NBMA interfaces. This is not currently specified in this document 6077 because it is not quite clear yet what exactly the implications are 6078 to make GRASP flooding depend on RPL DODAG convergence and how 6079 difficult it would be to let GRASP flooding access the DODAG 6080 information. 6082 A.6. Extending ACP channel negotiation (via GRASP) 6084 The mechanism described in the normative part of this document to 6085 support multiple different ACP secure channel protocols without a 6086 single network wide MTI protocol is important to allow extending 6087 secure ACP channel protocols beyond what is specified in this 6088 document, but it will run into problem if it would be used for 6089 multiple protocols: 6091 The need to potentially have multiple of these security associations 6092 even temporarily run in parallel to determine which of them works 6093 best does not support the most lightweight implementation options. 6095 The simple policy of letting one side (Alice) decide what is best may 6096 not lead to the mutual best result. 6098 The two limitations can easier be solved if the solution was more 6099 modular and as few as possible initial secure channel negotiation 6100 protocols would be used, and these protocols would then take on the 6101 responsibility to support more flexible objectives to negotiate the 6102 mutually preferred ACP security channel protocol. 6104 IKEv2 is the IETF standard protocol to negotiate network security 6105 associations. It is meant to be extensible, but it is unclear 6106 whether it would be feasible to extend IKEv2 to support possible 6107 future requirements for ACP secure channel negotiation: 6109 Consider the simple case where the use of native IPsec vs. IPsec via 6110 GRE is to be negotiated and the objective is the maximum throughput. 6111 Both sides would indicate some agreed upon performance metric and the 6112 preferred encapsulation is the one with the higher performance of the 6113 slower side. IKEv2 does not support negotiation with this objective. 6115 Consider DTLS and some form of MacSec are to be added as negotiation 6116 options - and the performance objective should work across all IPsec, 6117 dDTLS and MacSec options. In the case of MacSEC, the negotiation 6118 would also need to determine a key for the peering. It is unclear if 6119 it would be even appropriate to consider extending the scope of 6120 negotiation in IKEv2 to those cases. Even if feasible to define, it 6121 is unclear if implementations of IKEv2 would be eager to adopt those 6122 type of extension given the long cycles of security testing that 6123 necessarily goes along with core security protocols such as IKEv2 6124 implementations. 6126 A more modular alternative to extending IKEv2 could be to layer a 6127 modular negotiation mechanism on top of the multitude of existing or 6128 possible future secure channel protocols. For this, GRASP over TLS 6129 could be considered as a first ACP secure channel negotiation 6130 protocol. The following are initial considerations for such an 6131 approach. A full specification is subject to a separate document: 6133 To explicitly allow negotiation of the ACP channel protocol, GRASP 6134 over a TLS connection using the GRASP_LISTEN_PORT and the nodes and 6135 peers link-local IPv6 address is used. When Alice and Bob support 6136 GRASP negotiation, they do prefer it over any other non-explicitly 6137 negotiated security association protocol and should wait trying any 6138 non-negotiated ACP channel protocol until after it is clear that 6139 GRASP/TLS will not work to the peer. 6141 When Alice and Bob successfully establish the GRASP/TSL session, they 6142 will negotiate the channel mechanism to use using objectives such as 6143 performance and perceived quality of the security. After agreeing on 6144 a channel mechanism, Alice and Bob start the selected Channel 6145 protocol. Once the secure channel protocol is successfully running, 6146 the GRASP/TLS connection can be kept alive or timed out as long as 6147 the selected channel protocol has a secure association between Alice 6148 and Bob. When it terminates, it needs to be re-negotiated via GRASP/ 6149 TLS. 6151 Notes: 6153 o Negotiation of a channel type may require IANA assignments of code 6154 points. 6156 o TLS is subject to reset attacks, which IKEv2 is not. Normally, 6157 ACP connections (as specified in this document) will be over link- 6158 local addresses so the attack surface for this one issue in TCP 6159 should be reduced (note that this may not be true when ACP is 6160 tunneled as described in Section 8.2.2. 6162 o GRASP packets received inside a TLS connection established for 6163 GRASP/TLS ACP negotiation are assigned to a separate GRASP domain 6164 unique to that TLS connection. 6166 A.7. CAs, domains and routing subdomains 6168 There is a wide range of setting up different ACP solution by 6169 appropriately using CAs and the domain and rsub elements in the 6170 domain information field of the domain certificate. We summarize 6171 these options here as they have been explained in different parts of 6172 the document in before and discuss possible and desirable extensions: 6174 An ACP domain is the set of all ACP nodes using certificates from the 6175 same CA using the same domain field. GRASP inside the ACP is run 6176 across all transitively connected ACP nodes in a domain. 6178 The rsub element in the domain information field permits the use of 6179 addresses from different ULA prefixes. One use case is to create 6180 multiple physical networks that initially may be separated with one 6181 ACP domain but different routing subdomains, so that all nodes can 6182 mutual trust their ACP domain certificates (not depending on rsub) 6183 and so that they could connect later together into a contiguous ACP 6184 network. 6186 One instance of such a use case is an ACP for regions interconnected 6187 via a non-ACP enabled core, for example due to the absence of product 6188 support for ACP on the core nodes. ACP connect configurations as 6189 defined in this document can be used to extend and interconnect those 6190 ACP islands to the NOC and merge them into a single ACP when later 6191 that product support gap is closed. 6193 Note that RPL scales very well. It is not necessary to use multiple 6194 routing subdomains to scale ACP domains in a way it would be possible 6195 if other routing protocols where used. They exist only as options 6196 for the above mentioned reasons. 6198 If different ACP domains are to be created that should not allow to 6199 connect to each other by default, these ACP domains simply need to 6200 have different domain elements in the domain information field. 6201 These domain elements can be arbitrary, including subdomains of one 6202 another: Domains "example.com" and "research.example.com" are 6203 separate domains if both are domain elements in the domain 6204 information element of certificates. 6206 It is not necessary to have a separate CA for different ACP domains: 6207 an operator can use a single CA to sign certificates for multiple ACP 6208 domains that are not allowed to connect to each other because the 6209 checks for ACP adjacencies includes comparison of the domain part. 6211 If multiple independent networks choose the same domain name but had 6212 their own CA, these would not form a single ACP domain because of CA 6213 mismatch. Therefore there is no problem in choosing domain names 6214 that are potentially also used by others. Nevertheless it is highly 6215 recommended to use domain names that one can have high probability to 6216 be unique. It is recommended to use domain names that start with a 6217 DNS domain names owned by the assigning organization and unique 6218 within it. For example "acp.example.com" if you own "example.com". 6220 A.8. Intent for the ACP 6222 Intent is the architecture component of autonomic networks according 6223 to [I-D.ietf-anima-reference-model] that allows operators to issue 6224 policies to the network. In a simple instance, Intent could simply 6225 be policies flooded across ACP GRASP and interpreted on every ACP 6226 node. 6228 One concern for future definitions of Intent solutions is the problem 6229 of circular dependencies when expressing Intent policies about the 6230 ACP itself. 6232 For example, Intent could indicate the desire to build an ACP across 6233 all domains that have a common parent domain (without relying on the 6234 rsub/routing-subdomain solution defined in this document). For 6235 example ACP nodes with domain "example.com", nodes of "example.com", 6236 "access.example.com", "core.example.com" and "city.core.example.com" 6237 should all establish one single ACP. 6239 If each domain has its own source of Intent, then the Intent would 6240 simply have to allow adding the peer domains trust anchors (CA) and 6241 domain names to the ACP domain membership check (Section 6.1.2) so 6242 that nodes from those other nodes are accepted as ACP peers. 6244 If this Intent was to be originated only from one domain, it could 6245 likely not be made to work because the other domains will not build 6246 any ACP connection amongst each other, whether they use the same or 6247 different CA due to the ACP domain membership check. 6249 If the domains use the same CA one could change the ACP setup to 6250 permit for the ACP to be established between the two ACP nodes even 6251 when the acp-domain-names of the peers are different, but only for 6252 the purpose of disseminating limited information, such as Intent, but 6253 not to set up full ACP connectivity, specifically not RPL routing and 6254 passing of arbitrary GRASP information. Unless the Intent policies 6255 permit this to happen across domain boundaries. 6257 This type of approach where the ACP first allows Intent to operate 6258 and only then sets up the rest of ACP connectivity based on Intent 6259 policy could also be used to enable Intent policies that would limit 6260 functionality across the ACP inside a domain, as long as no policy 6261 would disturb the operations of Intent. For example to limit 6262 reachability across the ACP to certain type of nodes or locations of 6263 nodes. 6265 A.9. Adopting ACP concepts for other environments 6267 The ACP as specified in this document is very explicit about the 6268 choice of options to allow interoperable implementations. The 6269 choices made may not be the best for all environments, but the 6270 concepts used by the ACP can be used to build derived solutions: 6272 The ACP specifies the use of ULA and deriving its prefix from the 6273 domain name so that no address allocation is required to deploy the 6274 ACP. The ACP will equally work not using ULA but any other /48 IPv6 6275 prefix. This prefix could simply be a configuration of the ACP 6276 registrars (for example when using BRSKI) to enroll the domain 6277 certificates - instead of the ACP registrar deriving the /48 ULA 6278 prefix from the AN domain name. 6280 Some solutions may already have an auto-addressing scheme, for 6281 example derived from existing unique device identifiers (e.g., MAC 6282 addresses). In those cases it may not be desirable to assign 6283 addresses to devices via the ACP address information field in the way 6284 described in this document. The certificate may simply serve to 6285 identify the ACP domain, and the address field could be empty/unused. 6286 The only fix required in the remaining way the ACP operate is to 6287 define another element in the domain certificate for the two peers to 6288 decide who is Alice and who is Bob during secure channel building. 6290 Note though that future work may leverage the acp address to 6291 authenticate "ownership" of the address by the device. If the 6292 address used by a device is derived from some pre-existing permanent 6293 local ID (such as MAC address), then it would be useful to store that 6294 address in the certificate using the format of the access address 6295 information field or in a similar way. 6297 The ACP is defined as a separate VRF because it intends to support 6298 well managed networks with a wide variety of configurations. 6299 Therefore, reliable, configuration-indestructible connectivity cannot 6300 be achieved from the Data-Plane itself. In solutions where all 6301 transit connectivity impacting functions are fully automated 6302 (including security), indestructible and resilient, it would be 6303 possible to eliminate the need for the ACP to be a separate VRF. 6304 Consider the most simple example system in which there is no separate 6305 Data-Plane, but the ACP is the Data-Plane. Add BRSKI, and it becomes 6306 a fully autonomic network - except that it does not support automatic 6307 addressing for user equipment. This gap can then be closed for 6308 example by adding a solution derived from 6309 [I-D.ietf-anima-prefix-management]. 6311 TCP/TLS as the protocols to provide reliability and security to GRASP 6312 in the ACP may not be the preferred choice in constrained networks. 6313 For example, CoAP/DTLS (Constrained Application Protocol) may be 6314 preferred where they are already used, allowing to reduce the 6315 additional code space footprint for the ACP on those devices. 6316 Because the transport for GRASP is not only hop-by-hop, but end-to- 6317 end across the ACP, this would require the definition of an 6318 incompatible variant of the ACP. Non-constrained devices could 6319 support both variants (the ACP as defined here, and one using CoAP/ 6320 DTLS for GRASP), and the variant used in a deployment could be chosen 6321 for example through a parameter of the domain certificate. 6323 The routing protocol chosen by the ACP design (RPL) does explicitly 6324 not optimize for shortest paths and fastest convergence. Variations 6325 of the ACP may want to use a different routing protocol or introduce 6326 more advanced RPL profiles. 6328 Variations such as what routing protocol to use, or whether to 6329 instantiate an ACP in a VRF or (as suggested above) as the actual 6330 Data-Plane, can be automatically chosen in implementations built to 6331 support multiple options by deriving them from future parameters in 6332 the certificate. Parameters in certificates should be limited to 6333 those that would not need to be changed more often than certificates 6334 would need to be updated anyhow; Or by ensuring that these parameters 6335 can be provisioned before the variation of an ACP is activated in a 6336 node. Using BRSKI, this could be done for example as additional 6337 follow-up signaling directly after the certificate enrollment, still 6338 leveraging the BRSKI TLS connection and therefore not introducing any 6339 additional connectivity requirements. 6341 Last but not least, secure channel protocols including their 6342 encapsulation are easily added to ACP solutions. ACP hop-by-hop 6343 network layer secure channels could also be replaced by end-to-end 6344 security plus other means for infrastructure protection. Any future 6345 network OAM should always use end-to-end security anyhow and can 6346 leverage the domain certificates and is therefore not dependent on 6347 security to be provided for by ACP secure channels. 6349 A.10. Further options / futures 6351 A.10.1. Auto-aggregation of routes 6353 Routing in the ACP according to this specification only leverages the 6354 standard RPL mechanism of route optimization, e.g. keeping only 6355 routes that are not towards the RPL root. This is known to scale to 6356 networks with 20,000 or more nodes. There is no auto-aggregation of 6357 routes for /48 ULA prefixes (when using rsub in the domain 6358 information field) and/or Zone-ID based prefixes. 6360 Automatic assignment of Zone-ID and auto-aggregation of routes could 6361 be achieved for example by configuring zone-boundaries, announcing 6362 via GRASP into the zones the zone parameters (zone-ID and /48 ULA 6363 prefix) and auto-aggrating routes on the zone-boundaries. Nodes 6364 would assign their Zone-ID and potentially even /48 prefix based on 6365 the GRASP announcements. 6367 A.10.2. More options for avoiding IPv6 Data-Plane dependency 6369 As described in Section 6.12.2, the ACP depends on the Data-Plane to 6370 establish IPv6 link-local addressing on interfaces. Using a separate 6371 MAC address for the ACP allows to fully isolate the ACP from the data 6372 plane in a way that is compatible with this specification. It is 6373 also an ideal option when using Single-root input/output 6374 virtualization (SR-IOV) in an implementation to isolate the ACP 6375 (https://en.wikipedia.org/wiki/Single-root_input/ 6376 output_virtualization [2]) because different SR-IOV interfaces use 6377 different MAC addresses. 6379 When additional MAC address(es) are not available to the ACP, 6380 separation of the ACP could be done at different demux points. The 6381 same subnet interface could have a separate IPv6 IPv6 interface for 6382 the ACP and Data-Plane and therefore separate link-local addresses 6383 for both, where the ACP interface is non-configurable on the data- 6384 plane. This too would be compatible with this specification and not 6385 impact interoperability. 6387 An option that would require additional specification is to use a 6388 different Ethertype from 0x86DD (IPv6) to encapsulate IPv6 packets 6389 for the ACP. This would be a similar approach as used for IP 6390 authentication packets in [IEEE-802.1X] that they use the Extensible 6391 Authentication Protocol over Local Area Network (EAPoL) ethertype 6392 (0x88A2). 6394 Note that in the case of ANI nodes, all the above considerations 6395 equally apply to the encapsulation of BRSKI packets including GRASP 6396 used for BRSKI. 6398 A.10.3. ACP APIs and operational models (YANG) 6400 Future work should define YANG ([RFC7950]) data model and/or node 6401 internal APIs to monitor and manage the ACP. 6403 The elements to include into this model/API include the ACP Adjacency 6404 Table (Section 6.2) and ACP GRASP. 6406 A.10.4. RPL enhancements 6408 ..... USA ...... ..... Europe ...... 6410 NOC1 NOC2 6411 | | 6412 | metric 100 | 6413 ACP1 --------------------------- ACP2 . 6414 | | . WAN 6415 | metric 10 metric 20 | . Core 6416 | | . 6417 ACP3 --------------------------- ACP4 . 6418 | metric 100 | 6419 | | . 6420 | | . Sites 6421 ACP10 ACP11 . 6423 Figure 16: Dual NOC 6425 The profile for RPL specified in this document builds only one 6426 spanning-tree pathset to a root (NOC). In the presence of multiple 6427 NOCs, routing toward the non-root NOCs may be suboptimal. Figure 16 6428 shows an extreme example. Assuming that node ACP1 becomes the RPL 6429 root, traffic between ACP11 and NOC2 will pass through 6430 ACP4-ACP3-ACP1-ACP2 instead of ACP4-ACP2 because the RPL calculated 6431 DODAG/routes are shortest paths towards the RPL root. 6433 To overcome these limitations, extensions/modifications to the RPL 6434 profile can provide optimality for multiple NOCs. This requires 6435 utilizing Data-Plane artifact including IPinIP encap/decap on ACP 6436 routers and processing of IPv6 RPI headers. Alternatively, (Src,Dst) 6437 routing table entries could be used. 6439 Flooding of ACP GRASP messages can be further constrained and 6440 therefore optimized by flooding only via links that are part of the 6441 RPL DODAG. 6443 A.10.5. Role assignments 6445 ACP connect is an explicit mechanism to "leak" ACP traffic explicitly 6446 (for example in a NOC). It is therefore also a possible security gap 6447 when it is easy to enable ACP connect on arbitrary compromised ACP 6448 nodes. 6450 One simple solution is to define an extension in the ACP certificates 6451 ACP information field indicating the permission for ACP connect to be 6452 configured on that ACP node. This could similarily be done to decide 6453 whether a node is permitted to be a registrar or not. 6455 Tying the permitted "roles" of an ACP node to the ACP domain 6456 certificate provides fairly strong protection against 6457 misconfiguration, but is still subject to code modifications. 6459 Another interesting role to assign to certificates is that of a NOC 6460 node. This would allow to limit certain type of connections such as 6461 OAM TLS connections to only NOC initiator or responders. 6463 A.10.6. Autonomic L3 transit 6465 In this specification, the ACP can only establish autonomic 6466 connectivity across L2 hops and only explicitly confiured options to 6467 tunnel across L3. Future work should specify mechanisms to 6468 automatically tunnel ACP across L3 networks. A hub&spoke option 6469 would allow to tunnel across the Internet to a cloud or central 6470 instance of the ACP, a peer-to-peer tunneling mechanism could tunnel 6471 ACP islands across an L3VPN infrastructure. 6473 A.10.7. Diagnostics 6475 Section 10.1 describes diagnostics options that can be done without 6476 changing the external, interoperability affecting characteristics of 6477 ACP implementation. 6479 Even better diagnostics of ACP operations is possible with additional 6480 signaling extensions, such as: 6482 1. Consider if LLDP should be a recommended functionality for ANI 6483 devices to improve diagnostics, and if so, which information 6484 elements it should signal (insecure). Includes potentially new 6485 information elements. 6487 2. In alternative to LLDP, A DULL GRASP diagnostics objective could 6488 be defined to carry these information elements. 6490 3. The IDevID of BRSKI pledges should be included in the selected 6491 insecure diagnostics option. 6493 4. A richer set of diagnostics information should be made available 6494 via the secured ACP channels, using either single-hop GRASP or 6495 network wide "topology discovery" mechanisms. 6497 Authors' Addresses 6499 Toerless Eckert (editor) 6500 Huawei USA - Futurewei Technologies Inc. 6501 2330 Central Expy 6502 Santa Clara 95050 6503 USA 6505 Email: tte+ietf@cs.fau.de 6507 Michael H. Behringer (editor) 6509 Email: michael.h.behringer@gmail.com 6511 Steinthor Bjarnason 6512 Arbor Networks 6513 2727 South State Street, Suite 200 6514 Ann Arbor MI 48104 6515 United States 6517 Email: sbjarnason@arbor.net