idnits 2.17.1 draft-ietf-anima-autonomic-control-plane-24.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 12 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 1139 has weird spacing: '...address of f...' == Line 2557 has weird spacing: '...k-local unic...' == Line 2558 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). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 4: If the node certificate indicates a Certificate Revocation List (CRL) Distribution Point (CDP) ([RFC5280], section 4.2.1.13) or Online Certificate Status Protocol (OCSP) responder ([RFC5280], section 4.2.2.1), then the peer's certificate MUST be valid according to those criteria: An OCSP check for the peer's certificate across the ACP MUST succeed or the peer certificate MUST not be listed in the CRL retrieved from the CDP. This rule has to be skipped for ACP secure channel peer authentication when the node has no ACP or non-ACP connectivity to retrieve current CRL or access an OCSP responder (and the security association protocol itself has also no way to communicate CRL or OCSP check). -- The document date (March 9, 2020) is 1502 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 434, but not defined -- Looks like a reference, but probably isn't: '1' on line 6275 -- Looks like a reference, but probably isn't: '2' on line 6851 -- Looks like a reference, but probably isn't: '3' on line 2020 -- Looks like a reference, but probably isn't: '5' on line 2026 -- Looks like a reference, but probably isn't: '9' on line 2037 -- Looks like a reference, but probably isn't: '13' on line 2053 == Missing Reference: 'ACP VRF' is mentioned on line 3883, but not defined == Missing Reference: 'Data-Plane' is mentioned on line 3885, but not defined == Missing Reference: 'Select' is mentioned on line 4045, but not defined == Missing Reference: 'Plane' is mentioned on line 4047, but not defined == Unused Reference: 'RFC1034' is defined on line 5811, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-applicability-template' is defined on line 5978, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IKEV2IANA' ** 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 (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-35 == Outdated reference: A later version (-44) exists of draft-ietf-roll-useofrplinfo-36 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-34 -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- 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 4492 (Obsoleted by RFC 8422) -- 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 (~~), 17 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANIMA WG T. Eckert, Ed. 3 Internet-Draft Futurewei USA 4 Intended status: Standards Track M. Behringer, Ed. 5 Expires: September 10, 2020 6 S. Bjarnason 7 Arbor Networks 8 March 9, 2020 10 An Autonomic Control Plane (ACP) 11 draft-ietf-anima-autonomic-control-plane-24 13 Abstract 15 Autonomic functions need a control plane to communicate, which 16 depends on some addressing and routing. This Autonomic Control Plane 17 should ideally be self-managing, and as independent as possible of 18 configuration. This document defines such a plane and calls it the 19 "Autonomic Control Plane", with the primary use as a control plane 20 for autonomic functions. It also serves as a "virtual out-of-band 21 channel" for Operations, Administration and Management (OAM) 22 communications over a network that provides automatically configured 23 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 10, 2020. 44 Copyright Notice 46 Copyright (c) 2020 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) . . . 16 65 3.1. An Infrastructure for Autonomic Functions . . . . . . . . 16 66 3.2. Secure Bootstrap over a not configured Network . . . . . 16 67 3.3. Data-Plane Independent Permanent Reachability . . . . . . 17 68 4. Requirements (Informative) . . . . . . . . . . . . . . . . . 18 69 5. Overview (Informative) . . . . . . . . . . . . . . . . . . . 19 70 6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 21 71 6.1. ACP Domain, Certificate and Network . . . . . . . . . . . 21 72 6.1.1. ACP Certificates . . . . . . . . . . . . . . . . . . 22 73 6.1.2. ACP Certificate ACP Domain Information Field . . . . 24 74 6.1.3. ACP domain membership check . . . . . . . . . . . . . 28 75 6.1.3.1. Realtime clock and Time Validation . . . . . . . 30 76 6.1.4. Trust Points and Trust Anchors . . . . . . . . . . . 30 77 6.1.5. Certificate and Trust Point Maintenance . . . . . . . 31 78 6.1.5.1. GRASP objective for EST server . . . . . . . . . 32 79 6.1.5.2. Renewal . . . . . . . . . . . . . . . . . . . . . 34 80 6.1.5.3. Certificate Revocation Lists (CRLs) . . . . . . . 34 81 6.1.5.4. Lifetimes . . . . . . . . . . . . . . . . . . . . 35 82 6.1.5.5. Re-enrollment . . . . . . . . . . . . . . . . . . 35 83 6.1.5.6. Failing Certificates . . . . . . . . . . . . . . 36 84 6.2. ACP Adjacency Table . . . . . . . . . . . . . . . . . . . 37 85 6.3. Neighbor Discovery with DULL GRASP . . . . . . . . . . . 38 86 6.4. Candidate ACP Neighbor Selection . . . . . . . . . . . . 41 87 6.5. Channel Selection . . . . . . . . . . . . . . . . . . . . 41 88 6.6. Candidate ACP Neighbor verification . . . . . . . . . . . 45 89 6.7. Security Association (Secure Channel) protocols . . . . . 45 90 6.7.1. General considerations . . . . . . . . . . . . . . . 45 91 6.7.2. Common requirements . . . . . . . . . . . . . . . . . 46 92 6.7.3. ACP via IPsec . . . . . . . . . . . . . . . . . . . . 47 93 6.7.3.1. Native IPsec . . . . . . . . . . . . . . . . . . 48 94 6.7.3.1.1. RFC8221 (IPsec/ESP) . . . . . . . . . . . . . 48 95 6.7.3.1.2. RFC847 (IKEv2) . . . . . . . . . . . . . . . 49 96 6.7.3.2. IPsec with GRE encapsulation . . . . . . . . . . 50 98 6.7.4. ACP via DTLS . . . . . . . . . . . . . . . . . . . . 51 99 6.7.5. ACP Secure Channel Profiles . . . . . . . . . . . . . 53 100 6.8. GRASP in the ACP . . . . . . . . . . . . . . . . . . . . 53 101 6.8.1. GRASP as a core service of the ACP . . . . . . . . . 53 102 6.8.2. ACP as the Security and Transport substrate for GRASP 54 103 6.8.2.1. Discussion . . . . . . . . . . . . . . . . . . . 57 104 6.9. Context Separation . . . . . . . . . . . . . . . . . . . 58 105 6.10. Addressing inside the ACP . . . . . . . . . . . . . . . . 58 106 6.10.1. Fundamental Concepts of Autonomic Addressing . . . . 58 107 6.10.2. The ACP Addressing Base Scheme . . . . . . . . . . . 60 108 6.10.3. ACP Zone Addressing Sub-Scheme . . . . . . . . . . . 61 109 6.10.3.1. Usage of the Zone-ID Field . . . . . . . . . . . 63 110 6.10.4. ACP Manual Addressing Sub-Scheme . . . . . . . . . . 64 111 6.10.5. ACP Vlong Addressing Sub-Scheme . . . . . . . . . . 65 112 6.10.6. Other ACP Addressing Sub-Schemes . . . . . . . . . . 66 113 6.10.7. ACP Registrars . . . . . . . . . . . . . . . . . . . 67 114 6.10.7.1. Use of BRSKI or other Mechanism/Protocols . . . 67 115 6.10.7.2. Unique Address/Prefix allocation . . . . . . . . 68 116 6.10.7.3. Addressing Sub-Scheme Policies . . . . . . . . . 68 117 6.10.7.4. Address/Prefix Persistence . . . . . . . . . . . 69 118 6.10.7.5. Further Details . . . . . . . . . . . . . . . . 70 119 6.11. Routing in the ACP . . . . . . . . . . . . . . . . . . . 70 120 6.11.1. RPL Profile . . . . . . . . . . . . . . . . . . . . 70 121 6.11.1.1. Overview . . . . . . . . . . . . . . . . . . . . 71 122 6.11.1.2. RPL Instances . . . . . . . . . . . . . . . . . 72 123 6.11.1.3. Storing vs. Non-Storing Mode . . . . . . . . . . 72 124 6.11.1.4. DAO Policy . . . . . . . . . . . . . . . . . . . 72 125 6.11.1.5. Path Metric . . . . . . . . . . . . . . . . . . 73 126 6.11.1.6. Objective Function . . . . . . . . . . . . . . . 73 127 6.11.1.7. DODAG Repair . . . . . . . . . . . . . . . . . . 73 128 6.11.1.8. Multicast . . . . . . . . . . . . . . . . . . . 73 129 6.11.1.9. Security . . . . . . . . . . . . . . . . . . . . 73 130 6.11.1.10. P2P communications . . . . . . . . . . . . . . . 74 131 6.11.1.11. IPv6 address configuration . . . . . . . . . . . 74 132 6.11.1.12. Administrative parameters . . . . . . . . . . . 74 133 6.11.1.13. RPL Data-Plane artifacts . . . . . . . . . . . . 74 134 6.11.1.14. Unknown Destinations . . . . . . . . . . . . . . 75 135 6.12. General ACP Considerations . . . . . . . . . . . . . . . 75 136 6.12.1. Performance . . . . . . . . . . . . . . . . . . . . 75 137 6.12.2. Addressing of Secure Channels . . . . . . . . . . . 75 138 6.12.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . 76 139 6.12.4. Multiple links between nodes . . . . . . . . . . . . 76 140 6.12.5. ACP interfaces . . . . . . . . . . . . . . . . . . . 77 141 6.12.5.1. ACP loopback interfaces . . . . . . . . . . . . 77 142 6.12.5.2. ACP virtual interfaces . . . . . . . . . . . . . 77 143 6.12.5.2.1. ACP point-to-point virtual interfaces . . . 78 144 6.12.5.2.2. ACP multi-access virtual interfaces . . . . 78 145 7. ACP support on L2 switches/ports (Normative) . . . . . . . . 80 146 7.1. Why (Benefits of ACP on L2 switches) . . . . . . . . . . 80 147 7.2. How (per L2 port DULL GRASP) . . . . . . . . . . . . . . 81 148 8. Support for Non-ACP Components (Normative) . . . . . . . . . 83 149 8.1. ACP Connect . . . . . . . . . . . . . . . . . . . . . . . 83 150 8.1.1. Non-ACP Controller / NMS system . . . . . . . . . . . 83 151 8.1.2. Software Components . . . . . . . . . . . . . . . . . 85 152 8.1.3. Auto Configuration . . . . . . . . . . . . . . . . . 86 153 8.1.4. Combined ACP/Data-Plane Interface (VRF Select) . . . 87 154 8.1.5. Use of GRASP . . . . . . . . . . . . . . . . . . . . 89 155 8.2. Connecting ACP islands over Non-ACP L3 networks (Remote 156 ACP neighbors) . . . . . . . . . . . . . . . . . . . . . 89 157 8.2.1. Configured Remote ACP neighbor . . . . . . . . . . . 90 158 8.2.2. Tunneled Remote ACP Neighbor . . . . . . . . . . . . 91 159 8.2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 91 160 9. ACP Operations (Informative) . . . . . . . . . . . . . . . . 91 161 9.1. ACP (and BRSKI) Diagnostics . . . . . . . . . . . . . . . 92 162 9.2. ACP Registrars . . . . . . . . . . . . . . . . . . . . . 96 163 9.2.1. Registrar interactions . . . . . . . . . . . . . . . 97 164 9.2.2. Registrar Parameter . . . . . . . . . . . . . . . . . 98 165 9.2.3. Certificate renewal and limitations . . . . . . . . . 98 166 9.2.4. ACP Registrars with sub-CA . . . . . . . . . . . . . 99 167 9.2.5. Centralized Policy Control . . . . . . . . . . . . . 100 168 9.3. Enabling and disabling ACP/ANI . . . . . . . . . . . . . 100 169 9.3.1. Filtering for non-ACP/ANI packets . . . . . . . . . . 101 170 9.3.2. Admin Down State . . . . . . . . . . . . . . . . . . 101 171 9.3.2.1. Security . . . . . . . . . . . . . . . . . . . . 102 172 9.3.2.2. Fast state propagation and Diagnostics . . . . . 103 173 9.3.2.3. Low Level Link Diagnostics . . . . . . . . . . . 103 174 9.3.2.4. Power Consumption Issues . . . . . . . . . . . . 104 175 9.3.3. Interface level ACP/ANI enable . . . . . . . . . . . 104 176 9.3.4. Which interfaces to auto-enable? . . . . . . . . . . 104 177 9.3.5. Node Level ACP/ANI enable . . . . . . . . . . . . . . 106 178 9.3.5.1. Brownfield nodes . . . . . . . . . . . . . . . . 106 179 9.3.5.2. Greenfield nodes . . . . . . . . . . . . . . . . 107 180 9.3.6. Undoing ANI/ACP enable . . . . . . . . . . . . . . . 107 181 9.3.7. Summary . . . . . . . . . . . . . . . . . . . . . . . 108 182 9.4. Configuration and the ACP (summary) . . . . . . . . . . . 108 183 10. Summary: Benefits (Informative) . . . . . . . . . . . . . . . 109 184 10.1. Self-Healing Properties . . . . . . . . . . . . . . . . 110 185 10.2. Self-Protection Properties . . . . . . . . . . . . . . . 111 186 10.2.1. From the outside . . . . . . . . . . . . . . . . . . 111 187 10.2.2. From the inside . . . . . . . . . . . . . . . . . . 112 188 10.3. The Administrator View . . . . . . . . . . . . . . . . . 113 189 11. Security Considerations . . . . . . . . . . . . . . . . . . . 113 190 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 116 191 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 117 192 14. Change log [RFC Editor: Please remove] . . . . . . . . . . . 117 193 14.1. Summary of changes since entering IESG review . . . . . 117 194 14.1.1. Reviews (while in IESG review status) / status . . . 117 195 14.1.2. BRSKI / ACP registrar related enhancements . . . . . 118 196 14.1.3. Normative enhancements since start of IESG review . 118 197 14.1.4. Explanatory enhancements since start of IESG review 119 198 14.2. draft-ietf-anima-autonomic-control-plane-24 . . . . . . 120 199 14.3. draft-ietf-anima-autonomic-control-plane-23 . . . . . . 120 200 14.4. draft-ietf-anima-autonomic-control-plane-22 . . . . . . 122 201 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 124 202 15.1. Normative References . . . . . . . . . . . . . . . . . . 124 203 15.2. Informative References . . . . . . . . . . . . . . . . . 127 204 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 134 205 Appendix A. Background and Futures (Informative) . . . . . . . . 134 206 A.1. ACP Address Space Schemes . . . . . . . . . . . . . . . . 134 207 A.2. BRSKI Bootstrap (ANI) . . . . . . . . . . . . . . . . . . 135 208 A.3. ACP Neighbor discovery protocol selection . . . . . . . . 136 209 A.3.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 136 210 A.3.2. mDNS and L2 support . . . . . . . . . . . . . . . . . 137 211 A.3.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 137 212 A.4. Choice of routing protocol (RPL) . . . . . . . . . . . . 137 213 A.5. ACP Information Distribution and multicast . . . . . . . 139 214 A.6. Extending ACP channel negotiation (via GRASP) . . . . . . 140 215 A.7. CAs, domains and routing subdomains . . . . . . . . . . . 142 216 A.8. Intent for the ACP . . . . . . . . . . . . . . . . . . . 143 217 A.9. Adopting ACP concepts for other environments . . . . . . 144 218 A.10. Further (future) options . . . . . . . . . . . . . . . . 146 219 A.10.1. Auto-aggregation of routes . . . . . . . . . . . . . 146 220 A.10.2. More options for avoiding IPv6 Data-Plane dependency 146 221 A.10.3. ACP APIs and operational models (YANG) . . . . . . . 147 222 A.10.4. RPL enhancements . . . . . . . . . . . . . . . . . . 147 223 A.10.5. Role assignments . . . . . . . . . . . . . . . . . . 148 224 A.10.6. Autonomic L3 transit . . . . . . . . . . . . . . . . 148 225 A.10.7. Diagnostics . . . . . . . . . . . . . . . . . . . . 148 226 A.10.8. Avoiding and dealing with compromised ACP nodes . . 149 227 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 150 229 1. Introduction (Informative) 231 Autonomic Networking is a concept of self-management: Autonomic 232 functions self-configure, and negotiate parameters and settings 233 across the network. [RFC7575] defines the fundamental ideas and 234 design goals of Autonomic Networking. A gap analysis of Autonomic 235 Networking is given in [RFC7576]. The reference architecture for 236 Autonomic Networking in the IETF is specified in the document 237 [I-D.ietf-anima-reference-model]. 239 Autonomic functions need an autonomically built communications 240 infrastructure. This infrastructure needs to be secure, resilient 241 and re-usable by all autonomic functions. Section 5 of [RFC7575] 242 introduces that infrastructure and calls it the Autonomic Control 243 Plane (ACP). More descriptively it would be the "Autonomic 244 communications infrastructure for OAM and Control". For naming 245 consistency with that prior document, this document continues to use 246 the name ACP though. 248 Today, the OAM and control plane of networks typically uses a routing 249 and forwarding table which is dependent on correct configuration and 250 routing. Misconfigurations or routing problems can disrupt OAM and 251 control channels. Traditionally, an out-of-band network has been 252 used to avoid or allow recovery from such problems, or personnel are 253 sent on site to access devices through out-of-band management ports 254 (also called craft ports, serial console, management ethernet port). 255 However, both options are expensive. 257 In increasingly automated networks either centralized management 258 systems or distributed autonomic service agents in the network 259 require a control plane which is independent of the configuration of 260 the network they manage, to avoid impacting their own operations 261 through the configuration actions they take. 263 This document describes a modular design for a self-forming, self- 264 managing and self-protecting ACP, which is a virtual in-band network 265 designed to be as independent as possible of configuration, 266 addressing and routing problems. The details how this is achieved 267 are described in Section 6. The ACP is designed to remain 268 operational even in the presence of configuration errors, addressing 269 or routing issues, or where policy could inadvertently affect 270 connectivity of both data packets or control packets. 272 This document uses the term "Data-Plane" to refer to anything in the 273 network nodes that is not the ACP, and therefore considered to be 274 dependent on (mis-)configuration. This Data-Plane includes both the 275 traditional forwarding-plane, as well as any pre-existing control- 276 plane, such as routing protocols that establish routing tables for 277 the forwarding plane. 279 The Autonomic Control Plane serves several purposes at the same time: 281 1. Autonomic functions communicate over the ACP. The ACP therefore 282 directly supports Autonomic Networking functions, as described in 283 [I-D.ietf-anima-reference-model]. For example, Generic Autonomic 284 Signaling Protocol (GRASP - [I-D.ietf-anima-grasp]) runs securely 285 inside the ACP and depends on the ACP as its "security and 286 transport substrate". 288 2. A controller or network management system can use it to securely 289 bootstrap network devices in remote locations, even if the (Data- 290 Plane) network in between is not yet configured; no Data-Plane 291 dependent bootstrap configuration is required. An example of 292 such a secure bootstrap process is described in 293 [I-D.ietf-anima-bootstrapping-keyinfra]. 295 3. An operator can use it to access remote devices using protocols 296 such as Secure SHell (SSH) or Network Configuration Protocol 297 (NETCONF) running across the ACP, even if the network is 298 misconfigured or not configured. 300 This document describes these purposes as use cases for the ACP in 301 Section 3, it defines the requirements in Section 4. Section 5 gives 302 an overview how the ACP is constructed. 304 The normative part of this document starts with Section 6, where the 305 ACP is specified. Section 7 defines normative how to support ACP on 306 L2 switches. Section 8 explains normative how non-ACP nodes and 307 networks can be integrated. 309 The remaining sections are non-normative: Section 10 reviews benefits 310 of the ACP (after all the details have been defined), Section 9 311 provides operational recommendations, Appendix A provides additional 312 explanations and describes additional details or future standard or 313 propriety extensions that were considered not to be appropriate for 314 standardization in this document but were considered important to 315 document. There are no dependencies against Appendix A to build a 316 complete working and interoperable ACP according to this document. 318 The ACP provides secure IPv6 connectivity, therefore it can be used 319 not only as the secure connectivity for self-management as required 320 for the ACP in [RFC7575], but it can also be used as the secure 321 connectivity for traditional (centralized) management. The ACP can 322 be implemented and operated without any other components of autonomic 323 networks, except for the GRASP protocol. ACP relies on per-link DULL 324 GRASP (see Section 6.3) to autodiscover ACP neighbors, and includes 325 the ACP GRASP instance to provide service discovery for clients of 326 the ACP (see Section 6.8) including for its own maintenance of ACP 327 certificates. 329 The document "Using Autonomic Control Plane for Stable Connectivity 330 of Network OAM" [RFC8368] describes how the ACP alone can be used to 331 provide secure and stable connectivity for autonomic and non- 332 autonomic OAM applications. That document also explains how existing 333 management solutions can leverage the ACP in parallel with 334 traditional management models, when to use the ACP and how to 335 integrate with potentially IPv4 only OAM backends. 337 Combining ACP with Bootstrapping Remote Secure Key Infrastructures 338 (BRSKI), see [I-D.ietf-anima-bootstrapping-keyinfra]) results in the 339 "Autonomic Network Infrastructure" (ANI) as defined in 340 [I-D.ietf-anima-reference-model], which provides autonomic 341 connectivity (from ACP) with secure zero-touch (automated) bootstrap 342 from BRSKI. The ANI itself does not constitute an Autonomic Network, 343 but it allows the building of more or less autonomic networks on top 344 of it - using either centralized, Software Defined Networking- 345 (SDN-)style (see [RFC7426]) automation or distributed automation via 346 Autonomic Service Agents (ASA) / Autonomic Functions (AF) - or a 347 mixture of both. See [I-D.ietf-anima-reference-model] for more 348 information. 350 1.1. Applicability and Scope 352 Please see the following Terminology section (Section 2) for 353 explanations of terms used in this section. 355 The design of the ACP as defined in this document is considered to be 356 applicable to all types of "professionally managed" networks: Service 357 Provider, Local Area Network (LAN), Metro(politan networks), Wide 358 Area Network (WAN), Enterprise Information Technology (IT) and 359 ->"Operational Technology" () (OT) networks. The ACP can operate 360 equally on layer 3 equipment and on layer 2 equipment such as bridges 361 (see Section 7). The hop-by-hop authentication, integrity-protection 362 and confidentiality mechanism used by the ACP is defined to be 363 negotiable, therefore it can be extended to environments with 364 different protocol preferences. The minimum implementation 365 requirements in this document attempt to achieve maximum 366 interoperability by requiring support for multiple options depending 367 on the type of device: IPsec, see [RFC4301], and datagram Transport 368 Layer Security (DTLS) version 1.2, see [RFC6347]). 370 The implementation footprint of the ACP consists of Public Key 371 Infrastructure (PKI) code for the ACP certificate, the GRASP 372 protocol, UDP, TCP and TLS (for security and reliability of GRASP), 373 the ACP secure channel protocol used (such as IPsec or DTLS), and an 374 instance of IPv6 packet forwarding and routing via the Routing 375 Protocol for Low-power and Lossy Networks (RPL), see [RFC6550], that 376 is separate from routing and forwarding for the Data-Plane (user 377 traffic). 379 The ACP uses only IPv6 to avoid complexity of dual-stack ACP 380 operations (IPv6/IPv4). Nevertheless, it can without any changes be 381 integrated into even otherwise IPv4-only network devices. The Data- 382 Plane itself would not need to change, it could continue to be IPv4 383 only. For such IPv4 only devices, the IPv6 protocol itself would be 384 additional implementation footprint only used for the ACP. 386 The protocol choices of the ACP are primarily based on wide use and 387 support in networks and devices, well understood security properties 388 and required scalability. The ACP design is an attempt to produce 389 the lowest risk combination of existing technologies and protocols to 390 build a widely applicable operational network management solution: 392 RPL was chosen because it requires a smaller routing table footprint 393 in large networks compared to other routing protocols with an 394 autonomically configured single area. The deployment experience of 395 large scale Internet of Things (IoT) networks serves as the basis for 396 wide deployment experience with RPL. The profile chosen for RPL in 397 the ACP does not leverage any RPL specific forwarding plane features 398 (IPv6 extension headers), making its implementation a pure control 399 plane software requirement. 401 GRASP is the only completely novel protocol used in the ACP, and this 402 choice was necessary because there is no existing suitable protocol 403 to provide the necessary functions to the ACP, so GRASP was developed 404 to fill that gap. 406 The ACP design can be applicable to (cpu, memory) constrained devices 407 and (bitrate, reliability) constrained networks, but this document 408 does not attempt to define the most constrained type of devices or 409 networks to which the ACP is applicable. RPL and DTLS for ACP secure 410 channels are two protocol choices already making ACP more applicable 411 to constrained environments. Support for constrained devices in this 412 specification is opportunistic, but not complete, because the 413 reliable transport for GRASP (see Section 6.8.2) only specifies TCP/ 414 TLS). See Appendix A.9 for discussions about how future standards or 415 proprietary extensions/variations of the ACP could better meet 416 different expectations from those on which the current design is 417 based including supporting constrained devices better. 419 2. Acronyms and Terminology (Informative) 421 [RFC Editor: WG/IETF/IESG review of the terms below asked for 422 references between these terms when they refer to each other. The 423 only option I could fin RFC/XML to point to a hanging text acronym 424 definition that also displays the actual term is the format="title" 425 version, which leads to references such as '->"ACP domain 426 certificate" ()'. I found no reasonable way to eliminate the 427 trailing '()' generated by this type of cross references. Can you 428 please take care of removing these artefacts during editing (after 429 conversion to nroff ?). I also created a ticket to ask for an 430 xml2rfc enhancement to avoid this in the future: 431 https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/347. 433 [RFC Editor: Question: Is it possible to change the first occurrences 434 of [RFCxxxx] references to "rfcxxx title" [RFCxxxx]? the XML2RFC 435 format does not seem to offer such a format, but I did not want to 436 duplicate 50 first references - one reference for title mentioning 437 and one for RFC number.] 439 This document serves both as a normative specification for how ACP 440 nodes have to behave as well as describing requirements, benefits, 441 architecture and operational aspects to explain the context. 442 Normative sections are labelled "(Normative)" and use 443 [RFC2119]/[RFC8174] keywords. Other sections are labelled 444 "(Informative)" and do not use those normative keywords. 446 In the rest of the document we will refer to systems using the ACP as 447 "nodes". Typically such a node is a physical (network equipment) 448 device, but it can equally be some virtualized system. Therefore, we 449 do not refer to them as devices unless the context specifically calls 450 for a physical system. 452 This document introduces or uses the following terms (sorted 453 alphabetically). Terms introduced are explained on first use, so 454 this list is for reference only. 456 ACP: "Autonomic Control Plane". The Autonomic Function as defined 457 in this document. It provides secure zero-touch (automated) 458 transitive (network wide) IPv6 connectivity for all nodes in the 459 same ACP domain as well as a GRASP instance running across this 460 ACP IPv6 connectivity. The ACP is primarily meant to be used as a 461 component of the ANI to enable Autonomic Networks but it can 462 equally be used in simple ANI networks (with no other Autonomic 463 Functions) or completely by itself. 465 ACP address: An IPv6 address assigned to the ACP node. It is stored 466 in the domain information field of the ->"ACP domain certificate" 467 (). 469 ACP address range/set: The ACP address may imply a range or set of 470 addresses that the node can assign for different purposes. This 471 address range/set is derived by the node from the format of the 472 ACP address called the "addressing sub-scheme". 474 ACP connect interface: An interface on an ACP node providing access 475 to the ACP for non ACP capable nodes without using an ACP secure 476 channel. See Section 8.1.1. 478 ACP domain: The ACP domain is the set of nodes with ->"ACP domain 479 certificates" that allow them to authenticate each other as 480 members of the ACP domain. See also Section 6.1.3. 482 ACP (ANI/AN) Domain Certificate: A [RFC5280] certificate (LDevID) 483 carrying the domain information field which is used by the ACP to 484 learn its address in the ACP and to derive and cryptographically 485 assert its membership in the ACP domain. 487 domain information (field): An rfc822Name information element (e.g., 488 field) in the domain certificate in which the ACP relevant 489 information is encoded: the domain name and the ACP address. 491 ACP Loopback interface: The Loopback interface in the ACP Virtual 492 Routing and Forwarding (VRF) that has the ACP address assigned to 493 it. 495 ACP network: The ACP network constitutes all the nodes that have 496 access to the ACP. It is the set of active and transitively 497 connected nodes of an ACP domain plus all nodes that get access to 498 the ACP of that domain via ACP edge nodes. 500 ACP (ULA) prefix(es): The /48 IPv6 address prefixes used across the 501 ACP. In the normal/simple case, the ACP has one ULA prefix, see 502 Section 6.10. The ACP routing table may include multiple ULA 503 prefixes if the "rsub" option is used to create addresses from 504 more than one ULA prefix. See Section 6.1.2. The ACP may also 505 include non-ULA prefixes if those are configured on ACP connect 506 interfaces. See Section 8.1.1. 508 ACP secure channel: A channel authenticated via ->"ACP domain 509 certificates" () providing integrity protection and 510 confidentiality through encryption. These are established between 511 (normally) adjacent ACP nodes to carry traffic of the ACP VRF 512 securely and isolated from Data-Plane traffic in-band over the 513 same link/path as the Data-Plane. 515 ACP secure channel protocol: The protocol used to build an ACP 516 secure channel, e.g., Internet Key Exchange Protocol version 2 517 (IKEv2) with IPsec or Datagram Transport Layer Security (DTLS). 519 ACP virtual interface: An interface in the ACP VRF mapped to one or 520 more ACP secure channels. See Section 6.12.5. 522 AN "Autonomic Network": A network according to 523 [I-D.ietf-anima-reference-model]. Its main components are ANI, 524 Autonomic Functions and Intent. 526 (AN) Domain Name: An FQDN (Fully Qualified Domain Name) in the 527 domain information field of the Domain Certificate. See 528 Section 6.1.2. 530 ANI (nodes/network): "Autonomic Network Infrastructure". The ANI is 531 the infrastructure to enable Autonomic Networks. It includes ACP, 532 BRSKI and GRASP. Every Autonomic Network includes the ANI, but 533 not every ANI network needs to include autonomic functions beyond 534 the ANI (nor Intent). An ANI network without further autonomic 535 functions can for example support secure zero-touch (automated) 536 bootstrap and stable connectivity for SDN networks - see 537 [RFC8368]. 539 ANIMA: "Autonomic Networking Integrated Model and Approach". ACP, 540 BRSKI and GRASP are specifications of the IETF ANIMA working 541 group. 543 ASA: "Autonomic Service Agent". Autonomic software modules running 544 on an ANI device. The components making up the ANI (BRSKI, ACP, 545 GRASP) are also described as ASAs. 547 Autonomic Function: A function/service in an Autonomic Network (AN) 548 composed of one or more ASA across one or more ANI nodes. 550 BRSKI: "Bootstrapping Remote Secure Key Infrastructures" 551 ([I-D.ietf-anima-bootstrapping-keyinfra]. A protocol extending 552 EST to enable secure zero-touch bootstrap in conjunction with ACP. 553 ANI nodes use ACP, BRSKI and GRASP. 555 CA: "Certificate Authority". An entity that issues digital 556 certificates. A CA uses its own cerrtificate to sign the 557 certificates it issues. This signing certificate can be 558 considered to be an identifier of the CA, so the term CA is also 559 loosely used to refer to the certificate used by the CA for 560 signing. 562 CRL: "Certificate Revocation List". A list of revoked certificates. 563 Required to revoke certificates before their lifetime expires. 565 Data-Plane: The counterpoint to the ACP VRF in an ACP node: all 566 routing and forwarding in the node other than the ACP VRF. In a 567 simple ACP or ANI node, the Data-Plane is typically provisioned by 568 means other than autonomically, for example manually (including 569 across the ACP) or via SDN controllers. In a fully Autonomic 570 Network node, the Data-Plane is managed autonomically via 571 Autonomic Functions and Intent. Note that other (non-ANIMA) RFCs 572 use the Data-Plane to refer to what is better called the 573 forwarding plane. This is not the way the term is used in this 574 document! 576 device: A physical system, or physical node. 578 Enrollment: The process where a node presents identification (for 579 example through keying material such as the private key of an 580 IDevID) to a network and acquires a network specific identity such 581 as an LDevID and trust anchors such as Certificate Authority (CA) 582 certificates. 584 EST: "Enrollment over Secure Transport" ([RFC7030]). IETF standard- 585 track protocol for enrollment of a node with an LDevID. BRSKI is 586 based on EST. 588 GRASP: "Generic Autonomic Signaling Protocol". An extensible 589 signaling protocol required by the ACP for ACP neighbor discovery. 591 The ACP also provides the "security and transport substrate" for 592 the "ACP instance of GRASP". This instance of GRASP runs across 593 the ACP secure channels to support BRSKI and other NOC/OAM or 594 Autonomic Functions. See [I-D.ietf-anima-grasp]. 596 IDevID: An "Initial Device IDentity" X.509 certificate installed by 597 the vendor on new equipment. Contains information that 598 establishes the identity of the node in the context of its vendor/ 599 manufacturer such as device model/type and serial number. See 600 [AR8021]. IDevID cannot be used as a node identifier for the ACP 601 because they are not provisioned by the owner of the network, so 602 they can not directly indicate an ACP domain they belong to. 604 in-band (management): The type of management used predominantly in 605 IP based networks, not leveraging an ->"out-of-band network" (). 606 In in-band management, access to the managed equipment depends on 607 the configuration of this equipment itself: interface, addressing, 608 forwarding, routing, policy, security, management. This 609 dependency makes in-band management fragile because the 610 configuration actions performed may break in-band management 611 connectivity. Breakage can not only be unintentional, it can 612 simply be an unavoidable side effect of being unable to create 613 configuration schemes where in-band management connectivity 614 configuration is unaffected by Data-Plane configuration. See also 615 ->"(virtual) out-of-band network" (). 617 Intent: Policy language of an autonomic network according to 618 [I-D.ietf-anima-reference-model]. 620 Loopback interface: The conventional name for an internal IP 621 interface to which addresses may be assigned, but which transmits 622 no external traffic. 624 LDevID: A "Local Device IDentity" is an X.509 certificate installed 625 during "enrollment". The Domain Certificate used by the ACP is an 626 LDevID. See [AR8021]. 628 Management: Used in this document as another word for ->"OAM" (). 630 MASA (service): "Manufacturer Authorized Signing Authority". A 631 vendor/manufacturer or delegated cloud service on the Internet 632 used as part of the BRSKI protocol. 634 MIC: "Manufacturer Installed Certificate". This is another word to 635 describe an IDevID in referenced materials. This term is not used 636 in this document. 638 native interface: Interfaces existing on a node without 639 configuration of the already running node. On physical nodes 640 these are usually physical interfaces. On virtual nodes their 641 equivalent. 643 NOC: Network Operations Center. 645 node: A system supporting the ACP according to this document. Can 646 be virtual or physical. Physical nodes are called devices. 648 Node-ID: The identifier of an ACP node inside that ACP. It is the 649 last 64 (see Section 6.10.3) or 78-bits (see Section 6.10.5) of 650 the ACP address. 652 OAM: Operations, Administration and Management. Includes Network 653 Monitoring. 655 Operational Technology (OT): "https://en.wikipedia.org/wiki/ 656 Operational_Technology" [1]: "The hardware and software dedicated 657 to detecting or causing changes in physical processes through 658 direct monitoring and/or control of physical devices such as 659 valves, pumps, etc.". OT networks are today in most cases well 660 separated from Information Technology (IT) networks. 662 (virtual) out-of-band network: An out-of-band network is a secondary 663 network used to manage a primary network. The equipment of the 664 primary network is connected to the out-of-band network via 665 dedicated management ports on the primary network equipment. 666 Serial (console) management ports were historically most common, 667 higher end network equipment now also has ethernet ports dedicated 668 only for management. An out-of-band network provides management 669 access to the primary network independent of the configuration 670 state of the primary network. One of the goals of the ACP is to 671 provide this benefit of out-of-band networks virtually on the 672 primary network equipment. The ACP VRF acts as a virtual out of 673 band network device providing configuration independent management 674 access. The ACP secure channels are the virtual links of the ACP 675 virtual out-of-band network, meant to be operating independent of 676 the configuration of the primary network. See also ->"in-band 677 (management)" (). 679 root CA: "root certificate authority". A trusted ->"CA" (). The 680 certificate used by the CA to sign issued certificates is expected 681 to be a ->"TA" (), which makes it the root of a certificate chain. 682 The term root CA is also loosely used to refer to the root CA's 683 signing certificate. Root CA certificates are self-signed. 685 RPL: "IPv6 Routing Protocol for Low-Power and Lossy Networks". The 686 routing protocol used in the ACP. See [RFC6550]. 688 (ACP/ANI/BRSKI) Registrar: An ACP registrar is an entity (software 689 and/or person) that is orchestrating the enrollment of ACP nodes 690 with the ACP domain certificate. ANI nodes use BRSKI, so ANI 691 registrars are also called BRSKI registrars. For non-ANI ACP 692 nodes, the registrar mechanisms are undefined by this document. 693 See Section 6.10.7. Renewal and other maintenance (such as 694 revocation) of ACP domain certificates may be performed by other 695 entities than registrars. EST must be supported for ACP domain 696 certificate renewal (see Section 6.1.5). BRSKI is an extension of 697 EST, so ANI/BRSKI registrars can easily support ACP domain 698 certificate renewal in addition to initial enrollment. 700 sUDI: "secured Unique Device Identifier". This is another word to 701 describe an IDevID in referenced material. This term is not used 702 in this document. 704 TA "Trust Anchor(s)". A list of one or more certificates that are 705 trusted signers of other certificates. Authenticating a 706 certificate consists of verifying the chain of signing 707 certificates until a TA is encountered. In the most simple case, 708 the TA is a single certificate of the single root CAThe most 709 simple form of a TA is a root certificate. 711 UDI: "Unique Device Identifier". In the context of this document 712 unsecured identity information of a node typically consisting of 713 at least device model/type and serial number, often in a vendor 714 specific format. See sUDI and LDevID. 716 ULA: (Global ID prefix) A "Unique Local Address" (ULA) is an IPv6 717 address in the block fc00::/7, defined in [RFC4193]. It is the 718 approximate IPv6 counterpart of the IPv4 private address 719 ([RFC1918]). The ULA Global ID prefix are the first 48-bits of a 720 ULA address. In this document it is abbreviated as "ULA prefix". 722 (ACP) VRF: The ACP is modeled in this document as a "Virtual Routing 723 and Forwarding" instance (VRF). This means that it is based on a 724 "virtual router" consisting of a separate IPv6 forwarding table to 725 which the ACP virtual interfaces are attached and an associated 726 IPv6 routing table separate from the Data-Plane. Unlike the VRFs 727 on MPLS/VPN-PE ([RFC4364]) or LISP XTR ([RFC6830]), the ACP VRF 728 does not have any special "core facing" functionality or routing/ 729 mapping protocols shared across multiple VRFs. In vendor products 730 a VRF such as the ACP-VRF may also be referred to as a so called 731 VRF-lite. 733 (ACP) Zone: An ACP zone is a set of ACP nodes using the same zone 734 field value in their ACP address according to Section 6.10.3. 735 Zones are a mechanism to support structured addressing of ACP 736 addresses within the same /48-bit ULA prefix. 738 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 739 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 740 "OPTIONAL" in this document are to be interpreted as described in BCP 741 14 [RFC2119],[RFC8174] when, and only when, they appear in all 742 capitals, as shown here. 744 3. Use Cases for an Autonomic Control Plane (Informative) 746 This section summarizes the use cases that are intended to be 747 supported by an ACP. To understand how these are derived from and 748 relate to the larger set of use cases for autonomic networks, please 749 refer to [RFC8316]. 751 3.1. An Infrastructure for Autonomic Functions 753 Autonomic Functions need a stable infrastructure to run on, and all 754 autonomic functions should use the same infrastructure to minimize 755 the complexity of the network. In this way, there is only need for a 756 single discovery mechanism, a single security mechanism, and single 757 instances of other processes that distributed functions require. 759 3.2. Secure Bootstrap over a not configured Network 761 Today, bootstrapping a new node typically requires all nodes between 762 a controlling node such as an SDN controller ("Software Defined 763 Networking", see [RFC7426]) and the new node to be completely and 764 correctly addressed, configured and secured. Bootstrapping and 765 configuration of a network happens in rings around the controller - 766 configuring each ring of devices before the next one can be 767 bootstrapped. Without console access (for example through an out-of- 768 band network) it is not possible today to make devices securely 769 reachable before having configured the entire network leading up to 770 them. 772 With the ACP, secure bootstrap of new devices and whole new networks 773 can happen without requiring any configuration of unconfigured 774 devices along the path: As long as all devices along the path support 775 ACP and a zero-touch bootstrap mechanism such as BRSKI, the ACP 776 across a whole network of unconfigured devices can be brought up 777 without operator/provisioning intervention. The ACP also provides 778 additional security for any bootstrap mechanism, because it can 779 provide encrypted discovery (via ACP GRASP) of registrars or other 780 bootstrap servers by bootstrap proxies connecting to nodes that are 781 to be bootstrapped and the ACP encryption hides the identities of the 782 communicating entities (pledge and registrar), making it more 783 difficult to learn which network node might be attackable. The ACP 784 domain certificate can also be used to end-to-end encrypt the 785 bootstrap communication between such proxies and server. Note that 786 bootstrapping here includes not only the first step that can be 787 provided by BRSKI (secure keys), but also later stages where 788 configuration is bootstrapped. 790 3.3. Data-Plane Independent Permanent Reachability 792 Today, most critical control plane protocols and OAM protocols are 793 using the Data-Plane of the network. This leads to often undesirable 794 dependencies between control and OAM plane on one side and the Data- 795 Plane on the other: Only if the forwarding and control plane of the 796 Data-Plane are configured correctly, will the Data-Plane and the OAM/ 797 control plane work as expected. 799 Data-Plane connectivity can be affected by errors and faults, for 800 example misconfigurations that make AAA (Authentication, 801 Authorization and Accounting) servers unreachable or can lock an 802 administrator out of a device; routing or addressing issues can make 803 a device unreachable; shutting down interfaces over which a current 804 management session is running can lock an admin irreversibly out of 805 the device. Traditionally only out-of-band access can help recover 806 from such issues (such as serial console or ethernet management 807 port). 809 Data-Plane dependencies also affect applications in a Network 810 Operations Center (NOC) such as SDN controller applications: Certain 811 network changes are today hard to implement, because the change 812 itself may affect reachability of the devices. Examples are address 813 or mask changes, routing changes, or security policies. Today such 814 changes require precise hop-by-hop planning. 816 Note that specific control plane functions for the Data-Plane often 817 want to depend on forwarding of their packets via the Data-Plane: 818 Aliveness and routing protocol signaling packets across the Data- 819 Plane to verify reachability across the Data-Plane, using IPv4 820 signaling packets for IPv4 routing vs. IPv6 signaling packets for 821 IPv6 routing. 823 Assuming appropriate implementation (see Section 6.12.2 for more 824 details), the ACP provides reachability that is independent of the 825 Data-Plane. This allows the control plane and OAM plane to operate 826 more robustly: 828 o For management plane protocols, the ACP provides the functionality 829 of a Virtual out-of-band (VooB) channel, by providing connectivity 830 to all nodes regardless of their Data-Plane configuration, routing 831 and forwarding tables. 833 o For control plane protocols, the ACP allows their operation even 834 when the Data-Plane is temporarily faulty, or during transitional 835 events, such as routing changes, which may affect the control 836 plane at least temporarily. This is specifically important for 837 autonomic service agents, which could affect Data-Plane 838 connectivity. 840 The document "Using Autonomic Control Plane for Stable Connectivity 841 of Network OAM" [RFC8368] explains this use case for the ACP in 842 significantly more detail and explains how the ACP can be used in 843 practical network operations. 845 4. Requirements (Informative) 847 The following requirements were identified for the design of the ACP 848 based on the above use-cases (Section 3). These requirements are 849 informative. The ACP as specified in the normative parts of this 850 document is meeting or exceeding these use-case requirements: 852 ACP1: The ACP should provide robust connectivity: As far as 853 possible, it should be independent of configured addressing, 854 configuration and routing. Requirements 2 and 3 build on this 855 requirement, but also have value on their own. 857 ACP2: The ACP must have a separate address space from the Data- 858 Plane. Reason: traceability, debug-ability, separation from 859 Data-Plane, infrastructure security (filtering based on known 860 address space). 862 ACP3: The ACP must use autonomically managed address space. Reason: 863 easy bootstrap and setup ("autonomic"); robustness (admin 864 cannot break network easily). This document uses Unique Local 865 Addresses (ULA) for this purpose, see [RFC4193]. 867 ACP4: The ACP must be generic, that is it must be usable by all the 868 functions and protocols of the ANI. Clients of the ACP must 869 not be tied to a particular application or transport protocol. 871 ACP5: The ACP must provide security: Messages coming through the ACP 872 must be authenticated to be from a trusted node, and should 873 (very strong should) be encrypted. 875 Explanation for ACP4: In a fully autonomic network (AN), newly 876 written ASA could potentially all communicate exclusively via GRASP 877 with each other, and if that was assumed to be the only requirement 878 against the ACP, it would not need to provide IPv6 layer connectivity 879 between nodes, but only GRASP connectivity. Nevertheless, because 880 ACP also intends to support non-AN networks, it is crucial to support 881 IPv6 layer connectivity across the ACP to support any transport and 882 application layer protocols. 884 The ACP operates hop-by-hop, because this interaction can be built on 885 IPv6 link local addressing, which is autonomic, and has no dependency 886 on configuration (requirement 1). It may be necessary to have ACP 887 connectivity across non-ACP nodes, for example to link ACP nodes over 888 the general Internet. This is possible, but introduces a dependency 889 against stable/resilient routing over the non-ACP hops (see 890 Section 8.2). 892 5. Overview (Informative) 894 The Autonomic Control Plane is constructed in the following way (for 895 details, see Section 6): 897 1. An ACP node creates a Virtual Routing and Forwarding (VRF) 898 instance, or a similar virtual context. 900 2. It determines, following a policy, a candidate peer list. This 901 is the list of nodes to which it should establish an Autonomic 902 Control Plane. Default policy is: To all link-layer adjacent 903 nodes supporting ACP. 905 3. For each node in the candidate peer list, it authenticates that 906 node (according to Section 6.1.3) and negotiates a mutually 907 acceptable channel type. 909 4. For each node in the candidate peer list, it then establishes a 910 secure tunnel of the negotiated channel type. The resulting 911 tunnels are then placed into the previously set up VRF. This 912 creates an overlay network with hop-by-hop tunnels. 914 5. Inside the ACP VRF, each node assigns its ULA IPv6 address to a 915 Loopback interface assigned to the ACP VRF. 917 6. Each node runs a lightweight routing protocol, to announce 918 reachability of the virtual addresses inside the ACP (see 919 Section 6.12.5). 921 Note: 923 o Non-ACP NMS ("Network Management Systems") or SDN controllers have 924 to be explicitly configured for connection into the ACP. 926 o Connecting over non-ACP Layer-3 clouds requires explicit 927 configuration. See Section 8.2. 929 o None of the above operations (except explicit configured ones) are 930 reflected in the configuration of the node. 932 The following figure illustrates the ACP. 934 ACP node 1 ACP node 2 935 ................... ................... 936 secure . . secure . . secure 937 channel: +-----------+ : channel : +-----------+ : channel 938 ..--------| ACP VRF |---------------------| ACP VRF |---------.. 939 : / \ / \ <--routing--> / \ / \ : 940 : \ / \ / \ / \ / : 941 ..--------| Loopback |---------------------| Loopback |---------.. 942 : | interface | : : | interface | : 943 : +-----------+ : : +-----------+ : 944 : : : : 945 : Data-Plane :...............: Data-Plane : 946 : : link : : 947 :.................: :.................: 949 Figure 1: ACP VRF and secure channels 951 The resulting overlay network is normally based exclusively on hop- 952 by-hop tunnels. This is because addressing used on links is IPv6 953 link local addressing, which does not require any prior set-up. In 954 this way the ACP can be built even if there is no configuration on 955 the node, or if the Data-Plane has issues such as addressing or 956 routing problems. 958 6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 960 This section describes the components and steps to set up an ACP and 961 highlights the key properties which make it "indestructible" against 962 many inadvertent changes to the Data-Plane, for example caused by 963 misconfigurations. 965 An ACP node can be a router, switch, controller, NMS host, or any 966 other IP capable node. Initially, it MUST have its ACP domain 967 certificate, as well as an (empty) ACP Adjacency Table (described in 968 Section 6.2). It then can start to discover ACP neighbors and build 969 the ACP. This is described step by step in the following sections: 971 6.1. ACP Domain, Certificate and Network 973 The ACP relies on group security. An ACP domain is a group of nodes 974 that trust each other to participate in ACP operations such as 975 creating ACP secure channels in an autonomous peer-to-peer fashion 976 between ACP domain members via protocols such as IPsec. To establish 977 trust, each ACP member requires keying material: An ACP node MUST 978 have a Local Device IDentity certificate (LDevID) and a Trust Anchor 979 (TA) consisting of a certificate (chain) used to sign the LDevID of 980 all ACP domain members. The LDevID is used to cryptographically 981 authenticate the membership of its owner node in the ACP domain to 982 other ACP domain members. The TA is used to authenticate the ACP 983 domain membership of other nodes (see Section 6.1.3). This document 984 calls the LDevID used for the the ACP the ACP certificate. 986 Manual keying via shared secrets is not usable for an ACP domain 987 because it would require a single shared secret across all current 988 and future ACP domain members to meet the expectation of autonomous, 989 peer-to-peer establishment of ACP secure channels between any ACP 990 domain members. Such a single shared secret would be an inacceptable 991 security weakness. Asymmetric keying material (public keys) without 992 certificates does not provide the mechanisms to authenticate ACP 993 domain membership in an autonomous, peer-to-peer fashion for current 994 and future ACP domain members. 996 The LDevID is called the ACP domain certificate, the TA is the 997 Certificate Authority (CA) root certificate of the ACP domain. 999 The ACP does not mandate specific mechanisms by which this keying 1000 material is provisioned into the ACP node. It only requires the 1001 certificate to comply with Section 6.1.1, specifically the Domain 1002 information field as specified in Section 6.1.2 in its domain 1003 certificate as well as those of candidate ACP peers. See 1004 Appendix A.2 for more information about enrollment or provisioning 1005 options. 1007 This document uses the term ACP in many places where the Autonomic 1008 Networking reference documents [RFC7575] and 1009 [I-D.ietf-anima-reference-model] use the word autonomic. This is 1010 done because those reference documents consider (only) fully 1011 autonomic networks and nodes, but support of ACP does not require 1012 support for other components of autonomic networks except for relying 1013 on GRASP and providing security and transport for GRASP. Therefore 1014 the word autonomic might be misleading to operators interested in 1015 only the ACP. 1017 [RFC7575] defines the term "Autonomic Domain" as a collection of 1018 autonomic nodes. ACP nodes do not need to be fully autonomic, but 1019 when they are, then the ACP domain is an autonomic domain. Likewise, 1020 [I-D.ietf-anima-reference-model] defines the term "Domain 1021 Certificate" as the certificate used in an autonomic domain. The ACP 1022 domain certificate is that domain certificate when ACP nodes are 1023 (fully) autonomic nodes. Finally, this document uses the term ACP 1024 network to refer to the network created by active ACP nodes in an ACP 1025 domain. The ACP network itself can extend beyond ACP nodes through 1026 the mechanisms described in Section 8.1. 1028 6.1.1. ACP Certificates 1030 ACP domain certificates MUST be [RFC5280] compliant X.509 1031 certificates. 1033 ACP nodes MUST support RSA and Elliptic Curve (ECC) public keys in 1034 ACP certificates. ACP certificates wth ECC keys MUST indicate to be 1035 Elliptic Curve Diffie-Hellman capable (ECDH) if X.509 v3 keyUsage and 1036 extendedKeyUsage are included in the certificate. 1038 ACP nodes MUST support Certificates RSA keys with no less than 2048 1039 bit key length and ECC keys with NIST P-256, P-384 and P-521 key 1040 length (and curve) or better. ACP nodes MUST support SHA-256, SHA- 1041 384, SHA-512 or better signatures for ACP certificates with RSA key 1042 and the same RSA signatures plus ECDSA signatures for ACP 1043 certificates with ECC key. 1045 The ACP certificate SHOULD use an RSA key and an RSA signature when 1046 the ACP certificate is intended to be used not only for ACP 1047 authentication but also for other purposes. The ACP certificate MAY 1048 use an ECC key and an ECDSA signature if the ACP certificate is only 1049 used for ACP and ANI authentication and authorization. 1051 Any secure channel protocols used for the ACP as specified in this 1052 document or extensions of this document MUST therefore support 1053 authentication (e.g.:signing) starting with these type of 1054 certificates. See [RFC4492] for more information. 1056 The reason for these choices are as follows: As of 2020, RSA is still 1057 more widely used than ECC, therefore the MUST for RSA. ECC offers 1058 equivalent security at (logarithmically) shorter key lengths (see 1059 [RFC4492]). This can be beneficial especially in the presence of 1060 constrained bandwidth or constrained nodes in an ACP/ANI network. 1061 Some ACP functions such as GRASP peer-2-peer across the ACP require 1062 end-to-end/any-to-any authentication/authorization, therefore ECC can 1063 only reliably be used in the ACP when it MUST be supported on all ACP 1064 nodes. RSA signatures are mandatory to be supported also for ECC 1065 certificates because CAs themselves may not support ECC yet. 1067 For further certificate details, ACP certificates may follow the 1068 recommendations from [CABFORUM]. 1070 The ACP domain certificate SHOULD be used for any authentication 1071 between nodes with ACP domain certificates (ACP nodes and NOC nodes) 1072 where the required authorization condition is ACP domain membership, 1073 such as ACP node to NOC/OAM end-to-end security and ASA to ASA end- 1074 to-end security. Section 6.1.3 defines this "ACP domain membership 1075 check". The uses of this check that are standardized in this 1076 document are for the establishment of hop-by-hop ACP secure channels 1077 (Section 6.6) and for ACP GRASP (Section 6.8.2) end-to-end via TLS 1078 ([RFC5246]). 1080 The ACP domain membership check requires a minimum amount of elements 1081 in a certificate as described in Section 6.1.3. All elements are 1082 [RFC5280] compliant. The identity of a node in the ACP is carried 1083 via the ACP Domain Information Field as defined in Section 6.1.2 1084 which is encoded as an rfc822Name field. 1086 Any other field of the ACP domain certificate is to be populated as 1087 required by [RFC5280] or desired by the operator of the ACP domain 1088 ACP registrars/CA and required by other purposes that the ACP domain 1089 certificate is intended to be used for. 1091 For diagnostic and other operational purposes, it is beneficial to 1092 copy the device identifying fields of the node's IDevID into the ACP 1093 domain certificate, such as the "serialNumber" (see 1094 [I-D.ietf-anima-bootstrapping-keyinfra] section 2.3.1). This can be 1095 done for example if it would be acceptable for the devices 1096 "serialNumber" to be signalled via the Link Layer Discovery Protocol 1097 (LLDP, [LLDP]) because like LLDP signalled information, the ACP 1098 certificate information can be retrieved bei neighboring nodes 1099 without further authentication and be used either for beneficial 1100 diagnostics or for malicious attacks. Retrieval of the ACP 1101 certificate is possible via a (failing) attempt to set up an ACP 1102 secure channel, and the "serialNumber" contains usually device type 1103 information that may help to faster determine working exploits/ 1104 attacks against the device. 1106 Note that there is no intention to constrain authorization within the 1107 ACP or autonomic networks using the ACP to just the ACP domain 1108 membership check as defined in this document. It can be extended or 1109 modified with future requirements. Such future authorizations can 1110 use and require additional elements in certificates or policies or 1111 even additional certificates. For an example, see Appendix A.10.5. 1113 6.1.2. ACP Certificate ACP Domain Information Field 1115 Information about the domain MUST be encoded in the domain 1116 certificate in a subjectAltName / rfc822Name field according to the 1117 following ABNF ([RFC5234]) definition: 1119 [RFC Editor: Please substitute SELF in all occurrences of rfcSELF in 1120 this document with the RFC number assigned to this document and 1121 remove this comment line] 1123 domain-information = local-part "@" acp-domain-name 1124 local-part = key [ "+" local-info ] 1125 key = "rfcSELF" 1126 local-info = [ acp-address ] [ "+" rsub extensions ] 1127 HEXLC = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" 1128 ; DIGIT as of RFC5234 section B.1 1129 acp-address = 32HEXLC | "0" 1130 rsub = [ ] ; as of RFC1034, section 3.5 1131 acp-domain-name = ; ; as of RFC 1034, section 3.5 1132 extensions = *( "+" extension ) 1133 extension = ; future standard definition. 1134 ; Must fit RFC5322 simple dot-atom format. 1136 routing-subdomain = [ rsub "." ] acp-domain-name 1138 Example: 1139 given an ACP address of fd89:b714:f3db:0:200:0:6400:0000 1140 and an ACP domain-name of acp.example.com 1141 and an rsub extenstion of area51.research 1143 then this results in: 1144 domain-information = rfcSELF+fd89b714F3db00000200000064000000 1145 +area51.research@acp.example.com 1146 acp-domain-name = acp.example.com 1147 routing-subdomain = area51.research.acp.example.com 1149 Figure 2: ACP Domain Information Field ABNF 1151 domain-information is the encoded information that is put into the 1152 ACP domain certificates subjectAltName / rfc822Name field. routing- 1153 subdomain is a string that can be constructed from the domain- 1154 information, and it is used in the hash-creation of the ULA (see 1155 below). The requirements and sementics of the parts of this 1156 information are explained in the following paragraphs: 1158 Nodes complying with this specification MUST be able to receive their 1159 ACP address through the domain certificate, in which case their own 1160 ACP domain certificate MUST have the 32HEXDIG "acp-address" field. 1161 Nodes complying with this specification MUST also be able to 1162 authenticate nodes as ACP domain members or ACP secure channel peers 1163 when they have a 0-value acp-address field and as ACP domain members 1164 (but not as ACP secure channel peers) when they have an empty acp- 1165 address field. See Section 6.1.3. 1167 "acp-domain-name" is used to indicate the ACP Domain across which all 1168 ACP nodes trust each other and are willing to build ACP channels to 1169 each other. See Section 6.1.3. Acp-domain-name SHOULD be the FQDN 1170 of a DNS domain owned by the operator assigning the certificate. 1171 This is a simple method to ensure that the domain is globally unique 1172 and collision of ACP addresses would therefore only happen due to ULA 1173 hash collisions (see Section 6.10.2). If the operator does not own 1174 any FQDN, it should choose a string (in FQDN format) that it intends 1175 to be equally unique. 1177 To keep the encoding simple, there is no consideration for 1178 internationalized acp-domain-names. The ACP domain information is 1179 not intended for enduser consumption, and there is no protection 1180 against someone not owning a domain name to simpy choose it. 1181 Instead, it only serves as a hash seed for the ULA and for 1182 diagnostics to the operator. Therefore, any operator owning only an 1183 internationalized domain name should be able to pick an equivalently 1184 unique 7-bit ASCII acp-domain-name string representing the 1185 internationalized domain name. 1187 "routing-subdomain" is a heuristic that allows a Registrar to 1188 consistently generate a unique 48-bit ULA prefix for ACP addresses. 1189 The presence of the "rsub" component allows to a single ACP domain to 1190 employ multiple /48 ULA prefixes. See Appendix A.7 for example use- 1191 cases. 1193 The optional "extensions" field is used for future standardized 1194 extensions to this specification. It MUST be ignored if present and 1195 not understood. 1197 Formatting notes: 1199 o "rsub" needs to be in the "local-part": If the format just had 1200 routing-subdomain as the domain part of the domain-information, 1201 rsub and acp-domain-name could not be separated from each other. 1202 It also makes domain-information a valid e-mail target across all 1203 routing-subdomains. 1205 o "acp-address" cannot use standard IPv6 address formats because it 1206 has to match the simple dot-atom format of [RFC5322]. The 1207 character ":" is not allowed in that format. 1209 o If "acp-address" is empty, and "rsub" is empty too, the "local- 1210 part" will have the format "rfcSELF++extension(s)". The two plus 1211 characters are necessary so the node can unambiguously parse that 1212 both "acp-address" and "rsub" are empty. 1214 o The maximum size of "domain-information" is 254 characters and the 1215 maximum size of local-part is 64 characters according to [RFC5280] 1216 that is referring to [RFC2821] (superseded by [RFC5321]). 1218 The subjectAltName / rfc822Name encoding of the ACP domain name and 1219 ACP address is used for the following reasons: 1221 Rfc822name encoding for the ACP domain information was choosen for 1222 the following reasons. 1224 o The ACP domain information field is the identifier of a node's 1225 ACP. It includes the the necessary components to identify a nodes 1226 ACP both from within the ACP as well as from the outside of the 1227 ACP. 1229 o For manual and/or automated diagnostics and backend management of 1230 devices and ACPs, it is necessary to have an easily human readible 1231 and software parsed standard, single string representation of the 1232 ACP domain information. For example, inventory or other backend 1233 systems can always identify an entity by one unique string field 1234 but not by a combination of multiple fields, which would be 1235 necessary if there was no single string representation. 1237 o If the encoding of the ACP domain information into the ACP domains 1238 certificate was not that of such a string, it would be necessary 1239 to define a second standard encoding to provide this format 1240 (standard string encoding). 1242 o Rfc822 addresses have become standard identifiers of entities in 1243 many systems, including the majority of user identification in web 1244 or mobile applications, where in many cases, e-mail is not even 1245 part of the service for which an rfc822 address is used as an 1246 entities identifier. In single-sign-on systems for example, 1247 @ is instead used to indicate a with 1248 which authentication and authorization of is 1249 performend without any other use of RFC822 than its address format 1250 (e.g.: no rfc822 formatted message exchanges). 1252 o Encoding the ACP nodes identity/name in the format of an 1253 rfc822address is therefore following common practices for how 1254 rfc822 addresses are used in other contexts. It also very well 1255 matches the format of rfc822 address structure @ because the ACP domain information does logically 1257 also consist of a identifying the ACP, and a 1258 identifying a nodes ACP. 1260 o subjectAltName / rfc822Name is the standard, mandatory to 1261 implement certificate attribute to encode the certificate subjects 1262 rfc822 address and can be the only subjects name. 1264 Compatibilities: 1266 o It should be possible to use the ACP domain certificate as an 1267 LDevID on the system for other uses beside the ACP. Therefore, 1268 the information element required for the ACP should be encoded so 1269 that it minimizes the possibility of creating incompatibilities 1270 with such other uses. The subjectName for example is for example 1271 often used as an entity identifier in non-ACP uses. 1273 o The element should not require additional ASN.1 en/decoding, 1274 because libraries to access certificate information especially for 1275 embedded devices may not support extended ASN.1 decoding beyond 1276 predefined, manadatory fields. subjectAltName / rfc822Name is such 1277 a mandatory predefined field. subjectAlName / otherName for 1278 example is not. 1280 o Encoding of the ACP domain information as a human readable string 1281 in a manadatory certificate field also has the benefit that it can 1282 be diagnosed/decoded in any pre-existing certificate diagnostic 1283 software. 1285 o The element required for the ACP should not be misinterpreted by 1286 any other uses of the LDevID. If the element used for the ACP is 1287 interpreted by other components than the ACP, the impact should be 1288 benign. By using fully rfc822address compliant encoding, the 1289 benign side effect of non-ACP software using the ACP rfc822address 1290 would be emails sent to the mailbox identified by the 1291 rfc822address. If it is desired to receive such emails, suitable 1292 email software may also support assigning all rfc822addresses for 1293 an ACP domain to a single mailbox rfcSELF@. This is 1294 possible when "+" (which follows rfcSELF) is supported by the Mail 1295 User Agent as a separator between mail subscriber and sub-mailbox. 1297 See section 4.2.1.6 of [RFC5280] for details on the subjectAltName 1298 field. 1300 6.1.3. ACP domain membership check 1302 The following points constitute the ACP domain membership check of a 1303 candidate peer via its certificate: 1305 1: The peer certificate MUST be valid (lifetime). 1307 2: The peer has proved ownership of the private key associated with 1308 the certificate's public key. This check is performed by the 1309 security association protocol used, for example [RFC7296], section 1310 2.15. 1312 3: The peer's certificate passes certificate path validation as 1313 defined in [RFC5280], section 6 against one of the TA associated 1314 with the ACP node's ACP domain certificate (see Section 6.1.4 1315 below). 1317 4: If the node certificate indicates a Certificate Revocation List 1318 (CRL) Distribution Point (CDP) ([RFC5280], section 4.2.1.13) or 1319 Online Certificate Status Protocol (OCSP) responder ([RFC5280], 1320 section 4.2.2.1), then the peer's certificate MUST be valid 1321 according to those criteria: An OCSP check for the peer's 1322 certificate across the ACP MUST succeed or the peer certificate 1323 MUST not be listed in the CRL retrieved from the CDP. This rule 1324 has to be skipped for ACP secure channel peer authentication when 1325 the node has no ACP or non-ACP connectivity to retrieve current 1326 CRL or access an OCSP responder (and the security association 1327 protocol itself has also no way to communicate CRL or OCSP check). 1329 When an ACP node learns later via OCSP/CRL that an ACP peer's 1330 certificate is invalid for which rule 4 had to be skipped during 1331 ACP secure channel establishment, then the ACP secure channel to 1332 that peer MUST be closed even if this peer is the only 1333 connectivity to access CRL/OCSP. This applies (of course) to all 1334 ACP secure channels to this peer if there are multiple. The ACP 1335 secure channel connection MUST be retried periodically to support 1336 the case that the neighbor aquires a new, valid certificate. 1338 5: The peer's certificate has a syntactically valid ACP domain 1339 information field (encoded as subjectAltName / rfc822Name) and the 1340 acp-domain-name in that peer's domain information field is the 1341 same as in this ACP node's certificate (lowercase normalized). 1343 When checking a candidate peer's certificate for the purpose of 1344 establishing an ACP secure channel, one additional check is 1345 performed: 1347 6: The candidate peer certificate's ACP domain information field 1348 has a non-empty acp-address field (either 32HEXDIG or 0, according 1349 to Figure 2). 1351 Technically, ACP secure channels can only be built with nodes that 1352 have an acp-address. Rule 6 ensures that this is taken into account 1353 during ACP domain membership check. 1355 Nodes with an empty acp-address field can only use their ACP domain 1356 certificate for non-ACP-secure channel authentication purposes. This 1357 includes for example NMS type nodes permitted to communicate into the 1358 ACP via ACP connect (Section 8.1) 1360 The special value 0 in an ACP certificates acp-address field is used 1361 for nodes that can and should determine their ACP address through 1362 other mechanisms than learning it through the acp-address field in 1363 their ACP domain certificate. These ACP nodes are permitted to 1364 establish ACP secure channels. Mechanisms for those nodes to 1365 determine their ACP address are outside the scope of this 1366 specification, but this option is defined here so that any ACP nodes 1367 can build ACP secure channels to them according to Rule 6. 1369 In summary: 1371 Steps 1...4 constitute standard certificate validity verification 1372 and private key authentication as defined by [RFC5280] and 1373 security association protocols (such as Internet Key Exchange 1374 Protocol version 2 IKEv2 [RFC7296] when leveraging certificates. 1376 Steps 1...4 do not include verification of any pre-existing form 1377 of non-public-key-only based identity elements of a certificate 1378 such as a web servers domain name prefix often encoded in 1379 certificate common name. Steps 5 and 6 are the equivalent steps. 1381 Step 4 Constitutes standard CRL/OCSP checks refined for the case 1382 of missing connectivity and limited functionality security 1383 association protocols. 1385 Step 5 Checks for the presence of an ACP identity for the peer. 1387 Steps 1...5 authorize to build any secure connection between 1388 members of the same ACP domain except for ACP secure channels. 1390 Step 6 is the additional verification of the presence of an ACP 1391 address. 1393 Steps 1...6 authorize to build an ACP secure channel. 1395 For brevity, the remainder of this document refers to this process 1396 only as authentication instead of as authentication and 1397 authorization. 1399 6.1.3.1. Realtime clock and Time Validation 1401 An ACP node with a realtime clock in which it has confidence, MUST 1402 check the time stamps when performing ACP domain membership check 1403 such as as the certificate validity period in step 1. and the 1404 respective times in step 4 for revocation information (e.g.: 1405 signingTimes in CMS signatures). 1407 An ACP node without such a realtime clock MAY ignore those time stamp 1408 validation steps if it does not know the current time. Such an ACP 1409 node SHOULD obtain the current time in a secured fashion, such as via 1410 a Network Time Protocol signalled through the ACP. It then ignores 1411 time stamp validation only until the current time is known. In the 1412 absence of implementing a secured mechanism, such an ACP node MAY use 1413 a current time learned in an insecured fashion in the ACP domain 1414 membership check. 1416 Beside ACP domain membership check, the ACP itself has no dependency 1417 against knowledge of the current time, but protocols and services 1418 using the ACP will likley have the need to know the current time. 1419 For example event logging. 1421 6.1.4. Trust Points and Trust Anchors 1423 ACP nodes need Trust Point (TP) certificates to perform certificate 1424 path validation as required by Section 6.1.3, rule 3. Trust Point(s) 1425 MUST be provisioned to an ACP node (together with its ACP domain 1426 certificate) by an ACP Registrar during initial enrolment of a 1427 candidate ACP node. ACP nodes MUST also support renewal of TPs via 1428 Enrollment over Secure Transport (EST, see [RFC7030]), as described 1429 below in Section 6.1.5. 1431 Trust Point is the term used in this document for a CA and its 1432 associated set of certificates. Multiple certificates are required 1433 for a CA to deal with CA certificate renewals as explained in 1434 Section 4.4 of CMP ([RFC4210]). 1436 A certificate path is a chain of certificates starting at the ACP 1437 certificate (leaf/end-entity) followed by zero or more intermediate 1438 Trust Point or sub-CA certificates and ending with a self-signed 1439 certificate of a so called root-CA or Trust Anchor. Certificate path 1440 validation authenticates that the ACP certificate is signed by a 1441 Trust Anchor, directly or indirectly via one or more intermediate 1442 Trust Points. 1444 Note that different ACP nodes may have different Trust Points and 1445 even different Trust Anchors in their certificate path, as long as 1446 the set of Trust Points for all ACP node includes the same set of 1447 Trust Anchors (usually 1), and each ACP nodes set of Trust Anchors 1448 includes the intermediate Trust Points for its own ACP domain 1449 certificate. The protocols through which ACP domain membership check 1450 rules 1-4 are performed therefore need to support the exchange not 1451 only of the ACP nodes certificates, but also their intermediate Trust 1452 Points. 1454 ACP nodes MUST support for the ACP domain membership check the 1455 certificate path validation with 0 or 1 intermediate Trust Points. 1456 They SHOULD support 2 intermediate Trust Points and two Trust Anchors 1457 (to permit migration to different root-CAs). 1459 Trust Points for ACP domain certificates are trusted to sign 1460 certificates with valid ACP domain information fields only for 1461 trusted ACP registrars of that domain. This can be achieved by using 1462 Trust Anchors private to the owner of the ACP domain or potentially 1463 through appropriate contractual agreements between the involved 1464 parties. Public CA without such obligations and guarantees can not 1465 be used. 1467 A single owner can operate multiple independent ACP domains from the 1468 same set of private trust anchors (CAs) when the ACP Registrars are 1469 trusted not to permit certificates with incorrect ACP information 1470 fields to be signed, such as ACP information with a wrong acp-domain 1471 field. In this case, CAs can be completely unaware of ACP specifics, 1472 so that it should be possible to use any existing CA software. When 1473 ACP Registrars are not to be trusted, the correctness of the ACP 1474 domain information field for the candidate ACP node has to be 1475 verified by the CA signing the ACP domain certificate. 1477 6.1.5. Certificate and Trust Point Maintenance 1479 ACP nodes MUST support renewal of their Certificate and TPs via EST 1480 ("Enrollment over Secure Transport", see [RFC7030]) and MAY support 1481 other mechanisms. An ACP network MUST have at least one ACP node 1482 supporting EST server functionality across the ACP so that EST 1483 renewal is useable. 1485 ACP nodes SHOULD be able to remember the IPv6 locator parameters of 1486 the O_IPv6_LOCATOR in GRASP of the EST server from which they last 1487 renewed their ACP domain certificate. They SHOULD provide the 1488 ability for these EST server parameters to also be set by the ACP 1489 Registrar (see Section 6.10.7) that initially enrolled the ACP device 1490 with its ACP domain certificate. When BRSKI (see 1491 [I-D.ietf-anima-bootstrapping-keyinfra]) is used, the IPv6 locator of 1492 the BRSKI registrar from the BRSKI TLS connection SHOULD be 1493 remembered and used for the next renewal via EST if that registrar 1494 also announces itself as an EST server via GRASP (see next section) 1495 on its ACP address. 1497 The EST server MUST present a certificate that is passing ACP domain 1498 membership check in its TLS connection setup (Section 6.1.3, rules 1499 1..5, not rule 6 as this is not for an ACP secure channel setup). 1500 The EST server certificate MUST also contain the id-kp-cmcRA 1501 [RFC6402] extended key usage extension and the EST client MUST check 1502 its presence. 1504 The additional check against the id-kp-cmcRA extended key usage 1505 extension field ensures that clients do not fall prey to an illicit 1506 EST server. While such illicit EST servers should not be able to 1507 support certificate signing requests (as they are not able to elicit 1508 a signing response from a valid CA), such an illicit EST server would 1509 be able to provide faked CA certificates to EST clients that need to 1510 renew their CA certificates when they expire. 1512 Note that EST servers supporting multiple ACP domains will need to 1513 have for each of these ACP domains a separate certificate and respond 1514 on a different transport address (IPv6 address and/or TCP port), but 1515 this is easily automated on the EST server as long as the CA does not 1516 restrict registrars to request certificates with the id-kp-cmcRA 1517 extended usage extension for themselves. 1519 6.1.5.1. GRASP objective for EST server 1521 ACP nodes that are EST servers MUST announce their service via GRASP 1522 in the ACP through M_FLOOD messages. See [I-D.ietf-anima-grasp], 1523 section 2.8.11 for the definition of this message type: 1525 Example: 1527 [M_FLOOD, 12340815, h'fd89b714f3db0000200000064000001', 210000, 1528 ["SRV.est", 4, 255 ], 1529 [O_IPv6_LOCATOR, 1530 h'fd89b714f3db0000200000064000001', TCP, 443] 1531 ] 1533 Figure 3: GRASP SRV.est example 1535 The formal definition of the objective in Concise data definition 1536 language (CDDL) (see [RFC8610]) is as follows: 1538 flood-message = [M_FLOOD, session-id, initiator, ttl, 1539 +[objective, (locator-option / [])]] 1540 ; see example above and explanation 1541 ; below for initiator and ttl 1543 objective = ["SRV.est", objective-flags, loop-count, 1544 objective-value] 1546 objective-flags = sync-only ; as in GRASP spec 1547 sync-only = 4 ; M_FLOOD only requires synchronization 1548 loop-count = 255 ; recommended as there is no mechanism 1549 ; to discover network diameter. 1550 objective-value = any ; reserved for future extensions 1552 Figure 4: GRASP SRV.est definition 1554 The objective name "SRV.est" indicates that the objective is an 1555 [RFC7030] compliant EST server because "est" is an [RFC6335] 1556 registered service name for [RFC7030]. Objective-value MUST be 1557 ignored if present. Backward compatible extensions to [RFC7030] MAY 1558 be indicated through objective-value. Non [RFC7030] compatible 1559 certificate renewal options MUST use a different objective-name. 1560 Non-recognized objective-values (or parts thereof if it is a 1561 structure partially understood) MUST be ignored. 1563 The M_FLOOD message MUST be sent periodically. The default SHOULD be 1564 60 seconds, the value SHOULD be operator configurable but SHOULD be 1565 not smaller than 60 seconds. The frequency of sending MUST be such 1566 that the aggregate amount of periodic M_FLOODs from all flooding 1567 sources cause only negligible traffic across the ACP. The time-to- 1568 live (ttl) parameter SHOULD be 3.5 times the period so that up to 1569 three consecutive messages can be dropped before considering an 1570 announcement expired. In the example above, the ttl is 210000 msec, 1571 3.5 times 60 seconds. When a service announcer using these 1572 parameters unexpectedly dies immediately after sending the M_FLOOD, 1573 receivers would consider it expired 210 seconds later. When a 1574 receiver tries to connect to this dead service before this timeout, 1575 it will experience a failing connection and use that as an indication 1576 that the service instance is dead and select another instance of the 1577 same service instead (from another GRASP announcement). 1579 6.1.5.2. Renewal 1581 When performing renewal, the node SHOULD attempt to connect to the 1582 remembered EST server. If that fails, it SHOULD attempt to connect 1583 to an EST server learned via GRASP. The server with which 1584 certificate renewal succeeds SHOULD be remembered for the next 1585 renewal. 1587 Remembering the last renewal server and preferring it provides 1588 stickiness which can help diagnostics. It also provides some 1589 protection against off-path compromised ACP members announcing bogus 1590 information into GRASP. 1592 Renewal of certificates SHOULD start after less than 50% of the 1593 domain certificate lifetime so that network operations has ample time 1594 to investigate and resolve any problems that causes a node to not 1595 renew its domain certificate in time - and to allow prolonged periods 1596 of running parts of a network disconnected from any CA. 1598 6.1.5.3. Certificate Revocation Lists (CRLs) 1600 The ACP node SHOULD support revocation through CRL(s) via HTTP from 1601 one or more CRL Distribution Points (CDPs). The CDP(s) MUST be 1602 indicated in the Domain Certificate when used. If the CDP URL uses 1603 an IPv6 address (ULA address when using the addressing rules 1604 specified in this document), the ACP node will connect to the CDP via 1605 the ACP. If the CDP uses a domain name, the ACP node will connect to 1606 the CDP via the Data-Plane. 1608 It is common to use domain names for CDP(s), but there is no 1609 requirement for the ACP to support DNS. Any DNS lookup in the Data- 1610 Plane is not only a possible security issue, but it would also not 1611 indicate whether the resolved address is meant to be reachable across 1612 the ACP. Therefore, the use of an IPv6 address versus the use of a 1613 DNS name doubles as an indicator whether or not to reach the CDP via 1614 the ACP. 1616 A CDP can be reachable across the ACP either by running it on a node 1617 with ACP or by connecting its node via an ACP connect interface (see 1618 Section 8.1). The CDP SHOULD use an ACP domain certificate for its 1619 HTTPs connections. The connecting ACP node SHOULD verify that the 1620 CDP certificate used during the HTTPs connection has the same ACP 1621 address as indicated in the CDP URL of the node's ACP domain 1622 certificate if the CDP URL uses an IPv6 address. 1624 6.1.5.4. Lifetimes 1626 Certificate lifetime may be set to shorter lifetimes than customary 1627 (1 year) because certificate renewal is fully automated via ACP and 1628 EST. The primary limiting factor for shorter certificate lifetimes 1629 is load on the EST server(s) and CA. It is therefore recommended 1630 that ACP domain certificates are managed via a CA chain where the 1631 assigning CA has enough performance to manage short lived 1632 certificates. See also Section 9.2.4 for discussion about an example 1633 setup achieving this. See also [I-D.ietf-acme-star]. 1635 When certificate lifetimes are sufficiently short, such as few hours, 1636 certificate revocation may not be necessary, allowing to simplify the 1637 overall certificate maintenance infrastructure. 1639 See Appendix A.2 for further optimizations of certificate maintenance 1640 when BRSKI can be used ("Bootstrapping Remote Secure Key 1641 Infrastructures", see [I-D.ietf-anima-bootstrapping-keyinfra]). 1643 6.1.5.5. Re-enrollment 1645 An ACP node may determine that its ACP domain certificate has 1646 expired, for example because the ACP node was powered down or 1647 disconnected longer than its certificate lifetime. In this case, the 1648 ACP node SHOULD convert to a role of a re-enrolling candidate ACP 1649 node. 1651 In this role, the node does maintain the trust anchor and certificate 1652 chain associated with its ACP domain certificate exclusively for the 1653 purpose of re-enrollment, and attempts (or waits) to get re-enrolled 1654 with a new ACP certificate. The details depend on the mechanisms/ 1655 protocols used by the ACP registrars. 1657 Please refer to Section 6.10.7 and 1658 [I-D.ietf-anima-bootstrapping-keyinfra] for explanations about ACP 1659 registrars and vouchers as used in the following text. When ACP is 1660 intended to be used without BRSKI, the details about BRSKI and 1661 vouchers in the following text can be skipped. 1663 When BRSKI is used (i.e.: on ACP nodes that are ANI nodes), the re- 1664 enrolling candidate ACP node would attempt to enroll like a candidate 1665 ACP node (BRSKI pledge), but instead of using the ACP nodes IDevID, 1666 it SHOULD first attempt to use its ACP domain certificate in the 1667 BRSKI TLS authentication. The BRSKI registrar MAY honor this 1668 certificate beyond its expiration date purely for the purpose of re- 1669 enrollment. Using the ACP node's domain certificate allows the BRSKI 1670 registrar to learn that node's ACP domain information field, so that 1671 the BRSKI registrar can re-assign the same ACP address information to 1672 the ACP node in the new ACP domain certificate. 1674 If the BRSKI registrar denies the use of the old ACP domain 1675 certificate, the re-enrolling candidate ACP node MUST re-attempt re- 1676 enrollment using its IDevID as defined in BRSKI during the TLS 1677 connection setup. 1679 Both when the BRSKI connection is attempted with the old ACP domain 1680 certificate or the IDevID, the re-enrolling candidate ACP node SHOULD 1681 authenticate the BRSKI registrar during TLS connection setup based on 1682 its existing trust anchor/certificate chain information associated 1683 with its old ACP certificate. The re-enrolling candidate ACP node 1684 SHOULD only fall back to requesting a voucher from the BRSKI 1685 registrar when this authentication fails during TLS connection setup. 1687 When other mechanisms than BRSKI are used for ACP domain certificate 1688 enrollment, the principles of the re-enrolling candidate ACP node are 1689 the same. The re-enrolling candidate ACP node attempts to 1690 authenticate any ACP registrar peers during re-enrollment protocol/ 1691 mechanisms via its existing certificate chain/trust anchor and 1692 provides its existing ACP domain certificate and other identification 1693 (such as the IDevID) as necessary to the registrar. 1695 Maintaining existing trust anchor information is especially important 1696 when enrollment mechanisms are used that unlike BRSKI do not leverage 1697 a voucher mechanism to authenticate the ACP registrar and where 1698 therefore the injection of certificate failures could otherwise make 1699 the ACP node easily attackable remotely. 1701 When using BRSKI or other protocol/mechanisms supporting vouchers, 1702 maintaining existing trust anchor information allows for re- 1703 enrollment of expired ACP certificates to be more lightweight, 1704 especially in environments where repeated acquisition of vouchers 1705 during the lifetime of ACP nodes may be operationally expensive or 1706 otherwise undesirable. 1708 6.1.5.6. Failing Certificates 1710 An ACP domain certificate is called failing in this document, if/when 1711 the ACP node to which the certificate was issued can determine that 1712 it was revoked (or explicitly not renewed), or in the absence of such 1713 explicit local diagnostics, when the ACP node fails to connect to 1714 other ACP nodes in the same ACP domain using its ACP certificate. 1715 For connection failures to determine the ACP domain certificate as 1716 the culprit, the peer should pass the domain membership check 1717 (Section 6.1.3) and other reasons for the connection failure can be 1718 excluded because of the connection error diagnostics. 1720 This type of failure can happen during setup/refresh of a secure ACP 1721 channel connections or any other use of the ACP domain certificate, 1722 such as for the TLS connection to an EST server for the renewal of 1723 the ACP domain certificate. 1725 Example reasons for failing certificates that the ACP node can only 1726 discover through connection failure are that the domain certificate 1727 or any of its signing certificates could have been revoked or may 1728 have expired, but the ACP node cannot self-diagnose this condition 1729 directly. Revocation information or clock synchronization may only 1730 be available across the ACP, but the ACP node cannot build ACP secure 1731 channels because ACP peers reject the ACP node's domain certificate. 1733 ACP nodes SHOULD support the option to determines whether its ACP 1734 certificate is failing, and when it does, put itself into the role of 1735 a re-enrolling candidate ACP node as explained above 1736 (Section 6.1.5.5). 1738 6.2. ACP Adjacency Table 1740 To know to which nodes to establish an ACP channel, every ACP node 1741 maintains an adjacency table. The adjacency table contains 1742 information about adjacent ACP nodes, at a minimum: Node-ID 1743 (identifier of the node inside the ACP, see Section 6.10.3 and 1744 Section 6.10.5), interface on which neighbor was discovered (by GRASP 1745 as explained below), link-local IPv6 address of neighbor on that 1746 interface, certificate (including domain information field). An ACP 1747 node MUST maintain this adjacency table. This table is used to 1748 determine to which neighbor an ACP connection is established. 1750 Where the next ACP node is not directly adjacent (i.e., not on a link 1751 connected to this node), the information in the adjacency table can 1752 be supplemented by configuration. For example, the Node-ID and IP 1753 address could be configured. See Section 8.2. 1755 The adjacency table MAY contain information about the validity and 1756 trust of the adjacent ACP node's certificate. However, subsequent 1757 steps MUST always start with the ACP domain membership check against 1758 the peer (see Section 6.1.3). 1760 The adjacency table contains information about adjacent ACP nodes in 1761 general, independently of their domain and trust status. The next 1762 step determines to which of those ACP nodes an ACP connection should 1763 be established. 1765 6.3. Neighbor Discovery with DULL GRASP 1767 [RFC Editor: GRASP draft is in RFC editor queue, waiting for 1768 dependencies, including ACP. Please ensure that references to I- 1769 D.ietf-anima-grasp that include section number references (throughout 1770 this document) will be updated in case any last-minute changes in 1771 GRASP would make those section references change. 1773 Discovery Unsolicited Link-Local (DULL) GRASP is a limited subset of 1774 GRASP intended to operate across an insecure link-local scope. See 1775 section 2.5.2 of [I-D.ietf-anima-grasp] for its formal definition. 1776 The ACP uses one instance of DULL GRASP for every L2 interface of the 1777 ACP node to discover link level adjacent candidate ACP neighbors. 1778 Unless modified by policy as noted earlier (Section 5 bullet point 1779 2.), native interfaces (e.g., physical interfaces on physical nodes) 1780 SHOULD be initialized automatically to a state in which ACP discovery 1781 can be performed and any native interfaces with ACP neighbors can 1782 then be brought into the ACP even if the interface is otherwise not 1783 configured. Reception of packets on such otherwise not configured 1784 interfaces MUST be limited so that at first only IPv6 StateLess 1785 Address Auto Configuration (SLAAC - [RFC4862]) and DULL GRASP work 1786 and then only the following ACP secure channel setup packets - but 1787 not any other unnecessary traffic (e.g., no other link-local IPv6 1788 transport stack responders for example). 1790 Note that the use of the IPv6 link-local multicast address 1791 (ALL_GRASP_NEIGHBORS) implies the need to use Multicast Listener 1792 Discovery Version 2 (MLDv2, see [RFC3810]) to announce the desire to 1793 receive packets for that address. Otherwise DULL GRASP could fail to 1794 operate correctly in the presence of MLD snooping, non-ACP enabled L2 1795 switches ([RFC4541]) - because those would stop forwarding DULL GRASP 1796 packets. Switches not supporting MLD snooping simply need to operate 1797 as pure L2 bridges for IPv6 multicast packets for DULL GRASP to work. 1799 ACP discovery SHOULD NOT be enabled by default on non-native 1800 interfaces. In particular, ACP discovery MUST NOT run inside the ACP 1801 across ACP virtual interfaces. See Section 9.3 for further, non- 1802 normative suggestions on how to enable/disable ACP at node and 1803 interface level. See Section 8.2.2 for more details about tunnels 1804 (typical non-native interfaces). See Section 7 for how ACP should be 1805 extended on devices operating (also) as L2 bridges. 1807 Note: If an ACP node also implements BRSKI to enroll its ACP domain 1808 certificate (see Appendix A.2 for a summary), then the above 1809 considerations also apply to GRASP discovery for BRSKI. Each DULL 1810 instance of GRASP set up for ACP is then also used for the discovery 1811 of a bootstrap proxy via BRSKI when the node does not have a domain 1812 certificate. Discovery of ACP neighbors happens only when the node 1813 does have the certificate. The node therefore never needs to 1814 discover both a bootstrap proxy and ACP neighbor at the same time. 1816 An ACP node announces itself to potential ACP peers by use of the 1817 "AN_ACP" objective. This is a synchronization objective intended to 1818 be flooded on a single link using the GRASP Flood Synchronization 1819 (M_FLOOD) message. In accordance with the design of the Flood 1820 message, a locator consisting of a specific link-local IP address, IP 1821 protocol number and port number will be distributed with the flooded 1822 objective. An example of the message is informally: 1824 [M_FLOOD, 12340815, h'fe80000000000000c0011001feef0000', 210000, 1825 ["AN_ACP", 4, 1, "IKEv2" ], 1826 [O_IPv6_LOCATOR, 1827 h'fe80000000000000c0011001feef0000', UDP, 15000] 1828 ["AN_ACP", 4, 1, "DTLS" ], 1829 [O_IPv6_LOCATOR, 1830 h'fe80000000000000c0011001feef0000', UDP, 17000] 1831 ] 1833 Figure 5: GRASP AN_ACP example 1835 The formal CDDL definition is: 1837 flood-message = [M_FLOOD, session-id, initiator, ttl, 1838 +[objective, (locator-option / [])]] 1840 objective = ["AN_ACP", objective-flags, loop-count, 1841 objective-value] 1843 objective-flags = sync-only ; as in the GRASP specification 1844 sync-only = 4 ; M_FLOOD only requires synchronization 1845 loop-count = 1 ; limit to link-local operation 1846 objective-value = method 1847 method = "IKEv2" / "DTLS" ; or future standard methods 1849 Figure 6: GRASP AN_ACP definition 1851 The objective-flags field is set to indicate synchronization. 1853 The loop-count is fixed at 1 since this is a link-local operation. 1855 In the above example the RECOMMENDED period of sending of the 1856 objective is 60 seconds. The indicated ttl of 210000 msec means that 1857 the objective would be cached by ACP nodes even when two out of three 1858 messages are dropped in transit. 1860 The session-id is a random number used for loop prevention 1861 (distinguishing a message from a prior instance of the same message). 1862 In DULL this field is irrelevant but has to be set according to the 1863 GRASP specification. 1865 The originator MUST be the IPv6 link local address of the originating 1866 ACP node on the sending interface. 1868 The 'objective-value' parameter is a string indicating the protocol 1869 available at the specified or implied locator. It is a protocol 1870 supported by the node to negotiate a secure channel. IKEv2 as shown 1871 above is the protocol used to negotiate an IPsec secure channel. 1873 The locator-option is optional and only required when the secure 1874 channel protocol is not offered at a well-defined port number, or if 1875 there is no well-defined port number. 1877 IKEv2 is the actual protocol used to negotiate an Internet Protocol 1878 security architecture (IPsec) connection. GRASP therefore indicates 1879 "IKEv2" and not "IPsec". If "IPsec" was used, this too could mean 1880 use of the obsolete older version IKE (v1) ([RFC2409]). IKEv2 has am 1881 IANA assigned port number 500, but in the above example, the 1882 candidate ACP neighbor is offering ACP secure channel negotiation via 1883 IKEv2 on port 15000 (purely to show through the example that GRASP 1884 allows to indicate the port number and it does not have to be the 1885 IANA assigned one). 1887 "DTLS" indicates DTLS version 1.2. This can also be a newer version 1888 of the protocol as long as it can negotiate down to version 1.2 in 1889 the presence of a peer only speaking DTLS version 1.2. There is no 1890 default UDP port for DTLS, it is always locally assigned by the node. 1891 For details, see Section 6.7.4. 1893 If a locator is included, it MUST be an O_IPv6_LOCATOR, and the IPv6 1894 address MUST be the same as the initiator address (these are DULL 1895 requirements to minimize third party DoS attacks). 1897 The secure channel methods defined in this document use the 1898 objective-values of "IKEv2" and "DTLS". There is no distinction 1899 between IKEv2 native and GRE-IKEv2 because this is purely negotiated 1900 via IKEv2. 1902 A node that supports more than one secure channel protocol method 1903 needs to flood multiple versions of the "AN_ACP" objective so that 1904 each method can be accompanied by its own locator-option. This can 1905 use a single GRASP M_FLOOD message as shown in Figure 5. 1907 Note that a node serving both as an ACP node and BRSKI Join Proxy may 1908 choose to distribute the "AN_ACP" objective and the respective BRSKI 1909 in the same M_FLOOD message, since GRASP allows multiple objectives 1910 in one message. This may be impractical though if ACP and BRSKI 1911 operations are implemented via separate software modules / ASAs. 1913 The result of the discovery is the IPv6 link-local address of the 1914 neighbor as well as its supported secure channel protocols (and non- 1915 standard port they are running on). It is stored in the ACP 1916 Adjacency Table (see Section 6.2), which then drives the further 1917 building of the ACP to that neighbor. 1919 Note that the DULL GRASP objective described does intentionally not 1920 include ACP nodes ACP domain certificate even though this would be 1921 useful for diagnostics and to simplify the security exchange in ACP 1922 secure channel security association protocols (see Section 6.7). The 1923 reason is that DULL GRASP messages are periodically multicasted 1924 across IPv6 subnets and full certificates could easily lead to 1925 fragmented IPv6 DULL GRASP multicast packets due to the size of a 1926 certificate. This would be highly undesirable. 1928 6.4. Candidate ACP Neighbor Selection 1930 An ACP node determines to which other ACP nodes in the adjacency 1931 table it should attempt to build an ACP connection. This is based on 1932 the information in the ACP Adjacency table. 1934 The ACP is established exclusively between nodes in the same domain. 1935 This includes all routing subdomains. Appendix A.7 explains how ACP 1936 connections across multiple routing subdomains are special. 1938 The result of the candidate ACP neighbor selection process is a list 1939 of adjacent or configured autonomic neighbors to which an ACP channel 1940 should be established. The next step begins that channel 1941 establishment. 1943 6.5. Channel Selection 1945 To avoid attacks, initial discovery of candidate ACP peers cannot 1946 include any non-protected negotiation. To avoid re-inventing and 1947 validating security association mechanisms, the next step after 1948 discovering the address of a candidate neighbor can only be to try 1949 first to establish a security association with that neighbor using a 1950 well-known security association method. 1952 From the use-cases it seems clear that not all type of ACP nodes can 1953 or need to connect directly to each other or are able to support or 1954 prefer all possible mechanisms. For example, code space limited IoT 1955 devices may only support DTLS because that code exists already on 1956 them for end-to-end security, but low-end in-ceiling L2 switches may 1957 only want to support Media Access Control Security (MacSec, see 1958 802.1AE ([MACSEC]) because that is also supported in their chips. 1959 Only a flexible gateway device may need to support both of these 1960 mechanisms and potentially more. Note that MacSec is not required by 1961 any profiles of the ACP in this specification but just mentioned as a 1962 likely next interesting secure channel protocol. 1964 To support extensible secure channel protocol selection without a 1965 single common mandatory to implement (MTI) protocol, ACP nodes MUST 1966 try all the ACP secure channel protocols it supports and that are 1967 feasible because the candidate ACP neighbor also announced them via 1968 its AN_ACP GRASP parameters (these are called the "feasible" ACP 1969 secure channel protocols). 1971 To ensure that the selection of the secure channel protocols always 1972 succeeds in a predictable fashion without blocking, the following 1973 rules apply: 1975 o An ACP node may choose to attempt to initiate the different 1976 feasible ACP secure channel protocols it supports according to its 1977 local policies sequentially or in parallel, but it MUST support 1978 acting as a responder to all of them in parallel. 1980 o Once the first secure channel protocol succeeds, the two peers 1981 know each other's certificates because they are used by all secure 1982 channel protocols for mutual authentication. The node with the 1983 lower Node-ID in the ACP address of its ACP domain certificate 1984 becomes Bob, the one with the higher Node-ID in the certificate 1985 Alice. A peer with an empty ACP address field in its ACP domain 1986 certificate becomes Bob (this specification does not define such 1987 peers, only the interoperability with them). 1989 o Bob becomes passive, he does not attempt to further initiate ACP 1990 secure channel protocols with Alice and does not consider it to be 1991 an error when Alice closes secure channels. Alice becomes the 1992 active party, continues to attempt setting up secure channel 1993 protocols with Bob until she arrives at the best one from her view 1994 that also works with Bob. 1996 For example, originally Bob could have been the initiator of one ACP 1997 secure channel protocol that Bob prefers and the security association 1998 succeeded. The roles of Bob and Alice are then assigned and the 1999 connection setup is completed. The protocol could for example be 2000 IPsec via IKEv2 ("IP security", see [RFC4301] and "Internet Key 2001 Exchange protocol version 2", see [RFC7296]. It is now up to Alice 2002 to decide how to proceed. Even if the IPsec connection from Bob 2003 succeeded, Alice might prefer another secure protocol over IPsec 2004 (e.g., FOOBAR), and try to set that up with Bob. If that preference 2005 of Alice succeeds, she would close the IPsec connection. If no 2006 better protocol attempt succeeds, she would keep the IPsec 2007 connection. 2009 The following sequence of steps show this example in more detail. 2010 Each step is tagged with [{:}]. The connection is 2011 included to easier distinguish which of the two competing connections 2012 the step belong to, one initiated by Node 1, one initiated by Node 2. 2014 [1] Node 1 sends GRASP AN_ACP message to announce itself 2016 [2] Node 2 sends GRASP AN_ACP message to announce itself 2018 [3] Node 2 receives [1] from Node 1 2020 [4:C1] Because of [3], Node 2 starts as initiator on its 2021 preferred secure channel protocol towards Node 1. 2022 Connection C1. 2024 [5] Node 1 receives [2] from Node 2 2026 [6:C2] Because of [5], Node 1 starts as initiator on its 2027 preferred secure channel protocol towards Node 2. 2028 Connection C2. 2030 [7:C1] Node1 and Node2 have authenticated each others 2031 certificate on connection C1 as valid ACP peers. 2033 [8:C1] Node 1 certificate has lower ACP Node-ID than Node2, 2034 therefore Node 1 considers itself Bob and Node 2 Alice 2035 on connection C1. Connection setup C1 is completed. 2037 [9] Node 1 (Bob)) refrains from attempting any further secure 2038 channel connections to Node 2 (Alice) as learned from [2] 2039 because it knows from [8:C1] that it is Bob relative 2040 to Node 1. 2042 [10:C2] Node1 and Node2 have authenticated each others 2043 certificate on connection C2 (like [7:C1]). 2045 [11:C2] Node 1 certificate has lower ACP Node-ID than Node2, 2046 therefore Node 1 considers itself Bob and Node 2 Alice 2047 on connection C1, but they also identify that C2 is to the 2048 same mutual peer as their C1, so this has no further impact. 2050 [12:C2] Node 1 (Alice) closes C1. Because of [8:C1], Node 2 (Bob) 2051 expected this. 2053 [13] Node 1 (Alice) and Node 2 (Bob) start data transfer across 2054 C2, which makes it become a secure channel for the ACP. 2056 Figure 7: Secure Channel sequence of steps 2058 All this negotiation is in the context of an "L2 interface". Alice 2059 and Bob will build ACP connections to each other on every "L2 2060 interface" that they both connect to. An autonomic node MUST NOT 2061 assume that neighbors with the same L2 or link-local IPv6 addresses 2062 on different L2 interfaces are the same node. This can only be 2063 determined after examining the certificate after a successful 2064 security association attempt. 2066 6.6. Candidate ACP Neighbor verification 2068 Independent of the security association protocol chosen, candidate 2069 ACP neighbors need to be authenticated based on their domain 2070 certificate. This implies that any secure channel protocol MUST 2071 support certificate based authentication that can support the ACP 2072 domain membership check as defined in Section 6.1.3. If it fails, 2073 the connection attempt is aborted and an error logged. Attempts to 2074 reconnect MUST be throttled. The RECOMMENDED default is exponential 2075 base 2 backoff with a minimum delay of 10 seconds and a maximum delay 2076 of 640 seconds. 2078 6.7. Security Association (Secure Channel) protocols 2080 This section describes how ACP nodes establish secured data 2081 connections to automatically discovered or configured peers in the 2082 ACP. Section 6.3 above described how IPv6 subnet adjacent peers are 2083 discovered automatically. Section 8.2 describes how non IPv6 subnet 2084 adjacent peers can be configured. 2086 Section 6.12.5.2 describes how secure channels are mapped to virtual 2087 IPv6 subnet interfaces in the ACP. The simple case is to map every 2088 ACP secure channel into a separate ACP point-to-point virtual 2089 interface Section 6.12.5.2.1. When a single subnet has multiple ACP 2090 peers this results in multiple ACP point-to-point virtual interfaces 2091 across that underlying multi-party IPv6 subnet. This can be 2092 optimized with ACP multi-access virtual interfaces Section 6.12.5.2.2 2093 but the benefits of that optimization may not justify the complexity 2094 of that option. 2096 6.7.1. General considerations 2098 Due to Channel Selection (Section 6.5), ACP can support an evolving 2099 set of security association protocols. These protocols only need to 2100 be used to establish secure channels with L2 adjacent ACP neighbors 2101 and only optionally (where needed) across non-ACP capable L3 network 2102 (see Section 8.2). Therefore, there is architecturally no need for 2103 any network wide MTI security association protocols. Instead, ACP 2104 nodes only need to implement those protocols required to interoperate 2105 with their candidate peers, not with potentially any node in the ACP 2106 domain. See Section 6.7.5 for an example of this. 2108 The degree of security required on every hop of an ACP network needs 2109 to be consistent across the network so that there is no designated 2110 "weakest link" because it is that "weakest link" that would otherwise 2111 become the designated point of attack. When the secure channel 2112 protection on one link is compromised, it can be used to send/receive 2113 packets across the whole ACP network. Therefore, even though the 2114 security association protocols can be different, their minimum degree 2115 of security should be comparable. 2117 Secure channel protocols do not need to always support arbitrary L3 2118 connectivity between peers, but can leverage the fact that the 2119 standard use case for ACP secure channels is an L2 adjacency. Hence, 2120 L2 mechanism dependent mechanisms could be adopted for use as secure 2121 channel association protocols: 2123 L2 mechanisms such as strong encrypted radio technologies or [MACSEC] 2124 may offer equivalent encryption and the ACP security association 2125 protocol may only be required to authenticate ACP domain membership 2126 of a peer and/or derive a key for the L2 mechanism. Mechanisms to 2127 auto-discover and associate ACP peers leveraging such underlying L2 2128 security are possible and desirable to avoid duplication of 2129 encryption, but none are specified in this document. 2131 Strong physical security of a link may stand in where cryptographic 2132 security is infeasible. As there is no secure mechanism to 2133 automatically discover strong physical security solely between two 2134 peers, it can only be used with explicit configuration and that 2135 configuration too could become an attack vector. This document 2136 therefore only specifies with ACP connect (Figure 15) one explicitly 2137 configured mechanism without any secure channel association protocol 2138 - for the case where both the link and the nodes attached to it have 2139 strong physical security. 2141 6.7.2. Common requirements 2143 The authentication of peers in any security association protocol MUST 2144 use the ACP domain certificate according to Section 6.1.3. Because 2145 auto-discovery of candidate ACP neighbors via GRASP (see Section 6.3) 2146 as specified in this document does not communicate the neighbors ACP 2147 domain certificate, and ACP nodes may not (yet) have any other 2148 network connectivity to retrieve certificates, any security 2149 association protocol MUST use a mechanism to communicate the 2150 certificate directly instead of relying on a referential mechanism 2151 such as communicating only a hash and/or URL for the certificate. 2153 A security association protocol MUST use Forward Secrecy (whether 2154 inherently or as part of a profile of the security association 2155 protocol). 2157 Because the ACP payload of legacy protocol payloads inside the ACP 2158 and hop-by-hop ACP flooded GRASP information is unencrypted, the ACP 2159 secure channel protocol requires confidentiality. Symmetric 2160 encryption for the transmission of secure channel data MUST use 2161 encryption schemes considered to be security wise equal to or better 2162 than AES256. There MUST NOT be support for NULL encryption. 2164 An ACP secure channel MUST immediately be terminated when the 2165 lifetime of any certificate in the chain used to authenticate the 2166 neighbor expires or becomes revoked. This may not be standard 2167 behavior in secure channel protocols because the certificate 2168 authentication may only influences the setup of the secure channel in 2169 these protocols, but may not be re-validated during the lifetime of 2170 the secure connection in the absence of this requirement. 2172 When introducing the profile for a security association protocol in 2173 support of the ACP, protocol options SHOULD be eliminated that do not 2174 provide benefits for devices that should be able to support the ACP. 2175 For example, definitions for security protocols often include old/ 2176 inferior security options required only to interoperate with existing 2177 devices that will not be a able to update to the currently preferred 2178 security options. Such old/inferior security options do not need to 2179 be supported when a security association protocol is first specified 2180 for the ACP, strengthening the "weakest link" and simplifying ACP 2181 implementation overhead. 2183 6.7.3. ACP via IPsec 2185 An ACP node announces its ability to support IPsec, negotiated via 2186 IKEv2, as the ACP secure channel protocol using the "IKEv2" 2187 objective-value in the "AN_ACP" GRASP objective. 2189 The ACP usage of IPsec and IKEv2 mandates a narrow profile of the 2190 current standards-track usage guidance for IPsec [RFC8221] and IKEv2 2191 [RFC8247]. This profile provides for stringent security properties 2192 and can exclude deprecated/legacy algorithms because there is no need 2193 for interoperability with legacy equipment for ACP secure channels. 2194 Any such backward compatibility would lead only to increased attack 2195 surface and implementation complexity, for no benefit. 2197 6.7.3.1. Native IPsec 2199 An ACP node that is supporting native IPsec MUST use IPsec in tunnel 2200 mode, negotiated via IKEv2, and with IPv6 payload (e.g., ESP Next 2201 Header of 41). It MUST use local and peer link-local IPv6 addresses 2202 for encapsulation. Manual keying MUST NOT be used, see Section 6.1. 2204 IPsec tunnel mode is required because the ACP will route/forward 2205 packets received from any other ACP node across the ACP secure 2206 channels, and not only its own generated ACP packets. With IPsec 2207 transport mode, it would only be possible to send packets originated 2208 by the ACP node itself. 2210 6.7.3.1.1. RFC8221 (IPsec/ESP) 2212 ACP IPsec implementations MUST comply with [RFC8221] (and its 2213 updates). The requirements from above and this section amend and 2214 superceed its requirements. 2216 AH MUST NOT be used (because it does not provide confidentiality). 2218 For the required ESP encryption algorithms in section 5 of [RFC8221] 2219 the following guidance applies: 2221 o ENCR_NULL AH MUST NOT be used (because it does not provide 2222 confidentiality). 2224 o ENCR_AES_GCM_16 is the only MTI ESP encryption algorithm for ACP 2225 via IPsec/ESP (it is already listed as MUST in [RFC8221]). 2227 o ENCR_AES_CBC and ENCR_AES_CCM_8 MAY be supported. If either 2228 provides higher performance than ENCR_AES_GCM_16 it SHOULD be 2229 supported. 2231 o ENCR_CHACHA20_POLY1305 SHOULD be supported at equal or higher 2232 performance than ENCR_AES_GCM_16. If that performance is not 2233 feasible, it MAY be supported. 2235 IKEv2 indicates an order for the offered algorithms. The algorithms 2236 SHOULD be ordered by performance. The first algorithm supported by 2237 both sides is generally choosen. 2239 Explanations: 2241 o There is no requirement to interoperate with legacy equipment in 2242 ACP secure channels, so a single MTI encryption algorithm for 2243 IPsec in ACP secure channels is sufficient for interoperability 2244 and allows for the most lightweight implementations. 2246 o ENCR_AES_GCM_16 is an authenticated encryption with associated 2247 data (AEAD) cipher mode, so no additional ESP authentication 2248 algorithm is needed, simplifying the MTI requirements of IPsec for 2249 the ACP. 2251 o There is no MTI requirement against support of ENCR_AES_CBC 2252 because ENCR_AES_GCM_16 is assumed to be feasible with less cost/ 2253 higher performance in modern devices hardware accelerated 2254 implementations compared to ENCR-AES_CBC. 2256 o ENCR_CHACHA20_POLY1305 is mandatory in [RFC8221] because of its 2257 target use as a fallback algorithm in case weaknesses in AES are 2258 uncoverered. Unfortunately, there is currently no way to 2259 automatically propagate across an ACP a policy to disallow use of 2260 AES based algorithms, so this target benefit of 2261 ENCR_CHACHA20_POLY1305 can not fully be adopted yet for the ACP. 2262 Therefore this algorithm is only recommended. Changing from AES 2263 to this algorithm at potentially big drop in performance could 2264 also render the ACP inoperable. Therefore the performance 2265 requirement against this algorithm so that it could become an 2266 effective security backup to AES for the ACP once a policy to 2267 switch over to it or prefer it is available in an ACP framework. 2269 [RFC8221] allows for 128-bit or 256-bit AES keys. This document 2270 mandates that only 256-bit AES keys MUST be supported. 2272 When [RFC8221] is updated, ACP implementations will need to consider 2273 legacy interoperability, and the IPsec WG has generally done a very 2274 good job of taking that into account in its recommendations. 2276 6.7.3.1.2. RFC847 (IKEv2) 2278 [RFC8247] provides a baseline recommendation for mandatory to 2279 implement ciphers, integrity checks, pseudo-random-functions and 2280 Diffie-Hellman mechanisms. Those recommendations, and the 2281 recommendations of subsequent documents apply well to the ACP. 2282 Because IKEv2 for ACP secure channels is sufficient to be implemented 2283 in control plane software, rather than in ASIC hardware, and ACP 2284 nodes supporting IKEv2 are not assumed to be code-space constrained, 2285 and because existing IKEv2 implementations are expected to support 2286 [RFC8247] recommendations, this documents makes no attempt to 2287 simplify its recommendations for use with the ACP. 2289 This document does establish a policy statement as permitted by 2290 [RFC8247] for the specific case of ACP traffic. 2292 The IKEv2 Diffie-Hellman key exchange group 19 (256-bit random ECP), 2293 listed as a SHOULD, is to be configured, along with the 2048-bit MODP 2294 (group 14). ECC provides a similar security level to finite-field 2295 (MODP) key exchange with a shorter key length, so is generally 2296 preferred absent other considerations. 2298 IKEv2 authentication MUST use the ACP domain certificates. The 2299 Certificate Encoding "PKCS #7 wrapped X.509 certificate" (1) MUST be 2300 supported. See [IKEV2IANA] for this and other IANA IKEv2 parameter 2301 names used in this text. 2303 A certificate payload with the ACP certificate MUST be included 2304 during IKEv2 authentication to support the ACP domain membership 2305 check as described in Section 6.1.3, because it is using additional 2306 elements of the ACP certificates. 2308 If certificate chains are used, all intermediate certificates up to, 2309 and including the locally provisioned trust anchor certificate MUST 2310 be signaled. See Section 6.10.7 for the sub-CA example in which 2311 certificate chains are used. 2313 While the top-trust anchor will never be used by an ACP peer with 2314 proper provisioned ACP TAs, it can provide a significant amount of 2315 useful information to debug an ACP network. There is some small 2316 concern that this might provide useful information to an attacker 2317 about who the network is, but the other certificates that are sent 2318 already clearly indicate this information. 2320 In IKEv2, ACP nodes are identified by their ACP address. The 2321 ID_IPv6_ADDR IKEv2 identification payload MUST be used and MUST 2322 convey the ACP address. If the peer's ACP domain certificate 2323 includes an ACP address in the ACP domain information field (not "0" 2324 or empty), the address in the IKEv2 identification payload MUST match 2325 it. See Section 6.1.3 for more information about "0" or empty ACP 2326 address fields in the ACP domain information field. 2328 IKEv2 authentication MUST use authentication method 14 ("Digital 2329 Signature") for ACP certificates; this authentication method can be 2330 used with both RSA and ECDSA certificates, as indicated by a PKIX- 2331 style OID. 2333 The Digital Signature hash SHA2-512 MUST be supported (in addition to 2334 SHA2-256). 2336 6.7.3.2. IPsec with GRE encapsulation 2338 In network devices it is often more common to implement high 2339 performance virtual interfaces on top of GRE encapsulation than on 2340 top of a "native" IPsec association (without any other encapsulation 2341 than those defined by IPsec). On those devices it may be beneficial 2342 to run the ACP secure channel on top of GRE protected by the IPsec 2343 association. 2345 The requirements for ESP/IPsec/IKEv2 are the same as for native IPsec 2346 (see Section 6.7.3.1) except that IPsec transport mode and next 2347 protocol GRE (47) are to be negotiated. Tunnel mode is not required 2348 because of GRE. 2350 If IKEv2 initiator and responder support IPsec over GRE, it has to be 2351 preferred over native IPsec. The ACP IPv6 traffic has to be carried 2352 across GRE according to [RFC7676]. 2354 6.7.4. ACP via DTLS 2356 We define the use of ACP via DTLS in the assumption that it is likely 2357 the first transport encryption supported in some classes of 2358 constrained devices because DTLS is already used in those devices but 2359 IPsec is not, and code-space may be limited. 2361 An ACP node announces its ability to support DTLS v1.2 compliant with 2362 the requirements defined in this document as an ACP secure channel 2363 protocol in GRASP through the "DTLS" objective-value in the "AN_ACP" 2364 objective. 2366 To run ACP via UDP and DTLS v1.2 [RFC6347], a locally assigned UDP 2367 port is used that is announced as a parameter in the GRASP AN_ACP 2368 objective to candidate neighbors. This port can also be any newer 2369 version of DTLS as long as that version can negotiate a DTLS v1.2 2370 connection in the presence of an DTLS v1.2 only peer. 2372 All ACP nodes supporting DTLS as a secure channel protocol MUST 2373 adhere to the DTLS implementation recommendations and security 2374 considerations of BCP 195 [RFC7525] except with respect to the DTLS 2375 version. ACP nodes supporting DTLS MUST support DTLS 1.2. They MUST 2376 NOT support older versions of DTLS. Implementation MUST comply with 2377 BCP 195, [RFC7525]. 2379 Unlike for IPsec, no attempts are made to simplify the requirements 2380 of the BCP 195 recommendations because the expectation is that DTLS 2381 would be using software-only implementations where the ability to 2382 reuse of widely adopted implementations is more important than 2383 minizing the complexity of a hardware accelerated implementation 2384 which is known to be important for IPsec. 2386 DTLS v1.3 ([I-D.ietf-tls-dtls13]) is "backward compatible" with DTLS 2387 v1.2 (see section 1. of DTLS v1.3): A DTLS implementation supporting 2388 both DTLS v1.2 and DTLS v1.3 does comply with the above requirements 2389 of negoting to DTLS v1.2 in the presence of a DTLS v1.2 only peer, 2390 but using DTLS v1.3 when booth peers support it. 2392 Version v1.2 is the MTI version of DTLS in this specification because 2394 o There is more experience with DTLS v1.2 across the spectrum of 2395 target ACP nodes. 2397 o Firmware of lower end, embedded ACP nodes may not support a newer 2398 version for a long time. 2400 o There are significant changes of DTLS v1.3, such as a different 2401 record layer requiring time to gain implementation and deployment 2402 experience especially on lower end, code space limited devices. 2404 o The existing BCP [RFC7525] for DTLS v1.2 may equally take longer 2405 time to be updated with experience from a newer DTLS version. 2407 o There are no significant use-case relevant benefits of DTLS v1.3 2408 over DTLS v1.2 in the context of the ACP profile for DTLS. For 2409 example, signaling performance improvements for session setup in 2410 DTLS v1.3 is not important for the ACP given the long-lived nature 2411 of ACP secure channel connections and the fact that DTLS 2412 connections are mostly link-local (short RTT). 2414 Nevertheless, newer versions of DTLS, such as DTLS v1.3 have more 2415 strict security requirements and use of the latest standard protocol 2416 version is for IETF security standards in general recommended. 2417 Therefore, ACP implementations are advised to support all the newer 2418 versions of DTLS that can still negotiate down to DTLS v1.2. 2420 [RFC-editor: if by the time of AUTH48, DTLS 1.3 would have evolved to 2421 be an RFC, then not only would the references to the DTLS v1.3 draft 2422 be changed to the RFC number, but that RFC is then going to be put 2423 into the normative list of references and the above paragraph is 2424 going to be amended to say: Implementations SHOULD support 2425 [DTLSv1.3-RFC]. This is not done right now, because there is no 2426 benefit in potentially waiting in RFC-editor queue for that RFC given 2427 how the text alreayd lays out a non-nrmative desire to support 2428 DTLSv1.3.] 2430 There is no additional session setup or other security association 2431 besides this simple DTLS setup. As soon as the DTLS session is 2432 functional, the ACP peers will exchange ACP IPv6 packets as the 2433 payload of the DTLS transport connection. Any DTLS defined security 2434 association mechanisms such as re-keying are used as they would be 2435 for any transport application relying solely on DTLS. 2437 6.7.5. ACP Secure Channel Profiles 2439 As explained in the beginning of Section 6.5, there is no single 2440 secure channel mechanism mandated for all ACP nodes. Instead, this 2441 section defines two ACP profiles (baseline and constrained) for ACP 2442 nodes that do introduce such requirements. 2444 A baseline ACP node MUST support IPsec natively and MAY support IPsec 2445 via GRE. A constrained ACP node that cannot support IPsec MUST 2446 support DTLS. An ACP node connecting an area of constrained ACP 2447 nodes with an area of baseline ACP nodes needs to support IPsec and 2448 DTLS and supports therefore the baseline and constrained profile. 2450 Explanation: Not all type of ACP nodes can or need to connect 2451 directly to each other or are able to support or prefer all possible 2452 secure channel mechanisms. For example, code space limited IoT 2453 devices may only support DTLS because that code exists already on 2454 them for end-to-end security, but high-end core routers may not want 2455 to support DTLS because they can perform IPsec in accelerated 2456 hardware but would need to support DTLS in an underpowered CPU 2457 forwarding path shared with critical control plane operations. This 2458 is not a deployment issue for a single ACP across these type of nodes 2459 as long as there are also appropriate gateway ACP nodes that support 2460 sufficiently many secure channel mechanisms to allow interconnecting 2461 areas of ACP nodes with a more constrained set of secure channel 2462 protocols. On the edge between IoT areas and high-end core networks, 2463 general-purpose routers that act as those gateways and that can 2464 support a variety of secure channel protocols is the norm already. 2466 ACP nodes need to specify in documentation the set of secure ACP 2467 mechanisms they support and should declare which profile they support 2468 according to above requirements. 2470 6.8. GRASP in the ACP 2472 6.8.1. GRASP as a core service of the ACP 2474 The ACP MUST run an instance of GRASP inside of it. It is a key part 2475 of the ACP services. The function in GRASP that makes it fundamental 2476 as a service of the ACP is the ability to provide ACP wide service 2477 discovery (using objectives in GRASP). 2479 ACP provides IP unicast routing via the RPL routing protocol (see 2480 Section 6.11). 2482 The ACP does not use IP multicast routing nor does it provide generic 2483 IP multicast services (the handling of GRASP link-local multicast 2484 messages is explained in Section 6.8.2). Instead, the ACP provides 2485 service discovery via the objective discovery/announcement and 2486 negotiation mechanisms of the ACP GRASP instance (services are a form 2487 of objectives). These mechanisms use hop-by-hop reliable flooding of 2488 GRASP messages for both service discovery (GRASP M_DISCOVERY 2489 messages) and service announcement (GRASP M_FLOOD messages). 2491 See Appendix A.5 for discussion about this design choice of the ACP. 2493 6.8.2. ACP as the Security and Transport substrate for GRASP 2495 In the terminology of GRASP ([I-D.ietf-anima-grasp]), the ACP is the 2496 security and transport substrate for the GRASP instance run inside 2497 the ACP ("ACP GRASP"). 2499 This means that the ACP is responsible for ensuring that this 2500 instance of GRASP is only sending messages across the ACP GRASP 2501 virtual interfaces. Whenever the ACP adds or deletes such an 2502 interface because of new ACP secure channels or loss thereof, the ACP 2503 needs to indicate this to the ACP instance of GRASP. The ACP exists 2504 also in the absence of any active ACP neighbors. It is created when 2505 the node has a domain certificate, and continues to exist even if all 2506 of its neighbors cease operation. 2508 In this case ASAs using GRASP running on the same node would still 2509 need to be able to discover each other's objectives. When the ACP 2510 does not exist, ASAs leveraging the ACP instance of GRASP via APIs 2511 MUST still be able to operate, and MUST be able to understand that 2512 there is no ACP and that therefore the ACP instance of GRASP cannot 2513 operate. 2515 The following explanation how ACP acts as the security and transport 2516 substrate for GRASP is visualized in Figure 8 below. 2518 GRASP unicast messages inside the ACP always use the ACP address. 2519 Link-local addresses from the ACP VRF MUST NOT be used inside 2520 objectives. GRASP unicast messages inside the ACP are transported 2521 via TLS which MUST comply with [RFC7525] execept that only TLS 2522 version 1.2 ([RFC5246]) is REQUIRED and TLS 1.3 ([RFC8446] is 2523 RECOMMENDED. There is no need for older version backward 2524 compatibility in the new use-case of ACP. Mutual authentication MUST 2525 use the ACP domain membership check defined in (Section 6.1.3). 2527 GRASP link-local multicast messages are targeted for a specific ACP 2528 virtual interface (as defined Section 6.12.5) but are sent by the ACP 2529 into an ACP GRASP virtual interface that is constructed from the TCP 2530 connection(s) to the IPv6 link-local neighbor address(es) on the 2531 underlying ACP virtual interface. If the ACP GRASP virtual interface 2532 has two or more neighbors, the GRASP link-local multicast messages 2533 are replicated to all neighbor TCP connections. 2535 TLS for GRASP MUST offer TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and 2536 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 and MUST NOT offer options 2537 with less than 256bit AES or less than SHA384. TLS for GRASP MUST 2538 also include the "Supported Elliptic Curves" extension, it MUST 2539 support support the NIST P-256 (secp256r1) and P-384 (secp384r1(24)) 2540 curves [RFC4492]. In addition, GRASP TLS clients SHOULD send an 2541 ec_point_formats extension with a single element, "uncompressed". 2542 For further interoperability recommendations, GRASP TLS 2543 implementations SHOULD follow [RFC7525]. 2545 TCP and TLS connections for GRASP in the ACP use the IANA assigned 2546 TCP port for GRASP (7107). Effectively the transport stack is 2547 expected to be TLS for connections from/to the ACP address (e.g., 2548 global scope address(es)) and TCP for connections from/to link-local 2549 addresses on the ACP virtual interfaces. The latter ones are only 2550 used for flooding of GRASP messages. 2552 ..............................ACP.............................. 2553 . . 2554 . /-GRASP-flooding-\ ACP GRASP instance . 2555 . / \ A 2556 . GRASP GRASP GRASP C 2557 . link-local unicast link-local P 2558 . multicast messages multicast . 2559 . messages | messages . 2560 . | | | . 2561 ............................................................... 2562 . v v v ACP security and transport . 2563 . | | | substrate for GRASP . 2564 . | | | . 2565 . | ACP GRASP | - ACP GRASP A 2566 . | Loopback | Loopback interface C 2567 . | interface | - ACP-cert auth P 2568 . | TLS | . 2569 . ACP GRASP | ACP GRASP - ACP GRASP virtual . 2570 . subnet1 | subnet2 virtual interfaces . 2571 . TCP | TCP . 2572 . | | | . 2573 ............................................................... 2574 . | | | ^^^ Users of ACP (GRASP/ASA) . 2575 . | | | ACP interfaces/addressing . 2576 . | | | . 2577 . | | | A 2578 . | ACP-Loopback Interf.| <- ACP Loopback interface C 2579 . | ACP-address | - address (global ULA) P 2580 . subnet1 | subnet2 <- ACP virtual interfaces . 2581 . link-local | link-local - link-local addresses . 2582 ............................................................... 2583 . | | | ACP VRF . 2584 . | RPL-routing | virtual routing and forwarding . 2585 . | /IP-Forwarding\ | A 2586 . | / \ | C 2587 . ACP IPv6 packets ACP IPv6 packets P 2588 . |/ \| . 2589 . IPsec/DTLS IPsec/DTLS - ACP-cert auth . 2590 ............................................................... 2591 | | Data-Plane 2592 | | 2593 | | - ACP secure channel 2594 link-local link-local - encapsulation addresses 2595 subnet1 subnet2 - Data-Plane interfaces 2596 | | 2597 ACP-Nbr1 ACP-Nbr2 2599 Figure 8: ACP as security and transport substrate for GRASP 2601 6.8.2.1. Discussion 2603 TCP encapsulation for GRASP M_DISCOVERY and M_FLOOD link local 2604 messages is used because these messages are flooded across 2605 potentially many hops to all ACP nodes and a single link with even 2606 temporary packet loss issues (e.g., WiFi/Powerline link) can reduce 2607 the probability for loss free transmission so much that applications 2608 would want to increase the frequency with which they send these 2609 messages. Such shorter periodic retransmission of datagrams would 2610 result in more traffic and processing overhead in the ACP than the 2611 hop-by-hop reliable retransmission mechanism by TCP and duplicate 2612 elimination by GRASP. 2614 TLS is mandated for GRASP non-link-local unicast because the ACP 2615 secure channel mandatory authentication and encryption protects only 2616 against attacks from the outside but not against attacks from the 2617 inside: Compromised ACP members that have (not yet) been detected and 2618 removed (e.g., via domain certificate revocation / expiry). 2620 If GRASP peer connections were to use just TCP, compromised ACP 2621 members could simply eavesdrop passively on GRASP peer connections 2622 for whom they are on-path ("Man In The Middle" - MITM) or intercept 2623 and modify them. With TLS, it is not possible to completely 2624 eliminate problems with compromised ACP members, but attacks are a 2625 lot more complex: 2627 Eavesdropping/spoofing by a compromised ACP node is still possible 2628 because in the model of the ACP and GRASP, the provider and consumer 2629 of an objective have initially no unique information (such as an 2630 identity) about the other side which would allow them to distinguish 2631 a benevolent from a compromised peer. The compromised ACP node would 2632 simply announce the objective as well, potentially filter the 2633 original objective in GRASP when it is a MITM and act as an 2634 application level proxy. This of course requires that the 2635 compromised ACP node understand the semantics of the GRASP 2636 negotiation to an extent that allows it to proxy it without being 2637 detected, but in an ACP environment this is quite likely public 2638 knowledge or even standardized. 2640 The GRASP TLS connections are run the same as any other ACP traffic 2641 through the ACP secure channels. This leads to double 2642 authentication/encryption, which has the following benefits: 2644 o Secure channel methods such as IPsec may provide protection 2645 against additional attacks, for example reset-attacks. 2647 o The secure channel method may leverage hardware acceleration and 2648 there may be little or no gain in eliminating it. 2650 o There is no different security model for ACP GRASP from other ACP 2651 traffic. Instead, there is just another layer of protection 2652 against certain attacks from the inside which is important due to 2653 the role of GRASP in the ACP. 2655 6.9. Context Separation 2657 The ACP is in a separate context from the normal Data-Plane of the 2658 node. This context includes the ACP channels' IPv6 forwarding and 2659 routing as well as any required higher layer ACP functions. 2661 In classical network system, a dedicated VRF is one logical 2662 implementation option for the ACP. If possible by the systems 2663 software architecture, separation options that minimize shared 2664 components are preferred, such as a logical container or virtual 2665 machine instance. The context for the ACP needs to be established 2666 automatically during bootstrap of a node. As much as possible it 2667 should be protected from being modified unintentionally by ("Data- 2668 Plane") configuration. 2670 Context separation improves security, because the ACP is not 2671 reachable from the Data-Plane routing or forwarding table(s). Also, 2672 configuration errors from the Data-Plane setup do not affect the ACP. 2674 6.10. Addressing inside the ACP 2676 The channels explained above typically only establish communication 2677 between two adjacent nodes. In order for communication to happen 2678 across multiple hops, the autonomic control plane requires ACP 2679 network wide valid addresses and routing. Each ACP node creates a 2680 Loopback interface with an ACP network wide unique address inside the 2681 ACP context (as explained in in Section 6.9). This address may be 2682 used also in other virtual contexts. 2684 With the algorithm introduced here, all ACP nodes in the same routing 2685 subdomain have the same /48 ULA prefix. Conversely, ULA global IDs 2686 from different domains are unlikely to clash, such that two ACP 2687 networks can be merged, as long as the policy allows that merge. See 2688 also Section 10.1 for a discussion on merging domains. 2690 Links inside the ACP only use link-local IPv6 addressing, such that 2691 each node's ACP only requires one routable virtual address. 2693 6.10.1. Fundamental Concepts of Autonomic Addressing 2695 o Usage: Autonomic addresses are exclusively used for self- 2696 management functions inside a trusted domain. They are not used 2697 for user traffic. Communications with entities outside the 2698 trusted domain use another address space, for example normally 2699 managed routable address space (called "Data-Plane" in this 2700 document). 2702 o Separation: Autonomic address space is used separately from user 2703 address space and other address realms. This supports the 2704 robustness requirement. 2706 o Loopback-only: Only ACP Loopback interfaces (and potentially those 2707 configured for "ACP connect", see Section 8.1) carry routable 2708 address(es); all other interfaces (called ACP virtual interfaces) 2709 only use IPv6 link local addresses. The usage of IPv6 link local 2710 addressing is discussed in [RFC7404]. 2712 o Use-ULA: For Loopback interfaces of ACP nodes, we use ULA with L=1 2713 (as defined in section 3.1 of [RFC4193]). Note that the random 2714 hash for ACP Loopback addresses uses the definition in 2715 Section 6.10.2 and not the one of [RFC4193] section 3.2.2. 2717 o No external connectivity: They do not provide access to the 2718 Internet. If a node requires further reaching connectivity, it 2719 should use another, traditionally managed address scheme in 2720 parallel. 2722 o Addresses in the ACP are permanent, and do not support temporary 2723 addresses as defined in [RFC4941]. 2725 o Addresses in the ACP are not considered sensitive on privacy 2726 grounds because ACP nodes are not expected to be end-user host. 2727 All ACP nodes are in one (potentially federated) administrative 2728 domain. They are assumed to be to be candidate hosts of ACP 2729 traffic amongst each other or transit thereof. There are no 2730 transit nodes less privileged to know about the identity of other 2731 hosts in the ACP. Therefore, ACP addresses do not need to be 2732 pseudo-random as discussed in [RFC7721]. Because they are not 2733 propagated to untrusted (non ACP) nodes and stay within a domain 2734 (of trust), we also consider them not to be subject to scanning 2735 attacks. 2737 The ACP is based exclusively on IPv6 addressing, for a variety of 2738 reasons: 2740 o Simplicity, reliability and scale: If other network layer 2741 protocols were supported, each would have to have its own set of 2742 security associations, routing table and process, etc. 2744 o Autonomic functions do not require IPv4: Autonomic functions and 2745 autonomic service agents are new concepts. They can be 2746 exclusively built on IPv6 from day one. There is no need for 2747 backward compatibility. 2749 o OAM protocols do not require IPv4: The ACP may carry OAM 2750 protocols. All relevant protocols (SNMP, TFTP, SSH, SCP, Radius, 2751 Diameter, ...) are available in IPv6. See also [RFC8368] for how 2752 ACP could be made to interoperate with IPv4 only OAM. 2754 6.10.2. The ACP Addressing Base Scheme 2756 The Base ULA addressing scheme for ACP nodes has the following 2757 format: 2759 8 40 2 78 2760 +--+-------------------------+------+------------------------------+ 2761 |fd| hash(routing-subdomain) | Type | (sub-scheme) | 2762 +--+-------------------------+------+------------------------------+ 2764 Figure 9: ACP Addressing Base Scheme 2766 The first 48-bits follow the ULA scheme, as defined in [RFC4193], to 2767 which a type field is added: 2769 o "fd" identifies a locally defined ULA address. 2771 o The 40-bits ULA "global ID" (term from [RFC4193]) for ACP 2772 addresses carried in the domain information field of domain 2773 certificates are the first 40-bits of the SHA256 hash of the 2774 routing subdomain from the same domain information field. In the 2775 example of Section 6.1.2, the routing subdomain is 2776 "area51.research.acp.example.com" and the 40-bits ULA "global ID" 2777 89b714f3db. 2779 o When creating a new routing-subdomain for an existing autonomic 2780 network, it MUST be ensured, that rsub is selected so the 2781 resulting hash of the routing-subdomain does not collide with the 2782 hash of any pre-existing routing-subdomains of the autonomic 2783 network. This ensures that ACP addresses created by registrars 2784 for different routing subdomains do not collide with each others. 2786 o To allow for extensibility, the fact that the ULA "global ID" is a 2787 hash of the routing subdomain SHOULD NOT be assumed by any ACP 2788 node during normal operations. The hash function is only executed 2789 during the creation of the certificate. If BRSKI is used then the 2790 BRSKI registrar will create the domain information field in 2791 response to the EST Certificate Signing Request (CSR) Attribute 2792 Request message by the pledge. 2794 o Establishing connectivity between different ACP (different acp- 2795 domain-name) is outside the scope of this specification. If it is 2796 being done through future extensions, then the rsub of all 2797 routing-subdomains across those autonomic networks need to be 2798 selected so the resulting routing-subdomain hashes do not collide. 2799 For example a large cooperation with its own private Trust Anchor 2800 may want to create different autonomic networks that initially 2801 should not be able to connect but where the option to do so should 2802 be kept open. When taking this future possibility into account, 2803 it is easy to always select rsub so that no collisions happen. 2805 o Type: This field allows different address sub-schemes. This 2806 addresses the "upgradability" requirement. Assignment of types 2807 for this field will be maintained by IANA. 2809 The sub-scheme may imply a range or set of addresses assigned to the 2810 node, this is called the ACP address range/set and explained in each 2811 sub-scheme. 2813 Please refer to Section 6.10.7 and Appendix A.1 for further 2814 explanations why the following Sub-Addressing schemes are used and 2815 why multiple are necessary. 2817 The following summarizes the addressing Sub-Schemes: 2819 +------+-----+----------------+-------+------------+ 2820 | Type | Z | name | F-bit | V-bit size | 2821 +------+-----+----------------+-------+------------+ 2822 | 0x00 | 0 | ACP Zone | N/A | 1 bit | 2823 +------+-----+----------------+-------+------------+ 2824 | 0x00 | 1 | ACP Manual | N/A | 1 bit | 2825 +------+-----+----------------+-------+------------+ 2826 | 0x01 | N/A | VLong-ASA | 0 | 8-bits | 2827 +------+-----+----------------+-------+------------+ 2828 | 0x01 | N/A | VLong-ACP-edge | 1 | 16-bits | 2829 +------+-----+----------------+-------+------------+ 2831 Figure 10: Addressing schemes 2833 6.10.3. ACP Zone Addressing Sub-Scheme 2835 This sub-scheme is used when the Type field of the base scheme is 2836 0x00 and the Z bit is 0x0. 2838 64 64 2839 +-----------------+---+---------++-----------------------------+---+ 2840 | (base scheme) | Z | Zone-ID || Node-ID | 2841 | | | || Registrar-ID | Node-Number| V | 2842 +-----------------+---+---------++--------------+--------------+---+ 2843 50 1 13 48 15 1 2845 Figure 11: ACP Zone Addressing Sub-Scheme 2847 The fields are defined as follows: 2849 o Type: MUST be 0x0. 2851 o Z: MUST be 0x0. 2853 o Zone-ID: If set to all zero bits: The Node-ID bits are used as an 2854 identifier (as opposed to a locator). This results in a non- 2855 hierarchical, flat addressing scheme. Any other value indicates a 2856 zone. See Section 6.10.3.1 on how this field is used in detail. 2858 o Node-ID: A unique value for each node. 2860 The 64-bit Node-ID is derived and composed as follows: 2862 o Registrar-ID (48-bit): A number unique inside the domain that 2863 identifies the ACP registrar which assigned the Node-ID to the 2864 node. One or more domain-wide unique identifiers of the ACP 2865 registrar can be used for this purpose. See Section 6.10.7.2. 2867 o Node-Number: A number which is unique for a given ACP registrar, 2868 to identify the node. This can be a sequentially assigned number. 2870 o V (1-bit): Virtualization bit: 0: Indicates the ACP itself ("ACP 2871 node base system); 1: Indicates the optional "host" context on the 2872 ACP node (see below). 2874 In the ACP Zone Addressing Sub-Scheme, the ACP address in the 2875 certificate has Zone-ID and V fields as all zero bits. The ACP 2876 address set includes addresses with any Zone-ID value and any V 2877 value. 2879 The "Node-ID" itself is unique in a domain (i.e., the Zone-ID is not 2880 required for uniqueness). Therefore, a node can be addressed either 2881 as part of a flat hierarchy (Zone-ID = 0), or with an aggregation 2882 scheme (any other Zone-ID). An address with Zone-ID = 0 is an 2883 identifier, with a Zone-ID !=0 it is a locator. See Section 6.10.3.1 2884 for more details. 2886 The Virtual bit in this sub-scheme allows the easy addition of the 2887 ACP as a component to existing systems without causing problems in 2888 the port number space between the services in the ACP and the 2889 existing system. V:0 is the ACP router (autonomic node base system), 2890 V:1 is the host with pre-existing transport endpoints on it that 2891 could collide with the transport endpoints used by the ACP router. 2892 The ACP host could for example have a p2p virtual interface with the 2893 V:0 address as its router into the ACP. Depending on the software 2894 design of ASAs, which is outside the scope of this specification, 2895 they may use the V:0 or V:1 address. 2897 The location of the V bit(s) at the end of the address allows the 2898 announcement of a single prefix for each ACP node. For example, in a 2899 network with 20,000 ACP nodes, this avoid 20,000 additional routes in 2900 the routing table. 2902 6.10.3.1. Usage of the Zone-ID Field 2904 The Zone-ID allows for the introduction of route prefixes in the 2905 addressing scheme. 2907 Zone-ID = 0 is the default addressing scheme in an ACP domain. Every 2908 ACP node with a Zone Addressing Sub-Scheme address MUST respond to 2909 its ACP address with Zone-ID = 0. Used on its own this leads to a 2910 non-hierarchical address scheme, which is suitable for networks up to 2911 a certain size. Zone-ID = 0 addresses act as identifiers for the 2912 nodes, and aggregation of these address in the ACP routing table is 2913 not possible. 2915 If aggregation is required, the 13-bit Zone-ID value allows for up to 2916 8191 zones. The allocation of Zone-ID's may either happen 2917 automatically through a to-be-defined algorithm; or it could be 2918 configured and maintained explicitly. 2920 If a node learns (see Appendix A.10.1) that it is part of a zone, it 2921 MUST also respond to its ACP address with that Zone-ID. In this case 2922 the ACP Loopback is configured with two ACP addresses: One for Zone- 2923 ID = 0 and one for the assigned Zone-ID. This method allows for a 2924 smooth transition between a flat addressing scheme and a hierarchical 2925 one. 2927 A node knowing it is in a zone MUST use that Zone-ID != 0 address in 2928 GRASP locator fields. This eliminates the use of the identifier 2929 address (Zone-ID = 0) in forwarding and the need for network wide 2930 reachability of those non-aggregable identifier addresses. Zone-ID 2931 != 0 addresses are assumed to be aggregable in routing/forwarding 2932 based on how they are allocated in the ACP topology. 2934 Note: The Zone-ID is one method to introduce structure or hierarchy 2935 into the ACP. Another way is the use of the routing subdomain field 2936 in the ACP that leads to multiple /48 Global IDs within an ACP 2937 domain. 2939 Note: Zones and Zone-ID as defined here are not related to [RFC4007] 2940 zones or zone_id. ACP zone addresses are not scoped (reachable only 2941 from within an RFC4007 zone) but reachable across the whole ACP. An 2942 RFC4007 zone_id is a zone index that has only local significance on a 2943 node, whereas an ACP Zone-ID is an identifier for an ACP zone that is 2944 unique across that ACP. 2946 6.10.4. ACP Manual Addressing Sub-Scheme 2948 This sub-scheme is used when the Type field of the base scheme is 2949 0x00 and the Z bit is 0x1. 2951 64 64 2952 +---------------------+---+----------++-----------------------------+ 2953 | (base scheme) | Z | Subnet-ID|| Interface Identifier | 2954 +---------------------+---+----------++-----------------------------+ 2955 50 1 13 2957 Figure 12: ACP Manual Addressing Sub-Scheme 2959 The fields are defined as follows: 2961 o Type: MUST be 0x0. 2963 o Z: MUST be 0x1. 2965 o Subnet-ID: Configured subnet identifier. 2967 o Interface Identifier. 2969 This sub-scheme is meant for "manual" allocation to subnets where the 2970 other addressing schemes cannot be used. The primary use case is for 2971 assignment to ACP connect subnets (see Section 8.1.1). 2973 "Manual" means that allocations of the Subnet-ID need to be done 2974 today with pre-existing, non-autonomic mechanisms. Every subnet that 2975 uses this addressing sub-scheme needs to use a unique Subnet-ID 2976 (unless some anycast setup is done). 2978 The Z bit field was added to distinguish Zone addressing and manual 2979 addressing sub-schemes without requiring one more bit in the base 2980 scheme and therefore allowing for the Vlong scheme (described below) 2981 to have one more bit available. 2983 Manual addressing sub-scheme addresses SHOULD NOT be used in ACP 2984 domain certificates. Any node capable to build ACP secure channels 2985 and permitted by Registrar policy to participate in building ACP 2986 secure channels SHOULD receive an ACP address (prefix) from one of 2987 the other ACP addressing sub-schemes. Nodes not capable (or 2988 permitted) to participate in ACP secure channels can connect to the 2989 ACP via ACP connect interfaces of ACP edge nodes (see Section 8.1), 2990 without setting up an ACP secure channel. Their ACP domain 2991 certificate MUST include an empty acp-address to indicate that their 2992 ACP domain certificate is only usable for non- ACP secure channel 2993 authentication, such as end-to-end transport connections across the 2994 ACP or Data-Plane. 2996 Address management of ACP connect subnets is done using traditional 2997 assignment methods and existing IPv6 protocols. See Section 8.1.3 2998 for details. 3000 6.10.5. ACP Vlong Addressing Sub-Scheme 3002 This sub-scheme is used when the Type field of the base scheme is 3003 0x01. 3005 50 78 3006 +---------------------++-----------------------------+----------+ 3007 | (base scheme) || Node-ID | 3008 | || Registrar-ID |F| Node-Number| V | 3009 +---------------------++--------------+--------------+----------+ 3010 50 46 1 23/15 8/16 3012 Figure 13: ACP Vlong Addressing Sub-Scheme 3014 This addressing scheme foregoes the Zone-ID field to allow for 3015 larger, flatter routed networks (e.g., as in IoT) with 8421376 Node- 3016 Numbers (2^23+2^15). It also allows for up to 2^16 (i.e. 65536) 3017 different virtualized addresses within a node, which could be used to 3018 address individual software components in an ACP node. 3020 The fields are the same as in the Zone-ID sub-scheme with the 3021 following refinements: 3023 o F: format bit. This bit determines the format of the subsequent 3024 bits. 3026 o V: Virtualization bit: this is a field that is either 8 or 16 3027 bits. For F=0, it is 8 bits, for F=1 it is 16 bits. The V bits 3028 are assigned by the ACP node. In the ACP certificate's ACP 3029 address Section 6.1.2, the V-bits are always set to 0. 3031 o Registrar-ID: To maximize Node-Number and V, the Registrar-ID is 3032 reduced to 46-bits. One or more domain-wide unique identifiers of 3033 the ACP registrar can be used for this purpose. See 3034 Section 6.10.7.2. 3036 o The Node-Number is unique to each ACP node. There are two formats 3037 for the Node-Number. When F=0, the node-number is 23 bits, for 3038 F=1 it is 15 bits. Each format of node-number is considered to be 3039 in a unique number space. 3041 The F=0 bit format addresses are intended to be used for "general 3042 purpose" ACP nodes that would potentially have a limited number (< 3043 256) of clients (ASA/Autonomic Functions or legacy services) of the 3044 ACP that require separate V(irtual) addresses. 3046 The F=1 bit Node-Numbers are intended for ACP nodes that are ACP edge 3047 nodes (see Section 8.1.1) or that have a large number of clients 3048 requiring separate V(irtual) addresses. For example large SDN 3049 controllers with container modular software architecture (see 3050 Section 8.1.2). 3052 In the Vlong addressing sub-scheme, the ACP address in the 3053 certificate has all V field bits as zero. The ACP address set for 3054 the node includes any V value. 3056 6.10.6. Other ACP Addressing Sub-Schemes 3058 Before further addressing sub-schemes are defined, experience with 3059 the schemes defined here should be collected. The schemes defined in 3060 this document have been devised to allow hopefully sufficiently 3061 flexible setup of ACPs for a variety of situation. These reasons 3062 also lead to the fairly liberal use of address space: The Zone 3063 Addressing Sub-Scheme is intended to enable optimized routing in 3064 large networks by reserving bits for Zone-ID's. The Vlong addressing 3065 sub-scheme enables the allocation of 8/16-bit of addresses inside 3066 individual ACP nodes. Both address spaces allow distributed, 3067 uncoordinated allocation of node addresses by reserving bits for the 3068 registrar-ID field in the address. 3070 IANA is asked need to assign a new "type" for each new addressing 3071 sub-scheme. With the current allocations, only 2 more schemes are 3072 possible, so the last addressing scheme MUST provide further 3073 extensions (e.g., by reserving bits from it for further extensions). 3075 6.10.7. ACP Registrars 3077 ACP registrars are responsible to enroll candidate ACP nodes with ACP 3078 domain certificates and associated trust point(s). They are also 3079 responsible that an ACP domain information field is included in the 3080 ACP domain certificate carrying the ACP domain name and the ACP nodes 3081 ACP address prefix. This address prefix is intended to persist 3082 unchanged through the lifetime of the ACP node. 3084 Because of the ACP addressing sub-schemes, an ACP domain can have 3085 multiple distributed ACP registrars that do not need to coordinate 3086 for address assignment. ACP registrars can also be sub-CAs, in which 3087 case they can also assign ACP domain certificates without 3088 dependencies against a (shared) root-CA (except during renewals of 3089 their own certificates). 3091 ACP registrars are PKI registration authorities (RA) enhanced with 3092 the handling of the ACP domain certificate specific fields. They 3093 request certificates for ACP nodes from a Certificate Authority 3094 through any appropriate mechanism (out of scope in this document, but 3095 required to be BRSKI for ANI registrars). Only nodes that are 3096 trusted to be compliant with the requirements against registrar 3097 described in this section can be given the necessary credentials to 3098 perform this RA function, such as credentials for the BRSKI 3099 connection to the CA for ANI registrars. 3101 6.10.7.1. Use of BRSKI or other Mechanism/Protocols 3103 Any protocols or mechanisms may be used as ACP registrars, as long as 3104 the resulting ACP certificate and trust anchors allow to perform the 3105 ACP domain membership described in Section 6.1.3 with other ACP 3106 domain members, and meet the ACP addressing requirements for its ACP 3107 domain information field as described further below in this section. 3109 An ACP registrar could be a person deciding whether to enroll a 3110 candidate ACP node and then orchestrating the enrollment of the ACP 3111 certificate and associated trust anchor, using command line or web 3112 based commands on the candidate ACP node and trust anchor to generate 3113 and sign the ACP domain certificate and configure certificate and 3114 trust anchors onto the node. 3116 The only currently defined protocol for ACP registrars is BRSKI 3117 ([I-D.ietf-anima-bootstrapping-keyinfra]). When BRSKI is used, the 3118 ACP nodes are called ANI nodes, and the ACP registrars are called 3119 BRSKI or ANI registrars. The BRSKI specification does not define the 3120 handling of the ACP domain information field because the rules do not 3121 depend on BRSKI but apply equally to any protocols/mechanisms an ACP 3122 registrar may use. 3124 6.10.7.2. Unique Address/Prefix allocation 3126 ACP registrars MUST NOT allocate ACP address prefixes to ACP nodes 3127 via the ACP domain information field that would collide with the ACP 3128 address prefixes of other ACP nodes in the same ACP domain. This 3129 includes both prefixes allocated by the same ACP registrar to 3130 different ACP nodes as well as prefixes allocated by other ACP 3131 registrars for the same ACP domain. 3133 To support such unique address allocation, an ACP registrar MUST have 3134 one or more 46-bit identifiers unique across the ACP domain which is 3135 called the Registrar-ID. Allocation of Registrar-ID(s) to an ACP 3136 registrar can happen through OAM mechanisms in conjunction with some 3137 database / allocation orchestration. 3139 ACP registrars running on physical devices with known globally unique 3140 EUI-48 MAC address(es) can use the lower 46 bits of those address(es) 3141 as unique Registrar-IDs without requiring any external signaling/ 3142 configuration (the upper two bits, V and U are not uniquely assigned 3143 but functional). This approach is attractive for distributed, non- 3144 centrally administered, lightweight ACP registrar implementations. 3145 There is no mechanism to deduce from a MAC address itself whether it 3146 is actually uniquely assigned. Implementations need to consult 3147 additional offline information before making this assumption. For 3148 example by knowing that a particular physical product/MIC-chip is 3149 guaranteed to use globally unique assigned EUI-48 MAC address(es). 3151 When the candidate ACP device (called Pledge in BRSKI) is to be 3152 enrolled into an ACP domain, the ACP registrar needs to allocate a 3153 unique ACP address to the node and ensure that the ACP certificate 3154 gets a domain information field (Section 6.1.2) with the appropriate 3155 information - ACP domain-name, ACP-address, and so on. If the ACP 3156 registrar uses BRSKI, it signals the ACP domain information field to 3157 the Pledge via the EST /csrattrs command (see 3158 [I-D.ietf-anima-bootstrapping-keyinfra], section 5.9.2 - "EST CSR 3159 Attributes"). 3161 [RFC Editor: please update reference to section 5.9.2 accordingly 3162 with latest BRSKI draft at time of publishing, or RFC] 3164 6.10.7.3. Addressing Sub-Scheme Policies 3166 The ACP registrar selects for the candidate ACP node a unique address 3167 prefix from an appropriate ACP addressing sub-scheme, either a zone 3168 addressing sub-scheme prefix (see Section 6.10.3), or a Vlong 3169 addressing sub-scheme prefix (see Section 6.10.5). The assigned ACP 3170 address prefix encoded in the domain information field of the ACP 3171 domain certificate indicates to the ACP node its ACP address 3172 information. The sub-addressing scheme indicates the prefix length: 3173 /127 for zone address sub-scheme, /120 or /112 for Vlong address sub- 3174 scheme. The first address of the prefix is the ACP address. All 3175 other addresses in the prefix are for other uses by the ACP node as 3176 described in the zone and Vlong addressing sub scheme sections. The 3177 ACP address prefix itself is then signaled by the ACP node into the 3178 ACP routing protocol (see Section 6.11) to establish IPv6 3179 reachability across the ACP. 3181 The choice of addressing sub-scheme and prefix-length in the Vlong 3182 address sub-scheme is subject to ACP registrar policy. It could be 3183 an ACP domain wide policy, or a per ACP node or per ACP node type 3184 policy. For example, in BRSKI, the ACP registrar is aware of the 3185 IDevID of the candidate ACP node, which contains a "serialNnumber" 3186 that is typically indicating the node's vendor and device type and 3187 can be used to drive a policy selecting an appropriate addressing 3188 sub-scheme for the (class of) node(s). 3190 ACP registrars SHOULD default to allocate ACP zone sub-address scheme 3191 addresses with Zone-ID 0. Allocation and use of zone sub-addresses 3192 with Zone-ID != 0 is outside the scope of this specification because 3193 it would need to go along with rules for extending ACP routing to 3194 multiple zones, which is outside the scope of this specification. 3196 ACP registrars that are aware of can use the IDevID of a candidate 3197 ACP device SHOULD be able to choose the zone vs. Vlong sub-address 3198 scheme for ACP nodes based on the "serialNumber" of the IDevID, for 3199 example by the PID (Product Identifier) part which identifies the 3200 product type, or the complete "serialNumber". 3202 In a simple allocation scheme, an ACP registrar remembers 3203 persistently across reboots its currently used Registrar-ID and for 3204 each addressing scheme (zone with Zone-ID 0, Vlong with /112, Vlong 3205 with /120), the next Node-Number available for allocation and 3206 increases it during successful enrollment to an ACP node. In this 3207 simple allocation scheme, the ACP registrar would not recycle ACP 3208 address prefixes from no longer used ACP nodes. 3210 6.10.7.4. Address/Prefix Persistence 3212 When an ACP domain certificate is renewed or rekeyed via EST or other 3213 mechanisms, the ACP address/prefix in the ACP domain information 3214 field MUST be maintained unless security issues or violations of the 3215 unique address assignment requirements exist or are suspected by the 3216 ACP registrar. 3218 ACP address information SHOULD be maintained even when the renewing/ 3219 rekeying ACP registrar is not the same as the one that enrolled the 3220 prior ACP certificate. See Section 9.2.4 for an example. 3222 ACP address information SHOULD also be maintained even after an ACP 3223 certificate did expire or failed. See Section 6.1.5.5 and 3224 Section 6.1.5.6. 3226 6.10.7.5. Further Details 3228 Section 9.2 discusses further informative details of ACP registrars: 3229 What interactions registrars need, what parameters they require, 3230 certificate renewal and limitations, use of sub-CAs on registrars and 3231 centralized policy control. 3233 6.11. Routing in the ACP 3235 Once ULA address are set up all autonomic entities should run a 3236 routing protocol within the autonomic control plane context. This 3237 routing protocol distributes the ULA created in the previous section 3238 for reachability. The use of the autonomic control plane specific 3239 context eliminates the probable clash with Data-Plane routing tables 3240 and also secures the ACP from interference from the configuration 3241 mismatch or incorrect routing updates. 3243 The establishment of the routing plane and its parameters are 3244 automatic and strictly within the confines of the autonomic control 3245 plane. Therefore, no explicit configuration is required. 3247 All routing updates are automatically secured in transit as the 3248 channels of the ACP are encrypted, and this routing runs only inside 3249 the ACP. 3251 The routing protocol inside the ACP is RPL ([RFC6550]). See 3252 Appendix A.4 for more details on the choice of RPL. 3254 RPL adjacencies are set up across all ACP channels in the same domain 3255 including all its routing subdomains. See Appendix A.7 for more 3256 details. 3258 6.11.1. RPL Profile 3260 The following is a description of the RPL profile that ACP nodes need 3261 to support by default. The format of this section is derived from 3262 draft-ietf-roll-applicability-template. 3264 6.11.1.1. Overview 3266 The choosen RPL profile is one that expects a fairly reliable network 3267 with reasonably fast links so that RPL convergence will be triggered 3268 immediately upon recognition of link failure/recovery. 3270 The profile is also designed to not require any RPL Data-Plane 3271 artifacts (such as defined in [RFC6553]). This is largely driven by 3272 the desire to avoid introducing the required Hop-by-Hop headers into 3273 the ACP forwarding plane, especially to support devices with silicon 3274 forwarding planes that cannot support insertion/removal of these 3275 headers in silicon or hop-by-hop forwarding based on them. Note: 3276 Insertion/removal of headers by a (potentially silicon based) ACP 3277 node would be be necessary when senders/receivers of ACP packets are 3278 legacy NOC devices connected via ACP connect (see Section 8.1.1 to 3279 the ACP. Their connectivity can be handled in RPL as non-RPL-aware 3280 leafs (or "Internet") according to the Data-Plane architecture 3281 explained in [I-D.ietf-roll-useofrplinfo]. 3283 This RPL profile avoids the use of Data-Plane artefacts (RPL data 3284 packet headers, see Section 6.11.1.13), because hardware accelerated 3285 forwarding planes most likely can not support them today. To achieve 3286 this, the profile uses a simple destination prefix based routing/ 3287 forwarding table. To achieve this, the profiles uses only one RPL 3288 instanceID. This single instanceID can contain only one Destination 3289 Oriented Directed Acyclic Graph (DODAG), and the routing/forwarding 3290 table can therefore only calculate a single class of service ("best 3291 effort towards the primary NOC/root") and cannot create optimized 3292 routing paths to accomplish latency or energy goals between any two 3293 nodes. 3295 Consider a network that has multiple NOCs in different locations. 3296 Only one NOC will become the DODAG root. Traffic to and from other 3297 NOCs has to be sent through the DODAG (shortest path tree) rooted in 3298 the primary NOC. Depending on topology, this can be an annoyance 3299 from a latency point of view or from minimizing network path 3300 resources, but this is deemed to be acceptable given how ACP traffic 3301 is "only" network management/control traffic. 3303 Using a single instanceID/DODAG does not introduce a single point of 3304 failure, as the DODAG will reconfigure itself when it detects data- 3305 plane forwarding failures including choosing a different root when 3306 the primary one fails. See Appendix A.10.4 for more details. 3308 The benefit of this profile, especially compared to other IGPs is 3309 that it does not calculate routes for node reachable through the same 3310 interface as the DODAG root. This RPL profile can therefore scale to 3311 much larger number of ACP nodes in the same amount of compute and 3312 memory than other routing protocols. Especially on nodes that are 3313 leafs of the topology or those close to those leafs. 3315 The lack of RPL Packet Information (see Section 6.11.1.13), means 3316 that the Data-Plane will have no rank value that can be used to 3317 detect loops. As a result, traffic may loop until the time-to-live 3318 (TTL) of the packet reaches zero. This is the same behavior as that 3319 of other IGPs that do not have the Data-Plane options of RPL. 3321 Since links in the ACP are assumed to be mostly reliable (or have 3322 link layer protection against loss) and because there is no stretch 3323 according to Section 6.11.1.7, loops caused by RPL routing packet 3324 loss should be exceedingly rare. 3326 There are a variety of mechanisms possible in RPL to further avoid 3327 temporary loops: DODAG Information Objects (DIOs) SHOULD be sent 3328 2...3 times to inform children when losing the last parent. The 3329 technique in [RFC6550] section 8.2.2.6. (Detaching) SHOULD be 3330 favored over that in section 8.2.2.5., (Poisoning) because it allows 3331 local connectivity. Nodes SHOULD select more than one parent, at 3332 least 3 if possible, and send Destination Advertisement Objects 3333 (DAO)s to all of them in parallel. 3335 Additionally, failed ACP tunnels can be quickly discovered trough the 3336 secure channel protocol mechanisms such as IKEv2 Dead Peer Detection. 3337 This can function as a replacement for a Low-power and Lossy 3338 Networks' (LLN's) Expected Transmission Count (ETX) feature that is 3339 not used in this profile. A failure of an ACP tunnel should 3340 imediately signal the RPL control plane to pick a different parent. 3342 6.11.1.2. RPL Instances 3344 Single RPL instance. Default RPLInstanceID = 0. 3346 6.11.1.3. Storing vs. Non-Storing Mode 3348 RPL Mode of Operations (MOP): MUST support mode 2 - "Storing Mode of 3349 Operations with no multicast support". Implementations MAY support 3350 mode 3 ("... with multicast support" as that is a superset of mode 3351 2). Note: Root indicates mode in DIO flow. 3353 6.11.1.4. DAO Policy 3355 Proactive, aggressive DAO state maintenance: 3357 o Use K-flag in unsolicited DAO indicating change from previous 3358 information (to require DAO-ACK). 3360 o Retry such DAO DAO-RETRIES(3) times with DAO- ACK_TIME_OUT(256ms) 3361 in between. 3363 6.11.1.5. Path Metric 3365 Hopcount. 3367 6.11.1.6. Objective Function 3369 Objective Function (OF): Use OF0 [RFC6552]. No use of metric 3370 containers. 3372 rank_factor: Derived from link speed: <= 100Mbps: 3373 LOW_SPEED_FACTOR(5), else HIGH_SPEED_FACTOR(1) 3375 6.11.1.7. DODAG Repair 3377 Global Repair: we assume stable links and ranks (metrics), so no need 3378 to periodically rebuild DODAG. DODAG version only incremented under 3379 catastrophic events (e.g., administrative action). 3381 Local Repair: As soon as link breakage is detected, send No-Path DAO 3382 for all the targets that were reachable only via this link. As soon 3383 as link repair is detected, validate if this link provides you a 3384 better parent. If so, compute your new rank, and send new DIO that 3385 advertises your new rank. Then send a DAO with a new path sequence 3386 about yourself. 3388 stretch_rank: none provided ("not stretched"). 3390 Data Path Validation: Not used. 3392 Trickle: Not used. 3394 6.11.1.8. Multicast 3396 Not used yet but possible because of the selected mode of operations. 3398 6.11.1.9. Security 3400 [RFC6550] security not used, substituted by ACP security. 3402 Because the ACP links already include provisions for confidentiality 3403 and integrity protection, their usage at the RPL layer would be 3404 redundant, and so RPL security is not used. 3406 6.11.1.10. P2P communications 3408 Not used. 3410 6.11.1.11. IPv6 address configuration 3412 Every ACP node (RPL node) announces an IPv6 prefix covering the 3413 address(es) used in the ACP node. The prefix length depends on the 3414 chosen addressing sub-scheme of the ACP address provisioned into the 3415 certificate of the ACP node, e.g., /127 for Zone Addressing Sub- 3416 Scheme or /112 or /120 for Vlong addressing sub-scheme. See 3417 Section 6.10 for more details. 3419 Every ACP node MUST install a black hole (aka null) route for 3420 whatever ACP address space that it advertises (i.e.: the /96 or 3421 /127). This is avoid routing loops for addresses that an ACP node 3422 has not (yet) used. 3424 6.11.1.12. Administrative parameters 3426 Administrative Preference ([RFC6550], 3.2.6 - to become root): 3427 Indicated in DODAGPreference field of DIO message. 3429 o Explicit configured "root": 0b100 3431 o ACP registrar (Default): 0b011 3433 o ACP-connect (non-registrar): 0b010 3435 o Default: 0b001. 3437 6.11.1.13. RPL Data-Plane artifacts 3439 RPL Packet Information (RPI) defined in [RFC6550], section 11.2 3440 defines the data packet artefacts required or beneficial in 3441 forwarding of those data packets when their routing information is 3442 derived from RPL. This profile does not use RPI for better 3443 compatibility with accelerated hardeware forwarding planes and 3444 achieves this for the following reasons. 3446 One RPI option is the RPL Source Routing Header (SRH) [RFC6554] which 3447 is not necessary in this profile because it uses storing mode where 3448 each hop has the necessary next-hop forwarding information. 3450 The simpler RPL Option header [RFC6553] is also not necessary in this 3451 profile, because it uses a single RPL instance and data path 3452 validation is also not used. 3454 6.11.1.14. Unknown Destinations 3456 Because RPL minimizes the size of the routing and forwarding table, 3457 prefixes reachable through the same interface as the RPL root are not 3458 known on every ACP node. Therefore traffic to unknown destination 3459 addresses can only be discovered at the RPL root. The RPL root 3460 SHOULD have attach safe mechanisms to operationally discover and log 3461 such packets. 3463 As this requirement raises additional data plane requirements, it 3464 does not apply to nodes where the administrative parameter to become 3465 root (Section 6.11.1.12) can always only be 0b001, e.g.: the node 3466 does not support explicit configuration to be root, or to be ACP 3467 registrar or to have ACP-connect functionality. If an ACP network is 3468 degraded to the point where there are no nodes that could be 3469 configured roots, ACP registrars or ACP-connect nodes, traffic to 3470 unknown destinations could not be diagnosed, but in the absence of 3471 any intelligent nodes supporting other than 0b001 administrative 3472 preference, there is likely also no diagnostic function possible. 3474 6.12. General ACP Considerations 3476 Since channels are by default established between adjacent neighbors, 3477 the resulting overlay network does hop-by-hop encryption. Each node 3478 decrypts incoming traffic from the ACP, and encrypts outgoing traffic 3479 to its neighbors in the ACP. Routing is discussed in Section 6.11. 3481 6.12.1. Performance 3483 There are no performance requirements against ACP implementations 3484 defined in this document because the performance requirements depend 3485 on the intended use case. It is expected that full autonomic node 3486 with a wide range of ASA can require high forwarding plane 3487 performance in the ACP, for example for telemetry. Implementations 3488 of ACP to solely support traditional/SDN style use cases can benefit 3489 from ACP at lower performance, especially if the ACP is used only for 3490 critical operations, e.g., when the Data-Plane is not available. The 3491 design of the ACP as specified in this document is intended to 3492 support a wide range of performance options: It is intended to allow 3493 software-only implementations at potentially low performance, but can 3494 also support high performance options. See [RFC8368] for more 3495 details. 3497 6.12.2. Addressing of Secure Channels 3499 In order to be independent of the Data-Plane routing and addressing, 3500 the GRASP discovered ACP secure channels use IPv6 link local 3501 addresses between adjacent neighbors. Note: Section 8.2 specifies 3502 extensions in which secure channels are configured tunnels operating 3503 over the Data-Plane, so those secure channels cannot be independent 3504 of the Data-Plane. 3506 To avoid that Data-Plane configuration can impact the operations of 3507 the IPv6 (link-local) interface/address used for ACP channels, 3508 appropriate implementation considerations are required. If the IPv6 3509 interface/link-local address is shared with the Data-Plane it needs 3510 to be impossible to unconfigure/disable it through configuration. 3511 Instead of sharing the IPv6 interface/link-local address, a separate 3512 (virtual) interface with a separate IPv6 link-local address can be 3513 used. For example, the ACP interface could be run over a separate 3514 MAC address of an underlying L2 (Ethernet) interface. For more 3515 details and options, see Appendix A.10.2. 3517 Note that other (non-ideal) implementation choices may introduce 3518 additional undesired dependencies against the Data-Plane. For 3519 example shared code and configuration of the secure channel protocols 3520 (IPsec / DTLS). 3522 6.12.3. MTU 3524 The MTU for ACP secure channels MUST be derived locally from the 3525 underlying link MTU minus the secure channel encapsulation overhead. 3527 ACP secure Channel protocols do not need to perform MTU discovery 3528 because they are built across L2 adjacencies - the MTU on both sides 3529 connecting to the L2 connection are assumed to be consistent. 3530 Extensions to ACP where the ACP is for example tunneled need to 3531 consider how to guarantee MTU consistency. This is an issue of 3532 tunnels, not an issue of running the ACP across a tunnel. Transport 3533 stacks running across ACP can perform normal PMTUD (Path MTU 3534 Discovery). Because the ACP is meant to be prioritize reliability 3535 over performance, they MAY opt to only expect IPv6 minimum MTU (1280) 3536 to avoid running into PMTUD implementation bugs or underlying link 3537 MTU mismatch problems. 3539 6.12.4. Multiple links between nodes 3541 If two nodes are connected via several links, the ACP SHOULD be 3542 established across every link, but it is possible to establish the 3543 ACP only on a sub-set of links. Having an ACP channel on every link 3544 has a number of advantages, for example it allows for a faster 3545 failover in case of link failure, and it reflects the physical 3546 topology more closely. Using a subset of links (for example, a 3547 single link), reduces resource consumption on the node, because state 3548 needs to be kept per ACP channel. The negotiation scheme explained 3549 in Section 6.5 allows Alice (the node with the higher ACP address) to 3550 drop all but the desired ACP channels to Bob - and Bob will not re- 3551 try to build these secure channels from his side unless Alice shows 3552 up with a previously unknown GRASP announcement (e.g., on a different 3553 link or with a different address announced in GRASP). 3555 6.12.5. ACP interfaces 3557 The ACP VRF has conceptually two type of interfaces: The "ACP 3558 Loopback interface(s)" to which the ACP ULA address(es) are assigned 3559 and the "ACP virtual interfaces" that are mapped to the ACP secure 3560 channels. 3562 6.12.5.1. ACP loopback interfaces 3564 The term "Loopback interface" was introduced initially to refer to an 3565 internal interface on a node that would allow IP traffic between 3566 transport endpoints on the node in the absence or failure of any or 3567 all external interfaces, see [RFC4291] section 2.5.3. 3569 Even though Loopback interfaces were originally designed to hold only 3570 Loopback addresses not reachable from outside the node, these 3571 interfaces are also commonly used today to hold addresses reachable 3572 from the outside. They are meant to be reachable independent of any 3573 external interface being operational, and therefore to be more 3574 resilient. These addresses on Loopback interfaces can be thought of 3575 as "node addresses" instead of "interface addresses", and that is 3576 what ACP address(es) are. This construct makes it therefore possible 3577 to address ACP nodes with a well-defined set of addresses independent 3578 of the number of external interfaces. 3580 For these reason, the ACP ULA address(es) are assigned to Loopback 3581 interface(s). 3583 6.12.5.2. ACP virtual interfaces 3585 Any ACP secure channel to another ACP node is mapped to ACP virtual 3586 interfaces in one of the following ways. This is independent of the 3587 chosen secure channel protocol (IPsec, DTLS or other future protocol 3588 - standards or non-standards). 3590 Note that all the considerations described here are assuming point- 3591 to-point secure channel associations. Mapping multi-party secure 3592 channel associations such as [RFC6407] is out of scope (but would be 3593 easy to add). 3595 6.12.5.2.1. ACP point-to-point virtual interfaces 3597 In this option, each ACP secure channel is mapped into a separate 3598 point-to-point ACP virtual interface. If a physical subnet has more 3599 than two ACP capable nodes (in the same domain), this implementation 3600 approach will lead to a full mesh of ACP virtual interfaces between 3601 them. 3603 6.12.5.2.2. ACP multi-access virtual interfaces 3605 In a more advanced implementation approach, the ACP will construct a 3606 single multi-access ACP virtual interface for all ACP secure channels 3607 to ACP capable nodes reachable across the same underlying (physical) 3608 subnet. IPv6 link-local multicast packets sent into an ACP multi- 3609 access virtual interface are replicated to every ACP secure channel 3610 mapped into the ACP multicast-access virtual interface. IPv6 unicast 3611 packets sent into an ACP multi-access virtual interface are sent to 3612 the ACP secure channel that belongs to the ACP neighbor that is the 3613 next-hop in the ACP forwarding table entry used to reach the packets 3614 destination address. 3616 There is no requirement for all ACP nodes on the same multi-access 3617 subnet to use the same type of ACP virtual interface. This is purely 3618 a node local decision. 3620 ACP nodes MUST perform standard IPv6 operations across ACP virtual 3621 interfaces including SLAAC (Stateless Address Auto-Configuration) - 3622 [RFC4862]) to assign their IPv6 link local address on the ACP virtual 3623 interface and ND (Neighbor Discovery - [RFC4861]) to discover which 3624 IPv6 link-local neighbor address belongs to which ACP secure channel 3625 mapped to the ACP virtual interface. This is independent of whether 3626 the ACP virtual interface is point-to-point or multi-access. 3628 "Optimistic Duplicate Address Detection (DAD)" according to [RFC4429] 3629 is RECOMMENDED because the likelihood for duplicates between ACP 3630 nodes is highly improbable as long as the address can be formed from 3631 a globally unique local assigned identifier (e.g., EUI-48/EUI-64, see 3632 below). 3634 ACP nodes MAY reduce the amount of link-local IPv6 multicast packets 3635 from ND by learning the IPv6 link-local neighbor address to ACP 3636 secure channel mapping from other messages such as the source address 3637 of IPv6 link-local multicast RPL messages - and therefore forego the 3638 need to send Neighbor Solicitation messages. 3640 The ACP virtual interface IPv6 link local address can be derived from 3641 any appropriate local mechanism such as node local EUI-48 or EUI-64 3642 ("EUI" stands for "Extended Unique Identifier"). It MUST NOT depend 3643 on something that is attackable from the Data-Plane such as the IPv6 3644 link-local address of the underlying physical interface, which can be 3645 attacked by SLAAC, or parameters of the secure channel encapsulation 3646 header that may not be protected by the secure channel mechanism. 3648 The link-layer address of an ACP virtual interface is the address 3649 used for the underlying interface across which the secure tunnels are 3650 built, typically Ethernet addresses. Because unicast IPv6 packets 3651 sent to an ACP virtual interface are not sent to a link-layer 3652 destination address but rather an ACP secure channel, the link-layer 3653 address fields SHOULD be ignored on reception and instead the ACP 3654 secure channel from which the message was received should be 3655 remembered. 3657 Multi-access ACP virtual interfaces are preferable implementations 3658 when the underlying interface is a (broadcast) multi-access subnet 3659 because they do reflect the presence of the underlying multi-access 3660 subnet into the virtual interfaces of the ACP. This makes it for 3661 example simpler to build services with topology awareness inside the 3662 ACP VRF in the same way as they could have been built running 3663 natively on the multi-access interfaces. 3665 Consider also the impact of point-to-point vs. multi-access virtual 3666 interface on the efficiency of flooding via link local multicasted 3667 messages: 3669 Assume a LAN with three ACP neighbors, Alice, Bob and Carol. Alice's 3670 ACP GRASP wants to send a link-local GRASP multicast message to Bob 3671 and Carol. If Alice's ACP emulates the LAN as one point-to-point 3672 virtual interface to Bob and one to Carol, The sending applications 3673 itself will send two copies, if Alice's ACP emulates a LAN, GRASP 3674 will send one packet and the ACP will replicate it. The result is 3675 the same. The difference happens when Bob and Carol receive their 3676 packet. If they use ACP point-to-point virtual interfaces, their 3677 GRASP instance would forward the packet from Alice to each other as 3678 part of the GRASP flooding procedure. These packets are unnecessary 3679 and would be discarded by GRASP on receipt as duplicates (by use of 3680 the GRASP Session ID). If Bob and Carol's ACP would emulate a multi- 3681 access virtual interface, then this would not happen, because GRASPs 3682 flooding procedure does not replicate back packets to the interface 3683 that they were received from. 3685 Note that link-local GRASP multicast messages are not sent directly 3686 as IPv6 link-local multicast UDP messages into ACP virtual 3687 interfaces, but instead into ACP GRASP virtual interfaces, that are 3688 layered on top of ACP virtual interfaces to add TCP reliability to 3689 link-local multicast GRASP messages. Nevertheless, these ACP GRASP 3690 virtual interfaces perform the same replication of message and, 3691 therefore, result in the same impact on flooding. See Section 6.8.2 3692 for more details. 3694 RPL does support operations and correct routing table construction 3695 across non-broadcast multi-access (NBMA) subnets. This is common 3696 when using many radio technologies. When such NBMA subnets are used, 3697 they MUST NOT be represented as ACP multi-access virtual interfaces 3698 because the replication of IPv6 link-local multicast messages will 3699 not reach all NBMA subnet neighbors. In result, GRASP message 3700 flooding would fail. Instead, each ACP secure channel across such an 3701 interface MUST be represented as a ACP point-to-point virtual 3702 interface. See also Appendix A.10.4. 3704 Care needs to be taken when creating multi-access ACP virtual 3705 interfaces across ACP secure channels between ACP nodes in different 3706 domains or routing subdomains. If for example future inter-domain 3707 ACP policies are defined as "peer-to-peer" policies, it is easier to 3708 create ACP point-to-point virtual interfaces for these inter-domain 3709 secure channels. 3711 7. ACP support on L2 switches/ports (Normative) 3713 7.1. Why (Benefits of ACP on L2 switches) 3715 ANrtr1 ------ ANswitch1 --- ANswitch2 ------- ANrtr2 3716 .../ \ \ ... 3717 ANrtrM ------ \ ------- ANrtrN 3718 ANswitchM ... 3720 Figure 14: Topology with L2 ACP switches 3722 Consider a large L2 LAN with ANrtr1...ANrtrN connected via some 3723 topology of L2 switches. Examples include large enterprise campus 3724 networks with an L2 core, IoT networks or broadband aggregation 3725 networks which often have even a multi-level L2 switched topology. 3727 If the discovery protocol used for the ACP is operating at the subnet 3728 level, every ACP router will see all other ACP routers on the LAN as 3729 neighbors and a full mesh of ACP channels will be built. If some or 3730 all of the AN switches are autonomic with the same discovery 3731 protocol, then the full mesh would include those switches as well. 3733 A full mesh of ACP connections can create fundamental scale 3734 challenges. The number of security associations of the secure 3735 channel protocols will likely not scale arbitrarily, especially when 3736 they leverage platform accelerated encryption/decryption. Likewise, 3737 any other ACP operations (such as routing) needs to scale to the 3738 number of direct ACP neighbors. An ACP router with just 4 physical 3739 interfaces might be deployed into a LAN with hundreds of neighbors 3740 connected via switches. Introducing such a new unpredictable scaling 3741 factor requirement makes it harder to support the ACP on arbitrary 3742 platforms and in arbitrary deployments. 3744 Predictable scaling requirements for ACP neighbors can most easily be 3745 achieved if in topologies such as these, ACP capable L2 switches can 3746 ensure that discovery messages terminate on them so that neighboring 3747 ACP routers and switches will only find the physically connected ACP 3748 L2 switches as their candidate ACP neighbors. With such a discovery 3749 mechanism in place, the ACP and its security associations will only 3750 need to scale to the number of physical interfaces instead of a 3751 potentially much larger number of "LAN-connected" neighbors. And the 3752 ACP topology will follow directly the physical topology, something 3753 which can then also be leveraged in management operations or by ASAs. 3755 In the example above, consider ANswitch1 and ANswitchM are ACP 3756 capable, and ANswitch2 is not ACP capable. The desired ACP topology 3757 is that ANrtr1 and ANrtrM only have an ACP connection to ANswitch1, 3758 and that ANswitch1, ANrtr2, ANrtrN have a full mesh of ACP connection 3759 amongst each other. ANswitch1 also has an ACP connection with 3760 ANswitchM and ANswitchM has ACP connections to anything else behind 3761 it. 3763 7.2. How (per L2 port DULL GRASP) 3765 To support ACP on L2 switches or L2 switched ports of an L3 device, 3766 it is necessary to make those L2 ports look like L3 interfaces for 3767 the ACP implementation. This primarily involves the creation of a 3768 separate DULL GRASP instance/domain on every such L2 port. Because 3769 GRASP has a dedicated link-local IPv6 multicast address 3770 (ALL_GRASP_NEIGHBORS), it is sufficient that all packets for this 3771 address are being extracted at the port level and passed to that DULL 3772 GRASP instance. Likewise the IPv6 link-local multicast packets sent 3773 by that DULL GRASP instance need to be sent only towards the L2 port 3774 for this DULL GRASP instance (instead of being flooded across all 3775 ports of the VLAN to which the port belongs). 3777 When Ports/Interfaces across which the ACP is expected to operate in 3778 an ACP-aware L2-switch or L2/L3-switch/router are L2-bridged, packets 3779 for the ALL_GRASP_NEIGHBORS multicast address MUST never be forward 3780 between these ports. If MLD snooping is used, it MUST be prohibited 3781 from bridging packets for the ALL_GRASP_NEIGHBORS IPv6 multicast 3782 address. 3784 On hybrid L2/L3 switches, multiple L2 ports are assigned to a single 3785 L3 VLAN interface. With the aforementioned changes for DULL GRASP, 3786 ACP can simply operate on the L3 VLAN interfaces, so no further 3787 (hardware) forwarding changes are required to make ACP operate on L2 3788 ports. This is possible because the ACP secure channel protocols 3789 only use link-local IPv6 unicast packets, and these packets will be 3790 sent to the correct L2 port towards the peer by the VLAN logic of the 3791 device. 3793 This is sufficient when p2p ACP virtual interfaces are established to 3794 every ACP peer. When it is desired to create multi-access ACP 3795 virtual interfaces (see Section 6.12.5.2.2), it is REQIURED not to 3796 coalesce all the ACP secure channels on the same L3 VLAN interface, 3797 but only all those on the same L2 port. 3799 If VLAN tagging is used, then all the above described logic only 3800 applies to untagged GRASP packets. For the purpose of ACP neighbor 3801 discovery via GRASP, no VLAN tagged packets SHOULD be sent or 3802 received. In a hybrid L2/L3 switch, each VLAN would therefore only 3803 create ACP adjacencies across those ports where the VLAN is carried 3804 untagged. 3806 In result, the simple logic is that ACP secure channels would operate 3807 over the same L3 interfaces that present a single flat bridged 3808 network across all routers, but because DULL GRASP is separated on a 3809 per-port basis, no full mesh of ACP secure channels is created, but 3810 only per-port ACP secure channels to per-port L2-adjacent ACP node 3811 neighbors. 3813 For example, in the above picture, ANswitch1 would run separate DULL 3814 GRASP instances on its ports to ANrtr1, ANswitch2 and ANswitchI, even 3815 though all those three ports may be in the data plane in the same 3816 (V)LAN and perform L2 switching between these ports, ANswitch1 would 3817 perform ACP L3 routing between them. 3819 The description in the previous paragraph was specifically meant to 3820 illustrate that on hybrid L3/L2 devices that are common in 3821 enterprise, IoT and broadband aggregation, there is only the GRASP 3822 packet extraction (by Ethernet address) and GRASP link-local 3823 multicast per L2-port packet injection that has to consider L2 ports 3824 at the hardware forwarding level. The remaining operations are 3825 purely ACP control plane and setup of secure channels across the L3 3826 interface. This hopefully makes support for per-L2 port ACP on those 3827 hybrid devices easy. 3829 In devices without such a mix of L2 port/interfaces and L3 interfaces 3830 (to terminate any transport layer connections), implementation 3831 details will differ. Logically most simply every L2 port is 3832 considered and used as a separate L3 subnet for all ACP operations. 3833 The fact that the ACP only requires IPv6 link-local unicast and 3834 multicast should make support for it on any type of L2 devices as 3835 simple as possible. 3837 A generic issue with ACP in L2 switched networks is the interaction 3838 with the Spanning Tree Protocol. Without further L2 enhancements, 3839 the ACP would run only across the active STP topology and the ACP 3840 would be interrupted and re-converge with STP changes. Ideally, ACP 3841 peering SHOULD be built also across ports that are blocked in STP so 3842 that the ACP does not depend on STP and can continue to run 3843 unaffected across STP topology changes, where re-convergence can be 3844 quite slow. The above described simple implementation options are 3845 not sufficient to achieve this. 3847 8. Support for Non-ACP Components (Normative) 3849 8.1. ACP Connect 3851 8.1.1. Non-ACP Controller / NMS system 3853 The Autonomic Control Plane can be used by management systems, such 3854 as controllers or network management system (NMS) hosts (henceforth 3855 called simply "NMS hosts"), to connect to devices (or other type of 3856 nodes) through it. For this, an NMS host needs to have access to the 3857 ACP. The ACP is a self-protecting overlay network, which allows by 3858 default access only to trusted, autonomic systems. Therefore, a 3859 traditional, non-ACP NMS system does not have access to the ACP by 3860 default, such as any other external node. 3862 If the NMS host is not autonomic, i.e., it does not support autonomic 3863 negotiation of the ACP, then it can be brought into the ACP by 3864 explicit configuration. To support connections to adjacent non-ACP 3865 nodes, an ACP node SHOULD support "ACP connect" (sometimes also 3866 called "autonomic connect"): 3868 "ACP connect" is an interface level configured workaround for 3869 connection of trusted non-ACP nodes to the ACP. The ACP node on 3870 which ACP connect is configured is called an "ACP edge node". With 3871 ACP connect, the ACP is accessible from those non-ACP nodes (such as 3872 NOC systems) on such an interface without those non-ACP nodes having 3873 to support any ACP discovery or ACP channel setup. This is also 3874 called "native" access to the ACP because to those NOC systems the 3875 interface looks like a normal network interface (without any 3876 encryption/novel-signaling). 3878 Data-Plane "native" (no ACP) 3879 . 3880 +--------+ +----------------+ . +-------------+ 3881 | ACP | |ACP Edge Node | . | | 3882 | Node | | | v | | 3883 | |-------|...[ACP VRF]....+-----------------| |+ 3884 | | ^ |. | | NOC Device || 3885 | | . | .[Data-Plane]..+-----------------| "NMS hosts" || 3886 | | . | [ ] | . ^ | || 3887 +--------+ . +----------------+ . . +-------------+| 3888 . . . +-------------+ 3889 . . . 3890 Data-Plane "native" . ACP "native" (unencrypted) 3891 + ACP auto-negotiated . "ACP connect subnet" 3892 and encrypted . 3893 ACP connect interface 3894 e.g., "VRF ACP native" (config) 3896 Figure 15: ACP connect 3898 ACP connect has security consequences: All systems and processes 3899 connected via ACP connect have access to all ACP nodes on the entire 3900 ACP, without further authentication. Thus, the ACP connect interface 3901 and NOC systems connected to it needs to be physically controlled/ 3902 secured. For this reason the mechanisms described here do explicitly 3903 not include options to allow for a non-ACP router to be connected 3904 across an ACP connect interface and addresses behind such a router 3905 routed inside the ACP. 3907 An ACP connect interface provides exclusively access to only the ACP. 3908 This is likely insufficient for many NMS hosts. Instead, they would 3909 require a second "Data-Plane" interface outside the ACP for 3910 connections between the NMS host and administrators, or Internet 3911 based services, or for direct access to the Data-Plane. The document 3912 "Using Autonomic Control Plane for Stable Connectivity of Network 3913 OAM" [RFC8368] explains in more detail how the ACP can be integrated 3914 in a mixed NOC environment. 3916 An ACP connect interface SHOULD use an IPv6 address/prefix from the 3917 ACP Manual Addressing Sub-Scheme (Section 6.10.4), letting the 3918 operator configure for example only the Subnet-ID and having the node 3919 automatically assign the remaining part of the prefix/address. It 3920 SHOULD NOT use a prefix that is also routed outside the ACP so that 3921 the addresses clearly indicate whether it is used inside the ACP or 3922 not. 3924 The prefix of ACP connect subnets MUST be distributed by the ACP edge 3925 node into the ACP routing protocol RPL. The NMS hosts MUST connect 3926 to prefixes in the ACP routing table via its ACP connect interface. 3927 In the simple case where the ACP uses only one ULA prefix and all ACP 3928 connect subnets have prefixes covered by that ULA prefix, NMS hosts 3929 can rely on [RFC6724] to determine longest match prefix routes 3930 towards its different interfaces, ACP and data-plane. With RFC6724, 3931 The NMS host will select the ACP connect interface for all addresses 3932 in the ACP because any ACP destination address is longest matched by 3933 the address on the ACP connect interface. If the NMS hosts ACP 3934 connect interface uses another prefix or if the ACP uses multiple ULA 3935 prefixes, then the NMS hosts require (static) routes towards the ACP 3936 interface for these prefixes. 3938 When an ACP Edge node receives a packet from an ACP connect 3939 interface, the ACP Edge node MUST only forward the packet into the 3940 ACP if the packet has an IPv6 source address from that interface. 3941 This is sometimes called "RPF filtering". This MAY be changed 3942 through administrative measures. 3944 To limit the security impact of ACP connect, nodes supporting it 3945 SHOULD implement a security mechanism to allow configuration/use of 3946 ACP connect interfaces only on nodes explicitly targeted to be 3947 deployed with it (those in physically secure locations such as a 3948 NOC). For example, the registrar could disable the ability to enable 3949 ACP connect on devices during enrollment and that property could only 3950 be changed through re-enrollment. See also Appendix A.10.5. 3952 ACP Edge nodes SHOULD have a configurable option to filter packets 3953 with RPI headers (xsee Section 6.11.1.13 across an ACP connect 3954 interface. These headers are outside the scope of the RPL profile in 3955 this specification but may be used in future extensions of this 3956 specification. 3958 8.1.2. Software Components 3960 The previous section assumed that ACP Edge node and NOC devices are 3961 separate physical devices and the ACP connect interface is a physical 3962 network connection. This section discusses the implication when 3963 these components are instead software components running on a single 3964 physical device. 3966 The ACP connect mechanism can not only be used to connect physically 3967 external systems (NMS hosts) to the ACP but also other applications, 3968 containers or virtual machines. In fact, one possible way to 3969 eliminate the security issue of the external ACP connect interface is 3970 to collocate an ACP edge node and an NMS host by making one a virtual 3971 machine or container inside the other; and therefore converting the 3972 unprotected external ACP subnet into an internal virtual subnet in a 3973 single device. This would ultimately result in a fully ACP enabled 3974 NMS host with minimum impact to the NMS hosts software architecture. 3975 This approach is not limited to NMS hosts but could equally be 3976 applied to devices consisting of one or more VNF (virtual network 3977 functions): An internal virtual subnet connecting out-of-band 3978 management interfaces of the VNFs to an ACP edge router VNF. 3980 The core requirement is that the software components need to have a 3981 network stack that permits access to the ACP and optionally also the 3982 Data-Plane. Like in the physical setup for NMS hosts this can be 3983 realized via two internal virtual subnets. One that is connecting to 3984 the ACP (which could be a container or virtual machine by itself), 3985 and one (or more) connecting into the Data-Plane. 3987 This "internal" use of ACP connect approach should not considered to 3988 be a "workaround" because in this case it is possible to build a 3989 correct security model: It is not necessary to rely on unprovable 3990 external physical security mechanisms as in the case of external NMS 3991 hosts. Instead, the orchestration of the ACP, the virtual subnets 3992 and the software components can be done by trusted software that 3993 could be considered to be part of the ANI (or even an extended ACP). 3994 This software component is responsible for ensuring that only trusted 3995 software components will get access to that virtual subnet and that 3996 only even more trusted software components will get access to both 3997 the ACP virtual subnet and the Data-Plane (because those ACP users 3998 could leak traffic between ACP and Data-Plane). This trust could be 3999 established for example through cryptographic means such as signed 4000 software packages. 4002 8.1.3. Auto Configuration 4004 ACP edge nodes, NMS hosts and software components that as described 4005 in the previous section are meant to be composed via virtual 4006 interfaces SHOULD support on the ACP connect subnet StateLess Address 4007 Autoconfiguration (SLAAC - [RFC4862]) and route auto configuration 4008 according to [RFC4191]. 4010 The ACP edge node acts as the router on the ACP connect subnet, 4011 providing the (auto-)configured prefix for the ACP connect subnet to 4012 NMS hosts and/or software components. The ACP edge node uses route 4013 prefix option of RFC4191 to announce the default route (::/) with a 4014 lifetime of 0 and aggregated prefixes for routes in the ACP routing 4015 table with normal lifetimes. This will ensure that the ACP edge node 4016 does not become a default router, but that the NMS hosts and software 4017 components will route the prefixes used in the ACP to the ACP edge 4018 node. 4020 Aggregated prefix means that the ACP edge node needs to only announce 4021 the /48 ULA prefixes used in the ACP but none of the actual /64 4022 (Manual Addressing Sub-Scheme), /127 (ACP Zone Addressing Sub- 4023 Scheme), /112 or /120 (Vlong Addressing Sub-Scheme) routes of actual 4024 ACP nodes. If ACP interfaces are configured with non ULA prefixes, 4025 then those prefixes cannot be aggregated without further configured 4026 policy on the ACP edge node. This explains the above recommendation 4027 to use ACP ULA prefix covered prefixes for ACP connect interfaces: 4028 They allow for a shorter list of prefixes to be signaled via RFC4191 4029 to NMS hosts and software components. 4031 The ACP edge nodes that have a Vlong ACP address MAY allocate a 4032 subset of their /112 or /120 address prefix to ACP connect 4033 interface(s) to eliminate the need to non-autonomically configure/ 4034 provision the address prefixes for such ACP connect interfaces. 4036 8.1.4. Combined ACP/Data-Plane Interface (VRF Select) 4038 Combined ACP and Data-Plane interface 4039 . 4040 +--------+ +--------------------+ . +--------------+ 4041 | ACP | |ACP Edge No | . | NMS Host(s) | 4042 | Node | | | . | / Software | 4043 | | | [ACP ]. | . | |+ 4044 | | | .[VRF ] .[VRF ] | v | "ACP address"|| 4045 | +-------+. .[Select].+--------+ "Date Plane || 4046 | | ^ | .[Data ]. | | Address(es)"|| 4047 | | . | [Plane] | | || 4048 | | . | [ ] | +--------------+| 4049 +--------+ . +--------------------+ +--------------+ 4050 . 4051 Data-Plane "native" and + ACP auto-negotiated/encrypted 4053 Figure 16: VRF select 4055 Using two physical and/or virtual subnets (and therefore interfaces) 4056 into NMS Hosts (as per Section 8.1.1) or Software (as per 4057 Section 8.1.2) may be seen as additional complexity, for example with 4058 legacy NMS Hosts that support only one IP interface. 4060 To provide a single subnet into both ACP and Data-Plane, the ACP Edge 4061 node needs to de-multiplex packets from NMS hosts into ACP VRF and 4062 Data-Plane. This is sometimes called "VRF select". If the ACP VRF 4063 has no overlapping IPv6 addresses with the Data-Plane (it should have 4064 no overlapping addresses), then this function can use the IPv6 4065 Destination address. The problem is Source Address Selection on the 4066 NMS Host(s) according to RFC6724. 4068 Consider the simple case: The ACP uses only one ULA prefix, the ACP 4069 IPv6 prefix for the Combined ACP and Data-Plane interface is covered 4070 by that ULA prefix. The ACP edge node announces both the ACP IPv6 4071 prefix and one (or more) prefixes for the Data-Plane. Without 4072 further policy configurations on the NMS Host(s), it may select its 4073 ACP address as a source address for Data-Plane ULA destinations 4074 because of Rule 8 of RFC6724. The ACP edge node can pass on the 4075 packet to the Data-Plane, but the ACP source address should not be 4076 used for Data-Plane traffic, and return traffic may fail. 4078 If the ACP carries multiple ULA prefixes or non-ULA ACP connect 4079 prefixes, then the correct source address selection becomes even more 4080 problematic. 4082 With separate ACP connect and Data-Plane subnets and RFC4191 prefix 4083 announcements that are to be routed across the ACP connect interface, 4084 RFC6724 source address selection Rule 5 (use address of outgoing 4085 interface) will be used, so that above problems do not occur, even in 4086 more complex cases of multiple ULA and non-ULA prefixes in the ACP 4087 routing table. 4089 To achieve the same behavior with a Combined ACP and Data-Plane 4090 interface, the ACP Edge Node needs to behave as two separate routers 4091 on the interface: One link-local IPv6 address/router for its ACP 4092 reachability, and one link-local IPv6 address/router for its Data- 4093 Plane reachability. The Router Advertisements for both are as 4094 described above (Section 8.1.3): For the ACP, the ACP prefix is 4095 announced together with RFC4191 option for the prefixes routed across 4096 the ACP and lifetime=0 to disqualify this next-hop as a default 4097 router. For the Data-Plane, the Data-Plane prefix(es) are announced 4098 together with whatever dafault router parameters are used for the 4099 Data-Plane. 4101 In result, RFC6724 source address selection Rule 5.5 may result in 4102 the same correct source address selection behavior of NMS hosts 4103 without further configuration on it as the separate ACP connect and 4104 Data-Plane interfaces. As described in the text for Rule 5.5, this 4105 is only a MAY, because IPv6 hosts are not required to track next-hop 4106 information. If an NMS Host does not do this, then separate ACP 4107 connect and Data-Plane interfaces are the preferable method of 4108 attachment. Hosts implementing [RFC8028] should (instead of may) 4109 implement [RFC6724] Rule 5.5, so it is preferred for hosts to support 4110 [RFC8028]. 4112 ACP edge nodes MAY support the Combined ACP and Data-Plane interface. 4114 8.1.5. Use of GRASP 4116 GRASP can and should be possible to use across ACP connect 4117 interfaces, especially in the architectural correct solution when it 4118 is used as a mechanism to connect Software (e.g., ASA or legacy NMS 4119 applications) to the ACP. 4121 Given how the ACP is the security and transport substrate for GRASP, 4122 the requirements for devices connected via ACP connect is that those 4123 are equivalently (if not better) secured against attacks and run only 4124 software that is equally (if not better) protected, known (or 4125 trusted) not to be malicious and accordingly designed to isolate 4126 access to the ACP against external equipment. 4128 The difference in security is that cryptographic security of the ACP 4129 secure channel is replaced by required physical security of the 4130 network connection between an ACP edge node and the NMS or other host 4131 reachable via the ACP connect interface. Node integrity too is 4132 expected to be easier because the ACP connect node, the ACP connect 4133 link and the nodes connecting to it must be in a contiguous secure 4134 environment, hence assuming there can be no physical attack against 4135 the devices. 4137 When using "Combined ACP and Data-Plane Interfaces", care hasa to be 4138 taken that only GRASP messages intended for the ACP GRASP domain 4139 received from Software or NMS Hosts are forwarded by ACP edge nodes. 4140 Currently there is no definition for a GRASP security and transport 4141 substrate beside the ACP, so there is no definition how such 4142 Software/NMS Host could participate in two separate GRASP Domains 4143 across the same subnet (ACP and Data-Plane domains). At current it 4144 is assumed that all GRASP packets on a Combined ACP and Data-Plane 4145 interface belong to the GRASP ACP Domain. They SHOULD all use the 4146 ACP IPv6 addresses of the Software/NMS Hosts. The link-local IPv6 4147 addresses of Software/NMS Hosts (used for GRASP M_DISCOVERY and 4148 M_FLOOD messages) are also assumed to belong to the ACP address 4149 space. 4151 8.2. Connecting ACP islands over Non-ACP L3 networks (Remote ACP 4152 neighbors) 4154 Not all nodes in a network may support the ACP. If non-ACP Layer-2 4155 devices are between ACP nodes, the ACP will work across it since it 4156 is IP based. However, the autonomic discovery of ACP neighbors via 4157 DULL GRASP is only intended to work across L2 connections, so it is 4158 not sufficient to autonomically create ACP connections across non-ACP 4159 Layer-3 devices. 4161 8.2.1. Configured Remote ACP neighbor 4163 On the ACP node, remote ACP neighbors are configured explicitly. The 4164 parameters of such a "connection" are described in the following 4165 ABNF. 4167 connection = [ method , local-addr, remote-addr, ?pmtu ] 4168 method = [ "IKEv2" , ?port ] 4169 method //= [ "DTLS", port ] 4170 local-addr = [ address , ?vrf ] 4171 remote-addr = [ address ] 4172 address = ("any" | ipv4-address | ipv6-address ) 4173 vrf = tstr ; Name of a VRF on this node with local-address 4175 Figure 17: Parameters for remote ACP neighbors 4177 Explicit configuration of a remote-peer according to this ABNF 4178 provides all the information to build a secure channel without 4179 requiring a tunnel to that peer and running DULL GRASP inside of it. 4181 The configuration includes the parameters otherwise signaled via DULL 4182 GRASP: local address, remote (peer) locator and method. The 4183 differences over DULL GRASP local neighbor discovery and secure 4184 channel creation are as follows: 4186 o The local and remote address can be IPv4 or IPv6 and are typically 4187 global scope addresses. 4189 o The VRF across which the connection is built (and in which local- 4190 addr exists) can to be specified. If vrf is not specified, it is 4191 the default VRF on the node. In DULL GRASP the VRF is implied by 4192 the interface across which DULL GRASP operates. 4194 o If local address is "any", the local address used when initiating 4195 a secure channel connection is decided by source address selection 4196 ([RFC6724] for IPv6). As a responder, the connection listens on 4197 all addresses of the node in the selected VRF. 4199 o Configuration of port is only required for methods where no 4200 defaults exist (e.g., "DTLS"). 4202 o If remote address is "any", the connection is only a responder. 4203 It is a "hub" that can be used by multiple remote peers to connect 4204 simultaneously - without having to know or configure their 4205 addresses. Example: Hub site for remote "spoke" sites reachable 4206 over the Internet. 4208 o Pmtu should be configurable to overcome issues/limitations of Path 4209 MTU Discovery (PMTUD). 4211 o IKEv2/IPsec to remote peers should support the optional NAT 4212 Traversal (NAT-T) procedures. 4214 8.2.2. Tunneled Remote ACP Neighbor 4216 An IPinIP, GRE or other form of pre-existing tunnel is configured 4217 between two remote ACP peers and the virtual interfaces representing 4218 the tunnel are configured for "ACP enable". This will enable IPv6 4219 link local addresses and DULL on this tunnel. In result, the tunnel 4220 is used for normal "L2 adjacent" candidate ACP neighbor discovery 4221 with DULL and secure channel setup procedures described in this 4222 document. 4224 Tunneled Remote ACP Neighbor requires two encapsulations: the 4225 configured tunnel and the secure channel inside of that tunnel. This 4226 makes it in general less desirable than Configured Remote ACP 4227 Neighbor. Benefits of tunnels are that it may be easier to implement 4228 because there is no change to the ACP functionality - just running it 4229 over a virtual (tunnel) interface instead of only native interfaces. 4230 The tunnel itself may also provide PMTUD while the secure channel 4231 method may not. Or the tunnel mechanism is permitted/possible 4232 through some firewall while the secure channel method may not. 4234 8.2.3. Summary 4236 Configured/Tunneled Remote ACP neighbors are less "indestructible" 4237 than L2 adjacent ACP neighbors based on link local addressing, since 4238 they depend on more correct Data-Plane operations, such as routing 4239 and global addressing. 4241 Nevertheless, these options may be crucial to incrementally deploy 4242 the ACP, especially if it is meant to connect islands across the 4243 Internet. Implementations SHOULD support at least Tunneled Remote 4244 ACP Neighbors via GRE tunnels - which is likely the most common 4245 router-to-router tunneling protocol in use today. 4247 9. ACP Operations (Informative) 4249 The following sections document important operational aspects of the 4250 ACP. They are not normative because they do not impact the 4251 interoperability between components of the ACP, but they include 4252 recommendations/requirements for the internal operational model 4253 beneficial or necessary to achieve the desired use-case benefits of 4254 the ACP (see Section 3). 4256 o Section 9.1 describes recommended operator diagnostics 4257 capabilities of ACP nodes. The have been derived from diagnostic 4258 of a commercially available ACP implementation. 4260 o Section 9.2 describes high level how an ACP registrar needs to 4261 work, what its configuration parameters are and specific issues 4262 impacting the choices of deployment design due to renewal and 4263 revocation issues. It describes a model where ACP Registrars have 4264 their own sub-CA to provide the most distributed deployment option 4265 for ACP Registrars, and it describes considerations for 4266 centralized policy control of ACP Registrar operations. 4268 o Section 9.3 describes suggested ACP node behavior and operational 4269 interfaces (configuration options) to manage the ACP in so-called 4270 greenfield devices (previously unconfigured) and brownfield 4271 devices (preconfigured). 4273 The recommendations and suggestions of this chapter were derived from 4274 operational experience gained with a commercially available pre- 4275 standard ACP implementation. 4277 9.1. ACP (and BRSKI) Diagnostics 4279 Even though ACP and ANI in general are taking out many manual 4280 configuration mistakes through their automation, it is important to 4281 provide good diagnostics for them. 4283 The basic diagnostics is support of (yang) data models representing 4284 the complete (auto-)configuration and operational state of all 4285 components: BRSKI, GRASP, ACP and the infrastructure used by them: 4286 TLS/DTLS, IPsec, certificates, trust anchors, time, VRF and so on. 4287 While necessary, this is not sufficient: 4289 Simply representing the state of components does not allow operators 4290 to quickly take action - unless they do understand how to interpret 4291 the data, and that can mean a requirement for deep understanding of 4292 all components and how they interact in the ACP/ANI. 4294 Diagnostic supports should help to quickly answer the questions 4295 operators are expected to ask, such as "is the ACP working 4296 correctly?", or "why is there no ACP connection to a known 4297 neighboring node?" 4299 In current network management approaches, the logic to answer these 4300 questions is most often built as centralized diagnostics software 4301 that leverages the above mentioned data models. While this approach 4302 is feasible for components utilizing the ANI, it is not sufficient to 4303 diagnose the ANI itself: 4305 o Developing the logic to identify common issues requires 4306 operational experience with the components of the ANI. Letting 4307 each management system define its own analysis is inefficient. 4309 o When the ANI is not operating correctly, it may not be possible to 4310 run diagnostics from remote because of missing connectivity. The 4311 ANI should therefore have diagnostic capabilities available 4312 locally on the nodes themselves. 4314 o Certain operations are difficult or impossible to monitor in real- 4315 time, such as initial bootstrap issues in a network location where 4316 no capabilities exist to attach local diagnostics. Therefore it 4317 is important to also define means of capturing (logging) 4318 diagnostics locally for later retrieval. Ideally, these captures 4319 are also non-volatile so that they can survive extended power-off 4320 conditions - for example when a device that fails to be brought up 4321 zero-touch is being sent back for diagnostics at a more 4322 appropriate location. 4324 The most simple form of diagnostics answering questions such as the 4325 above is to represent the relevant information sequentially in 4326 dependency order, so that the first non-expected/non-operational item 4327 is the most likely root cause. Or just log/highlight that item. For 4328 example: 4330 Q: Is ACP operational to accept neighbor connections: 4332 o Check if any potentially necessary configuration to make ACP/ANI 4333 operational are correct (see Section 9.3 for a discussion of such 4334 commands). 4336 o Does the system time look reasonable, or could it be the default 4337 system time after clock chip battery failure (certificate checks 4338 depend on reasonable notion of time). 4340 o Does the node have keying material - domain certificate, trust 4341 anchors. 4343 o If no keying material and ANI is supported/enabled, check the 4344 state of BRSKI (not detailed in this example). 4346 o Check the validity of the domain certificate: 4348 * Does the certificate validate against the trust anchor? 4350 * Has it been revoked? 4351 * Was the last scheduled attempt to retrieve a CRL successful 4352 (e.g., do we know that our CRL information is up to date). 4354 * Is the certificate valid: validity start time in the past, 4355 expiration time in the future? 4357 * Does the certificate have a correctly formatted ACP domain 4358 information field? 4360 o Was the ACP VRF successfully created? 4362 o Is ACP enabled on one or more interfaces that are up and running? 4364 If all this looks good, the ACP should be running locally "fine" - 4365 but we did not check any ACP neighbor relationships. 4367 Question: why does the node not create a working ACP connection to a 4368 neighbor on an interface? 4370 o Is the interface physically up? Does it have an IPv6 link-local 4371 address? 4373 o Is it enabled for ACP? 4375 o Do we successfully send DULL GRASP messages to the interface (link 4376 layer errors)? 4378 o Do we receive DULL GRASP messages on the interface? If not, some 4379 intervening L2 equipment performing bad MLD snooping could have 4380 caused problems. Provide e.g., diagnostics of the MLD querier 4381 IPv6 and MAC address. 4383 o Do we see the ACP objective in any DULL GRASP message from that 4384 interface? Diagnose the supported secure channel methods. 4386 o Do we know the MAC address of the neighbor with the ACP objective? 4387 If not, diagnose SLAAC/ND state. 4389 o When did we last attempt to build an ACP secure channel to the 4390 neighbor? 4392 o If it failed, why: 4394 * Did the neighbor close the connection on us or did we close the 4395 connection on it because the domain certificate membership 4396 failed? 4398 * If the neighbor closed the connection on us, provide any error 4399 diagnostics from the secure channel protocol. 4401 * If we failed the attempt, display our local reason: 4403 + There was no common secure channel protocol supported by the 4404 two neighbors (this could not happen on nodes supporting 4405 this specification because it mandates common support for 4406 IPsec). 4408 + The ACP domain certificate membership check (Section 6.1.3) 4409 fails: 4411 - The neighbor's certificate does not have the required 4412 trust anchor. Provide diagnostics which trust anchor it 4413 has (can identify whom the device belongs to). 4415 - The neighbor's certificate does not have the same domain 4416 (or no domain at all). Diagnose domain-name and 4417 potentially other cert info. 4419 - The neighbor's certificate has been revoked or could not 4420 be authenticated by OCSP. 4422 - The neighbor's certificate has expired - or is not yet 4423 valid. 4425 * Any other connection issues in e.g., IKEv2 / IPsec, DTLS?. 4427 Question: Is the ACP operating correctly across its secure channels? 4429 o Are there one or more active ACP neighbors with secure channels? 4431 o Is the RPL routing protocol for the ACP running? 4433 o Is there a default route to the root in the ACP routing table? 4435 o Is there for each direct ACP neighbor not reachable over the ACP 4436 virtual interface to the root a route in the ACP routing table? 4438 o Is ACP GRASP running? 4440 o Is at least one SRV.est objective cached (to support certificate 4441 renewal)? 4443 o Is there at least one BRSKI registrar objective cached (in case 4444 BRSKI is supported) 4446 o Is BRSKI proxy operating normally on all interfaces where ACP is 4447 operating? 4449 o ... 4451 These lists are not necessarily complete, but illustrate the 4452 principle and show that there are variety of issues ranging from 4453 normal operational causes (a neighbor in another ACP domain) over 4454 problems in the credentials management (certificate lifetimes), 4455 explicit security actions (revocation) or unexpected connectivity 4456 issues (intervening L2 equipment). 4458 The items so far are illustrating how the ANI operations can be 4459 diagnosed with passive observation of the operational state of its 4460 components including historic/cached/counted events. This is not 4461 necessary sufficient to provide good enough diagnostics overall: 4463 The components of ACP and BRSKI are designed with security in mind 4464 but they do not attempt to provide diagnostics for building the 4465 network itself. Consider two examples: 4467 1. BRSKI does not allow for a neighboring device to identify the 4468 pledges certificate (IDevID). Only the selected BRSKI registrar 4469 can do this, but it may be difficult to disseminate information 4470 about undesired pledges from those BRSKI registrars to locations/ 4471 nodes where information about those pledges is desired. 4473 2. LLDP disseminates information about nodes to their immediate 4474 neighbors, such as node model/type/software and interface name/ 4475 number of the connection. This information is often helpful or 4476 even necessary in network diagnostics. It can equally considered 4477 to be too insecure to make this information available unprotected 4478 to all possible neighbors. 4480 An "interested adjacent party" can always determine the IDevID of a 4481 BRSKI pledge by behaving like a BRSKI proxy/registrar. Therefore the 4482 IDevID of a BRSKI pledge is not meant to be protected - it just has 4483 to be queried and is not signaled unsolicited (as it would be in 4484 LLDP) so that other observers on the same subnet can determine who is 4485 an "interested adjacent party". 4487 9.2. ACP Registrars 4489 As described in Section 6.10.7, the ACP addressing mechanism is 4490 designed to enable lightweight, distributed and uncoordinated ACP 4491 registrars that are providing ACP address prefixes to candidate ACP 4492 nodes by enrolling them with an ACP domain certificate into an ACP 4493 domain via any appropriate mechanism/protocol, automated or not. 4495 This section discusses informatively more details and options for ACP 4496 registrars. 4498 9.2.1. Registrar interactions 4500 This section summarizes and discusses the interactions with other 4501 entities required by an ACP registrar. 4503 In a simple instance of an ACP network, no central NOC component 4504 beside a trust anchor (root CA) is required. One or more 4505 uncoordinated acting ACP registrar can be set up, performing the 4506 following interactions: 4508 To orchestrate enrolling a candidate ACP node autonomically, the ACP 4509 registrar can rely on the ACP and use Proxies to reach the candidate 4510 ACP node, therefore allowing minimum pre-existing (auto-)configured 4511 network services on the candidate ACP node. BRSKI defines the BRSKI 4512 proxy, a design that can be adopted for various protocols that 4513 Pledges/candidate ACP nodes could want to use, for example BRSKI over 4514 CoAP (Constrained Application Protocol), or proxying of Netconf. 4516 To reach a trust anchor unaware of the ACP, the ACP registrar would 4517 use the Data-Plane. ACP and Data-Plane in an ACP registrar could 4518 (and by default should be) completely isolated from each other at the 4519 network level. Only applications such as the ACP registrar would 4520 need the ability for their transport stacks to access both. 4522 In non-autonomic enrollment options, the Data-Plane between a ACP 4523 registrar and the candidate ACP node needs to be configured first. 4524 This includes the ACP registrar and the candidate ACP node. Then any 4525 appropriate set of protocols can be used between ACP registrar and 4526 candidate ACP node to discover the other side, and then connect and 4527 enroll (configure) the candidate ACP node with an ACP domain 4528 certificate. Netconf ZeroTouch ([RFC8572]) is an example protocol 4529 that could be used for this. BRSKI using optional discovery 4530 mechanisms is equally a possibility for candidate ACP nodes 4531 attempting to be enrolled across non-ACP networks, such as the 4532 Internet. 4534 When candidate ACP nodes have secure bootstrap, such as BRSKI 4535 Pledges, they will not trust to be configured/enrolled across the 4536 network, unless being presented with a voucher (see [RFC8366]) 4537 authorizing the network to take possession of the node. An ACP 4538 registrar will then need a method to retrieve such a voucher, either 4539 offline, or online from a MASA (Manufacturer Authorized Signing 4540 Authority). BRSKI and Netconf ZeroTouch are two protocols that 4541 include capabilities to present the voucher to the candidate ACP 4542 node. 4544 An ACP registrar could operate EST for ACP certificate renewal and/or 4545 act as a CRL Distribution point. A node performing these services 4546 does not need to support performing (initial) enrollment, but it does 4547 require the same above described connectivity as an ACP registrar: 4548 via the ACP to ACP nodes and via the Data-Plane to the trust anchor 4549 and other sources of CRL information. 4551 9.2.2. Registrar Parameter 4553 The interactions of an ACP registrar outlined Section 6.10.7 and 4554 Section 9.2.1 above depend on the following parameters: 4556 A URL to the trust anchor (root CA) and credentials so that the 4557 ACP registrar can let the trust anchor sign candidate ACP member 4558 certificates. 4560 The ACP domain-name. 4562 The Registrar-ID to use. This could default to a MAC address of 4563 the ACP registrar. 4565 For recovery, the next-useable Node-IDs for zone (Zone-ID=0) sub- 4566 addressing scheme, for Vlong /112 and for Vlong /1120 sub- 4567 addressing scheme. These IDs would only need to be provisioned 4568 after recovering from a crash. Some other mechanism would be 4569 required to remember these IDs in a backup location or to recover 4570 them from the set of currently known ACP nodes. 4572 Policies if candidate ACP nodes should receive a domain 4573 certificate or not, for example based on the devices IDevID as in 4574 BRSKI. The ACP registrar may have a whitelist or blacklist of 4575 devices "serialNumbers" from their IDevID. 4577 Policies what type of address prefix to assign to a candidate ACP 4578 devices, based on likely the same information. 4580 For BRSKI or other mechanisms using vouchers: Parameters to 4581 determine how to retrieve vouchers for specific type of secure 4582 bootstrap candidate ACP nodes (such as MASA URLs), unless this 4583 information is automatically learned such as from the IDevID of 4584 candidate ACP nodes (as defined in BRSKI). 4586 9.2.3. Certificate renewal and limitations 4588 When an ACP node renews/rekeys its certificate, it may end up doing 4589 so via a different registrar (e.g., EST server) than the one it 4590 originally received its ACP domain certificate from, for example 4591 because that original ACP registrar is gone. The ACP registrar 4592 through which the renewal/rekeying is performed would by default 4593 trust the ACP domain information from the ACP nodes current ACP 4594 domain certificate and maintain this information so that the ACP node 4595 maintains its ACP address prefix. In EST renewal/rekeying, the ACP 4596 nodes current ACP domain certificate is signaled during the TLS 4597 handshake. 4599 This simple scenario has two limitations: 4601 1. The ACP registrars cannot directly assign certificates to nodes 4602 and therefore needs an "online" connection to the trust anchor 4603 (root CA). 4605 2. Recovery from a compromised ACP registrar is difficult. When an 4606 ACP registrar is compromised, it can insert for example 4607 conflicting ACP domain information and create thereby an attack 4608 against other ACP nodes through the ACP routing protocol. 4610 Even when such a malicious ACP registrar is detected, resolving the 4611 problem may be difficult because it would require identifying all the 4612 wrong ACP domain certificates assigned via the ACP registrar after it 4613 was compromised. And without additional centralized tracking of 4614 assigned certificates there is no way to do this. 4616 9.2.4. ACP Registrars with sub-CA 4618 In situations, where either of the above two limitations are an 4619 issue, ACP registrars could also be sub-CAs. This removes the need 4620 for connectivity to a root-CA whenever an ACP node is enrolled, and 4621 reduces the need for connectivity of such an ACP registrar to a root- 4622 CA to only those times when it needs to renew its own certificate. 4623 The ACP registrar would also now use its own (sub-CA) certificate to 4624 enroll and sign the ACP nodes certificates, and therefore it is only 4625 necessary to revoke a compromised ACP registrars sub-CA certificate. 4626 Alternatively one can let it expire and not renew it, when the 4627 certificate of the sub-CA is appropriately short-lived. 4629 As the ACP domain membership check verifies a peer ACP node's ACP 4630 domain certificate trust chain, it will also verify the signing 4631 certificate which is the compromised/revoked sub-CA certificate. 4632 Therefore ACP domain membership for an ACP node enrolled from a 4633 compromised and discovered ACP registrar will fail. 4635 ACP nodes enrolled by a compromised ACP registrar would automatically 4636 fail to establish ACP channels and ACP domain certificate renewal via 4637 EST and therefore revert to their role as a candidate ACP members and 4638 attempt to get a new ACP domain certificate from an ACP registrar - 4639 for example, via BRSKI. In result, ACP registrars that have an 4640 associated sub-CA makes isolating and resolving issues with 4641 compromised registrars easier. 4643 Note that ACP registrars with sub-CA functionality also can control 4644 the lifetime of ACP domain certificates easier and therefore also be 4645 used as a tool to introduce short lived certificates and not rely on 4646 CRL, whereas the certificates for the sub-CAs themselves could be 4647 longer lived and subject to CRL. 4649 9.2.5. Centralized Policy Control 4651 When using multiple, uncoordinated ACP registrars, several advanced 4652 operations are potentially more complex than with a single, resilient 4653 policy control backend, for example including but not limited to: 4655 Which candidate ACP node is permitted or not permitted into an ACP 4656 domain. This may not be a decision to be taken upfront, so that a 4657 per-"serialNumber" policy can be loaded into every ACP registrar. 4658 Instead, it may better be decided in real-time including 4659 potentially a human decision in a NOC. 4661 Tracking of all enrolled ACP nodes and their certificate 4662 information. For example in support of revoking individual ACP 4663 nodes certificates. 4665 More flexible policies what type of address prefix or even what 4666 specific address prefix to assign to a candidate ACP node. 4668 These and other operations could be introduced more easily by 4669 introducing a centralized Policy Management System (PMS) and 4670 modifying ACP registrar behavior so that it queries the PMS for any 4671 policy decision occurring during the candidate ACP node enrollment 4672 process and/or the ACP node certificate renewal process. For 4673 example, which ACP address prefix to assign. Likewise the ACP 4674 registrar would report any relevant state change information to the 4675 PMS as well, for example when a certificate was successfully enrolled 4676 onto a candidate ACP node. 4678 9.3. Enabling and disabling ACP/ANI 4680 Both ACP and BRSKI require interfaces to be operational enough to 4681 support sending/receiving their packets. In node types where 4682 interfaces are by default (e.g., without operator configuration) 4683 enabled, such as most L2 switches, this would be less of a change in 4684 behavior than in most L3 devices (e.g.: routers), where interfaces 4685 are by default disabled. In almost all network devices it is common 4686 though for configuration to change interfaces to a physically 4687 disabled state and that would break the ACP. 4689 In this section, we discuss a suggested operational model to enable/ 4690 disable interfaces and nodes for ACP/ANI in a way that minimizes the 4691 risk of operator action to break the ACP in this way, and that also 4692 minimizes operator surprise when ACP/ANI becomes supported in node 4693 software. 4695 9.3.1. Filtering for non-ACP/ANI packets 4697 Whenever this document refers to enabling an interface for ACP (or 4698 BRSKI), it only requires to permit the interface to send/receive 4699 packets necessary to operate ACP (or BRSKI) - but not any other Data- 4700 Plane packets. Unless the Data-Plane is explicitly configured/ 4701 enabled, all packets not required for ACP/BRSKI should be filtered on 4702 input and output: 4704 Both BRSKI and ACP require link-local only IPv6 operations on 4705 interfaces and DULL GRASP. IPv6 link-local operations means the 4706 minimum signaling to auto-assign an IPv6 link-local address and talk 4707 to neighbors via their link-local address: SLAAC (Stateless Address 4708 Auto-Configuration - [RFC4862]) and ND (Neighbor Discovery - 4709 [RFC4861]). When the device is a BRSKI pledge, it may also require 4710 TCP/TLS connections to BRSKI proxies on the interface. When the 4711 device has keying material, and the ACP is running, it requires DULL 4712 GRASP packets and packets necessary for the secure-channel mechanism 4713 it supports, e.g., IKEv2 and IPsec ESP packets or DTLS packets to the 4714 IPv6 link-local address of an ACP neighbor on the interface. It also 4715 requires TCP/TLS packets for its BRSKI proxy functionality, if it 4716 does support BRSKI. 4718 9.3.2. Admin Down State 4720 Interfaces on most network equipment have at least two states: "up" 4721 and "down". These may have product specific names. "down" for 4722 example could be called "shutdown" and "up" could be called "no 4723 shutdown". The "down" state disables all interface operations down 4724 to the physical level. The "up" state enables the interface enough 4725 for all possible L2/L3 services to operate on top of it and it may 4726 also auto-enable some subset of them. More commonly, the operations 4727 of various L2/L3 services is controlled via additional node-wide or 4728 interface level options, but they all become only active when the 4729 interface is not "down". Therefore an easy way to ensure that all 4730 L2/L3 operations on an interface are inactive is to put the interface 4731 into "down" state. The fact that this also physically shuts down the 4732 interface is in many cases just a side effect, but it may be 4733 important in other cases (see below, Section 9.3.2.2). 4735 To provide ACP/ANI resilience against operators configuring 4736 interfaces to "down" state, this document recommends to separate the 4737 "down" state of interfaces into an "admin down" state where the 4738 physical layer is kept running and ACP/ANI can use the interface and 4739 a "physical down" state. Any existing "down" configurations would 4740 map to "admin down". In "admin down", any existing L2/L3 services of 4741 the Data-Plane should see no difference to "physical down" state. To 4742 ensure that no Data-Plane packets could be sent/received, packet 4743 filtering could be established automatically as described above in 4744 Section 9.3.1. 4746 As necessary (see discussion below) new configuration options could 4747 be introduced to issue "physical down". The options should be 4748 provided with additional checks to minimize the risk of issuing them 4749 in a way that breaks the ACP without automatic restoration. For 4750 example they could be denied to be issued from a control connection 4751 (netconf/ssh) that goes across the interface itself ("do not 4752 disconnect yourself"). Or they could be performed only temporary and 4753 only be made permanent with additional later reconfirmation. 4755 In the following sub-sections important aspects to the introduction 4756 of "admin down" state are discussed. 4758 9.3.2.1. Security 4760 Interfaces are physically brought down (or left in default down 4761 state) as a form of security. "Admin down" state as described above 4762 provides also a high level of security because it only permits ACP/ 4763 ANI operations which are both well secured. Ultimately, it is 4764 subject to security review for the deployment whether "admin down" is 4765 a feasible replacement for "physical down". 4767 The need to trust the security of ACP/ANI operations needs to be 4768 weighed against the operational benefits of permitting this: Consider 4769 the typical example of a CPE (customer premises equipment) with no 4770 on-site network expert. User ports are in physical down state unless 4771 explicitly configured not to be. In a misconfiguration situation, 4772 the uplink connection is incorrectly plugged into such as user port. 4773 The device is disconnected from the network and therefore no 4774 diagnostics from the network side is possible anymore. 4775 Alternatively, all ports default to "admin down". The ACP (but not 4776 the Data-Plane) would still automatically form. Diagnostics from the 4777 network side is possible and operator reaction could include to 4778 either make this port the operational uplink port or to instruct re- 4779 cabling. Security wise, only ACP/ANI could be attacked, all other 4780 functions are filtered on interfaces in "admin down" state. 4782 9.3.2.2. Fast state propagation and Diagnostics 4784 "Physical down" state propagates on many interface types (e.g., 4785 Ethernet) to the other side. This can trigger fast L2/L3 protocol 4786 reaction on the other side and "admin down" would not have the same 4787 (fast) result. 4789 Bringing interfaces to "physical down" state is to the best of our 4790 knowledge always a result of operator action, but today, never the 4791 result of autonomic L2/L3 services running on the nodes. Therefore 4792 one option is to change the operator action to not rely on link-state 4793 propagation anymore. This may not be possible when both sides are 4794 under different operator control, but in that case it is unlikely 4795 that the ACP is running across the link and actually putting the 4796 interface into "physical down" state may still be a good option. 4798 Ideally, fast physical state propagation is replaced by fast software 4799 driven state propagation. For example a DULL GRASP "admin-state" 4800 objective could be used to auto configure a Bidirectional Forwarding 4801 Protocol (BFD, [RFC5880]) session between the two sides of the link 4802 that would be used to propagate the "up" vs. admin down state. 4804 Triggering physical down state may also be used as a mean of 4805 diagnosing cabling in the absence of easier methods. It is more 4806 complex than automated neighbor diagnostics because it requires 4807 coordinated remote access to both (likely) sides of a link to 4808 determine whether up/down toggling will cause the same reaction on 4809 the remote side. 4811 See Section 9.1 for a discussion about how LLDP and/or diagnostics 4812 via GRASP could be used to provide neighbor diagnostics, and 4813 therefore hopefully eliminating the need for "physical down" for 4814 neighbor diagnostics - as long as both neighbors support ACP/ANI. 4816 9.3.2.3. Low Level Link Diagnostics 4818 "Physical down" is performed to diagnose low-level interface behavior 4819 when higher layer services (e.g., IPv6) are not working. Especially 4820 Ethernet links are subject to a wide variety of possible wrong 4821 configuration/cablings if they do not support automatic selection of 4822 variable parameters such as speed (10/100/1000 Mbps), crossover 4823 (Auto-MDIX) and connector (fiber, copper - when interfaces have 4824 multiple but can only enable one at a time). The need for low level 4825 link diagnostic can therefore be minimized by using fully auto 4826 configuring links. 4828 In addition to "Physical down", low level diagnostics of Ethernet or 4829 other interfaces also involve the creation of other states on 4830 interfaces, such as physical Loopback (internal and/or external) or 4831 bringing down all packet transmissions for reflection/cable-length 4832 measurements. Any of these options would disrupt ACP as well. 4834 In cases where such low-level diagnostics of an operational link is 4835 desired but where the link could be a single point of failure for the 4836 ACP, ASA on both nodes of the link could perform a negotiated 4837 diagnostics that automatically terminates in a predetermined manner 4838 without dependence on external input ensuring the link will become 4839 operational again. 4841 9.3.2.4. Power Consumption Issues 4843 Power consumption of "physical down" interfaces, may be significantly 4844 lower than those in "admin down" state, for example on long-range 4845 fiber interfaces. Bringing up interfaces, for example to probe 4846 reachability, may also consume additional power. This can make these 4847 type of interfaces inappropriate to operate purely for the ACP when 4848 they are not currently needed for the Data-Plane. 4850 9.3.3. Interface level ACP/ANI enable 4852 The interface level configuration option "ACP enable" enables ACP 4853 operations on an interface, starting with ACP neighbor discovery via 4854 DULL GRAP. The interface level configuration option "ANI enable" on 4855 nodes supporting BRSKI and ACP starts with BRSKI pledge operations 4856 when there is no domain certificate on the node. On ACP/BRSKI nodes, 4857 "ACP enable" may not need to be supported, but only "ANI enable". 4858 Unless overridden by global configuration options (see later), "ACP/ 4859 ANI enable" will result in "down" state on an interface to behave as 4860 "admin down". 4862 9.3.4. Which interfaces to auto-enable? 4864 (Section 6.3) requires that "ACP enable" is automatically set on 4865 native interfaces, but not on non-native interfaces (reminder: a 4866 native interface is one that exists without operator configuration 4867 action such as physical interfaces in physical devices). 4869 Ideally, ACP enable is set automatically on all interfaces that 4870 provide access to additional connectivity that allows to reach more 4871 nodes of the ACP domain. The best set of interfaces necessary to 4872 achieve this is not possible to determine automatically. Native 4873 interfaces are the best automatic approximation. 4875 Consider an ACP domain of ACP nodes transitively connected via native 4876 interfaces. A Data-Plane tunnel between two of these nodes that are 4877 non-adjacent is created and "ACP enable" is set for that tunnel. ACP 4878 RPL sees this tunnel as just as a single hop. Routes in the ACP 4879 would use this hop as an attractive path element to connect regions 4880 adjacent to the tunnel nodes. In result, the actual hop-by-hop paths 4881 used by traffic in the ACP can become worse. In addition, correct 4882 forwarding in the ACP now depends on correct Data-Plane forwarding 4883 config including QoS, filtering and other security on the Data-Plane 4884 path across which this tunnel runs. This is the main issue why "ACP/ 4885 ANI enable" should not be set automatically on non-native interfaces. 4887 If the tunnel would connect two previously disjoint ACP regions, then 4888 it likely would be useful for the ACP. A Data-Plane tunnel could 4889 also run across nodes without ACP and provide additional connectivity 4890 for an already connected ACP network. The benefit of this additional 4891 ACP redundancy has to be weighed against the problems of relying on 4892 the Data-Plane. If a tunnel connects two separate ACP regions: how 4893 many tunnels should be created to connect these ACP regions reliably 4894 enough? Between which nodes? These are all standard tunneled 4895 network design questions not specific to the ACP, and there are no 4896 generic fully automated answers. 4898 Instead of automatically setting "ACP enable" on these type of 4899 interfaces, the decision needs to be based on the use purpose of the 4900 non-native interface and "ACP enable" needs to be set in conjunction 4901 with the mechanism through which the non-native interface is created/ 4902 configured. 4904 In addition to explicit setting of "ACP/ANI enable", non-native 4905 interfaces also need to support configuration of the ACP RPL cost of 4906 the link - to avoid the problems of attracting too much traffic to 4907 the link as described above. 4909 Even native interfaces may not be able to automatically perform BRSKI 4910 or ACP because they may require additional operator input to become 4911 operational. Example include DSL interfaces requiring PPPoE 4912 credentials or mobile interfaces requiring credentials from a SIM 4913 card. Whatever mechanism is used to provide the necessary config to 4914 the device to enable the interface can also be expanded to decide on 4915 whether or not to set "ACP/ANI enable". 4917 The goal of automatically setting "ACP/ANI enable" on interfaces 4918 (native or not) is to eliminate unnecessary "touches" to the node to 4919 make its operation as much as possible "zero-touch" with respect to 4920 ACP/ANI. If there are "unavoidable touches" such a creating/ 4921 configuring a non-native interface or provisioning credentials for a 4922 native interface, then "ACP/ANI enable" should be added as an option 4923 to that "touch". If a wrong "touch" is easily fixed (not creating 4924 another high-cost touch), then the default should be not to enable 4925 ANI/ACP, and if it is potentially expensive or slow to fix (e.g., 4926 parameters on SIM card shipped to remote location), then the default 4927 should be to enable ACP/ANI. 4929 9.3.5. Node Level ACP/ANI enable 4931 A node level command "ACP/ANI enable [up-if-only]" enables ACP or ANI 4932 on the node (ANI = ACP + BRSKI). Without this command set, any 4933 interface level "ACP/ANI enable" is ignored. Once set, ACP/ANI will 4934 operate an interface where "ACP/ANI enable" is set. Setting of 4935 interface level "ACP/ANI enable" is either automatic (default) or 4936 explicit through operator action as described in the previous 4937 section. 4939 If the option "up-if-only" is selected, the behavior of "down" 4940 interfaces is unchanged, and ACP/ANI will only operate on interfaces 4941 where "ACP/ANI enable" is set and that are "up". When it is not set, 4942 then "down" state of interfaces with "ACP/ANI enable" is modified to 4943 behave as "admin down". 4945 9.3.5.1. Brownfield nodes 4947 A "brownfield" node is one that already has a configured Data-Plane. 4949 Executing global "ACP/ANI enable [up-if-only]" on each node is the 4950 only command necessary to create an ACP across a network of 4951 brownfield nodes once all the nodes have a domain certificate. When 4952 BRSKI is used ("ANI enable"), provisioning of the certificates only 4953 requires set-up of a single BRSKI registrar node which could also 4954 implement a CA for the network. This is the most simple way to 4955 introduce ACP/ANI into existing (== brownfield) networks. 4957 The need to explicitly enable ACP/ANI is especially important in 4958 brownfield nodes because otherwise software updates may introduce 4959 support for ACP/ANI: Automatic enablement of ACP/ANI in networks 4960 where the operator does not only not want ACP/ANI but where the 4961 operator likely never even heard of it could be quite irritating to 4962 the operator. Especially when "down" behavior is changed to "admin 4963 down". 4965 Automatically setting "ANI enable" on brownfield nodes where the 4966 operator is unaware of BRSKI and MASA operations could also be an 4967 unlikely but then critical security issue. If an attacker could 4968 impersonate the operator and register as the operator at the MASA or 4969 otherwise get hold of vouchers and can get enough physical access to 4970 the network so pledges would register to an attacking registrar, then 4971 the attacker could gain access to the network through the ACP that 4972 the attacker then has access to. 4974 In networks where the operator explicitly wants to enable the ANI 4975 this could not happen, because the operator would create a BRSKI 4976 registrar that would discover attack attempts, and the operator would 4977 be setting up his registrar with the MASA. Nodes requiring 4978 "ownership vouchers" would not be subject to that attack. See 4979 [I-D.ietf-anima-bootstrapping-keyinfra] for more details. Note that 4980 a global "ACP enable" alone is not subject to these type of attacks, 4981 because it always depends on some other mechanism first to provision 4982 domain certificates into the device. 4984 9.3.5.2. Greenfield nodes 4986 A "greenfield" node is one that did not have any prior configuration. 4988 For greenfield nodes, only "ANI enable" is relevant. If another 4989 mechanism than BRSKI is used to (zero-touch) bootstrap a node, then 4990 it is up to that mechanism to provision domain certificates and to 4991 set global "ACP enable" as desired. 4993 Nodes supporting full ANI functionality set "ANI enable" 4994 automatically when they decide that they are greenfield, e.g., that 4995 they are powering on from factory condition. They will then put all 4996 native interfaces into "admin down" state and start to perform BRSKI 4997 pledge functionality - and once a domain certificate is enrolled they 4998 automatically enable ACP. 5000 Attempts for BRSKI pledge operations in greenfield state should 5001 terminate automatically when another method of configuring the node 5002 is used. Methods that indicate some form of physical possession of 5003 the device such as configuration via the serial console port could 5004 lead to immediate termination of BRSKI, while other parallel auto 5005 configuration methods subject to remote attacks might lead to BRSKI 5006 termination only after they were successful. Details of this may 5007 vary widely over different type of nodes. When BRSKI pledge 5008 operation terminates, this will automatically unset "ANI enable" and 5009 should terminate any temporarily needed state on the device to 5010 perform BRSKI - DULL GRASP, BRSKI pledge and any IPv6 configuration 5011 on interfaces. 5013 9.3.6. Undoing ANI/ACP enable 5015 Disabling ANI/ACP by undoing "ACP/ANI enable" is a risk for the 5016 reliable operations of the ACP if it can be executed by mistake or 5017 unauthorized. This behavior could be influenced through some 5018 additional (future) property in the certificate (e.g., in the domain 5019 information extension field): In an ANI deployment intended for 5020 convenience, disabling it could be allowed without further 5021 constraints. In an ANI deployment considered to be critical more 5022 checks would be required. One very controlled option would be to not 5023 permit these commands unless the domain certificate has been revoked 5024 or is denied renewal. Configuring this option would be a parameter 5025 on the BRSKI registrar(s). As long as the node did not receive a 5026 domain certificate, undoing "ANI/ACP enable" should not have any 5027 additional constraints. 5029 9.3.7. Summary 5031 Node-wide "ACP/ANI enable [up-if-only]" commands enable the operation 5032 of ACP/ANI. This is only auto-enabled on ANI greenfield devices, 5033 otherwise it must be configured explicitly. 5035 If the option "up-if-only" is not selected, interfaces enabled for 5036 ACP/ANI interpret "down" state as "admin down" and not "physical 5037 down". In "admin-down" all non-ACP/ANI packets are filtered, but the 5038 physical layer is kept running to permit ACP/ANI to operate. 5040 (New) commands that result in physical interruption ("physical down", 5041 "loopback") of ACP/ANI enabled interfaces should be built to protect 5042 continuance or reestablishment of ACP as much as possible. 5044 Interface level "ACP/ANI enable" control per-interface operations. 5045 It is enabled by default on native interfaces and has to be 5046 configured explicitly on other interfaces. 5048 Disabling "ACP/ANI enable" global and per-interface should have 5049 additional checks to minimize undesired breakage of ACP. The degree 5050 of control could be a domain wide parameter in the domain 5051 certificates. 5053 9.4. Configuration and the ACP (summary) 5055 There is no desirable configuration for the ACP. Instead, all 5056 parameters that need to be configured in support of the ACP are 5057 limitations of the solution, but they are only needed in cases where 5058 not all components are made autonomic. Whereever this is necessary, 5059 it relies on pre-existing mechanisms for configuration such as CLI or 5060 YANG ([RFC7950]) data models. 5062 The most important examples of such configuration include: 5064 o When ACP nodes do not support an autonomic way to receive an ACP 5065 domain certificate, for example BRSKI, then such certificate needs 5066 to be configured via some pre-existing mechanisms outside the 5067 scope of this specification. Today, router have typically a 5068 variety of mechanisms to do this. 5070 o Certificate maintenance requires PKI functions. Discovery of 5071 these functions across the ACP is automated (see Section 6.1.5), 5072 but their configuration is not. 5074 o When non-ACP capable nodes such as pre-existing NMS need to be 5075 physically connected to the ACP, the ACP node to which they attach 5076 needs to be configured with ACP-connect according to Section 8.1. 5077 It is also possible to use that single physical connection to 5078 connect both to ACP and the data-plane of the network as explained 5079 in Section 8.1.4. 5081 o When devices are not autonomically bootstrapped, explicit 5082 configuration to enable the ACP needs to be applied. See 5083 Section 9.3. 5085 o When the ACP needs to be extended across interfacess other than 5086 L2, the ACP as defined in this document can not autodiscover 5087 candidate neighbors automatically. Remote neighbors need to be 5088 configured, see Section 8.2. 5090 Once the ACP is operating, any further configuration for the data- 5091 plane can be configured more reliably across the ACP itself because 5092 the ACP provides addressing and connectivity (routing) independent of 5093 the data-plane itself. For this, the configuration methods simply 5094 need to also allow to operate across the ACP VRF - netconf, ssh or 5095 any other method. 5097 The ACP also provides additional security through its hop-by-hop 5098 encryption for any such configuration operations: Some legacy 5099 configuration methods (SNMP, TFTP, HTTP) may not use end-to-end 5100 encryption, and most of the end-to-end secured configuration methods 5101 still allow for easy passive observation along the path about 5102 configuration taking place (transport flows, port numbers, IP 5103 addresses). 5105 The ACP can and should equally be used as the transport to configure 5106 any of the aforemention non-automic components of the ACP, but in 5107 that case, the same caution needs to be exercised as with data-plane 5108 configuration without ACP: Misconfiguration may cause the configuring 5109 entity to be disconnected from the node it configures - for example 5110 when incorrectly unconfiguring a remote ACP neighbor through which 5111 the configured ACP node is reached. 5113 10. Summary: Benefits (Informative) 5114 10.1. Self-Healing Properties 5116 The ACP is self-healing: 5118 o New neighbors will automatically join the ACP after successful 5119 validation and will become reachable using their unique ULA 5120 address across the ACP. 5122 o When any changes happen in the topology, the routing protocol used 5123 in the ACP will automatically adapt to the changes and will 5124 continue to provide reachability to all nodes. 5126 o The ACP tracks the validity of peer certificates and tears down 5127 ACP secure channels when a peer certificate has expired. When 5128 short-lived certificates with lifetimes in the order of OCSP/CRL 5129 refresh times are used, then this allows for removal of invalid 5130 peers (whose certificate was not renewed) at similar speeds as 5131 when using OCSP/CRL. The same benefit can be achieved when using 5132 CRL/OCSP, periodically refreshing the revocation information and 5133 also tearing down ACP secure channels when the peer's (long-lived) 5134 certificate is revoked. There is no requirement against ACP 5135 implementations to require this enhancement though to keep the 5136 mandatory implementations simpler. 5138 The ACP can also sustain network partitions and mergers. Practically 5139 all ACP operations are link local, where a network partition has no 5140 impact. Nodes authenticate each other using the domain certificates 5141 to establish the ACP locally. Addressing inside the ACP remains 5142 unchanged, and the routing protocol inside both parts of the ACP will 5143 lead to two working (although partitioned) ACPs. 5145 There are few central dependencies: A CRL may not be available during 5146 a network partition; a suitable policy to not immediately disconnect 5147 neighbors when no CRL is available can address this issue. Also, an 5148 ACP registrar or Certificate Authority might not be available during 5149 a partition. This may delay renewal of certificates that are to 5150 expire in the future, and it may prevent the enrollment of new nodes 5151 during the partition. 5153 Highly resilient ACP designs can be built by using ACP registrars 5154 with embedded sub-CA, as outlined in Section 9.2.4. As long as a 5155 partition is left with one or more of such ACP registrars, it can 5156 continue to enroll new candidate ACP nodes as long as the ACP 5157 registrar's sub-CA certificate does not expire. Because the ACP 5158 addressing relies on unique Registrar-IDs, a later re-merge of 5159 partitions will also not cause problems with ACP addresses assigned 5160 during partitioning. 5162 After a network partition, a re-merge will just establish the 5163 previous status, certificates can be renewed, the CRL is available, 5164 and new nodes can be enrolled everywhere. Since all nodes use the 5165 same trust anchor(s), a re-merge will be smooth. 5167 Merging two networks with different trust anchors requires the ACP 5168 nodes to trust the union of Trust Anchors. As long as the routing- 5169 subdomain hashes are different, the addressing will not overlap, 5170 which only happens in the unlikely event of a 40-bit hash collision 5171 in SHA256 (see Section 6.10). Note that the complete mechanisms to 5172 merge networks is out of scope of this specification. 5174 It is also highly desirable for implementation of the ACP to be able 5175 to run it over interfaces that are administratively down. If this is 5176 not feasible, then it might instead be possible to request explicit 5177 operator override upon administrative actions that would 5178 administratively bring down an interface across which the ACP is 5179 running. Especially if bringing down the ACP is known to disconnect 5180 the operator from the node. For example any such down administrative 5181 action could perform a dependency check to see if the transport 5182 connection across which this action is performed is affected by the 5183 down action (with default RPL routing used, packet forwarding will be 5184 symmetric, so this is actually possible to check). 5186 10.2. Self-Protection Properties 5188 10.2.1. From the outside 5190 As explained in Section 6, the ACP is based on secure channels built 5191 between nodes that have mutually authenticated each other with their 5192 domain certificates. The channels themselves are protected using 5193 standard encryption technologies such as DTLS or IPsec which provide 5194 additional authentication during channel establishment, data 5195 integrity and data confidentiality protection of data inside the ACP 5196 and in addition, provide replay protection. 5198 An attacker will not be able to join the ACP unless having a valid 5199 domain certificate, also packet injection and sniffing traffic will 5200 not be possible due to the security provided by the encryption 5201 protocol. 5203 The ACP also serves as protection (through authentication and 5204 encryption) for protocols relevant to OAM that may not have secured 5205 protocol stack options or where implementation or deployment of those 5206 options fail on some vendor/product/customer limitations. This 5207 includes protocols such as SNMP ([RFC3411]), NTP ([RFC5905]), PTP 5208 ([IEEE-1588-2008]), DNS ([RFC3596]), DHCPv6 ([RFC3315]), syslog 5209 ([RFC3164]), Radius ([RFC2865]), Diameter ([RFC6733]), TACACS 5210 ([RFC1492]), IPFIX ([RFC7011]), Netflow ([RFC3954]) - just to name a 5211 few. Protection via the ACP secure hop-by-hop channels for these 5212 protocols is meant to be only a stopgap though: The ultimate goal is 5213 for these and other protocols to use end-to-end encryption utilizing 5214 the domain certificate and rely on the ACP secure channels primarily 5215 for zero-touch reliable connectivity, but not primarily for security. 5217 The remaining attack vector would be to attack the underlying ACP 5218 protocols themselves, either via directed attacks or by denial-of- 5219 service attacks. However, as the ACP is built using link-local IPv6 5220 addresses, remote attacks from the data-plane are impossible as long 5221 as the data-plane has no facilities to remotely sent IPv6 link-local 5222 packets. The only exception are ACP connected interfaces which 5223 require higher physical protection. The ULA addresses are only 5224 reachable inside the ACP context, therefore, unreachable from the 5225 Data-Plane. Also, the ACP protocols should be implemented to be 5226 attack resistant and not consume unnecessary resources even while 5227 under attack. 5229 10.2.2. From the inside 5231 The security model of the ACP is based on trusting all members of the 5232 group of nodes that receive an ACP domain certificate for the same 5233 domain. Attacks from the inside by a compromised group member are 5234 therefore the biggest challenge. 5236 Group members must be protected against attackers so that there is no 5237 easy way to compromise them, or use them as a proxy for attacking 5238 other devices across the ACP. For example, management plane 5239 functions (transport ports) should only be reachable from the ACP but 5240 not the Data-Plane. Especially for those management plane functions 5241 that have no good protection by themselves because they do not have 5242 secure end-to-end transport and to whom ACP not only provides 5243 automatic reliable connectivity but also protection against attacks. 5244 Protection across all potential attack vectors is typically easier to 5245 do in devices whose software is designed from the ground up with 5246 security in mind than with legacy software based systems where the 5247 ACP is added on as another feature. 5249 As explained above, traffic across the ACP SHOULD still be end-to-end 5250 encrypted whenever possible. This includes traffic such as GRASP, 5251 EST and BRSKI inside the ACP. This minimizes man in the middle 5252 attacks by compromised ACP group members. Such attackers cannot 5253 eavesdrop or modify communications, they can just filter them (which 5254 is unavoidable by any means). 5256 See Appendix A.10.8 for further considerations how to avoid and deal 5257 with compromised nodes. 5259 10.3. The Administrator View 5261 An ACP is self-forming, self-managing and self-protecting, therefore 5262 has minimal dependencies on the administrator of the network. 5263 Specifically, since it is (intended to be) independent of 5264 configuration, there is only limited scope for configuration errors 5265 on the ACP itself. The administrator may have the option to enable 5266 or disable the entire approach, but detailed configuration is not 5267 possible. This means that the ACP must not be reflected in the 5268 running configuration of nodes, except a possible on/off switch (and 5269 even that is undesirable). 5271 While configuration (except for Section 8 and Section 9.2) is not 5272 possible, an administrator must have full visibility of the ACP and 5273 all its parameters, to be able to do trouble-shooting. Therefore, an 5274 ACP must support all show and debug options, as for any other network 5275 function. Specifically, a network management system or controller 5276 must be able to discover the ACP, and monitor its health. This 5277 visibility of ACP operations must clearly be separated from 5278 visibility of Data-Plane so automated systems will never have to deal 5279 with ACP aspects unless they explicitly desire to do so. 5281 Since an ACP is self-protecting, a node not supporting the ACP, or 5282 without a valid domain certificate cannot connect to it. This means 5283 that by default a traditional controller or network management system 5284 cannot connect to an ACP. See Section 8.1.1 for more details on how 5285 to connect an NMS host into the ACP. 5287 11. Security Considerations 5289 After seeding an ACP by configuring at least one ACP registrar with 5290 routing-subdomain and a CA, an ACP is self-protecting and there is no 5291 need to apply configuration to make it secure (typically the ACP 5292 Registrar doubles as EST server for certificate renewal). Its 5293 security therefore does not depend on configuration. This does not 5294 include workarounds for non-autonomic components as explained in 5295 Section 8. See Section 10.2 for details of how the ACP protects 5296 itself against attacks from the outside and to a more limited degree 5297 from the inside as well. 5299 However, the security of the ACP depends on a number of other 5300 factors: 5302 o The usage of domain certificates depends on a valid supporting PKI 5303 infrastructure. If the chain of trust of this PKI infrastructure 5304 is compromised, the security of the ACP is also compromised. This 5305 is typically under the control of the network administrator. 5307 o Every ACP registrar is criticial infrastructure that needs to be 5308 hardened against attacks, similar to a CA. A malicious registrar 5309 can enroll enemy plegdes to an ACP network or break ACP routing by 5310 duplicate ACP address assignment to pledges via their ACP domain 5311 certificates. 5313 o Security can be compromised by implementation errors (bugs), as in 5314 all products. 5316 There is no prevention of source-address spoofing inside the ACP. 5317 This implies that if an attacker gains access to the ACP, it can 5318 spoof all addresses inside the ACP and fake messages from any other 5319 node. 5321 The ACP is designed to enable automation of current network 5322 management and future autonomic peer-to-peer/distributed network 5323 automation. Any ACP member can send ACP IPv6 packet to other ACP 5324 members and announce via ACP GRASP services to all ACP members 5325 without depenency against centralized components. 5327 The ACP relies on peer-to-peer authentication and authorization using 5328 ACP certificates. This security model is necessary to enable the 5329 autonomic ad-hoc any-to-any connectivity between ACP nodes. It 5330 provides infrastructure protection through hop by hop authentication 5331 and encryption - without relying on third parties. For any services 5332 where this complete autonomic peer-to-peer group security model is 5333 appropriate, the ACP domain certificate can also be used unchanged. 5334 For example for any type of data-plane routing protocol security. 5336 This ACP security model is designed primarily to protect against 5337 attack from the outside, but not against attacks from the inside. To 5338 protect against spoofing attacks from compromised on-path ACP nodes, 5339 end-to-end encryption inside the ACP is used by new ACP signaling: 5340 GRASP across the ACP using TLS. The same is expected from any non- 5341 legacy services/protocols using the ACP. Because no group-keys are 5342 used, there is no risk for impacted nodes to access end-to-end 5343 encrypted traffic from other ACP nodes. 5345 Attacks from impacted ACP nodes against the ACP are more difficult 5346 than against the data-plane because of the autoconfiguration of the 5347 ACP and the absence of configuration options that could be abused 5348 that allow to change/break ACP behavior. This is excluding 5349 configuration for workaround in support of non-autonomic components. 5351 Mitigation against compromised ACP members is possible through 5352 standard automated certificate management mechanisms including 5353 revocation and non-renewal of short-lived certificates. In this 5354 version of the specification, there are no further optimization of 5355 these mechanisms defined for the ACP (but see Appendix A.10.8). 5357 Higher layer service built using ACP domain certificates should not 5358 solely rely on undifferentiated group security when another model is 5359 more appropriate/more secure. For example central network 5360 configuration relies on a security model where only few especially 5361 trusted nodes are allowed to configure the data-plane of network 5362 nodes (CLIL, Netconf). This can be done through ACP domain 5363 certificates by differentiating them and introduce roles. See 5364 Appendix A.10.5. 5366 Fundamentally, security depends on avoiding operator and network 5367 operations automation mistakes, implementation and architecture. 5368 Autonomic approaches such as the ACP largely eliminate operator 5369 mistakes and make it easier to recover from network operations 5370 mistakes. Implementation and architectural mistakes are still 5371 possible, as in all networking technologies. 5373 Many details of ACP are designed with security in mind and discussed 5374 elsewhere in the document: 5376 IPv6 addresses used by nodes in the ACP are covered as part of the 5377 node's domain certificate as described in Section 6.1.2. This allows 5378 even verification of ownership of a peer's IPv6 address when using a 5379 connection authenticated with the domain certificate. 5381 The ACP acts as a security (and transport) substrate for GRASP inside 5382 the ACP such that GRASP is not only protected by attacks from the 5383 outside, but also by attacks from compromised inside attackers - by 5384 relying not only on hop-by-hop security of ACP secure channels, but 5385 adding end-to-end security for those GRASP messages. See 5386 Section 6.8.2. 5388 ACP provides for secure, resilient zero-touch discovery of EST 5389 servers for certificate renewal. See Section 6.1.5. 5391 ACP provides extensible, auto-configuring hop-by-hop protection of 5392 the ACP infrastructure via the negotiation of hop-by-hop secure 5393 channel protocols. See Section 6.5. 5395 The ACP is designed to minimize attacks from the outside by 5396 minimizing its dependency against any non-ACP (Data-Plane) 5397 operations/configuration on a node. See also Section 6.12.2. 5399 In combination with BRSKI, ACP enables a resilient, fully zero-touch 5400 network solution for short-lived certificates that can be renewed or 5401 re-enrolled even after unintentional expiry (e.g., because of 5402 interrupted connectivity). See Appendix A.2. 5404 Because ACP secure channels can be long lived, but certificates used 5405 may be short lived, secure channels, for example built via IPsec need 5406 to be terminated when peer certificates expire. See Section 6.7.5. 5408 The ACP is designed to minimize attacks from the outside by 5409 minimizing its dependency against any non-ACP (Data-Plane) 5410 operations/configuration on a node. See also Section 6.12.2. 5412 Section 7.2 describes how to implement a routed ACP topology 5413 operating on what effectively is a large bridge-domain when using L3/ 5414 L2 routers that operate at L2 in the data-plane. In this case, the 5415 ACP is subject to much higher likelyhood of attacks by other nodes 5416 "stealing" L2 addresses than in the actual routed case. Especially 5417 when the bridged network includes non-trusted devices such as hosts. 5418 This is a generic issue in L2 LANs. L2/L3 devices often already have 5419 some form of "port security" to prohibit this. They rely on NDP or 5420 DHCP learning of which port/MAC-address and IPv6 address belong 5421 together and block MAC/IPv6 source addresses from wrong ports. This 5422 type of function needs to be enabled to prohibit DoS attacks and 5423 specifically to protect the ACP. Likewise the GRASP DULL instance 5424 needs to ensure that the IPv6 address in the locator-option matches 5425 the source IPv6 address of the DULL GRASP packet. 5427 12. IANA Considerations 5429 This document defines the "Autonomic Control Plane". 5431 The IANA is requested to register the value "AN_ACP" (without quotes) 5432 to the GRASP Objectives Names Table in the GRASP Parameter Registry. 5433 The specification for this value is this document, Section 6.3. 5435 The IANA is requested to register the value "SRV.est" (without 5436 quotes) to the GRASP Objectives Names Table in the GRASP Parameter 5437 Registry. The specification for this value is this document, 5438 Section 6.1.5. 5440 Explanation: This document chooses the initially strange looking 5441 format "SRV." because these objective names would be in 5442 line with potential future simplification of the GRASP objective 5443 registry. Today, every name in the GRASP objective registry needs to 5444 be explicitly allocated with IANA. In the future, this type of 5445 objective names could considered to be automatically registered in 5446 that registry for the same service for which is 5447 registered according to [RFC6335]. This explanation is solely 5448 informational and has no impact on the requested registration. 5450 The IANA is requested to create an ACP Parameter Registry with 5451 currently one registry table - the "ACP Address Type" table. 5453 "ACP Address Type" Table. The value in this table are numeric values 5454 0...3 paired with a name (string). Future values MUST be assigned 5455 using the Standards Action policy defined by [RFC8126]. The 5456 following initial values are assigned by this document: 5458 0: ACP Zone Addressing Sub-Scheme (ACP RFC Figure 11) / ACP Manual 5459 Addressing Sub-Scheme (ACP RFC Section 6.10.4) 5460 1: ACP Vlong Addressing Sub-Scheme (ACP RFC Section 6.10.5) 5462 13. Acknowledgements 5464 This work originated from an Autonomic Networking project at Cisco 5465 Systems, which started in early 2010. Many people contributed to 5466 this project and the idea of the Autonomic Control Plane, amongst 5467 which (in alphabetical order): Ignas Bagdonas, Parag Bhide, Balaji 5468 BL, Alex Clemm, Yves Hertoghs, Bruno Klauser, Max Pritikin, Michael 5469 Richardson, Ravi Kumar Vadapalli. 5471 Special thanks to Brian Carpenter, Elwyn Davies, Joel Halpern and 5472 Sheng Jiang for their thorough reviews and to Pascal Thubert and 5473 Michael Richardson to provide the details for the recommendations of 5474 the use of RPL in the ACP. 5476 Thanks to Valery Smyslov for review of the IPsec and IKEv2 5477 configuration parameters. 5479 Further input, review or suggestions were received from: Rene Struik, 5480 Brian Carpenter, Benoit Claise, William Atwood and Yongkang Zhang. 5482 14. Change log [RFC Editor: Please remove] 5484 14.1. Summary of changes since entering IESG review 5486 This text replaces the prior changelog with a summary to provide 5487 guidance for further IESG review. 5489 Please see revision -21 for the individual changelogs of prior 5490 versions . 5492 14.1.1. Reviews (while in IESG review status) / status 5494 This document entered IESG review with version -13. It has since 5495 seen the following reviews: 5497 IESG: Original owner/Yes: Terry Manderson (INT). 5499 IESG: No Objection: Deborah Brungard (RTG), Alissa Cooper (GEN), 5500 Warren Kumari (OPS), Mirja Kuehlewind (TSV), Alexey Melnikov (ART), 5501 Adam Roach (ART). 5503 IESG: No Objection, not counted anymore as they have left IESG: Ben 5504 Campbell (ART), Spencer Dawkins (TSV). 5506 IESG: Open DISCUSS hopefully resolved by this version: Eric Rescorla 5507 (SEC, left IESG), Benjamin Kaduk (SEC). 5509 Other: Michael Richardson (WG), Brian Carpenter (WG), Pascal Thubert 5510 (WG), Frank Xialiang (WG), Elwyn Davies (GEN), Joel Halpern (RTGdir), 5511 Yongkang Zhang (WG), William Atwood (WG). 5513 14.1.2. BRSKI / ACP registrar related enhancements 5515 Only after ACP entered IESG review did it become clear that the in- 5516 progress BRSKI document would not provide all the explanations needed 5517 for ACP registrars as expected earlier by ACP authors. Instead, 5518 BRSKI will only specify a subset of required ACP behavior related to 5519 certificate handling and registrar. There, it became clear that the 5520 ACP draft should specify generic ACP registrar behavior independent 5521 of BRSKI so ACP could be implemented with or without BRSKI and any 5522 manual/proprietary or future standardized BRSKI alternatives (for 5523 example via NetConf) would understand the requirements for ACP 5524 registrars and its certificate handling. 5526 This lead to additional text about ACP registrars in the ACP 5527 document: 5529 1. Defined relationship ACP / ANI (ANI = ACP + BRSKI). 5531 6.1.4 (new) Overview of trust points and trust anchors required for 5532 ACP. 5534 6.1.5.5 Added explanations/requirements for Re-enrolment. 5536 6.10.7 Normative requirements for ACP registrars (BRSKI or not). 5538 10.2 Operational expectations against ACP registrars (BRSKI or not). 5540 14.1.3. Normative enhancements since start of IESG review 5542 In addition to above ACP registrar / BRSKI related enhancements there 5543 is a range of minor normative (also explanatory) enhancements since 5544 the start of IESG review: 5546 6.1.1 Hex digits in ACP domain information field now upper-case (no 5547 specific reason except that both options are equally good, but 5548 capitalized ones are used in rfc5234). 5550 6.1.5.3 Added explanations about CRLs. 5552 6.1.5.6 Added explanations of behavior under failing certificates. 5554 6.1.2 Allow ACP adddress '0' in ACP domain information field: 5555 presence of address indicates permission to build ACP secure channel 5556 to node, 0 indicates that the address of the node is assigned by 5557 (future) other means than certificate. Non-autonomic nodes have no 5558 address at all (that was in -13), and can only connect via ACP 5559 connect interfaces to ACP. 5561 6.1.3 Distinction of real ACP nodes (with address) and those with 5562 domain certificate without address added as a new rule to ACP domain 5563 membership check. 5565 6.6 Added throttling of secure-channel setup attempts. 5567 6.11.1.14 Removed requirement to handle unknown destination ACP 5568 traffic in low-end nodes that would never be RPL roots. 5570 6.12.5 Added recommendation to use IPv6 DAD. 5572 6.1.1, 6.7.1.1, 6.7.2, 6.7.3, 6.8.2 Various refined additional 5573 certificate, secure channel protocol (IPsec/IKEv2 and DTLS) and ACP 5574 GRASP TLS protocol parameter requirements to ensure interoperating 5575 implementations (from SEC-AD review). 5577 14.1.4. Explanatory enhancements since start of IESG review 5579 Beyond the functional enhancements from the previous two sections, 5580 the mayority of changes since -13 are additional explanations from 5581 review feedback, textual nits and restructuring - with no functional 5582 requirement additions/changes. 5584 1.1 Added "applicability and scope" section with summarized 5585 explanations. 5587 2.Added in-band vs. out-of-band management definitions. 5589 6.1.2 (was 6.1.1) expanded explanations of reasoning for elements of 5590 the ACP domain information field. 5592 6.1.3 refined explanations of ACP domain membership check and 5593 justifications for it. 5595 6.5 Elaborated step-by-step secure channel setup. 5597 6.10 Additional explanations for addressing modes, additional table 5598 of addressing formats (thanks MichaelR). 5600 6.10.5 introduced 'F' bit position as a better visual representation 5601 in the Vlong address space. 5603 6.11.1.1 extensive overhaul to improve readability of use of RPL 5604 (from IESG feedback of non-routing/RPL experts). 5606 6.12.2 Added caution about unconfiguring data-plane IPv6 addresses 5607 and impact to ACP (limitation of current ACP design, and pointint to 5608 more details in 10.2). 5610 10.4 New explanations / summary of configurations for ACP (aka: all 5611 config is undesirable and only required for integrating with non- 5612 autonomic components, primarily ACP-connect and Registrars). 5614 11. Textually enhanced / better structured security considerations 5615 section after IESG security review. 5617 A. (new) Moved all explanations and discussions about futures from 5618 section 10 into this new appendix. This text should not be removed 5619 because it captures a lot of repeated asked questions in WG and 5620 during reviews and from users, and also captures ideas for some 5621 likely important followup work. But none of this is relevant to 5622 implementing (section 6) and operating (section 10) the ACP. 5624 14.2. draft-ietf-anima-autonomic-control-plane-24 5626 Leftover from -23 review by Eric Vyncke: 5628 Swapping sections 9 and 10, section 9 was meant to be at end of 5629 document and summarize. Its not meant to be misinterpreted as 5630 introducing any new information. This did happen because section 10 5631 was added after section 9. 5633 14.3. draft-ietf-anima-autonomic-control-plane-23 5635 Note: big rfcdiff of TOC is an rfcdiff bug, changes really minimal. 5637 Review of IPsec security with Mcr and ipsec mailing list. 5639 6.7.1 - new section: Moved general considerations for secure channel 5640 protocols here, refined them. 5642 6.7.2 - new section: Moved common requirements for secure channel 5643 protocols here, refined them. 5645 6.7.3.1.1. - improved requirements text related to RFC8221, better 5646 explamations re. HW acceleration issues. 5648 6.7.3.1.2. - improved requirements text related to RFC8247, (some 5649 requirements still discussed to be redundant, will be finalized in 5650 next weeks. 5652 Eric Vyncke review of -21: 5654 Only noting most important changes, long list of smaller text/ 5655 readability enhancements. 5657 2. - New explanation of "normative" , "informational" section title 5658 tags. alphabetic reordering of terms, refined definitions for CA, 5659 CRL. root CA. 5661 6.1.1. - explanation when IDevID parameters may be copied into 5662 LDevID. 5664 6.1.2. - Fixed hex digits in ACP domain information to lower case. 5666 6.1.3.1. - New section on Realtime clock and Time Validation. 5668 6.3 - Added explanation that DTLS means >= version 1.2 (not only 5669 1.2). 5671 6.7 - New text in this main section explaing relationship of ACP 5672 secure channels and ACP virtual interfaces - with forward references 5673 to virtual interface section. 5675 6.8.2 - reordered text and picture, no text change. 5677 6.10.7.2 - describe first how Registrar-ID can be allocted for all 5678 type of registrars, then refined text for how to potentially use MAC 5679 addresses on physical registrars. 5681 6.11.1.1 - Added text how this profile does not use data-plane 5682 artefacts (RPI) because hadware forwarding. This was previously 5683 hidden only later in the text. 5685 6.11.1.13. - Rewrote RPL data-plane artefact text. Provide decoder 5686 ring for abbreviations and all relevant RFCs. 5688 6.12.5.2. - Added more explicit text that secure channels are mapped 5689 into virtual interfaces, moved different type of interfaces used by 5690 ACP into seperate subsections to be able to refer to them. 5692 7.2 - Rewrote/refined text for ACP on L2, prior text was confusing 5693 and did not well explain why ACP for L2/L3 switches can be 5694 implemented without any L2 (HW) changes. Also missing explanation of 5695 only running GRASP untagged when VLANs are used. 5697 8.1.1 - Added requirement for ACP Edge nodes to allow configurable 5698 filtering of IPv6 RPI headers. 5700 11. - (security section). Moved explanation of address stealing from 5701 7.2 to here. 5703 14.4. draft-ietf-anima-autonomic-control-plane-22 5705 Ben Kaduk review of -21: 5707 RFC822 encoding of ACP domain information: 5709 6.1.2 rewrote text for explaining / justifying use of rfc822name as 5710 identifier for node CP in certificate (was discussed in thread, but 5711 badly written in prior versions). 5713 6.1.2 Changed EBNF syntax to use "+" after rfcSELF because that is 5714 the known primary name to extensions separator in many email systems 5715 ("." was wrong in prior versions). 5717 6.1.2 Rewrote/improved explanations for use of rfc822name field to 5718 explain better why it is PKIX compliant and the right thing to do. 5720 Crypto parameters for IPsec: 5722 6.1 - Added explanation of why manual keying for ACP is not feasible 5723 for ACP. Surprisingly, that text did not exist. Referred to by 5724 IPsec text (6.7.1), but here is the right place to describe the 5725 reasoning. 5727 6.1.2 - Small textual refinement referring to requirements to 5728 authenticate peers (for the special cases of empty or '0' ACP address 5729 in ACP domain information field. 5731 6.3 - To better justify Bens proposed change of secure channel 5732 protocol being IPsec vs. GRASP objective being IKEv2, better 5733 explained how protocol indicated in GRASP objective-value is name of 5734 protocol used to negotiate secure channel, use example of IKEv2 to 5735 negotiate IPsec. 5737 6.7.1 - refinemenet similar to 6.3. 5739 - moved new paragraph from Bens pull request up from 6.7.1.1 to 6.7.1 5740 as it equally applies to GRE encapped IPsec (looks nicer one level 5741 up). 5743 - created subsections 6.7.1.1 (IPsec/ESP) / 6.7.1.2 (IKEv2) to 5744 clearer distinguish between these two requirements blocks. 5746 - Refined the text in these two sections to hopefully be a good 5747 answer to Valery's concern of not randomnly mocking with existing 5748 requirements docs (rfc8247 / rfc8221). 5750 6.7.1.1.1 - IPsec/ESP requirements section: 5752 - MUST support rfc8221 mandatory EXCEPT for the superceeding 5753 requirements in this section. Previously, this was not quite clear 5754 from the text. 5756 - Hopefully persuasive explanations about the requirements levels for 5757 ENCR_AES_GCM_16, ENCR_AES_CBC, ENCR_AES_CCM_8 and 5758 ENCR_CHACHA20_POLY1305: Restructured text for why not ENCR_AES_CBC 5759 (was in prior version, just not well structured), added new 5760 expanations for ENCR_AES_CCM_8 and ENCR_CHACHA20_POLY130. 5762 - In simple terms, requirements for ENCR_AES_CBC, ENCR_AES_CCM_8, 5763 ENCR_CHACHACHA are SHOULD when they are implementable with rqual or 5764 faster performancce than ENCR_AES_GCM_16. 5766 - Removed text about "additional rfc8221" reqiurements MAY be used. 5767 Now the logic is that all other requirements apply. Hopefully we 5768 have written enough so that we prohibited downgrades. 5770 6.7.1.1.2 - RFC8247 requirements: 5772 - Added mandate to support rfc8247, added explanation that there is 5773 no "stripping down" requirement, just additional stronger 5774 requirements to mandate correct use of ACP certificartes during 5775 authentication. 5777 - refined text on identifying ACP by IPv6 address to be clearer: 5778 Identifying in the context of IKEv2 and cases for '0' in ACP domain 5779 information. 5781 - removed last two paragraphs about relationship to rfc8247, as his 5782 is now written in first paragraph of the section. 5784 End of Ben Kaduk review related fixes. 5786 Other: 5788 Forgot to update example of ACP domain information to use capitalized 5789 hex-digits as required by HEXDIGIT used. 5791 Added reference to RFC8316 (AN use-cases) to beginning of section 3 5792 (ACP use cases). 5794 Small Enhanced IPsec parameters description / requirements fixes 5795 (from Michael Richardson). 5797 15. References 5799 15.1. Normative References 5801 [I-D.ietf-anima-grasp] 5802 Bormann, C., Carpenter, B., and B. Liu, "A Generic 5803 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 5804 grasp-15 (work in progress), July 2017. 5806 [IKEV2IANA] 5807 IANA, "Internet Key Exchange Version 2 (IKEv2) 5808 Parameters", . 5811 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 5812 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 5813 . 5815 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 5816 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 5817 DOI 10.17487/RFC3810, June 2004, 5818 . 5820 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 5821 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 5822 November 2005, . 5824 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 5825 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 5826 . 5828 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 5829 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 5830 2006, . 5832 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 5833 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 5834 December 2005, . 5836 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 5837 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 5838 DOI 10.17487/RFC4861, September 2007, 5839 . 5841 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 5842 Address Autoconfiguration", RFC 4862, 5843 DOI 10.17487/RFC4862, September 2007, 5844 . 5846 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 5847 Specifications: ABNF", STD 68, RFC 5234, 5848 DOI 10.17487/RFC5234, January 2008, 5849 . 5851 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 5852 (TLS) Protocol Version 1.2", RFC 5246, 5853 DOI 10.17487/RFC5246, August 2008, 5854 . 5856 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 5857 Housley, R., and W. Polk, "Internet X.509 Public Key 5858 Infrastructure Certificate and Certificate Revocation List 5859 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 5860 . 5862 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 5863 DOI 10.17487/RFC5322, October 2008, 5864 . 5866 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 5867 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 5868 January 2012, . 5870 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 5871 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 5872 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 5873 Low-Power and Lossy Networks", RFC 6550, 5874 DOI 10.17487/RFC6550, March 2012, 5875 . 5877 [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing 5878 Protocol for Low-Power and Lossy Networks (RPL)", 5879 RFC 6552, DOI 10.17487/RFC6552, March 2012, 5880 . 5882 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 5883 Power and Lossy Networks (RPL) Option for Carrying RPL 5884 Information in Data-Plane Datagrams", RFC 6553, 5885 DOI 10.17487/RFC6553, March 2012, 5886 . 5888 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 5889 "Enrollment over Secure Transport", RFC 7030, 5890 DOI 10.17487/RFC7030, October 2013, 5891 . 5893 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 5894 Kivinen, "Internet Key Exchange Protocol Version 2 5895 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 5896 2014, . 5898 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 5899 "Recommendations for Secure Use of Transport Layer 5900 Security (TLS) and Datagram Transport Layer Security 5901 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 5902 2015, . 5904 [RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support 5905 for Generic Routing Encapsulation (GRE)", RFC 7676, 5906 DOI 10.17487/RFC7676, October 2015, 5907 . 5909 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 5910 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 5911 May 2017, . 5913 [RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T. 5914 Kivinen, "Cryptographic Algorithm Implementation 5915 Requirements and Usage Guidance for Encapsulating Security 5916 Payload (ESP) and Authentication Header (AH)", RFC 8221, 5917 DOI 10.17487/RFC8221, October 2017, 5918 . 5920 [RFC8247] Nir, Y., Kivinen, T., Wouters, P., and D. Migault, 5921 "Algorithm Implementation Requirements and Usage Guidance 5922 for the Internet Key Exchange Protocol Version 2 (IKEv2)", 5923 RFC 8247, DOI 10.17487/RFC8247, September 2017, 5924 . 5926 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 5927 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 5928 . 5930 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 5931 Definition Language (CDDL): A Notational Convention to 5932 Express Concise Binary Object Representation (CBOR) and 5933 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 5934 June 2019, . 5936 15.2. Informative References 5938 [AR8021] Group, W. -. H. L. L. P. W., "IEEE Standard for Local and 5939 metropolitan area networks - Secure Device Identity", 5940 December 2009, . 5943 [CABFORUM] 5944 CA/Browser Forum, "Certificate Contents for Baseline SSL", 5945 Nov 2019, . 5948 [I-D.eckert-anima-noc-autoconfig] 5949 Eckert, T., "Autoconfiguration of NOC services in ACP 5950 networks via GRASP", draft-eckert-anima-noc-autoconfig-00 5951 (work in progress), July 2018. 5953 [I-D.ietf-acme-star] 5954 Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T. 5955 Fossati, "Support for Short-Term, Automatically-Renewed 5956 (STAR) Certificates in Automated Certificate Management 5957 Environment (ACME)", draft-ietf-acme-star-11 (work in 5958 progress), October 2019. 5960 [I-D.ietf-anima-bootstrapping-keyinfra] 5961 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 5962 and K. Watsen, "Bootstrapping Remote Secure Key 5963 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 5964 keyinfra-35 (work in progress), February 2020. 5966 [I-D.ietf-anima-prefix-management] 5967 Jiang, S., Du, Z., Carpenter, B., and Q. Sun, "Autonomic 5968 IPv6 Edge Prefix Management in Large-scale Networks", 5969 draft-ietf-anima-prefix-management-07 (work in progress), 5970 December 2017. 5972 [I-D.ietf-anima-reference-model] 5973 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 5974 and J. Nobre, "A Reference Model for Autonomic 5975 Networking", draft-ietf-anima-reference-model-10 (work in 5976 progress), November 2018. 5978 [I-D.ietf-roll-applicability-template] 5979 Richardson, M., "ROLL Applicability Statement Template", 5980 draft-ietf-roll-applicability-template-09 (work in 5981 progress), May 2016. 5983 [I-D.ietf-roll-useofrplinfo] 5984 Robles, I., Richardson, M., and P. Thubert, "Using RPI 5985 option Type, Routing Header for Source Routes and IPv6-in- 5986 IPv6 encapsulation in the RPL Data Plane", draft-ietf- 5987 roll-useofrplinfo-36 (work in progress), February 2020. 5989 [I-D.ietf-tls-dtls13] 5990 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 5991 Datagram Transport Layer Security (DTLS) Protocol Version 5992 1.3", draft-ietf-tls-dtls13-34 (work in progress), 5993 November 2019. 5995 [IEEE-1588-2008] 5996 IEEE, "IEEE Standard for a Precision Clock Synchronization 5997 Protocol for Networked Measurement and Control Systems", 5998 December 2008, . 6001 [IEEE-802.1X] 6002 Group, W. -. H. L. L. P. W., "IEEE Standard for Local and 6003 Metropolitan Area Networks: Port-Based Network Access 6004 Control", February 2010, 6005 . 6008 [LLDP] Group, W. -. H. L. L. P. W., "IEEE Standard for Local and 6009 Metropolitan Area Networks: Station and Media Access 6010 Control Connectivity Discovery", June 2016, 6011 . 6014 [MACSEC] Group, W. -. H. L. L. P. W., "IEEE Standard for Local and 6015 Metropolitan Area Networks: Media Access Control (MAC) 6016 Security", June 2006, 6017 . 6020 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 6021 RFC 1112, DOI 10.17487/RFC1112, August 1989, 6022 . 6024 [RFC1492] Finseth, C., "An Access Control Protocol, Sometimes Called 6025 TACACS", RFC 1492, DOI 10.17487/RFC1492, July 1993, 6026 . 6028 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 6029 and E. Lear, "Address Allocation for Private Internets", 6030 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 6031 . 6033 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 6034 Requirement Levels", BCP 14, RFC 2119, 6035 DOI 10.17487/RFC2119, March 1997, 6036 . 6038 [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax 6039 Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998, 6040 . 6042 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 6043 (IKE)", RFC 2409, DOI 10.17487/RFC2409, November 1998, 6044 . 6046 [RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", 6047 RFC 2821, DOI 10.17487/RFC2821, April 2001, 6048 . 6050 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 6051 "Remote Authentication Dial In User Service (RADIUS)", 6052 RFC 2865, DOI 10.17487/RFC2865, June 2000, 6053 . 6055 [RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, 6056 DOI 10.17487/RFC3164, August 2001, 6057 . 6059 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 6060 C., and M. Carney, "Dynamic Host Configuration Protocol 6061 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 6062 2003, . 6064 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 6065 Architecture for Describing Simple Network Management 6066 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 6067 DOI 10.17487/RFC3411, December 2002, 6068 . 6070 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 6071 "DNS Extensions to Support IP Version 6", STD 88, 6072 RFC 3596, DOI 10.17487/RFC3596, October 2003, 6073 . 6075 [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export 6076 Version 9", RFC 3954, DOI 10.17487/RFC3954, October 2004, 6077 . 6079 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 6080 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 6081 DOI 10.17487/RFC4007, March 2005, 6082 . 6084 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 6085 "Internet X.509 Public Key Infrastructure Certificate 6086 Management Protocol (CMP)", RFC 4210, 6087 DOI 10.17487/RFC4210, September 2005, 6088 . 6090 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 6091 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 6092 2006, . 6094 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 6095 for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, 6096 . 6098 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 6099 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 6100 for Transport Layer Security (TLS)", RFC 4492, 6101 DOI 10.17487/RFC4492, May 2006, 6102 . 6104 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 6105 "Considerations for Internet Group Management Protocol 6106 (IGMP) and Multicast Listener Discovery (MLD) Snooping 6107 Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, 6108 . 6110 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 6111 Group Management Protocol Version 3 (IGMPv3) and Multicast 6112 Listener Discovery Protocol Version 2 (MLDv2) for Source- 6113 Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, 6114 August 2006, . 6116 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 6117 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 6118 . 6120 [RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol 6121 Independent Multicast (PIM)", RFC 4610, 6122 DOI 10.17487/RFC4610, August 2006, 6123 . 6125 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 6126 Extensions for Stateless Address Autoconfiguration in 6127 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 6128 . 6130 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 6131 DOI 10.17487/RFC5321, October 2008, 6132 . 6134 [RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet 6135 Group Management Protocol Version 3 (IGMPv3) and Multicast 6136 Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, 6137 DOI 10.17487/RFC5790, February 2010, 6138 . 6140 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 6141 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 6142 . 6144 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 6145 "Network Time Protocol Version 4: Protocol and Algorithms 6146 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 6147 . 6149 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 6150 and A. Bierman, Ed., "Network Configuration Protocol 6151 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 6152 . 6154 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 6155 Cheshire, "Internet Assigned Numbers Authority (IANA) 6156 Procedures for the Management of the Service Name and 6157 Transport Protocol Port Number Registry", BCP 165, 6158 RFC 6335, DOI 10.17487/RFC6335, August 2011, 6159 . 6161 [RFC6402] Schaad, J., "Certificate Management over CMS (CMC) 6162 Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011, 6163 . 6165 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 6166 of Interpretation", RFC 6407, DOI 10.17487/RFC6407, 6167 October 2011, . 6169 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 6170 Routing Header for Source Routes with the Routing Protocol 6171 for Low-Power and Lossy Networks (RPL)", RFC 6554, 6172 DOI 10.17487/RFC6554, March 2012, 6173 . 6175 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 6176 "Default Address Selection for Internet Protocol Version 6 6177 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 6178 . 6180 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 6181 Ed., "Diameter Base Protocol", RFC 6733, 6182 DOI 10.17487/RFC6733, October 2012, 6183 . 6185 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 6186 DOI 10.17487/RFC6762, February 2013, 6187 . 6189 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 6190 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 6191 . 6193 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 6194 Locator/ID Separation Protocol (LISP)", RFC 6830, 6195 DOI 10.17487/RFC6830, January 2013, 6196 . 6198 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 6199 "Specification of the IP Flow Information Export (IPFIX) 6200 Protocol for the Exchange of Flow Information", STD 77, 6201 RFC 7011, DOI 10.17487/RFC7011, September 2013, 6202 . 6204 [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local 6205 Addressing inside an IPv6 Network", RFC 7404, 6206 DOI 10.17487/RFC7404, November 2014, 6207 . 6209 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 6210 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 6211 Defined Networking (SDN): Layers and Architecture 6212 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 6213 2015, . 6215 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 6216 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 6217 Networking: Definitions and Design Goals", RFC 7575, 6218 DOI 10.17487/RFC7575, June 2015, 6219 . 6221 [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap 6222 Analysis for Autonomic Networking", RFC 7576, 6223 DOI 10.17487/RFC7576, June 2015, 6224 . 6226 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 6227 Considerations for IPv6 Address Generation Mechanisms", 6228 RFC 7721, DOI 10.17487/RFC7721, March 2016, 6229 . 6231 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 6232 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 6233 Multicast - Sparse Mode (PIM-SM): Protocol Specification 6234 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 6235 2016, . 6237 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 6238 RFC 7950, DOI 10.17487/RFC7950, August 2016, 6239 . 6241 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 6242 Hosts in a Multi-Prefix Network", RFC 8028, 6243 DOI 10.17487/RFC8028, November 2016, 6244 . 6246 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 6247 Writing an IANA Considerations Section in RFCs", BCP 26, 6248 RFC 8126, DOI 10.17487/RFC8126, June 2017, 6249 . 6251 [RFC8316] Nobre, J., Granville, L., Clemm, A., and A. Gonzalez 6252 Prieto, "Autonomic Networking Use Case for Distributed 6253 Detection of Service Level Agreement (SLA) Violations", 6254 RFC 8316, DOI 10.17487/RFC8316, February 2018, 6255 . 6257 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 6258 "A Voucher Artifact for Bootstrapping Protocols", 6259 RFC 8366, DOI 10.17487/RFC8366, May 2018, 6260 . 6262 [RFC8368] Eckert, T., Ed. and M. Behringer, "Using an Autonomic 6263 Control Plane for Stable Connectivity of Network 6264 Operations, Administration, and Maintenance (OAM)", 6265 RFC 8368, DOI 10.17487/RFC8368, May 2018, 6266 . 6268 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 6269 Touch Provisioning (SZTP)", RFC 8572, 6270 DOI 10.17487/RFC8572, April 2019, 6271 . 6273 15.3. URIs 6275 [1] https://en.wikipedia.org/wiki/Operational_Technology 6277 [2] https://en.wikipedia.org/wiki/Single-root_input/ 6278 output_virtualization 6280 Appendix A. Background and Futures (Informative) 6282 The following sections discuss additional background information 6283 about aspects of the normative parts of this document or associated 6284 mechanisms such as BRSKI (such as why specific choices were made by 6285 the ACP) and they provide discussion about possible future variations 6286 of the ACP. 6288 A.1. ACP Address Space Schemes 6290 This document defines the Zone, Vlong and Manual sub address schemes 6291 primarily to support address prefix assignment via distributed, 6292 potentially uncoordinated ACP registrars as defined in 6293 Section 6.10.7. This costs 48/46-bit identifier so that these ACP 6294 registrar can assign non-conflicting address prefixes. This design 6295 does not leave enough bits to simultaneously support a large number 6296 of nodes (Node-ID) plus a large prefix of local addresses for every 6297 node plus a large enough set of bits to identify a routing Zone. In 6298 result, Zone, Vlong 8/16 attempt to support all features, but in via 6299 separate prefixes. 6301 In networks that always expect to rely on a centralized PMS as 6302 described above (Section 9.2.5), the 48/46-bits for the Registrar-ID 6303 could be saved. Such variations of the ACP addressing mechanisms 6304 could be introduced through future work in different ways. If the 6305 prefix rfcSELF in the ACP information field was changed, incompatible 6306 ACP variations could be created where every design aspect of the ACP 6307 could be changed. Including all addressing choices. If instead a 6308 new addressing sub-type would be defined, it could be a backward 6309 compatible extension of this ACP specification. Information such as 6310 the size of a zone-prefix and the length of the prefix assigned to 6311 the ACP node itself could be encoded via the extension field of the 6312 ACP domain information. 6314 Note that an explicitly defined "Manual" addressing sub-scheme is 6315 always beneficial to provide an easy way for ACP nodes to prohibit 6316 incorrect manual configuration of any non-"Manual" ACP address spaces 6317 and therefore ensure that "Manual" operations will never impact 6318 correct routing for any non-"Manual" ACP addresses assigned via ACP 6319 domain certificates. 6321 A.2. BRSKI Bootstrap (ANI) 6323 BRSKI describes how nodes with an IDevID certificate can securely and 6324 zero-touch enroll with an LDevID to support the ACP. BRSKI also 6325 leverages the ACP to enable zero-touch bootstrap of new nodes across 6326 networks without any configuration requirements across the transit 6327 nodes (e.g., no DHCP/DNS forwarding/server setup). This includes 6328 otherwise not configured networks as described in Section 3.2. 6329 Therefore BRSKI in conjunction with ACP provides for a secure and 6330 zero-touch management solution for complete networks. Nodes 6331 supporting such an infrastructure (BRSKI and ACP) are called ANI 6332 nodes (Autonomic Networking Infrastructure), see 6333 [I-D.ietf-anima-reference-model]. Nodes that do not support an 6334 IDevID but only an (insecure) vendor specific Unique Device 6335 Identifier (UDI) or nodes whose manufacturer does not support a MASA 6336 could use some future security reduced version of BRSKI. 6338 When BRSKI is used to provision a domain certificate (which is called 6339 enrollment), the BRSKI registrar (acting as an enhanced EST server) 6340 must include the subjectAltName / rfc822Name encoded ACP address and 6341 domain name to the enrolling node (called pledge) via its response to 6342 the pledges EST CSR Attribute request that is mandatory in BRSKI. 6344 The Certificate Authority in an ACP network must not change the 6345 subjectAltName / rfc822Name in the certificate. The ACP nodes can 6346 therefore find their ACP address and domain using this field in the 6347 domain certificate, both for themselves, as well as for other nodes. 6349 The use of BRSKI in conjunction with the ACP can also help to further 6350 simplify maintenance and renewal of domain certificates. Instead of 6351 relying on CRL, the lifetime of certificates can be made extremely 6352 small, for example in the order of hours. When a node fails to 6353 connect to the ACP within its certificate lifetime, it cannot connect 6354 to the ACP to renew its certificate across it (using just EST), but 6355 it can still renew its certificate as an "enrolled/expired pledge" 6356 via the BRSKI bootstrap proxy. This requires only that the BRSKI 6357 registrar honors expired domain certificates and that the pledge 6358 attempts to perform TLS authentication for BRSKI bootstrap using its 6359 expired domain certificate before falling back to attempting to use 6360 its IDevID for BRSKI. This mechanism could also render CRLs 6361 unnecessary because the BRSKI registrar in conjunction with the CA 6362 would not renew revoked certificates - only a "Do-not-renew" list 6363 would be necessary on BRSKI registrars/CA. 6365 In the absence of BRSKI or less secure variants thereof, provisioning 6366 of certificates may involve one or more touches or non-standardized 6367 automation. Node vendors usually support provisioning of 6368 certificates into nodes via PKCS#7 (see [RFC2315]) and may support 6369 this provisioning through vendor specific models via Netconf 6370 ([RFC6241]). If such nodes also support Netconf Zero-Touch 6371 ([RFC8572]) then this can be combined to zero-touch provisioning of 6372 domain certificates into nodes. Unless there are equivalent 6373 integration of Netconf connections across the ACP as there is in 6374 BRSKI, this combination would not support zero-touch bootstrap across 6375 a not configured network though. 6377 A.3. ACP Neighbor discovery protocol selection 6379 This section discusses why GRASP DULL was chosen as the discovery 6380 protocol for L2 adjacent candidate ACP neighbors. The contenders 6381 considered where GRASP, mDNS or LLDP. 6383 A.3.1. LLDP 6385 LLDP and Cisco's earlier Cisco Discovery Protocol (CDP) are example 6386 of L2 discovery protocols that terminate their messages on L2 ports. 6387 If those protocols would be chosen for ACP neighbor discovery, ACP 6388 neighbor discovery would therefore also terminate on L2 ports. This 6389 would prevent ACP construction over non-ACP capable but LLDP or CDP 6390 enabled L2 switches. LLDP has extensions using different MAC 6391 addresses and this could have been an option for ACP discovery as 6392 well, but the additional required IEEE standardization and definition 6393 of a profile for such a modified instance of LLDP seemed to be more 6394 work than the benefit of "reusing the existing protocol" LLDP for 6395 this very simple purpose. 6397 A.3.2. mDNS and L2 support 6399 Multicast DNNS (mDNS) [RFC6762] with DNS Service Discovery (DNS-SD) 6400 Resource Records (RRs) as defined in [RFC6763] is a key contender as 6401 an ACP discovery protocol. because it relies on link-local IP 6402 multicast, it does operates at the subnet level, and is also found in 6403 L2 switches. The authors of this document are not aware of mDNS 6404 implementation that terminate their mDNS messages on L2 ports instead 6405 of the subnet level. If mDNS was used as the ACP discovery mechanism 6406 on an ACP capable (L3)/L2 switch as outlined in Section 7, then this 6407 would be necessary to implement. It is likely that termination of 6408 mDNS messages could only be applied to all mDNS messages from such a 6409 port, which would then make it necessary to software forward any non- 6410 ACP related mDNS messages to maintain prior non-ACP mDNS 6411 functionality. Adding support for ACP into such L2 switches with 6412 mDNS could therefore create regression problems for prior mDNS 6413 functionality on those nodes. With low performance of software 6414 forwarding in many L2 switches, this could also make the ACP risky to 6415 support on such L2 switches. 6417 A.3.3. Why DULL GRASP 6419 LLDP was not considered because of the above mentioned issues. mDNS 6420 was not selected because of the above L2 mDNS considerations and 6421 because of the following additional points: 6423 If mDNS was not already existing in a node, it would be more work to 6424 implement than DULL GRASP, and if an existing implementation of mDNS 6425 was used, it would likely be more code space than a separate 6426 implementation of DULL GRASP or a shared implementation of DULL GRASP 6427 and GRASP in the ACP. 6429 A.4. Choice of routing protocol (RPL) 6431 This section motivates why RPL - "IPv6 Routing Protocol for Low-Power 6432 and Lossy Networks ([RFC6550] was chosen as the default (and in this 6433 specification only) routing protocol for the ACP. The choice and 6434 above explained profile was derived from a pre-standard 6435 implementation of ACP that was successfully deployed in operational 6436 networks. 6438 Requirements for routing in the ACP are: 6440 o Self-management: The ACP must build automatically, without human 6441 intervention. Therefore routing protocol must also work 6442 completely automatically. RPL is a simple, self-managing 6443 protocol, which does not require zones or areas; it is also self- 6444 configuring, since configuration is carried as part of the 6445 protocol (see Section 6.7.6 of [RFC6550]). 6447 o Scale: The ACP builds over an entire domain, which could be a 6448 large enterprise or service provider network. The routing 6449 protocol must therefore support domains of 100,000 nodes or more, 6450 ideally without the need for zoning or separation into areas. RPL 6451 has this scale property. This is based on extensive use of 6452 default routing. 6454 o Low resource consumption: The ACP supports traditional network 6455 infrastructure, thus runs in addition to traditional protocols. 6456 The ACP, and specifically the routing protocol must have low 6457 resource consumption both in terms of memory and CPU requirements. 6458 Specifically, at edge nodes, where memory and CPU are scarce, 6459 consumption should be minimal. RPL builds a DODAG, where the main 6460 resource consumption is at the root of the DODAG. The closer to 6461 the edge of the network, the less state needs to be maintained. 6462 This adapts nicely to the typical network design. Also, all 6463 changes below a common parent node are kept below that parent 6464 node. 6466 o Support for unstructured address space: In the Autonomic 6467 Networking Infrastructure, node addresses are identifiers, and may 6468 not be assigned in a topological way. Also, nodes may move 6469 topologically, without changing their address. Therefore, the 6470 routing protocol must support completely unstructured address 6471 space. RPL is specifically made for mobile ad-hoc networks, with 6472 no assumptions on topologically aligned addressing. 6474 o Modularity: To keep the initial implementation small, yet allow 6475 later for more complex methods, it is highly desirable that the 6476 routing protocol has a simple base functionality, but can import 6477 new functional modules if needed. RPL has this property with the 6478 concept of "objective function", which is a plugin to modify 6479 routing behavior. 6481 o Extensibility: Since the Autonomic Networking Infrastructure is a 6482 new concept, it is likely that changes in the way of operation 6483 will happen over time. RPL allows for new objective functions to 6484 be introduced later, which allow changes to the way the routing 6485 protocol creates the DAGs. 6487 o Multi-topology support: It may become necessary in the future to 6488 support more than one DODAG for different purposes, using 6489 different objective functions. RPL allow for the creation of 6490 several parallel DODAGs, should this be required. This could be 6491 used to create different topologies to reach different roots. 6493 o No need for path optimization: RPL does not necessarily compute 6494 the optimal path between any two nodes. However, the ACP does not 6495 require this today, since it carries mainly non-delay-sensitive 6496 feedback loops. It is possible that different optimization 6497 schemes become necessary in the future, but RPL can be expanded 6498 (see point "Extensibility" above). 6500 A.5. ACP Information Distribution and multicast 6502 IP multicast is not used by the ACP because the ANI (Autonomic 6503 Networking Infrastructure) itself does not require IP multicast but 6504 only service announcement/discovery. Using IP multicast for that 6505 would have made it necessary to develop a zero-touch auto configuring 6506 solution for ASM (Any Source Multicast - the original form of IP 6507 multicast defined in [RFC1112]), which would be quite complex and 6508 difficult to justify. One aspect of complexity where no attempt at a 6509 solution has been described in IETF documents is the automatic- 6510 selection of routers that should be PIM Sparse Mode (PIM-SM) 6511 Rendezvous Points (RPs) (see [RFC7761]). The other aspects of 6512 complexity are the implementation of MLD ([RFC4604]), PIM-SM and 6513 Anycast-RP (see [RFC4610]). If those implementations already exist 6514 in a product, then they would be very likely tied to accelerated 6515 forwarding which consumes hardware resources, and that in return is 6516 difficult to justify as a cost of performing only service discovery. 6518 Some future ASA may need high performance in-network data 6519 replication. That is the case when the use of IP multicast is 6520 justified. Such an ASA can then use service discovery from ACP 6521 GRASP, and then they do not need ASM but only SSM (Source Specific 6522 Multicast, see [RFC4607]) for the IP multicast replication. SSM 6523 itself can simply be enabled in the Data-Plane (or even in an update 6524 to the ACP) without any other configuration than just enabling it on 6525 all nodes and only requires a simpler version of MLD (see [RFC5790]). 6527 LSP (Link State Protocol) based IGP routing protocols typically have 6528 a mechanism to flood information, and such a mechanism could be used 6529 to flood GRASP objectives by defining them to be information of that 6530 IGP. This would be a possible optimization in future variations of 6531 the ACP that do use an LSP routing protocol. Note though that such a 6532 mechanism would not work easily for GRASP M_DISCOVERY messages which 6533 are intelligently (constrained) flooded not across the whole ACP, but 6534 only up to a node where a responder is found. We do expect that many 6535 future services in ASA will have only few consuming ASA, and for 6536 those cases, M_DISCOVERY is the more efficient method than flooding 6537 across the whole domain. 6539 Because the ACP uses RPL, one desirable future extension is to use 6540 RPLs existing notion of DODAG, which are loop-free distribution 6541 trees, to make GRASP flooding more efficient both for M_FLOOD and 6542 M_DISCOVERY. See Section 6.12.5 how this will be specifically 6543 beneficial when using NBMA interfaces. This is not currently 6544 specified in this document because it is not quite clear yet what 6545 exactly the implications are to make GRASP flooding depend on RPL 6546 DODAG convergence and how difficult it would be to let GRASP flooding 6547 access the DODAG information. 6549 A.6. Extending ACP channel negotiation (via GRASP) 6551 [RFC Editor: This section to be removed before RFC. 6553 [This section kept for informational purposes up until the last draft 6554 version as that would be the version that readers interested in the 6555 changelog would also go to to revisit it.] 6557 The mechanism described in the normative part of this document to 6558 support multiple different ACP secure channel protocols without a 6559 single network wide MTI protocol is important to allow extending 6560 secure ACP channel protocols beyond what is specified in this 6561 document, but it will run into problem if it would be used for 6562 multiple protocols: 6564 The need to potentially have multiple of these security associations 6565 even temporarily run in parallel to determine which of them works 6566 best does not support the most lightweight implementation options. 6568 The simple policy of letting one side (Alice) decide what is best may 6569 not lead to the mutual best result. 6571 The two limitations can easier be solved if the solution was more 6572 modular and as few as possible initial secure channel negotiation 6573 protocols would be used, and these protocols would then take on the 6574 responsibility to support more flexible objectives to negotiate the 6575 mutually preferred ACP security channel protocol. 6577 IKEv2 is the IETF standard protocol to negotiate network security 6578 associations. It is meant to be extensible, but it is unclear 6579 whether it would be feasible to extend IKEv2 to support possible 6580 future requirements for ACP secure channel negotiation: 6582 Consider the simple case where the use of native IPsec vs. IPsec via 6583 GRE is to be negotiated and the objective is the maximum throughput. 6584 Both sides would indicate some agreed upon performance metric and the 6585 preferred encapsulation is the one with the higher performance of the 6586 slower side. IKEv2 does not support negotiation with such 6587 objectives. 6589 Consider DTLS and some form of MacSec are to be added as negotiation 6590 options - and the performance objective should work across all IPsec, 6591 DTLS and MacSec options. In the case of MacSEC, the negotiation 6592 would also need to determine a key for the peering. It is unclear if 6593 it would be even appropriate to consider extending the scope of 6594 negotiation in IKEv2 to those cases. Even if feasible to define, it 6595 is unclear if implementations of IKEv2 would be eager to adopt those 6596 type of extension given the long cycles of security testing that 6597 necessarily goes along with core security protocols such as IKEv2 6598 implementations. 6600 A more modular alternative to extending IKEv2 could be to layer a 6601 modular negotiation mechanism on top of the multitude of existing or 6602 possible future secure channel protocols. For this, GRASP over TLS 6603 could be considered as a first ACP secure channel negotiation 6604 protocol. The following are initial considerations for such an 6605 approach. A full specification is subject to a separate document: 6607 To explicitly allow negotiation of the ACP channel protocol, GRASP 6608 over a TLS connection using the GRASP_LISTEN_PORT and the node's and 6609 peer's link-local IPv6 address is used. When Alice and Bob support 6610 GRASP negotiation, they do prefer it over any other non-explicitly 6611 negotiated security association protocol and should wait trying any 6612 non-negotiated ACP channel protocol until after it is clear that 6613 GRASP/TLS will not work to the peer. 6615 When Alice and Bob successfully establish the GRASP/TSL session, they 6616 will negotiate the channel mechanism to use using objectives such as 6617 performance and perceived quality of the security. After agreeing on 6618 a channel mechanism, Alice and Bob start the selected Channel 6619 protocol. Once the secure channel protocol is successfully running, 6620 the GRASP/TLS connection can be kept alive or timed out as long as 6621 the selected channel protocol has a secure association between Alice 6622 and Bob. When it terminates, it needs to be re-negotiated via GRASP/ 6623 TLS. 6625 Notes: 6627 o Negotiation of a channel type may require IANA assignments of code 6628 points. 6630 o TLS is subject to reset attacks, which IKEv2 is not. Normally, 6631 ACP connections (as specified in this document) will be over link- 6632 local addresses so the attack surface for this one issue in TCP 6633 should be reduced (note that this may not be true when ACP is 6634 tunneled as described in Section 8.2.2. 6636 o GRASP packets received inside a TLS connection established for 6637 GRASP/TLS ACP negotiation are assigned to a separate GRASP domain 6638 unique to that TLS connection. 6640 A.7. CAs, domains and routing subdomains 6642 There is a wide range of setting up different ACP solution by 6643 appropriately using CAs and the domain and rsub elements in the 6644 domain information field of the domain certificate. We summarize 6645 these options here as they have been explained in different parts of 6646 the document in before and discuss possible and desirable extensions: 6648 An ACP domain is the set of all ACP nodes using certificates from one 6649 or more Trust Anchors (typically one CA) using the same domain field. 6650 GRASP inside the ACP is run across all transitively connected ACP 6651 nodes in a domain. 6653 The rsub element in the domain information field permits the use of 6654 addresses from different ULA prefixes. One use case is to create 6655 multiple physical networks that initially may be separated with one 6656 ACP domain but different routing subdomains, so that all nodes can 6657 mutual trust their ACP domain certificates (not depending on rsub) 6658 and so that they could connect later together into a contiguous ACP 6659 network. 6661 One instance of such a use case is an ACP for regions interconnected 6662 via a non-ACP enabled core, for example due to the absence of product 6663 support for ACP on the core nodes. ACP connect configurations as 6664 defined in this document can be used to extend and interconnect those 6665 ACP islands to the NOC and merge them into a single ACP when later 6666 that product support gap is closed. 6668 Note that RPL scales very well. It is not necessary to use multiple 6669 routing subdomains to scale ACP domains in a way it would be possible 6670 if other routing protocols where used. They exist only as options 6671 for the above mentioned reasons. 6673 If different ACP domains are to be created that should not allow to 6674 connect to each other by default, these ACP domains simply need to 6675 have different domain elements in the domain information field. 6676 These domain elements can be arbitrary, including subdomains of one 6677 another: Domains "example.com" and "research.example.com" are 6678 separate domains if both are domain elements in the domain 6679 information element of certificates. 6681 It is not necessary to have a separate CA for different ACP domains: 6682 an operator can use a single CA to sign certificates for multiple ACP 6683 domains that are not allowed to connect to each other because the 6684 checks for ACP adjacencies includes comparison of the domain part. 6686 If multiple independent networks choose the same domain name but had 6687 their own CA, these would not form a single ACP domain because of CA 6688 mismatch. Therefore there is no problem in choosing domain names 6689 that are potentially also used by others. Nevertheless it is highly 6690 recommended to use domain names that one can have high probability to 6691 be unique. It is recommended to use domain names that start with a 6692 DNS domain names owned by the assigning organization and unique 6693 within it. For example "acp.example.com" if you own "example.com". 6695 A.8. Intent for the ACP 6697 Intent is the architecture component of autonomic networks according 6698 to [I-D.ietf-anima-reference-model] that allows operators to issue 6699 policies to the network. Its applicability for use is quite flexible 6700 and freeform, with potential applications including policies flooded 6701 across ACP GRASP and interpreted on every ACP node. 6703 One concern for future definitions of Intent solutions is the problem 6704 of circular dependencies when expressing Intent policies about the 6705 ACP itself. 6707 For example, Intent could indicate the desire to build an ACP across 6708 all domains that have a common parent domain (without relying on the 6709 rsub/routing-subdomain solution defined in this document). For 6710 example ACP nodes with domain "example.com", "access.example.com", 6711 "core.example.com" and "city.core.example.com" should all establish 6712 one single ACP. 6714 If each domain has its own source of Intent, then the Intent would 6715 simply have to allow adding the peer domains TA and domain names to 6716 the parameters for the ACP domain membership check (Section 6.1.3) so 6717 that nodes from those other domains are accepted as ACP peers. 6719 If this Intent was to be originated only from one domain, it could 6720 likely not be made to work because the other domains will not build 6721 any ACP connection amongst each other, whether they use the same or 6722 different CA due to the ACP domain membership check. 6724 If the domains use the same CA one could change the ACP setup to 6725 permit for the ACP to be established between two ACP nodes with 6726 different acp-domain-names, but only for the purpose of disseminating 6727 limited information, such as Intent, but not to set up full ACP 6728 connectivity, specifically not RPL routing and passing of arbitrary 6729 GRASP information. Unless the Intent policies permit this to happen 6730 across domain boundaries. 6732 This type of approach where the ACP first allows Intent to operate 6733 and only then sets up the rest of ACP connectivity based on Intent 6734 policy could also be used to enable Intent policies that would limit 6735 functionality across the ACP inside a domain, as long as no policy 6736 would disturb the distribution of Intent. For example to limit 6737 reachability across the ACP to certain type of nodes or locations of 6738 nodes. 6740 A.9. Adopting ACP concepts for other environments 6742 The ACP as specified in this document is very explicit about the 6743 choice of options to allow interoperable implementations. The 6744 choices made may not be the best for all environments, but the 6745 concepts used by the ACP can be used to build derived solutions: 6747 The ACP specifies the use of ULA and deriving its prefix from the 6748 domain name so that no address allocation is required to deploy the 6749 ACP. The ACP will equally work not using ULA but any other /48 IPv6 6750 prefix. This prefix could simply be a configuration of the ACP 6751 registrars (for example when using BRSKI) to enroll the domain 6752 certificates - instead of the ACP registrar deriving the /48 ULA 6753 prefix from the AN domain name. 6755 Some solutions may already have an auto-addressing scheme, for 6756 example derived from existing unique device identifiers (e.g., MAC 6757 addresses). In those cases it may not be desirable to assign 6758 addresses to devices via the ACP address information field in the way 6759 described in this document. The certificate may simply serve to 6760 identify the ACP domain, and the address field could be empty/unused. 6761 The only fix required in the remaining way the ACP operate is to 6762 define another element in the domain certificate for the two peers to 6763 decide who is Alice and who is Bob during secure channel building. 6764 Note though that future work may leverage the acp address to 6765 authenticate "ownership" of the address by the device. If the 6766 address used by a device is derived from some pre-existing permanent 6767 local ID (such as MAC address), then it would be useful to store that 6768 address in the certificate using the format of the access address 6769 information field or in a similar way. 6771 The ACP is defined as a separate VRF because it intends to support 6772 well managed networks with a wide variety of configurations. 6773 Therefore, reliable, configuration-indestructible connectivity cannot 6774 be achieved from the Data-Plane itself. In solutions where all 6775 transit connectivity impacting functions are fully automated 6776 (including security), indestructible and resilient, it would be 6777 possible to eliminate the need for the ACP to be a separate VRF. 6778 Consider the most simple example system in which there is no separate 6779 Data-Plane, but the ACP is the Data-Plane. Add BRSKI, and it becomes 6780 a fully autonomic network - except that it does not support automatic 6781 addressing for user equipment. This gap can then be closed for 6782 example by adding a solution derived from 6783 [I-D.ietf-anima-prefix-management]. 6785 TCP/TLS as the protocols to provide reliability and security to GRASP 6786 in the ACP may not be the preferred choice in constrained networks. 6787 For example, CoAP/DTLS (Constrained Application Protocol) may be 6788 preferred where they are already used, allowing to reduce the 6789 additional code space footprint for the ACP on those devices. Hop- 6790 by-hop reliability for ACP GRASP messages could be made to support 6791 protocols like DTLS by adding the same type of negotiation as defined 6792 in this document for ACP secure channel protocol negotiation. End- 6793 to-end GRASP connections can be made to select their transport 6794 protocol in future extensions of the ACP meant to better support 6795 constrained devices by indicating the supported transport protocols 6796 (e.g.: TLS/DTLS) via GRASP parameters of the GRASP objective through 6797 which the transport endpoint is discovered. 6799 The routing protocol RPL used for the ACP does explicitly not 6800 optimize for shortest paths and fastest convergence. Variations of 6801 the ACP may want to use a different routing protocol or introduce 6802 more advanced RPL profiles. 6804 Variations such as what routing protocol to use, or whether to 6805 instantiate an ACP in a VRF or (as suggested above) as the actual 6806 Data-Plane, can be automatically chosen in implementations built to 6807 support multiple options by deriving them from future parameters in 6808 the certificate. Parameters in certificates should be limited to 6809 those that would not need to be changed more often than certificates 6810 would need to be updated anyhow; Or by ensuring that these parameters 6811 can be provisioned before the variation of an ACP is activated in a 6812 node. Using BRSKI, this could be done for example as additional 6813 follow-up signaling directly after the certificate enrollment, still 6814 leveraging the BRSKI TLS connection and therefore not introducing any 6815 additional connectivity requirements. 6817 Last but not least, secure channel protocols including their 6818 encapsulations are easily added to ACP solutions. ACP hop-by-hop 6819 network layer secure channels could also be replaced by end-to-end 6820 security plus other means for infrastructure protection. Any future 6821 network OAM should always use end-to-end security anyhow and can 6822 leverage the domain certificates and is therefore not dependent on 6823 security to be provided for by ACP secure channels. 6825 A.10. Further (future) options 6827 A.10.1. Auto-aggregation of routes 6829 Routing in the ACP according to this specification only leverages the 6830 standard RPL mechanism of route optimization, e.g. keeping only 6831 routes that are not towards the RPL root. This is known to scale to 6832 networks with 20,000 or more nodes. There is no auto-aggregation of 6833 routes for /48 ULA prefixes (when using rsub in the domain 6834 information field) and/or Zone-ID based prefixes. 6836 Automatic assignment of Zone-ID and auto-aggregation of routes could 6837 be achieved for example by configuring zone-boundaries, announcing 6838 via GRASP into the zones the zone parameters (zone-ID and /48 ULA 6839 prefix) and auto-aggegating routes on the zone-boundaries. Nodes 6840 would assign their Zone-ID and potentially even /48 prefix based on 6841 the GRASP announcements. 6843 A.10.2. More options for avoiding IPv6 Data-Plane dependency 6845 As described in Section 6.12.2, the ACP depends on the Data-Plane to 6846 establish IPv6 link-local addressing on interfaces. Using a separate 6847 MAC address for the ACP allows to fully isolate the ACP from the 6848 data-plane in a way that is compatible with this specification. It 6849 is also an ideal option when using Single-root input/output 6850 virtualization (SR-IOV - see https://en.wikipedia.org/wiki/Single- 6851 root_input/output_virtualization [2]) in an implementation to isolate 6852 the ACP because different SR-IOV interfaces use different MAC 6853 addresses. 6855 When additional MAC address(es) are not available, separation of the 6856 ACP could be done at different demux points. The same subnet 6857 interface could have a separate IPv6 interface for the ACP and Data- 6858 Plane and therefore separate link-local addresses for both, where the 6859 ACP interface is non-configurable on the Data-Plane. This too would 6860 be compatible with this specification and not impact 6861 interoperability. 6863 An option that would require additional specification is to use a 6864 different Ethertype from 0x86DD (IPv6) to encapsulate IPv6 packets 6865 for the ACP. This would be a similar approach as used for IP 6866 authentication packets in [IEEE-802.1X] which use the Extensible 6867 Authentication Protocol over Local Area Network (EAPoL) ethertype 6868 (0x88A2). 6870 Note that in the case of ANI nodes, all the above considerations 6871 equally apply to the encapsulation of BRSKI packets including GRASP 6872 used for BRSKI. 6874 A.10.3. ACP APIs and operational models (YANG) 6876 Future work should define YANG ([RFC7950]) data model and/or node 6877 internal APIs to monitor and manage the ACP. 6879 Support for the ACP Adjacency Table (Section 6.2) and ACP GRASP need 6880 to be included into such model/API. 6882 A.10.4. RPL enhancements 6884 ..... USA ...... ..... Europe ...... 6886 NOC1 NOC2 6887 | | 6888 | metric 100 | 6889 ACP1 --------------------------- ACP2 . 6890 | | . WAN 6891 | metric 10 metric 20 | . Core 6892 | | . 6893 ACP3 --------------------------- ACP4 . 6894 | metric 100 | 6895 | | . 6896 | | . Sites 6897 ACP10 ACP11 . 6899 Figure 18: Dual NOC 6901 The profile for RPL specified in this document builds only one 6902 spanning-tree path set to a root, typically a registrar in one NOC. 6903 In the presence of multiple NOCs, routing toward the non-root NOCs 6904 may be suboptimal. Figure 18 shows an extreme example. Assuming 6905 that node ACP1 becomes the RPL root, traffic between ACP11 and NOC2 6906 will pass through ACP4-ACP3-ACP1-ACP2 instead of ACP4-ACP2 because 6907 the RPL calculated DODAG/routes are shortest paths towards the RPL 6908 root. 6910 To overcome these limitations, extensions/modifications to the RPL 6911 profile can provide optimality for multiple NOCs. This requires 6912 utilizing Data-Plane artifact including IPinIP encap/decap on ACP 6913 routers and processing of IPv6 RPI headers. Alternatively, (Src,Dst) 6914 routing table entries could be used. 6916 Flooding of ACP GRASP messages can be further constrained and 6917 therefore optimized by flooding only via links that are part of the 6918 RPL DODAG. 6920 A.10.5. Role assignments 6922 ACP connect is an explicit mechanism to "leak" ACP traffic explicitly 6923 (for example in a NOC). It is therefore also a possible security gap 6924 when it is easy to enable ACP connect on arbitrary compromised ACP 6925 nodes. 6927 One simple solution is to define an extension in the ACP certificates 6928 ACP information field indicating the permission for ACP connect to be 6929 configured on that ACP node. This could similarly be done to decide 6930 whether a node is permitted to be a registrar or not. 6932 Tying the permitted "roles" of an ACP node to the ACP domain 6933 certificate provides fairly strong protection against 6934 misconfiguration, but is still subject to code modifications. 6936 Another interesting role to assign to certificates is that of a NOC 6937 node. This would allow to limit certain type of connections such as 6938 OAM TLS connections to only NOC initiator or responders. 6940 A.10.6. Autonomic L3 transit 6942 In this specification, the ACP can only establish autonomic 6943 connectivity across L2 hops and only explicitly configured options to 6944 tunnel across L3. Future work should specify mechanisms to 6945 automatically tunnel ACP across L3 networks. A hub&spoke option 6946 would allow to tunnel across the Internet to a cloud or central 6947 instance of the ACP, a peer-to-peer tunneling mechanism could tunnel 6948 ACP islands across an L3VPN infrastructure. 6950 A.10.7. Diagnostics 6952 Section 9.1 describes diagnostics options that can be done without 6953 changing the external, interoperability affecting characteristics of 6954 ACP implementations. 6956 Even better diagnostics of ACP operations is possible with additional 6957 signaling extensions, such as: 6959 1. Consider if LLDP should be a recommended functionality for ANI 6960 devices to improve diagnostics, and if so, which information 6961 elements it should signal (noting that such information is 6962 conveyed in an insecure manner). Includes potentially new 6963 information elements. 6965 2. In alternative to LLDP, A DULL GRASP diagnostics objective could 6966 be defined to carry these information elements. 6968 3. The IDevID of BRSKI pledges should be included in the selected 6969 insecure diagnostics option. This may be undesirable when 6970 exposure of device information is seen as too much of a security 6971 issue (ability to deduce possible attack vectors from device 6972 model for example). 6974 4. A richer set of diagnostics information should be made available 6975 via the secured ACP channels, using either single-hop GRASP or 6976 network wide "topology discovery" mechanisms. 6978 A.10.8. Avoiding and dealing with compromised ACP nodes 6980 Compromised ACP nodes pose the biggest risk to the operations of the 6981 network. The most common type of compromise is leakage of 6982 credentials to manage/configure the device and the application of 6983 malicious configuration including the change of access credentials, 6984 but not the change of software. Most of todays networking equipment 6985 should have secure boot/software infrastructure anyhow, so attacks 6986 that introduce malicious software should be a lot harder. 6988 The most important aspect of security design against these type of 6989 attacks is to eliminate password based configuration access methods 6990 and instead rely on certificate based credentials handed out only to 6991 nodes where it is clear that the private keys can not leak. This 6992 limits unexpected propagation of credentials. 6994 If password based credentials to configure devices still need to be 6995 supported, they must not be locally configurable, but only be 6996 remotely provisioned or verified (through protocols like Radius or 6997 Diameter), and there must be no local configuration permitting to 6998 change these authentication mechanisms, but ideally they should be 6999 autoconfiguring across the ACP. See 7000 [I-D.eckert-anima-noc-autoconfig]. 7002 Without physical access to the compromised device, attackers with 7003 access to configuration should not be able to break the ACP 7004 connectivity, even when they can break or otherwise manipulate 7005 (spoof) the data-plane connectivity through configuration. To 7006 achieve this, it is necessary to avoid providing configuration 7007 options for the ACP, such as enabling/disabling it on interfaces. 7008 For example there could be an ACP configuration that locks down the 7009 current ACP config unless factory reseet is done. 7011 With such means, the valid administration has the best chances to 7012 maintain access to ACP nodes, discover malicious configuration though 7013 ongoing configuration tracking from central locations for example, 7014 and to react accordingly. 7016 The primary reaction is withdrawal/change of credentials, terminate 7017 malicious existing management sessions and fixing the configuration. 7018 Ensuring that management sessions using invalidated credentials are 7019 terminated automatically without recourse will likely require new 7020 work. 7022 Only when these steps are not feasible would it be necessary to 7023 revoke or expire the ACP domain certificate credentials and consider 7024 the node kicked off the network - until the situation can be further 7025 rectified, likely requiring direct physical access to the node. 7027 Without extensions, compromised ACP nodes can only be removed from 7028 the ACP at the speed of CRL/OCSP information refresh or expiry (and 7029 non-removal) of short lived certificates. Future extensions to the 7030 ACP could for example use GRASP flooding distribution of triggered 7031 updates of CRL/OCSP or explicit removal indication of the compromised 7032 nodes domain certificate. 7034 Authors' Addresses 7036 Toerless Eckert (editor) 7037 Futurewei Technologies Inc. USA 7038 2330 Central Expy 7039 Santa Clara 95050 7040 USA 7042 Email: tte+ietf@cs.fau.de 7044 Michael H. Behringer (editor) 7046 Email: michael.h.behringer@gmail.com 7048 Steinthor Bjarnason 7049 Arbor Networks 7050 2727 South State Street, Suite 200 7051 Ann Arbor MI 48104 7052 United States 7054 Email: sbjarnason@arbor.net