idnits 2.17.1 draft-ietf-anima-autonomic-control-plane-19.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 11 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 1104 has weird spacing: '... called rfcS...' == Line 1983 has weird spacing: '...k-local unic...' == Line 1984 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 (March 11, 2019) is 1866 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 440, but not defined -- Looks like a reference, but probably isn't: '1' on line 6400 == Missing Reference: 'RFC2119' is mentioned on line 706, but not defined -- Looks like a reference, but probably isn't: '2' on line 6969 -- Looks like a reference, but probably isn't: '3' on line 1743 -- Looks like a reference, but probably isn't: '5' on line 1749 -- Looks like a reference, but probably isn't: '9' on line 1760 -- Looks like a reference, but probably isn't: '13' on line 1776 == Missing Reference: 'ACP VRF' is mentioned on line 3265, but not defined == Missing Reference: 'Data-Plane' is mentioned on line 3267, but not defined == Missing Reference: 'Select' is mentioned on line 3414, but not defined == Missing Reference: 'Plane' is mentioned on line 3416, but not defined == Unused Reference: 'RFC1034' is defined on line 5995, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-applicability-template' is defined on line 6144, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-cbor-cddl-07 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-11) exists of draft-ietf-acme-star-05 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-18 == Outdated reference: A later version (-44) exists of draft-ietf-roll-useofrplinfo-24 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-30 -- Obsolete informational reference (is this intentional?): RFC 1886 (Obsoleted by RFC 3596) -- Obsolete informational reference (is this intentional?): RFC 2821 (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 3164 (Obsoleted by RFC 5424) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- 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: 3 errors (**), 0 flaws (~~), 19 warnings (==), 13 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: September 12, 2019 6 S. Bjarnason 7 Arbor Networks 8 March 11, 2019 10 An Autonomic Control Plane (ACP) 11 draft-ietf-anima-autonomic-control-plane-19 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 provides automatically 23 configured hop-by-hop authenticated and encrypted communications via 24 automatically configured IPv6 even when the network is not 25 configured, or misconfigured. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 12, 2019. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction (Informative) . . . . . . . . . . . . . . . . . 5 62 1.1. Applicability and Scope . . . . . . . . . . . . . . . . . 8 63 2. Acronyms and Terminology (Informative) . . . . . . . . . . . 9 64 3. Use Cases for an Autonomic Control Plane (Informative) . . . 15 65 3.1. An Infrastructure for Autonomic Functions . . . . . . . . 15 66 3.2. Secure Bootstrap over a not configured Network . . . . . 16 67 3.3. Data-Plane Independent Permanent Reachability . . . . . . 16 68 4. Requirements (Informative) . . . . . . . . . . . . . . . . . 17 69 5. Overview (Informative) . . . . . . . . . . . . . . . . . . . 18 70 6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 20 71 6.1. ACP Domain, Certificate and Network . . . . . . . . . . . 20 72 6.1.1. Certificate ACP Domain Information Field . . . . . . 21 73 6.1.2. ACP domain membership check . . . . . . . . . . . . . 24 74 6.1.3. Trust Points and Trust Anchors . . . . . . . . . . . 26 75 6.1.4. Certificate and Trust Point Maintenance . . . . . . . 27 76 6.1.4.1. GRASP objective for EST server . . . . . . . . . 27 77 6.1.4.2. Renewal . . . . . . . . . . . . . . . . . . . . . 29 78 6.1.4.3. Certificate Revocation Lists (CRLs) . . . . . . . 29 79 6.1.4.4. Lifetimes . . . . . . . . . . . . . . . . . . . . 30 80 6.1.4.5. Re-enrollment . . . . . . . . . . . . . . . . . . 30 81 6.1.4.6. Failing Certificates . . . . . . . . . . . . . . 31 82 6.2. ACP Adjacency Table . . . . . . . . . . . . . . . . . . . 32 83 6.3. Neighbor Discovery with DULL GRASP . . . . . . . . . . . 33 84 6.4. Candidate ACP Neighbor Selection . . . . . . . . . . . . 36 85 6.5. Channel Selection . . . . . . . . . . . . . . . . . . . . 36 86 6.6. Candidate ACP Neighbor verification . . . . . . . . . . . 39 87 6.7. Security Association protocols . . . . . . . . . . . . . 39 88 6.7.1. ACP via IKEv2 . . . . . . . . . . . . . . . . . . . . 39 89 6.7.1.1. Native IPsec . . . . . . . . . . . . . . . . . . 39 90 6.7.1.2. IPsec with GRE encapsulation . . . . . . . . . . 40 91 6.7.2. ACP via DTLS . . . . . . . . . . . . . . . . . . . . 40 92 6.7.3. ACP Secure Channel Requirements . . . . . . . . . . . 41 93 6.8. GRASP in the ACP . . . . . . . . . . . . . . . . . . . . 42 94 6.8.1. GRASP as a core service of the ACP . . . . . . . . . 42 95 6.8.2. ACP as the Security and Transport substrate for GRASP 42 96 6.8.2.1. Discussion . . . . . . . . . . . . . . . . . . . 45 98 6.9. Context Separation . . . . . . . . . . . . . . . . . . . 46 99 6.10. Addressing inside the ACP . . . . . . . . . . . . . . . . 47 100 6.10.1. Fundamental Concepts of Autonomic Addressing . . . . 47 101 6.10.2. The ACP Addressing Base Scheme . . . . . . . . . . . 48 102 6.10.3. ACP Zone Addressing Sub-Scheme . . . . . . . . . . . 50 103 6.10.3.1. Usage of the Zone-ID Field . . . . . . . . . . . 51 104 6.10.4. ACP Manual Addressing Sub-Scheme . . . . . . . . . . 52 105 6.10.5. ACP Vlong Addressing Sub-Scheme . . . . . . . . . . 53 106 6.10.6. Other ACP Addressing Sub-Schemes . . . . . . . . . . 54 107 6.10.7. ACP Registrars . . . . . . . . . . . . . . . . . . . 55 108 6.10.7.1. Use of BRSKI or other Mechanism/Protocols . . . 55 109 6.10.7.2. Unique Address/Prefix allocation . . . . . . . . 56 110 6.10.7.3. Addressing Sub-Scheme Policies . . . . . . . . . 56 111 6.10.7.4. Address/Prefix Persistence . . . . . . . . . . . 57 112 6.10.7.5. Further Details . . . . . . . . . . . . . . . . 58 113 6.11. Routing in the ACP . . . . . . . . . . . . . . . . . . . 58 114 6.11.1. RPL Profile . . . . . . . . . . . . . . . . . . . . 58 115 6.11.1.1. Overview . . . . . . . . . . . . . . . . . . . . 58 116 6.11.1.2. RPL Instances . . . . . . . . . . . . . . . . . 60 117 6.11.1.3. Storing vs. Non-Storing Mode . . . . . . . . . . 60 118 6.11.1.4. DAO Policy . . . . . . . . . . . . . . . . . . . 60 119 6.11.1.5. Path Metric . . . . . . . . . . . . . . . . . . 60 120 6.11.1.6. Objective Function . . . . . . . . . . . . . . . 61 121 6.11.1.7. DODAG Repair . . . . . . . . . . . . . . . . . . 61 122 6.11.1.8. Multicast . . . . . . . . . . . . . . . . . . . 61 123 6.11.1.9. Security . . . . . . . . . . . . . . . . . . . . 61 124 6.11.1.10. P2P communications . . . . . . . . . . . . . . . 61 125 6.11.1.11. IPv6 address configuration . . . . . . . . . . . 61 126 6.11.1.12. Administrative parameters . . . . . . . . . . . 62 127 6.11.1.13. RPL Data-Plane artifacts . . . . . . . . . . . . 62 128 6.11.1.14. Unknown Destinations . . . . . . . . . . . . . . 62 129 6.12. General ACP Considerations . . . . . . . . . . . . . . . 62 130 6.12.1. Performance . . . . . . . . . . . . . . . . . . . . 63 131 6.12.2. Addressing of Secure Channels . . . . . . . . . . . 63 132 6.12.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . 63 133 6.12.4. Multiple links between nodes . . . . . . . . . . . . 64 134 6.12.5. ACP interfaces . . . . . . . . . . . . . . . . . . . 64 135 7. ACP support on L2 switches/ports (Normative) . . . . . . . . 67 136 7.1. Why (Benefits of ACP on L2 switches) . . . . . . . . . . 67 137 7.2. How (per L2 port DULL GRASP) . . . . . . . . . . . . . . 68 138 8. Support for Non-ACP Components (Normative) . . . . . . . . . 70 139 8.1. ACP Connect . . . . . . . . . . . . . . . . . . . . . . . 70 140 8.1.1. Non-ACP Controller / NMS system . . . . . . . . . . . 70 141 8.1.2. Software Components . . . . . . . . . . . . . . . . . 72 142 8.1.3. Auto Configuration . . . . . . . . . . . . . . . . . 73 143 8.1.4. Combined ACP/Data-Plane Interface (VRF Select) . . . 74 144 8.1.5. Use of GRASP . . . . . . . . . . . . . . . . . . . . 75 145 8.2. ACP through Non-ACP L3 Clouds (Remote ACP neighbors) . . 76 146 8.2.1. Configured Remote ACP neighbor . . . . . . . . . . . 76 147 8.2.2. Tunneled Remote ACP Neighbor . . . . . . . . . . . . 77 148 8.2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 78 149 9. Benefits (Informative) . . . . . . . . . . . . . . . . . . . 78 150 9.1. Self-Healing Properties . . . . . . . . . . . . . . . . . 78 151 9.2. Self-Protection Properties . . . . . . . . . . . . . . . 80 152 9.2.1. From the outside . . . . . . . . . . . . . . . . . . 80 153 9.2.2. From the inside . . . . . . . . . . . . . . . . . . . 80 154 9.3. The Administrator View . . . . . . . . . . . . . . . . . 81 155 10. ACP Operations (Informative) . . . . . . . . . . . . . . . . 82 156 10.1. ACP (and BRSKI) Diagnostics . . . . . . . . . . . . . . 82 157 10.2. ACP Registrars . . . . . . . . . . . . . . . . . . . . . 87 158 10.2.1. Registrar interactions . . . . . . . . . . . . . . . 87 159 10.2.2. Registrar Parameter . . . . . . . . . . . . . . . . 88 160 10.2.3. Certificate renewal and limitations . . . . . . . . 89 161 10.2.4. ACP Registrars with sub-CA . . . . . . . . . . . . . 90 162 10.2.5. Centralized Policy Control . . . . . . . . . . . . . 90 163 10.3. Enabling and disabling ACP/ANI . . . . . . . . . . . . . 91 164 10.3.1. Filtering for non-ACP/ANI packets . . . . . . . . . 91 165 10.3.2. Admin Down State . . . . . . . . . . . . . . . . . . 92 166 10.3.2.1. Security . . . . . . . . . . . . . . . . . . . . 93 167 10.3.2.2. Fast state propagation and Diagnostics . . . . . 93 168 10.3.2.3. Low Level Link Diagnostics . . . . . . . . . . . 94 169 10.3.2.4. Power Consumption Issues . . . . . . . . . . . . 94 170 10.3.3. Interface level ACP/ANI enable . . . . . . . . . . . 95 171 10.3.4. Which interfaces to auto-enable? . . . . . . . . . . 95 172 10.3.5. Node Level ACP/ANI enable . . . . . . . . . . . . . 96 173 10.3.5.1. Brownfield nodes . . . . . . . . . . . . . . . . 97 174 10.3.5.2. Greenfield nodes . . . . . . . . . . . . . . . . 97 175 10.3.6. Undoing ANI/ACP enable . . . . . . . . . . . . . . . 98 176 10.3.7. Summary . . . . . . . . . . . . . . . . . . . . . . 98 177 10.4. Configuration and the ACP (summary) . . . . . . . . . . 99 178 11. Security Considerations . . . . . . . . . . . . . . . . . . . 100 179 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 102 180 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 103 181 14. Change log [RFC Editor: Please remove] . . . . . . . . . . . 104 182 14.1. Initial version . . . . . . . . . . . . . . . . . . . . 104 183 14.2. draft-behringer-anima-autonomic-control-plane-00 . . . . 104 184 14.3. draft-behringer-anima-autonomic-control-plane-01 . . . . 104 185 14.4. draft-behringer-anima-autonomic-control-plane-02 . . . . 104 186 14.5. draft-behringer-anima-autonomic-control-plane-03 . . . . 104 187 14.6. draft-ietf-anima-autonomic-control-plane-00 . . . . . . 105 188 14.7. draft-ietf-anima-autonomic-control-plane-01 . . . . . . 105 189 14.8. draft-ietf-anima-autonomic-control-plane-02 . . . . . . 106 190 14.9. draft-ietf-anima-autonomic-control-plane-03 . . . . . . 106 191 14.10. draft-ietf-anima-autonomic-control-plane-04 . . . . . . 106 192 14.11. draft-ietf-anima-autonomic-control-plane-05 . . . . . . 107 193 14.12. draft-ietf-anima-autonomic-control-plane-06 . . . . . . 107 194 14.13. draft-ietf-anima-autonomic-control-plane-07 . . . . . . 108 195 14.14. draft-ietf-anima-autonomic-control-plane-08 . . . . . . 109 196 14.15. draft-ietf-anima-autonomic-control-plane-09 . . . . . . 111 197 14.16. draft-ietf-anima-autonomic-control-plane-10 . . . . . . 113 198 14.17. draft-ietf-anima-autonomic-control-plane-11 . . . . . . 115 199 14.18. draft-ietf-anima-autonomic-control-plane-12 . . . . . . 115 200 14.19. draft-ietf-anima-autonomic-control-plane-13 . . . . . . 116 201 14.20. draft-ietf-anima-autonomic-control-plane-14 . . . . . . 118 202 14.21. draft-ietf-anima-autonomic-control-plane-15 . . . . . . 122 203 14.22. draft-ietf-anima-autonomic-control-plane-16 . . . . . . 123 204 14.23. draft-ietf-anima-autonomic-control-plane-17 . . . . . . 123 205 14.24. draft-ietf-anima-autonomic-control-plane-18 . . . . . . 125 206 14.25. draft-ietf-anima-autonomic-control-plane-19 . . . . . . 125 207 14.26. Open Issues in -19 . . . . . . . . . . . . . . . . . . . 128 208 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 128 209 15.1. Normative References . . . . . . . . . . . . . . . . . . 128 210 15.2. Informative References . . . . . . . . . . . . . . . . . 130 211 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 137 212 Appendix A. Background and Futures (Informative) . . . . . . . . 137 213 A.1. ACP Address Space Schemes . . . . . . . . . . . . . . . . 137 214 A.2. BRSKI Bootstrap (ANI) . . . . . . . . . . . . . . . . . . 138 215 A.3. ACP Neighbor discovery protocol selection . . . . . . . . 139 216 A.3.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 139 217 A.3.2. mDNS and L2 support . . . . . . . . . . . . . . . . . 139 218 A.3.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 140 219 A.4. Choice of routing protocol (RPL) . . . . . . . . . . . . 140 220 A.5. ACP Information Distribution and multicast . . . . . . . 142 221 A.6. Extending ACP channel negotiation (via GRASP) . . . . . . 143 222 A.7. CAs, domains and routing subdomains . . . . . . . . . . . 144 223 A.8. Intent for the ACP . . . . . . . . . . . . . . . . . . . 145 224 A.9. Adopting ACP concepts for other environments . . . . . . 146 225 A.10. Further options / futures . . . . . . . . . . . . . . . . 148 226 A.10.1. Auto-aggregation of routes . . . . . . . . . . . . . 148 227 A.10.2. More options for avoiding IPv6 Data-Plane dependency 149 228 A.10.3. ACP APIs and operational models (YANG) . . . . . . . 149 229 A.10.4. RPL enhancements . . . . . . . . . . . . . . . . . . 149 230 A.10.5. Role assignments . . . . . . . . . . . . . . . . . . 150 231 A.10.6. Autonomic L3 transit . . . . . . . . . . . . . . . . 151 232 A.10.7. Diagnostics . . . . . . . . . . . . . . . . . . . . 151 233 A.10.8. Avoiding and dealing with compromised ACP nodes . . 151 234 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 153 236 1. Introduction (Informative) 238 Autonomic Networking is a concept of self-management: Autonomic 239 functions self-configure, and negotiate parameters and settings 240 across the network. [RFC7575] defines the fundamental ideas and 241 design goals of Autonomic Networking. A gap analysis of Autonomic 242 Networking is given in [RFC7576]. The reference architecture for 243 Autonomic Networking in the IETF is specified in the document 244 [I-D.ietf-anima-reference-model]. 246 Autonomic functions need an autonomically built communications 247 infrastructure. This infrastructure needs to be secure, resilient 248 and re-usable by all autonomic functions. Section 5 of [RFC7575] 249 introduces that infrastructure and calls it the Autonomic Control 250 Plane (ACP). More descriptively it would be the "Autonomic 251 communications infrastructure for Management and Control". For 252 naming consistency with that prior document, this document continues 253 to use the name ACP though. 255 Today, the management and control plane of networks typically uses a 256 routing and forwarding table which is dependent on correct 257 configuration and routing. Misconfigurations or routing problems can 258 disrupt management and control channels. Traditionally, an out-of- 259 band network has been used to avoid or allow recovery from such 260 problems, or personnel are sent on site to access devices through 261 out-of-band management ports (also called craft ports, serial 262 console, management ethernet port). However, both options are 263 expensive. 265 In increasingly automated networks either centralized management 266 systems or distributed autonomic service agents in the network 267 require a control plane which is independent of the configuration of 268 the network they manage, to avoid impacting their own operations 269 through the configuration actions they take. 271 This document describes a modular design for a self-forming, self- 272 managing and self-protecting Autonomic Control Plane (ACP), which is 273 a virtual in-band network designed to be as independent as possible 274 of configuration, addressing and routing problems. The details how 275 this is achieved are described in Section 6. The ACP is designed to 276 remain operational even in the presence of configuration errors, 277 addressing or routing issues, or where policy could inadvertently 278 affect connectivity of both data packets or control packets. 280 This document uses the term "Data-Plane" to refer to anything in the 281 network nodes that is not the ACP, and therefore considered to be 282 dependent on (mis-)configuration. This Data-Plane includes both the 283 traditional forwarding-plane, as well as any pre-existing control- 284 plane, such as routing protocols that establish routing tables for 285 the forwarding plane. 287 The Autonomic Control Plane serves several purposes at the same time: 289 1. Autonomic functions communicate over the ACP. The ACP therefore 290 directly supports Autonomic Networking functions, as described in 291 [I-D.ietf-anima-reference-model]. For example, Generic Autonomic 292 Signaling Protocol (GRASP - [I-D.ietf-anima-grasp]) runs securely 293 inside the ACP and depends on the ACP as its "security and 294 transport substrate". 296 2. A controller or network management system can use it to securely 297 bootstrap network devices in remote locations, even if the (Data- 298 Plane) network in between is not yet configured; no Data-Plane 299 dependent bootstrap configuration is required. An example of 300 such a secure bootstrap process is described in 301 [I-D.ietf-anima-bootstrapping-keyinfra]. 303 3. An operator can use it to log into remote devices, even if the 304 network is misconfigured or not configured. 306 This document describes these purposes as use cases for the ACP in 307 Section 3, it defines the requirements in Section 4. Section 5 gives 308 an overview how the ACP is constructed. 310 The normative part of this document starts with Section 6, where the 311 ACP is specified. Section 7 defines normative how to support ACP on 312 L2 switches. Section 8 explains normative how non-ACP nodes and 313 networks can be integrated. 315 The remaining sections are non-normative: Section 9 reviews benefits 316 of the ACP (after all the details have been defined), Section 10 317 provides operational recommendations, Appendix A provides additional 318 explanations and describes additional details or future standard or 319 propriety extensions that were considered not to be appropriate for 320 standardization in this document but were considered important to 321 document. There are no dependencies against Appendix A to build a 322 complete working and interoperable ACP according to this document. 324 The ACP provides secure IPv6 connectivity, therefore it can be used 325 not only as the secure connectivity for self-management as required 326 for the ACP in [RFC7575], but it can also be used as the secure 327 connectivity for traditional (centralized) management. The ACP can 328 be implemented and operated without any other components of autonomic 329 networks, except for the GRASP protocol. ACP relies on per-link DULL 330 GRASP (see Section 6.3) to autodiscover ACP neighbors, and includes 331 the ACP GRASP instance to provide service discovery for clients of 332 the ACP (see Section 6.8) including for its own maintenance of ACP 333 certificates. 335 The document "Using Autonomic Control Plane for Stable Connectivity 336 of Network OAM" [RFC8368] describes how the ACP alone can be used to 337 provide secure and stable connectivity for autonomic and non- 338 autonomic Operations Administration and Management (OAM) 339 applications. That document also explains how existing management 340 solutions can leverage the ACP in parallel with traditional 341 management models, when to use the ACP and how to integrate with 342 potentially IPv4 only OAM backends. 344 Combining ACP with Bootstrapping Remote Secure Key Infrastructures 345 (BRSKI), see [I-D.ietf-anima-bootstrapping-keyinfra]) results in the 346 "Autonomic Network Infrastructure" as defined in 347 [I-D.ietf-anima-reference-model], which provides autonomic 348 connectivity (from ACP) with fully secure zero-touch (automated) 349 bootstrap from BRSKI. The ANI itself does not constitute an 350 Autonomic Network, but it allows the building of more or less 351 autonomic networks on top of it - using either centralized, Software 352 Defined Networking- (SDN-)style (see [RFC7426]) automation or 353 distributed automation via Autonomic Service Agents (ASA) / Autonomic 354 Functions (AF) - or a mixture of both. See 355 [I-D.ietf-anima-reference-model] for more information. 357 1.1. Applicability and Scope 359 Please see the following Terminology section (Section 2) for 360 explanations of terms used in this section. 362 The design of the ACP as defined in this document is considered to be 363 applicable to all types of "professionally managed" networks: Service 364 Provider, Local Area Network (LAN), Metro(politan networks), Wide 365 Area Network (WAN), Enterprise Information Technology (IT) and 366 ->"Operational Technology" () (OT) networks. The ACP can operate 367 equally on layer 3 equipment and on layer 2 equipment such as bridges 368 (see Section 7). The hop-by-hop authentication and confidentiality 369 mechanism used by the ACP is defined to be negotiable, therefore it 370 can be extended to environments with different protocol preferences. 371 The minimum implementation requirements in this document attempt to 372 achieve maximum interoperability by requiring support for multiple 373 options depending on the type of device: IPsec, see [RFC4301], and 374 datagram Transport Layer Security version 1.2 (DTLS), see [RFC6347]). 376 The implementation footprint of the ACP consists of Public Key 377 Infrastructure (PKI) code for the ACP certificate, the GRASP 378 protocol, UDP, TCP and TLS (for security and reliability of GRASP), 379 the ACP secure channel protocol used (such as IPsec or DTLS), and an 380 instance of IPv6 packet forwarding and routing via the Routing 381 Protocol for Low-power and Lossy Networks (RPL), see [RFC6550], that 382 is separate from routing and forwarding for the Data-Plane (user 383 traffic). 385 The ACP uses only IPv6 to avoid complexity of dual-stack ACP 386 operations (IPv6/IPv4). Nevertheless, it can without any changes be 387 integrated into even otherwise IPv4-only network devices. The Data- 388 Plane itself would not need to change, it could continue to be IPv4 389 only. For such IPv4 only devices, the IPv6 protocol itself would be 390 additional implementation footprint only used for the ACP. 392 The protocol choices of the ACP are primarily based on wide use and 393 support in networks and devices, well understood security properties 394 and required scalability. The ACP design is an attempt to produce 395 the lowest risk combination of existing technologies and protocols to 396 build a widely applicable operational network management solution: 398 RPL was chosen because it requires a smaller routing table footprint 399 in large networks compared to other routing protocols with an 400 autonomically configured single area. The deployment experience of 401 large scale Internet of Things (IoT) networks serves as the basis for 402 wide deployment experience with RPL. The profile chosen for RPL in 403 the ACP does not leverage any RPL specific forwarding plane features 404 (IPv6 extension headers), making its implementation a pure control 405 plane software requirement. 407 GRASP is the only completely novel protocol used in the ACP, and this 408 choice was necessary because there is no existing suitable protocol 409 to provide the necessary functions to the ACP, so GRASP was developed 410 to fill that gap. 412 The ACP design can be applicable to (cpu, memory) constrained devices 413 and (bitrate, reliability) constrained networks, but this document 414 does not attempt to define the most constrained type of devices or 415 networks to which the ACP is applicable. RPL and DTLS for ACP secure 416 channels are two protocol choices already making ACP more applicable 417 to constrained environments. Support for constrained devices in this 418 specification is opportunistic, but not complete, because the 419 reliable transport for GRASP (see Section 6.8.2) only specifies TCP/ 420 TLS). See Appendix A.9 for discussions about how future standards or 421 proprietary extensions/variations of the ACP could better meet 422 different expectations from those on which the current design is 423 based including supporting constrained devices better. 425 2. Acronyms and Terminology (Informative) 427 [RFC Editor: WG/IETF/IESG review of the terms below asked for 428 references between these terms when they refer to each other. The 429 only option I could fin RFC/XML to point to a hanging text acronym 430 definition that also displays the actual term is the format="title" 431 version, which leads to references such as '->"ACP domain 432 certificate" ()'. I found no reasonable way to eliminate the 433 trailing '()' generated by this type of cross references. Can you 434 please take care of removing these artefacts during editing (after 435 conversion to nroff ?). I also created a ticket to ask for an 436 xml2rfc enhancement to avoid this in the future: 437 https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/347. 439 [RFC Editor: Question: Is it possible to change the first occurrences 440 of [RFCxxxx] references to "rfcxxx title" [RFCxxxx]? the XML2RFC 441 format does not seem to offer such a format, but I did not want to 442 duplicate 50 first references - one reference for title mentioning 443 and one for RFC number.] 445 In the rest of the document we will refer to systems using the ACP as 446 "nodes". Typically such a node is a physical (network equipment) 447 device, but it can equally be some virtualized system. Therefore, we 448 do not refer to them as devices unless the context specifically calls 449 for a physical system. 451 This document introduces or uses the following terms (sorted 452 alphabetically). Terms introduced are explained on first use, so 453 this list is for reference only. 455 ACP: "Autonomic Control Plane". The Autonomic Function as defined 456 in this document. It provides secure zero-touch (automated) 457 transitive (network wide) IPv6 connectivity for all nodes in the 458 same ACP domain as well as a GRASP instance running across this 459 ACP IPv6 connectivity. The ACP is primarily meant to be used as a 460 component of the ANI to enable Autonomic Networks but it can 461 equally be used in simple ANI networks (with no other Autonomic 462 Functions) or completely by itself. 464 ACP address: An IPv6 address assigned to the ACP node. It is stored 465 in the domain information field of the ->"ACP domain certificate" 466 (). 468 ACP address range/set: The ACP address may imply a range or set of 469 addresses that the node can assign for different purposes. This 470 address range/set is derived by the node from the format of the 471 ACP address called the "addressing sub-scheme". 473 ACP connect interface: An interface on an ACP node providing access 474 to the ACP for non ACP capable nodes without using an ACP secure 475 channel. See Section 8.1.1. 477 ACP domain: The ACP domain is the set of nodes with ->"ACP domain 478 certificates" that allow them to authenticate each other as 479 members of the ACP domain. See also Section 6.1.2. 481 ACP (ANI/AN) Domain Certificate: A provisioned [RFC5280] certificate 482 (LDevID) carrying the domain information field which is used by 483 the ACP to learn its address in the ACP and to derive and 484 cryptographically assert its membership in the ACP domain. 486 domain information (field): An rfc822Name information element (e.g., 487 field) in the domain certificate in which the ACP relevant 488 information is encoded: the domain name and the ACP address. 490 ACP Loopback interface: The Loopback interface in the ACP Virtual 491 Routing and Forwarding (VRF) that has the ACP address assigned to 492 it. 494 ACP network: The ACP network constitutes all the nodes that have 495 access to the ACP. It is the set of active and transitively 496 connected nodes of an ACP domain plus all nodes that get access to 497 the ACP of that domain via ACP edge nodes. 499 ACP (ULA) prefix(es): The /48 IPv6 address prefixes used across the 500 ACP. In the normal/simple case, the ACP has one ULA prefix, see 501 Section 6.10. The ACP routing table may include multiple ULA 502 prefixes if the "rsub" option is used to create addresses from 503 more than one ULA prefix. See Section 6.1.1. The ACP may also 504 include non-ULA prefixes if those are configured on ACP connect 505 interfaces. See Section 8.1.1. 507 ACP secure channel: A cryptographically authenticated and encrypted 508 data connection established between (normally) adjacent ACP nodes 509 to carry traffic of the ACP VRF secure and isolated from Data- 510 Plane traffic in-band over the same link/path as the Data-Plane. 512 ACP secure channel protocol: The protocol used to build an ACP 513 secure channel, e.g., Internet Key Exchange Protocol version 2 514 (IKEv2) with IPsec or Datagram Transport Layer Security (DTLS). 516 ACP virtual interface: An interface in the ACP VRF mapped to one or 517 more ACP secure channels. See Section 6.12.5. 519 AN "Autonomic Network": A network according to 520 [I-D.ietf-anima-reference-model]. Its main components are ANI, 521 Autonomic Functions and Intent. 523 (AN) Domain Name: An FQDN (Fully Qualified Domain Name) in the 524 domain information field of the Domain Certificate. See 525 Section 6.1.1. 527 ANI (nodes/network): "Autonomic Network Infrastructure". The ANI is 528 the infrastructure to enable Autonomic Networks. It includes ACP, 529 BRSKI and GRASP. Every Autonomic Network includes the ANI, but 530 not every ANI network needs to include autonomic functions beyond 531 the ANI (nor Intent). An ANI network without further autonomic 532 functions can for example support secure zero-touch (automated) 533 bootstrap and stable connectivity for SDN networks - see 534 [RFC8368]. 536 ANIMA: "Autonomic Networking Integrated Model and Approach". ACP, 537 BRSKI and GRASP are products of the IETF ANIMA working group. 539 ASA: "Autonomic Service Agent". Autonomic software modules running 540 on an ANI device. The components making up the ANI (BRSKI, ACP, 541 GRASP) are also described as ASAs. 543 Autonomic Function: A function/service in an Autonomic Network (AN) 544 composed of one or more ASA across one or more ANI nodes. 546 BRSKI: "Bootstrapping Remote Secure Key Infrastructures" 547 ([I-D.ietf-anima-bootstrapping-keyinfra]. A protocol extending 548 EST to enable secure zero-touch bootstrap in conjunction with ACP. 549 ANI nodes use ACP, BRSKI and GRASP. 551 Data-Plane: The counterpoint to the ACP VRF in an ACP node: all 552 routing and forwarding in the node other than the ACP VRF. In a 553 simple ACP or ANI node, the Data-Plane is typically provisioned by 554 means other than autonomically, for example manually (including 555 across the ACP) or via SDN controllers. In a fully Autonomic 556 Network node, the Data-Plane is managed autonomically via 557 Autonomic Functions and Intent. Note that other (non-ANIMA) RFCs 558 use the Data-Plane to refer to what is better called the 559 forwarding plane. This is not the way the term is used in this 560 document! 562 device: A physical system, or physical node. 564 Enrollment: The process where a node presents identification (for 565 example through keying material such as the private key of an 566 IDevID) to a network and acquires a network specific identity and 567 trust anchor such as an LDevID. 569 EST: "Enrollment over Secure Transport" ([RFC7030]). IETF standard- 570 track protocol for enrollment of a node with an LDevID. BRSKI is 571 based on EST. 573 GRASP: "Generic Autonomic Signaling Protocol". An extensible 574 signaling protocol required by the ACP for ACP neighbor discovery. 576 The ACP also provides the "security and transport substrate" for 577 the "ACP instance of GRASP". This instance of GRASP runs across 578 the ACP secure channels to support BRSKI and other NOC/OAM or 579 Autonomic Functions. See [I-D.ietf-anima-grasp]. 581 IDevID: An "Initial Device IDentity" X.509 certificate installed by 582 the vendor on new equipment. Contains information that 583 establishes the identity of the node in the context of its vendor/ 584 manufacturer such as device model/type and serial number. See 585 [AR8021]. IDevID cannot be used for the ACP because they are not 586 provisioned by the owner of the network, so they can not directly 587 indicate an ACP domain they belong to. 589 in-band (management): The type of management used predominantly in 590 IP based networks, not leveraging an ->"out-of-band network" (). 591 In in-band management, access to the managed equipment depends on 592 the configuration of this equipment itself: interface, addressing, 593 forwarding, routing, policy, security, management. This 594 dependency makes in-band management fragile because the 595 configuration actions performed may break in-band management 596 connectivity. Breakage can not only be unintentional, it can 597 simply be an unavoidable side effect of being unable to create 598 configuration schemes where in-band management connectivity 599 configuration is unaffected by Data-Plane configuration. See also 600 ->"(virtual) out-of-band network" (). 602 Intent: Policy language of an autonomic network according to 603 [I-D.ietf-anima-reference-model]. 605 Loopback interface: The conventional name for an internal IP 606 interface to which addresses may be assigned, but which transmits 607 no external traffic. 609 LDevID: A "Local Device IDentity" is an X.509 certificate installed 610 during "enrollment". The Domain Certificate used by the ACP is an 611 LDevID. See [AR8021]. 613 MIC: "Manufacturer Installed Certificate". Another word not used in 614 this document to describe an IDevID. 616 native interface: Interfaces existing on a node without 617 configuration of the already running node. On physical nodes 618 these are usually physical interfaces. On virtual nodes their 619 equivalent. 621 node: A system, e.g., supporting the ACP according to this document. 622 Can be virtual or physical. Physical nodes are called devices. 624 Node-ID: The identifier of an ACP node inside that ACP. It is the 625 last 64 (see Section 6.10.3) or 78-bits (see Section 6.10.5) of 626 the ACP address. 628 Operational Technology (OT): "https://en.wikipedia.org/wiki/ 629 Operational_Technology" [1]: "The hardware and software dedicated 630 to detecting or causing changes in physical processes through 631 direct monitoring and/or control of physical devices such as 632 valves, pumps, etc.". OT networks are today in most cases well 633 separated from Information Technology (IT) networks. 635 (virtual) out-of-band network: An out-of-band network is a secondary 636 network used to manage a primary network. The equipment of the 637 primary network is connected to the out-of-band network via 638 dedicated management ports on the primary network equipment. 639 Serial (console) management ports were historically most common, 640 higher end network equipment now also has ethernet ports dedicated 641 only for management. An out-of-band network provides management 642 access to the primary network independent of the configuration 643 state of the primary network. One of the goals of the ACP is to 644 provide this benefit of out-of-band networks virtually on the 645 primary network equipment. The ACP VRF acts as a virtual out of 646 band network device providing configuration independent management 647 access. The ACP secure channels are the virtual links of the ACP 648 virtual out-of-band network, meant to be operating independent of 649 the configuration of the primary network. See also ->"in-band 650 (management)" (). 652 RPL: "IPv6 Routing Protocol for Low-Power and Lossy Networks". The 653 routing protocol used in the ACP. See [RFC6550]. 655 MASA (service): "Manufacturer Authorized Signing Authority". A 656 vendor/manufacturer or delegated cloud service on the Internet 657 used as part of the BRSKI protocol. 659 (ACP/ANI/BRSKI) Registrar: An ACP registrar is an entity (software 660 and/or person) that is orchestrating the enrollment of ACP nodes 661 with the ACP domain certificate. ANI nodes use BRSKI, so ANI 662 registrars are also called BRSKI registrars. For non-ANI ACP 663 nodes, the registrar mechanisms are undefined by this document. 664 See Section 6.10.7. Renewal and other maintenance (such as 665 revocation) of ACP domain certificates may be performed by other 666 entities than registrars. EST must be supported for ACP domain 667 certificate renewal (see Section 6.1.4). BRSKI is an extension of 668 EST, so ANI/BRSKI registrars can easily support ACP domain 669 certificate renewal in addition to initial enrollment. 671 sUDI: "secured Unique Device Identifier". Another term not used in 672 this document to refer to an IDevID. 674 UDI: "Unique Device Identifier". In the context of this document 675 unsecured identity information of a node typically consisting of 676 at least device model/type and serial number, often in a vendor 677 specific format. See sUDI and LDevID. 679 ULA: (Global ID prefix) A "Unique Local Address" (ULA) is an IPv6 680 address in the block fc00::/7, defined in [RFC4193]. It is the 681 approximate IPv6 counterpart of the IPv4 private address 682 ([RFC1918]). The ULA Global ID prefix are the first 48-bits of a 683 ULA address. In this document it is abbreviated as "ULA prefix". 685 (ACP) VRF: The ACP is modeled in this document as a "Virtual Routing 686 and Forwarding" instance (VRF). This means that it is based on a 687 "virtual router" consisting of a separate IPv6 forwarding table to 688 which the ACP virtual interfaces are attached and an associated 689 IPv6 routing table separate from the Data-Plane. Unlike the VRFs 690 on MPLS/VPN-PE ([RFC4364]) or LISP XTR ([RFC6830]), the ACP VRF 691 does not have any special "core facing" functionality or routing/ 692 mapping protocols shared across multiple VRFs. In vendor products 693 a VRF such as the ACP-VRF may also be referred to as a so called 694 VRF-lite. 696 (ACP) Zone: An ACP zone is a set of ACP nodes using the same zone 697 field value in their ACP address according to Section 6.10.3. 698 Zones are a mechanism to support structured addressing of ACP 699 addresses within the same /48-bit ULA prefix. 701 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 702 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 703 "OPTIONAL" in this document are to be interpreted as described in BCP 704 14 [RFC2119],[RFC8174] when, and only when, they appear in all 705 capitals, as shown here. 707 3. Use Cases for an Autonomic Control Plane (Informative) 709 3.1. An Infrastructure for Autonomic Functions 711 Autonomic Functions need a stable infrastructure to run on, and all 712 autonomic functions should use the same infrastructure to minimize 713 the complexity of the network. In this way, there is only need for a 714 single discovery mechanism, a single security mechanism, and single 715 instances of other processes that distributed functions require. 717 3.2. Secure Bootstrap over a not configured Network 719 Today, bootstrapping a new node typically requires all nodes between 720 a controlling node such as an SDN controller ("Software Defined 721 Networking", see [RFC7426]) and the new node to be completely and 722 correctly addressed, configured and secured. Bootstrapping and 723 configuration of a network happens in rings around the controller - 724 configuring each ring of devices before the next one can be 725 bootstrapped. Without console access (for example through an out-of- 726 band network) it is not possible today to make devices securely 727 reachable before having configured the entire network leading up to 728 them. 730 With the ACP, secure bootstrap of new devices and whole new networks 731 can happen without requiring any configuration of unconfigured 732 devices along the path: As long as all devices along the path support 733 ACP and a zero-touch bootstrap mechanism such as BRSKI, the ACP 734 across a whole network of unconfigured devices can be brought up 735 without operator/provisioning intervention. The ACP also provides 736 additional security for any bootstrap mechanism, because it can 737 provide encrypted discovery (via ACP GRASP) of registrars or other 738 bootstrap servers by bootstrap proxies connecting to nodes that are 739 to be bootstrapped and the ACP encryption hides the identities of the 740 communicating entities (pledge and registrar), making it more 741 difficult to learn which network node might be attackable. The ACP 742 domain certificate can also be used to end-to-end encrypt the 743 bootstrap communication between such proxies and server. Note that 744 bootstrapping here includes not only the first step that can be 745 provided by BRSKI (secure keys), but also later stages where 746 configuration is bootstrapped. 748 3.3. Data-Plane Independent Permanent Reachability 750 Today, most critical control plane protocols and network management 751 protocols are using the Data-Plane of the network. This leads to 752 often undesirable dependencies between control and management plane 753 on one side and the Data-Plane on the other: Only if the forwarding 754 and control plane of the Data-Plane are configured correctly, will 755 the Data-Plane and the management plane work as expected. 757 Data-Plane connectivity can be affected by errors and faults, for 758 example misconfigurations that make AAA (Authentication, 759 Authorization and Accounting) servers unreachable or can lock an 760 administrator out of a device; routing or addressing issues can make 761 a device unreachable; shutting down interfaces over which a current 762 management session is running can lock an admin irreversibly out of 763 the device. Traditionally only out-of-band access can help recover 764 from such issues (such as serial console or ethernet management 765 port). 767 Data-Plane dependencies also affect applications in a Network 768 Operations Center (NOC) such as SDN controller applications: Certain 769 network changes are today hard to implement, because the change 770 itself may affect reachability of the devices. Examples are address 771 or mask changes, routing changes, or security policies. Today such 772 changes require precise hop-by-hop planning. 774 Note that specific control plane functions for the Data-Plane often 775 want to depend on forwarding of their packets via the Data-Plane: 776 Aliveness and routing protocol signaling packets across the Data- 777 Plane to verify reachability across the Data-Plane, using IPv4 778 signaling packets for IPv4 routing vs. IPv6 signaling packets for 779 IPv6 routing. 781 Assuming appropriate implementation (see Section 6.12.2 for more 782 details), the ACP provides reachability that is independent of the 783 Data-Plane. This allows the control plane and management plane to 784 operate more robustly: 786 o For management plane protocols, the ACP provides the functionality 787 of a Virtual out-of-band (VooB) channel, by providing connectivity 788 to all nodes regardless of their Data-Plane configuration, routing 789 and forwarding tables. 791 o For control plane protocols, the ACP allows their operation even 792 when the Data-Plane is temporarily faulty, or during transitional 793 events, such as routing changes, which may affect the control 794 plane at least temporarily. This is specifically important for 795 autonomic service agents, which could affect Data-Plane 796 connectivity. 798 The document "Using Autonomic Control Plane for Stable Connectivity 799 of Network OAM" [RFC8368] explains this use case for the ACP in 800 significantly more detail and explains how the ACP can be used in 801 practical network operations. 803 4. Requirements (Informative) 805 The following requirements were identified for the design of the ACP 806 based on the above use-cases (Section 3). These requirements are 807 informative. The ACP as specified in the normative parts of this 808 document is meeting or exceeding these use-case requirements: 810 ACP1: The ACP should provide robust connectivity: As far as 811 possible, it should be independent of configured addressing, 812 configuration and routing. Requirements 2 and 3 build on this 813 requirement, but also have value on their own. 815 ACP2: The ACP must have a separate address space from the Data- 816 Plane. Reason: traceability, debug-ability, separation from 817 Data-Plane, infrastructure security (filtering based on known 818 address space). 820 ACP3: The ACP must use autonomically managed address space. Reason: 821 easy bootstrap and setup ("autonomic"); robustness (admin 822 cannot break network easily). This document suggests using 823 ULA addressing for this purpose ("Unique Local Address", see 824 [RFC4193]). 826 ACP4: The ACP must be generic, that is it must be usable by all the 827 functions and protocols of the ANI. Clients of the ACP must 828 not be tied to a particular application or transport protocol. 830 ACP5: The ACP must provide security: Messages coming through the ACP 831 must be authenticated to be from a trusted node, and should 832 (very strong should) be encrypted. 834 Explanation for ACP4: In a fully autonomic network (AN), newly 835 written ASA could potentially all communicate exclusively via GRASP 836 with each other, and if that was assumed to be the only requirement 837 against the ACP, it would not need to provide IPv6 layer connectivity 838 between nodes, but only GRASP connectivity. Nevertheless, because 839 ACP also intends to support non-AN networks, it is crucial to support 840 IPv6 layer connectivity across the ACP to support any transport and 841 application layer protocols. 843 The ACP operates hop-by-hop, because this interaction can be built on 844 IPv6 link local addressing, which is autonomic, and has no dependency 845 on configuration (requirement 1). It may be necessary to have ACP 846 connectivity across non-ACP nodes, for example to link ACP nodes over 847 the general Internet. This is possible, but introduces a dependency 848 against stable/resilient routing over the non-ACP hops (see 849 Section 8.2). 851 5. Overview (Informative) 853 The Autonomic Control Plane is constructed in the following way (for 854 details, see Section 6): 856 1. An ACP node creates a Virtual Routing and Forwarding (VRF) 857 instance, or a similar virtual context. 859 2. It determines, following a policy, a candidate peer list. This 860 is the list of nodes to which it should establish an Autonomic 861 Control Plane. Default policy is: To all link-layer adjacent 862 nodes supporting ACP. 864 3. For each node in the candidate peer list, it authenticates that 865 node (according to Section 6.1.2) and negotiates a mutually 866 acceptable channel type. 868 4. For each node in the candidate peer list, it then establishes a 869 secure tunnel of the negotiated type. The resulting tunnels are 870 then placed into the previously set up VRF. This creates an 871 overlay network with hop-by-hop tunnels. 873 5. Inside the ACP VRF, each node assigns its ULA IPv6 address to a 874 Loopback interface assigned to the ACP VRF. 876 6. Each node runs a lightweight routing protocol, to announce 877 reachability of the virtual addresses inside the ACP (see 878 Section 6.12.5). 880 Note: 882 o Non-autonomic NMS ("Network Management Systems") or SDN 883 controllers have to be explicitly configured for connection into 884 the ACP. 886 o Connecting over non-ACP Layer-3 clouds requires explicit 887 configuration. See Section 8.2. 889 o None of the above operations (except explicit configured ones) are 890 reflected in the configuration of the node. 892 The following figure illustrates the ACP. 894 ACP node 1 ACP node 2 895 ................... ................... 896 secure . . secure . . secure 897 channel: +-----------+ : channel : +-----------+ : channel 898 ..--------| ACP VRF |---------------------| ACP VRF |---------.. 899 : / \ / \ <--routing--> / \ / \ : 900 : \ / \ / \ / \ / : 901 ..--------| Loopback |---------------------| Loopback |---------.. 902 : | interface | : : | interface | : 903 : +-----------+ : : +-----------+ : 904 : : : : 905 : Data-Plane :...............: Data-Plane : 906 : : link : : 907 :.................: :.................: 909 Figure 1: ACP VRF and secure channels 911 The resulting overlay network is normally based exclusively on hop- 912 by-hop tunnels. This is because addressing used on links is IPv6 913 link local addressing, which does not require any prior set-up. In 914 this way the ACP can be built even if there is no configuration on 915 the node, or if the Data-Plane has issues such as addressing or 916 routing problems. 918 6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 920 This section describes the components and steps to set up an 921 Autonomic Control Plane (ACP), and highlights the key properties 922 which make it "indestructible" against many inadvertent changes to 923 the Data-Plane, for example caused by misconfigurations. 925 An ACP node can be a router, switch, controller, NMS host, or any 926 other IP capable node. Initially, it must have it's ACP domain 927 certificate, as well as an (empty) ACP Adjacency Table (described in 928 Section 6.2). It then can start to discover ACP neighbors and build 929 the ACP. This is described step by step in the following sections: 931 6.1. ACP Domain, Certificate and Network 933 The ACP relies on group security. An ACP domain is a group of nodes 934 that trust each other to participate in ACP operations. To establish 935 trust, each ACP member requires keying material: An ACP node MUST 936 have a certificate (LDevID) and a Trust Anchor (TA) consisting of a 937 certificate (chain) used to sign the LDevID of all ACP domain 938 members. The LDevID is used to cryptographically authenticate the 939 membership of its owner node in the ACP domain to other ACP domain 940 members, the TA is used to authenticate the ACP domain membership of 941 other nodes (see Section 6.1.2). 943 The LDevID is called the ACP domain certificate, the TA is the 944 Certificate Authority (CA) of the ACP domain. 946 The ACP does not mandate specific mechanisms by which this keying 947 material is provisioned into the ACP node, it only requires the 948 Domain information field as specified in Section 6.1.1 in its domain 949 certificate as well as those of candidate ACP peers. See 950 Appendix A.2 for more information about enrollment or provisioning 951 options. 953 This document uses the term ACP in many places where the Autonomic 954 Networking reference documents [RFC7575] and 955 [I-D.ietf-anima-reference-model] use the word autonomic. This is 956 done because those reference documents consider (only) fully 957 autonomic networks and nodes, but support of ACP does not require 958 support for other components of autonomic networks. Therefore the 959 word autonomic might be misleading to operators interested in only 960 the ACP. 962 [RFC7575] defines the term "Autonomic Domain" as a collection of 963 autonomic nodes. ACP nodes do not need to be fully autonomic, but 964 when they are, then the ACP domain is an autonomic domain. Likewise, 965 [I-D.ietf-anima-reference-model] defines the term "Domain 966 Certificate" as the certificate used in an autonomic domain. The ACP 967 domain certificate is that domain certificate when ACP nodes are 968 (fully) autonomic nodes. Finally, this document uses the term ACP 969 network to refer to the network created by active ACP nodes in an ACP 970 domain. The ACP network itself can extend beyond ACP nodes through 971 the mechanisms described in Section 8.1. 973 The ACP domain certificate SHOULD be used for any authentication 974 between nodes with ACP domain certificates (ACP nodes and NOC nodes) 975 where the required condition is ACP domain membership, such as ACP 976 node to NOC/OAM end-to-end security and ASA to ASA end-to-end 977 security. Section 6.1.2 defines this "ACP domain membership check". 978 The uses of this check that are standardized in this document are for 979 the establishment of ACP secure channels (Section 6.6) and for ACP 980 GRASP (Section 6.8.2). 982 6.1.1. Certificate ACP Domain Information Field 984 Information about the domain MUST be encoded in the domain 985 certificate in a subjectAltName / rfc822Name field according to the 986 following ABNF definition ([RFC5234]): 988 [RFC Editor: Please substitute SELF in all occurrences of rfcSELF in 989 this document with the RFC number assigned to this document and 990 remove this comment line] 991 domain-information = local-part "@" acp-domain-name 992 local-part = key [ "." local-info ] 993 key = "rfcSELF" 994 local-info = [ acp-address ] [ "+" rsub extensions ] 995 acp-address = 32hex-dig | 0 996 hex-dig = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" 997 rsub = [ ] ; as of RFC1034, section 3.5 998 routing-subdomain = [ rsub "." ] acp-domain-name 999 acp-domain-name = ; ; as of RFC 1034, section 3.5 1000 extensions = *( "+" extension ) 1001 extension = ; future standard definition. 1002 ; Must fit RFC5322 simple dot-atom format. 1004 Example: 1005 domain-information = rfcSELF+fd89b714f3db00000200000064000000 1006 +area51.research@acp.example.com 1007 acp-domain-name = acp.example.com 1008 routing-subdomain = area51.research.acp.example.com 1010 Figure 2: ACP Domain Information Field ABNF 1012 Nodes complying with this specification MUST be able to receive their 1013 ACP address through the domain certificate, in which case their own 1014 ACP domain certificate MUST have the 32hex-dig "acp-address" field. 1015 Nodes complying with this specification MUST also be able to 1016 authenticate nodes as ACP domain members / ACP secure channel peers 1017 when they have an empty or 0-value acp-address field. See 1018 Section 6.1.2. 1020 "acp-domain-name" is used to indicate the ACP Domain across which all 1021 ACP nodes trust each other and are willing to build ACP channels to 1022 each other. See Section 6.1.2. Acp-domain-name SHOULD be the FQDN 1023 of a DNS domain owned by the operator assigning the certificate. 1024 This is a simple method to ensure that the domain is globally unique 1025 and collision of ACP addresses would therefore only happen due to ULA 1026 hash collisions (see Section 6.10.2). If the operator does not own 1027 any FQDN, it should choose a string (in FQDN format) that it intends 1028 to be equally unique. 1030 "routing-subdomain" is the autonomic subdomain composed of "rsub" and 1031 "acp-domain-name". "rsub" is optional. When not present, "routing- 1032 subdomain" is the same as "acp-domain-name". "routing-subdomain" 1033 determines the /48 ULA prefix for ACP addresses. "rsub" therefore 1034 allows to use multiple /48 ULA prefixes in an ACP domain. See 1035 Appendix A.7 for example use-cases. 1037 The optional "extensions" field is used for future standardized 1038 extensions to this specification. It MUST be ignored if present and 1039 not understood. 1041 Formatting notes: 1043 o "rsub" needs to be in the "local-part": If the format just had 1044 routing-subdomain as the domain part of the domain-information, 1045 rsub and acp-domain-name could not be separated from each other. 1046 It also makes acp-domain-name a valid e-mail target across all 1047 routing-subdomains. 1049 o "acp-address" cannot use standard IPv6 address formats because it 1050 must match the simple dot-atom format of [RFC5322]. The character 1051 ":" is not allowed in that format. 1053 o If "acp-address" is empty, and "rsub" is empty too, the "local- 1054 part" will have the format "rfcSELF++extension(s)". The two plus 1055 characters are necessary so the node can unambiguously parse that 1056 both "acp-address" and "rsub" are empty. 1058 o The maximum size of "domain-information" is 254 characters and the 1059 maximum size of node-info is 64 characters according to [RFC5280] 1060 that is referring to [RFC2821] (superseded by [RFC5321]). 1062 The subjectAltName / rfc822Name encoding of the ACP domain name and 1063 ACP address is used for the following reasons: 1065 o It should be possible to share the LDevID with other uses beside 1066 the ACP. Therefore, the information element required for the ACP 1067 should be encoded so that it minimizes the possibility of creating 1068 incompatibilities with such other uses. 1070 o The information for the ACP should not cause incompatibilities 1071 with any pre-existing ASN.1 software. This eliminates the 1072 introduction of a novel information element because that could 1073 require extensions to such pre-existing ASN.1 parsers. 1075 o subjectAltName / rfc822Name is a pre-existing element that must be 1076 supported by all existing ASN.1 parsers for LDevID. 1078 o The element required for the ACP should not be misinterpreted by 1079 any other uses of the LDevID. If the element used for the ACP is 1080 interpreted by other uses, the impact should be benign. 1082 o The element should not require additional ASN.1 en/decoding, 1083 because it is unclear if all, especially embedded devices 1084 certificate libraries would support extensible ASN.1 1085 functionality. 1087 o Using an IP address format encoding could result in non-benign 1088 misinterpretation of the domain information field; other uses 1089 unaware of the ACP could try to do something with the ACP address 1090 that would fail to work correctly. For example, the address could 1091 be interpreted to be an address of the node which does not belong 1092 to the ACP VRF. 1094 o At minimum, both the AN domain name and the non-domain name 1095 derived part of the ACP address need to be encoded in one or more 1096 appropriate fields of the certificate, so there are not many 1097 alternatives with pre-existing fields where the only possible 1098 conflicts would likely be beneficial. 1100 o rfc822Name encoding is very flexible. It allows to encode all the 1101 different fields of information required for the ACP. 1103 o The format of the rfc822Name is chosen so that an operator can set 1104 up a mailbox called rfcSELF@ that would receive emails 1105 sent towards the rfc822Name of any node inside a domain. This is 1106 possible because in many modern mail systems, components behind a 1107 "+" character are considered part of a single mailbox. In other 1108 words, it is not necessary to set up a separate mailbox for every 1109 ACP node, but only one for the whole domain. 1111 o In result, if any unexpected use of the ACP addressing information 1112 in a certificate happens, it is benign and detectable: it would be 1113 mail to that mailbox. 1115 See section 4.2.1.6 of [RFC5280] for details on the subjectAltName 1116 field. 1118 6.1.2. ACP domain membership check 1120 The following points constitute the ACP domain membership check of a 1121 candidate peer certificate, independent of the protocol used: 1123 1: The peer certificate is valid (lifetime). 1125 2: The peer has proved ownership of the private key associated with 1126 the certificate's public key. 1128 3: The peer's certificate passes certificate path validation as 1129 defined in [RFC5280] against one of the Trust Anchors associated 1130 with the ACP nodes ACP domain certificate (see Section 6.1.3 1131 below). 1133 4: If the node certificate indicates a Certificate Revocation List 1134 (CRL) Distribution Point (CDP) ([RFC5280], section 4.2.1.13) or 1135 Online Certificate Status Protocol (OCSP) responder ([RFC5280], 1136 section 4.2.2.1), then the peer's certificate must be valid 1137 according to those criteria: An OCSP check for the peer's 1138 certificate across the ACP must succeed or the peer certificate 1139 must not be listed in the CRL retrieved from the CDP. This rule 1140 has to be skipped for ACP secure channel peer authentication when 1141 the node has no ACP or non-ACP connectivity to retrieve current 1142 CRL or access an OCSP responder (see below). 1144 5: The peer's certificate has a syntactically valid ACP domain 1145 information field (encoded as subjectAltName / rfc822Name) and the 1146 acp-domain-name in that peer's domain information field is the 1147 same as in this ACP node's certificate (lowercase normalized). 1149 When an ACP node learns later via OCSP/CRL that an ACP peers 1150 certificate for which rule 4 had to be skipped during ACP secure 1151 channel establishment is invalid, then the ACP secure channel to that 1152 peer SHOULD be closed even if this peer is the only connectivity to 1153 access CRL/OCSP. The ACP secure channel connection MUST be retried 1154 periodically to support the case that the neighbor aquires a new, 1155 valid certificate. 1157 Only when checking a candidate peer's certificate for the purpose of 1158 establishing an ACP secure channel, one additional check is 1159 performed: 1161 6: The candidate peer certificate's ACP domain information field 1162 has a non-empty acp-address field (either 32hex-dig or 0, 1163 according to Figure 2). 1165 Rule 6 for the establishment of ACP secure channels ensures that they 1166 will only be built between nodes which indicate through the acp- 1167 address in their ACP domain certificate the ability and permission by 1168 the Registrar to participate in ACP secure-channels. 1170 Nodes with an empty acp-address field can only use their ACP domain 1171 certificate for non-ACP-secure channel authentication purposes. 1173 The special value 0 in an ACP certificates acp-address field is used 1174 for nodes that can and should determine their ACP address through 1175 other mechanisms than learning it through the acp-address field in 1176 their ACP domain certificate. These ACP nodes are permitted to 1177 establish ACP secure channels. Mechanisms for those nodes to 1178 determine their ACP address are outside the scope of this 1179 specification. 1181 Formally, the ACP domain membership check includes both the 1182 authentication of the peers certificate (steps 1...4) and a check 1183 authorizing this node and the peer to establish an ACP connection 1184 and/or any other secure connection across ACP or data-plane end to 1185 end. Step 5 authorizes to build any non-ACP secure connection 1186 between members of the same ACP domain, step 5 and 6 are required to 1187 build an ACP secure channel. For brevity, the remainder of this 1188 document refers to this process only as authentication instead of as 1189 authentication and authorization. 1191 6.1.3. Trust Points and Trust Anchors 1193 ACP nodes need Trust Point (TP) certificates to perform certificate 1194 path validation as required by Section 6.1.2, rule 3. Trust Point(s) 1195 must be provisioned to an ACP node (together with its ACP domain 1196 certificate) by an ACP Registrar during initial enrolment of a 1197 candidate ACP node. ACP nodes MUST also support renewal of TPs via 1198 EST as described below in Section 6.1.4. 1200 Trust Point is the term used in this document for a certificate 1201 authority (CA) and its associated set of certificates. Multiple 1202 certificates are required for a CA to deal with CA certificate 1203 renewals as explained in Section 4.4 of CMP ([RFC4210]). 1205 A certificate path is a chain of certificates starting at a self- 1206 signed certificate of a so called root-CA or Trust Anchor, followed 1207 by zero or more intermediate Trust Point or sub-CA certificates and 1208 ending with an ACP certificate. Certificate path validation 1209 authenticates that the ACP certificate is signed by a Trust Anchor, 1210 directly or indirectly via one or more intermediate Trust Points. 1212 Note that different ACP nodes may have different Trust Points and 1213 even different Trust Anchors in their certificate path, as long as 1214 the set of Trust Points for all ACP node includes the same set of 1215 Trust Anchors (usually 1), and each ACP nodes set of Trust Anchors 1216 includes the intermediate Trust Points for its own ACP domain 1217 certificate. The protocols through which ACP domain membership check 1218 rules 1-4 are performed therefore need to support the exchange not 1219 only of the ACP nodes certificates, but also their intermediate Trust 1220 Points. 1222 ACP nodes MUST support for the ACP domain membership check the 1223 certificate path validation with 0 or 1 intermediate Trust Points. 1224 They SHOULD support 2 intermediate Trust Points and two Trust Anchors 1225 (to permit migration to different root-CAs). 1227 Trust Points for ACP domain certificates must be trusted to sign 1228 certificates with valid ACP domain information fields only for 1229 trusted ACP registrars of that domain. This can be achieved by using 1230 Trust Anchors private to the owner of the ACP domain or potentially 1231 through appropriate contractual agreements between the involved 1232 parties. Public CA without such obligations and guarantees can not 1233 be used. 1235 A single owner can operate multiple independent ACP domains from the 1236 same set of private trust anchors (CAs) when the ACP Registrars are 1237 trusted not to permit certificates with incorrect ACP information 1238 fields to be signed. Such as ACP information with a wrong acp-domain 1239 field. In this case, CAs can be completely unaware of ACP specifics, 1240 so that it should be possible to use any existing CA software. When 1241 ACP Registrars are not to be trusted, the correctness of the ACP 1242 domain information field for the candidate ACP node has to be 1243 verified by the CA signing the ACP domain certificate. 1245 6.1.4. Certificate and Trust Point Maintenance 1247 ACP nodes MUST support renewal of their Certificate and Trust Points 1248 (TP) via EST ("Enrollment over Secure Transport", see [RFC7030]) and 1249 MAY support other mechanisms. An ACP network MUST have at least one 1250 ACP node supporting EST server functionality across the ACP so that 1251 EST renewal is useable. 1253 ACP nodes SHOULD be able to remember the EST server from which they 1254 last renewed their ACP domain certificate and SHOULD provide the 1255 ability for this remembered EST server to also be set by the ACP 1256 Registrar (see Section 6.10.7) that initially enrolled the ACP device 1257 with its ACP domain certificate. When BRSKI (see 1258 [I-D.ietf-anima-bootstrapping-keyinfra]) is used, the ACP address of 1259 the BRSKI registrar from the BRSKI TLS connection SHOULD be 1260 remembered and used for the next renewal via EST if that registrar 1261 also announces itself as an EST server via GRASP (see next section) 1262 on its ACP address. 1264 6.1.4.1. GRASP objective for EST server 1266 ACP nodes that are EST servers MUST announce their service via GRASP 1267 in the ACP through M_FLOOD messages. See [I-D.ietf-anima-grasp], 1268 section 2.8.11 for the definition of this message type: 1270 Example: 1272 [M_FLOOD, 12340815, h'fd89b714f3db0000200000064000001', 210000, 1273 ["SRV.est", 4, 255 ], 1274 [O_IPv6_LOCATOR, 1275 h'fd89b714f3db0000200000064000001', TCP, 80] 1276 ] 1278 Figure 3: GRASP SRV.est example 1280 The formal definition of the objective in Concise data definition 1281 language (CDDL) (see [I-D.ietf-cbor-cddl]) is as follows: 1283 flood-message = [M_FLOOD, session-id, initiator, ttl, 1284 +[objective, (locator-option / [])]] 1286 objective = ["SRV.est", objective-flags, loop-count, 1287 objective-value] 1289 objective-flags = sync-only ; as in GRASP spec 1290 sync-only = 4 ; M_FLOOD only requires synchronization 1291 loop-count = 255 ; recommended 1292 objective-value = any ; Not used (yet) 1294 Figure 4: GRASP SRV.est definition 1296 The objective name "SRV.est" indicates that the objective is an 1297 [RFC7030] compliant EST server because "est" is an [RFC6335] 1298 registered service name for [RFC7030]. Objective-value MUST be 1299 ignored if present. Backward compatible extensions to [RFC7030] MAY 1300 be indicated through objective-value. Non [RFC7030] compatible 1301 certificate renewal options MUST use a different objective-name. 1303 The M_FLOOD message MUST be sent periodically. The default SHOULD be 1304 60 seconds, the value SHOULD be operator configurable but SHOULD be 1305 not smaller than 60 seconds. The frequency of sending MUST be such 1306 that the aggregate amount of periodic M_FLOODs from all flooding 1307 sources cause only negligible traffic across the ACP. The time-to- 1308 live (ttl) parameter SHOULD be 3.5 times the period so that up to 1309 three consecutive messages can be dropped before considering an 1310 announcement expired. In the example above, the ttl is 210000 msec, 1311 3.5 times 60 seconds. When a service announcer using these 1312 parameters unexpectedly dies immediately after sending the M_FLOOD, 1313 receivers would consider it expired 210 seconds later. When a 1314 receiver tries to connect to this dead service before this timeout, 1315 it will experience a failing connection and use that as an indication 1316 that the service is dead and select another instance of the same 1317 service instead. 1319 6.1.4.2. Renewal 1321 When performing renewal, the node SHOULD attempt to connect to the 1322 remembered EST server. If that fails, it SHOULD attempt to connect 1323 to an EST server learned via GRASP. The server with which 1324 certificate renewal succeeds SHOULD be remembered for the next 1325 renewal. 1327 Remembering the last renewal server and preferring it provides 1328 stickiness which can help diagnostics. It also provides some 1329 protection against off-path compromised ACP members announcing bogus 1330 information into GRASP. 1332 Renewal of certificates SHOULD start after less than 50% of the 1333 domain certificate lifetime so that network operations has ample time 1334 to investigate and resolve any problems that causes a node to not 1335 renew its domain certificate in time - and to allow prolonged periods 1336 of running parts of a network disconnected from any CA. 1338 6.1.4.3. Certificate Revocation Lists (CRLs) 1340 The ACP node SHOULD support Certificate Revocation Lists (CRL) via 1341 HTTPs from one or more CRL Distribution Points (CDPs). The CDP(s) 1342 MUST be indicated in the Domain Certificate when used. If the CDP 1343 URL uses an IPv6 address (ULA address when using the addressing rules 1344 specified in this document), the ACP node will connect to the CDP via 1345 the ACP. If the CDP uses a domain name, the ACP node will connect to 1346 the CDP via the Data-Plane. 1348 It is common to use domain names for CDP(s), but there is no 1349 requirement for the ACP to support DNS. Any DNS lookup in the Data- 1350 Plane is not only a possible security issue, but it would also not 1351 indicate whether the resolved address is meant to be reachable across 1352 the ACP. Therefore, the use of an IPv6 address versus the use of a 1353 DNS name doubles as an indicator whether or not to reach the CDP via 1354 the ACP. 1356 A CDP can be reachable across the ACP either by running it on a node 1357 with ACP or by connecting its node via an ACP connect interface (see 1358 Section 8.1). The CDP SHOULD use an ACP domain certificate for its 1359 HTTPs connections. The connecting ACP node SHOULD verify that the 1360 CDP certificate used during the HTTPs connection has the same ACP 1361 address as indicated in the CDP URL of the nodes ACP domain 1362 certificate if the CDP URL uses an IPv6 address. 1364 6.1.4.4. Lifetimes 1366 Certificate lifetime may be set to shorter lifetimes than customary 1367 (1 year) because certificate renewal is fully automated via ACP and 1368 EST. The primary limiting factor for shorter certificate lifetimes 1369 is load on the EST server(s) and CA. It is therefore recommended 1370 that ACP domain certificates are managed via a CA chain where the 1371 assigning CA has enough performance to manage short lived 1372 certificates. See also Section 10.2.4 for discussion about an 1373 example setup achieving this. See also [I-D.ietf-acme-star]. 1375 When certificate lifetimes are sufficiently short, such as few hours, 1376 certificate revocation may not be necessary, allowing to simplify the 1377 overall certificate maintenance infrastructure. 1379 See Appendix A.2 for further optimizations of certificate maintenance 1380 when BRSKI can be used ("Bootstrapping Remote Secure Key 1381 Infrastructures", see [I-D.ietf-anima-bootstrapping-keyinfra]). 1383 6.1.4.5. Re-enrollment 1385 An ACP node may determine that its ACP domain certificate has 1386 expired, for example because the ACP node was powered down or 1387 disconnected longer than its certificate lifetime. In this case, the 1388 ACP node SHOULD convert to a role of a re-enrolling candidate ACP 1389 node. 1391 In this role, the node does maintain the trust anchor and certificate 1392 chain associated with its ACP domain certificate exclusively for the 1393 purpose of re-enrollment, and attempts (or waits) to get re-enrolled 1394 with a new ACP certificate. The details depend on the mechanisms/ 1395 protocols used by the ACP registrars. 1397 Please refer to Section 6.10.7 and 1398 [I-D.ietf-anima-bootstrapping-keyinfra] for explanations about ACP 1399 registrars and vouchers as used in the following text. When ACP is 1400 intended to be used without BRSKI, the details about BRSKI and 1401 vouchers in the following text can be skipped. 1403 When BRSKI is used (i.e.: on ACP nodes that are ANI nodes), the re- 1404 enrolling candidate ACP node would attempt to enroll like a candidate 1405 ACP node (BRSKI pledge), but instead of using the ACP nodes IDevID, 1406 it SHOULD first attempt to use its ACP domain certificate in the 1407 BRSKI TLS authentication. The BRSKI registrar MAY honor this 1408 certificate beyond its expiration date purely for the purpose of re- 1409 enrollment. Using the ACP node's domain certificate allows the BRSKI 1410 registrar to learn that nodes ACP domain information field, so that 1411 the BRSKI registrar can re-assign the same ACP address information to 1412 the ACP node in the new ACP domain certificate. 1414 If the BRSKI registrar denies the use of the old ACP domain 1415 certificate, the re-enrolling candidate ACP node MUST re-attempt re- 1416 enrollment using its IDevID as defined in BRSKI during the TLS 1417 connection setup. 1419 Both when the BRSKI connection is attempted with the old ACP domain 1420 certificate or the IDevID, the re-enrolling candidate ACP node SHOULD 1421 authenticate the BRSKI registrar during TLS connection setup based on 1422 its existing trust anchor/certificate chain information associated 1423 with its old ACP certificate. The re-enrolling candidate ACP node 1424 SHOULD only request a voucher from the BRSKI registrar when this 1425 authentication fails during TLS connection setup. 1427 When other mechanisms than BRSKI are used for ACP domain certificate 1428 enrollment, the principles of the re-enrolling candidate ACP node are 1429 the same. The re-enrolling candidate ACP node attempts to 1430 authenticate any ACP registrar peers during re-enrollment protocol/ 1431 mechanisms via its existing certificate chain/trust anchor and 1432 provides its existing ACP domain certificate and other identification 1433 (such as the IDevID) as necessary to the registrar. 1435 Maintaining existing trust anchor information is especially important 1436 when enrollment mechanisms are used that unlike BRSKI do not leverage 1437 a voucher mechanism to authenticate the ACP registrar and where 1438 therefore the injection of certificate failures could otherwise make 1439 the ACP node easily attackable remotely. 1441 When using BRSKI or other protocol/mechanisms supporting vouchers, 1442 maintaining existing trust anchor information allows for re- 1443 enrollment of expired ACP certificates to be more lightweight, 1444 especially in environments where repeated acquisition of vouchers 1445 during the lifetime of ACP nodes may be operationally expensive or 1446 otherwise undesirable. 1448 6.1.4.6. Failing Certificates 1450 An ACP domain certificate is called failing in this document, if/when 1451 the ACP node can determine that it was revoked (or explicitly not 1452 renewed), or in the absence of such explicit local diagnostics, when 1453 the ACP node fails to connect to other ACP nodes in the same ACP 1454 domain using its ACP certificate. For connection failures to 1455 determine the ACP domain certificate as the culprit, the peer should 1456 pass the domain membership check (Section 6.1.2) and other reasons 1457 for the connection failure can be excluded because of the connection 1458 error diagnostics. 1460 This type of failure can happen during setup/refresh of a secure ACP 1461 channel connections or any other use of the ACP domain certificate, 1462 such as for the TLS connection to an EST server for the renewal of 1463 the ACP domain certificate. 1465 Example reasons for failing certificates that the ACP node can only 1466 discover through connection failure are that the domain certificate 1467 or any of its signing certificates could have been revoked or may 1468 have expired, but the ACP node cannot self-diagnose this condition 1469 directly. Revocation information or clock synchronization may only 1470 be available across the ACP, but the ACP node cannot build ACP secure 1471 channels because ACP peers reject the ACP node's domain certificate. 1473 ACP nodes SHOULD support the option to determines whether its ACP 1474 certificate is failing, and when it does, put itself into the role of 1475 a re-enrolling candidate ACP node as explained above 1476 (Section 6.1.4.5). 1478 6.2. ACP Adjacency Table 1480 To know to which nodes to establish an ACP channel, every ACP node 1481 maintains an adjacency table. The adjacency table contains 1482 information about adjacent ACP nodes, at a minimum: Node-ID 1483 (identifier of the node inside the ACP, see Section 6.10.3 and 1484 Section 6.10.5), interface on which neighbor was discovered (by GRASP 1485 as explained below), link-local IPv6 address of neighbor on that 1486 interface, certificate (including domain information field). An ACP 1487 node MUST maintain this adjacency table. This table is used to 1488 determine to which neighbor an ACP connection is established. 1490 Where the next ACP node is not directly adjacent (i.e., not on a link 1491 connected to this node), the information in the adjacency table can 1492 be supplemented by configuration. For example, the Node-ID and IP 1493 address could be configured. See Section 8.2. 1495 The adjacency table MAY contain information about the validity and 1496 trust of the adjacent ACP node's certificate. However, subsequent 1497 steps MUST always start with the ACP domain membership check against 1498 the peer (see Section 6.1.2). 1500 The adjacency table contains information about adjacent ACP nodes in 1501 general, independently of their domain and trust status. The next 1502 step determines to which of those ACP nodes an ACP connection should 1503 be established. 1505 6.3. Neighbor Discovery with DULL GRASP 1507 [RFC Editor: GRASP draft is in RFC editor queue, waiting for 1508 dependencies, including ACP. Please ensure that references to I- 1509 D.ietf-anima-grasp that include section number references (throughout 1510 this document) will be updated in case any last-minute changes in 1511 GRASP would make those section references change. 1513 Discovery Unsolicited Link-Local (DULL) GRASP is a limited subset of 1514 GRASP intended to operate across an insecure link-local scope. See 1515 section 2.5.2 of [I-D.ietf-anima-grasp] for its formal definition. 1516 The ACP uses one instance of DULL GRASP for every L2 interface of the 1517 ACP node to discover link level adjacent candidate ACP neighbors. 1518 Unless modified by policy as noted earlier (Section 5 bullet point 1519 2.), native interfaces (e.g., physical interfaces on physical nodes) 1520 SHOULD be initialized automatically to a state in which ACP discovery 1521 can be performed and any native interfaces with ACP neighbors can 1522 then be brought into the ACP even if the interface is otherwise not 1523 configured. Reception of packets on such otherwise not configured 1524 interfaces MUST be limited so that at first only IPv6 StateLess 1525 Address Auto Configuration (SLAAC - [RFC4862]) and DULL GRASP work 1526 and then only the following ACP secure channel setup packets - but 1527 not any other unnecessary traffic (e.g., no other link-local IPv6 1528 transport stack responders for example). 1530 Note that the use of the IPv6 link-local multicast address 1531 (ALL_GRASP_NEIGHBORS) implies the need to use Multicast Listener 1532 Discovery Version 2 (MLDv2, see [RFC3810]) to announce the desire to 1533 receive packets for that address. Otherwise DULL GRASP could fail to 1534 operate correctly in the presence of MLD snooping, non-ACP enabled L2 1535 switches - because those would stop forwarding DULL GRASP packets. 1536 Switches not supporting MLD snooping simply need to operate as pure 1537 L2 bridges for IPv6 multicast packets for DULL GRASP to work. 1539 ACP discovery SHOULD NOT be enabled by default on non-native 1540 interfaces. In particular, ACP discovery MUST NOT run inside the ACP 1541 across ACP virtual interfaces. See Section 10.3 for further, non- 1542 normative suggestions on how to enable/disable ACP at node and 1543 interface level. See Section 8.2.2 for more details about tunnels 1544 (typical non-native interfaces). See Section 7 for how ACP should be 1545 extended on devices operating (also) as L2 bridges. 1547 Note: If an ACP node also implements BRSKI to enroll its ACP domain 1548 certificate (see Appendix A.2 for a summary), then the above 1549 considerations also apply to GRASP discovery for BRSKI. Each DULL 1550 instance of GRASP set up for ACP is then also used for the discovery 1551 of a bootstrap proxy via BRSKI when the node does not have a domain 1552 certificate. Discovery of ACP neighbors happens only when the node 1553 does have the certificate. The node therefore never needs to 1554 discover both a bootstrap proxy and ACP neighbor at the same time. 1556 An ACP node announces itself to potential ACP peers by use of the 1557 "AN_ACP" objective. This is a synchronization objective intended to 1558 be flooded on a single link using the GRASP Flood Synchronization 1559 (M_FLOOD) message. In accordance with the design of the Flood 1560 message, a locator consisting of a specific link-local IP address, IP 1561 protocol number and port number will be distributed with the flooded 1562 objective. An example of the message is informally: 1564 [M_FLOOD, 12340815, h'fe80000000000000c0011001FEEF0000, 210000, 1565 ["AN_ACP", 4, 1, "IKEv2" ], 1566 [O_IPv6_LOCATOR, 1567 h'fe80000000000000c0011001FEEF0000, UDP, 15000] 1568 ["AN_ACP", 4, 1, "DTLS" ], 1569 [O_IPv6_LOCATOR, 1570 h'fe80000000000000c0011001FEEF0000, UDP, 17000] 1571 ] 1573 Figure 5: GRASP AN_ACP example 1575 The formal CDDL definition is: 1577 flood-message = [M_FLOOD, session-id, initiator, ttl, 1578 +[objective, (locator-option / [])]] 1580 objective = ["AN_ACP", objective-flags, loop-count, 1581 objective-value] 1583 objective-flags = sync-only ; as in the GRASP specification 1584 sync-only = 4 ; M_FLOOD only requires synchronization 1585 loop-count = 1 ; limit to link-local operation 1586 objective-value = method 1587 method = "IKEv2" / "DTLS" ; or future standard methods 1589 Figure 6: GRASP AN_ACP definition 1591 The objective-flags field is set to indicate synchronization. 1593 The loop-count is fixed at 1 since this is a link-local operation. 1595 In the above example the RECOMMENDED period of sending of the 1596 objective is 60 seconds. The indicated ttl of 210000 msec means that 1597 the objective would be cached by ACP nodes even when two out of three 1598 messages are dropped in transit. 1600 The session-id is a random number used for loop prevention 1601 (distinguishing a message from a prior instance of the same message). 1602 In DULL this field is irrelevant but must still be set according to 1603 the GRASP specification. 1605 The originator MUST be the IPv6 link local address of the originating 1606 ACP node on the sending interface. 1608 The 'objective-value' parameter is a string indicating the secure 1609 channel protocol available at the specified or implied locator. 1611 The locator-option is optional and only required when the secure 1612 channel protocol is not offered at a well-defined port number, or if 1613 there is no well-defined port number. 1615 "IKEv2" is the abbreviation for "Internet Key Exchange protocol 1616 version 2". It is the main protocol used by the Internet IP security 1617 architecture (IPsec). We therefore use the term "IKEv2" and not 1618 "IPsec" in the GRASP definitions and example above. "IKEv2" has a 1619 well-defined port number 500, but in the above example, the candidate 1620 ACP neighbor is offering ACP secure channel negotiation via IKEv2 on 1621 port 15000 (for the sake of creating a non-standard example). 1623 "DTLS" indicates datagram Transport Layer Security version 1.2. 1624 There is no default UDP port, it must always be locally assigned by 1625 the node. See Section 6.7.2. 1627 If a locator is included, it MUST be an O_IPv6_LOCATOR, and the IPv6 1628 address MUST be the same as the initiator address (these are DULL 1629 requirements to minimize third party DoS attacks). 1631 The secure channel methods defined in this document use the 1632 objective-values of "IKEv2" and "DTLS". There is no distinction 1633 between IKEv2 native and GRE-IKEv2 because this is purely negotiated 1634 via IKEv2. 1636 A node that supports more than one secure channel protocol method 1637 needs to flood multiple versions of the "AN_ACP" objective so that 1638 each method can be accompanied by its own locator-option. This can 1639 use a single GRASP M_FLOOD message as shown in Figure 5. 1641 Note that a node serving both as an ACP node and BRSKI Join Proxy may 1642 choose to distribute the "AN_ACP" objective and the respective BRSKI 1643 in the same M_FLOOD message, since GRASP allows multiple objectives 1644 in one message. This may be impractical though if ACP and BRSKI 1645 operations are implemented via separate software modules / ASAs. 1647 The result of the discovery is the IPv6 link-local address of the 1648 neighbor as well as its supported secure channel protocols (and non- 1649 standard port they are running on). It is stored in the ACP 1650 Adjacency Table (see Section 6.2), which then drives the further 1651 building of the ACP to that neighbor. 1653 6.4. Candidate ACP Neighbor Selection 1655 An ACP node must determine to which other ACP nodes in the adjacency 1656 table it should build an ACP connection. This is based on the 1657 information in the ACP Adjacency table. 1659 The ACP is established exclusively between nodes in the same domain. 1660 This includes all routing subdomains. Appendix A.7 explains how ACP 1661 connections across multiple routing subdomains are special. 1663 The result of the candidate ACP neighbor selection process is a list 1664 of adjacent or configured autonomic neighbors to which an ACP channel 1665 should be established. The next step begins that channel 1666 establishment. 1668 6.5. Channel Selection 1670 To avoid attacks, initial discovery of candidate ACP peers cannot 1671 include any non-protected negotiation. To avoid re-inventing and 1672 validating security association mechanisms, the next step after 1673 discovering the address of a candidate neighbor can only be to try 1674 first to establish a security association with that neighbor using a 1675 well-known security association method. 1677 At this time in the lifecycle of ACP nodes, it is unclear whether it 1678 is feasible to even decide on a single MTI (mandatory to implement) 1679 security association protocol across all ACP nodes. 1681 From the use-cases it seems clear that not all type of ACP nodes can 1682 or need to connect directly to each other or are able to support or 1683 prefer all possible mechanisms. For example, code space limited IoT 1684 devices may only support DTLS because that code exists already on 1685 them for end-to-end security, but low-end in-ceiling L2 switches may 1686 only want to support Media Access Control Security (MacSec, see 1687 802.1AE ([MACSEC]) because that is also supported in their chips. 1688 Only a flexible gateway device may need to support both of these 1689 mechanisms and potentially more. Note that MacSec is not required by 1690 any profiles of the ACP in this specification but just mentioned as a 1691 likely next interesting secure channel protocol. 1693 To support extensible secure channel protocol selection without a 1694 single common MTI protocol, ACP nodes must try all the ACP secure 1695 channel protocols it supports and that are feasible because the 1696 candidate ACP neighbor also announced them via its AN_ACP GRASP 1697 parameters (these are called the "feasible" ACP secure channel 1698 protocols). 1700 To ensure that the selection of the secure channel protocols always 1701 succeeds in a predictable fashion without blocking, the following 1702 rules apply: 1704 o An ACP node may choose to attempt to initiate the different 1705 feasible ACP secure channel protocols it supports according to its 1706 local policies sequentially or in parallel, but it MUST support 1707 acting as a responder to all of them in parallel. 1709 o Once the first secure channel protocol succeeds, the two peers 1710 know each other's certificates because they must be used by all 1711 secure channel protocols for mutual authentication. The node with 1712 the lower Node-ID in the ACP address becomes Bob, the one with the 1713 higher Node-ID in the certificate Alice. 1715 o Bob becomes passive, he does not attempt to further initiate ACP 1716 secure channel protocols with Alice and does not consider it to be 1717 an error when Alice closes secure channels. Alice becomes the 1718 active party, continues to attempt setting up secure channel 1719 protocols with Bob until she arrives at the best one from her view 1720 that also works with Bob. 1722 For example, originally Bob could have been the initiator of one ACP 1723 secure channel protocol that Bob prefers and the security association 1724 succeeded. The roles of Bob and Alice are then assigned and the 1725 connection setup is completed. The protocol could for example be 1726 IPsec via IKEv2 ("IP security", see [RFC4301] and "Internet Key 1727 Exchange protocol version 2", see [RFC7296]. It is now up to Alice 1728 to decide how to proceed. Even if the IPsec connection from Bob 1729 succeeded, Alice might prefer another secure protocol over IPsec 1730 (e.g., FOOBAR), and try to set that up with Bob. If that preference 1731 of Alice succeeds, she would close the IPsec connection. If no 1732 better protocol attempt succeeds, she would keep the IPsec 1733 connection. 1735 The following sequence of steps show this example in more detail: 1737 [1] Node 1 sends GRASP AN_ACP message to announce itself 1739 [2] Node 2 sends GRASP AN_ACP message to announce itself 1741 [3] Node 2 receives [1] from Node 1 1743 [4:C1] Because of [3], Node 2 starts as initiator on its 1744 preferred secure channel protocol towards Node 1. 1745 Connection C1. 1747 [5] Node 1 receives [2] from Node 2 1749 [6:C2] Because of [5], Node 1 starts as initiator on its 1750 preferred secure channel protocol towards Node 2. 1751 Connection C2. 1753 [7:C1] Node1 and Node2 have authenticated each others 1754 certificate on connection C1 as valid ACP peers. 1756 [8:C1] Node 1 certificate has lower ACP Node-ID than Node2, 1757 therefore Node 1 considers itself Bob and Node 2 Alice 1758 on connection C1. Connection setup C1 is completed. 1760 [9] Node 1 (Bob)) refrains from attempting any further secure 1761 channel connections to Node 2 (Alice) as learned from [2] 1762 because it knows from [8:C1] that it is Bob relative 1763 to Node 1. 1765 [10:C2] Node1 and Node2 have authenticated each others 1766 certificate on connection C2 (like [7:C1]). 1768 [11:C2] Node 2 certificate has lower ACP Node-ID than Node2, 1769 therefore Node 1 considers itself Bob and Node 2 Alice 1770 on connection C1, but they also identify that C2 is to the 1771 same mutual peer as their C1, so this has no further impact. 1773 [12:C2] Node 1 (Alice) closes C1. Because of [8:C1], Node 2 (Bob) 1774 expected this. 1776 [13] Node 1 (Alice) and Node 2 (Bob) start data transfer across 1777 C2, which makes it become a secure channel for the ACP. 1779 Figure 7: Secure Channel sequence of steps 1781 All this negotiation is in the context of an "L2 interface". Alice 1782 and Bob will build ACP connections to each other on every "L2 1783 interface" that they both connect to. An autonomic node must not 1784 assume that neighbors with the same L2 or link-local IPv6 addresses 1785 on different L2 interfaces are the same node. This can only be 1786 determined after examining the certificate after a successful 1787 security association attempt. 1789 6.6. Candidate ACP Neighbor verification 1791 Independent of the security association protocol chosen, candidate 1792 ACP neighbors need to be authenticated based on their domain 1793 certificate. This implies that any secure channel protocol MUST 1794 support certificate based authentication that can support the ACP 1795 domain membership check as defined in Section 6.1.2. If it fails, 1796 the connection attempt is aborted and an error logged. Attempts to 1797 reconnect MUST be throttled. The RECOMMENDED default is exponential 1798 base 2 backoff with a minimum delay of 10 seconds and a maximum delay 1799 of 640 seconds. 1801 6.7. Security Association protocols 1803 The following sections define the security association protocols that 1804 we consider to be important and feasible to specify in this document: 1806 6.7.1. ACP via IKEv2 1808 An ACP node announces its ability to support IKEv2 as the ACP secure 1809 channel protocol in GRASP as "IKEv2". 1811 6.7.1.1. Native IPsec 1813 To run ACP via IPsec natively, no further IANA assignments/ 1814 definitions are required. An ACP node that is supporting native 1815 IPsec MUST use IPsec security setup via IKEv2, tunnel mode, local and 1816 peer link-local IPv6 addresses used for encapsulation. It MUST then 1817 support ESP with AES-256-GCM ([RFC4106]) for encryption and SHA256 1818 hash and MUST NOT permit weaker crypto options. Key establishment 1819 MUST support ECDHE with P-256. 1821 In terms of IKEv2, this means the initiator will offer to support 1822 IPsec tunnel mode with next protocol equal to 41 (IPv6). 1824 IPsec tunnel mode is required because the ACP will route/forward 1825 packets received from any other ACP node across the ACP secure 1826 channels, and not only its own generated ACP packets. With IPsec 1827 transport mode, it would only be possible to send packets originated 1828 by the ACP node itself. 1830 ESP is used because ACP mandates the use of encryption for ACP secure 1831 channels. 1833 6.7.1.2. IPsec with GRE encapsulation 1835 In network devices it is often more common to implement high 1836 performance virtual interfaces on top of GRE encapsulation than on 1837 top of a "native" IPsec association (without any other encapsulation 1838 than those defined by IPsec). On those devices it may be beneficial 1839 to run the ACP secure channel on top of GRE protected by the IPsec 1840 association. 1842 To run ACP via GRE/IPsec, no further IANA assignments/definitions are 1843 required. An ACP node that is supporting ACP via GRE/IPsec MUST then 1844 support IPsec security setup via IKEv2, IPsec transport mode, local 1845 and peer link-local IPv6 addresses used for encapsulation, ESP with 1846 AES256 encryption and SHA256 hash. 1848 When GRE is used, transport mode is sufficient because the routed ACP 1849 packets are not "tunneled" by IPsec but rather by GRE: IPsec only has 1850 to deal with the GRE/IP packet which always uses the local and peer 1851 link-local IPv6 addresses and is therefore applicable to transport 1852 mode. 1854 ESP is used because ACP mandates the use of encryption for ACP secure 1855 channels. 1857 In terms of IKEv2 negotiation, this means the initiator must offer to 1858 support IPsec transport mode with next protocol equal to GRE (47) 1859 followed by the offer for native IPsec as described above (because 1860 that option is mandatory to support). 1862 If IKEv2 initiator and responder support GRE, it will be selected. 1863 The version of GRE to be used must be determined according to 1864 [RFC7676]. 1866 6.7.2. ACP via DTLS 1868 We define the use of ACP via DTLS in the assumption that it is likely 1869 the first transport encryption code basis supported in some classes 1870 of constrained devices. 1872 To run ACP via UDP and DTLS v1.2 [RFC6347] a locally assigned UDP 1873 port is used that is announced as a parameter in the GRASP AN_ACP 1874 objective to candidate neighbors. 1876 All ACP nodes supporting DTLS as a secure channel protocol MUST 1877 adhere to the DTLS implementation recommendations and security 1878 considerations of [RFC7525] except with respect to the DTLS version. 1879 ACP nodes supporting DTLS MUST implement only DTLS 1.2 or later. For 1880 example, implementing DTLS-1.3 ([I-D.ietf-tls-dtls13]) is also an 1881 option. 1883 There is no additional session setup or other security association 1884 besides this simple DTLS setup. As soon as the DTLS session is 1885 functional, the ACP peers will exchange ACP IPv6 packets as the 1886 payload of the DTLS transport connection. Any DTLS defined security 1887 association mechanisms such as re-keying are used as they would be 1888 for any transport application relying solely on DTLS. 1890 6.7.3. ACP Secure Channel Requirements 1892 As explained in the beginning of Section 6.5, there is no single 1893 secure channel mechanism mandated for all ACP nodes. Instead, this 1894 section defines two ACP profiles (baseline and constrained) for ACP 1895 nodes that do introduce such requirements. 1897 A baseline ACP node MUST support IPsec natively and MAY support IPsec 1898 via GRE. A constrained ACP node that cannot support IPsec MUST 1899 support DTLS. An ACP node connecting an area of constrained ACP 1900 nodes with an area of baseline ACP nodes MUST therefore support IPsec 1901 and DTLS and supports therefore the baseline and constrained profile. 1903 Explanation: Not all type of ACP nodes can or need to connect 1904 directly to each other or are able to support or prefer all possible 1905 secure channel mechanisms. For example, code space limited IoT 1906 devices may only support DTLS because that code exists already on 1907 them for end-to-end security, but high-end core routers may not want 1908 to support DTLS because they can perform IPsec in accelerated 1909 hardware but would need to support DTLS in an underpowered CPU 1910 forwarding path shared with critical control plane operations. This 1911 is not a deployment issue for a single ACP across these type of nodes 1912 as long as there are also appropriate gateway ACP nodes that support 1913 sufficiently many secure channel mechanisms to allow interconnecting 1914 areas of ACP nodes with a more constrained set of secure channel 1915 protocols. On the edge between IoT areas and high-end core networks, 1916 general-purpose routers that act as those gateways and that can 1917 support a variety of secure channel protocols is the norm already. 1919 ACP nodes need to specify in documentation the set of secure ACP 1920 mechanisms they support and should declare which profile they support 1921 according to above requirements. 1923 An ACP secure channel MUST immediately be terminated when the 1924 lifetime of any certificate in the chain used to authenticate the 1925 neighbor expires or becomes revoked. Note that this is not standard 1926 behavior in secure channel protocols such as IPsec because the 1927 certificate authentication only influences the setup of the secure 1928 channel in these protocols. 1930 6.8. GRASP in the ACP 1932 6.8.1. GRASP as a core service of the ACP 1934 The ACP MUST run an instance of GRASP inside of it. It is a key part 1935 of the ACP services. The function in GRASP that makes it fundamental 1936 as a service of the ACP is the ability to provide ACP wide service 1937 discovery (using objectives in GRASP). 1939 ACP provides IP unicast routing via the RPL routing protocol (see 1940 Section 6.11). 1942 The ACP does not use IP multicast routing nor does it provide generic 1943 IP multicast services (the handling of GRASP link-local multicast 1944 messages is explained in Section 6.8.2). Instead, the ACP provides 1945 service discovery via the objective discovery/announcement and 1946 negotiation mechanisms of the ACP GRASP instance (services are a form 1947 of objectives). These mechanisms use hop-by-hop reliable flooding of 1948 GRASP messages for both service discovery (GRASP M_DISCOVERY 1949 messages) and service announcement (GRASP M_FLOOD messages). 1951 See Appendix A.5 for discussion about this design choice of the ACP. 1953 6.8.2. ACP as the Security and Transport substrate for GRASP 1955 In the terminology of GRASP ([I-D.ietf-anima-grasp]), the ACP is the 1956 security and transport substrate for the GRASP instance run inside 1957 the ACP ("ACP GRASP"). 1959 This means that the ACP is responsible for ensuring that this 1960 instance of GRASP is only sending messages across the ACP GRASP 1961 virtual interfaces. Whenever the ACP adds or deletes such an 1962 interface because of new ACP secure channels or loss thereof, the ACP 1963 needs to indicate this to the ACP instance of GRASP. The ACP exists 1964 also in the absence of any active ACP neighbors. It is created when 1965 the node has a domain certificate, and continues to exist even if all 1966 of its neighbors cease operation. 1968 In this case ASAs using GRASP running on the same node would still 1969 need to be able to discover each other's objectives. When the ACP 1970 does not exist, ASAs leveraging the ACP instance of GRASP via APIs 1971 MUST still be able to operate, and MUST be able to understand that 1972 there is no ACP and that therefore the ACP instance of GRASP cannot 1973 operate. 1975 The way ACP acts as the security and transport substrate for GRASP is 1976 visualized in the following picture: 1978 ..............................ACP.............................. 1979 . . 1980 . /-GRASP-flooding-\ ACP GRASP instance . 1981 . / \ A 1982 . GRASP GRASP GRASP C 1983 . link-local unicast link-local P 1984 . multicast messages multicast . 1985 . messages | messages . 1986 . | | | . 1987 ............................................................... 1988 . v v v ACP security and transport . 1989 . | | | substrate for GRASP . 1990 . | | | . 1991 . | ACP GRASP | - ACP GRASP A 1992 . | Loopback | Loopback interface C 1993 . | interface | - ACP-cert auth P 1994 . | TLS | . 1995 . ACP GRASP | ACP GRASP - ACP GRASP virtual . 1996 . subnet1 | subnet2 virtual interfaces . 1997 . TCP | TCP . 1998 . | | | . 1999 ............................................................... 2000 . | | | ^^^ Users of ACP (GRASP/ASA) . 2001 . | | | ACP interfaces/addressing . 2002 . | | | . 2003 . | | | A 2004 . | ACP-Loopback Interf.| <- ACP Loopback interface C 2005 . | ACP-address | - address (global ULA) P 2006 . subnet1 | subnet2 <- ACP virtual interfaces . 2007 . link-local | link-local - link-local addresses . 2008 ............................................................... 2009 . | | | ACP VRF . 2010 . | RPL-routing | virtual routing and forwarding . 2011 . | /IP-Forwarding\ | A 2012 . | / \ | C 2013 . ACP IPv6 packets ACP IPv6 packets P 2014 . |/ \| . 2015 . IPsec/DTLS IPsec/DTLS - ACP-cert auth . 2016 ............................................................... 2017 | | Data-Plane 2018 | | 2019 | | - ACP secure channel 2020 link-local link-local - encapsulation addresses 2021 subnet1 subnet2 - Data-Plane interfaces 2022 | | 2023 ACP-Nbr1 ACP-Nbr2 2025 Figure 8: ACP as security and transport substrate for GRASP 2027 GRASP unicast messages inside the ACP always use the ACP address. 2028 Link-local addresses from the ACP VRF must not be used inside 2029 objectives. GRASP unicast messages inside the ACP are transported 2030 via TLS 1.2 ([RFC5246]) connections with AES256 encryption and 2031 SHA256. Mutual authentication uses the ACP domain membership check 2032 defined in (Section 6.1.2). 2034 GRASP link-local multicast messages are targeted for a specific ACP 2035 virtual interface (as defined Section 6.12.5) but are sent by the ACP 2036 into an ACP GRASP virtual interface that is constructed from the TCP 2037 connection(s) to the IPv6 link-local neighbor address(es) on the 2038 underlying ACP virtual interface. If the ACP GRASP virtual interface 2039 has two or more neighbors, the GRASP link-local multicast messages 2040 are replicated to all neighbor TCP connections. 2042 TCP and TLS connections for GRASP in the ACP use the IANA assigned 2043 TCP port for GRASP (7107). Effectively the transport stack is 2044 expected to be TLS for connections from/to the ACP address (e.g., 2045 global scope address(es)) and TCP for connections from/to link-local 2046 addresses on the ACP virtual interfaces. The latter ones are only 2047 used for flooding of GRASP messages. 2049 6.8.2.1. Discussion 2051 TCP encapsulation for GRASP M_DISCOVERY and M_FLOOD link local 2052 messages is used because these messages are flooded across 2053 potentially many hops to all ACP nodes and a single link with even 2054 temporary packet loss issues (e.g., WiFi/Powerline link) can reduce 2055 the probability for loss free transmission so much that applications 2056 would want to increase the frequency with which they send these 2057 messages. Such shorter periodic retransmission of datagrams would 2058 result in more traffic and processing overhead in the ACP than the 2059 hop-by-hop reliable retransmission mechanism by TCP and duplicate 2060 elimination by GRASP. 2062 TLS is mandated for GRASP non-link-local unicast because the ACP 2063 secure channel mandatory authentication and encryption protects only 2064 against attacks from the outside but not against attacks from the 2065 inside: Compromised ACP members that have (not yet) been detected and 2066 removed (e.g., via domain certificate revocation / expiry). 2068 If GRASP peer connections would just use TCP, compromised ACP members 2069 could simply eavesdrop passively on GRASP peer connections for whom 2070 they are on-path ("Man In The Middle" - MITM). Or intercept and 2071 modify them. With TLS, it is not possible to completely eliminate 2072 problems with compromised ACP members, but attacks are a lot more 2073 complex: 2075 Eavesdropping/spoofing by a compromised ACP node is still possible 2076 because in the model of the ACP and GRASP, the provider and consumer 2077 of an objective have initially no unique information (such as an 2078 identity) about the other side which would allow them to distinguish 2079 a benevolent from a compromised peer. The compromised ACP node would 2080 simply announce the objective as well, potentially filter the 2081 original objective in GRASP when it is a MITM and act as an 2082 application level proxy. This of course requires that the 2083 compromised ACP node understand the semantics of the GRASP 2084 negotiation to an extent that allows it to proxy it without being 2085 detected, but in an ACP environment this is quite likely public 2086 knowledge or even standardized. 2088 The GRASP TLS connections are run the same as any other ACP traffic 2089 through the ACP secure channels. This leads to double 2090 authentication/encryption, which has the following benefits: 2092 o Secure channel methods such as IPsec may provide protection 2093 against additional attacks, for example reset-attacks. 2095 o The secure channel method may leverage hardware acceleration and 2096 there may be little or no gain in eliminating it. 2098 o There is no different security model for ACP GRASP from other ACP 2099 traffic. Instead, there is just another layer of protection 2100 against certain attacks from the inside which is important due to 2101 the role of GRASP in the ACP. 2103 6.9. Context Separation 2105 The ACP is in a separate context from the normal Data-Plane of the 2106 node. This context includes the ACP channels' IPv6 forwarding and 2107 routing as well as any required higher layer ACP functions. 2109 In classical network system, a dedicated so called Virtual routing 2110 and forwarding instance (VRF) is one logical implementation option 2111 for the ACP. If possible by the systems software architecture, 2112 separation options that minimize shared components are preferred, 2113 such as a logical container or virtual machine instance. The context 2114 for the ACP needs to be established automatically during bootstrap of 2115 a node. As much as possible it should be protected from being 2116 modified unintentionally by ("Data-Plane") configuration. 2118 Context separation improves security, because the ACP is not 2119 reachable from the Data-Plane routing or forwarding table(s). Also, 2120 configuration errors from the Data-Plane setup do not affect the ACP. 2122 6.10. Addressing inside the ACP 2124 The channels explained above typically only establish communication 2125 between two adjacent nodes. In order for communication to happen 2126 across multiple hops, the autonomic control plane requires ACP 2127 network wide valid addresses and routing. Each ACP node must create 2128 a Loopback interface with an ACP network wide unique address inside 2129 the ACP context (as explained in in Section 6.9). This address may 2130 be used also in other virtual contexts. 2132 With the algorithm introduced here, all ACP nodes in the same routing 2133 subdomain have the same /48 ULA prefix. Conversely, ULA global IDs 2134 from different domains are unlikely to clash, such that two ACP 2135 networks can be merged, as long as the policy allows that merge. See 2136 also Section 9.1 for a discussion on merging domains. 2138 Links inside the ACP only use link-local IPv6 addressing, such that 2139 each nodes ACP only requires one routable virtual address. 2141 6.10.1. Fundamental Concepts of Autonomic Addressing 2143 o Usage: Autonomic addresses are exclusively used for self- 2144 management functions inside a trusted domain. They are not used 2145 for user traffic. Communications with entities outside the 2146 trusted domain use another address space, for example normally 2147 managed routable address space (called "Data-Plane" in this 2148 document). 2150 o Separation: Autonomic address space is used separately from user 2151 address space and other address realms. This supports the 2152 robustness requirement. 2154 o Loopback-only: Only ACP Loopback interfaces (and potentially those 2155 configured for "ACP connect", see Section 8.1) carry routable 2156 address(es); all other interfaces (called ACP virtual interfaces) 2157 only use IPv6 link local addresses. The usage of IPv6 link local 2158 addressing is discussed in [RFC7404]. 2160 o Use-ULA: For Loopback interfaces of ACP nodes, we use Unique Local 2161 Addresses (ULA), as defined in [RFC4193] with L=1 (as defined in 2162 section 3.1 of [RFC4193]). Note that the random hash for ACP 2163 Loopback addresses uses the definition in Section 6.10.2 and not 2164 the one of [RFC4193] section 3.2.2. 2166 o No external connectivity: They do not provide access to the 2167 Internet. If a node requires further reaching connectivity, it 2168 should use another, traditionally managed address scheme in 2169 parallel. 2171 o Addresses in the ACP are permanent, and do not support temporary 2172 addresses as defined in [RFC4941]. 2174 o Addresses in the ACP are not considered sensitive on privacy 2175 grounds because ACP nodes are not expected to be end-user host. 2176 All ACP nodes are in one (potentially federated) administrative 2177 domain. They are assumed to be to be candidate hosts of ACP 2178 traffic amongst each other or transit thereof. There are no 2179 transit nodes less privileged to know about the identity of other 2180 hosts in the ACP. Therefore, ACP addresses do not need to be 2181 pseudo-random as discussed in [RFC7721]. Because they are not 2182 propagated to untrusted (non ACP) nodes and stay within a domain 2183 (of trust), we also consider them not to be subject to scanning 2184 attacks. 2186 The ACP is based exclusively on IPv6 addressing, for a variety of 2187 reasons: 2189 o Simplicity, reliability and scale: If other network layer 2190 protocols were supported, each would have to have its own set of 2191 security associations, routing table and process, etc. 2193 o Autonomic functions do not require IPv4: Autonomic functions and 2194 autonomic service agents are new concepts. They can be 2195 exclusively built on IPv6 from day one. There is no need for 2196 backward compatibility. 2198 o OAM protocols do not require IPv4: The ACP may carry OAM 2199 protocols. All relevant protocols (SNMP, TFTP, SSH, SCP, Radius, 2200 Diameter, ...) are available in IPv6. See also [RFC8368] for how 2201 ACP could be made to interoperate with IPv4 only OAM. 2203 6.10.2. The ACP Addressing Base Scheme 2205 The Base ULA addressing scheme for ACP nodes has the following 2206 format: 2208 8 40 2 78 2209 +--+-------------------------+------+------------------------------+ 2210 |fd| hash(routing-subdomain) | Type | (sub-scheme) | 2211 +--+-------------------------+------+------------------------------+ 2213 Figure 9: ACP Addressing Base Scheme 2215 The first 48-bits follow the ULA scheme, as defined in [RFC4193], to 2216 which a type field is added: 2218 o "fd" identifies a locally defined ULA address. 2220 o The 40-bits ULA "global ID" (term from [RFC4193]) for ACP 2221 addresses carried in the domain information field of domain 2222 certificates are the first 40-bits of the SHA256 hash of the 2223 routing subdomain from the same domain information field. In the 2224 example of Section 6.1.1, the routing subdomain is 2225 "area51.research.acp.example.com" and the 40-bits ULA "global ID" 2226 89b714f3db. 2228 o When creating a new routing-subdomain for an existing autonomic 2229 network, it MUST be ensured, that rsub is selected so the 2230 resulting hash of the routing-subdomain does not collide with the 2231 hash of any pre-existing routing-subdomains of the autonomic 2232 network. This ensures that ACP addresses created by registrars 2233 for different routing subdomains do not collide with each others. 2235 o To allow for extensibility, the fact that the ULA "global ID" is a 2236 hash of the routing subdomain SHOULD NOT be assumed by any ACP 2237 node during normal operations. The hash function is only executed 2238 during the creation of the certificate. If BRSKI is used then the 2239 BRSKI registrar will create the domain information field in 2240 response to the EST Certificate Signing Request (CSR) Attribute 2241 Request message by the pledge. 2243 o Establishing connectivity between different ACP (different acp- 2244 domain-name) is outside the scope of this specification. If it is 2245 being done through future extensions, then the rsub of all 2246 routing-subdomains across those autonomic networks need to be 2247 selected so their hashes do not collide. For example a large 2248 cooperation with its own private Trust Anchor may want to create 2249 different autonomic networks that initially should not be able to 2250 connect but where the option to do so should be kept open. When 2251 taking this future possibility into account, it is easy to always 2252 select rsub so that no collisions happen. 2254 o Type: This field allows different address sub-schemes. This 2255 addresses the "upgradability" requirement. Assignment of types 2256 for this field will be maintained by IANA. 2258 The sub-scheme may imply a range or set of addresses assigned to the 2259 node, this is called the ACP address range/set and explained in each 2260 sub-scheme. 2262 Please refer to Section 6.10.7 and Appendix A.1 for further 2263 explanations why the following Sub-Addressing schemes are used and 2264 why multiple are necessary. 2266 6.10.3. ACP Zone Addressing Sub-Scheme 2268 The sub-scheme defined here is defined by the Type value 00b (zero) 2269 in the base scheme and 0 in the Z bit. 2271 64 64 2272 +-----------------+---+---------++-----------------------------+---+ 2273 | (base scheme) | Z | Zone-ID || Node-ID | 2274 | | | || Registrar-ID | Node-Number| V | 2275 +-----------------+---+---------++--------------+--------------+---+ 2276 50 1 13 48 15 1 2278 Figure 10: ACP Zone Addressing Sub-Scheme 2280 The fields are defined as follows: 2282 o Zone-ID: If set to all zero bits: The Node-ID bits are used as an 2283 identifier (as opposed to a locator). This results in a non- 2284 hierarchical, flat addressing scheme. Any other value indicates a 2285 zone. See Section 6.10.3.1 on how this field is used in detail. 2287 o Z: MUST be 0. 2289 o Node-ID: A unique value for each node. 2291 The 64-bit Node-ID is derived and composed as follows: 2293 o Registrar-ID (48-bit): A number unique inside the domain that 2294 identifies the ACP registrar which assigned the Node-ID to the 2295 node. A MAC address of the ACP registrar can be used for this 2296 purpose. 2298 o Node-Number: A number which is unique for a given ACP registrar, 2299 to identify the node. This can be a sequentially assigned number. 2301 o V (1-bit): Virtualization bit: 0: Indicates the ACP itself ("ACP 2302 node base system); 1: Indicates the optional "host" context on the 2303 ACP node (see below). 2305 In the ACP Zone Addressing Sub-Scheme, the ACP address in the 2306 certificate has Zone-ID and V fields as all zero bits. The ACP 2307 address set includes addresses with any Zone-ID value and any V 2308 value. 2310 The "Node-ID" itself is unique in a domain (i.e., the Zone-ID is not 2311 required for uniqueness). Therefore, a node can be addressed either 2312 as part of a flat hierarchy (Zone-ID = 0), or with an aggregation 2313 scheme (any other Zone-ID). An address with Zone-ID = 0 is an 2314 identifier, with a Zone-ID !=0 it is a locator. See Section 6.10.3.1 2315 for more details. 2317 The Virtual bit in this sub-scheme allows the easy addition of the 2318 ACP as a component to existing systems without causing problems in 2319 the port number space between the services in the ACP and the 2320 existing system. V:0 is the ACP router (autonomic node base system), 2321 V:1 is the host with pre-existing transport endpoints on it that 2322 could collide with the transport endpoints used by the ACP router. 2323 The ACP host could for example have a p2p virtual interface with the 2324 V:0 address as its router into the ACP. Depending on the software 2325 design of ASAs, which is outside the scope of this specification, 2326 they may use the V:0 or V:1 address. 2328 The location of the V bit(s) at the end of the address allows the 2329 announcement of a single prefix for each ACP node. For example, in a 2330 network with 20,000 ACP nodes, this avoid 20,000 additional routes in 2331 the routing table. 2333 6.10.3.1. Usage of the Zone-ID Field 2335 The Zone-ID allows for the introduction of route prefixes in the 2336 addressing scheme. 2338 Zone-ID = 0 is the default addressing scheme in an ACP domain. Every 2339 ACP node with a Zone Addressing Sub-Scheme address MUST respond to 2340 its ACP address with Zone-ID = 0. Used on its own this leads to a 2341 non-hierarchical address scheme, which is suitable for networks up to 2342 a certain size. Zone-ID = 0 addresses act as identifiers for the 2343 nodes, and aggregation of these address in the ACP routing table is 2344 not possible. 2346 If aggregation is required, the 13-bit Zone-ID value allows for up to 2347 8191 zones. The allocation of Zone-ID's may either happen 2348 automatically through a to-be-defined algorithm; or it could be 2349 configured and maintained explicitly. 2351 If a node learns (see Appendix A.10.1) that it is part of a zone, it 2352 MUST also respond to its ACP address with that Zone-ID. In this case 2353 the ACP Loopback is configured with two ACP addresses: One for Zone- 2354 ID = 0 and one for the assigned Zone-ID. This method allows for a 2355 smooth transition between a flat addressing scheme and a hierarchical 2356 one. 2358 A node knowing it is in a zone MUST use that Zone-ID != 0 address in 2359 GRASP locator fields. This eliminates the use of the identifier 2360 address (Zone-ID = 0) in forwarding and the need for network wide 2361 reachability of those non-aggregable identifier addresses. Zone-ID 2362 != 0 addresses are assumed to be aggregable in routing/forwarding 2363 based on how they are allocated in the ACP topology. 2365 Note: The Zone-ID is one method to introduce structure or hierarchy 2366 into the ACP. Another way is the use of the routing subdomain field 2367 in the ACP that leads to multiple /48 Global IDs within an ACP 2368 domain. 2370 Note: Zones and Zone-ID as defined here are not related to [RFC4007] 2371 zones or zone_id. ACP zone addresses are not scoped (reachable only 2372 from within an RFC4007 zone) but reachable across the whole ACP. An 2373 RFC4007 zone_id is a zone index that has only local significance on a 2374 node, whereas an ACP Zone-ID is an identifier for an ACP zone that is 2375 unique across that ACP. 2377 6.10.4. ACP Manual Addressing Sub-Scheme 2379 The sub-scheme defined here is defined by the Type value 00b (zero) 2380 in the base scheme and 1 in the Z bit. 2382 64 64 2383 +---------------------+---+----------++-----------------------------+ 2384 | (base scheme) | Z | Subnet-ID|| Interface Identifier | 2385 +---------------------+---+----------++-----------------------------+ 2386 50 1 13 2388 Figure 11: ACP Manual Addressing Sub-Scheme 2390 The fields are defined as follows: 2392 o Subnet-ID: Configured subnet identifier. 2394 o Z: MUST be 1. 2396 o Interface Identifier. 2398 This sub-scheme is meant for "manual" allocation to subnets where the 2399 other addressing schemes cannot be used. The primary use case is for 2400 assignment to ACP connect subnets (see Section 8.1.1). 2402 "Manual" means that allocations of the Subnet-ID need to be done 2403 today with pre-existing, non-autonomic mechanisms. Every subnet that 2404 uses this addressing sub-scheme needs to use a unique Subnet-ID 2405 (unless some anycast setup is done). 2407 The Z bit field was added to distinguish Zone addressing and manual 2408 addressing sub-schemes without requiring one more bit in the base 2409 scheme and therefore allowing for the Vlong scheme (described below) 2410 to have one more bit available. 2412 Manual addressing sub-scheme addresses SHOULD NOT be used in ACP 2413 domain certificates. Any node capable to build ACP secure channels 2414 and permitted by Registrar policy to participate in building ACP 2415 secure channels SHOULD receive an ACP address (prefix) from one of 2416 the other ACP addressing sub-schemes. Nodes not capable (or 2417 permitted) to participate in ACP secure channels can connect to the 2418 ACP via ACP connect interfaces of ACP edge nodes (see Section 8.1), 2419 without setting up an ACP secure channel. Their ACP domain 2420 certificate MUST include an empty acp-address to indicate that their 2421 ACP domain certificate is only usable for non- ACP secure channel 2422 authentication, such as end-to-end transport connections across the 2423 ACP or Data-Plane. 2425 Address management of ACP connect subnets is done using traditional 2426 assignment methods and existing IPv6 protocols. See Section 8.1.3 2427 for details. 2429 6.10.5. ACP Vlong Addressing Sub-Scheme 2431 The sub-scheme defined here is defined by the Type value 01b (one) in 2432 the base scheme. 2434 50 78 2435 +---------------------++-----------------------------+----------+ 2436 | (base scheme) || Node-ID | 2437 | || Registrar-ID | Node-Number| V | 2438 +---------------------++--------------+--------------+----------+ 2439 50 46 24/16 8/16 2441 Figure 12: ACP Vlong Addressing Sub-Scheme 2443 This addressing scheme foregoes the Zone-ID field to allow for 2444 larger, flatter routed networks (e.g., as in IoT) with 8421376 Node- 2445 Numbers (2^23+2^15). It also allows for up to 2^16 (i.e. 65536) 2446 different virtualized addresses within a node, which could be used to 2447 address individual software components in an ACP node. 2449 The fields are the same as in the Zone-ID sub-scheme with the 2450 following refinements: 2452 o V: Virtualization field: 8 or 16 bit. Values 0 and 1 are assigned 2453 in the same way as in the Zone-ID sub-scheme, the other values are 2454 for further use by the node. 2456 o Registrar-ID: To maximize Node-Number and V, the Registrar-ID is 2457 reduced to 46-bits. This still permits the use of the MAC address 2458 of an ACP registrar by removing the V and U bits from the 48-bits 2459 of a MAC address (those two bits are never unique, so they cannot 2460 be used to distinguish MAC addresses). 2462 o If the first bit of the "Node-Number" is "1", then the Node-Number 2463 is 16-bit long and the V field is 16-bit long. Otherwise the 2464 Node-Number is 24-bit long and the V field is 8-bit long. 2466 "0" bit Node-Numbers are intended to be used for "general purpose" 2467 ACP nodes that would potentially have a limited number (< 256) of 2468 clients (ASA/Autonomic Functions or legacy services) of the ACP that 2469 require separate V(irtual) addresses. "1" bit Node-Numbers are 2470 intended for ACP nodes that are ACP edge nodes (see Section 8.1.1) or 2471 that have a large number of clients requiring separate V(irtual) 2472 addresses. For example large SDN controllers with container modular 2473 software architecture (see Section 8.1.2). 2475 In the Vlong addressing sub-scheme, the ACP address in the 2476 certificate has all V field bits as zero. The ACP address set for 2477 the node includes any V value. 2479 6.10.6. Other ACP Addressing Sub-Schemes 2481 Before further addressing sub-schemes are defined, experience with 2482 the schemes defined here should be collected. The schemes defined in 2483 this document have been devised to allow hopefully sufficiently 2484 flexible setup of ACPs for a variety of situation. These reasons 2485 also lead to the fairly liberal use of address space: The Zone 2486 Addressing Sub-Scheme is intended to enable optimized routing in 2487 large networks by reserving bits for Zone-ID's. The Vlong addressing 2488 sub-scheme enables the allocation of 8/16-bit of addresses inside 2489 individual ACP nodes. Both address spaces allow distributed, 2490 uncoordinated allocation of node addresses by reserving bits for the 2491 registrar-ID field in the address. 2493 IANA is asked need to assign a new "type" for each new addressing 2494 sub-scheme. With the current allocations, only 2 more schemes are 2495 possible, so the last addressing scheme MUST provide further 2496 extensions (e.g., by reserving bits from it for further extensions). 2498 6.10.7. ACP Registrars 2500 ACP registrars are responsible to enroll candidate ACP nodes with ACP 2501 domain certificates and associated trust point(s). They are also 2502 responsible that an ACP domain information field is included in the 2503 ACP domain certificate carrying the ACP domain name and the ACP nodes 2504 ACP address prefix. This address prefix is intended to persist 2505 unchanged through the lifetime of the ACP node. 2507 Because of the ACP addressing sub-schemes, an ACP domain can have 2508 multiple distributed ACP registrars that do not need to coordinate 2509 for address assignment. ACP registrars can also be sub-CAs, in which 2510 case they can also assign ACP domain certificates without 2511 dependencies against a (shared) root-CA (except during renewals of 2512 their own certificates). 2514 ACP registrars are PKI registration authorities (RA) enhanced with 2515 the handling of the ACP domain certificate specific fields. They 2516 request certificates for ACP nodes from a Certificate Authority 2517 through any appropriate mechanism (out of scope in this document, but 2518 required to be BRSKI for ANI registrars). Only nodes that are 2519 trusted to be compliant with the requirements against registrar 2520 described in this section must be given the necessary credentials to 2521 perform this RA function, such as credentials for the BRSKI 2522 connection to the CA for ANI registrars. 2524 6.10.7.1. Use of BRSKI or other Mechanism/Protocols 2526 Any protocols or mechanisms may be used as ACP registrars, as long as 2527 the resulting ACP certificate and trust anchors allow to perform the 2528 ACP domain membership described in Section 6.1.2 with other ACP 2529 domain members, and meet the ACP addressing requirements for its ACP 2530 domain information field as described further below in this section. 2532 An ACP registrar could be a person deciding whether to enroll a 2533 candidate ACP node and then orchestrating the enrollment of the ACP 2534 certificate and associated trust anchor, using command line or web 2535 based commands on the candidate ACP node and trust anchor to generate 2536 and sign the ACP domain certificate and configure certificate and 2537 trust anchors onto the node. 2539 The only currently defined protocol for ACP registrars is BRSKI 2540 ([I-D.ietf-anima-bootstrapping-keyinfra]). When BRSKI is used, the 2541 ACP nodes are called ANI nodes, and the ACP registrars are called 2542 BRSKI or ANI registrars. The BRSKI specification does not define the 2543 handling of the ACP domain information field because the rules do not 2544 depend on BRSKI but apply equally to any protocols/mechanisms an ACP 2545 registrar may use. 2547 6.10.7.2. Unique Address/Prefix allocation 2549 ACP registrars MUST NOT allocate ACP address prefixes to ACP nodes 2550 via the ACP domain information field that would collide with the ACP 2551 address prefixes of other ACP nodes in the same ACP domain. This 2552 includes both prefixes allocated by the same ACP registrar to 2553 different ACP nodes as well as prefixes allocated by other ACP 2554 registrars for the same ACP domain. 2556 For this purpose, an ACP registrar MUST have one or more unique 2557 46-bit identifiers called Registrar-IDs used to allocate ACP address 2558 prefixes. The lower 46-bits of a EUI-48 MAC addresses are globally 2559 unique 46 bit identifiers, so ACP registrars with known unique EUI-48 2560 MAC addresses can use these as Registrar-IDs. Registrar-IDs do not 2561 need to be globally unique but only unique across the set of ACP 2562 registrars for an ACP domain, so other means to assign unique 2563 Registrar-IDs to ACP registrars can be used, such as configuration on 2564 the ACP registrars. 2566 When the candidate ACP device (called Pledge in BRSKI) is to be 2567 enrolled into an ACP domain, the ACP registrar needs to allocate a 2568 unique ACP address to the node and ensure that the ACP certificate 2569 gets a domain information field (Section 6.1.1) with the appropriate 2570 information - ACP domain-name, ACP-address, and so on. If the ACP 2571 registrar uses BRSKI, it signals the ACP domain information field to 2572 the Pledge via the EST /csraddrs command (see 2573 [I-D.ietf-anima-bootstrapping-keyinfra], section 5.8.2 - "EST CSR 2574 Attributes"). 2576 [RFC Editor: please update reference to section 5.8.2 accordingly 2577 with latest BRSKI draft at time of publishing, or RFC] 2579 6.10.7.3. Addressing Sub-Scheme Policies 2581 The ACP registrar selects for the candidate ACP node a unique address 2582 prefix from an appropriate ACP addressing sub-scheme, either a zone 2583 addressing sub-scheme prefix (see Section 6.10.3), or a Vlong 2584 addressing sub-scheme prefix (see Section 6.10.5). The assigned ACP 2585 address prefix encoded in the domain information field of the ACP 2586 domain certificate indicates to the ACP node its ACP address 2587 information. The sub-addressing scheme indicates the prefix length: 2588 /127 for zone address sub-scheme, /120 or /112 for Vlong address sub- 2589 scheme. The first address of the prefix is the ACP address, all 2590 other addresses in the prefix are for other uses by the ACP node as 2591 described in the zone and Vlong addressing sub scheme sections. The 2592 ACP address prefix itself is then signaled by the ACP node into the 2593 ACP routing protocol (see Section 6.11) to establish IPv6 2594 reachability across the ACP. 2596 The choice of addressing sub-scheme and prefix-length in the Vlong 2597 address sub-scheme is subject to ACP registrar policy. It could be 2598 an ACP domain wide policy, or a per ACP node or per ACP node type 2599 policy. For example, in BRSKI, the ACP registrar is aware of the 2600 IDevID of the candidate ACP node, which contains a serialNnumber that 2601 is typically indicating the nodes vendor and device type and can be 2602 used to drive a policy selecting an appropriate addressing sub-scheme 2603 for the (class of) node(s). 2605 ACP registrars SHOULD default to allocate ACP zone sub-address scheme 2606 addresses with Subnet-ID 0. Allocation and use of zone sub-addresses 2607 with Subnet-ID != 0 is outside the scope of this specification 2608 because it would need to go along with rules for extending ACP 2609 routing to multiple zones, which is outside the scope of this 2610 specification. 2612 ACP registrars that can use the IDevID of a candidate ACP device 2613 SHOULD be able to choose the zone vs. Vlong sub-address scheme for 2614 ACP nodes based on the serialNumber of the IDevID, for example by the 2615 PID (Product Identifier) part which identifies the product type, or 2616 the complete serialNumber. 2618 In a simple allocation scheme, an ACP registrar remembers 2619 persistently across reboots its currently used Registrar-ID and for 2620 each addressing scheme (zone with Subnet-ID 0, Vlong with /112, Vlong 2621 with /120), the next Node-Number available for allocation and 2622 increases it during successful enrollment to an ACP node. In this 2623 simple allocation scheme, the ACP registrar would not recycle ACP 2624 address prefixes from no longer used ACP nodes. 2626 6.10.7.4. Address/Prefix Persistence 2628 When an ACP domain certificate is renewed or rekeyed via EST or other 2629 mechanisms, the ACP address/prefix in the ACP domain information 2630 field MUST be maintained unless security issues or violations of the 2631 unique address assignment requirements exist or are suspected by the 2632 ACP registrar. 2634 ACP address information SHOULD be maintained even when the renewing/ 2635 rekeying ACP registrar is not the same as the one that enrolled the 2636 prior ACP certificate. See Section 10.2.4 for an example. 2638 ACP address information SHOULD also be maintained even after an ACP 2639 certificate did expire or failed. See Section 6.1.4.5 and 2640 Section 6.1.4.6. 2642 6.10.7.5. Further Details 2644 Section 10.2 discusses further informative details of ACP registrars: 2645 What interactions registrars need, what parameters they require, 2646 certificate renewal and limitations, use of sub-CAs on registrars and 2647 centralized policy control. 2649 6.11. Routing in the ACP 2651 Once ULA address are set up all autonomic entities should run a 2652 routing protocol within the autonomic control plane context. This 2653 routing protocol distributes the ULA created in the previous section 2654 for reachability. The use of the autonomic control plane specific 2655 context eliminates the probable clash with Data-Plane routing tables 2656 and also secures the ACP from interference from the configuration 2657 mismatch or incorrect routing updates. 2659 The establishment of the routing plane and its parameters are 2660 automatic and strictly within the confines of the autonomic control 2661 plane. Therefore, no explicit configuration is required. 2663 All routing updates are automatically secured in transit as the 2664 channels of the ACP are encrypted, and this routing runs only inside 2665 the ACP. 2667 The routing protocol inside the ACP is RPL ([RFC6550]). See 2668 Appendix A.4 for more details on the choice of RPL. 2670 RPL adjacencies are set up across all ACP channels in the same domain 2671 including all its routing subdomains. See Appendix A.7 for more 2672 details. 2674 6.11.1. RPL Profile 2676 The following is a description of the RPL profile that ACP nodes need 2677 to support by default. The format of this section is derived from 2678 draft-ietf-roll-applicability-template. 2680 6.11.1.1. Overview 2682 The choosen RPL profile is one that expects a fairly reliable network 2683 with reasonably fast links so that RPL convergence will be triggered 2684 immediately upon recognition of link failure/recovery. 2686 The profile is also designed to not require any RPL Data-Plane 2687 artifacts (such as defined in [RFC6553]). This is largely driven by 2688 the desire to avoid introducing the required Hop-by-Hop headers into 2689 the ACP forwarding plane, especially to support devices with silicon 2690 forwarding planes that cannot support insertion/removal of these 2691 headers in silicon or hop-by-hop forwarding based on them. Note: 2692 Insertion/removal of headers by a (potentially silicon based) ACP 2693 node would be be necessary when senders/receivers of ACP packets are 2694 legacy NOC devices connected via ACP connect (see Section 8.1.1 to 2695 the ACP. Their connectivity can be handled in RPL as non-RPL-aware 2696 leafs (or "Internet") according to the Data-Plane architecture 2697 explained in [I-D.ietf-roll-useofrplinfo]. 2699 To avoid Data-Plane artefacts, the profile uses a simple destination 2700 prefix based routing/forwarding table. To achieve this, the profiles 2701 uses only one RPL instanceID. This single instanceID can contain 2702 only one Destination Oriented Directed Acyclic Graph (DODAG), and the 2703 routing/forwarding table can therefore only calculate a single class 2704 of service ("best effort towards the primary NOC/root") and cannot 2705 create optimized routing paths to accomplish latency or energy goals 2706 between any two nodes. 2708 Consider a network that has multiple NOCs in different locations. 2709 Only one NOC will become the DODAG root. Traffic to and from other 2710 NOCs has to be sent through the DODAG (shortest path tree) rooted in 2711 the primary NOC. Depending on topology, this can be an annoyance 2712 from a latency point of view or from minimizing network path 2713 resources, but this is deemed to be acceptable given how ACP traffic 2714 is "only" network management/control traffic. 2716 Using a single instanceID/DODAG does not introduce a single point of 2717 failure, as the DODAG will reconfigure itself when it detects data- 2718 plane forwarding failures including choosing a different root when 2719 the primary one fails. See Appendix A.10.4 for more details. 2721 The benefit of this profile, especially compared to other IGPs is 2722 that it does not calculate routes for node reachable through the same 2723 interface as the DODAG root. This RPL profile can therefore scale to 2724 much larger number of ACP nodes in the same amount of compute and 2725 memory than other routing protocols. Especially on nodes that are 2726 leafs of the topology or those close to those leafs. 2728 The lack of RPL Packet Information (RPI, the IPv6 header for RPL 2729 defined by [RFC6553]), means that the Data-Plane will have no rank 2730 value that can be used to detect loops. As a result, traffic may 2731 loop until the time-to-live (TTL) of the packet reaches zero. This 2732 is the same behavior as that of other IGPs that do not have the Data- 2733 Plane options of RPL. 2735 Since links in the ACP are assumed to be mostly reliable (or have 2736 link layer protection against loss) and because there is no stretch 2737 according to Section 6.11.1.7, loops caused by RPL routing packet 2738 loss should be exceedingly rare. 2740 There are a variety of mechanisms possible in RPL to further avoid 2741 temporary loops: DODAG Information Objects (DIOs) SHOULD be sent 2742 2...3 times to inform children when losing the last parent. The 2743 technique in [RFC6550] section 8.2.2.6. (Detaching) SHOULD be 2744 favored over that in section 8.2.2.5., (Poisoning) because it allows 2745 local connectivity. Nodes SHOULD select more than one parent, at 2746 least 3 if possible, and send Destination Advertisement Objects 2747 (DAO)s to all of them in parallel. 2749 Additionally, failed ACP tunnels can be quickly discovered the secure 2750 channel protocol mechanisms such as IKEv2 Dead Peer Detection. This 2751 can function as a replacement for a Low-power and Lossy Networks' 2752 (LLN's) Expected Transmission Count (ETX) feature that is not used in 2753 this profile. A failure of an ACP tunnel should imediately signal 2754 the RPL control plane to pick a different parent. 2756 6.11.1.2. RPL Instances 2758 Single RPL instance. Default RPLInstanceID = 0. 2760 6.11.1.3. Storing vs. Non-Storing Mode 2762 RPL Mode of Operations (MOP): MUST support mode 2 - "Storing Mode of 2763 Operations with no multicast support". Implementations MAY support 2764 mode 3 ("... with multicast support" as that is a superset of mode 2765 2). Note: Root indicates mode in DIO flow. 2767 6.11.1.4. DAO Policy 2769 Proactive, aggressive DAO state maintenance: 2771 o Use K-flag in unsolicited DAO indicating change from previous 2772 information (to require DAO-ACK). 2774 o Retry such DAO DAO-RETRIES(3) times with DAO- ACK_TIME_OUT(256ms) 2775 in between. 2777 6.11.1.5. Path Metric 2779 Hopcount. 2781 6.11.1.6. Objective Function 2783 Objective Function (OF): Use OF0 [RFC6552]. No use of metric 2784 containers. 2786 rank_factor: Derived from link speed: <= 100Mbps: 2787 LOW_SPEED_FACTOR(5), else HIGH_SPEED_FACTOR(1) 2789 6.11.1.7. DODAG Repair 2791 Global Repair: we assume stable links and ranks (metrics), so no need 2792 to periodically rebuild DODAG. DODAG version only incremented under 2793 catastrophic events (e.g., administrative action). 2795 Local Repair: As soon as link breakage is detected, send No-Path DAO 2796 for all the targets that were reachable only via this link. As soon 2797 as link repair is detected, validate if this link provides you a 2798 better parent. If so, compute your new rank, and send new DIO that 2799 advertises your new rank. Then send a DAO with a new path sequence 2800 about yourself. 2802 stretch_rank: none provided ("not stretched"). 2804 Data Path Validation: Not used. 2806 Trickle: Not used. 2808 6.11.1.8. Multicast 2810 Not used yet but possible because of the selected mode of operations. 2812 6.11.1.9. Security 2814 [RFC6550] security not used, substituted by ACP security. 2816 Because the ACP links already include provisions for confidentiality 2817 and integrity protection, their usage at the RPL layer would be 2818 redundant, and so RPL security is not used. 2820 6.11.1.10. P2P communications 2822 Not used. 2824 6.11.1.11. IPv6 address configuration 2826 Every ACP node (RPL node) announces an IPv6 prefix covering the 2827 address(es) used in the ACP node. The prefix length depends on the 2828 chosen addressing sub-scheme of the ACP address provisioned into the 2829 certificate of the ACP node, e.g., /127 for Zone Addressing Sub- 2830 Scheme or /112 or /120 for Vlong addressing sub-scheme. See 2831 Section 6.10 for more details. 2833 Every ACP node MUST install a black hole (aka null) route for 2834 whatever ACP address space that it advertises (i.e.: the /96 or 2835 /127). This is avoid routing loops for addresses that an ACP node 2836 has not (yet) used. 2838 6.11.1.12. Administrative parameters 2840 Administrative Preference ([RFC6550], 3.2.6 - to become root): 2841 Indicated in DODAGPreference field of DIO message. 2843 o Explicit configured "root": 0b100 2845 o ACP registrar (Default): 0b011 2847 o ACP-connect (non-registrar): 0b010 2849 o Default: 0b001. 2851 6.11.1.13. RPL Data-Plane artifacts 2853 RPI (RPL Packet Information [RFC6553]): Not used as there is only a 2854 single instance, and data path validation is not being used. 2856 SRH (RPL Source Routing - RFC6552): Not used. Storing mode is being 2857 used. 2859 6.11.1.14. Unknown Destinations 2861 Because RPL minimizes the size of the routing and forwarding table, 2862 prefixes reachable through the same interface as the RPL root are not 2863 known on every ACP node. Therefore traffic to unknown destination 2864 addresses can only be discovered at the RPL root. The RPL root 2865 SHOULD have attach safe mechanisms to operationally discover and log 2866 such packets. 2868 6.12. General ACP Considerations 2870 Since channels are by default established between adjacent neighbors, 2871 the resulting overlay network does hop-by-hop encryption. Each node 2872 decrypts incoming traffic from the ACP, and encrypts outgoing traffic 2873 to its neighbors in the ACP. Routing is discussed in Section 6.11. 2875 6.12.1. Performance 2877 There are no performance requirements against ACP implementations 2878 defined in this document because the performance requirements depend 2879 on the intended use case. It is expected that full autonomic node 2880 with a wide range of ASA can require high forwarding plane 2881 performance in the ACP, for example for telemetry. Implementations 2882 of ACP to solely support traditional/SDN style use cases can benefit 2883 from ACP at lower performance, especially if the ACP is used only for 2884 critical operations, e.g., when the Data-Plane is not available. The 2885 design of the ACP as specified in this document is intended to 2886 support a wide range of performance options: It is intended to allow 2887 software-only implementations at potentially low performance, but can 2888 also support high performance options. See [RFC8368] for more 2889 details. 2891 6.12.2. Addressing of Secure Channels 2893 In order to be independent of the Data-Plane (routing and addressing) 2894 the GRASP discovered (autonomic) ACP secure channels use IPv6 link 2895 local addresses between adjacent neighbors. Note: Section 8.2 2896 specifies extensions in which secure channels are configured tunnels 2897 operating over the Data-Plane, so those secure channels cannot be 2898 independent of the Data-Plane. 2900 To avoid that Data-Plane configuration can impact the operations of 2901 the IPv6 (link-local) interface/address used for ACP channels, 2902 appropriate implementation considerations are required. If the IPv6 2903 interface/link-local address is shared with the Data-Plane it needs 2904 to be impossible to unconfigure/disable it through configuration. 2905 Instead of sharing the IPv6 interface/link-local address, a separate 2906 (virtual) interface with a separate IPv6 link-local address can be 2907 used. For example, the ACP interface could be run over a separate 2908 MAC address of an underlying L2 (Ethernet) interface. For more 2909 details and options, see Appendix A.10.2. 2911 Note that other (non-ideal) implementation choices may introduce 2912 additional undesired dependencies against the Data-Plane. For 2913 example shared code and configuration of the secure channel protocols 2914 (IPsec / DTLS). 2916 6.12.3. MTU 2918 The MTU for ACP secure channels must be derived locally from the 2919 underlying link MTU minus the secure channel encapsulation overhead. 2921 ACP secure Channel protocols do not need to perform MTU discovery 2922 because they are built across L2 adjacencies - the MTU on both sides 2923 connecting to the L2 connection are assumed to be consistent. 2924 Extensions to ACP where the ACP is for example tunneled need to 2925 consider how to guarantee MTU consistency. This is an issue of 2926 tunnels, not an issue of running the ACP across a tunnel. Transport 2927 stacks running across ACP can perform normal PMTUD (Path MTU 2928 Discovery). Because the ACP is meant to be prioritize reliability 2929 over performance, they MAY opt to only expect IPv6 minimum MTU (1280) 2930 to avoid running into PMTUD implementation bugs or underlying link 2931 MTU mismatch problems. 2933 6.12.4. Multiple links between nodes 2935 If two nodes are connected via several links, the ACP SHOULD be 2936 established across every link, but it is possible to establish the 2937 ACP only on a sub-set of links. Having an ACP channel on every link 2938 has a number of advantages, for example it allows for a faster 2939 failover in case of link failure, and it reflects the physical 2940 topology more closely. Using a subset of links (for example, a 2941 single link), reduces resource consumption on the node, because state 2942 needs to be kept per ACP channel. The negotiation scheme explained 2943 in Section 6.5 allows Alice (the node with the higher ACP address) to 2944 drop all but the desired ACP channels to Bob - and Bob will not re- 2945 try to build these secure channels from his side unless Alice shows 2946 up with a previously unknown GRASP announcement (e.g., on a different 2947 link or with a different address announced in GRASP). 2949 6.12.5. ACP interfaces 2951 The ACP VRF has conceptually two type of interfaces: The "ACP 2952 Loopback interface(s)" to which the ACP ULA address(es) are assigned 2953 and the "ACP virtual interfaces" that are mapped to the ACP secure 2954 channels. 2956 The term "Loopback interface" was introduced initially to refer to an 2957 internal interface on a node that would allow IP traffic between 2958 transport endpoints on the node in the absence or failure of any or 2959 all external interfaces, see [RFC4291] section 2.5.3. 2961 Even though Loopback interfaces were originally designed to hold only 2962 Loopback addresses not reachable from outside the node, these 2963 interfaces are also commonly used today to hold addresses reachable 2964 from the outside. They are meant to be reachable independent of any 2965 external interface being operational, and therefore to be more 2966 resilient. These addresses on Loopback interfaces can be thought of 2967 as "node addresses" instead of "interface addresses", and that is 2968 what ACP address(es) are. This construct makes it therefore possible 2969 to address ACP nodes with a well-defined set of addresses independent 2970 of the number of external interfaces. 2972 For these reason, the ACP (ULA) address(es) are assigned to Loopback 2973 interface(s). 2975 Any type of ACP secure channels to another ACP node can be mapped to 2976 ACP virtual interfaces in following ways. This is independent of the 2977 chosen secure channel protocol (IPsec, DTLS or other future protocol 2978 - standards or non-standards): 2980 ACP point-to-point virtual interface: 2982 Each ACP secure channel is mapped into a separate point-to-point ACP 2983 virtual interface. If a physical subnet has more than two ACP 2984 capable nodes (in the same domain), this implementation approach will 2985 lead to a full mesh of ACP virtual interfaces between them. 2987 ACP multi-access virtual interface: 2989 In a more advanced implementation approach, the ACP will construct a 2990 single multi-access ACP virtual interface for all ACP secure channels 2991 to ACP capable nodes reachable across the same underlying (physical) 2992 subnet. IPv6 link-local multicast packets sent into an ACP multi- 2993 access virtual interface are replicated to every ACP secure channel 2994 mapped into the ACP multicast-access virtual interface. IPv6 unicast 2995 packets sent into an ACP multi-access virtual interface are sent to 2996 the ACP secure channel that belongs to the ACP neighbor that is the 2997 next-hop in the ACP forwarding table entry used to reach the packets 2998 destination address. 3000 There is no requirement for all ACP nodes on the same multi-access 3001 subnet to use the same type of ACP virtual interface. This is purely 3002 a node local decision. 3004 ACP nodes MUST perform standard IPv6 operations across ACP virtual 3005 interfaces including SLAAC (Stateless Address Auto-Configuration) - 3006 [RFC4862]) to assign their IPv6 link local address on the ACP virtual 3007 interface and ND (Neighbor Discovery - [RFC4861]) to discover which 3008 IPv6 link-local neighbor address belongs to which ACP secure channel 3009 mapped to the ACP virtual interface. This is independent of whether 3010 the ACP virtual interface is point-to-point or multi-access. 3012 "Optimistic Duplicate Address Detection (DAD)" according to [RFC4429] 3013 is RECOMMENDED because the likelihood for duplicates between ACP 3014 nodes is highly improbable as long as the address can be formed from 3015 a globally unique local assigned identifier (e.g., EUI-48/EUI-64, see 3016 below). 3018 ACP nodes MAY reduce the amount of link-local IPv6 multicast packets 3019 from ND by learning the IPv6 link-local neighbor address to ACP 3020 secure channel mapping from other messages such as the source address 3021 of IPv6 link-local multicast RPL messages - and therefore forego the 3022 need to send Neighbor Solicitation messages. 3024 The ACP virtual interface IPv6 link local address can be derived from 3025 any appropriate local mechanism such as node local EUI-48 or EUI-64 3026 ("EUI" stands for "Extended Unique Identifier"). It MUST NOT depend 3027 on something that is attackable from the Data-Plane such as the IPv6 3028 link-local address of the underlying physical interface, which can be 3029 attacked by SLAAC, or parameters of the secure channel encapsulation 3030 header that may not be protected by the secure channel mechanism. 3032 The link-layer address of an ACP virtual interface is the address 3033 used for the underlying interface across which the secure tunnels are 3034 built, typically Ethernet addresses. Because unicast IPv6 packets 3035 sent to an ACP virtual interface are not sent to a link-layer 3036 destination address but rather an ACP secure channel, the link-layer 3037 address fields SHOULD be ignored on reception and instead the ACP 3038 secure channel from which the message was received should be 3039 remembered. 3041 Multi-access ACP virtual interfaces are preferable implementations 3042 when the underlying interface is a (broadcast) multi-access subnet 3043 because they do reflect the presence of the underlying multi-access 3044 subnet into the virtual interfaces of the ACP. This makes it for 3045 example simpler to build services with topology awareness inside the 3046 ACP VRF in the same way as they could have been built running 3047 natively on the multi-access interfaces. 3049 Consider also the impact of point-to-point vs. multi-access virtual 3050 interface on the efficiency of flooding via link local multicasted 3051 messages: 3053 Assume a LAN with three ACP neighbors, Alice, Bob and Carol. Alice's 3054 ACP GRASP wants to send a link-local GRASP multicast message to Bob 3055 and Carol. If Alice's ACP emulates the LAN as one point-to-point 3056 virtual interface to Bob and one to Carol, The sending applications 3057 itself will send two copies, if Alice's ACP emulates a LAN, GRASP 3058 will send one packet and the ACP will replicate it. The result is 3059 the same. The difference happens when Bob and Carol receive their 3060 packet. If they use ACP point-to-point virtual interfaces, their 3061 GRASP instance would forward the packet from Alice to each other as 3062 part of the GRASP flooding procedure. These packets are unnecessary 3063 and would be discarded by GRASP on receipt as duplicates (by use of 3064 the GRASP Session ID). If Bob and Carol's ACP would emulate a multi- 3065 access virtual interface, then this would not happen, because GRASPs 3066 flooding procedure does not replicate back packets to the interface 3067 that they were received from. 3069 Note that link-local GRASP multicast messages are not sent directly 3070 as IPv6 link-local multicast UDP messages into ACP virtual 3071 interfaces, but instead into ACP GRASP virtual interfaces, that are 3072 layered on top of ACP virtual interfaces to add TCP reliability to 3073 link-local multicast GRASP messages. Nevertheless, these ACP GRASP 3074 virtual interfaces perform the same replication of message and, 3075 therefore, result in the same impact on flooding. See Section 6.8.2 3076 for more details. 3078 RPL does support operations and correct routing table construction 3079 across non-broadcast multi-access (NBMA) subnets. This is common 3080 when using many radio technologies. When such NBMA subnets are used, 3081 they MUST NOT be represented as ACP multi-access virtual interfaces 3082 because the replication of IPv6 link-local multicast messages will 3083 not reach all NBMA subnet neighbors. In result, GRASP message 3084 flooding would fail. Instead, each ACP secure channel across such an 3085 interface MUST be represented as a ACP point-to-point virtual 3086 interface. See also Appendix A.10.4. 3088 Care must also be taken when creating multi-access ACP virtual 3089 interfaces across ACP secure channels between ACP nodes in different 3090 domains or routing subdomains. The policies to be negotiated may be 3091 described as peer-to-peer policies in which case it is easier to 3092 create ACP point-to-point virtual interfaces for these secure 3093 channels. 3095 7. ACP support on L2 switches/ports (Normative) 3097 7.1. Why (Benefits of ACP on L2 switches) 3099 ANrtr1 ------ ANswitch1 --- ANswitch2 ------- ANrtr2 3100 .../ \ \ ... 3101 ANrtrM ------ \ ------- ANrtrN 3102 ANswitchM ... 3104 Figure 13: Topology with L2 ACP switches 3106 Consider a large L2 LAN with ANrtr1...ANrtrN connected via some 3107 topology of L2 switches. Examples include large enterprise campus 3108 networks with an L2 core, IoT networks or broadband aggregation 3109 networks which often have even a multi-level L2 switched topology. 3111 If the discovery protocol used for the ACP is operating at the subnet 3112 level, every ACP router will see all other ACP routers on the LAN as 3113 neighbors and a full mesh of ACP channels will be built. If some or 3114 all of the AN switches are autonomic with the same discovery 3115 protocol, then the full mesh would include those switches as well. 3117 A full mesh of ACP connections can create fundamental scale 3118 challenges. The number of security associations of the secure 3119 channel protocols will likely not scale arbitrarily, especially when 3120 they leverage platform accelerated encryption/decryption. Likewise, 3121 any other ACP operations (such as routing) needs to scale to the 3122 number of direct ACP neighbors. An ACP router with just 4 physical 3123 interfaces might be deployed into a LAN with hundreds of neighbors 3124 connected via switches. Introducing such a new unpredictable scaling 3125 factor requirement makes it harder to support the ACP on arbitrary 3126 platforms and in arbitrary deployments. 3128 Predictable scaling requirements for ACP neighbors can most easily be 3129 achieved if in topologies such as these, ACP capable L2 switches can 3130 ensure that discovery messages terminate on them so that neighboring 3131 ACP routers and switches will only find the physically connected ACP 3132 L2 switches as their candidate ACP neighbors. With such a discovery 3133 mechanism in place, the ACP and its security associations will only 3134 need to scale to the number of physical interfaces instead of a 3135 potentially much larger number of "LAN-connected" neighbors. And the 3136 ACP topology will follow directly the physical topology, something 3137 which can then also be leveraged in management operations or by ASAs. 3139 In the example above, consider ANswitch1 and ANswitchM are ACP 3140 capable, and ANswitch2 is not ACP capable. The desired ACP topology 3141 is that ANrtr1 and ANrtrM only have an ACP connection to ANswitch1, 3142 and that ANswitch1, ANrtr2, ANrtrN have a full mesh of ACP connection 3143 amongst each other. ANswitch1 also has an ACP connection with 3144 ANswitchM and ANswitchM has ACP connections to anything else behind 3145 it. 3147 7.2. How (per L2 port DULL GRASP) 3149 To support ACP on L2 switches or L2 switched ports of an L3 device, 3150 it is necessary to make those L2 ports look like L3 interfaces for 3151 the ACP implementation. This primarily involves the creation of a 3152 separate DULL GRASP instance/domain on every such L2 port. Because 3153 GRASP has a dedicated link-local IPv6 multicast address 3154 (ALL_GRASP_NEIGHBORS), it is sufficient that all packets for this 3155 address are being extracted at the port level and passed to that DULL 3156 GRASP instance. Likewise the IPv6 link-local multicast packets sent 3157 by that DULL GRASP instance need to be sent only towards the L2 port 3158 for this DULL GRASP instance. 3160 If the device with L2 ports is supporting per L2 port ACP DULL GRASP 3161 as well as MLD snooping ([RFC4541]), then MLD snooping must be 3162 changed to never forward packets for ALL_GRASP_NEIGHBORS because that 3163 would cause the problem that per L2 port ACP DULL GRASP is meant to 3164 overcome (forwarding DULL GRASP packets across L2 ports). 3166 The rest of ACP operations can operate in the same way as in L3 3167 devices: Assume for example that the device is an L3/L2 hybrid device 3168 where L3 interfaces are assigned to VLANs and each VLAN has 3169 potentially multiple ports. DULL GRASP is run as described 3170 individually on each L2 port. When it discovers a candidate ACP 3171 neighbor, it passes its IPv6 link-local address and supported secure 3172 channel protocols to the ACP secure channel negotiation that can be 3173 bound to the L3 (VLAN) interface. It will simply use link-local IPv6 3174 multicast packets to the candidate ACP neighbor. Once a secure 3175 channel is established to such a neighbor, the virtual interface to 3176 which this secure channel is mapped should then actually be the L2 3177 port and not the L3 interface to best map the actual physical 3178 topology into the ACP virtual interfaces. See Section 6.12.5 for 3179 more details about how to map secure channels into ACP virtual 3180 interfaces. Note that a single L2 port can still have multiple ACP 3181 neighbors if it connect for example to multiple ACP neighbors via a 3182 non-ACP enabled switch. The per L2 port ACP virtual interface can 3183 therefore still be a multi-access virtual LAN. 3185 For example, in the above picture, ANswitch1 would run separate DULL 3186 GRASP instances on its ports to ANrtr1, ANswitch2 and ANswitchI, even 3187 though all those three ports may be in the data plane in the same 3188 (V)LAN and perform L2 switching between these ports, ANswitch1 would 3189 perform ACP L3 routing between them. 3191 The description in the previous paragraph was specifically meant to 3192 illustrate that on hybrid L3/L2 devices that are common in 3193 enterprise, IoT and broadband aggregation, there is only the GRASP 3194 packet extraction (by Ethernet address) and GRASP link-local 3195 multicast per L2-port packet injection that has to consider L2 ports 3196 at the hardware forwarding level. The remaining operations are 3197 purely ACP control plane and setup of secure channels across the L3 3198 interface. This hopefully makes support for per-L2 port ACP on those 3199 hybrid devices easy. 3201 This L2/L3 optimized approach is subject to "address stealing", e.g., 3202 where a device on one port uses addresses of a device on another 3203 port. This is a generic issue in L2 LANs and switches often already 3204 have some form of "port security" to prohibit this. They rely on NDP 3205 or DHCP learning of which port/MAC-address and IPv6 address belong 3206 together and block duplicates. This type of function needs to be 3207 enabled to prohibit DoS attacks. Likewise the GRASP DULL instance 3208 needs to ensure that the IPv6 address in the locator-option matches 3209 the source IPv6 address of the DULL GRASP packet. 3211 In devices without such a mix of L2 port/interfaces and L3 interfaces 3212 (to terminate any transport layer connections), implementation 3213 details will differ. Logically most simply every L2 port is 3214 considered and used as a separate L3 subnet for all ACP operations. 3215 The fact that the ACP only requires IPv6 link-local unicast and 3216 multicast should make support for it on any type of L2 devices as 3217 simple as possible. 3219 A generic issue with ACP in L2 switched networks is the interaction 3220 with the Spanning Tree Protocol. Without further L2 enhancements, 3221 the ACP would run only across the active STP topology and the ACP 3222 would be interrupted and re-converge with STP changes. Ideally, ACP 3223 peering should be built also across ports that are blocked in STP so 3224 that the ACP does not depend on STP and can continue to run 3225 unaffected across STP topology changes, where re-convergence can be 3226 quite slow. The above described simple implementation options are 3227 not sufficient to achieve this. 3229 8. Support for Non-ACP Components (Normative) 3231 8.1. ACP Connect 3233 8.1.1. Non-ACP Controller / NMS system 3235 The Autonomic Control Plane can be used by management systems, such 3236 as controllers or network management system (NMS) hosts (henceforth 3237 called simply "NMS hosts"), to connect to devices (or other type of 3238 nodes) through it. For this, an NMS host must have access to the 3239 ACP. The ACP is a self-protecting overlay network, which allows by 3240 default access only to trusted, autonomic systems. Therefore, a 3241 traditional, non-ACP NMS system does not have access to the ACP by 3242 default, such as any other external node. 3244 If the NMS host is not autonomic, i.e., it does not support autonomic 3245 negotiation of the ACP, then it can be brought into the ACP by 3246 explicit configuration. To support connections to adjacent non-ACP 3247 nodes, an ACP node must support "ACP connect" (sometimes also called 3248 "autonomic connect"): 3250 "ACP connect" is an interface level configured workaround for 3251 connection of trusted non-ACP nodes to the ACP. The ACP node on 3252 which ACP connect is configured is called an "ACP edge node". With 3253 ACP connect, the ACP is accessible from those non-ACP nodes (such as 3254 NOC systems) on such an interface without those non-ACP nodes having 3255 to support any ACP discovery or ACP channel setup. This is also 3256 called "native" access to the ACP because to those (NOC) systems the 3257 interface looks like a normal network interface (without any 3258 encryption/novel-signaling). 3260 Data-Plane "native" (no ACP) 3261 . 3262 +--------+ +----------------+ . +-------------+ 3263 | ACP | |ACP Edge Node | . | | 3264 | Node | | | v | | 3265 | |-------|...[ACP VRF]....+-----------------| |+ 3266 | | ^ |. | | NOC Device || 3267 | | . | .[Data-Plane]..+-----------------| "NMS hosts" || 3268 | | . | [ ] | . ^ | || 3269 +--------+ . +----------------+ . . +-------------+| 3270 . . . +-------------+ 3271 . . . 3272 Data-Plane "native" . ACP "native" (unencrypted) 3273 + ACP auto-negotiated . "ACP connect subnet" 3274 and encrypted . 3275 ACP connect interface 3276 e.g., "VRF ACP native" (config) 3278 Figure 14: ACP connect 3280 ACP connect has security consequences: All systems and processes 3281 connected via ACP connect have access to all ACP nodes on the entire 3282 ACP, without further authentication. Thus, the ACP connect interface 3283 and (NOC) systems connected to it must be physically controlled/ 3284 secured. For this reason the mechanisms described here do explicitly 3285 not include options to allow for a non-ACP router to be connected 3286 across an ACP connect interface and addresses behind such a router 3287 routed inside the ACP. 3289 An ACP connect interface provides exclusively access to only the ACP. 3290 This is likely insufficient for many NMS hosts. Instead, they would 3291 require a second "Data-Plane" interface outside the ACP for 3292 connections between the NMS host and administrators, or Internet 3293 based services, or for direct access to the Data-Plane. The document 3294 "Using Autonomic Control Plane for Stable Connectivity of Network 3295 OAM" [RFC8368] explains in more detail how the ACP can be integrated 3296 in a mixed NOC environment. 3298 An ACP connect interface SHOULD use an IPv6 address/prefix from the 3299 ACP Manual Addressing Sub-Scheme (Section 6.10.4), letting the 3300 operator configure for example only the Subnet-ID and having the node 3301 automatically assign the remaining part of the prefix/address. It 3302 SHOULD NOT use a prefix that is also routed outside the ACP so that 3303 the addresses clearly indicate whether it is used inside the ACP or 3304 not. 3306 The prefix of ACP connect subnets MUST be distributed by the ACP edge 3307 node into the ACP routing protocol (RPL). The NMS hosts MUST connect 3308 to prefixes in the ACP routing table via its ACP connect interface. 3309 In the simple case where the ACP uses only one ULA prefix and all ACP 3310 connect subnets have prefixes covered by that ULA prefix, NMS hosts 3311 can rely on [RFC6724] to determine longest match prefix routes 3312 towards its different interfaces, ACP and data-plane. With RFC6724, 3313 The NMS host will select the ACP connect interface for all addresses 3314 in the ACP because any ACP destination address is longest matched by 3315 the address on the ACP connect interface. If the NMS hosts ACP 3316 connect interface uses another prefix or if the ACP uses multiple ULA 3317 prefixes, then the NMS hosts require (static) routes towards the ACP 3318 interface for these prefixes. 3320 When an ACP Edge node receives a packet from an ACP connect 3321 interface, it MUST only forward it intot he ACP if it has an IPv6 3322 source address from that interface. This is sometimes called "RPF 3323 filtering". This MAY be changed through administrative measures. 3325 To limit the security impact of ACP connect, nodes supporting it 3326 SHOULD implement a security mechanism to allow configuration/use of 3327 ACP connect interfaces only on nodes explicitly targeted to be 3328 deployed with it (those in physically secure locations such as a 3329 NOC). For example, the registrar could disable the ability to enable 3330 ACP connect on devices during enrollment and that property could only 3331 be changed through re-enrollment. See also Appendix A.10.5. 3333 8.1.2. Software Components 3335 The ACP connect mechanism be only be used to connect physically 3336 external systems (NMS hosts) to the ACP but also other applications, 3337 containers or virtual machines. In fact, one possible way to 3338 eliminate the security issue of the external ACP connect interface is 3339 to collocate an ACP edge node and an NMS host by making one a virtual 3340 machine or container inside the other; and therefore converting the 3341 unprotected external ACP subnet into an internal virtual subnet in a 3342 single device. This would ultimately result in a fully ACP enabled 3343 NMS host with minimum impact to the NMS hosts software architecture. 3344 This approach is not limited to NMS hosts but could equally be 3345 applied to devices consisting of one or more VNF (virtual network 3346 functions): An internal virtual subnet connecting out-of-band 3347 management interfaces of the VNFs to an ACP edge router VNF. 3349 The core requirement is that the software components need to have a 3350 network stack that permits access to the ACP and optionally also the 3351 Data-Plane. Like in the physical setup for NMS hosts this can be 3352 realized via two internal virtual subnets. One that is connecting to 3353 the ACP (which could be a container or virtual machine by itself), 3354 and one (or more) connecting into the Data-Plane. 3356 This "internal" use of ACP connect approach should not considered to 3357 be a "workaround" because in this case it is possible to build a 3358 correct security model: It is not necessary to rely on unprovable 3359 external physical security mechanisms as in the case of external NMS 3360 hosts. Instead, the orchestration of the ACP, the virtual subnets 3361 and the software components can be done by trusted software that 3362 could be considered to be part of the ANI (or even an extended ACP). 3363 This software component is responsible for ensuring that only trusted 3364 software components will get access to that virtual subnet and that 3365 only even more trusted software components will get access to both 3366 the ACP virtual subnet and the Data-Plane (because those ACP users 3367 could leak traffic between ACP and Data-Plane). This trust could be 3368 established for example through cryptographic means such as signed 3369 software packages. 3371 8.1.3. Auto Configuration 3373 ACP edge nodes, NMS hosts and software components that as described 3374 in the previous section are meant to be composed via virtual 3375 interfaces SHOULD support on the ACP connect subnet StateLess Address 3376 Autoconfiguration (SLAAC - [RFC4862]) and route auto configuration 3377 according to [RFC4191]. 3379 The ACP edge node acts as the router on the ACP connect subnet, 3380 providing the (auto-)configured prefix for the ACP connect subnet to 3381 NMS hosts and/or software components. The ACP edge node uses route 3382 prefix option of RFC4191 to announce the default route (::/) with a 3383 lifetime of 0 and aggregated prefixes for routes in the ACP routing 3384 table with normal lifetimes. This will ensure that the ACP edge node 3385 does not become a default router, but that the NMS hosts and software 3386 components will route the prefixes used in the ACP to the ACP edge 3387 node. 3389 Aggregated prefix means that the ACP edge node needs to only announce 3390 the /48 ULA prefixes used in the ACP but none of the actual /64 3391 (Manual Addressing Sub-Scheme), /127 (ACP Zone Addressing Sub- 3392 Scheme), /112 or /120 (Vlong Addressing Sub-Scheme) routes of actual 3393 ACP nodes. If ACP interfaces are configured with non ULA prefixes, 3394 then those prefixes cannot be aggregated without further configured 3395 policy on the ACP edge node. This explains the above recommendation 3396 to use ACP ULA prefix covered prefixes for ACP connect interfaces: 3397 They allow for a shorter list of prefixes to be signaled via RFC4191 3398 to NMS hosts and software components. 3400 The ACP edge nodes that have a Vlong ACP address MAY allocate a 3401 subset of their /112 or /120 address prefix to ACP connect 3402 interface(s) to eliminate the need to non-autonomically configure/ 3403 provision the address prefixes for such ACP connect interfaces. 3405 8.1.4. Combined ACP/Data-Plane Interface (VRF Select) 3407 Combined ACP and Data-Plane interface 3408 . 3409 +--------+ +--------------------+ . +--------------+ 3410 | ACP | |ACP Edge No | . | NMS Host(s) | 3411 | Node | | | . | / Software | 3412 | | | [ACP ]. | . | |+ 3413 | | | .[VRF ] .[VRF ] | v | "ACP address"|| 3414 | +-------+. .[Select].+--------+ "Date Plane || 3415 | | ^ | .[Data ]. | | Address(es)"|| 3416 | | . | [Plane] | | || 3417 | | . | [ ] | +--------------+| 3418 +--------+ . +--------------------+ +--------------+ 3419 . 3420 Data-Plane "native" and + ACP auto-negotiated/encrypted 3422 Figure 15: VRF select 3424 Using two physical and/or virtual subnets (and therefore interfaces) 3425 into NMS Hosts (as per Section 8.1.1) or Software (as per 3426 Section 8.1.2) may be seen as additional complexity, for example with 3427 legacy NMS Hosts that support only one IP interface. 3429 To provide a single subnet into both ACP and Data-Plane, the ACP Edge 3430 node needs to de-multiplex packets from NMS hosts into ACP VRF and 3431 Data-Plane. This is sometimes called "VRF select". If the ACP VRF 3432 has no overlapping IPv6 addresses with the Data-Plane (it should have 3433 no overlapping addresses), then this function can use the IPv6 3434 Destination address. The problem is Source Address Selection on the 3435 NMS Host(s) according to RFC6724. 3437 Consider the simple case: The ACP uses only one ULA prefix, the ACP 3438 IPv6 prefix for the Combined ACP and Data-Plane interface is covered 3439 by that ULA prefix. The ACP edge node announces both the ACP IPv6 3440 prefix and one (or more) prefixes for the Data-Plane. Without 3441 further policy configurations on the NMS Host(s), it may select its 3442 ACP address as a source address for Data-Plane ULA destinations 3443 because of Rule 8 of RFC6724. The ACP edge node can pass on the 3444 packet to the Data-Plane, but the ACP source address should not be 3445 used for Data-Plane traffic, and return traffic may fail. 3447 If the ACP carries multiple ULA prefixes or non-ULA ACP connect 3448 prefixes, then the correct source address selection becomes even more 3449 problematic. 3451 With separate ACP connect and Data-Plane subnets and RFC4191 prefix 3452 announcements that are to be routed across the ACP connect interface, 3453 RFC6724 source address selection Rule 5 (use address of outgoing 3454 interface) will be used, so that above problems do not occur, even in 3455 more complex cases of multiple ULA and non-ULA prefixes in the ACP 3456 routing table. 3458 To achieve the same behavior with a Combined ACP and Data-Plane 3459 interface, the ACP Edge Node needs to behave as two separate routers 3460 on the interface: One link-local IPv6 address/router for its ACP 3461 reachability, and one link-local IPv6 address/router for its Data- 3462 Plane reachability. The Router Advertisements for both are as 3463 described above (Section 8.1.3): For the ACP, the ACP prefix is 3464 announced together with RFC4191 option for the prefixes routed across 3465 the ACP and lifetime=0 to disqualify this next-hop as a default 3466 router. For the Data-Plane, the Data-Plane prefix(es) are announced 3467 together with whatever dafault router parameters are used for the 3468 Data-Plane. 3470 In result, RFC6724 source address selection Rule 5.5 may result in 3471 the same correct source address selection behavior of NMS hosts 3472 without further configuration on it as the separate ACP connect and 3473 Data-Plane interfaces. As described in the text for Rule 5.5, this 3474 is only a MAY, because IPv6 hosts are not required to track next-hop 3475 information. If an NMS Host does not do this, then separate ACP 3476 connect and Data-Plane interfaces are the preferable method of 3477 attachment. Hosts implementing [RFC8028] should (instead of may) 3478 implement [RFC6724] Rule 5.5, so it is preferred for hosts to support 3479 [RFC8028]. 3481 ACP edge nodes MAY support the Combined ACP and Data-Plane interface. 3483 8.1.5. Use of GRASP 3485 GRASP can and should be possible to use across ACP connect 3486 interfaces, especially in the architectural correct solution when it 3487 is used as a mechanism to connect Software (e.g., ASA or legacy NMS 3488 applications) to the ACP. Given how the ACP is the security and 3489 transport substrate for GRASP, the trustworthiness of nodes/software 3490 allowed to participate in the ACP GRASP domain is one of the main 3491 reasons why the ACP section describes no solution with non-ACP 3492 routers participating in the ACP routing table. 3494 ACP connect interfaces can be dealt with in the GRASP ACP domain the 3495 same as any other ACP interface assuming that any physical ACP 3496 connect interface is physically protected from attacks and that the 3497 connected Software or NMS Hosts are equally trusted as that on other 3498 ACP nodes. ACP edge nodes SHOULD have options to filter GRASP 3499 messages in and out of ACP connect interfaces (permit/deny) and MAY 3500 have more fine-grained filtering (e.g., based on IPv6 address of 3501 originator or objective). 3503 When using "Combined ACP and Data-Plane Interfaces", care must be 3504 taken that only GRASP messages intended for the ACP GRASP domain 3505 received from Software or NMS Hosts are forwarded by ACP edge nodes. 3506 Currently there is no definition for a GRASP security and transport 3507 substrate beside the ACP, so there is no definition how such 3508 Software/NMS Host could participate in two separate GRASP Domains 3509 across the same subnet (ACP and Data-Plane domains). At current it 3510 is assumed that all GRASP packets on a Combined ACP and Data-Plane 3511 interface belong to the GRASP ACP Domain. They must all use the ACP 3512 IPv6 addresses of the Software/NMS Hosts. The link-local IPv6 3513 addresses of Software/NMS Hosts (used for GRASP M_DISCOVERY and 3514 M_FLOOD messages) are also assumed to belong to the ACP address 3515 space. 3517 8.2. ACP through Non-ACP L3 Clouds (Remote ACP neighbors) 3519 Not all nodes in a network may support the ACP. If non-ACP Layer-2 3520 devices are between ACP nodes, the ACP will work across it since it 3521 is IP based. However, the autonomic discovery of ACP neighbors via 3522 DULL GRASP is only intended to work across L2 connections, so it is 3523 not sufficient to autonomically create ACP connections across non-ACP 3524 Layer-3 devices. 3526 8.2.1. Configured Remote ACP neighbor 3528 On the ACP node, remote ACP neighbors are configured explicitly. The 3529 parameters of such a "connection" are described in the following 3530 ABNF. 3532 connection = [ method , local-addr, remote-addr, ?pmtu ] 3533 method = [ "IKEv2" , ?port ] 3534 method //= [ "DTLS", port ] 3535 local-addr = [ address , ?vrf ] 3536 remote-addr = [ address ] 3537 address = ("any" | ipv4-address | ipv6-address ) 3538 vrf = tstr ; Name of a VRF on this node with local-address 3540 Figure 16: Parameters for remote ACP neighbors 3542 Explicit configuration of a remote-peer according to this ABNF 3543 provides all the information to build a secure channel without 3544 requiring a tunnel to that peer and running DULL GRASP inside of it. 3546 The configuration includes the parameters otherwise signaled via DULL 3547 GRASP: local address, remote (peer) locator and method. The 3548 differences over DULL GRASP local neighbor discovery and secure 3549 channel creation are as follows: 3551 o The local and remote address can be IPv4 or IPv6 and are typically 3552 global scope addresses. 3554 o The VRF across which the connection is built (and in which local- 3555 addr exists) can to be specified. If vrf is not specified, it is 3556 the default VRF on the node. In DULL GRASP the VRF is implied by 3557 the interface across which DULL GRASP operates. 3559 o If local address is "any", the local address used when initiating 3560 a secure channel connection is decided by source address selection 3561 ([RFC6724] for IPv6). As a responder, the connection listens on 3562 all addresses of the node in the selected VRF. 3564 o Configuration of port is only required for methods where no 3565 defaults exist (e.g., "DTLS"). 3567 o If remote address is "any", the connection is only a responder. 3568 It is a "hub" that can be used by multiple remote peers to connect 3569 simultaneously - without having to know or configure their 3570 addresses. Example: Hub site for remote "spoke" sites reachable 3571 over the Internet. 3573 o Pmtu should be configurable to overcome issues/limitations of Path 3574 MTU Discovery (PMTUD). 3576 o IKEv2/IPsec to remote peers should support the optional NAT 3577 Traversal (NAT-T) procedures. 3579 8.2.2. Tunneled Remote ACP Neighbor 3581 An IPinIP, GRE or other form of pre-existing tunnel is configured 3582 between two remote ACP peers and the virtual interfaces representing 3583 the tunnel are configured for "ACP enable". This will enable IPv6 3584 link local addresses and DULL on this tunnel. In result, the tunnel 3585 is used for normal "L2 adjacent" candidate ACP neighbor discovery 3586 with DULL and secure channel setup procedures described in this 3587 document. 3589 Tunneled Remote ACP Neighbor requires two encapsulations: the 3590 configured tunnel and the secure channel inside of that tunnel. This 3591 makes it in general less desirable than Configured Remote ACP 3592 Neighbor. Benefits of tunnels are that it may be easier to implement 3593 because there is no change to the ACP functionality - just running it 3594 over a virtual (tunnel) interface instead of only native interfaces. 3595 The tunnel itself may also provide PMTUD while the secure channel 3596 method may not. Or the tunnel mechanism is permitted/possible 3597 through some firewall while the secure channel method may not. 3599 8.2.3. Summary 3601 Configured/Tunneled Remote ACP neighbors are less "indestructible" 3602 than L2 adjacent ACP neighbors based on link local addressing, since 3603 they depend on more correct Data-Plane operations, such as routing 3604 and global addressing. 3606 Nevertheless, these options may be crucial to incrementally deploy 3607 the ACP, especially if it is meant to connect islands across the 3608 Internet. Implementations SHOULD support at least Tunneled Remote 3609 ACP Neighbors via GRE tunnels - which is likely the most common 3610 router-to-router tunneling protocol in use today. 3612 9. Benefits (Informative) 3614 9.1. Self-Healing Properties 3616 The ACP is self-healing: 3618 o New neighbors will automatically join the ACP after successful 3619 validation and will become reachable using their unique ULA 3620 address across the ACP. 3622 o When any changes happen in the topology, the routing protocol used 3623 in the ACP will automatically adapt to the changes and will 3624 continue to provide reachability to all nodes. 3626 o The ACP tracks the validity of peer certificates and tears down 3627 ACP secure channels when a peer certificate has expired. When 3628 short-lived certificates with lifetimes in the order of OCSP/CRL 3629 refresh times are used, then this allows for removal of invalid 3630 peers (whose certificate was not renewed) at similar speeds as 3631 when using OCSP/CRL. The same benefit can be achieved when using 3632 CRL/OCSP, periodically refreshing the revocation information and 3633 also tearing down ACP secure channels when the peers (long-lived) 3634 certificate is revoked. There is no requirement against ACP 3635 implementations to require this enhancement though to keep the 3636 mandatory implementations simpler. 3638 The ACP can also sustain network partitions and mergers. Practically 3639 all ACP operations are link local, where a network partition has no 3640 impact. Nodes authenticate each other using the domain certificates 3641 to establish the ACP locally. Addressing inside the ACP remains 3642 unchanged, and the routing protocol inside both parts of the ACP will 3643 lead to two working (although partitioned) ACPs. 3645 There are few central dependencies: A certificate revocation list 3646 (CRL) may not be available during a network partition; a suitable 3647 policy to not immediately disconnect neighbors when no CRL is 3648 available can address this issue. Also, an ACP registrar or 3649 Certificate Authority might not be available during a partition. 3650 This may delay renewal of certificates that are to expire in the 3651 future, and it may prevent the enrollment of new nodes during the 3652 partition. 3654 Highly resilient ACP designs can be built by using ACP registrars 3655 with embedded sub-CA, as outlined in Section 10.2.4. As long as a 3656 partition is left with one or more of such ACP registrars, it can 3657 continue to enroll new candidate ACP nodes as long as the ACP 3658 registrars sub-CA certificate does not expire. Because the ACP 3659 addressing relies on unique Registrar-IDs, a later re-merge of 3660 partitions will also not cause problems with ACP addresses assigned 3661 during partitioning. 3663 After a network partition, a re-merge will just establish the 3664 previous status, certificates can be renewed, the CRL is available, 3665 and new nodes can be enrolled everywhere. Since all nodes use the 3666 same trust anchor(s), a re-merge will be smooth. 3668 Merging two networks with different trust anchors requires the ACP 3669 nodes to trust the union of Trust Anchors. As long as the routing- 3670 subdomain hashes are different, the addressing will not overlap, 3671 except for the low probability of a 40-bit hash collision in SHA256 3672 (see Section 6.10). Note that the complete mechanisms to merge 3673 networks is out of scope of this specification. 3675 It is also highly desirable for implementation of the ACP to be able 3676 to run it over interfaces that are administratively down. If this is 3677 not feasible, then it might instead be possible to request explicit 3678 operator override upon administrative actions that would 3679 administratively bring down an interface across which the ACP is 3680 running. Especially if bringing down the ACP is known to disconnect 3681 the operator from the node. For example any such down administrative 3682 action could perform a dependency check to see if the transport 3683 connection across which this action is performed is affected by the 3684 down action (with default RPL routing used, packet forwarding will be 3685 symmetric, so this is actually possible to check). 3687 9.2. Self-Protection Properties 3689 9.2.1. From the outside 3691 As explained in Section 6, the ACP is based on secure channels built 3692 between nodes that have mutually authenticated each other with their 3693 domain certificates. The channels themselves are protected using 3694 standard encryption technologies such as DTLS or IPsec which provide 3695 additional authentication during channel establishment, data 3696 integrity and data confidentiality protection of data inside the ACP 3697 and in addition, provide replay protection. 3699 An attacker will not be able to join the ACP unless having a valid 3700 domain certificate, also packet injection and sniffing traffic will 3701 not be possible due to the security provided by the encryption 3702 protocol. 3704 The ACP also serves as protection (through authentication and 3705 encryption) for protocols relevant to OAM that may not have secured 3706 protocol stack options or where implementation or deployment of those 3707 options fail on some vendor/product/customer limitations. This 3708 includes protocols such as SNMP ([RFC3411]), NTP ([RFC5905]), PTP 3709 ([IEEE-1588-2008]), DNS ([RFC1886]), DHCPv6 ([RFC3315]), syslog 3710 ([RFC3164]), Radius ([RFC2865]), Diameter ([RFC6733]), TACACS 3711 ([RFC1492]), IPFIX ([RFC7011]), Netflow ([RFC3954]) - just to name a 3712 few. Protection via the ACP secure hop-by-hop channels for these 3713 protocols is meant to be only a stopgap though: The ultimate goal is 3714 for these and other protocols to use end-to-end encryption utilizing 3715 the domain certificate and rely on the ACP secure channels primarily 3716 for zero-touch reliable connectivity, but not primarily for security. 3718 The remaining attack vector would be to attack the underlying ACP 3719 protocols themselves, either via directed attacks or by denial-of- 3720 service attacks. However, as the ACP is built using link-local IPv6 3721 addresses, remote attacks from the data-plane are impossible as long 3722 as the data-plane has no facilities to remotely sent IPv6 link-local 3723 packets. The only exception are ACP connected interfaces which 3724 require higher physical protection. The ULA addresses are only 3725 reachable inside the ACP context, therefore, unreachable from the 3726 Data-Plane. Also, the ACP protocols should be implemented to be 3727 attack resistant and not consume unnecessary resources even while 3728 under attack. 3730 9.2.2. From the inside 3732 The security model of the ACP is based on trusting all members of the 3733 group of nodes that receive an ACP domain certificate for the same 3734 domain. Attacks from the inside by a compromised group member are 3735 therefore the biggest challenge. 3737 Group members must be protected against attackers so that there is no 3738 easy way to compromise them, or use them as a proxy for attacking 3739 other devices across the ACP. For example, management plane 3740 functions (transport ports) should only be reachable from the ACP but 3741 not the Data-Plane. Especially for those management plane functions 3742 that have no good protection by themselves because they do not have 3743 secure end-to-end transport and to whom ACP does not only provides 3744 automatic reliable connectivity but also protection against attacks. 3745 Protection across all potential attack vectors is typically easier to 3746 do in devices whose software is designed from the ground up with 3747 security in mind than with legacy software based systems where the 3748 ACP is added on as another feature. 3750 As explained above, traffic across the ACP SHOULD still be end-to-end 3751 encrypted whenever possible. This includes traffic such as GRASP, 3752 EST and BRSKI inside the ACP. This minimizes man in the middle 3753 attacks by compromised ACP group members. Such attackers cannot 3754 eavesdrop or modify communications, they can just filter them (which 3755 is unavoidable by any means). 3757 See Appendix A.10.8 for further considerations how to avoid and deal 3758 with compromised nodes. 3760 9.3. The Administrator View 3762 An ACP is self-forming, self-managing and self-protecting, therefore 3763 has minimal dependencies on the administrator of the network. 3764 Specifically, since it is (intended to be) independent of 3765 configuration, there is no scope for configuration errors on the ACP 3766 itself. The administrator may have the option to enable or disable 3767 the entire approach, but detailed configuration is not possible. 3768 This means that the ACP must not be reflected in the running 3769 configuration of nodes, except a possible on/off switch (and even 3770 that is undesirable). 3772 While configuration is not possible, an administrator must have full 3773 visibility of the ACP and all its parameters, to be able to do 3774 trouble-shooting. Therefore, an ACP must support all show and debug 3775 options, as for any other network function. Specifically, a network 3776 management system or controller must be able to discover the ACP, and 3777 monitor its health. This visibility of ACP operations must clearly 3778 be separated from visibility of Data-Plane so automated systems will 3779 never have to deal with ACP aspect unless they explicitly desire to 3780 do so. 3782 Since an ACP is self-protecting, a node not supporting the ACP, or 3783 without a valid domain certificate cannot connect to it. This means 3784 that by default a traditional controller or network management system 3785 cannot connect to an ACP. See Section 8.1.1 for more details on how 3786 to connect an NMS host into the ACP. 3788 10. ACP Operations (Informative) 3790 The following sections document important operational aspects of the 3791 ACP. They are not normative because they do not impact the 3792 interoperability between components of the ACP, but they include 3793 recommendations/requirements for the internal operational model 3794 beneficial or necessary to achieve the desired use-case benefits of 3795 the ACP (see Section 3). 3797 o Section 10.1 describes recommended operator diagnostics 3798 capabilities of ACP nodes. The have been derived from diagnostic 3799 of a commercially available ACP implementation. 3801 o Section 10.2 describes high level how an ACP registrar needs to 3802 work, what its configuration parameters are and specific issues 3803 impacting the choices of deployment design due to renewal and 3804 revocation issues. It describes a model where ACP Registrars have 3805 their own sub-CA to provide the most distributed deployment option 3806 for ACP Registrars, and it describes considerations for 3807 centralized policy control of ACP Registrar operations. 3809 o Section 10.3 describes suggested ACP node behavior and operational 3810 interfaces (configuration options) to manage the ACP in so-called 3811 greenfield devices (previously unconfigured) and brownfield 3812 devices (preconfigured). 3814 The recommendations and suggestions of this chapter were derived from 3815 operational experience gained with a commercially available pre- 3816 standard ACP implementation. 3818 10.1. ACP (and BRSKI) Diagnostics 3820 Even though ACP and ANI in general are taking out many manual 3821 configuration mistakes through their automation, it is important to 3822 provide good diagnostics for them. 3824 The basic diagnostics is support of (yang) data models representing 3825 the complete (auto-)configuration and operational state of all 3826 components: BRSKI, GRASP, ACP and the infrastructure used by them: 3827 TLS/DTLS, IPsec, certificates, trust anchors, time, VRF and so on. 3828 While necessary, this is not sufficient: 3830 Simply representing the state of components does not allow operators 3831 to quickly take action - unless they do understand how to interpret 3832 the data, and that can mean a requirement for deep understanding of 3833 all components and how they interact in the ACP/ANI. 3835 Diagnostic supports should help to quickly answer the questions 3836 operators are expected to ask, such as "is the ACP working 3837 correctly?", or "why is there no ACP connection to a known 3838 neighboring node?" 3840 In current network management approaches, the logic to answer these 3841 questions is most often built as centralized diagnostics software 3842 that leverages the above mentioned data models. While this approach 3843 is feasible for components utilizing the ANI, it is not sufficient to 3844 diagnose the ANI itself: 3846 o Developing the logic to identify common issues requires 3847 operational experience with the components of the ANI. Letting 3848 each management system define its own analysis is inefficient. 3850 o When the ANI is not operating correctly, it may not be possible to 3851 run diagnostics from remote because of missing connectivity. The 3852 ANI should therefore have diagnostic capabilities available 3853 locally on the nodes themselves. 3855 o Certain operations are difficult or impossible to monitor in real- 3856 time, such as initial bootstrap issues in a network location where 3857 no capabilities exist to attach local diagnostics. Therefore it 3858 is important to also define means of capturing (logging) 3859 diagnostics locally for later retrieval. Ideally, these captures 3860 are also non-volatile so that they can survive extended power-off 3861 conditions - for example when a device that fails to be brought up 3862 zero-touch is being sent back for diagnostics at a more 3863 appropriate location. 3865 The most simple form of diagnostics answering questions such as the 3866 above is to represent the relevant information sequentially in 3867 dependency order, so that the first non-expected/non-operational item 3868 is the most likely root cause. Or just log/highlight that item. For 3869 example: 3871 Q: Is ACP operational to accept neighbor connections: 3873 o Check if any potentially necessary configuration to make ACP/ANI 3874 operational are correct (see Section 10.3 for a discussion of such 3875 commands). 3877 o Does the system time look reasonable, or could it be the default 3878 system time after clock chip battery failure (certificate checks 3879 depend on reasonable notion of time). 3881 o Does the node have keying material - domain certificate, trust 3882 anchors. 3884 o If no keying material and ANI is supported/enabled, check the 3885 state of BRSKI (not detailed in this example). 3887 o Check the validity of the domain certificate: 3889 * Does the certificate authenticate against the trust anchor? 3891 * Has it been revoked? 3893 * Was the last scheduled attempt to retrieve a CRL successful 3894 (e.g., do we know that our CRL information is up to date). 3896 * Is the certificate valid: validity start time in the past, 3897 expiration time in the future? 3899 * Does the certificate have a correctly formatted ACP domain 3900 information field? 3902 o Was the ACP VRF successfully created? 3904 o Is ACP enabled on one or more interfaces that are up and running? 3906 If all this looks good, the ACP should be running locally "fine" - 3907 but we did not check any ACP neighbor relationships. 3909 Question: why does the node not create a working ACP connection to a 3910 neighbor on an interface? 3912 o Is the interface physically up? Does it have an IPv6 link-local 3913 address? 3915 o Is it enabled for ACP? 3917 o Do we successfully send DULL GRASP messages to the interface (link 3918 layer errors)? 3920 o Do we receive DULL GRASP messages on the interface? If not, some 3921 intervening L2 equipment performing bad MLD snooping could have 3922 caused problems. Provide e.g., diagnostics of the MLD querier 3923 IPv6 and MAC address. 3925 o Do we see the ACP objective in any DULL GRASP message from that 3926 interface? Diagnose the supported secure channel methods. 3928 o Do we know the MAC address of the neighbor with the ACP objective? 3929 If not, diagnose SLAAC/ND state. 3931 o When did we last attempt to build an ACP secure channel to the 3932 neighbor? 3934 o If it failed, why: 3936 * Did the neighbor close the connection on us or did we close the 3937 connection on it because the domain certificate membership 3938 failed? 3940 * If the neighbor closed the connection on us, provide any error 3941 diagnostics from the secure channel protocol. 3943 * If we failed the attempt, display our local reason: 3945 + There was no common secure channel protocol supported by the 3946 two neighbors (this could not happen on nodes supporting 3947 this specification because it mandates common support for 3948 IPsec). 3950 + The ACP domain certificate membership check (Section 6.1.2) 3951 fails: 3953 - The neighbors certificate does not have the required 3954 trust anchor. Provide diagnostics which trust anchor it 3955 has (can identify whom the device belongs to). 3957 - The neighbors certificate does not have the same domain 3958 (or no domain at all). Diagnose domain-name and 3959 potentially other cert info. 3961 - The neighbors certificate has been revoked or could not 3962 be authenticated by OCSP. 3964 - The neighbors certificate has expired - or is not yet 3965 valid. 3967 * Any other connection issues in e.g., IKEv2 / IPsec, DTLS?. 3969 Question: Is the ACP operating correctly across its secure channels? 3971 o Are there one or more active ACP neighbors with secure channels? 3972 o Is the RPL routing protocol for the ACP running? 3974 o Is there a default route to the root in the ACP routing table? 3976 o Is there for each direct ACP neighbor not reachable over the ACP 3977 virtual interface to the root a route in the ACP routing table? 3979 o Is ACP GRASP running? 3981 o Is at least one SRV.est objective cached (to support certificate 3982 renewal)? 3984 o Is there at least one BRSKI registrar objective cached (in case 3985 BRSKI is supported) 3987 o Is BRSKI proxy operating normally on all interfaces where ACP is 3988 operating? 3990 o ... 3992 These lists are not necessarily complete, but illustrate the 3993 principle and show that there are variety of issues ranging from 3994 normal operational causes (a neighbor in another ACP domain) over 3995 problems in the credentials management (certificate lifetimes), 3996 explicit security actions (revocation) or unexpected connectivity 3997 issues (intervening L2 equipment). 3999 The items so far are illustrating how the ANI operations can be 4000 diagnosed with passive observation of the operational state of its 4001 components including historic/cached/counted events. This is not 4002 necessary sufficient to provide good enough diagnostics overall: 4004 The components of ACP and BRSKI are designed with security in mind 4005 but they do not attempt to provide diagnostics for building the 4006 network itself. Consider two examples: 4008 1. BRSKI does not allow for a neighboring device to identify the 4009 pledges certificate (IDevID). Only the selected BRSKI registrar 4010 can do this, but it may be difficult to disseminate information 4011 about undesired pledges from those BRSKI registrars to locations/ 4012 nodes where information about those pledges is desired. 4014 2. The Link Layer Discovery Protocol (LLDP, [LLDP]) disseminates 4015 information about nodes to their immediate neighbors, such as 4016 node model/type/software and interface name/number of the 4017 connection. This information is often helpful or even necessary 4018 in network diagnostics. It can equally considered to be too 4019 insecure to make this information available unprotected to all 4020 possible neighbors. 4022 An "interested adjacent party" can always determine the IDevID of a 4023 BRSKI pledge by behaving like a BRSKI proxy/registrar. Therefore the 4024 IDevID of a BRSKI pledge is not meant to be protected - it just has 4025 to be queried and is not signaled unsolicited (as it would be in 4026 LLDP) so that other observers on the same subnet can determine who is 4027 an "interested adjacent party". 4029 10.2. ACP Registrars 4031 As described in Section 6.10.7, the ACP addressing mechanism is 4032 designed to enable lightweight, distributed and uncoordinated ACP 4033 registrars that are providing ACP address prefixes to candidate ACP 4034 nodes by enrolling them with an ACP domain certificate into an ACP 4035 domain via any appropriate mechanism/protocol, automated or not. 4037 This section discusses informatively more details and options for ACP 4038 registrars. 4040 10.2.1. Registrar interactions 4042 This section summarizes and discusses the interactions with other 4043 entities required by an ACP registrar. 4045 In a simple instance of an ACP network, no central NOC component 4046 beside a trust anchor (root CA) is required. One or more 4047 uncoordinated acting ACP registrar can be set up, performing the 4048 following interactions: 4050 To orchestrate enrolling a candidate ACP node autonomically, the ACP 4051 registrar can rely on the ACP and use Proxies to reach the candidate 4052 ACP node, therefore allowing minimum pre-existing (auto-)configured 4053 network services on the candidate ACP node. BRSKI defines the BRSKI 4054 proxy, a design that can be adopted for various protocols that 4055 Pledges/candidate ACP nodes could want to use, for example BRSKI over 4056 CoAP (Constrained Application Protocol), or proxying of Netconf. 4058 To reach a trust anchor unaware of the ACP, the ACP registrar would 4059 use the Data-Plane. ACP and Data-Plane in an ACP registrar could 4060 (and by default should be) completely isolated from each other at the 4061 network level. Only applications such as the ACP registrar would 4062 need the ability for their transport stacks to access both. 4064 In non-autonomic enrollment options, the Data-Plane between a ACP 4065 registrar and the candidate ACP node needs to be configured first. 4066 This includes the ACP registrar and the candidate ACP node. Then any 4067 appropriate set of protocols can be used between ACP registrar and 4068 candidate ACP node to discover the other side, and then connect and 4069 enroll (configure) the candidate ACP node with an ACP domain 4070 certificate. Netconf ZeroTouch ([I-D.ietf-netconf-zerotouch]) is an 4071 example protocol that could be used for this. BRSKI using optional 4072 discovery mechanisms is equally a possibility for candidate ACP nodes 4073 attempting to be enrolled across non-ACP networks, such as the 4074 Internet. 4076 When candidate ACP nodes have secure bootstrap, such as BRSKI 4077 Pledges, they will not trust to be configured/enrolled across the 4078 network, unless being presented with a voucher (see [RFC8366]) 4079 authorizing the network to take possession of the node. An ACP 4080 registrar will then need a method to retrieve such a voucher, either 4081 offline, or online from a MASA (Manufacturer Authorized Signing 4082 Authority). BRSKI and Netconf ZeroTouch are two protocols that 4083 include capabilities to present the voucher to the candidate ACP 4084 node. 4086 An ACP registrar could operate EST for ACP certificate renewal and/or 4087 act as a CRL Distribution point. A node performing these services 4088 does not need to support performing (initial) enrollment, but it does 4089 require the same above described connectivity as an ACP registrar: 4090 via the ACP to ACP nodes and via the Data-Plane to the trust anchor 4091 and other sources of CRL information. 4093 10.2.2. Registrar Parameter 4095 The interactions of an ACP registrar outlined Section 6.10.7 and 4096 Section 10.2.1 above depend on the following parameters: 4098 A URL to the trust anchor (root CA) and credentials so that the 4099 ACP registrar can let the trust anchor sign candidate ACP member 4100 certificates. 4102 The ACP domain-name. 4104 The Registrar-ID to use. This could default to a MAC address of 4105 the ACP registrar. 4107 For recovery, the next-useable Node-IDs for zone (Zone-ID=0) sub- 4108 addressing scheme, for Vlong /112 and for Vlong /1120 sub- 4109 addressing scheme. These IDs would only need to be provisioned 4110 after recovering from a crash. Some other mechanism would be 4111 required to remember these IDs in a backup location or to recover 4112 them from the set of currently known ACP nodes. 4114 Policies if candidate ACP nodes should receive a domain 4115 certificate or not, for example based on the devices LDevID as in 4116 BRSKI. The ACP registrar may have a whitelist or blacklist of 4117 devices serialNumbers from their LDevID. 4119 Policies what type of address prefix to assign to a candidate ACP 4120 devices, based on likely the same information. 4122 For BRSKI or other mechanisms using vouchers: Parameters to 4123 determine how to retrieve vouchers for specific type of secure 4124 bootstrap candidate ACP nodes (such as MASA URLs), unless this 4125 information is automatically learned such as from the IDevID of 4126 candidate ACP nodes (as defined in BRSKI). 4128 10.2.3. Certificate renewal and limitations 4130 When an ACP node renews/rekeys its certificate, it may end up doing 4131 so via a different registrar (e.g., EST server) than the one it 4132 originally received its ACP domain certificate from, for example 4133 because that original ACP registrar is gone. The ACP registrar 4134 through which the renewal/rekeying is performed would by default 4135 trust the ACP domain information from the ACP nodes current ACP 4136 domain certificate and maintain this information so that the ACP node 4137 maintains its ACP address prefix. In EST renewal/rekeying, the ACP 4138 nodes current ACP domain certificate is signaled during the TLS 4139 handshake. 4141 This simple scenario has two limitations: 4143 1. The ACP registrars cannot directly assign certificates to nodes 4144 and therefore needs an "online" connection to the trust anchor 4145 (root CA). 4147 2. Recovery from a compromised ACP registrar is difficult. When an 4148 ACP registrar is compromised, it can insert for example 4149 conflicting ACP domain information and create thereby an attack 4150 against other ACP nodes through the ACP routing protocol. 4152 Even when such a malicious ACP registrar is detected, resolving the 4153 problem may be difficult because it would require identifying all the 4154 wrong ACP domain certificates assigned via the ACP registrar after it 4155 was compromised. And without additional centralized tracking of 4156 assigned certificates there is no way to do this. 4158 10.2.4. ACP Registrars with sub-CA 4160 In situations, where either of the above two limitations are an 4161 issue, ACP registrars could also be sub-CAs. This removes the need 4162 for connectivity to a root-CA whenever an ACP node is enrolled, and 4163 reduces the need for connectivity of such an ACP registrar to a root- 4164 CA to only those times when it needs to renew its own certificate. 4165 The ACP registrar would also now use its own (sub-CA) certificate to 4166 enroll and sign the ACP nodes certificates, and therefore it is only 4167 necessary to revoke a compromised ACP registrars sub-CA certificate. 4168 Alternatively one can let it expire and not renew it, when the 4169 certificate of the sub-CA is appropriately short-lived. 4171 As the ACP domain membership check verifies a peer ACP node's ACP 4172 domain certificate trust chain, it will also verify the signing 4173 certificate which is the compromised/revoked sub-CA certificate. 4174 Therefore ACP domain membership for an ACP node enrolled from a 4175 compromised and discovered ACP registrar will fail. 4177 ACP nodes enrolled by a compromised ACP registrar would automatically 4178 fail to establish ACP channels and ACP domain certificate renewal via 4179 EST and therefore revert to their role as a candidate ACP members and 4180 attempt to get a new ACP domain certificate from an ACP registrar - 4181 for example, via BRSKI. In result, ACP registrars that have an 4182 associated sub-CA makes isolating and resolving issues with 4183 compromised registrars easier. 4185 Note that ACP registrars with sub-CA functionality also can control 4186 the lifetime of ACP domain certificates easier and therefore also be 4187 used as a tool to introduce short lived certificates and not rely on 4188 CRL, whereas the certificates for the sub-CAs themselves could be 4189 longer lived and subject to CRL. 4191 10.2.5. Centralized Policy Control 4193 When using multiple, uncoordinated ACP registrars, several advanced 4194 operations are potentially more complex than with a single, resilient 4195 policy control backend, for example including but not limited to: 4197 Which candidate ACP node is permitted or not permitted into an ACP 4198 domain. This may not be a decision to be taken upfront, so that a 4199 per-serialNumber policy can be loaded into ever ACP registrar. 4200 Instead, it may better be decided in real-time including 4201 potentially a human decision in a NOC. 4203 Tracking of all enrolled ACP nodes and their certificate 4204 information. For example in support of revoking individual ACP 4205 nodes certificates. 4207 More flexible policies what type of address prefix or even what 4208 specific address prefix to assign to a candidate ACP node. 4210 These and other operations could be introduced more easily by 4211 introducing a centralized Policy Management System (PMS) and 4212 modifying ACP registrar behavior so that it queries the PMS for any 4213 policy decision occurring during the candidate ACP node enrollment 4214 process and/or the ACP node certificate renewal process. For 4215 example, which ACP address prefix to assign. Likewise the ACP 4216 registrar would report any relevant state change information to the 4217 PMS as well, for example when a certificate was successfully enrolled 4218 onto a candidate ACP node. 4220 10.3. Enabling and disabling ACP/ANI 4222 Both ACP and BRSKI require interfaces to be operational enough to 4223 support sending/receiving their packets. In node types where 4224 interfaces are by default (e.g., without operator configuration) 4225 enabled, such as most L2 switches, this would be less of a change in 4226 behavior than in most L3 devices (e.g.: routers), where interfaces 4227 are by default disabled. In almost all network devices it is common 4228 though for configuration to change interfaces to a physically 4229 disabled state and that would break the ACP. 4231 In this section, we discuss a suggested operational model to enable/ 4232 disable interfaces and nodes for ACP/ANI in a way that minimizes the 4233 risk of operator action to break the ACP in this way, and that also 4234 minimizes operator surprise when ACP/ANI becomes supported in node 4235 software. 4237 10.3.1. Filtering for non-ACP/ANI packets 4239 Whenever this document refers to enabling an interface for ACP (or 4240 BRSKI), it only requires to permit the interface to send/receive 4241 packets necessary to operate ACP (or BRSKI) - but not any other Data- 4242 Plane packets. Unless the Data-Plane is explicitly configured/ 4243 enabled, all packets not required for ACP/BRSKI should be filtered on 4244 input and output: 4246 Both BRSKI and ACP require link-local only IPv6 operations on 4247 interfaces and DULL GRASP. IPv6 link-local operations means the 4248 minimum signaling to auto-assign an IPv6 link-local address and talk 4249 to neighbors via their link-local address: SLAAC (Stateless Address 4250 Auto-Configuration - [RFC4862]) and ND (Neighbor Discovery - 4251 [RFC4861]). When the device is a BRSKI pledge, it may also require 4252 TCP/TLS connections to BRSKI proxies on the interface. When the 4253 device has keying material, and the ACP is running, it requires DULL 4254 GRASP packets and packets necessary for the secure-channel mechanism 4255 it supports, e.g., IKEv2 and IPsec ESP packets or DTLS packets to the 4256 IPv6 link-local address of an ACP neighbor on the interface. It also 4257 requires TCP/TLS packets for its BRSKI proxy functionality, if it 4258 does support BRSKI. 4260 10.3.2. Admin Down State 4262 Interfaces on most network equipment have at least two states: "up" 4263 and "down". These may have product specific names. "down" for 4264 example could be called "shutdown" and "up" could be called "no 4265 shutdown". The "down" state disables all interface operations down 4266 to the physical level. The "up" state enables the interface enough 4267 for all possible L2/L3 services to operate on top of it and it may 4268 also auto-enable some subset of them. More commonly, the operations 4269 of various L2/L3 services is controlled via additional node-wide or 4270 interface level options, but they all become only active when the 4271 interface is not "down". Therefore an easy way to ensure that all 4272 L2/L3 operations on an interface are inactive is to put the interface 4273 into "down" state. The fact that this also physically shuts down the 4274 interface is in many cases just a side effect, but it may be 4275 important in other cases (see below, Section 10.3.2.2). 4277 To provide ACP/ANI resilience against operators configuring 4278 interfaces to "down" state, this document recommends to separate the 4279 "down" state of interfaces into an "admin down" state where the 4280 physical layer is kept running and ACP/ANI can use the interface and 4281 a "physical down" state. Any existing "down" configurations would 4282 map to "admin down". In "admin down", any existing L2/L3 services of 4283 the Data-Plane should see no difference to "physical down" state. To 4284 ensure that no Data-Plane packets could be sent/received, packet 4285 filtering could be established automatically as described above in 4286 Section 10.3.1. 4288 As necessary (see discussion below) new configuration options could 4289 be introduced to issue "physical down". The options should be 4290 provided with additional checks to minimize the risk of issuing them 4291 in a way that breaks the ACP without automatic restoration. For 4292 example they could be denied to be issued from a control connection 4293 (netconf/ssh) that goes across the interface itself ("do not 4294 disconnect yourself"). Or they could be performed only temporary and 4295 only be made permanent with additional later reconfirmation. 4297 In the following sub-sections important aspects to the introduction 4298 of "admin down" state are discussed. 4300 10.3.2.1. Security 4302 Interfaces are physically brought down (or left in default down 4303 state) as a form of security. "Admin down" state as described above 4304 provides also a high level of security because it only permits ACP/ 4305 ANI operations which are both well secured. Ultimately, it is 4306 subject to security review for the deployment whether "admin down" is 4307 a feasible replacement for "physical down". 4309 The need to trust the security of ACP/ANI operations needs to be 4310 weighed against the operational benefits of permitting this: Consider 4311 the typical example of a CPE (customer premises equipment) with no 4312 on-site network expert. User ports are in physical down state unless 4313 explicitly configured not to be. In a misconfiguration situation, 4314 the uplink connection is incorrectly plugged into such as user port. 4315 The device is disconnected from the network and therefore no 4316 diagnostics from the network side is possible anymore. 4317 Alternatively, all ports default to "admin down". The ACP (but not 4318 the Data-Plane) would still automatically form. Diagnostics from the 4319 network side is possible and operator reaction could include to 4320 either make this port the operational uplink port or to instruct re- 4321 cabling. Security wise, only ACP/ANI could be attacked, all other 4322 functions are filtered on interfaces in "admin down" state. 4324 10.3.2.2. Fast state propagation and Diagnostics 4326 "Physical down" state propagates on many interface types (e.g., 4327 Ethernet) to the other side. This can trigger fast L2/L3 protocol 4328 reaction on the other side and "admin down" would not have the same 4329 (fast) result. 4331 Bringing interfaces to "physical down" state is to the best of our 4332 knowledge always a result of operator action, but today, never the 4333 result of (autonomic) L2/L3 services running on the nodes. Therefore 4334 one option is to change the operator action to not rely on link-state 4335 propagation anymore. This may not be possible when both sides are 4336 under different operator control, but in that case it is unlikely 4337 that the ACP is running across the link and actually putting the 4338 interface into "physical down" state may still be a good option. 4340 Ideally, fast physical state propagation is replaced by fast software 4341 driven state propagation. For example a DULL GRASP "admin-state" 4342 objective could be used to auto configure a Bidirectional Forwarding 4343 Protocol (BFD, [RFC5880]) session between the two sides of the link 4344 that would be used to propagate the "up" vs. admin down state. 4346 Triggering physical down state may also be used as a mean of 4347 diagnosing cabling in the absence of easier methods. It is more 4348 complex than automated neighbor diagnostics because it requires 4349 coordinated remote access to both (likely) sides of a link to 4350 determine whether up/down toggling will cause the same reaction on 4351 the remote side. 4353 See Section 10.1 for a discussion about how LLDP and/or diagnostics 4354 via GRASP could be used to provide neighbor diagnostics, and 4355 therefore hopefully eliminating the need for "physical down" for 4356 neighbor diagnostics - as long as both neighbors support ACP/ANI. 4358 10.3.2.3. Low Level Link Diagnostics 4360 "Physical down" is performed to diagnose low-level interface behavior 4361 when higher layer services (e.g., IPv6) are not working. Especially 4362 Ethernet links are subject to a wide variety of possible wrong 4363 configuration/cablings if they do not support automatic selection of 4364 variable parameters such as speed (10/100/1000 Mbps), crossover 4365 (Auto-MDIX) and connector (fiber, copper - when interfaces have 4366 multiple but can only enable one at a time). The need for low level 4367 link diagnostic can therefore be minimized by using fully auto 4368 configuring links. 4370 In addition to "Physical down", low level diagnostics of Ethernet or 4371 other interfaces also involve the creation of other states on 4372 interfaces, such as physical Loopback (internal and/or external) or 4373 bringing down all packet transmissions for reflection/cable-length 4374 measurements. Any of these options would disrupt ACP as well. 4376 In cases where such low-level diagnostics of an operational link is 4377 desired but where the link could be a single point of failure for the 4378 ACP, ASA on both nodes of the link could perform a negotiated 4379 diagnostics that automatically terminates in a predetermined manner 4380 without dependence on external input ensuring the link will become 4381 operational again. 4383 10.3.2.4. Power Consumption Issues 4385 Power consumption of "physical down" interfaces, may be significantly 4386 lower than those in "admin down" state, for example on long-range 4387 fiber interfaces. Bringing up interfaces, for example to probe 4388 reachability, may also consume additional power. This can make these 4389 type of interfaces inappropriate to operate purely for the ACP when 4390 they are not currently needed for the Data-Plane. 4392 10.3.3. Interface level ACP/ANI enable 4394 The interface level configuration option "ACP enable" enables ACP 4395 operations on an interface, starting with ACP neighbor discovery via 4396 DULL GRAP. The interface level configuration option "ANI enable" on 4397 nodes supporting BRSKI and ACP starts with BRSKI pledge operations 4398 when there is no domain certificate on the node. On ACP/BRSKI nodes, 4399 "ACP enable" may not need to be supported, but only "ANI enable". 4400 Unless overridden by global configuration options (see later), "ACP/ 4401 ANI enable" will result in "down" state on an interface to behave as 4402 "admin down". 4404 10.3.4. Which interfaces to auto-enable? 4406 (Section 6.3) requires that "ACP enable" is automatically set on 4407 native interfaces, but not on non-native interfaces (reminder: a 4408 native interface is one that exists without operator configuration 4409 action such as physical interfaces in physical devices). 4411 Ideally, ACP enable is set automatically on all interfaces that 4412 provide access to additional connectivity that allows to reach more 4413 nodes of the ACP domain. The best set of interfaces necessary to 4414 achieve this is not possible to determine automatically. Native 4415 interfaces are the best automatic approximation. 4417 Consider an ACP domain of ACP nodes transitively connected via native 4418 interfaces. A Data-Plane tunnel between two of these nodes that are 4419 non-adjacent is created and "ACP enable" is set for that tunnel. ACP 4420 RPL sees this tunnel as just as a single hop. Routes in the ACP 4421 would use this hop as an attractive path element to connect regions 4422 adjacent to the tunnel nodes. In result, the actual hop-by-hop paths 4423 used by traffic in the ACP can become worse. In addition, correct 4424 forwarding in the ACP now depends on correct Data-Plane forwarding 4425 config including QoS, filtering and other security on the Data-Plane 4426 path across which this tunnel runs. This is the main issue why "ACP/ 4427 ANI enable" should not be set automatically on non-native interfaces. 4429 If the tunnel would connect two previously disjoint ACP regions, then 4430 it likely would be useful for the ACP. A Data-Plane tunnel could 4431 also run across nodes without ACP and provide additional connectivity 4432 for an already connected ACP network. The benefit of this additional 4433 ACP redundancy has to be weighed against the problems of relying on 4434 the Data-Plane. If a tunnel connects two separate ACP regions: how 4435 many tunnels should be created to connect these ACP regions reliably 4436 enough? Between which nodes? These are all standard tunneled 4437 network design questions not specific to the ACP, and there are no 4438 generic fully automated answers. 4440 Instead of automatically setting "ACP enable" on these type of 4441 interfaces, the decision needs to be based on the use purpose of the 4442 non-native interface and "ACP enable" needs to be set in conjunction 4443 with the mechanism through which the non-native interface is created/ 4444 configured. 4446 In addition to explicit setting of "ACP/ANI enable", non-native 4447 interfaces also need to support configuration of the ACP RPL cost of 4448 the link - to avoid the problems of attracting too much traffic to 4449 the link as described above. 4451 Even native interfaces may not be able to automatically perform BRSKI 4452 or ACP because they may require additional operator input to become 4453 operational. Example include DSL interfaces requiring PPPoE 4454 credentials or mobile interfaces requiring credentials from a SIM 4455 card. Whatever mechanism is used to provide the necessary config to 4456 the device to enable the interface can also be expanded to decide on 4457 whether or not to set "ACP/ANI enable". 4459 The goal of automatically setting "ACP/ANI enable" on interfaces 4460 (native or not) is to eliminate unnecessary "touches" to the node to 4461 make its operation as much as possible "zero-touch" with respect to 4462 ACP/ANI. If there are "unavoidable touches" such a creating/ 4463 configuring a non-native interface or provisioning credentials for a 4464 native interface, then "ACP/ANI enable" should be added as an option 4465 to that "touch". If a wrong "touch" is easily fixed (not creating 4466 another high-cost touch), then the default should be not to enable 4467 ANI/ACP, and if it is potentially expensive or slow to fix (e.g., 4468 parameters on SIM card shipped to remote location), then the default 4469 should be to enable ACP/ANI. 4471 10.3.5. Node Level ACP/ANI enable 4473 A node level command "ACP/ANI enable [up-if-only]" enables ACP or ANI 4474 on the node (ANI = ACP + BRSKI). Without this command set, any 4475 interface level "ACP/ANI enable" is ignored. Once set, ACP/ANI will 4476 operate interface where "ACP/ANI enable" is set. Setting of 4477 interface level "ACP/ANI enable" is either automatic (default) or 4478 explicit through operator action as described in the previous 4479 section. 4481 If the option "up-if-only" is selected, the behavior of "down" 4482 interfaces is unchanged, and ACP/ANI will only operate on interfaces 4483 where "ACP/ANI enable" is set and that are "up". When it is not set, 4484 then "down" state of interfaces with "ACP/ANI enable" is modified to 4485 behave as "admin down". 4487 10.3.5.1. Brownfield nodes 4489 A "brownfield" node is one that already has a configured Data-Plane. 4491 Executing global "ACP/ANI enable [up-if-only]" on each node is the 4492 only command necessary to create an ACP across a network of 4493 brownfield nodes once all the nodes have a domain certificate. When 4494 BRSKI is used ("ANI enable"), provisioning of the certificates only 4495 requires set-up of a single BRSKI registrar node which could also 4496 implement a CA for the network. This is the most simple way to 4497 introduce ACP/ANI into existing (== brownfield) networks. 4499 The need to explicitly enable ACP/ANI is especially important in 4500 brownfield nodes because otherwise software updates may introduce 4501 support for ACP/ANI: Automatic enablement of ACP/ANI in networks 4502 where the operator does not only not want ACP/ANI but where the 4503 operator likely never even heard of it could be quite irritating to 4504 the operator. Especially when "down" behavior is changed to "admin 4505 down". 4507 Automatically setting "ANI enable" on brownfield nodes where the 4508 operator is unaware of it could also be a critical security issue 4509 depending on the vouchers used by BRKSI on these nodes. An attacker 4510 could claim to be the owner of these devices and create an ACP that 4511 the attacker has access/control over. In networks where the operator 4512 explicitly wants to enable the ANI this could not happen, because he 4513 would create a BRSKI registrar that would discover attack attempts. 4514 Nodes requiring "ownership vouchers" would not be subject to that 4515 attack. See [I-D.ietf-anima-bootstrapping-keyinfra] for more 4516 details. Note that a global "ACP enable" alone is not subject to 4517 these type of attacks, because it always depends on some other 4518 mechanism first to provision domain certificates into the device. 4520 10.3.5.2. Greenfield nodes 4522 A "greenfield" node is one that did not have any prior configuration. 4524 For greenfield nodes, only "ANI enable" is relevant. If another 4525 mechanism than BRSKI is used to (zero-touch) bootstrap a node, then 4526 it is up to that mechanism to provision domain certificates and to 4527 set global "ACP enable" as desired. 4529 Nodes supporting full ANI functionality set "ANI enable" 4530 automatically when they decide that they are greenfield, e.g., that 4531 they are powering on from factory condition. They will then put all 4532 native interfaces into "admin down" state and start to perform BRSKI 4533 pledge functionality - and once a domain certificate is enrolled they 4534 automatically enable ACP. 4536 Attempts for BRSKI pledge operations in greenfield state should 4537 terminate automatically when another method of configuring the node 4538 is used. Methods that indicate some form of physical possession of 4539 the device such as configuration via the serial console port could 4540 lead to immediate termination of BRSKI, while other parallel auto 4541 configuration methods subject to remote attacks might lead to BRSKI 4542 termination only after they were successful. Details of this may 4543 vary widely over different type of nodes. When BRSKI pledge 4544 operation terminates, this will automatically unset "ANI enable" and 4545 should terminate any temporarily needed state on the device to 4546 perform BRSKI - DULL GRASP, BRSKI pledge and any IPv6 configuration 4547 on interfaces. 4549 10.3.6. Undoing ANI/ACP enable 4551 Disabling ANI/ACP by undoing "ACP/ANI enable" is a risk for the 4552 reliable operations of the ACP if it can be executed by mistake or 4553 unauthorized. This behavior could be influenced through some 4554 additional property in the certificate (e.g., in the domain 4555 information extension field) subject to future work: In an ANI 4556 deployment intended for convenience, disabling it could be allowed 4557 without further constraints. In an ANI deployment considered to be 4558 critical more checks would be required. One very controlled option 4559 would be to not permit these commands unless the domain certificate 4560 has been revoked or is denied renewal. Configuring this option would 4561 be a parameter on the BRSKI registrar(s). As long as the node did 4562 not receive a domain certificate, undoing "ANI/ACP enable" should not 4563 have any additional constraints. 4565 10.3.7. Summary 4567 Node-wide "ACP/ANI enable [up-if-only]" commands enable the operation 4568 of ACP/ANI. This is only auto-enabled on ANI greenfield devices, 4569 otherwise it must be configured explicitly. 4571 If the option "up-if-only" is not selected, interfaces enabled for 4572 ACP/ANI interpret "down" state as "admin down" and not "physical 4573 down". In "admin-down" all non-ACP/ANI packets are filtered, but the 4574 physical layer is kept running to permit ACP/ANI to operate. 4576 (New) commands that result in physical interruption ("physical down", 4577 "loopback") of ACP/ANI enabled interfaces should be built to protect 4578 continuance or reestablishment of ACP as much as possible. 4580 Interface level "ACP/ANI enable" control per-interface operations. 4581 It is enabled by default on native interfaces and has to be 4582 configured explicitly on other interfaces. 4584 Disabling "ACP/ANI enable" global and per-interface should have 4585 additional checks to minimize undesired breakage of ACP. The degree 4586 of control could be a domain wide parameter in the domain 4587 certificates. 4589 10.4. Configuration and the ACP (summary) 4591 There is no desirable configuration for the ACP. Instead, all 4592 parameters that need to be configured in support of the ACP are 4593 limitations of the solution, but they are only needed in cases where 4594 not all components are made autonomic. Whereever this is necessary, 4595 it will rely on pre-existing mechanisms for configuration such as CLI 4596 or YANG ([RFC7950]) data models. 4598 The most important examples of such configuration include: 4600 o When ACP nodes do not support an autonomic way to receive an ACP 4601 domain certificate, for example BRSKI, then such certificate needs 4602 to be configured via some pre-existing mechanisms outside the 4603 scope of this specification. Today, router have typically a 4604 variety of mechanisms to do this. 4606 o Certificate maintenance requires PKI functions. Discovery of 4607 these functions across the ACP is automated (see Section 6.1.4), 4608 but their configuration is is not. 4610 o When non-ACP capable nodes need to be connected to the ACP, the 4611 connecting ACP node needs to be configuration to support this 4612 according to Section 8.1. 4614 o When devices are not autonomically bootstrapped, explicit 4615 configuration to enable the ACP needs to be applied. See 4616 Section 10.3. 4618 o When the ACP needs to be extended across interfacess other than 4619 L2, the ACP as defined in this document can not autodiscover 4620 candidate neighbors automatically. Remove neighbors need to be 4621 configured, see Section 8.2. 4623 Once the ACP is operating, any further configuration for the data- 4624 lane can be configured more reliably across the ACP itself because 4625 the ACP provides addressing and connectivity (routing) independent of 4626 the data-plane itself. For this, the configuration methods simply 4627 need to also allow to operate across the ACP VRF - netconf, ssh or 4628 any other method. 4630 The ACP also provides additional security through its hop-by-hop 4631 encryption for any such configuration operations: Some legacy 4632 configuration methods (SNMP, TFTP, HTTP) may not use end-to-end 4633 encryption, and most of the end-to-end secured configuration methods 4634 still allow for easy passive observation along the path about 4635 configuration taking place (transport flows, port numbers, IP 4636 addresses). 4638 The ACP can and should equally be used as the transport to configure 4639 any of the aforemention non-automic components of the ACP, but in 4640 that case, the same caution needs to be exercised as with data-plane 4641 configuration without ACP: Misconfiguration may cause the configuring 4642 entity to be disconnected from the node it configures - for example 4643 when incorrectly unconfiguring a remote ACP neighbor through which 4644 the configured ACP node is reached. 4646 11. Security Considerations 4648 After seeding an ACP by configuring at least one ACP registrar with 4649 routing-subdomain and a CA, an ACP is self-protecting and there is no 4650 need to apply configuration to make it secure (typically the ACP 4651 Registrar doubles as EST server for certificate renewal). Its 4652 security therefore does not depend on configuration. This does not 4653 include workarounds for non-autonomic components as explained in 4654 Section 8. See Section 9.2 for details of how the ACP protects 4655 itself against attacks from the outside and to a more limited degree 4656 from the inside as well. 4658 However, the security of the ACP depends on a number of other 4659 factors: 4661 o The usage of domain certificates depends on a valid supporting PKI 4662 infrastructure. If the chain of trust of this PKI infrastructure 4663 is compromised, the security of the ACP is also compromised. This 4664 is typically under the control of the network administrator. 4666 o Every ACP registrar is criticial infrastructure that needs to be 4667 hardened against attacks similar to a CA. A malicious registrar 4668 can enroll enemy plegdes to an ACP network or break ACP routing by 4669 duplicate ACP address assignment to pledges via their ACP domain 4670 certificates. 4672 o Security can be compromised by implementation errors (bugs), as in 4673 all products. 4675 There is no prevention of source-address spoofing inside the ACP. 4676 This implies that if an attacker gains access to the ACP, it can 4677 spoof all addresses inside the ACP and fake messages from any other 4678 node. 4680 The ACP It is designed to enable automation of current network 4681 management and future autonomic peer-to-peer/distributed network 4682 automation. Any ACP member can send ACP IPv6 packet to other ACP 4683 members and announce via ACP GRASP services to all ACP members 4684 without depenency against centralized components. 4686 The ACP relies on peer-to-peer authentication and authorization using 4687 ACP certificates. This security model is necessary to enable the 4688 autonomic ad-hoc any-to-any connectivity between ACP nodes. It 4689 provides infrastructure protection through hop by hop authentication 4690 and encryption - without relying on third parties. For any services 4691 where this complete autonomic peer-to-peer group security model is 4692 appropriate, the ACP domain certificate can also be used unchanged. 4693 For example for any type of data-plane routing protocol security. 4695 This ACP security model is designed primarily to protect against 4696 attack from the outside, but not against attacks from the inside. To 4697 protect against spoofing attacks from compromised on-path ACP nodes, 4698 end-to-end encryption inside the ACP is used by new ACP signaling: 4699 GRASP across the ACP using TLS. The same is expected from any non- 4700 legacy services/protocols using the ACP. Because no group-keys are 4701 used, there is no risk for impacted nodes to access end-to-end 4702 encrypted traffic from other ACP nodes. 4704 Attacks from impacted ACP nodes against the ACP are more difficult 4705 than against the data-plane because of the autoconfiguration of the 4706 ACP and the absence of configuration options that could be abused 4707 that allow to change/break ACP behavior. This is excluding 4708 configuration for workaround in support of non-autonomic components. 4710 Mitigation against compromised ACP members is possible through 4711 standard automated certificate management mechanisms including 4712 revocation and non-renewal of short-lived cdrtificates. In this 4713 version of the specification, there are no further optimization of 4714 these mechanisms defined for the ACP (but see Appendix A.10.8). 4716 Higher layer service built using ACP domain certificates should not 4717 solely rely on undifferentiated group security when another model is 4718 more appropriate/more secure. For example central network 4719 configuration relies on a security model where only few especially 4720 trusted nodes are allowed to configure the data-plane of network 4721 nodes (CLIL, Netconf). This can be done through ACP domain 4722 certificates by differentiating them and introduce roles. See 4723 Appendix A.10.5. 4725 Fundamentally, security depends on avoiding operator and network 4726 operations automation mistakes, implementation and architecture. 4727 Autonomic approaches such as the ACP largely eliminate operator 4728 mistakes and make it easier to recover from network operations 4729 mistakes. Implementation and architectural mistakes are still 4730 possible, as in all networking technologies. 4732 Many details of ACP are designed with security in mind and discussed 4733 elsewhere in the document: 4735 IPv6 addresses used by nodes in the ACP are covered as part of the 4736 node's domain certificate as described in Section 6.1.1. This allows 4737 even verification of ownership of a peers IPv6 address when using a 4738 connection authenticated with the domain certificate. 4740 The ACP acts as a security (and transport) substrate for GRASP inside 4741 the ACP such that GRASP is not only protected by attacks from the 4742 outside, but also by attacks from compromised inside attackers - by 4743 relying not only on hop-by-hop security of ACP secure channels, but 4744 adding end-to-end security for those GRASP messages. See 4745 Section 6.8.2. 4747 ACP provides for secure, resilient zero-touch discovery of EST 4748 servers for certificate renewal. See Section 6.1.4. 4750 ACP provides extensible, auto-configuring hop-by-hop protection of 4751 the ACP infrastructure via the negotiation of hop-by-hop secure 4752 channel protocols. See Section 6.5 and Appendix A.6. 4754 The ACP is designed to minimize attacks from the outside by 4755 minimizing its dependency against any non-ACP (Data-Plane) 4756 operations/configuration on a node. See also Section 6.12.2. 4758 In combination with BRSKI, ACP enables a resilient, fully zero-touch 4759 network solution for short-lived certificates that can be renewed or 4760 re-enrolled even after unintentional expiry (e.g., because of 4761 interrupted connectivity). See Appendix A.2. 4763 Because ACP secure channels can be long lived, but certificates used 4764 may be short lived, secure channels, for example built via IPsec need 4765 to be terminated when peer certificates expire. See Section 6.7.3. 4767 The ACP is designed to minimize attacks from the outside by 4768 minimizing its dependency against any non-ACP (Data-Plane) 4769 operations/configuration on a node. See also Section 6.12.2. 4771 12. IANA Considerations 4773 This document defines the "Autonomic Control Plane". 4775 The IANA is requested to register the value "AN_ACP" (without quotes) 4776 to the GRASP Objectives Names Table in the GRASP Parameter Registry. 4777 The specification for this value is this document, Section 6.3. 4779 The IANA is requested to register the value "SRV.est" (without 4780 quotes) to the GRASP Objectives Names Table in the GRASP Parameter 4781 Registry. The specification for this value is this document, 4782 Section 6.1.4. 4784 Explanation: This document chooses the initially strange looking 4785 format "SRV." because these objective names would be in 4786 line with potential future simplification of the GRASP objective 4787 registry. Today, every name in the GRASP objective registry needs to 4788 be explicitly allocated with IANA. In the future, this type of 4789 objective names could considered to be automatically registered in 4790 that registry for the same service for which is 4791 registered according to [RFC6335]. This explanation is solely 4792 informational and has no impact on the requested registration. 4794 The IANA is requested to create an ACP Parameter Registry with 4795 currently one registry table - the "ACP Address Type" table. 4797 "ACP Address Type" Table. The value in this table are numeric values 4798 0...3 paired with a name (string). Future values MUST be assigned 4799 using the Standards Action policy defined by [RFC8126]. The 4800 following initial values are assigned by this document: 4802 0: ACP Zone Addressing Sub-Scheme (ACP RFC Figure 10) / ACP Manual 4803 Addressing Sub-Scheme (ACP RFC Section 6.10.4) 4804 1: ACP Vlong Addressing Sub-Scheme (ACP RFC Section 6.10.5) 4806 13. Acknowledgements 4808 This work originated from an Autonomic Networking project at Cisco 4809 Systems, which started in early 2010. Many people contributed to 4810 this project and the idea of the Autonomic Control Plane, amongst 4811 which (in alphabetical order): Ignas Bagdonas, Parag Bhide, Balaji 4812 BL, Alex Clemm, Yves Hertoghs, Bruno Klauser, Max Pritikin, Michael 4813 Richardson, Ravi Kumar Vadapalli. 4815 Special thanks to Brian Carpenter, Elwyn Davies, Joel Halpern and 4816 Sheng Jiang for their thorough reviews and to Pascal Thubert and 4817 Michael Richardson to provide the details for the recommendations of 4818 the use of RPL in the ACP. 4820 Further input, review or suggestions were received from: Rene Struik, 4821 Brian Carpenter, Benoit Claise, William Atwood and Yongkang Zhang. 4823 14. Change log [RFC Editor: Please remove] 4825 14.1. Initial version 4827 First version of this document: draft-behringer-autonomic-control- 4828 plane 4830 14.2. draft-behringer-anima-autonomic-control-plane-00 4832 Initial version of the anima document; only minor edits. 4834 14.3. draft-behringer-anima-autonomic-control-plane-01 4836 o Clarified that the ACP should be based on, and support only IPv6. 4838 o Clarified in intro that ACP is for both, between devices, as well 4839 as for access from a central entity, such as an NMS. 4841 o Added a section on how to connect an NMS system. 4843 o Clarified the hop-by-hop crypto nature of the ACP. 4845 o Added several references to GDNP as a candidate protocol. 4847 o Added a discussion on network split and merge. Although, this 4848 should probably go into the certificate management story longer 4849 term. 4851 14.4. draft-behringer-anima-autonomic-control-plane-02 4853 Addresses (numerous) comments from Brian Carpenter. See mailing list 4854 for details. The most important changes are: 4856 o Introduced a new section "overview", to ease the understanding of 4857 the approach. 4859 o Merged the previous "problem statement" and "use case" sections 4860 into a mostly re-written "use cases" section, since they were 4861 overlapping. 4863 o Clarified the relationship with draft-ietf-anima-stable- 4864 connectivity 4866 14.5. draft-behringer-anima-autonomic-control-plane-03 4868 o Took out requirement for IPv6 --> that's in the reference doc. 4870 o Added requirement section. 4872 o Changed focus: more focus on autonomic functions, not only virtual 4873 out-of-band. This goes a bit throughout the document, starting 4874 with a changed abstract and intro. 4876 14.6. draft-ietf-anima-autonomic-control-plane-00 4878 No changes; re-submitted as WG document. 4880 14.7. draft-ietf-anima-autonomic-control-plane-01 4882 o Added some paragraphs in addressing section on "why IPv6 only", to 4883 reflect the discussion on the list. 4885 o Moved the Data-Plane ACP out of the main document, into an 4886 appendix. The focus is now the virtually separated ACP, since it 4887 has significant advantages, and isn't much harder to do. 4889 o Changed the self-creation algorithm: Part of the initial steps go 4890 into the reference document. This document now assumes an 4891 adjacency table, and domain certificate. How those get onto the 4892 device is outside scope for this document. 4894 o Created a new section 6 "workarounds for non-autonomic nodes", and 4895 put the previous controller section (5.9) into this new section. 4896 Now, section 5 is "autonomic only", and section 6 explains what to 4897 do with non-autonomic stuff. Much cleaner now. 4899 o Added an appendix explaining the choice of RPL as a routing 4900 protocol. 4902 o Formalized the creation process a bit more. Now, we create a 4903 "candidate peer list" from the adjacency table, and form the ACP 4904 with those candidates. Also it explains now better that policy 4905 (Intent) can influence the peer selection. (section 4 and 5) 4907 o Introduce a section for the capability negotiation protocol 4908 (section 7). This needs to be worked out in more detail. This 4909 will likely be based on GRASP. 4911 o Introduce a new parameter: ACP tunnel type. And defines it in the 4912 IANA considerations section. Suggest GRE protected with IPSec 4913 transport mode as the default tunnel type. 4915 o Updated links, lots of small edits. 4917 14.8. draft-ietf-anima-autonomic-control-plane-02 4919 o Added explicitly text for the ACP channel negotiation. 4921 o Merged draft-behringer-anima-autonomic-addressing-02 into this 4922 document, as suggested by WG chairs. 4924 14.9. draft-ietf-anima-autonomic-control-plane-03 4926 o Changed Neighbor discovery protocol from GRASP to mDNS. Bootstrap 4927 protocol team decided to go with mDNS to discover bootstrap proxy, 4928 and ACP should be consistent with this. Reasons to go with mDNS 4929 in bootstrap were a) Bootstrap should be reuseable also outside of 4930 full anima solutions and introduce as few as possible new 4931 elements. mDNS was considered well-known and very-likely even pre- 4932 existing in low-end devices (IoT). b) Using GRASP both for the 4933 insecure neighbor discovery and secure ACP operatations raises the 4934 risk of introducing security issues through implementation issues/ 4935 non-isolation between those two instances of GRASP. 4937 o Shortened the section on GRASP instances, because with mDNS being 4938 used for discovery, there is no insecure GRASP session any longer, 4939 simplifying the GRASP considerations. 4941 o Added certificate requirements for ANIMA in section 5.1.1, 4942 specifically how the ANIMA information is encoded in 4943 subjectAltName. 4945 o Deleted the appendix on "ACP without separation", as originally 4946 planned, and the paragraph in the main text referring to it. 4948 o Deleted one sub-addressing scheme, focusing on a single scheme 4949 now. 4951 o Included information on how ANIMA information must be encoded in 4952 the domain certificate in section "preconditions". 4954 o Editorial changes, updated draft references, etc. 4956 14.10. draft-ietf-anima-autonomic-control-plane-04 4958 Changed discovery of ACP neighbor back from mDNS to GRASP after 4959 revisiting the L2 problem. Described problem in discovery section 4960 itself to justify. Added text to explain how ACP discovery relates 4961 to BRSKY (bootstrap) discovery and pointed to Michael Richardsons 4962 draft detailing it. Removed appendix section that contained the 4963 original explanations why GRASP would be useful (current text is 4964 meant to be better). 4966 14.11. draft-ietf-anima-autonomic-control-plane-05 4968 o Section 5.3 (candidate ACP neighbor selection): Add that Intent 4969 can override only AFTER an initial default ACP establishment. 4971 o Section 6.10.1 (addressing): State that addresses in the ACP are 4972 permanent, and do not support temporary addresses as defined in 4973 RFC4941. 4975 o Modified Section 6.3 to point to the GRASP objective defined in 4976 draft-carpenter-anima-ani-objectives. (and added that reference) 4978 o Section 6.10.2: changed from MD5 for calculating the first 40-bits 4979 to SHA256; reason is MD5 should not be used any more. 4981 o Added address sub-scheme to the IANA section. 4983 o Made the routing section more prescriptive. 4985 o Clarified in Section 8.1.1 the ACP Connect port, and defined that 4986 term "ACP Connect". 4988 o Section 8.2: Added some thoughts (from mcr) on how traversing a L3 4989 cloud could be automated. 4991 o Added a CRL check in Section 6.7. 4993 o Added a note on the possibility of source-address spoofing into 4994 the security considerations section. 4996 o Other editoral changes, including those proposed by Michael 4997 Richardson on 30 Nov 2016 (see ANIMA list). 4999 14.12. draft-ietf-anima-autonomic-control-plane-06 5001 o Added proposed RPL profile. 5003 o detailed DTLS profile - DTLS with any additional negotiation/ 5004 signaling channel. 5006 o Fixed up text for ACP/GRE encap. Removed text claiming its 5007 incompatible with non-GRE IPsec and detailed it. 5009 o Added text to suggest admin down interfaces should still run ACP. 5011 14.13. draft-ietf-anima-autonomic-control-plane-07 5013 o Changed author association. 5015 o Improved ACP connect setion (after confusion about term came up in 5016 the stable connectivity draft review). Added picture, defined 5017 complete terminology. 5019 o Moved ACP channel negotiation from normative section to appendix 5020 because it can in the timeline of this document not be fully 5021 specified to be implementable. Aka: work for future document. 5022 That work would also need to include analysing IKEv2 and describin 5023 the difference of a proposed GRASP/TLS solution to it. 5025 o Removed IANA request to allocate registry for GRASP/TLS. This 5026 would come with future draft (see above). 5028 o Gave the name "ACP domain information field" to the field in the 5029 certificate carrying the ACP address and domain name. 5031 o Changed the rules for mutual authentication of certificates to 5032 rely on the domain in the ACP information field of the certificate 5033 instead of the OU in the certificate. Also renewed the text 5034 pointing out that the ACP information field in the certificate is 5035 meant to be in a form that it does not disturb other uses of the 5036 certificate. As long as the ACP expected to rely on a common OU 5037 across all certificates in a domain, this was not really true: 5038 Other uses of the certificates might require different OUs for 5039 different areas/type of devices. With the rules in this draft 5040 version, the ACP authentication does not rely on any other fields 5041 in the certificate. 5043 o Added an extension field to the ACP information field so that in 5044 the future additional fields like a subdomain could be inserted. 5045 An example using such a subdomain field was added to the pre- 5046 existing text suggesting sub-domains. This approach is necessary 5047 so that there can be a single (main) domain in the ACP information 5048 field, because that is used for mutual authentication of the 5049 certificate. Also clarified that only the register(s) SHOULD/MUST 5050 use that the ACP address was generated from the domain name - so 5051 that we can easier extend change this in extensions. 5053 o Took the text for the GRASP discovery of ACP neighbors from Brians 5054 grasp-ani-objectives draft. Alas, that draft was behind the 5055 latest GRASP draft, so i had to overhaul. The mayor change is to 5056 describe in the ACP draft the whole format of the M_FLOOD message 5057 (and not only the actual objective). This should make it a lot 5058 easier to read (without having to go back and forth to the GRASP 5059 RFC/draft). It was also necessary because the locator in the 5060 M_FLOOD messages has an important role and its not coded inside 5061 the objective. The specification of how to format the M_FLOOD 5062 message shuold now be complete, the text may be some duplicate 5063 with the DULL specificateion in GRASP, but no contradiction. 5065 o One of the main outcomes of reworking the GRASP section was the 5066 notion that GRASP announces both the candidate peers IPv6 link 5067 local address but also the support ACP security protocol including 5068 the port it is running on. In the past we shied away from using 5069 this information because it is not secured, but i think the 5070 additional attack vectors possible by using this information are 5071 negligible: If an attacker on an L2 subnet can fake another 5072 devices GRASP message then it can already provide a similar amount 5073 of attack by purely faking the link-local address. 5075 o Removed the section on discovery and BRSKI. This can be revived 5076 in the BRSKI document, but it seems mood given how we did remove 5077 mDNS from the latest BRSKI document (aka: this section discussed 5078 discrepancies between GRASP and mDNS discovery which should not 5079 exist anymore with latest BRSKI. 5081 o Tried to resolve the EDNOTE about CRL vs. OCSP by pointing out we 5082 do not specify which one is to be used but that the ACP should be 5083 used to reach the URL included in the certificate to get to the 5084 CRL storage or OCSP server. 5086 o Changed ACP via IPsec to ACP via IKEv2 and restructured the 5087 sections to make IPsec native and IPsec via GRE subsections. 5089 o No need for any assigned DTLS port if ACP is run across DTLS 5090 because it is signaled via GRASP. 5092 14.14. draft-ietf-anima-autonomic-control-plane-08 5094 Modified mentioning of BRSKI to make it consistent with current 5095 (07/2017) target for BRSKI: MASA and IDevID are mandatory. Devices 5096 with only insecure UDI would need a security reduced variant of 5097 BRSKI. Also added mentioning of Netconf Zero-Touch. Made BRSKI non- 5098 normative for ACP because wrt. ACP it is just one option how the 5099 domain certificate can be provisioned. Instead, BRSKI is mandatory 5100 when a device implements ANI which is ACP+BRSKI. 5102 Enhanced text for ACP across tunnels to describe two options: one 5103 across configured tunnels (GRE, IPinIP etc) a more efficient one via 5104 directed DULL. 5106 Moved decription of BRSKI to appendix to emphasize that BRSKI is not 5107 a (normative) dependency of GRASP, enhanced text to indicate other 5108 options how Domain Certificates can be provisioned. 5110 Added terminology section. 5112 Separated references into normative and non-normative. 5114 Enhanced section about ACP via "tunnels". Defined an option to run 5115 ACP secure channel without an outer tunnel, discussed PMTU, benefits 5116 of tunneling, potential of using this with BRSKI, made ACP via GREP a 5117 SHOULD requirement. 5119 Moved appendix sections up before IANA section because there where 5120 concerns about appendices to be too far on the bottom to be read. 5121 Added (Informative) / (Normative) to section titles to clarify which 5122 sections are informative and which are normative 5124 Moved explanation of ACP with L2 from precondition to separate 5125 section before workarounds, made it instructive enough to explain how 5126 to implement ACP on L2 ports for L3/L2 switches and made this part of 5127 normative requirement (L2/L3 switches SHOULD support this). 5129 Rewrote section "GRASP in the ACP" to define GRASP in ACP as 5130 mandatory (and why), and define the ACP as security and transport 5131 substrate to GRASP in ACP. And how it works. 5133 Enhanced "self-protection" properties section: protect legacy 5134 management protocols. Security in ACP is for protection from outside 5135 and those legacy protocols. Otherwise need end-to-end encryption 5136 also inside ACP, e.g., with domain certificate. 5138 Enhanced initial domain certificate section to include requirements 5139 for maintenance (renewal/revocation) of certificates. Added 5140 explanation to BRSKI informative section how to handle very short 5141 lived certificates (renewal via BRSKI with expired cert). 5143 Modified the encoding of the ACP address to better fit RFC822 simple 5144 local-parts (":" as required by RFC5952 are not permitted in simple 5145 dot-atoms according to RFC5322. Removed reference to RFC5952 as its 5146 now not needed anymore. 5148 Introduced a sub-domain field in the ACP information in the 5149 certificate to allow defining such subdomains with depending on 5150 future Intent definitions. It also makes it clear what the "main 5151 domain" is. Scheme is called "routing subdomain" to have a unique 5152 name. 5154 Added V8 (now called Vlong) addressing sub-scheme according to 5155 suggestion from mcr in his mail from 30 Nov 2016 5156 (https://mailarchive.ietf.org/arch/msg/anima/ 5157 nZpEphrTqDCBdzsKMpaIn2gsIzI). Also modified the explanation of the 5158 single V bit in the first sub-scheme now renamed to Zone sub-scheme 5159 to distinguish it. 5161 14.15. draft-ietf-anima-autonomic-control-plane-09 5163 Added reference to RFC4191 and explained how it should be used on ACP 5164 edge routers to allow auto configuration of routing by NMS hosts. 5165 This came after review of stable connectivity draft where ACP connect 5166 is being referred to. 5168 V8 addressing Sub-Scheme was modified to allow not only /8 device- 5169 local address space but also /16. This was in response to the 5170 possible need to have maybe as much as 2^12 local addresses for 5171 future encaps in BRSKI like IPinIP. It also would allow fully 5172 autonomic address assignment for ACP connect interfaces from this 5173 local address space (on an ACP edge device), subject to approval of 5174 the implied update to rfc4291/rfc4193 (IID length). Changed name to 5175 Vlong addressing sub-scheme. 5177 Added text in response to Brian Carpenters review of draft-ietf- 5178 anima-stable-connectivity-04. 5180 o The stable connectivity draft was vaguely describing ACP connect 5181 behavior that is better standardized in this ACP draft. 5183 o Added new ACP "Manual" addressing sub-scheme with /64 subnets for 5184 use with ACP connect interfaces. Being covered by the ACP ULA 5185 prefix, these subnets do not require additional routing entries 5186 for NMS hosts. They also are fully 64-bit IID length compliant 5187 and therefore not subject to 4191bis considerations. And they 5188 avoid that operators manually assign prefixes from the ACP ULA 5189 prefixes that might later be assigned autonomically. 5191 o ACP connect auto-configuration: Defined that ACP edge devices, NMS 5192 hosts should use RFC4191 to automatically learn ACP prefixes. 5193 This is especially necessary when the ACP uses multiple ULA 5194 prefixes (via e.g., the rsub domain certificate option), or if ACP 5195 connect sub-interfaces use manually configured prefixes NOT 5196 covered by the ACP ULA prefixes. 5198 o Explained how rfc6724 is (only) sufficient when the NMS host has a 5199 separate ACP connect and Data-Plane interface. But not when there 5200 is a single interface. 5202 o Added a separate subsection to talk about "software" instead of 5203 "NMS hosts" connecting to the ACP via the "ACP connect" method. 5204 The reason is to point out that the "ACP connect" method is not 5205 only a workaround (for NMS hosts), but an actual desirable long 5206 term architectural component to modularly build software (e.g., 5207 ASA or OAM for VNF) into ACP devices. 5209 o Added a section to define how to run ACP connect across the same 5210 interface as the Data-Plane. This turns out to be quite 5211 challenging because we only want to rely on existing standards for 5212 the network stack in the NMS host/software and only define what 5213 features the ACP edge device needs. 5215 o Added section about use of GRASP over ACP connect. 5217 o Added text to indicate packet processing/filtering for security: 5218 filter incorrect packets arriving on ACP connect interfaces, 5219 diagnose on RPL root packets to incorrect destination address (not 5220 in ACP connect section, but because of it). 5222 o Reaffirm security goal of ACP: Do not permit non-ACP routers into 5223 ACP routing domain. 5225 Made this ACP document be an update to RFC4291 and RFC4193. At the 5226 core, some of the ACP addressing sub-schemes do effectively not use 5227 64-bit IIDs as required by RFC4191 and debated in rfc4191bis. During 5228 6man in Prague, it was suggested that all documents that do not do 5229 this should be classified as such updates. Add a rather long section 5230 that summarizes the relevant parts of ACP addressing and usage and. 5231 Aka: This section is meant to be the primary review section for 5232 readers interested in these changes (e.g., 6man WG.). 5234 Added changes from Michael Richardsons review https://github.com/ 5235 anima-wg/autonomic-control-plane/pull/3/commits, textual and: 5237 o ACP discovery inside ACP is bad *doh*!. 5239 o Better CA trust and revocation sentences. 5241 o More details about RPL behavior in ACP. 5243 o black hole route to avoid loops in RPL. 5245 Added requirement to terminate ACP channels upon cert expiry/ 5246 revocation. 5248 Added fixes from 08-mcr-review-reply.txt (on github): 5250 o AN Domain Names are FQDNs. 5252 o Fixed bit length of schemes, numerical writing of bits (00b/01b). 5254 o Lets use US american english. 5256 14.16. draft-ietf-anima-autonomic-control-plane-10 5258 Used the term routing subdomain more consistently where previously 5259 only subdomain was used. Clarified use of routing subdomain in 5260 creation of ULA "global ID" addressing prefix. 5262 6.7.1.* Changed native IPsec encapsulation to tunnel mode 5263 (necessary), explained why. Added notion that ESP is used, added 5264 explanations why tunnel/transport mode in native vs. GRE cases. 5266 6.10.3/6.10.5 Added term "ACP address range/set" to be able to better 5267 explain how the address in the ACP certificate is actually the base 5268 address (lowest address) of a range/set that is available to the 5269 device. 5271 6.10.4 Added note that manual address sub-scheme addresses must not 5272 be used within domain certificates (only for explicit configuration). 5274 6.12.5 Refined explanation of how ACP virtual interfaces work (p2p 5275 and multipoint). Did seek for pre-existing RFCs that explain how to 5276 build a multi-access interface on top of a full mesh of p2p 5277 connections (6man WG, anima WG mailing lists), but could not find any 5278 prior work that had a succinct explanation. So wrote up an 5279 explanation here. Added hopefully all necessary and sufficient 5280 details how to map ACP unicast packets to ACP secure channel, how to 5281 deal with ND packet details. Added verbiage for ACP not to assign 5282 the virtual interface link-local address from the underlying 5283 interface. Added note that GRAP link-local messages are treated 5284 specially but logically the same. Added paragraph about NBMA 5285 interfaces. 5287 remaining changes from Brian Carpenters review. See Github file 5288 draft-ietf-anima-autonomic-control-plane/08-carpenter-review-reply.tx 5289 for more details: 5291 Added multiple new RFC references for terms/technologies used. 5293 Fixed verbage in several places. 5295 2. (terminology) Added 802.1AR as reference. 5297 2. Fixed up definition of ULA. 5299 6.1.1 Changed definition of ACP information in cert into ABNF format. 5300 Added warning about maximum size of ACP address field due to domain- 5301 name limitations. 5303 6.2 Mentioned API requirement between ACP and clients leveraging 5304 adjacency table. 5306 6.3 Fixed TTL in GRASP example: msec, not hop-count!. 5308 6.8.2 MAYOR: expanded security/transport substrate text: 5310 Introduced term ACP GRASP virtual interface to explain how GRASP 5311 link-local multicast messages are encapsulated and replicated to 5312 neighbors. Explain how ACP knows when to use TLS vs. TCP (TCP only 5313 for link-local address (sockets). Introduced "ladder" picture to 5314 visualize stack. 5316 6.8.2.1 Expanded discussion/explanation of security model. TLS for 5317 GRASP unicast connections across ACP is double encryption (plus 5318 underlying ACP secure channel), but highly necessary to avoid very 5319 simple man-in-the-middle attacks by compromised ACP members on-path. 5320 Ultimately, this is done to ensure that any apps using GRASP can get 5321 full end-to-end secrecy for information sent across GRASP. But for 5322 publically known ASA services, even this will not provide 100% 5323 security (this is discussed). Also why double encryption is the 5324 better/easier solution than trying to optimize this. 5326 6.10.1 Added discussion about pseudo-random addressing, scanning- 5327 attacks (not an issue for ACP). 5329 6.12.2 New performance requirements section added. 5331 6.10.1 Added notion to first experiment with existing addressing 5332 schemes before defining new ones - we should be flexible enough. 5334 6.3/7.2 clarified the interactions between MLD and DULL GRASP and 5335 specified what needs to be done (e.g., in 2 switches doing ACP per L2 5336 port). 5338 12. Added explanations and cross-references to various security 5339 aspects of ACP discussed elsewhere in the document. 5341 13. Added IANA requirements. 5343 Added RFC2119 boilerplate. 5345 14.17. draft-ietf-anima-autonomic-control-plane-11 5347 Same text as -10 Unfortunately when uploading -10 .xml/.txt to 5348 datatracker, a wrong version of .txt got uploaded, only the .xml was 5349 correct. This impacts the -10 html version on datatracker and the 5350 PDF versions as well. Because rfcdiff also compares the .txt 5351 version, this -11 version was created so that one can compare changes 5352 from -09 and changes to the next version (-12). 5354 14.18. draft-ietf-anima-autonomic-control-plane-12 5356 Sheng Jiangs extensive review. Thanks! See Github file draft-ietf- 5357 anima-autonomic-control-plane/09-sheng-review-reply.txt for more 5358 details. Many of the larger changes listed below where inspired by 5359 the review. 5361 Removed the claim that the document is updating RFC4291,RFC4193 and 5362 the section detailing it. Done on suggestion of Michael Richardson - 5363 just try to describe use of addressing in a way that would not 5364 suggest a need claim update to architecture. 5366 Terminology cleanup: 5368 o Replaced "device" with "node" in text. Kept "device" only when 5369 referring to "physical node". Added definitions for those words. 5370 Includes changes of derived terms, especially in addressing: 5371 "Node-ID" and "Node-Number" in the addressing details. 5373 o Replaced term "autonomic FOOBAR" with "acp FOOBAR" as wherever 5374 appropriate: "autonomic" would imply that the node would need to 5375 support more than the ACP, but that is not correct in most of the 5376 cases. Wanted to make sure that implementers know they only need 5377 to support/implement ACP - unless stated otherwise. Includes 5378 "AN->ACP node", "AN->ACP adjacency table" and so on. 5380 1 Added explanation in the introduction about relationship between 5381 ACP, BRSKI, ANI and Autonomic Networks. 5383 6.1.1 Improved terminology and features of the certificate 5384 information field. Now called domain information field instead of 5385 ACP information field. The acp-address field in the domain 5386 information field is now optional, enabling easier introduction of 5387 various future options. 5389 6.1.2 Moved ACP domain membership check from section 6.6 to (ACP 5390 secure channels setup) here because it is not only used for ACP 5391 secure channel setup. 5393 6.1.3 Fix text about certificate renewal after discussion with Max 5394 Pritikin/Michael Richardson/Brian Carpenter: 5396 o Version 10 erroneously assumed that the certificate itself could 5397 store a URL for renewal, but that is only possible for CRL URLs. 5398 Text now only refers to "remembered EST server" without implying 5399 that this is stored in the certificate. 5401 o Objective for RFC7030/EST domain certificate renewal was changed 5402 to "SRV.est" See also IANA section for explanation. 5404 o Removed detail of distance based service selection. This can be 5405 better done in future work because it would require a lot more 5406 detail for a good DNS-SD compatible approach. 5408 o Removed detail about trying to create more security by using ACP 5409 address from certificate of peer. After rethinking, this does not 5410 seem to buy additional security. 5412 6.10 Added reference to 6.12.5 in initial use of "loopback interface" 5413 in section 6.10 in result of email discussion michaelR/michaelB. 5415 10.2 Introduced informational section (diagnostics) because of 5416 operational experience - ACP/ANI undeployable without at least 5417 diagnostics like this. 5419 10.3 Introduced informational section (enabling/disabling) ACP. 5420 Important to discuss this for security reasons (e.g., why to never 5421 auto-enable ANI on brownfield devices), for implementers and to 5422 answer ongoing questions during WG meetings about how to deal with 5423 shutdown interface. 5425 10.8 Added informational section discussing possible future 5426 variations of the ACP for potential adopters that cannot directly use 5427 the complete solution described in this document unmodified. 5429 14.19. draft-ietf-anima-autonomic-control-plane-13 5431 Swap author list (with permission). 5433 6.1.1. Eliminate blank lines in definition by making it a picture 5434 (reformatting only). 5436 6.10.3.1 New paragraph: Explained how nodes using Zone-ID != 0 need 5437 to use Zone-ID != 0 in GRASP so that we can avoid routing/forwarding 5438 of Zone-ID = 0 prefixes. 5440 Rest of feedback from review of -12, see 5441 https://raw.githubusercontent.com/anima-wg/autonomic-control- 5442 plane/master/draft-ietf-anima-autonomic-control-plane/12-feedback- 5443 reply.txt 5445 Review from Brian Carpenter: 5447 various: Autonomous -> autonomic(ally) in all remaining occurrences. 5449 various: changed "manual (configured)" to "explicitly (configured)" 5450 to not exclude the option of (SDN controller) automatic configuration 5451 (no humans involved). 5453 1. Fixed reference to section 9. 5455 2. Added definition of loopback interface == internal interface. 5456 After discus on WG mailing lists, including 6man. 5458 6.1.2 Defined CDP/OCSP and pointed to RFC5280 for them. 5460 6.1.3 Removed "EST-TLS", no objective value needed or beneficial, 5461 added explanation paragraph why. 5463 6.2 Added to adjacency table the interface that a neighbor is 5464 discovered on. 5466 6.3 Simplified CDDL syntax: Only one method per AN_ACP objective 5467 (because of locators). Example with two objectives in GRASP message. 5469 6.8.1 Added note about link-local GRASP multicast message to avoid 5470 confusion. 5472 8.1.4 Added RFC8028 as recommended on hosts to better support VRF- 5473 select with ACP. 5475 8.2.1 Rewrote and Simplified CDDL for configured remote peer and 5476 explanations. Removed pattern option for remote peer. Not important 5477 enough to be mandated. 5479 Review thread started by William Atwood: 5481 2. Refined definition of VRF (vs. MPLS/VPN, LISP, VRF-LITE). 5483 2. Refined definition of ACP (ACP includes ACP GRASP instance). 5485 2. Added explanation for "zones" to terminology section and into 5486 Zone Addressing Sub Scheme section, relating it to RFC4007 zones 5487 (from Brian Carpenter). 5489 4. Fixed text for ACP4 requirement (Clients of the ACP must not be 5490 tied to specific protocol.). 5492 5. Fixed step 4. with proposed text. 5494 6.1.1 Included suggested explanation for rsub semantics. 5496 6.1.3 must->MUST for at least one EST server in ACP network to 5497 autonomically renew certs. 5499 6.7.2 normative: AND MUST NOT (permit weaker crypto options. 5501 6.7.1.1 also included text denying weaker IPsec profile options. 5503 6.8.2 Fixed description how to build ACP GRASP virtual interfaces. 5504 Added text that ACP continues to exist in absence of ACP neighbors. 5506 various: Make sure all "zone" words are used consistently. 5508 6.10.2/various: fixed 40-bit RFC4193 ULA prefix in all examples to 5509 89b714f3db (thanks MichaelR). 5511 6.10.1 Removed comment about assigned ULA addressing. Decision not 5512 to use it now ancient history of WG decision making process, not 5513 worth nothing anymore in the RFC. 5515 Review from Yongkang Zhang: 5517 6.10.5 Fixed length of Node-Numbers in ACP Vlong Addressing Sub- 5518 Scheme. 5520 14.20. draft-ietf-anima-autonomic-control-plane-14 5522 Disclaimer: All new text introduced by this revision provides only 5523 additional explanations/ details based on received reviews and 5524 analysis by the authors. No changes to behavior already specified in 5525 prior revisions. 5527 Joel Halpern, review part 3: 5529 Define/explain "ACP registrar" in reply to Joel Halpern review part 5530 3, resolving primarily 2 documentation issues:: 5532 1. Unclear how much ACP depends on BRSKI. ACP document was 5533 referring unqualified to registrars and Registrar-ID in the 5534 addressing section without explaining what a registrar is, 5535 leading to the assumption it must be a BRSKI Registrar. 5537 2. Unclear how the ACP addresses in ACP domain certificates are 5538 assigned because the BRSKI document does not defines this, but 5539 refers to this ACP document. 5541 Wrt. 1: ACP does NOT depend on BRSKI registrars, instead ANY 5542 appropriate automated or manual mechanism can be used to enroll ACP 5543 nodes with ACP domain certificates. This revision calls defines such 5544 mechanisms the "ACP registrar" and defines requirements. this is 5545 non-normative, because it does not define specific mechanisms that 5546 need to be support. In ANI devices, ACP Registrars are BRSKI 5547 Registrars. In non-ANI ACP networks, the registrar may simply be a 5548 person using CLI/web-interfaces to provision domain certificates and 5549 set the ACP address correctly in the ACP domain certificate. 5551 Wrt. 2.: The BRSKI document does rightfully not define how the ACP 5552 address assignment and creation of the ACP domain information field 5553 has to work because this is independent of BRSKI and needs to follow 5554 the same rules whatever protocol/mechanisms are used to implement an 5555 ACP Registrar. Another set of protocols that could be used instead 5556 of BRSKI is Netconf/Netconf-Call-Home, but such an alternative ACP 5557 Registrar solution would need to be specified in its own document. 5559 Additional text/sections had to be added to detail important 5560 conditions so that automatic certificate maintenance for ACP nodes 5561 (with BRSKI or other mechanisms) can be done in a way that as good as 5562 possible maintains ACP address information of ACP nodes across the 5563 nodes lifetime because that ACP address is intended as an identifier 5564 of the ACP node. 5566 Summary of sections added: 5568 o 6.1.3.5/6.1.3.6 (normative): re-enrollment of ACP nodes after 5569 certificate expiry/failure in a way that allows to maintain as 5570 much as possible ACP address information. 5572 o 6.10.7 (normative): defines "ACP Registrar" including requirements 5573 and how it can perform ACP address assignment. 5575 o 10.3 (informative): details / examples about registrars to help 5576 implementers and operators understand easier how they operate, and 5577 provide suggestion of models that a likely very useful (sub-CA 5578 and/or centralized policy management). 5580 o 10.4 (informative): Explains the need for the multiple address 5581 sub-spaces defined in response to discuss with Joel. 5583 Other changes: 5585 Updated references (RFC8366, RFC8368). 5587 Introduced sub-section headings for 6.1.3 (certificate maintenance) 5588 because section became too long with newly added sub-sections. Also 5589 some small text fixups/remove of duplicate text. 5591 Gen-ART review, Elwyn Davies: 5593 [RFC Editor: how can i raise the issue of problematic cross 5594 references of terms in the terminology section - rendering is 5595 problematic. ]. 5597 4. added explanation for ACP4 (finally). 5599 6.1.1 Simplified text in bullet list explaining rfc822 encoding. 5601 6.1.3 refined second paragraph defining remembering of previous EST 5602 server and explaining how to do this with BRSKI. 5604 9.1 Added paragraph outlining the benefit of the sub-CA Registrar 5605 option for supporting partitioned networks. 5607 Roughly 100 more nits/minor fixes throughout the document. See: 5608 https://raw.githubusercontent.com/anima-wg/autonomic-control- 5609 plane/master/draft-ietf-anima-autonomic-control-plane/13-elwynd- 5610 reply.txt 5612 Joel Halpern, review part 2: 5614 6.1.1: added note about "+ +" format in address field when acp- 5615 address and rsub are empty. 5617 6.5.10 - clarified text about V bit in Vlong addressing scheme. 5619 6.10.3/6.10.4 - moved the Z bit field up front (directly after base 5620 scheme) and indicated more explicitly Z is part of selecting of the 5621 sub-addressing scheme. 5623 Refined text about reaching CRL Distribution Point, explain why 5624 address as indicator to use ACP. 5626 Note from Brian Carpenter: RFC Editor note for section reference into 5627 GRASP. 5629 IOT directorate review from Pascal Thubert: 5631 Various Nits/typos. 5633 TBD: Punted wish for mentioning RFC reference titles to RFC editor 5634 for now. 5636 1. Added section 1.1 - applicability, discussing protocol choices 5637 re. applicability to constrained devices (or not). Added notion of 5638 TCP/TLS via CoAP/DTLS to section 10.4 in support of this. 5640 2. Added in-band / out-of-band into terminology. 5642 5. Referenced section 8.2 for remote ACP channel configuration. 5644 6.3 made M_FLOOD periods RECOMMENDED (less guesswork) 5646 6.7.x Clarified conditional nature of MUST for the profile details of 5647 IPsec parameters (aka: only 6.7.3 defines actual MUST for nodes, 5648 prior notions only define the requirements for IPsec profiles IF 5649 IPsec is supported. 5651 6.8.1 Moved discussion about IP multicast, IGP, RPL for GRASP into a 5652 new subsection in the informative part (section 10) to tighten up 5653 text in normative part. 5655 6.10.1 added another reference to stable-connectivity for interop 5656 with IPv4 management. 5658 6.10.1 removed mentioning of ULA-Random, term was used in email 5659 discus of ULA with L=1, but term actually not defined in rfc4193, so 5660 mentioning it is just confusing/redundant. Also added note about the 5661 random hash being defined in this document, not using SHA1 from 5662 rfc4193. 5664 6.11.1.1 added suggested text about mechanisms to further reduce 5665 opportunities for loop during reconvergence (active signaling options 5666 from RFC6550). 5668 6.11.1.3 made mode 2 MUST and mode 2 MAY (RPL MOP - mode of 5669 operations). Removes ambiguity. 5671 6.12.5 Added recommendation for RFC4429 (optimistic DAD). 5673 Nits from Benjamin Kaduk: dTLS -> DTLS: 5675 Review from Joel Halpern: 5677 1. swapped order of "purposes" for ACP to match order in section 3. 5679 1. Added notion about manageability of ACP gong beyond RFC7575 5680 (before discussion of stable connectivity). 5682 2. Changed definition of Intent to be same as reference model 5683 (policy language instead of API). 5685 6.1.1 changed BNF specification so that a local-part without acp- 5686 address (for future extensions) would not be rfcSELF.+rsub but 5687 simpler rfcSELF+rsub. Added explanation why rsub is in local-part. 5689 Tried to eliminate unnecessary references to VRF to minimize 5690 assumption how system is designed. 5692 6.1.3 Explained how to make CDP reachable via ACP. 5694 6.7.2 Made it clearer that constrained devices MUST support DTLS if 5695 they cannot support IPsec. 5697 6.8.2.1 clarified first paragraph (TCP retransmissions lightweight). 5699 6.11.1 fixed up RPL profile text - to remove "VRF". Text was also 5700 buggy. mentioned control plane, but it's a forwarding/silicon issue 5701 to have these header. 5703 6.12.5 Clarified how link-local ACP channel address can be derived, 5704 and how not. 5706 8.2.1 Fixed up text to distinguish between configuration and model 5707 describing parameters of the configuration (spec only provides 5708 parameter model). 5710 Various Nits. 5712 14.21. draft-ietf-anima-autonomic-control-plane-15 5714 Only reshuffling and formatting changes, but wanted to allow 5715 reviewers later to easily compare -13 with -14, and these changes in 5716 -15 mess that up too much. 5718 increased TOC depth to 4. 5720 Separated and reordered section 10 into an operational and a 5721 background and futures section. The background and futures could 5722 also become appendices if the layout of appendices in RFC format 5723 wasn't so horrible that you really only want to avoid using them (all 5724 the way after a lot of text like references that stop most readers 5725 from proceeding any further). 5727 14.22. draft-ietf-anima-autonomic-control-plane-16 5729 Mirja Kuehlewind: 5731 Tightened requirements for ACP related GRASP objective timers. 5733 Better text to introduce/explains baseline and constrained ACP 5734 profiles. 5736 IANA guideline: MUST only accept extensible last allocation for 5737 address sub-scheme. 5739 Moved section 11 into appendix. 5741 Warren Kumari: 5743 Removed "global routing table", replaced with "Data-Plane routing 5744 (and forwarding) tables. 5746 added text to indicate how routing protocols do like to have data- 5747 plane dependencies. 5749 Changed power consumption section re. admin-down state. Power needed 5750 to bring up such interfaces make t inappropriate to probe. Need to 5751 think more about best suggests -> beyond scope. 5753 Replaced "console" with out-of-band... (console/management ethernet). 5755 Various nits. 5757 Joel Halpern: 5759 Fixed up domain information field ABNF to eliminate confusion that 5760 rsub is not an FQDN but only a prefix to routing-subdomain. 5762 Corrected certcheck to separate out cert verification into lifetime 5763 validity and proof of ownership of private key. 5765 Fixed pagination for "ACP as security and transport substrate for 5766 GRASP" picture. 5768 14.23. draft-ietf-anima-autonomic-control-plane-17 5770 Review Alissa Cooper: 5772 Main discuss point fixed by untangling two specific node type cases: 5774 NOC nodes have ACP domain cert without acp-address field. Are ACP 5775 domain members, but cannot build ACP secure channels (just end-to-end 5776 or nay other authentications. 5778 ACP nodes may have other methods to assign ACP address than getting 5779 it through the cert. This is indicated through new value 0 for acp- 5780 address in certificate. 5782 Accordingly modified texts in ABNF/explanation and Cert-Check 5783 section. 5785 Other: 5787 Better separation of normative text and considerations for "future" 5788 work: 5790 - Marked missing chapters as Informative. Reworded requirements 5791 section to indicate its informative nature, changed requirements to 5792 _MUST_/_SHOULD_ to indicate these are not RFC2119 requirements but 5793 that this requirements section is really just in place of a separate 5794 solutions requirements document (that ANIMA was not allowed to 5795 produce). 5797 - removed ca. 20 instances of "futures" in normative part of 5798 document. 5800 - moved important instances of "futures" into new section A.10 (last 5801 section of appendix). These serve as reminder of work discussed 5802 during WG but not able to finish specifying it. 5804 Eliminated perception that "rsub" (routing subdomain) is only 5805 beneficial with future work. Example in A.7. 5807 Added RFC-editor note re formatting of references to terms defined in 5808 terminology section. 5810 Using now correct RFC 8174 boilerplate. 5812 Clarified semantic and use of manual ACP sub-scheme. Not used in 5813 certificates, only assigned via traditional methods. Use for ACP- 5814 connect subnets or the like. 5816 Corrected text about Data-Plane dependencies of ACP. Appropriate 5817 implementations can be fully data-plane independent (without more 5818 spec work) if not sharing link-local address with Data-Plane. 6.12.2 5819 text updated to discuss those (MAC address), A.10.2 discusses options 5820 that would require new standards work. 5822 Moved all text about Intent into A.8 to clearly mark it as futures. 5824 Changed suggestion of future insecure ACP option to future "end-to- 5825 end-security-only" option. 5827 Various textual fixes. 5829 Gen-ART review by Elwyn Davies: 5831 Some fixes also mentioned by Alissa. 5833 Added reference for OT. 5835 Fixed notion that secure channel is not only a security association. 5837 >20 good textual fixes. Thanks! 5839 Other: 5841 Added picture requested by Pascal Thubert about Dual-NOC (A.10.4). 5843 Moved RFC-editor request for better first RFC reference closer to the 5844 top of the document. 5846 Fixed typo /126 -> 127 for prefix length with zone address scheme. 5848 Overlooked early SecDir review from frank.xialiang@huawei.com: 5850 most issues fixed through other review in -16. Added reference to 5851 self-protection section 9.2 into security considerations section. 5853 14.24. draft-ietf-anima-autonomic-control-plane-18 5855 Too many word/grammar mistakes in -17. 5857 14.25. draft-ietf-anima-autonomic-control-plane-19 5859 Review Eric Rescola: 5861 6.1.2 - clarified that we do certificate path validation against 5862 potentially multiple trust anchors. 5864 6.1.3 - Added more comprehensive explanation of Trust Points via new 5865 section 6.1.3. 5867 6.5 - added figure with sequential steps of ACP channel establishment 5868 and Alice and Bob finding their role in the setup. 5870 6.7.x - detailled crypto profiles: AES-256-GCM, ECDHE. 5872 6.7.2 - Referring to RFC7525 as the required crypto profile for DTLS 5873 (taking text from RFC8310 as previously discussed with Eric). 5875 6.7.3 - Added explanation that ACP needs no single MTI secure channel 5876 protocol with example. 5878 6.10.2 - Added requirement that rsub must be choosen so that they 5879 don't create SHA256 collisions. Added explanation how the same could 5880 be done for different ACP networks with same trust anchors but that 5881 this outside the scope of this specification. 5883 6.7.10 - Explains security expectations against ACP registrars: Must 5884 be trusted and then given credentials to act as PKI RA to help 5885 pledges to enroll with an ACP certificate. 5887 9.1 - Added explanations about merging ACP domains requiring both 5888 domains to trust union of Trust Anchors and need to avod ULA hash 5889 collisions. 5891 11 - Added that ACP registrars are critical infrastructure requiring 5892 hardening like CA, mentioning attack impact examples. 5894 11 - Mentioning that ACP requires initial setup of CA and registrar. 5896 11 - long rewrite/extension of group security model and its 5897 implication shared with review from Ben (below). 5899 Many nits fixed. 5901 Review Benjamin Kaduk: 5903 Fixed various nits. 5905 Changed style of MUST/SHOULD in Requirements section to all lower 5906 case to avoid any RFC2119 confusion. 5908 1. clarified support for constrained devices/DTLS: Opportunistic. 5910 1. Clarified ACPs use of two variants of GRASP DULL for neighbor 5911 discovery and ACP grasp for service discovery/clients. 5913 3.2 - amended text explaining what additional security ACP provides 5914 for bootstrap protocols. 5916 6.1.1 - Added note about ASN.1 encoding in the justification for use 5917 of rfc822address. 5919 6.1.2 - Added details how to handle ACP connection when node via 5920 which OCSP/CRL-server is reached fails certificate verification. 5922 12. Rewrote explanation why objective names requested for ACP use 5923 SRV.name. 5925 10.4 - added summary section about ACP and configuration. 5927 Review Eric Rescorla: 5929 6.1.2 - changed peer certificate verification to be certificate path 5930 verification, added lowercase normalizaion comparison to domain name 5931 check. 5933 6.1.2 - explained how domain membership check is authentication and 5934 authorization. 5936 6.1.4.1 - Fixed "objective value" to "objective name". 5938 6.1.4.3 - check IPv6 address of CDP against CDP ACP certificate IPv6 5939 address only if URL uses IPv6 address. 5941 6.10.1 - added more justification why there is no need for privacy 5942 protection of ACP addresses. 5944 6.11.1.1 - thorough fixup of sentences/structure of this RPL overview 5945 section to make it more logical and easier to digest. Also added a 5946 paragraph about the second key benefit of this profile (scalability). 5948 6.11.1.9 - Added explanation about not using RPL security from 5949 Benjamin. 5951 8.1.1 - Fixed up text for address assignment of ACP connect 5952 interfaces. Only recommending manual addressing scheme. 5954 9.1 - changed self-healing benefit text to describe immediate channel 5955 reset for short-lived certificates and describing how the same with 5956 CRL/OCSP is optional. 5958 11. - added note about immediate termination of secure channels after 5959 certificate expiry as this is uncommon today. 5961 11. - rewrote section of security model, attacks and mitigation of 5962 compromised ACP members. 5964 A.24 - clarified the process in which expired certificates are used 5965 for certificate renewal to avvoid higher overhead of -re-enrolment. 5967 A.4 - removed mentioning of RPL trickle because not used by ACP RPL 5968 profile. 5970 A.10.8 - added section discussing how to minimize risk of compromised 5971 nodes, recovering them or kicking them out. 5973 14.26. Open Issues in -19 5975 Need to find good reference for TLS profile for ACP GRASP TLS 5976 connections. 5978 TBD: Add DTLS choice to GRASP secure channel. 5980 15. References 5982 15.1. Normative References 5984 [I-D.ietf-anima-grasp] 5985 Bormann, C., Carpenter, B., and B. Liu, "A Generic 5986 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 5987 grasp-15 (work in progress), July 2017. 5989 [I-D.ietf-cbor-cddl] 5990 Birkholz, H., Vigano, C., and C. Bormann, "Concise data 5991 definition language (CDDL): a notational convention to 5992 express CBOR and JSON data structures", draft-ietf-cbor- 5993 cddl-07 (work in progress), February 2019. 5995 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 5996 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 5997 . 5999 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 6000 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 6001 DOI 10.17487/RFC3810, June 2004, 6002 . 6004 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 6005 (GCM) in IPsec Encapsulating Security Payload (ESP)", 6006 RFC 4106, DOI 10.17487/RFC4106, June 2005, 6007 . 6009 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 6010 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 6011 November 2005, . 6013 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 6014 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 6015 . 6017 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 6018 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 6019 2006, . 6021 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 6022 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 6023 December 2005, . 6025 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 6026 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 6027 DOI 10.17487/RFC4861, September 2007, 6028 . 6030 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 6031 Address Autoconfiguration", RFC 4862, 6032 DOI 10.17487/RFC4862, September 2007, 6033 . 6035 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 6036 Specifications: ABNF", STD 68, RFC 5234, 6037 DOI 10.17487/RFC5234, January 2008, 6038 . 6040 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 6041 (TLS) Protocol Version 1.2", RFC 5246, 6042 DOI 10.17487/RFC5246, August 2008, 6043 . 6045 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 6046 Housley, R., and W. Polk, "Internet X.509 Public Key 6047 Infrastructure Certificate and Certificate Revocation List 6048 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 6049 . 6051 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 6052 DOI 10.17487/RFC5322, October 2008, 6053 . 6055 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 6056 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 6057 January 2012, . 6059 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 6060 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 6061 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 6062 Low-Power and Lossy Networks", RFC 6550, 6063 DOI 10.17487/RFC6550, March 2012, 6064 . 6066 [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing 6067 Protocol for Low-Power and Lossy Networks (RPL)", 6068 RFC 6552, DOI 10.17487/RFC6552, March 2012, 6069 . 6071 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 6072 Power and Lossy Networks (RPL) Option for Carrying RPL 6073 Information in Data-Plane Datagrams", RFC 6553, 6074 DOI 10.17487/RFC6553, March 2012, 6075 . 6077 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 6078 "Enrollment over Secure Transport", RFC 7030, 6079 DOI 10.17487/RFC7030, October 2013, 6080 . 6082 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 6083 Kivinen, "Internet Key Exchange Protocol Version 2 6084 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 6085 2014, . 6087 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 6088 "Recommendations for Secure Use of Transport Layer 6089 Security (TLS) and Datagram Transport Layer Security 6090 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 6091 2015, . 6093 [RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support 6094 for Generic Routing Encapsulation (GRE)", RFC 7676, 6095 DOI 10.17487/RFC7676, October 2015, 6096 . 6098 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 6099 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 6100 May 2017, . 6102 15.2. Informative References 6104 [AR8021] Group, W. -. H. L. L. P. W., "IEEE Standard for Local and 6105 metropolitan area networks - Secure Device Identity", 6106 December 2009, . 6109 [I-D.eckert-anima-noc-autoconfig] 6110 Eckert, T., "Autoconfiguration of NOC services in ACP 6111 networks via GRASP", draft-eckert-anima-noc-autoconfig-00 6112 (work in progress), July 2018. 6114 [I-D.ietf-acme-star] 6115 Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T. 6116 Fossati, "Support for Short-Term, Automatically-Renewed 6117 (STAR) Certificates in Automated Certificate Management 6118 Environment (ACME)", draft-ietf-acme-star-05 (work in 6119 progress), March 2019. 6121 [I-D.ietf-anima-bootstrapping-keyinfra] 6122 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 6123 S., and K. Watsen, "Bootstrapping Remote Secure Key 6124 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 6125 keyinfra-18 (work in progress), January 2019. 6127 [I-D.ietf-anima-prefix-management] 6128 Jiang, S., Du, Z., Carpenter, B., and Q. Sun, "Autonomic 6129 IPv6 Edge Prefix Management in Large-scale Networks", 6130 draft-ietf-anima-prefix-management-07 (work in progress), 6131 December 2017. 6133 [I-D.ietf-anima-reference-model] 6134 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 6135 and J. Nobre, "A Reference Model for Autonomic 6136 Networking", draft-ietf-anima-reference-model-10 (work in 6137 progress), November 2018. 6139 [I-D.ietf-netconf-zerotouch] 6140 Watsen, K., Abrahamsson, M., and I. Farrer, "Secure Zero 6141 Touch Provisioning (SZTP)", draft-ietf-netconf- 6142 zerotouch-29 (work in progress), January 2019. 6144 [I-D.ietf-roll-applicability-template] 6145 Richardson, M., "ROLL Applicability Statement Template", 6146 draft-ietf-roll-applicability-template-09 (work in 6147 progress), May 2016. 6149 [I-D.ietf-roll-useofrplinfo] 6150 Robles, I., Richardson, M., and P. Thubert, "Using RPL 6151 Option Type, Routing Header for Source Routes and IPv6-in- 6152 IPv6 encapsulation in the RPL Data Plane", draft-ietf- 6153 roll-useofrplinfo-24 (work in progress), January 2019. 6155 [I-D.ietf-tls-dtls13] 6156 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 6157 Datagram Transport Layer Security (DTLS) Protocol Version 6158 1.3", draft-ietf-tls-dtls13-30 (work in progress), 6159 November 2018. 6161 [IEEE-1588-2008] 6162 IEEE, "IEEE Standard for a Precision Clock Synchronization 6163 Protocol for Networked Measurement and Control Systems", 6164 December 2008, . 6167 [IEEE-802.1X] 6168 Group, W. -. H. L. L. P. W., "IEEE Standard for Local and 6169 Metropolitan Area Networks: Port-Based Network Access 6170 Control", February 2010, 6171 . 6174 [LLDP] Group, W. -. H. L. L. P. W., "IEEE Standard for Local and 6175 Metropolitan Area Networks: Station and Media Access 6176 Control Connectivity Discovery", June 2016, 6177 . 6180 [MACSEC] Group, W. -. H. L. L. P. W., "IEEE Standard for Local and 6181 Metropolitan Area Networks: Media Access Control (MAC) 6182 Security", June 2006, 6183 . 6186 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 6187 RFC 1112, DOI 10.17487/RFC1112, August 1989, 6188 . 6190 [RFC1492] Finseth, C., "An Access Control Protocol, Sometimes Called 6191 TACACS", RFC 1492, DOI 10.17487/RFC1492, July 1993, 6192 . 6194 [RFC1886] Thomson, S. and C. Huitema, "DNS Extensions to support IP 6195 version 6", RFC 1886, DOI 10.17487/RFC1886, December 1995, 6196 . 6198 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 6199 and E. Lear, "Address Allocation for Private Internets", 6200 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 6201 . 6203 [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax 6204 Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998, 6205 . 6207 [RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", 6208 RFC 2821, DOI 10.17487/RFC2821, April 2001, 6209 . 6211 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 6212 "Remote Authentication Dial In User Service (RADIUS)", 6213 RFC 2865, DOI 10.17487/RFC2865, June 2000, 6214 . 6216 [RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, 6217 DOI 10.17487/RFC3164, August 2001, 6218 . 6220 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 6221 C., and M. Carney, "Dynamic Host Configuration Protocol 6222 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 6223 2003, . 6225 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 6226 Architecture for Describing Simple Network Management 6227 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 6228 DOI 10.17487/RFC3411, December 2002, 6229 . 6231 [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export 6232 Version 9", RFC 3954, DOI 10.17487/RFC3954, October 2004, 6233 . 6235 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 6236 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 6237 DOI 10.17487/RFC4007, March 2005, 6238 . 6240 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 6241 "Internet X.509 Public Key Infrastructure Certificate 6242 Management Protocol (CMP)", RFC 4210, 6243 DOI 10.17487/RFC4210, September 2005, 6244 . 6246 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 6247 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 6248 2006, . 6250 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 6251 for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, 6252 . 6254 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 6255 "Considerations for Internet Group Management Protocol 6256 (IGMP) and Multicast Listener Discovery (MLD) Snooping 6257 Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, 6258 . 6260 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 6261 Group Management Protocol Version 3 (IGMPv3) and Multicast 6262 Listener Discovery Protocol Version 2 (MLDv2) for Source- 6263 Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, 6264 August 2006, . 6266 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 6267 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 6268 . 6270 [RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol 6271 Independent Multicast (PIM)", RFC 4610, 6272 DOI 10.17487/RFC4610, August 2006, 6273 . 6275 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 6276 Extensions for Stateless Address Autoconfiguration in 6277 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 6278 . 6280 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 6281 DOI 10.17487/RFC5321, October 2008, 6282 . 6284 [RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet 6285 Group Management Protocol Version 3 (IGMPv3) and Multicast 6286 Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, 6287 DOI 10.17487/RFC5790, February 2010, 6288 . 6290 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 6291 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 6292 . 6294 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 6295 "Network Time Protocol Version 4: Protocol and Algorithms 6296 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 6297 . 6299 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 6300 and A. Bierman, Ed., "Network Configuration Protocol 6301 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 6302 . 6304 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 6305 Cheshire, "Internet Assigned Numbers Authority (IANA) 6306 Procedures for the Management of the Service Name and 6307 Transport Protocol Port Number Registry", BCP 165, 6308 RFC 6335, DOI 10.17487/RFC6335, August 2011, 6309 . 6311 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 6312 "Default Address Selection for Internet Protocol Version 6 6313 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 6314 . 6316 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 6317 Ed., "Diameter Base Protocol", RFC 6733, 6318 DOI 10.17487/RFC6733, October 2012, 6319 . 6321 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 6322 DOI 10.17487/RFC6762, February 2013, 6323 . 6325 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 6326 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 6327 . 6329 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 6330 Locator/ID Separation Protocol (LISP)", RFC 6830, 6331 DOI 10.17487/RFC6830, January 2013, 6332 . 6334 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 6335 "Specification of the IP Flow Information Export (IPFIX) 6336 Protocol for the Exchange of Flow Information", STD 77, 6337 RFC 7011, DOI 10.17487/RFC7011, September 2013, 6338 . 6340 [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local 6341 Addressing inside an IPv6 Network", RFC 7404, 6342 DOI 10.17487/RFC7404, November 2014, 6343 . 6345 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 6346 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 6347 Defined Networking (SDN): Layers and Architecture 6348 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 6349 2015, . 6351 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 6352 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 6353 Networking: Definitions and Design Goals", RFC 7575, 6354 DOI 10.17487/RFC7575, June 2015, 6355 . 6357 [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap 6358 Analysis for Autonomic Networking", RFC 7576, 6359 DOI 10.17487/RFC7576, June 2015, 6360 . 6362 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 6363 Considerations for IPv6 Address Generation Mechanisms", 6364 RFC 7721, DOI 10.17487/RFC7721, March 2016, 6365 . 6367 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 6368 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 6369 Multicast - Sparse Mode (PIM-SM): Protocol Specification 6370 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 6371 2016, . 6373 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 6374 RFC 7950, DOI 10.17487/RFC7950, August 2016, 6375 . 6377 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 6378 Hosts in a Multi-Prefix Network", RFC 8028, 6379 DOI 10.17487/RFC8028, November 2016, 6380 . 6382 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 6383 Writing an IANA Considerations Section in RFCs", BCP 26, 6384 RFC 8126, DOI 10.17487/RFC8126, June 2017, 6385 . 6387 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 6388 "A Voucher Artifact for Bootstrapping Protocols", 6389 RFC 8366, DOI 10.17487/RFC8366, May 2018, 6390 . 6392 [RFC8368] Eckert, T., Ed. and M. Behringer, "Using an Autonomic 6393 Control Plane for Stable Connectivity of Network 6394 Operations, Administration, and Maintenance (OAM)", 6395 RFC 8368, DOI 10.17487/RFC8368, May 2018, 6396 . 6398 15.3. URIs 6400 [1] https://en.wikipedia.org/wiki/Operational_Technology 6402 [2] https://en.wikipedia.org/wiki/Single-root_input/ 6403 output_virtualization 6405 Appendix A. Background and Futures (Informative) 6407 The following sections discuss additional background information 6408 about aspects of the normative parts of this document or associated 6409 mechanisms such as BRSKI (such as why specific choices were made by 6410 the ACP) and they provide discussion about possible future variations 6411 of the ACP. 6413 A.1. ACP Address Space Schemes 6415 This document defines the Zone, Vlong and Manual sub address schemes 6416 primarily to support address prefix assignment via distributed, 6417 potentially uncoordinated ACP registrars as defined in 6418 Section 6.10.7. This costs 48/46-bit identifier so that these ACP 6419 registrar can assign non-conflicting address prefixes. This design 6420 does not leave enough bits to simultaneously support a large number 6421 of nodes (Node-ID) plus a large prefix of local addresses for every 6422 node plus a large enough set of bits to identify a routing Zone. In 6423 result, Zone, Vlong 8/16 attempt to support all features, but in via 6424 separate prefixes. 6426 In networks that always expect to rely on a centralized PMS as 6427 described above (Section 10.2.5), the 48/46-bits for the Registrar-ID 6428 could be saved. Such variations of the ACP addressing mechanisms 6429 could be introduced through future work in different ways. If the 6430 prefix rfcSELF in the ACP information field was changed, incompatible 6431 ACP variations could be created where every design aspect of the ACP 6432 could be changed. Including all addressing choices. If instead a 6433 new addressing sub-type would be defined, it could be a backward 6434 compatible extension of this ACP specification. Information such as 6435 the size of a zone-prefix and the length of the prefix assigned to 6436 the ACP node itself could be encoded via the extension field of the 6437 ACP domain information. 6439 Note that an explicitly defined "Manual" addressing sub-scheme is 6440 always beneficial to provide an easy way for ACP nodes to prohibit 6441 incorrect manual configuration of any non-"Manual" ACP address spaces 6442 and therefore ensure that "Manual" operations will never impact 6443 correct routing for any non-"Manual" ACP addresses assigned via ACP 6444 domain certificates. 6446 A.2. BRSKI Bootstrap (ANI) 6448 [I-D.ietf-anima-bootstrapping-keyinfra] (BRSKI) describes how nodes 6449 with an IDevID certificate can securely and zero-touch enroll with a 6450 domain certificate (LDevID) to support the ACP. BRSKI also leverages 6451 the ACP to enable zero-touch bootstrap of new nodes across networks 6452 without any configuration requirements across the transit nodes 6453 (e.g., no DHCP/DNS forwarding/server setup). This includes otherwise 6454 not configured networks as described in Section 3.2. Therefore BRSKI 6455 in conjunction with ACP provides for a secure and zero-touch 6456 management solution for complete networks. Nodes supporting such an 6457 infrastructure (BRSKI and ACP) are called ANI nodes (Autonomic 6458 Networking Infrastructure), see [I-D.ietf-anima-reference-model]. 6459 Nodes that do not support an IDevID but only an (insecure) vendor 6460 specific Unique Device Identifier (UDI) or nodes whose manufacturer 6461 does not support a MASA could use some future security reduced 6462 version of BRSKI. 6464 When BRSKI is used to provision a domain certificate (which is called 6465 enrollment), the BRSKI registrar (acting as an enhanced EST server) 6466 must include the subjectAltName / rfc822Name encoded ACP address and 6467 domain name to the enrolling node (called pledge) via its response to 6468 the pledges EST CSR Attribute request that is mandatory in BRSKI. 6470 The Certificate Authority in an ACP network must not change the 6471 subjectAltName / rfc822Name in the certificate. The ACP nodes can 6472 therefore find their ACP address and domain using this field in the 6473 domain certificate, both for themselves, as well as for other nodes. 6475 The use of BRSKI in conjunction with the ACP can also help to further 6476 simplify maintenance and renewal of domain certificates. Instead of 6477 relying on CRL, the lifetime of certificates can be made extremely 6478 small, for example in the order of hours. When a node fails to 6479 connect to the ACP within its certificate lifetime, it cannot connect 6480 to the ACP to renew its certificate across it (using just EST), but 6481 it can still renew its certificate as an "enrolled/expired pledge" 6482 via the BRSKI bootstrap proxy. This requires only that the BRSKI 6483 registrar honors expired domain certificates and that the pledge 6484 attempts to perform TLS authentication for BRSKI bootstrap using its 6485 expired domain certificate before falling back to attempting to use 6486 its IDevID for BRSKI. This mechanism could also render CRLs 6487 unnecessary because the BRSKI registrar in conjunction with the CA 6488 would not renew revoked certificates - only a "Do-not-renew" list 6489 would be necessary on BRSKI registrars/CA. 6491 In the absence of BRSKI or less secure variants thereof, provisioning 6492 of certificates may involve one or more touches or non-standardized 6493 automation. Node vendors usually support provisioning of 6494 certificates into nodes via PKCS#7 (see [RFC2315]) and may support 6495 this provisioning through vendor specific models via Netconf 6496 ([RFC6241]). If such nodes also support Netconf Zero-Touch 6497 ([I-D.ietf-netconf-zerotouch]) then this can be combined to zero- 6498 touch provisioning of domain certificates into nodes. Unless there 6499 are equivalent integration of Netconf connections across the ACP as 6500 there is in BRSKI, this combination would not support zero-touch 6501 bootstrap across a not configured network though. 6503 A.3. ACP Neighbor discovery protocol selection 6505 This section discusses why GRASP DULL was chosen as the discovery 6506 protocol for L2 adjacent candidate ACP neighbors. The contenders 6507 considered where GRASP, mDNS or LLDP. 6509 A.3.1. LLDP 6511 LLDP and Cisco's earlier Cisco Discovery Protocol (CDP) are example 6512 of L2 discovery protocols that terminate their messages on L2 ports. 6513 If those protocols would be chosen for ACP neighbor discovery, ACP 6514 neighbor discovery would therefore also terminate on L2 ports. This 6515 would prevent ACP construction over non-ACP capable but LLDP or CDP 6516 enabled L2 switches. LLDP has extensions using different MAC 6517 addresses and this could have been an option for ACP discovery as 6518 well, but the additional required IEEE standardization and definition 6519 of a profile for such a modified instance of LLDP seemed to be more 6520 work than the benefit of "reusing the existing protocol" LLDP for 6521 this very simple purpose. 6523 A.3.2. mDNS and L2 support 6525 Multicast DNNS (mDNS) [RFC6762] with DNS Service Discovery (DNS-SD) 6526 Resource Records (RRs) as defined in [RFC6763] is a key contender as 6527 an ACP discovery protocol. because it relies on link-local IP 6528 multicast, it does operates at the subnet level, and is also found in 6529 L2 switches. The authors of this document are not aware of mDNS 6530 implementation that terminate their mDNS messages on L2 ports instead 6531 of the subnet level. If mDNS was used as the ACP discovery mechanism 6532 on an ACP capable (L3)/L2 switch as outlined in Section 7, then this 6533 would be necessary to implement. It is likely that termination of 6534 mDNS messages could only be applied to all mDNS messages from such a 6535 port, which would then make it necessary to software forward any non- 6536 ACP related mDNS messages to maintain prior non-ACP mDNS 6537 functionality. Adding support for ACP into such L2 switches with 6538 mDNS could therefore create regression problems for prior mDNS 6539 functionality on those nodes. With low performance of software 6540 forwarding in many L2 switches, this could also make the ACP risky to 6541 support on such L2 switches. 6543 A.3.3. Why DULL GRASP 6545 LLDP was not considered because of the above mentioned issues. mDNS 6546 was not selected because of the above L2 mDNS considerations and 6547 because of the following additional points: 6549 If mDNS was not already existing in a node, it would be more work to 6550 implement than DULL GRASP, and if an existing implementation of mDNS 6551 was used, it would likely be more code space than a separate 6552 implementation of DULL GRASP or a shared implementation of DULL GRASP 6553 and GRASP in the ACP. 6555 A.4. Choice of routing protocol (RPL) 6557 This section motivates why RPL - "IPv6 Routing Protocol for Low-Power 6558 and Lossy Networks ([RFC6550] was chosen as the default (and in this 6559 specification only) routing protocol for the ACP. The choice and 6560 above explained profile was derived from a pre-standard 6561 implementation of ACP that was successfully deployed in operational 6562 networks. 6564 Requirements for routing in the ACP are: 6566 o Self-management: The ACP must build automatically, without human 6567 intervention. Therefore routing protocol must also work 6568 completely automatically. RPL is a simple, self-managing 6569 protocol, which does not require zones or areas; it is also self- 6570 configuring, since configuration is carried as part of the 6571 protocol (see Section 6.7.6 of [RFC6550]). 6573 o Scale: The ACP builds over an entire domain, which could be a 6574 large enterprise or service provider network. The routing 6575 protocol must therefore support domains of 100,000 nodes or more, 6576 ideally without the need for zoning or separation into areas. RPL 6577 has this scale property. This is based on extensive use of 6578 default routing. 6580 o Low resource consumption: The ACP supports traditional network 6581 infrastructure, thus runs in addition to traditional protocols. 6582 The ACP, and specifically the routing protocol must have low 6583 resource consumption both in terms of memory and CPU requirements. 6584 Specifically, at edge nodes, where memory and CPU are scarce, 6585 consumption should be minimal. RPL builds a destination-oriented 6586 directed acyclic graph (DODAG), where the main resource 6587 consumption is at the root of the DODAG. The closer to the edge 6588 of the network, the less state needs to be maintained. This 6589 adapts nicely to the typical network design. Also, all changes 6590 below a common parent node are kept below that parent node. 6592 o Support for unstructured address space: In the Autonomic 6593 Networking Infrastructure, node addresses are identifiers, and may 6594 not be assigned in a topological way. Also, nodes may move 6595 topologically, without changing their address. Therefore, the 6596 routing protocol must support completely unstructured address 6597 space. RPL is specifically made for mobile ad-hoc networks, with 6598 no assumptions on topologically aligned addressing. 6600 o Modularity: To keep the initial implementation small, yet allow 6601 later for more complex methods, it is highly desirable that the 6602 routing protocol has a simple base functionality, but can import 6603 new functional modules if needed. RPL has this property with the 6604 concept of "objective function", which is a plugin to modify 6605 routing behavior. 6607 o Extensibility: Since the Autonomic Networking Infrastructure is a 6608 new concept, it is likely that changes in the way of operation 6609 will happen over time. RPL allows for new objective functions to 6610 be introduced later, which allow changes to the way the routing 6611 protocol creates the DAGs. 6613 o Multi-topology support: It may become necessary in the future to 6614 support more than one DODAG for different purposes, using 6615 different objective functions. RPL allow for the creation of 6616 several parallel DODAGs, should this be required. This could be 6617 used to create different topologies to reach different roots. 6619 o No need for path optimization: RPL does not necessarily compute 6620 the optimal path between any two nodes. However, the ACP does not 6621 require this today, since it carries mainly non-delay-sensitive 6622 feedback loops. It is possible that different optimization 6623 schemes become necessary in the future, but RPL can be expanded 6624 (see point "Extensibility" above). 6626 A.5. ACP Information Distribution and multicast 6628 IP multicast is not used by the ACP because the ANI (Autonomic 6629 Networking Infrastructure) itself does not require IP multicast but 6630 only service announcement/discovery. Using IP multicast for that 6631 would have made it necessary to develop a zero-touch auto configuring 6632 solution for ASM (Any Source Multicast - the original form of IP 6633 multicast defined in [RFC1112]), which would be quite complex and 6634 difficult to justify. One aspect of complexity where no attempt at a 6635 solution has been described in IETF documents is the automatic- 6636 selection of routers that should be PIM Sparse Mode (PIM-SM) 6637 Rendezvous Points (RPs) (see [RFC7761]). The other aspects of 6638 complexity are the implementation of MLD ([RFC4604]), PIM-SM and 6639 Anycast-RP (see [RFC4610]). If those implementations already exist 6640 in a product, then they would be very likely tied to accelerated 6641 forwarding which consumes hardware resources, and that in return is 6642 difficult to justify as a cost of performing only service discovery. 6644 Some future ASA may need high performance in-network data 6645 replication. That is the case when the use of IP multicast is 6646 justified. Such an ASA can then use service discovery from ACP 6647 GRASP, and then they do not need ASM but only SSM (Source Specific 6648 Multicast, see [RFC4607]) for the IP multicast replication. SSM 6649 itself can simply be enabled in the Data-Plane (or even in an update 6650 to the ACP) without any other configuration than just enabling it on 6651 all nodes and only requires a simpler version of MLD (see [RFC5790]). 6653 LSP (Link State Protocol) based IGP routing protocols typically have 6654 a mechanism to flood information, and such a mechanism could be used 6655 to flood GRASP objectives by defining them to be information of that 6656 IGP. This would be a possible optimization in future variations of 6657 the ACP that do use an LSP routing protocol. Note though that such a 6658 mechanism would not work easily for GRASP M_DISCOVERY messages which 6659 are intelligently (constrained) flooded not across the whole ACP, but 6660 only up to a node where a responder is found. We do expect that many 6661 future services in ASA will have only few consuming ASA, and for 6662 those cases, M_DISCOVERY is the more efficient method than flooding 6663 across the whole domain. 6665 Because the ACP uses RPL, one desirable future extension is to use 6666 RPLs existing notion of loop-free distribution trees (DODAG) to make 6667 GRASPs flooding more efficient both for M_FLOOD and M_DISCOVERY) See 6668 Section 6.12.5 how this will be specifically beneficial when using 6669 NBMA interfaces. This is not currently specified in this document 6670 because it is not quite clear yet what exactly the implications are 6671 to make GRASP flooding depend on RPL DODAG convergence and how 6672 difficult it would be to let GRASP flooding access the DODAG 6673 information. 6675 A.6. Extending ACP channel negotiation (via GRASP) 6677 The mechanism described in the normative part of this document to 6678 support multiple different ACP secure channel protocols without a 6679 single network wide MTI protocol is important to allow extending 6680 secure ACP channel protocols beyond what is specified in this 6681 document, but it will run into problem if it would be used for 6682 multiple protocols: 6684 The need to potentially have multiple of these security associations 6685 even temporarily run in parallel to determine which of them works 6686 best does not support the most lightweight implementation options. 6688 The simple policy of letting one side (Alice) decide what is best may 6689 not lead to the mutual best result. 6691 The two limitations can easier be solved if the solution was more 6692 modular and as few as possible initial secure channel negotiation 6693 protocols would be used, and these protocols would then take on the 6694 responsibility to support more flexible objectives to negotiate the 6695 mutually preferred ACP security channel protocol. 6697 IKEv2 is the IETF standard protocol to negotiate network security 6698 associations. It is meant to be extensible, but it is unclear 6699 whether it would be feasible to extend IKEv2 to support possible 6700 future requirements for ACP secure channel negotiation: 6702 Consider the simple case where the use of native IPsec vs. IPsec via 6703 GRE is to be negotiated and the objective is the maximum throughput. 6704 Both sides would indicate some agreed upon performance metric and the 6705 preferred encapsulation is the one with the higher performance of the 6706 slower side. IKEv2 does not support negotiation with this objective. 6708 Consider DTLS and some form of MacSec are to be added as negotiation 6709 options - and the performance objective should work across all IPsec, 6710 DTLS and MacSec options. In the case of MacSEC, the negotiation 6711 would also need to determine a key for the peering. It is unclear if 6712 it would be even appropriate to consider extending the scope of 6713 negotiation in IKEv2 to those cases. Even if feasible to define, it 6714 is unclear if implementations of IKEv2 would be eager to adopt those 6715 type of extension given the long cycles of security testing that 6716 necessarily goes along with core security protocols such as IKEv2 6717 implementations. 6719 A more modular alternative to extending IKEv2 could be to layer a 6720 modular negotiation mechanism on top of the multitude of existing or 6721 possible future secure channel protocols. For this, GRASP over TLS 6722 could be considered as a first ACP secure channel negotiation 6723 protocol. The following are initial considerations for such an 6724 approach. A full specification is subject to a separate document: 6726 To explicitly allow negotiation of the ACP channel protocol, GRASP 6727 over a TLS connection using the GRASP_LISTEN_PORT and the nodes and 6728 peers link-local IPv6 address is used. When Alice and Bob support 6729 GRASP negotiation, they do prefer it over any other non-explicitly 6730 negotiated security association protocol and should wait trying any 6731 non-negotiated ACP channel protocol until after it is clear that 6732 GRASP/TLS will not work to the peer. 6734 When Alice and Bob successfully establish the GRASP/TSL session, they 6735 will negotiate the channel mechanism to use using objectives such as 6736 performance and perceived quality of the security. After agreeing on 6737 a channel mechanism, Alice and Bob start the selected Channel 6738 protocol. Once the secure channel protocol is successfully running, 6739 the GRASP/TLS connection can be kept alive or timed out as long as 6740 the selected channel protocol has a secure association between Alice 6741 and Bob. When it terminates, it needs to be re-negotiated via GRASP/ 6742 TLS. 6744 Notes: 6746 o Negotiation of a channel type may require IANA assignments of code 6747 points. 6749 o TLS is subject to reset attacks, which IKEv2 is not. Normally, 6750 ACP connections (as specified in this document) will be over link- 6751 local addresses so the attack surface for this one issue in TCP 6752 should be reduced (note that this may not be true when ACP is 6753 tunneled as described in Section 8.2.2. 6755 o GRASP packets received inside a TLS connection established for 6756 GRASP/TLS ACP negotiation are assigned to a separate GRASP domain 6757 unique to that TLS connection. 6759 A.7. CAs, domains and routing subdomains 6761 There is a wide range of setting up different ACP solution by 6762 appropriately using CAs and the domain and rsub elements in the 6763 domain information field of the domain certificate. We summarize 6764 these options here as they have been explained in different parts of 6765 the document in before and discuss possible and desirable extensions: 6767 An ACP domain is the set of all ACP nodes using certificates from the 6768 same CA using the same domain field. GRASP inside the ACP is run 6769 across all transitively connected ACP nodes in a domain. 6771 The rsub element in the domain information field permits the use of 6772 addresses from different ULA prefixes. One use case is to create 6773 multiple physical networks that initially may be separated with one 6774 ACP domain but different routing subdomains, so that all nodes can 6775 mutual trust their ACP domain certificates (not depending on rsub) 6776 and so that they could connect later together into a contiguous ACP 6777 network. 6779 One instance of such a use case is an ACP for regions interconnected 6780 via a non-ACP enabled core, for example due to the absence of product 6781 support for ACP on the core nodes. ACP connect configurations as 6782 defined in this document can be used to extend and interconnect those 6783 ACP islands to the NOC and merge them into a single ACP when later 6784 that product support gap is closed. 6786 Note that RPL scales very well. It is not necessary to use multiple 6787 routing subdomains to scale ACP domains in a way it would be possible 6788 if other routing protocols where used. They exist only as options 6789 for the above mentioned reasons. 6791 If different ACP domains are to be created that should not allow to 6792 connect to each other by default, these ACP domains simply need to 6793 have different domain elements in the domain information field. 6794 These domain elements can be arbitrary, including subdomains of one 6795 another: Domains "example.com" and "research.example.com" are 6796 separate domains if both are domain elements in the domain 6797 information element of certificates. 6799 It is not necessary to have a separate CA for different ACP domains: 6800 an operator can use a single CA to sign certificates for multiple ACP 6801 domains that are not allowed to connect to each other because the 6802 checks for ACP adjacencies includes comparison of the domain part. 6804 If multiple independent networks choose the same domain name but had 6805 their own CA, these would not form a single ACP domain because of CA 6806 mismatch. Therefore there is no problem in choosing domain names 6807 that are potentially also used by others. Nevertheless it is highly 6808 recommended to use domain names that one can have high probability to 6809 be unique. It is recommended to use domain names that start with a 6810 DNS domain names owned by the assigning organization and unique 6811 within it. For example "acp.example.com" if you own "example.com". 6813 A.8. Intent for the ACP 6815 Intent is the architecture component of autonomic networks according 6816 to [I-D.ietf-anima-reference-model] that allows operators to issue 6817 policies to the network. In a simple instance, Intent could simply 6818 be policies flooded across ACP GRASP and interpreted on every ACP 6819 node. 6821 One concern for future definitions of Intent solutions is the problem 6822 of circular dependencies when expressing Intent policies about the 6823 ACP itself. 6825 For example, Intent could indicate the desire to build an ACP across 6826 all domains that have a common parent domain (without relying on the 6827 rsub/routing-subdomain solution defined in this document). For 6828 example ACP nodes with domain "example.com", "access.example.com", 6829 "core.example.com" and "city.core.example.com" should all establish 6830 one single ACP. 6832 If each domain has its own source of Intent, then the Intent would 6833 simply have to allow adding the peer domains trust anchors (CA) and 6834 domain names to the ACP domain membership check (Section 6.1.2) so 6835 that nodes from those other domains are accepted as ACP peers. 6837 If this Intent was to be originated only from one domain, it could 6838 likely not be made to work because the other domains will not build 6839 any ACP connection amongst each other, whether they use the same or 6840 different CA due to the ACP domain membership check. 6842 If the domains use the same CA one could change the ACP setup to 6843 permit for the ACP to be established between two ACP nodes with 6844 different acp-domain-names, but only for the purpose of disseminating 6845 limited information, such as Intent, but not to set up full ACP 6846 connectivity, specifically not RPL routing and passing of arbitrary 6847 GRASP information. Unless the Intent policies permit this to happen 6848 across domain boundaries. 6850 This type of approach where the ACP first allows Intent to operate 6851 and only then sets up the rest of ACP connectivity based on Intent 6852 policy could also be used to enable Intent policies that would limit 6853 functionality across the ACP inside a domain, as long as no policy 6854 would disturb the distribution of Intent. For example to limit 6855 reachability across the ACP to certain type of nodes or locations of 6856 nodes. 6858 A.9. Adopting ACP concepts for other environments 6860 The ACP as specified in this document is very explicit about the 6861 choice of options to allow interoperable implementations. The 6862 choices made may not be the best for all environments, but the 6863 concepts used by the ACP can be used to build derived solutions: 6865 The ACP specifies the use of ULA and deriving its prefix from the 6866 domain name so that no address allocation is required to deploy the 6867 ACP. The ACP will equally work not using ULA but any other /48 IPv6 6868 prefix. This prefix could simply be a configuration of the ACP 6869 registrars (for example when using BRSKI) to enroll the domain 6870 certificates - instead of the ACP registrar deriving the /48 ULA 6871 prefix from the AN domain name. 6873 Some solutions may already have an auto-addressing scheme, for 6874 example derived from existing unique device identifiers (e.g., MAC 6875 addresses). In those cases it may not be desirable to assign 6876 addresses to devices via the ACP address information field in the way 6877 described in this document. The certificate may simply serve to 6878 identify the ACP domain, and the address field could be empty/unused. 6879 The only fix required in the remaining way the ACP operate is to 6880 define another element in the domain certificate for the two peers to 6881 decide who is Alice and who is Bob during secure channel building. 6882 Note though that future work may leverage the acp address to 6883 authenticate "ownership" of the address by the device. If the 6884 address used by a device is derived from some pre-existing permanent 6885 local ID (such as MAC address), then it would be useful to store that 6886 address in the certificate using the format of the access address 6887 information field or in a similar way. 6889 The ACP is defined as a separate VRF because it intends to support 6890 well managed networks with a wide variety of configurations. 6891 Therefore, reliable, configuration-indestructible connectivity cannot 6892 be achieved from the Data-Plane itself. In solutions where all 6893 transit connectivity impacting functions are fully automated 6894 (including security), indestructible and resilient, it would be 6895 possible to eliminate the need for the ACP to be a separate VRF. 6896 Consider the most simple example system in which there is no separate 6897 Data-Plane, but the ACP is the Data-Plane. Add BRSKI, and it becomes 6898 a fully autonomic network - except that it does not support automatic 6899 addressing for user equipment. This gap can then be closed for 6900 example by adding a solution derived from 6901 [I-D.ietf-anima-prefix-management]. 6903 TCP/TLS as the protocols to provide reliability and security to GRASP 6904 in the ACP may not be the preferred choice in constrained networks. 6905 For example, CoAP/DTLS (Constrained Application Protocol) may be 6906 preferred where they are already used, allowing to reduce the 6907 additional code space footprint for the ACP on those devices. Hop- 6908 by-hop reliability for ACP GRASP messages could be made to support 6909 protocols like DTLS by adding the same type of negotiation as defined 6910 in this document for ACP secure channel protocol negotiation. End- 6911 to-end GRASP connections can be made to select their transport 6912 protocol in future extensions of the ACP meant to better support 6913 constrained devices by indicating the supported transport protocols 6914 (e.g.: TLS/DTLS) via GRASP parameters of the GRASP objective through 6915 which the transport endpoint is discovered. 6917 The routing protocol chosen by the ACP design (RPL) does explicitly 6918 not optimize for shortest paths and fastest convergence. Variations 6919 of the ACP may want to use a different routing protocol or introduce 6920 more advanced RPL profiles. 6922 Variations such as what routing protocol to use, or whether to 6923 instantiate an ACP in a VRF or (as suggested above) as the actual 6924 Data-Plane, can be automatically chosen in implementations built to 6925 support multiple options by deriving them from future parameters in 6926 the certificate. Parameters in certificates should be limited to 6927 those that would not need to be changed more often than certificates 6928 would need to be updated anyhow; Or by ensuring that these parameters 6929 can be provisioned before the variation of an ACP is activated in a 6930 node. Using BRSKI, this could be done for example as additional 6931 follow-up signaling directly after the certificate enrollment, still 6932 leveraging the BRSKI TLS connection and therefore not introducing any 6933 additional connectivity requirements. 6935 Last but not least, secure channel protocols including their 6936 encapsulations are easily added to ACP solutions. ACP hop-by-hop 6937 network layer secure channels could also be replaced by end-to-end 6938 security plus other means for infrastructure protection. Any future 6939 network OAM should always use end-to-end security anyhow and can 6940 leverage the domain certificates and is therefore not dependent on 6941 security to be provided for by ACP secure channels. 6943 A.10. Further options / futures 6945 A.10.1. Auto-aggregation of routes 6947 Routing in the ACP according to this specification only leverages the 6948 standard RPL mechanism of route optimization, e.g. keeping only 6949 routes that are not towards the RPL root. This is known to scale to 6950 networks with 20,000 or more nodes. There is no auto-aggregation of 6951 routes for /48 ULA prefixes (when using rsub in the domain 6952 information field) and/or Zone-ID based prefixes. 6954 Automatic assignment of Zone-ID and auto-aggregation of routes could 6955 be achieved for example by configuring zone-boundaries, announcing 6956 via GRASP into the zones the zone parameters (zone-ID and /48 ULA 6957 prefix) and auto-aggegating routes on the zone-boundaries. Nodes 6958 would assign their Zone-ID and potentially even /48 prefix based on 6959 the GRASP announcements. 6961 A.10.2. More options for avoiding IPv6 Data-Plane dependency 6963 As described in Section 6.12.2, the ACP depends on the Data-Plane to 6964 establish IPv6 link-local addressing on interfaces. Using a separate 6965 MAC address for the ACP allows to fully isolate the ACP from the 6966 data-plane in a way that is compatible with this specification. It 6967 is also an ideal option when using Single-root input/output 6968 virtualization (SR-IOV - see https://en.wikipedia.org/wiki/Single- 6969 root_input/output_virtualization [2]) in an implementation to isolate 6970 the ACP because different SR-IOV interfaces use different MAC 6971 addresses. 6973 When additional MAC address(es) are not available, separation of the 6974 ACP could be done at different demux points. The same subnet 6975 interface could have a separate IPv6 interface for the ACP and Data- 6976 Plane and therefore separate link-local addresses for both, where the 6977 ACP interface is non-configurable on the Data-Plane. This too would 6978 be compatible with this specification and not impact 6979 interoperability. 6981 An option that would require additional specification is to use a 6982 different Ethertype from 0x86DD (IPv6) to encapsulate IPv6 packets 6983 for the ACP. This would be a similar approach as used for IP 6984 authentication packets in [IEEE-802.1X] which use the Extensible 6985 Authentication Protocol over Local Area Network (EAPoL) ethertype 6986 (0x88A2). 6988 Note that in the case of ANI nodes, all the above considerations 6989 equally apply to the encapsulation of BRSKI packets including GRASP 6990 used for BRSKI. 6992 A.10.3. ACP APIs and operational models (YANG) 6994 Future work should define YANG ([RFC7950]) data model and/or node 6995 internal APIs to monitor and manage the ACP. 6997 Support for the ACP Adjacency Table (Section 6.2) and ACP GRASP need 6998 to be included into such model/API. 7000 A.10.4. RPL enhancements 7001 ..... USA ...... ..... Europe ...... 7003 NOC1 NOC2 7004 | | 7005 | metric 100 | 7006 ACP1 --------------------------- ACP2 . 7007 | | . WAN 7008 | metric 10 metric 20 | . Core 7009 | | . 7010 ACP3 --------------------------- ACP4 . 7011 | metric 100 | 7012 | | . 7013 | | . Sites 7014 ACP10 ACP11 . 7016 Figure 17: Dual NOC 7018 The profile for RPL specified in this document builds only one 7019 spanning-tree path set to a root (NOC). In the presence of multiple 7020 NOCs, routing toward the non-root NOCs may be suboptimal. Figure 17 7021 shows an extreme example. Assuming that node ACP1 becomes the RPL 7022 root, traffic between ACP11 and NOC2 will pass through 7023 ACP4-ACP3-ACP1-ACP2 instead of ACP4-ACP2 because the RPL calculated 7024 DODAG/routes are shortest paths towards the RPL root. 7026 To overcome these limitations, extensions/modifications to the RPL 7027 profile can provide optimality for multiple NOCs. This requires 7028 utilizing Data-Plane artifact including IPinIP encap/decap on ACP 7029 routers and processing of IPv6 RPI headers. Alternatively, (Src,Dst) 7030 routing table entries could be used. 7032 Flooding of ACP GRASP messages can be further constrained and 7033 therefore optimized by flooding only via links that are part of the 7034 RPL DODAG. 7036 A.10.5. Role assignments 7038 ACP connect is an explicit mechanism to "leak" ACP traffic explicitly 7039 (for example in a NOC). It is therefore also a possible security gap 7040 when it is easy to enable ACP connect on arbitrary compromised ACP 7041 nodes. 7043 One simple solution is to define an extension in the ACP certificates 7044 ACP information field indicating the permission for ACP connect to be 7045 configured on that ACP node. This could similarly be done to decide 7046 whether a node is permitted to be a registrar or not. 7048 Tying the permitted "roles" of an ACP node to the ACP domain 7049 certificate provides fairly strong protection against 7050 misconfiguration, but is still subject to code modifications. 7052 Another interesting role to assign to certificates is that of a NOC 7053 node. This would allow to limit certain type of connections such as 7054 OAM TLS connections to only NOC initiator or responders. 7056 A.10.6. Autonomic L3 transit 7058 In this specification, the ACP can only establish autonomic 7059 connectivity across L2 hops and only explicitly configured options to 7060 tunnel across L3. Future work should specify mechanisms to 7061 automatically tunnel ACP across L3 networks. A hub&spoke option 7062 would allow to tunnel across the Internet to a cloud or central 7063 instance of the ACP, a peer-to-peer tunneling mechanism could tunnel 7064 ACP islands across an L3VPN infrastructure. 7066 A.10.7. Diagnostics 7068 Section 10.1 describes diagnostics options that can be done without 7069 changing the external, interoperability affecting characteristics of 7070 ACP implementations. 7072 Even better diagnostics of ACP operations is possible with additional 7073 signaling extensions, such as: 7075 1. Consider if LLDP should be a recommended functionality for ANI 7076 devices to improve diagnostics, and if so, which information 7077 elements it should signal (insecure). Includes potentially new 7078 information elements. 7080 2. In alternative to LLDP, A DULL GRASP diagnostics objective could 7081 be defined to carry these information elements. 7083 3. The IDevID of BRSKI pledges should be included in the selected 7084 insecure diagnostics option. 7086 4. A richer set of diagnostics information should be made available 7087 via the secured ACP channels, using either single-hop GRASP or 7088 network wide "topology discovery" mechanisms. 7090 A.10.8. Avoiding and dealing with compromised ACP nodes 7092 Compromised ACP nodes pose the biggest risk to the operations of the 7093 network. The most common type of compromise is leakage of 7094 credentials to manage/configure the device and the application of 7095 malicious configuration including the change of access credentials, 7096 but not the change of software. Most of todays networking equipment 7097 should have secure boot/software infrastructure anyhow, so attacks 7098 that introduce malicious software should be a lot harder. 7100 The most important aspect of security design against these type of 7101 attacks is to eliminate password based configuration access methods 7102 and instead rely on certificate based credentials handed out only to 7103 nodes where it is clear that the private keys can not leak. This 7104 limits unexpected propagation of credentials. 7106 If password based credentials to configure devices still need to be 7107 supported, they must not be locally configurable, but only be 7108 remotely provisioned or verified (through protocols like Radius or 7109 Diameter), and there must be no local configuration permitting to 7110 change these authentication mechanisms, but ideally they should be 7111 autoconfiguring across the ACP. See 7112 [I-D.eckert-anima-noc-autoconfig]. 7114 Without physcial access to the compromised device, attackers with 7115 access to configuration should not be able to break the ACP 7116 connectivity, even when they can break or otherwise manipulate 7117 (spoof) the data-plane connectivity through configuration. To 7118 achieve this, it is necessary to avoid providing configuration 7119 options for the ACP, such as enabling/disabling it on interfaces. 7120 For example there could be an ACP configuration that locks down the 7121 current ACP config unless factory reseet is done. 7123 With such means, the valid administration has the best chances to 7124 maintain access to ACP nodes, discover malicious configuration though 7125 ongoing configuration tracking from central locations for example, 7126 and to react accordingly. 7128 The primary reaction is withdrawal/change of credentials, terminate 7129 malicious existing management sessions and fixing the configuration. 7130 Ensuring that manaement sessions using invalidated credentials are 7131 terminated automatically without recourse will likely require new 7132 work. 7134 Only when these steps are not feasible would it be necessary to 7135 revoke or expire the ACP domain certificate credentials and consider 7136 the node kicked off the network - until the situation can be further 7137 rectified, likely requiring direct physical access to the node. 7139 Without extensions, compromised ACP nodes can only be removed from 7140 the ACP at the speed of CRL/OCSP information refresh or expiry (and 7141 non-removal) of short lived certificates. Future extensions to the 7142 ACP could for example use GRASP flooding distribution of triggered 7143 updates of CRL/OCSP or explicit removal indication of the compromised 7144 nodes domain certificate. 7146 Authors' Addresses 7148 Toerless Eckert (editor) 7149 Huawei USA - Futurewei Technologies Inc. 7150 2330 Central Expy 7151 Santa Clara 95050 7152 USA 7154 Email: tte+ietf@cs.fau.de 7156 Michael H. Behringer (editor) 7158 Email: michael.h.behringer@gmail.com 7160 Steinthor Bjarnason 7161 Arbor Networks 7162 2727 South State Street, Suite 200 7163 Ann Arbor MI 48104 7164 United States 7166 Email: sbjarnason@arbor.net