idnits 2.17.1 draft-ietf-anima-autonomic-control-plane-23.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 1138 has weird spacing: '...address of f...' == Line 2556 has weird spacing: '...k-local unic...' == Line 2557 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 433, but not defined -- Looks like a reference, but probably isn't: '1' on line 6267 -- Looks like a reference, but probably isn't: '2' on line 6843 -- Looks like a reference, but probably isn't: '3' on line 2019 -- Looks like a reference, but probably isn't: '5' on line 2025 -- Looks like a reference, but probably isn't: '9' on line 2036 -- Looks like a reference, but probably isn't: '13' on line 2052 == Missing Reference: 'ACP VRF' is mentioned on line 3882, but not defined == Missing Reference: 'Data-Plane' is mentioned on line 3884, but not defined == Missing Reference: 'Select' is mentioned on line 4044, but not defined == Missing Reference: 'Plane' is mentioned on line 4046, but not defined == Unused Reference: 'RFC1034' is defined on line 5803, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-applicability-template' is defined on line 5970, 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-23 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. Benefits (Informative) . . . . . . . . . . . . . . . . . . . 91 161 9.1. Self-Healing Properties . . . . . . . . . . . . . . . . . 91 162 9.2. Self-Protection Properties . . . . . . . . . . . . . . . 93 163 9.2.1. From the outside . . . . . . . . . . . . . . . . . . 93 164 9.2.2. From the inside . . . . . . . . . . . . . . . . . . . 94 165 9.3. The Administrator View . . . . . . . . . . . . . . . . . 94 166 10. ACP Operations (Informative) . . . . . . . . . . . . . . . . 95 167 10.1. ACP (and BRSKI) Diagnostics . . . . . . . . . . . . . . 96 168 10.2. ACP Registrars . . . . . . . . . . . . . . . . . . . . . 100 169 10.2.1. Registrar interactions . . . . . . . . . . . . . . . 100 170 10.2.2. Registrar Parameter . . . . . . . . . . . . . . . . 101 171 10.2.3. Certificate renewal and limitations . . . . . . . . 102 172 10.2.4. ACP Registrars with sub-CA . . . . . . . . . . . . . 103 173 10.2.5. Centralized Policy Control . . . . . . . . . . . . . 103 174 10.3. Enabling and disabling ACP/ANI . . . . . . . . . . . . . 104 175 10.3.1. Filtering for non-ACP/ANI packets . . . . . . . . . 104 176 10.3.2. Admin Down State . . . . . . . . . . . . . . . . . . 105 177 10.3.2.1. Security . . . . . . . . . . . . . . . . . . . . 106 178 10.3.2.2. Fast state propagation and Diagnostics . . . . . 106 179 10.3.2.3. Low Level Link Diagnostics . . . . . . . . . . . 107 180 10.3.2.4. Power Consumption Issues . . . . . . . . . . . . 107 181 10.3.3. Interface level ACP/ANI enable . . . . . . . . . . . 108 182 10.3.4. Which interfaces to auto-enable? . . . . . . . . . . 108 183 10.3.5. Node Level ACP/ANI enable . . . . . . . . . . . . . 109 184 10.3.5.1. Brownfield nodes . . . . . . . . . . . . . . . . 110 185 10.3.5.2. Greenfield nodes . . . . . . . . . . . . . . . . 110 186 10.3.6. Undoing ANI/ACP enable . . . . . . . . . . . . . . . 111 187 10.3.7. Summary . . . . . . . . . . . . . . . . . . . . . . 111 188 10.4. Configuration and the ACP (summary) . . . . . . . . . . 112 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-23 . . . . . . 120 199 14.3. draft-ietf-anima-autonomic-control-plane-22 . . . . . . 122 200 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 124 201 15.1. Normative References . . . . . . . . . . . . . . . . . . 124 202 15.2. Informative References . . . . . . . . . . . . . . . . . 127 203 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 134 204 Appendix A. Background and Futures (Informative) . . . . . . . . 134 205 A.1. ACP Address Space Schemes . . . . . . . . . . . . . . . . 134 206 A.2. BRSKI Bootstrap (ANI) . . . . . . . . . . . . . . . . . . 135 207 A.3. ACP Neighbor discovery protocol selection . . . . . . . . 136 208 A.3.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 136 209 A.3.2. mDNS and L2 support . . . . . . . . . . . . . . . . . 136 210 A.3.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 137 211 A.4. Choice of routing protocol (RPL) . . . . . . . . . . . . 137 212 A.5. ACP Information Distribution and multicast . . . . . . . 139 213 A.6. Extending ACP channel negotiation (via GRASP) . . . . . . 140 214 A.7. CAs, domains and routing subdomains . . . . . . . . . . . 141 215 A.8. Intent for the ACP . . . . . . . . . . . . . . . . . . . 143 216 A.9. Adopting ACP concepts for other environments . . . . . . 144 217 A.10. Further (future) options . . . . . . . . . . . . . . . . 145 218 A.10.1. Auto-aggregation of routes . . . . . . . . . . . . . 145 219 A.10.2. More options for avoiding IPv6 Data-Plane dependency 146 220 A.10.3. ACP APIs and operational models (YANG) . . . . . . . 146 221 A.10.4. RPL enhancements . . . . . . . . . . . . . . . . . . 147 222 A.10.5. Role assignments . . . . . . . . . . . . . . . . . . 147 223 A.10.6. Autonomic L3 transit . . . . . . . . . . . . . . . . 148 224 A.10.7. Diagnostics . . . . . . . . . . . . . . . . . . . . 148 225 A.10.8. Avoiding and dealing with compromised ACP nodes . . 149 226 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 150 228 1. Introduction (Informative) 230 Autonomic Networking is a concept of self-management: Autonomic 231 functions self-configure, and negotiate parameters and settings 232 across the network. [RFC7575] defines the fundamental ideas and 233 design goals of Autonomic Networking. A gap analysis of Autonomic 234 Networking is given in [RFC7576]. The reference architecture for 235 Autonomic Networking in the IETF is specified in the document 236 [I-D.ietf-anima-reference-model]. 238 Autonomic functions need an autonomically built communications 239 infrastructure. This infrastructure needs to be secure, resilient 240 and re-usable by all autonomic functions. Section 5 of [RFC7575] 241 introduces that infrastructure and calls it the Autonomic Control 242 Plane (ACP). More descriptively it would be the "Autonomic 243 communications infrastructure for OAM and Control". For naming 244 consistency with that prior document, this document continues to use 245 the name ACP though. 247 Today, the OAM and control plane of networks typically uses a routing 248 and forwarding table which is dependent on correct configuration and 249 routing. Misconfigurations or routing problems can disrupt OAM and 250 control channels. Traditionally, an out-of-band network has been 251 used to avoid or allow recovery from such problems, or personnel are 252 sent on site to access devices through out-of-band management ports 253 (also called craft ports, serial console, management ethernet port). 254 However, both options are expensive. 256 In increasingly automated networks either centralized management 257 systems or distributed autonomic service agents in the network 258 require a control plane which is independent of the configuration of 259 the network they manage, to avoid impacting their own operations 260 through the configuration actions they take. 262 This document describes a modular design for a self-forming, self- 263 managing and self-protecting ACP, which is a virtual in-band network 264 designed to be as independent as possible of configuration, 265 addressing and routing problems. The details how this is achieved 266 are described in Section 6. The ACP is designed to remain 267 operational even in the presence of configuration errors, addressing 268 or routing issues, or where policy could inadvertently affect 269 connectivity of both data packets or control packets. 271 This document uses the term "Data-Plane" to refer to anything in the 272 network nodes that is not the ACP, and therefore considered to be 273 dependent on (mis-)configuration. This Data-Plane includes both the 274 traditional forwarding-plane, as well as any pre-existing control- 275 plane, such as routing protocols that establish routing tables for 276 the forwarding plane. 278 The Autonomic Control Plane serves several purposes at the same time: 280 1. Autonomic functions communicate over the ACP. The ACP therefore 281 directly supports Autonomic Networking functions, as described in 282 [I-D.ietf-anima-reference-model]. For example, Generic Autonomic 283 Signaling Protocol (GRASP - [I-D.ietf-anima-grasp]) runs securely 284 inside the ACP and depends on the ACP as its "security and 285 transport substrate". 287 2. A controller or network management system can use it to securely 288 bootstrap network devices in remote locations, even if the (Data- 289 Plane) network in between is not yet configured; no Data-Plane 290 dependent bootstrap configuration is required. An example of 291 such a secure bootstrap process is described in 292 [I-D.ietf-anima-bootstrapping-keyinfra]. 294 3. An operator can use it to access remote devices using protocols 295 such as Secure SHell (SSH) or Network Configuration Protocol 296 (NETCONF) running across the ACP, even if the network is 297 misconfigured or not configured. 299 This document describes these purposes as use cases for the ACP in 300 Section 3, it defines the requirements in Section 4. Section 5 gives 301 an overview how the ACP is constructed. 303 The normative part of this document starts with Section 6, where the 304 ACP is specified. Section 7 defines normative how to support ACP on 305 L2 switches. Section 8 explains normative how non-ACP nodes and 306 networks can be integrated. 308 The remaining sections are non-normative: Section 9 reviews benefits 309 of the ACP (after all the details have been defined), Section 10 310 provides operational recommendations, Appendix A provides additional 311 explanations and describes additional details or future standard or 312 propriety extensions that were considered not to be appropriate for 313 standardization in this document but were considered important to 314 document. There are no dependencies against Appendix A to build a 315 complete working and interoperable ACP according to this document. 317 The ACP provides secure IPv6 connectivity, therefore it can be used 318 not only as the secure connectivity for self-management as required 319 for the ACP in [RFC7575], but it can also be used as the secure 320 connectivity for traditional (centralized) management. The ACP can 321 be implemented and operated without any other components of autonomic 322 networks, except for the GRASP protocol. ACP relies on per-link DULL 323 GRASP (see Section 6.3) to autodiscover ACP neighbors, and includes 324 the ACP GRASP instance to provide service discovery for clients of 325 the ACP (see Section 6.8) including for its own maintenance of ACP 326 certificates. 328 The document "Using Autonomic Control Plane for Stable Connectivity 329 of Network OAM" [RFC8368] describes how the ACP alone can be used to 330 provide secure and stable connectivity for autonomic and non- 331 autonomic OAM applications. That document also explains how existing 332 management solutions can leverage the ACP in parallel with 333 traditional management models, when to use the ACP and how to 334 integrate with potentially IPv4 only OAM backends. 336 Combining ACP with Bootstrapping Remote Secure Key Infrastructures 337 (BRSKI), see [I-D.ietf-anima-bootstrapping-keyinfra]) results in the 338 "Autonomic Network Infrastructure" (ANI) as defined in 339 [I-D.ietf-anima-reference-model], which provides autonomic 340 connectivity (from ACP) with secure zero-touch (automated) bootstrap 341 from BRSKI. The ANI itself does not constitute an Autonomic Network, 342 but it allows the building of more or less autonomic networks on top 343 of it - using either centralized, Software Defined Networking- 344 (SDN-)style (see [RFC7426]) automation or distributed automation via 345 Autonomic Service Agents (ASA) / Autonomic Functions (AF) - or a 346 mixture of both. See [I-D.ietf-anima-reference-model] for more 347 information. 349 1.1. Applicability and Scope 351 Please see the following Terminology section (Section 2) for 352 explanations of terms used in this section. 354 The design of the ACP as defined in this document is considered to be 355 applicable to all types of "professionally managed" networks: Service 356 Provider, Local Area Network (LAN), Metro(politan networks), Wide 357 Area Network (WAN), Enterprise Information Technology (IT) and 358 ->"Operational Technology" () (OT) networks. The ACP can operate 359 equally on layer 3 equipment and on layer 2 equipment such as bridges 360 (see Section 7). The hop-by-hop authentication, integrity-protection 361 and confidentiality mechanism used by the ACP is defined to be 362 negotiable, therefore it can be extended to environments with 363 different protocol preferences. The minimum implementation 364 requirements in this document attempt to achieve maximum 365 interoperability by requiring support for multiple options depending 366 on the type of device: IPsec, see [RFC4301], and datagram Transport 367 Layer Security (DTLS) version 1.2, see [RFC6347]). 369 The implementation footprint of the ACP consists of Public Key 370 Infrastructure (PKI) code for the ACP certificate, the GRASP 371 protocol, UDP, TCP and TLS (for security and reliability of GRASP), 372 the ACP secure channel protocol used (such as IPsec or DTLS), and an 373 instance of IPv6 packet forwarding and routing via the Routing 374 Protocol for Low-power and Lossy Networks (RPL), see [RFC6550], that 375 is separate from routing and forwarding for the Data-Plane (user 376 traffic). 378 The ACP uses only IPv6 to avoid complexity of dual-stack ACP 379 operations (IPv6/IPv4). Nevertheless, it can without any changes be 380 integrated into even otherwise IPv4-only network devices. The Data- 381 Plane itself would not need to change, it could continue to be IPv4 382 only. For such IPv4 only devices, the IPv6 protocol itself would be 383 additional implementation footprint only used for the ACP. 385 The protocol choices of the ACP are primarily based on wide use and 386 support in networks and devices, well understood security properties 387 and required scalability. The ACP design is an attempt to produce 388 the lowest risk combination of existing technologies and protocols to 389 build a widely applicable operational network management solution: 391 RPL was chosen because it requires a smaller routing table footprint 392 in large networks compared to other routing protocols with an 393 autonomically configured single area. The deployment experience of 394 large scale Internet of Things (IoT) networks serves as the basis for 395 wide deployment experience with RPL. The profile chosen for RPL in 396 the ACP does not leverage any RPL specific forwarding plane features 397 (IPv6 extension headers), making its implementation a pure control 398 plane software requirement. 400 GRASP is the only completely novel protocol used in the ACP, and this 401 choice was necessary because there is no existing suitable protocol 402 to provide the necessary functions to the ACP, so GRASP was developed 403 to fill that gap. 405 The ACP design can be applicable to (cpu, memory) constrained devices 406 and (bitrate, reliability) constrained networks, but this document 407 does not attempt to define the most constrained type of devices or 408 networks to which the ACP is applicable. RPL and DTLS for ACP secure 409 channels are two protocol choices already making ACP more applicable 410 to constrained environments. Support for constrained devices in this 411 specification is opportunistic, but not complete, because the 412 reliable transport for GRASP (see Section 6.8.2) only specifies TCP/ 413 TLS). See Appendix A.9 for discussions about how future standards or 414 proprietary extensions/variations of the ACP could better meet 415 different expectations from those on which the current design is 416 based including supporting constrained devices better. 418 2. Acronyms and Terminology (Informative) 420 [RFC Editor: WG/IETF/IESG review of the terms below asked for 421 references between these terms when they refer to each other. The 422 only option I could fin RFC/XML to point to a hanging text acronym 423 definition that also displays the actual term is the format="title" 424 version, which leads to references such as '->"ACP domain 425 certificate" ()'. I found no reasonable way to eliminate the 426 trailing '()' generated by this type of cross references. Can you 427 please take care of removing these artefacts during editing (after 428 conversion to nroff ?). I also created a ticket to ask for an 429 xml2rfc enhancement to avoid this in the future: 430 https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/347. 432 [RFC Editor: Question: Is it possible to change the first occurrences 433 of [RFCxxxx] references to "rfcxxx title" [RFCxxxx]? the XML2RFC 434 format does not seem to offer such a format, but I did not want to 435 duplicate 50 first references - one reference for title mentioning 436 and one for RFC number.] 438 This document serves both as a normative specification for how ACP 439 nodes have to behave as well as describing requirements, benefits, 440 architecture and operational aspects to explain the context. 441 Normative sections are labelled "(Normative)" and use 442 [RFC2119]/[RFC8174] keywords. Other sections are labelled 443 "(Informative)" and do not use those normative keywords. 445 In the rest of the document we will refer to systems using the ACP as 446 "nodes". Typically such a node is a physical (network equipment) 447 device, but it can equally be some virtualized system. Therefore, we 448 do not refer to them as devices unless the context specifically calls 449 for a physical system. 451 This document introduces or uses the following terms (sorted 452 alphabetically). Terms introduced are explained on first use, so 453 this list is for reference only. 455 ACP: "Autonomic Control Plane". The Autonomic Function as defined 456 in this document. It provides secure zero-touch (automated) 457 transitive (network wide) IPv6 connectivity for all nodes in the 458 same ACP domain as well as a GRASP instance running across this 459 ACP IPv6 connectivity. The ACP is primarily meant to be used as a 460 component of the ANI to enable Autonomic Networks but it can 461 equally be used in simple ANI networks (with no other Autonomic 462 Functions) or completely by itself. 464 ACP address: An IPv6 address assigned to the ACP node. It is stored 465 in the domain information field of the ->"ACP domain certificate" 466 (). 468 ACP address range/set: The ACP address may imply a range or set of 469 addresses that the node can assign for different purposes. This 470 address range/set is derived by the node from the format of the 471 ACP address called the "addressing sub-scheme". 473 ACP connect interface: An interface on an ACP node providing access 474 to the ACP for non ACP capable nodes without using an ACP secure 475 channel. See Section 8.1.1. 477 ACP domain: The ACP domain is the set of nodes with ->"ACP domain 478 certificates" that allow them to authenticate each other as 479 members of the ACP domain. See also Section 6.1.3. 481 ACP (ANI/AN) Domain Certificate: A [RFC5280] certificate (LDevID) 482 carrying the domain information field which is used by the ACP to 483 learn its address in the ACP and to derive and cryptographically 484 assert its membership in the ACP domain. 486 domain information (field): An rfc822Name information element (e.g., 487 field) in the domain certificate in which the ACP relevant 488 information is encoded: the domain name and the ACP address. 490 ACP Loopback interface: The Loopback interface in the ACP Virtual 491 Routing and Forwarding (VRF) that has the ACP address assigned to 492 it. 494 ACP network: The ACP network constitutes all the nodes that have 495 access to the ACP. It is the set of active and transitively 496 connected nodes of an ACP domain plus all nodes that get access to 497 the ACP of that domain via ACP edge nodes. 499 ACP (ULA) prefix(es): The /48 IPv6 address prefixes used across the 500 ACP. In the normal/simple case, the ACP has one ULA prefix, see 501 Section 6.10. The ACP routing table may include multiple ULA 502 prefixes if the "rsub" option is used to create addresses from 503 more than one ULA prefix. See Section 6.1.2. The ACP may also 504 include non-ULA prefixes if those are configured on ACP connect 505 interfaces. See Section 8.1.1. 507 ACP secure channel: A channel authenticated via ->"ACP domain 508 certificates" () providing integrity protection and 509 confidentiality through encryption. These are established between 510 (normally) adjacent ACP nodes to carry traffic of the ACP VRF 511 securely and isolated from Data-Plane traffic in-band over the 512 same link/path as the Data-Plane. 514 ACP secure channel protocol: The protocol used to build an ACP 515 secure channel, e.g., Internet Key Exchange Protocol version 2 516 (IKEv2) with IPsec or Datagram Transport Layer Security (DTLS). 518 ACP virtual interface: An interface in the ACP VRF mapped to one or 519 more ACP secure channels. See Section 6.12.5. 521 AN "Autonomic Network": A network according to 522 [I-D.ietf-anima-reference-model]. Its main components are ANI, 523 Autonomic Functions and Intent. 525 (AN) Domain Name: An FQDN (Fully Qualified Domain Name) in the 526 domain information field of the Domain Certificate. See 527 Section 6.1.2. 529 ANI (nodes/network): "Autonomic Network Infrastructure". The ANI is 530 the infrastructure to enable Autonomic Networks. It includes ACP, 531 BRSKI and GRASP. Every Autonomic Network includes the ANI, but 532 not every ANI network needs to include autonomic functions beyond 533 the ANI (nor Intent). An ANI network without further autonomic 534 functions can for example support secure zero-touch (automated) 535 bootstrap and stable connectivity for SDN networks - see 536 [RFC8368]. 538 ANIMA: "Autonomic Networking Integrated Model and Approach". ACP, 539 BRSKI and GRASP are specifications of the IETF ANIMA working 540 group. 542 ASA: "Autonomic Service Agent". Autonomic software modules running 543 on an ANI device. The components making up the ANI (BRSKI, ACP, 544 GRASP) are also described as ASAs. 546 Autonomic Function: A function/service in an Autonomic Network (AN) 547 composed of one or more ASA across one or more ANI nodes. 549 BRSKI: "Bootstrapping Remote Secure Key Infrastructures" 550 ([I-D.ietf-anima-bootstrapping-keyinfra]. A protocol extending 551 EST to enable secure zero-touch bootstrap in conjunction with ACP. 552 ANI nodes use ACP, BRSKI and GRASP. 554 CA: "Certificate Authority". An entity that issues digital 555 certificates. A CA uses its own cerrtificate to sign the 556 certificates it issues. This signing certificate can be 557 considered to be an identifier of the CA, so the term CA is also 558 loosely used to refer to the certificate used by the CA for 559 signing. 561 CRL: "Certificate Revocation List". A list of revoked certificates. 562 Required to revoke certificates before their lifetime expires. 564 Data-Plane: The counterpoint to the ACP VRF in an ACP node: all 565 routing and forwarding in the node other than the ACP VRF. In a 566 simple ACP or ANI node, the Data-Plane is typically provisioned by 567 means other than autonomically, for example manually (including 568 across the ACP) or via SDN controllers. In a fully Autonomic 569 Network node, the Data-Plane is managed autonomically via 570 Autonomic Functions and Intent. Note that other (non-ANIMA) RFCs 571 use the Data-Plane to refer to what is better called the 572 forwarding plane. This is not the way the term is used in this 573 document! 575 device: A physical system, or physical node. 577 Enrollment: The process where a node presents identification (for 578 example through keying material such as the private key of an 579 IDevID) to a network and acquires a network specific identity such 580 as an LDevID and trust anchors such as Certificate Authority (CA) 581 certificates. 583 EST: "Enrollment over Secure Transport" ([RFC7030]). IETF standard- 584 track protocol for enrollment of a node with an LDevID. BRSKI is 585 based on EST. 587 GRASP: "Generic Autonomic Signaling Protocol". An extensible 588 signaling protocol required by the ACP for ACP neighbor discovery. 590 The ACP also provides the "security and transport substrate" for 591 the "ACP instance of GRASP". This instance of GRASP runs across 592 the ACP secure channels to support BRSKI and other NOC/OAM or 593 Autonomic Functions. See [I-D.ietf-anima-grasp]. 595 IDevID: An "Initial Device IDentity" X.509 certificate installed by 596 the vendor on new equipment. Contains information that 597 establishes the identity of the node in the context of its vendor/ 598 manufacturer such as device model/type and serial number. See 599 [AR8021]. IDevID cannot be used as a node identifier for the ACP 600 because they are not provisioned by the owner of the network, so 601 they can not directly indicate an ACP domain they belong to. 603 in-band (management): The type of management used predominantly in 604 IP based networks, not leveraging an ->"out-of-band network" (). 605 In in-band management, access to the managed equipment depends on 606 the configuration of this equipment itself: interface, addressing, 607 forwarding, routing, policy, security, management. This 608 dependency makes in-band management fragile because the 609 configuration actions performed may break in-band management 610 connectivity. Breakage can not only be unintentional, it can 611 simply be an unavoidable side effect of being unable to create 612 configuration schemes where in-band management connectivity 613 configuration is unaffected by Data-Plane configuration. See also 614 ->"(virtual) out-of-band network" (). 616 Intent: Policy language of an autonomic network according to 617 [I-D.ietf-anima-reference-model]. 619 Loopback interface: The conventional name for an internal IP 620 interface to which addresses may be assigned, but which transmits 621 no external traffic. 623 LDevID: A "Local Device IDentity" is an X.509 certificate installed 624 during "enrollment". The Domain Certificate used by the ACP is an 625 LDevID. See [AR8021]. 627 Management: Used in this document as another word for ->"OAM" (). 629 MASA (service): "Manufacturer Authorized Signing Authority". A 630 vendor/manufacturer or delegated cloud service on the Internet 631 used as part of the BRSKI protocol. 633 MIC: "Manufacturer Installed Certificate". This is another word to 634 describe an IDevID in referenced materials. This term is not used 635 in this document. 637 native interface: Interfaces existing on a node without 638 configuration of the already running node. On physical nodes 639 these are usually physical interfaces. On virtual nodes their 640 equivalent. 642 NOC: Network Operations Center. 644 node: A system supporting the ACP according to this document. Can 645 be virtual or physical. Physical nodes are called devices. 647 Node-ID: The identifier of an ACP node inside that ACP. It is the 648 last 64 (see Section 6.10.3) or 78-bits (see Section 6.10.5) of 649 the ACP address. 651 OAM: Operations, Administration and Management. Includes Network 652 Monitoring. 654 Operational Technology (OT): "https://en.wikipedia.org/wiki/ 655 Operational_Technology" [1]: "The hardware and software dedicated 656 to detecting or causing changes in physical processes through 657 direct monitoring and/or control of physical devices such as 658 valves, pumps, etc.". OT networks are today in most cases well 659 separated from Information Technology (IT) networks. 661 (virtual) out-of-band network: An out-of-band network is a secondary 662 network used to manage a primary network. The equipment of the 663 primary network is connected to the out-of-band network via 664 dedicated management ports on the primary network equipment. 665 Serial (console) management ports were historically most common, 666 higher end network equipment now also has ethernet ports dedicated 667 only for management. An out-of-band network provides management 668 access to the primary network independent of the configuration 669 state of the primary network. One of the goals of the ACP is to 670 provide this benefit of out-of-band networks virtually on the 671 primary network equipment. The ACP VRF acts as a virtual out of 672 band network device providing configuration independent management 673 access. The ACP secure channels are the virtual links of the ACP 674 virtual out-of-band network, meant to be operating independent of 675 the configuration of the primary network. See also ->"in-band 676 (management)" (). 678 root CA: "root certificate authority". A trusted ->"CA" (). The 679 certificate used by the CA to sign issued certificates is expected 680 to be a ->"TA" (), which makes it the root of a certificate chain. 681 The term root CA is also loosely used to refer to the root CA's 682 signing certificate. Root CA certificates are self-signed. 684 RPL: "IPv6 Routing Protocol for Low-Power and Lossy Networks". The 685 routing protocol used in the ACP. See [RFC6550]. 687 (ACP/ANI/BRSKI) Registrar: An ACP registrar is an entity (software 688 and/or person) that is orchestrating the enrollment of ACP nodes 689 with the ACP domain certificate. ANI nodes use BRSKI, so ANI 690 registrars are also called BRSKI registrars. For non-ANI ACP 691 nodes, the registrar mechanisms are undefined by this document. 692 See Section 6.10.7. Renewal and other maintenance (such as 693 revocation) of ACP domain certificates may be performed by other 694 entities than registrars. EST must be supported for ACP domain 695 certificate renewal (see Section 6.1.5). BRSKI is an extension of 696 EST, so ANI/BRSKI registrars can easily support ACP domain 697 certificate renewal in addition to initial enrollment. 699 sUDI: "secured Unique Device Identifier". This is another word to 700 describe an IDevID in referenced material. This term is not used 701 in this document. 703 TA "Trust Anchor(s)". A list of one or more certificates that are 704 trusted signers of other certificates. Authenticating a 705 certificate consists of verifying the chain of signing 706 certificates until a TA is encountered. In the most simple case, 707 the TA is a single certificate of the single root CAThe most 708 simple form of a TA is a root certificate. 710 UDI: "Unique Device Identifier". In the context of this document 711 unsecured identity information of a node typically consisting of 712 at least device model/type and serial number, often in a vendor 713 specific format. See sUDI and LDevID. 715 ULA: (Global ID prefix) A "Unique Local Address" (ULA) is an IPv6 716 address in the block fc00::/7, defined in [RFC4193]. It is the 717 approximate IPv6 counterpart of the IPv4 private address 718 ([RFC1918]). The ULA Global ID prefix are the first 48-bits of a 719 ULA address. In this document it is abbreviated as "ULA prefix". 721 (ACP) VRF: The ACP is modeled in this document as a "Virtual Routing 722 and Forwarding" instance (VRF). This means that it is based on a 723 "virtual router" consisting of a separate IPv6 forwarding table to 724 which the ACP virtual interfaces are attached and an associated 725 IPv6 routing table separate from the Data-Plane. Unlike the VRFs 726 on MPLS/VPN-PE ([RFC4364]) or LISP XTR ([RFC6830]), the ACP VRF 727 does not have any special "core facing" functionality or routing/ 728 mapping protocols shared across multiple VRFs. In vendor products 729 a VRF such as the ACP-VRF may also be referred to as a so called 730 VRF-lite. 732 (ACP) Zone: An ACP zone is a set of ACP nodes using the same zone 733 field value in their ACP address according to Section 6.10.3. 734 Zones are a mechanism to support structured addressing of ACP 735 addresses within the same /48-bit ULA prefix. 737 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 738 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 739 "OPTIONAL" in this document are to be interpreted as described in BCP 740 14 [RFC2119],[RFC8174] when, and only when, they appear in all 741 capitals, as shown here. 743 3. Use Cases for an Autonomic Control Plane (Informative) 745 This section summarizes the use cases that are intended to be 746 supported by an ACP. To understand how these are derived from and 747 relate to the larger set of use cases for autonomic networks, please 748 refer to [RFC8316]. 750 3.1. An Infrastructure for Autonomic Functions 752 Autonomic Functions need a stable infrastructure to run on, and all 753 autonomic functions should use the same infrastructure to minimize 754 the complexity of the network. In this way, there is only need for a 755 single discovery mechanism, a single security mechanism, and single 756 instances of other processes that distributed functions require. 758 3.2. Secure Bootstrap over a not configured Network 760 Today, bootstrapping a new node typically requires all nodes between 761 a controlling node such as an SDN controller ("Software Defined 762 Networking", see [RFC7426]) and the new node to be completely and 763 correctly addressed, configured and secured. Bootstrapping and 764 configuration of a network happens in rings around the controller - 765 configuring each ring of devices before the next one can be 766 bootstrapped. Without console access (for example through an out-of- 767 band network) it is not possible today to make devices securely 768 reachable before having configured the entire network leading up to 769 them. 771 With the ACP, secure bootstrap of new devices and whole new networks 772 can happen without requiring any configuration of unconfigured 773 devices along the path: As long as all devices along the path support 774 ACP and a zero-touch bootstrap mechanism such as BRSKI, the ACP 775 across a whole network of unconfigured devices can be brought up 776 without operator/provisioning intervention. The ACP also provides 777 additional security for any bootstrap mechanism, because it can 778 provide encrypted discovery (via ACP GRASP) of registrars or other 779 bootstrap servers by bootstrap proxies connecting to nodes that are 780 to be bootstrapped and the ACP encryption hides the identities of the 781 communicating entities (pledge and registrar), making it more 782 difficult to learn which network node might be attackable. The ACP 783 domain certificate can also be used to end-to-end encrypt the 784 bootstrap communication between such proxies and server. Note that 785 bootstrapping here includes not only the first step that can be 786 provided by BRSKI (secure keys), but also later stages where 787 configuration is bootstrapped. 789 3.3. Data-Plane Independent Permanent Reachability 791 Today, most critical control plane protocols and OAM protocols are 792 using the Data-Plane of the network. This leads to often undesirable 793 dependencies between control and OAM plane on one side and the Data- 794 Plane on the other: Only if the forwarding and control plane of the 795 Data-Plane are configured correctly, will the Data-Plane and the OAM/ 796 control plane work as expected. 798 Data-Plane connectivity can be affected by errors and faults, for 799 example misconfigurations that make AAA (Authentication, 800 Authorization and Accounting) servers unreachable or can lock an 801 administrator out of a device; routing or addressing issues can make 802 a device unreachable; shutting down interfaces over which a current 803 management session is running can lock an admin irreversibly out of 804 the device. Traditionally only out-of-band access can help recover 805 from such issues (such as serial console or ethernet management 806 port). 808 Data-Plane dependencies also affect applications in a Network 809 Operations Center (NOC) such as SDN controller applications: Certain 810 network changes are today hard to implement, because the change 811 itself may affect reachability of the devices. Examples are address 812 or mask changes, routing changes, or security policies. Today such 813 changes require precise hop-by-hop planning. 815 Note that specific control plane functions for the Data-Plane often 816 want to depend on forwarding of their packets via the Data-Plane: 817 Aliveness and routing protocol signaling packets across the Data- 818 Plane to verify reachability across the Data-Plane, using IPv4 819 signaling packets for IPv4 routing vs. IPv6 signaling packets for 820 IPv6 routing. 822 Assuming appropriate implementation (see Section 6.12.2 for more 823 details), the ACP provides reachability that is independent of the 824 Data-Plane. This allows the control plane and OAM plane to operate 825 more robustly: 827 o For management plane protocols, the ACP provides the functionality 828 of a Virtual out-of-band (VooB) channel, by providing connectivity 829 to all nodes regardless of their Data-Plane configuration, routing 830 and forwarding tables. 832 o For control plane protocols, the ACP allows their operation even 833 when the Data-Plane is temporarily faulty, or during transitional 834 events, such as routing changes, which may affect the control 835 plane at least temporarily. This is specifically important for 836 autonomic service agents, which could affect Data-Plane 837 connectivity. 839 The document "Using Autonomic Control Plane for Stable Connectivity 840 of Network OAM" [RFC8368] explains this use case for the ACP in 841 significantly more detail and explains how the ACP can be used in 842 practical network operations. 844 4. Requirements (Informative) 846 The following requirements were identified for the design of the ACP 847 based on the above use-cases (Section 3). These requirements are 848 informative. The ACP as specified in the normative parts of this 849 document is meeting or exceeding these use-case requirements: 851 ACP1: The ACP should provide robust connectivity: As far as 852 possible, it should be independent of configured addressing, 853 configuration and routing. Requirements 2 and 3 build on this 854 requirement, but also have value on their own. 856 ACP2: The ACP must have a separate address space from the Data- 857 Plane. Reason: traceability, debug-ability, separation from 858 Data-Plane, infrastructure security (filtering based on known 859 address space). 861 ACP3: The ACP must use autonomically managed address space. Reason: 862 easy bootstrap and setup ("autonomic"); robustness (admin 863 cannot break network easily). This document uses Unique Local 864 Addresses (ULA) for this purpose, see [RFC4193]. 866 ACP4: The ACP must be generic, that is it must be usable by all the 867 functions and protocols of the ANI. Clients of the ACP must 868 not be tied to a particular application or transport protocol. 870 ACP5: The ACP must provide security: Messages coming through the ACP 871 must be authenticated to be from a trusted node, and should 872 (very strong should) be encrypted. 874 Explanation for ACP4: In a fully autonomic network (AN), newly 875 written ASA could potentially all communicate exclusively via GRASP 876 with each other, and if that was assumed to be the only requirement 877 against the ACP, it would not need to provide IPv6 layer connectivity 878 between nodes, but only GRASP connectivity. Nevertheless, because 879 ACP also intends to support non-AN networks, it is crucial to support 880 IPv6 layer connectivity across the ACP to support any transport and 881 application layer protocols. 883 The ACP operates hop-by-hop, because this interaction can be built on 884 IPv6 link local addressing, which is autonomic, and has no dependency 885 on configuration (requirement 1). It may be necessary to have ACP 886 connectivity across non-ACP nodes, for example to link ACP nodes over 887 the general Internet. This is possible, but introduces a dependency 888 against stable/resilient routing over the non-ACP hops (see 889 Section 8.2). 891 5. Overview (Informative) 893 The Autonomic Control Plane is constructed in the following way (for 894 details, see Section 6): 896 1. An ACP node creates a Virtual Routing and Forwarding (VRF) 897 instance, or a similar virtual context. 899 2. It determines, following a policy, a candidate peer list. This 900 is the list of nodes to which it should establish an Autonomic 901 Control Plane. Default policy is: To all link-layer adjacent 902 nodes supporting ACP. 904 3. For each node in the candidate peer list, it authenticates that 905 node (according to Section 6.1.3) and negotiates a mutually 906 acceptable channel type. 908 4. For each node in the candidate peer list, it then establishes a 909 secure tunnel of the negotiated channel type. The resulting 910 tunnels are then placed into the previously set up VRF. This 911 creates an overlay network with hop-by-hop tunnels. 913 5. Inside the ACP VRF, each node assigns its ULA IPv6 address to a 914 Loopback interface assigned to the ACP VRF. 916 6. Each node runs a lightweight routing protocol, to announce 917 reachability of the virtual addresses inside the ACP (see 918 Section 6.12.5). 920 Note: 922 o Non-ACP NMS ("Network Management Systems") or SDN controllers have 923 to be explicitly configured for connection into the ACP. 925 o Connecting over non-ACP Layer-3 clouds requires explicit 926 configuration. See Section 8.2. 928 o None of the above operations (except explicit configured ones) are 929 reflected in the configuration of the node. 931 The following figure illustrates the ACP. 933 ACP node 1 ACP node 2 934 ................... ................... 935 secure . . secure . . secure 936 channel: +-----------+ : channel : +-----------+ : channel 937 ..--------| ACP VRF |---------------------| ACP VRF |---------.. 938 : / \ / \ <--routing--> / \ / \ : 939 : \ / \ / \ / \ / : 940 ..--------| Loopback |---------------------| Loopback |---------.. 941 : | interface | : : | interface | : 942 : +-----------+ : : +-----------+ : 943 : : : : 944 : Data-Plane :...............: Data-Plane : 945 : : link : : 946 :.................: :.................: 948 Figure 1: ACP VRF and secure channels 950 The resulting overlay network is normally based exclusively on hop- 951 by-hop tunnels. This is because addressing used on links is IPv6 952 link local addressing, which does not require any prior set-up. In 953 this way the ACP can be built even if there is no configuration on 954 the node, or if the Data-Plane has issues such as addressing or 955 routing problems. 957 6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 959 This section describes the components and steps to set up an ACP and 960 highlights the key properties which make it "indestructible" against 961 many inadvertent changes to the Data-Plane, for example caused by 962 misconfigurations. 964 An ACP node can be a router, switch, controller, NMS host, or any 965 other IP capable node. Initially, it MUST have its ACP domain 966 certificate, as well as an (empty) ACP Adjacency Table (described in 967 Section 6.2). It then can start to discover ACP neighbors and build 968 the ACP. This is described step by step in the following sections: 970 6.1. ACP Domain, Certificate and Network 972 The ACP relies on group security. An ACP domain is a group of nodes 973 that trust each other to participate in ACP operations such as 974 creating ACP secure channels in an autonomous peer-to-peer fashion 975 between ACP domain members via protocols such as IPsec. To establish 976 trust, each ACP member requires keying material: An ACP node MUST 977 have a Local Device IDentity certificate (LDevID) and a Trust Anchor 978 (TA) consisting of a certificate (chain) used to sign the LDevID of 979 all ACP domain members. The LDevID is used to cryptographically 980 authenticate the membership of its owner node in the ACP domain to 981 other ACP domain members. The TA is used to authenticate the ACP 982 domain membership of other nodes (see Section 6.1.3). This document 983 calls the LDevID used for the the ACP the ACP certificate. 985 Manual keying via shared secrets is not usable for an ACP domain 986 because it would require a single shared secret across all current 987 and future ACP domain members to meet the expectation of autonomous, 988 peer-to-peer establishment of ACP secure channels between any ACP 989 domain members. Such a single shared secret would be an inacceptable 990 security weakness. Asymmetric keying material (public keys) without 991 certificates does not provide the mechanisms to authenticate ACP 992 domain membership in an autonomous, peer-to-peer fashion for current 993 and future ACP domain members. 995 The LDevID is called the ACP domain certificate, the TA is the 996 Certificate Authority (CA) root certificate of the ACP domain. 998 The ACP does not mandate specific mechanisms by which this keying 999 material is provisioned into the ACP node. It only requires the 1000 certificate to comply with Section 6.1.1, specifically the Domain 1001 information field as specified in Section 6.1.2 in its domain 1002 certificate as well as those of candidate ACP peers. See 1003 Appendix A.2 for more information about enrollment or provisioning 1004 options. 1006 This document uses the term ACP in many places where the Autonomic 1007 Networking reference documents [RFC7575] and 1008 [I-D.ietf-anima-reference-model] use the word autonomic. This is 1009 done because those reference documents consider (only) fully 1010 autonomic networks and nodes, but support of ACP does not require 1011 support for other components of autonomic networks except for relying 1012 on GRASP and providing security and transport for GRASP. Therefore 1013 the word autonomic might be misleading to operators interested in 1014 only the ACP. 1016 [RFC7575] defines the term "Autonomic Domain" as a collection of 1017 autonomic nodes. ACP nodes do not need to be fully autonomic, but 1018 when they are, then the ACP domain is an autonomic domain. Likewise, 1019 [I-D.ietf-anima-reference-model] defines the term "Domain 1020 Certificate" as the certificate used in an autonomic domain. The ACP 1021 domain certificate is that domain certificate when ACP nodes are 1022 (fully) autonomic nodes. Finally, this document uses the term ACP 1023 network to refer to the network created by active ACP nodes in an ACP 1024 domain. The ACP network itself can extend beyond ACP nodes through 1025 the mechanisms described in Section 8.1. 1027 6.1.1. ACP Certificates 1029 ACP domain certificates MUST be [RFC5280] compliant X.509 1030 certificates. 1032 ACP nodes MUST support RSA and Elliptic Curve (ECC) public keys in 1033 ACP certificates. ACP certificates wth ECC keys MUST indicate to be 1034 Elliptic Curve Diffie-Hellman capable (ECDH) if X.509 v3 keyUsage and 1035 extendedKeyUsage are included in the certificate. 1037 ACP nodes MUST support Certificates RSA keys with no less than 2048 1038 bit key length and ECC keys with NIST P-256, P-384 and P-521 key 1039 length (and curve) or better. ACP nodes MUST support SHA-256, SHA- 1040 384, SHA-512 or better signatures for ACP certificates with RSA key 1041 and the same RSA signatures plus ECDSA signatures for ACP 1042 certificates with ECC key. 1044 The ACP certificate SHOULD use an RSA key and an RSA signature when 1045 the ACP certificate is intended to be used not only for ACP 1046 authentication but also for other purposes. The ACP certificate MAY 1047 use an ECC key and an ECDSA signature if the ACP certificate is only 1048 used for ACP and ANI authentication and authorization. 1050 Any secure channel protocols used for the ACP as specified in this 1051 document or extensions of this document MUST therefore support 1052 authentication (e.g.:signing) starting with these type of 1053 certificates. See [RFC4492] for more information. 1055 The reason for these choices are as follows: As of 2020, RSA is still 1056 more widely used than ECC, therefore the MUST for RSA. ECC offers 1057 equivalent security at (logarithmically) shorter key lengths (see 1058 [RFC4492]). This can be beneficial especially in the presence of 1059 constrained bandwidth or constrained nodes in an ACP/ANI network. 1060 Some ACP functions such as GRASP peer-2-peer across the ACP require 1061 end-to-end/any-to-any authentication/authorization, therefore ECC can 1062 only reliably be used in the ACP when it MUST be supported on all ACP 1063 nodes. RSA signatures are mandatory to be supported also for ECC 1064 certificates because CAs themselves may not support ECC yet. 1066 For further certificate details, ACP certificates may follow the 1067 recommendations from [CABFORUM]. 1069 The ACP domain certificate SHOULD be used for any authentication 1070 between nodes with ACP domain certificates (ACP nodes and NOC nodes) 1071 where the required authorization condition is ACP domain membership, 1072 such as ACP node to NOC/OAM end-to-end security and ASA to ASA end- 1073 to-end security. Section 6.1.3 defines this "ACP domain membership 1074 check". The uses of this check that are standardized in this 1075 document are for the establishment of hop-by-hop ACP secure channels 1076 (Section 6.6) and for ACP GRASP (Section 6.8.2) end-to-end via TLS 1077 ([RFC5246]). 1079 The ACP domain membership check requires a minimum amount of elements 1080 in a certificate as described in Section 6.1.3. All elements are 1081 [RFC5280] compliant. The identity of a node in the ACP is carried 1082 via the ACP Domain Information Field as defined in Section 6.1.2 1083 which is encoded as an rfc822Name field. 1085 Any other field of the ACP domain certificate is to be populated as 1086 required by [RFC5280] or desired by the operator of the ACP domain 1087 ACP registrars/CA and required by other purposes that the ACP domain 1088 certificate is intended to be used for. 1090 For diagnostic and other operational purposes, it is beneficial to 1091 copy the device identifying fields of the node's IDevID into the ACP 1092 domain certificate, such as the "serialNumber" (see 1093 [I-D.ietf-anima-bootstrapping-keyinfra] section 2.3.1). This can be 1094 done for example if it would be acceptable for the devices 1095 "serialNumber" to be signalled via the Link Layer Discovery Protocol 1096 (LLDP, [LLDP]) because like LLDP signalled information, the ACP 1097 certificate information can be retrieved bei neighboring nodes 1098 without further authentication and be used either for beneficial 1099 diagnostics or for malicious attacks. Retrieval of the ACP 1100 certificate is possible via a (failing) attempt to set up an ACP 1101 secure channel, and the "serialNumber" contains usually device type 1102 information that may help to faster determine working exploits/ 1103 attacks against the device. 1105 Note that there is no intention to constrain authorization within the 1106 ACP or autonomic networks using the ACP to just the ACP domain 1107 membership check as defined in this document. It can be extended or 1108 modified with future requirements. Such future authorizations can 1109 use and require additional elements in certificates or policies or 1110 even additional certificates. For an example, see Appendix A.10.5. 1112 6.1.2. ACP Certificate ACP Domain Information Field 1114 Information about the domain MUST be encoded in the domain 1115 certificate in a subjectAltName / rfc822Name field according to the 1116 following ABNF ([RFC5234]) definition: 1118 [RFC Editor: Please substitute SELF in all occurrences of rfcSELF in 1119 this document with the RFC number assigned to this document and 1120 remove this comment line] 1122 domain-information = local-part "@" acp-domain-name 1123 local-part = key [ "+" local-info ] 1124 key = "rfcSELF" 1125 local-info = [ acp-address ] [ "+" rsub extensions ] 1126 HEXLC = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" 1127 ; DIGIT as of RFC5234 section B.1 1128 acp-address = 32HEXLC | "0" 1129 rsub = [ ] ; as of RFC1034, section 3.5 1130 acp-domain-name = ; ; as of RFC 1034, section 3.5 1131 extensions = *( "+" extension ) 1132 extension = ; future standard definition. 1133 ; Must fit RFC5322 simple dot-atom format. 1135 routing-subdomain = [ rsub "." ] acp-domain-name 1137 Example: 1138 given an ACP address of fd89:b714:f3db:0:200:0:6400:0000 1139 and an ACP domain-name of acp.example.com 1140 and an rsub extenstion of area51.research 1142 then this results in: 1143 domain-information = rfcSELF+fd89b714F3db00000200000064000000 1144 +area51.research@acp.example.com 1145 acp-domain-name = acp.example.com 1146 routing-subdomain = area51.research.acp.example.com 1148 Figure 2: ACP Domain Information Field ABNF 1150 domain-information is the encoded information that is put into the 1151 ACP domain certificates subjectAltName / rfc822Name field. routing- 1152 subdomain is a string that can be constructed from the domain- 1153 information, and it is used in the hash-creation of the ULA (see 1154 below). The requirements and sementics of the parts of this 1155 information are explained in the following paragraphs: 1157 Nodes complying with this specification MUST be able to receive their 1158 ACP address through the domain certificate, in which case their own 1159 ACP domain certificate MUST have the 32HEXDIG "acp-address" field. 1160 Nodes complying with this specification MUST also be able to 1161 authenticate nodes as ACP domain members or ACP secure channel peers 1162 when they have a 0-value acp-address field and as ACP domain members 1163 (but not as ACP secure channel peers) when they have an empty acp- 1164 address field. See Section 6.1.3. 1166 "acp-domain-name" is used to indicate the ACP Domain across which all 1167 ACP nodes trust each other and are willing to build ACP channels to 1168 each other. See Section 6.1.3. Acp-domain-name SHOULD be the FQDN 1169 of a DNS domain owned by the operator assigning the certificate. 1170 This is a simple method to ensure that the domain is globally unique 1171 and collision of ACP addresses would therefore only happen due to ULA 1172 hash collisions (see Section 6.10.2). If the operator does not own 1173 any FQDN, it should choose a string (in FQDN format) that it intends 1174 to be equally unique. 1176 To keep the encoding simple, there is no consideration for 1177 internationalized acp-domain-names. The ACP domain information is 1178 not intended for enduser consumption, and there is no protection 1179 against someone not owning a domain name to simpy choose it. 1180 Instead, it only serves as a hash seed for the ULA and for 1181 diagnostics to the operator. Therefore, any operator owning only an 1182 internationalized domain name should be able to pick an equivalently 1183 unique 7-bit ASCII acp-domain-name string representing the 1184 internationalized domain name. 1186 "routing-subdomain" is a heuristic that allows a Registrar to 1187 consistently generate a unique 48-bit ULA prefix for ACP addresses. 1188 The presence of the "rsub" component allows to a single ACP domain to 1189 employ multiple /48 ULA prefixes. See Appendix A.7 for example use- 1190 cases. 1192 The optional "extensions" field is used for future standardized 1193 extensions to this specification. It MUST be ignored if present and 1194 not understood. 1196 Formatting notes: 1198 o "rsub" needs to be in the "local-part": If the format just had 1199 routing-subdomain as the domain part of the domain-information, 1200 rsub and acp-domain-name could not be separated from each other. 1201 It also makes domain-information a valid e-mail target across all 1202 routing-subdomains. 1204 o "acp-address" cannot use standard IPv6 address formats because it 1205 has to match the simple dot-atom format of [RFC5322]. The 1206 character ":" is not allowed in that format. 1208 o If "acp-address" is empty, and "rsub" is empty too, the "local- 1209 part" will have the format "rfcSELF++extension(s)". The two plus 1210 characters are necessary so the node can unambiguously parse that 1211 both "acp-address" and "rsub" are empty. 1213 o The maximum size of "domain-information" is 254 characters and the 1214 maximum size of local-part is 64 characters according to [RFC5280] 1215 that is referring to [RFC2821] (superseded by [RFC5321]). 1217 The subjectAltName / rfc822Name encoding of the ACP domain name and 1218 ACP address is used for the following reasons: 1220 Rfc822name encoding for the ACP domain information was choosen for 1221 the following reasons. 1223 o The ACP domain information field is the identifier of a node's 1224 ACP. It includes the the necessary components to identify a nodes 1225 ACP both from within the ACP as well as from the outside of the 1226 ACP. 1228 o For manual and/or automated diagnostics and backend management of 1229 devices and ACPs, it is necessary to have an easily human readible 1230 and software parsed standard, single string representation of the 1231 ACP domain information. For example, inventory or other backend 1232 systems can always identify an entity by one unique string field 1233 but not by a combination of multiple fields, which would be 1234 necessary if there was no single string representation. 1236 o If the encoding of the ACP domain information into the ACP domains 1237 certificate was not that of such a string, it would be necessary 1238 to define a second standard encoding to provide this format 1239 (standard string encoding). 1241 o Rfc822 addresses have become standard identifiers of entities in 1242 many systems, including the majority of user identification in web 1243 or mobile applications, where in many cases, e-mail is not even 1244 part of the service for which an rfc822 address is used as an 1245 entities identifier. In single-sign-on systems for example, 1246 @ is instead used to indicate a with 1247 which authentication and authorization of is 1248 performend without any other use of RFC822 than its address format 1249 (e.g.: no rfc822 formatted message exchanges). 1251 o Encoding the ACP nodes identity/name in the format of an 1252 rfc822address is therefore following common practices for how 1253 rfc822 addresses are used in other contexts. It also very well 1254 matches the format of rfc822 address structure @ because the ACP domain information does logically 1256 also consist of a identifying the ACP, and a 1257 identifying a nodes ACP. 1259 o subjectAltName / rfc822Name is the standard, mandatory to 1260 implement certificate attribute to encode the certificate subjects 1261 rfc822 address and can be the only subjects name. 1263 Compatibilities: 1265 o It should be possible to use the ACP domain certificate as an 1266 LDevID on the system for other uses beside the ACP. Therefore, 1267 the information element required for the ACP should be encoded so 1268 that it minimizes the possibility of creating incompatibilities 1269 with such other uses. The subjectName for example is for example 1270 often used as an entity identifier in non-ACP uses. 1272 o The element should not require additional ASN.1 en/decoding, 1273 because libraries to access certificate information especially for 1274 embedded devices may not support extended ASN.1 decoding beyond 1275 predefined, manadatory fields. subjectAltName / rfc822Name is such 1276 a mandatory predefined field. subjectAlName / otherName for 1277 example is not. 1279 o Encoding of the ACP domain information as a human readable string 1280 in a manadatory certificate field also has the benefit that it can 1281 be diagnosed/decoded in any pre-existing certificate diagnostic 1282 software. 1284 o The element required for the ACP should not be misinterpreted by 1285 any other uses of the LDevID. If the element used for the ACP is 1286 interpreted by other components than the ACP, the impact should be 1287 benign. By using fully rfc822address compliant encoding, the 1288 benign side effect of non-ACP software using the ACP rfc822address 1289 would be emails sent to the mailbox identified by the 1290 rfc822address. If it is desired to receive such emails, suitable 1291 email software may also support assigning all rfc822addresses for 1292 an ACP domain to a single mailbox rfcSELF@. This is 1293 possible when "+" (which follows rfcSELF) is supported by the Mail 1294 User Agent as a separator between mail subscriber and sub-mailbox. 1296 See section 4.2.1.6 of [RFC5280] for details on the subjectAltName 1297 field. 1299 6.1.3. ACP domain membership check 1301 The following points constitute the ACP domain membership check of a 1302 candidate peer via its certificate: 1304 1: The peer certificate MUST be valid (lifetime). 1306 2: The peer has proved ownership of the private key associated with 1307 the certificate's public key. This check is performed by the 1308 security association protocol used, for example [RFC7296], section 1309 2.15. 1311 3: The peer's certificate passes certificate path validation as 1312 defined in [RFC5280], section 6 against one of the TA associated 1313 with the ACP node's ACP domain certificate (see Section 6.1.4 1314 below). 1316 4: If the node certificate indicates a Certificate Revocation List 1317 (CRL) Distribution Point (CDP) ([RFC5280], section 4.2.1.13) or 1318 Online Certificate Status Protocol (OCSP) responder ([RFC5280], 1319 section 4.2.2.1), then the peer's certificate MUST be valid 1320 according to those criteria: An OCSP check for the peer's 1321 certificate across the ACP MUST succeed or the peer certificate 1322 MUST not be listed in the CRL retrieved from the CDP. This rule 1323 has to be skipped for ACP secure channel peer authentication when 1324 the node has no ACP or non-ACP connectivity to retrieve current 1325 CRL or access an OCSP responder (and the security association 1326 protocol itself has also no way to communicate CRL or OCSP check). 1328 When an ACP node learns later via OCSP/CRL that an ACP peer's 1329 certificate is invalid for which rule 4 had to be skipped during 1330 ACP secure channel establishment, then the ACP secure channel to 1331 that peer MUST be closed even if this peer is the only 1332 connectivity to access CRL/OCSP. This applies (of course) to all 1333 ACP secure channels to this peer if there are multiple. The ACP 1334 secure channel connection MUST be retried periodically to support 1335 the case that the neighbor aquires a new, valid certificate. 1337 5: The peer's certificate has a syntactically valid ACP domain 1338 information field (encoded as subjectAltName / rfc822Name) and the 1339 acp-domain-name in that peer's domain information field is the 1340 same as in this ACP node's certificate (lowercase normalized). 1342 When checking a candidate peer's certificate for the purpose of 1343 establishing an ACP secure channel, one additional check is 1344 performed: 1346 6: The candidate peer certificate's ACP domain information field 1347 has a non-empty acp-address field (either 32HEXDIG or 0, according 1348 to Figure 2). 1350 Technically, ACP secure channels can only be built with nodes that 1351 have an acp-address. Rule 6 ensures that this is taken into account 1352 during ACP domain membership check. 1354 Nodes with an empty acp-address field can only use their ACP domain 1355 certificate for non-ACP-secure channel authentication purposes. This 1356 includes for example NMS type nodes permitted to communicate into the 1357 ACP via ACP connect (Section 8.1) 1359 The special value 0 in an ACP certificates acp-address field is used 1360 for nodes that can and should determine their ACP address through 1361 other mechanisms than learning it through the acp-address field in 1362 their ACP domain certificate. These ACP nodes are permitted to 1363 establish ACP secure channels. Mechanisms for those nodes to 1364 determine their ACP address are outside the scope of this 1365 specification, but this option is defined here so that any ACP nodes 1366 can build ACP secure channels to them according to Rule 6. 1368 In summary: 1370 Steps 1...4 constitute standard certificate validity verification 1371 and private key authentication as defined by [RFC5280] and 1372 security association protocols (such as Internet Key Exchange 1373 Protocol version 2 IKEv2 [RFC7296] when leveraging certificates. 1375 Steps 1...4 do not include verification of any pre-existing form 1376 of non-public-key-only based identity elements of a certificate 1377 such as a web servers domain name prefix often encoded in 1378 certificate common name. Steps 5 and 6 are the equivalent steps. 1380 Step 4 Constitutes standard CRL/OCSP checks refined for the case 1381 of missing connectivity and limited functionality security 1382 association protocols. 1384 Step 5 Checks for the presence of an ACP identity for the peer. 1386 Steps 1...5 authorize to build any secure connection between 1387 members of the same ACP domain except for ACP secure channels. 1389 Step 6 is the additional verification of the presence of an ACP 1390 address. 1392 Steps 1...6 authorize to build an ACP secure channel. 1394 For brevity, the remainder of this document refers to this process 1395 only as authentication instead of as authentication and 1396 authorization. 1398 6.1.3.1. Realtime clock and Time Validation 1400 An ACP node with a realtime clock in which it has confidence, MUST 1401 check the time stamps when performing ACP domain membership check 1402 such as as the certificate validity period in step 1. and the 1403 respective times in step 4 for revocation information (e.g.: 1404 signingTimes in CMS signatures). 1406 An ACP node without such a realtime clock MAY ignore those time stamp 1407 validation steps if it does not know the current time. Such an ACP 1408 node SHOULD obtain the current time in a secured fashion, such as via 1409 a Network Time Protocol signalled through the ACP. It then ignores 1410 time stamp validation only until the current time is known. In the 1411 absence of implementing a secured mechanism, such an ACP node MAY use 1412 a current time learned in an insecured fashion in the ACP domain 1413 membership check. 1415 Beside ACP domain membership check, the ACP itself has no dependency 1416 against knowledge of the current time, but protocols and services 1417 using the ACP will likley have the need to know the current time. 1418 For example event logging. 1420 6.1.4. Trust Points and Trust Anchors 1422 ACP nodes need Trust Point (TP) certificates to perform certificate 1423 path validation as required by Section 6.1.3, rule 3. Trust Point(s) 1424 MUST be provisioned to an ACP node (together with its ACP domain 1425 certificate) by an ACP Registrar during initial enrolment of a 1426 candidate ACP node. ACP nodes MUST also support renewal of TPs via 1427 Enrollment over Secure Transport (EST, see [RFC7030]), as described 1428 below in Section 6.1.5. 1430 Trust Point is the term used in this document for a CA and its 1431 associated set of certificates. Multiple certificates are required 1432 for a CA to deal with CA certificate renewals as explained in 1433 Section 4.4 of CMP ([RFC4210]). 1435 A certificate path is a chain of certificates starting at the ACP 1436 certificate (leaf/end-entity) followed by zero or more intermediate 1437 Trust Point or sub-CA certificates and ending with a self-signed 1438 certificate of a so called root-CA or Trust Anchor. Certificate path 1439 validation authenticates that the ACP certificate is signed by a 1440 Trust Anchor, directly or indirectly via one or more intermediate 1441 Trust Points. 1443 Note that different ACP nodes may have different Trust Points and 1444 even different Trust Anchors in their certificate path, as long as 1445 the set of Trust Points for all ACP node includes the same set of 1446 Trust Anchors (usually 1), and each ACP nodes set of Trust Anchors 1447 includes the intermediate Trust Points for its own ACP domain 1448 certificate. The protocols through which ACP domain membership check 1449 rules 1-4 are performed therefore need to support the exchange not 1450 only of the ACP nodes certificates, but also their intermediate Trust 1451 Points. 1453 ACP nodes MUST support for the ACP domain membership check the 1454 certificate path validation with 0 or 1 intermediate Trust Points. 1455 They SHOULD support 2 intermediate Trust Points and two Trust Anchors 1456 (to permit migration to different root-CAs). 1458 Trust Points for ACP domain certificates are trusted to sign 1459 certificates with valid ACP domain information fields only for 1460 trusted ACP registrars of that domain. This can be achieved by using 1461 Trust Anchors private to the owner of the ACP domain or potentially 1462 through appropriate contractual agreements between the involved 1463 parties. Public CA without such obligations and guarantees can not 1464 be used. 1466 A single owner can operate multiple independent ACP domains from the 1467 same set of private trust anchors (CAs) when the ACP Registrars are 1468 trusted not to permit certificates with incorrect ACP information 1469 fields to be signed, such as ACP information with a wrong acp-domain 1470 field. In this case, CAs can be completely unaware of ACP specifics, 1471 so that it should be possible to use any existing CA software. When 1472 ACP Registrars are not to be trusted, the correctness of the ACP 1473 domain information field for the candidate ACP node has to be 1474 verified by the CA signing the ACP domain certificate. 1476 6.1.5. Certificate and Trust Point Maintenance 1478 ACP nodes MUST support renewal of their Certificate and TPs via EST 1479 ("Enrollment over Secure Transport", see [RFC7030]) and MAY support 1480 other mechanisms. An ACP network MUST have at least one ACP node 1481 supporting EST server functionality across the ACP so that EST 1482 renewal is useable. 1484 ACP nodes SHOULD be able to remember the IPv6 locator parameters of 1485 the O_IPv6_LOCATOR in GRASP of the EST server from which they last 1486 renewed their ACP domain certificate. They SHOULD provide the 1487 ability for these EST server parameters to also be set by the ACP 1488 Registrar (see Section 6.10.7) that initially enrolled the ACP device 1489 with its ACP domain certificate. When BRSKI (see 1490 [I-D.ietf-anima-bootstrapping-keyinfra]) is used, the IPv6 locator of 1491 the BRSKI registrar from the BRSKI TLS connection SHOULD be 1492 remembered and used for the next renewal via EST if that registrar 1493 also announces itself as an EST server via GRASP (see next section) 1494 on its ACP address. 1496 The EST server MUST present a certificate that is passing ACP domain 1497 membership check in its TLS connection setup (Section 6.1.3, rules 1498 1..5, not rule 6 as this is not for an ACP secure channel setup). 1499 The EST server certificate MUST also contain the id-kp-cmcRA 1500 [RFC6402] extended key usage extension and the EST client MUST check 1501 its presence. 1503 The additional check against the id-kp-cmcRA extended key usage 1504 extension field ensures that clients do not fall prey to an illicit 1505 EST server. While such illicit EST servers should not be able to 1506 support certificate signing requests (as they are not able to elicit 1507 a signing response from a valid CA), such an illicit EST server would 1508 be able to provide faked CA certificates to EST clients that need to 1509 renew their CA certificates when they expire. 1511 Note that EST servers supporting multiple ACP domains will need to 1512 have for each of these ACP domains a separate certificate and respond 1513 on a different transport address (IPv6 address and/or TCP port), but 1514 this is easily automated on the EST server as long as the CA does not 1515 restrict registrars to request certificates with the id-kp-cmcRA 1516 extended usage extension for themselves. 1518 6.1.5.1. GRASP objective for EST server 1520 ACP nodes that are EST servers MUST announce their service via GRASP 1521 in the ACP through M_FLOOD messages. See [I-D.ietf-anima-grasp], 1522 section 2.8.11 for the definition of this message type: 1524 Example: 1526 [M_FLOOD, 12340815, h'fd89b714f3db0000200000064000001', 210000, 1527 ["SRV.est", 4, 255 ], 1528 [O_IPv6_LOCATOR, 1529 h'fd89b714f3db0000200000064000001', TCP, 443] 1530 ] 1532 Figure 3: GRASP SRV.est example 1534 The formal definition of the objective in Concise data definition 1535 language (CDDL) (see [RFC8610]) is as follows: 1537 flood-message = [M_FLOOD, session-id, initiator, ttl, 1538 +[objective, (locator-option / [])]] 1539 ; see example above and explanation 1540 ; below for initiator and ttl 1542 objective = ["SRV.est", objective-flags, loop-count, 1543 objective-value] 1545 objective-flags = sync-only ; as in GRASP spec 1546 sync-only = 4 ; M_FLOOD only requires synchronization 1547 loop-count = 255 ; recommended as there is no mechanism 1548 ; to discover network diameter. 1549 objective-value = any ; reserved for future extensions 1551 Figure 4: GRASP SRV.est definition 1553 The objective name "SRV.est" indicates that the objective is an 1554 [RFC7030] compliant EST server because "est" is an [RFC6335] 1555 registered service name for [RFC7030]. Objective-value MUST be 1556 ignored if present. Backward compatible extensions to [RFC7030] MAY 1557 be indicated through objective-value. Non [RFC7030] compatible 1558 certificate renewal options MUST use a different objective-name. 1559 Non-recognized objective-values (or parts thereof if it is a 1560 structure partially understood) MUST be ignored. 1562 The M_FLOOD message MUST be sent periodically. The default SHOULD be 1563 60 seconds, the value SHOULD be operator configurable but SHOULD be 1564 not smaller than 60 seconds. The frequency of sending MUST be such 1565 that the aggregate amount of periodic M_FLOODs from all flooding 1566 sources cause only negligible traffic across the ACP. The time-to- 1567 live (ttl) parameter SHOULD be 3.5 times the period so that up to 1568 three consecutive messages can be dropped before considering an 1569 announcement expired. In the example above, the ttl is 210000 msec, 1570 3.5 times 60 seconds. When a service announcer using these 1571 parameters unexpectedly dies immediately after sending the M_FLOOD, 1572 receivers would consider it expired 210 seconds later. When a 1573 receiver tries to connect to this dead service before this timeout, 1574 it will experience a failing connection and use that as an indication 1575 that the service instance is dead and select another instance of the 1576 same service instead (from another GRASP announcement). 1578 6.1.5.2. Renewal 1580 When performing renewal, the node SHOULD attempt to connect to the 1581 remembered EST server. If that fails, it SHOULD attempt to connect 1582 to an EST server learned via GRASP. The server with which 1583 certificate renewal succeeds SHOULD be remembered for the next 1584 renewal. 1586 Remembering the last renewal server and preferring it provides 1587 stickiness which can help diagnostics. It also provides some 1588 protection against off-path compromised ACP members announcing bogus 1589 information into GRASP. 1591 Renewal of certificates SHOULD start after less than 50% of the 1592 domain certificate lifetime so that network operations has ample time 1593 to investigate and resolve any problems that causes a node to not 1594 renew its domain certificate in time - and to allow prolonged periods 1595 of running parts of a network disconnected from any CA. 1597 6.1.5.3. Certificate Revocation Lists (CRLs) 1599 The ACP node SHOULD support revocation through CRL(s) via HTTP from 1600 one or more CRL Distribution Points (CDPs). The CDP(s) MUST be 1601 indicated in the Domain Certificate when used. If the CDP URL uses 1602 an IPv6 address (ULA address when using the addressing rules 1603 specified in this document), the ACP node will connect to the CDP via 1604 the ACP. If the CDP uses a domain name, the ACP node will connect to 1605 the CDP via the Data-Plane. 1607 It is common to use domain names for CDP(s), but there is no 1608 requirement for the ACP to support DNS. Any DNS lookup in the Data- 1609 Plane is not only a possible security issue, but it would also not 1610 indicate whether the resolved address is meant to be reachable across 1611 the ACP. Therefore, the use of an IPv6 address versus the use of a 1612 DNS name doubles as an indicator whether or not to reach the CDP via 1613 the ACP. 1615 A CDP can be reachable across the ACP either by running it on a node 1616 with ACP or by connecting its node via an ACP connect interface (see 1617 Section 8.1). The CDP SHOULD use an ACP domain certificate for its 1618 HTTPs connections. The connecting ACP node SHOULD verify that the 1619 CDP certificate used during the HTTPs connection has the same ACP 1620 address as indicated in the CDP URL of the node's ACP domain 1621 certificate if the CDP URL uses an IPv6 address. 1623 6.1.5.4. Lifetimes 1625 Certificate lifetime may be set to shorter lifetimes than customary 1626 (1 year) because certificate renewal is fully automated via ACP and 1627 EST. The primary limiting factor for shorter certificate lifetimes 1628 is load on the EST server(s) and CA. It is therefore recommended 1629 that ACP domain certificates are managed via a CA chain where the 1630 assigning CA has enough performance to manage short lived 1631 certificates. See also Section 10.2.4 for discussion about an 1632 example setup achieving this. See also [I-D.ietf-acme-star]. 1634 When certificate lifetimes are sufficiently short, such as few hours, 1635 certificate revocation may not be necessary, allowing to simplify the 1636 overall certificate maintenance infrastructure. 1638 See Appendix A.2 for further optimizations of certificate maintenance 1639 when BRSKI can be used ("Bootstrapping Remote Secure Key 1640 Infrastructures", see [I-D.ietf-anima-bootstrapping-keyinfra]). 1642 6.1.5.5. Re-enrollment 1644 An ACP node may determine that its ACP domain certificate has 1645 expired, for example because the ACP node was powered down or 1646 disconnected longer than its certificate lifetime. In this case, the 1647 ACP node SHOULD convert to a role of a re-enrolling candidate ACP 1648 node. 1650 In this role, the node does maintain the trust anchor and certificate 1651 chain associated with its ACP domain certificate exclusively for the 1652 purpose of re-enrollment, and attempts (or waits) to get re-enrolled 1653 with a new ACP certificate. The details depend on the mechanisms/ 1654 protocols used by the ACP registrars. 1656 Please refer to Section 6.10.7 and 1657 [I-D.ietf-anima-bootstrapping-keyinfra] for explanations about ACP 1658 registrars and vouchers as used in the following text. When ACP is 1659 intended to be used without BRSKI, the details about BRSKI and 1660 vouchers in the following text can be skipped. 1662 When BRSKI is used (i.e.: on ACP nodes that are ANI nodes), the re- 1663 enrolling candidate ACP node would attempt to enroll like a candidate 1664 ACP node (BRSKI pledge), but instead of using the ACP nodes IDevID, 1665 it SHOULD first attempt to use its ACP domain certificate in the 1666 BRSKI TLS authentication. The BRSKI registrar MAY honor this 1667 certificate beyond its expiration date purely for the purpose of re- 1668 enrollment. Using the ACP node's domain certificate allows the BRSKI 1669 registrar to learn that node's ACP domain information field, so that 1670 the BRSKI registrar can re-assign the same ACP address information to 1671 the ACP node in the new ACP domain certificate. 1673 If the BRSKI registrar denies the use of the old ACP domain 1674 certificate, the re-enrolling candidate ACP node MUST re-attempt re- 1675 enrollment using its IDevID as defined in BRSKI during the TLS 1676 connection setup. 1678 Both when the BRSKI connection is attempted with the old ACP domain 1679 certificate or the IDevID, the re-enrolling candidate ACP node SHOULD 1680 authenticate the BRSKI registrar during TLS connection setup based on 1681 its existing trust anchor/certificate chain information associated 1682 with its old ACP certificate. The re-enrolling candidate ACP node 1683 SHOULD only fall back to requesting a voucher from the BRSKI 1684 registrar when this authentication fails during TLS connection setup. 1686 When other mechanisms than BRSKI are used for ACP domain certificate 1687 enrollment, the principles of the re-enrolling candidate ACP node are 1688 the same. The re-enrolling candidate ACP node attempts to 1689 authenticate any ACP registrar peers during re-enrollment protocol/ 1690 mechanisms via its existing certificate chain/trust anchor and 1691 provides its existing ACP domain certificate and other identification 1692 (such as the IDevID) as necessary to the registrar. 1694 Maintaining existing trust anchor information is especially important 1695 when enrollment mechanisms are used that unlike BRSKI do not leverage 1696 a voucher mechanism to authenticate the ACP registrar and where 1697 therefore the injection of certificate failures could otherwise make 1698 the ACP node easily attackable remotely. 1700 When using BRSKI or other protocol/mechanisms supporting vouchers, 1701 maintaining existing trust anchor information allows for re- 1702 enrollment of expired ACP certificates to be more lightweight, 1703 especially in environments where repeated acquisition of vouchers 1704 during the lifetime of ACP nodes may be operationally expensive or 1705 otherwise undesirable. 1707 6.1.5.6. Failing Certificates 1709 An ACP domain certificate is called failing in this document, if/when 1710 the ACP node to which the certificate was issued can determine that 1711 it was revoked (or explicitly not renewed), or in the absence of such 1712 explicit local diagnostics, when the ACP node fails to connect to 1713 other ACP nodes in the same ACP domain using its ACP certificate. 1714 For connection failures to determine the ACP domain certificate as 1715 the culprit, the peer should pass the domain membership check 1716 (Section 6.1.3) and other reasons for the connection failure can be 1717 excluded because of the connection error diagnostics. 1719 This type of failure can happen during setup/refresh of a secure ACP 1720 channel connections or any other use of the ACP domain certificate, 1721 such as for the TLS connection to an EST server for the renewal of 1722 the ACP domain certificate. 1724 Example reasons for failing certificates that the ACP node can only 1725 discover through connection failure are that the domain certificate 1726 or any of its signing certificates could have been revoked or may 1727 have expired, but the ACP node cannot self-diagnose this condition 1728 directly. Revocation information or clock synchronization may only 1729 be available across the ACP, but the ACP node cannot build ACP secure 1730 channels because ACP peers reject the ACP node's domain certificate. 1732 ACP nodes SHOULD support the option to determines whether its ACP 1733 certificate is failing, and when it does, put itself into the role of 1734 a re-enrolling candidate ACP node as explained above 1735 (Section 6.1.5.5). 1737 6.2. ACP Adjacency Table 1739 To know to which nodes to establish an ACP channel, every ACP node 1740 maintains an adjacency table. The adjacency table contains 1741 information about adjacent ACP nodes, at a minimum: Node-ID 1742 (identifier of the node inside the ACP, see Section 6.10.3 and 1743 Section 6.10.5), interface on which neighbor was discovered (by GRASP 1744 as explained below), link-local IPv6 address of neighbor on that 1745 interface, certificate (including domain information field). An ACP 1746 node MUST maintain this adjacency table. This table is used to 1747 determine to which neighbor an ACP connection is established. 1749 Where the next ACP node is not directly adjacent (i.e., not on a link 1750 connected to this node), the information in the adjacency table can 1751 be supplemented by configuration. For example, the Node-ID and IP 1752 address could be configured. See Section 8.2. 1754 The adjacency table MAY contain information about the validity and 1755 trust of the adjacent ACP node's certificate. However, subsequent 1756 steps MUST always start with the ACP domain membership check against 1757 the peer (see Section 6.1.3). 1759 The adjacency table contains information about adjacent ACP nodes in 1760 general, independently of their domain and trust status. The next 1761 step determines to which of those ACP nodes an ACP connection should 1762 be established. 1764 6.3. Neighbor Discovery with DULL GRASP 1766 [RFC Editor: GRASP draft is in RFC editor queue, waiting for 1767 dependencies, including ACP. Please ensure that references to I- 1768 D.ietf-anima-grasp that include section number references (throughout 1769 this document) will be updated in case any last-minute changes in 1770 GRASP would make those section references change. 1772 Discovery Unsolicited Link-Local (DULL) GRASP is a limited subset of 1773 GRASP intended to operate across an insecure link-local scope. See 1774 section 2.5.2 of [I-D.ietf-anima-grasp] for its formal definition. 1775 The ACP uses one instance of DULL GRASP for every L2 interface of the 1776 ACP node to discover link level adjacent candidate ACP neighbors. 1777 Unless modified by policy as noted earlier (Section 5 bullet point 1778 2.), native interfaces (e.g., physical interfaces on physical nodes) 1779 SHOULD be initialized automatically to a state in which ACP discovery 1780 can be performed and any native interfaces with ACP neighbors can 1781 then be brought into the ACP even if the interface is otherwise not 1782 configured. Reception of packets on such otherwise not configured 1783 interfaces MUST be limited so that at first only IPv6 StateLess 1784 Address Auto Configuration (SLAAC - [RFC4862]) and DULL GRASP work 1785 and then only the following ACP secure channel setup packets - but 1786 not any other unnecessary traffic (e.g., no other link-local IPv6 1787 transport stack responders for example). 1789 Note that the use of the IPv6 link-local multicast address 1790 (ALL_GRASP_NEIGHBORS) implies the need to use Multicast Listener 1791 Discovery Version 2 (MLDv2, see [RFC3810]) to announce the desire to 1792 receive packets for that address. Otherwise DULL GRASP could fail to 1793 operate correctly in the presence of MLD snooping, non-ACP enabled L2 1794 switches ([RFC4541]) - because those would stop forwarding DULL GRASP 1795 packets. Switches not supporting MLD snooping simply need to operate 1796 as pure L2 bridges for IPv6 multicast packets for DULL GRASP to work. 1798 ACP discovery SHOULD NOT be enabled by default on non-native 1799 interfaces. In particular, ACP discovery MUST NOT run inside the ACP 1800 across ACP virtual interfaces. See Section 10.3 for further, non- 1801 normative suggestions on how to enable/disable ACP at node and 1802 interface level. See Section 8.2.2 for more details about tunnels 1803 (typical non-native interfaces). See Section 7 for how ACP should be 1804 extended on devices operating (also) as L2 bridges. 1806 Note: If an ACP node also implements BRSKI to enroll its ACP domain 1807 certificate (see Appendix A.2 for a summary), then the above 1808 considerations also apply to GRASP discovery for BRSKI. Each DULL 1809 instance of GRASP set up for ACP is then also used for the discovery 1810 of a bootstrap proxy via BRSKI when the node does not have a domain 1811 certificate. Discovery of ACP neighbors happens only when the node 1812 does have the certificate. The node therefore never needs to 1813 discover both a bootstrap proxy and ACP neighbor at the same time. 1815 An ACP node announces itself to potential ACP peers by use of the 1816 "AN_ACP" objective. This is a synchronization objective intended to 1817 be flooded on a single link using the GRASP Flood Synchronization 1818 (M_FLOOD) message. In accordance with the design of the Flood 1819 message, a locator consisting of a specific link-local IP address, IP 1820 protocol number and port number will be distributed with the flooded 1821 objective. An example of the message is informally: 1823 [M_FLOOD, 12340815, h'fe80000000000000c0011001feef0000', 210000, 1824 ["AN_ACP", 4, 1, "IKEv2" ], 1825 [O_IPv6_LOCATOR, 1826 h'fe80000000000000c0011001feef0000', UDP, 15000] 1827 ["AN_ACP", 4, 1, "DTLS" ], 1828 [O_IPv6_LOCATOR, 1829 h'fe80000000000000c0011001feef0000', UDP, 17000] 1830 ] 1832 Figure 5: GRASP AN_ACP example 1834 The formal CDDL definition is: 1836 flood-message = [M_FLOOD, session-id, initiator, ttl, 1837 +[objective, (locator-option / [])]] 1839 objective = ["AN_ACP", objective-flags, loop-count, 1840 objective-value] 1842 objective-flags = sync-only ; as in the GRASP specification 1843 sync-only = 4 ; M_FLOOD only requires synchronization 1844 loop-count = 1 ; limit to link-local operation 1845 objective-value = method 1846 method = "IKEv2" / "DTLS" ; or future standard methods 1848 Figure 6: GRASP AN_ACP definition 1850 The objective-flags field is set to indicate synchronization. 1852 The loop-count is fixed at 1 since this is a link-local operation. 1854 In the above example the RECOMMENDED period of sending of the 1855 objective is 60 seconds. The indicated ttl of 210000 msec means that 1856 the objective would be cached by ACP nodes even when two out of three 1857 messages are dropped in transit. 1859 The session-id is a random number used for loop prevention 1860 (distinguishing a message from a prior instance of the same message). 1861 In DULL this field is irrelevant but has to be set according to the 1862 GRASP specification. 1864 The originator MUST be the IPv6 link local address of the originating 1865 ACP node on the sending interface. 1867 The 'objective-value' parameter is a string indicating the protocol 1868 available at the specified or implied locator. It is a protocol 1869 supported by the node to negotiate a secure channel. IKEv2 as shown 1870 above is the protocol used to negotiate an IPsec secure channel. 1872 The locator-option is optional and only required when the secure 1873 channel protocol is not offered at a well-defined port number, or if 1874 there is no well-defined port number. 1876 IKEv2 is the actual protocol used to negotiate an Internet Protocol 1877 security architecture (IPsec) connection. GRASP therefore indicates 1878 "IKEv2" and not "IPsec". If "IPsec" was used, this too could mean 1879 use of the obsolete older version IKE (v1) ([RFC2409]). IKEv2 has am 1880 IANA assigned port number 500, but in the above example, the 1881 candidate ACP neighbor is offering ACP secure channel negotiation via 1882 IKEv2 on port 15000 (purely to show through the example that GRASP 1883 allows to indicate the port number and it does not have to be the 1884 IANA assigned one). 1886 "DTLS" indicates DTLS version 1.2. This can also be a newer version 1887 of the protocol as long as it can negotiate down to version 1.2 in 1888 the presence of a peer only speaking DTLS version 1.2. There is no 1889 default UDP port for DTLS, it is always locally assigned by the node. 1890 For details, see Section 6.7.4. 1892 If a locator is included, it MUST be an O_IPv6_LOCATOR, and the IPv6 1893 address MUST be the same as the initiator address (these are DULL 1894 requirements to minimize third party DoS attacks). 1896 The secure channel methods defined in this document use the 1897 objective-values of "IKEv2" and "DTLS". There is no distinction 1898 between IKEv2 native and GRE-IKEv2 because this is purely negotiated 1899 via IKEv2. 1901 A node that supports more than one secure channel protocol method 1902 needs to flood multiple versions of the "AN_ACP" objective so that 1903 each method can be accompanied by its own locator-option. This can 1904 use a single GRASP M_FLOOD message as shown in Figure 5. 1906 Note that a node serving both as an ACP node and BRSKI Join Proxy may 1907 choose to distribute the "AN_ACP" objective and the respective BRSKI 1908 in the same M_FLOOD message, since GRASP allows multiple objectives 1909 in one message. This may be impractical though if ACP and BRSKI 1910 operations are implemented via separate software modules / ASAs. 1912 The result of the discovery is the IPv6 link-local address of the 1913 neighbor as well as its supported secure channel protocols (and non- 1914 standard port they are running on). It is stored in the ACP 1915 Adjacency Table (see Section 6.2), which then drives the further 1916 building of the ACP to that neighbor. 1918 Note that the DULL GRASP objective described does intentionally not 1919 include ACP nodes ACP domain certificate even though this would be 1920 useful for diagnostics and to simplify the security exchange in ACP 1921 secure channel security association protocols (see Section 6.7). The 1922 reason is that DULL GRASP messages are periodically multicasted 1923 across IPv6 subnets and full certificates could easily lead to 1924 fragmented IPv6 DULL GRASP multicast packets due to the size of a 1925 certificate. This would be highly undesirable. 1927 6.4. Candidate ACP Neighbor Selection 1929 An ACP node determines to which other ACP nodes in the adjacency 1930 table it should attempt to build an ACP connection. This is based on 1931 the information in the ACP Adjacency table. 1933 The ACP is established exclusively between nodes in the same domain. 1934 This includes all routing subdomains. Appendix A.7 explains how ACP 1935 connections across multiple routing subdomains are special. 1937 The result of the candidate ACP neighbor selection process is a list 1938 of adjacent or configured autonomic neighbors to which an ACP channel 1939 should be established. The next step begins that channel 1940 establishment. 1942 6.5. Channel Selection 1944 To avoid attacks, initial discovery of candidate ACP peers cannot 1945 include any non-protected negotiation. To avoid re-inventing and 1946 validating security association mechanisms, the next step after 1947 discovering the address of a candidate neighbor can only be to try 1948 first to establish a security association with that neighbor using a 1949 well-known security association method. 1951 From the use-cases it seems clear that not all type of ACP nodes can 1952 or need to connect directly to each other or are able to support or 1953 prefer all possible mechanisms. For example, code space limited IoT 1954 devices may only support DTLS because that code exists already on 1955 them for end-to-end security, but low-end in-ceiling L2 switches may 1956 only want to support Media Access Control Security (MacSec, see 1957 802.1AE ([MACSEC]) because that is also supported in their chips. 1958 Only a flexible gateway device may need to support both of these 1959 mechanisms and potentially more. Note that MacSec is not required by 1960 any profiles of the ACP in this specification but just mentioned as a 1961 likely next interesting secure channel protocol. 1963 To support extensible secure channel protocol selection without a 1964 single common mandatory to implement (MTI) protocol, ACP nodes MUST 1965 try all the ACP secure channel protocols it supports and that are 1966 feasible because the candidate ACP neighbor also announced them via 1967 its AN_ACP GRASP parameters (these are called the "feasible" ACP 1968 secure channel protocols). 1970 To ensure that the selection of the secure channel protocols always 1971 succeeds in a predictable fashion without blocking, the following 1972 rules apply: 1974 o An ACP node may choose to attempt to initiate the different 1975 feasible ACP secure channel protocols it supports according to its 1976 local policies sequentially or in parallel, but it MUST support 1977 acting as a responder to all of them in parallel. 1979 o Once the first secure channel protocol succeeds, the two peers 1980 know each other's certificates because they are used by all secure 1981 channel protocols for mutual authentication. The node with the 1982 lower Node-ID in the ACP address of its ACP domain certificate 1983 becomes Bob, the one with the higher Node-ID in the certificate 1984 Alice. A peer with an empty ACP address field in its ACP domain 1985 certificate becomes Bob (this specification does not define such 1986 peers, only the interoperability with them). 1988 o Bob becomes passive, he does not attempt to further initiate ACP 1989 secure channel protocols with Alice and does not consider it to be 1990 an error when Alice closes secure channels. Alice becomes the 1991 active party, continues to attempt setting up secure channel 1992 protocols with Bob until she arrives at the best one from her view 1993 that also works with Bob. 1995 For example, originally Bob could have been the initiator of one ACP 1996 secure channel protocol that Bob prefers and the security association 1997 succeeded. The roles of Bob and Alice are then assigned and the 1998 connection setup is completed. The protocol could for example be 1999 IPsec via IKEv2 ("IP security", see [RFC4301] and "Internet Key 2000 Exchange protocol version 2", see [RFC7296]. It is now up to Alice 2001 to decide how to proceed. Even if the IPsec connection from Bob 2002 succeeded, Alice might prefer another secure protocol over IPsec 2003 (e.g., FOOBAR), and try to set that up with Bob. If that preference 2004 of Alice succeeds, she would close the IPsec connection. If no 2005 better protocol attempt succeeds, she would keep the IPsec 2006 connection. 2008 The following sequence of steps show this example in more detail. 2009 Each step is tagged with [{:}]. The connection is 2010 included to easier distinguish which of the two competing connections 2011 the step belong to, one initiated by Node 1, one initiated by Node 2. 2013 [1] Node 1 sends GRASP AN_ACP message to announce itself 2015 [2] Node 2 sends GRASP AN_ACP message to announce itself 2017 [3] Node 2 receives [1] from Node 1 2019 [4:C1] Because of [3], Node 2 starts as initiator on its 2020 preferred secure channel protocol towards Node 1. 2021 Connection C1. 2023 [5] Node 1 receives [2] from Node 2 2025 [6:C2] Because of [5], Node 1 starts as initiator on its 2026 preferred secure channel protocol towards Node 2. 2027 Connection C2. 2029 [7:C1] Node1 and Node2 have authenticated each others 2030 certificate on connection C1 as valid ACP peers. 2032 [8:C1] Node 1 certificate has lower ACP Node-ID than Node2, 2033 therefore Node 1 considers itself Bob and Node 2 Alice 2034 on connection C1. Connection setup C1 is completed. 2036 [9] Node 1 (Bob)) refrains from attempting any further secure 2037 channel connections to Node 2 (Alice) as learned from [2] 2038 because it knows from [8:C1] that it is Bob relative 2039 to Node 1. 2041 [10:C2] Node1 and Node2 have authenticated each others 2042 certificate on connection C2 (like [7:C1]). 2044 [11:C2] Node 1 certificate has lower ACP Node-ID than Node2, 2045 therefore Node 1 considers itself Bob and Node 2 Alice 2046 on connection C1, but they also identify that C2 is to the 2047 same mutual peer as their C1, so this has no further impact. 2049 [12:C2] Node 1 (Alice) closes C1. Because of [8:C1], Node 2 (Bob) 2050 expected this. 2052 [13] Node 1 (Alice) and Node 2 (Bob) start data transfer across 2053 C2, which makes it become a secure channel for the ACP. 2055 Figure 7: Secure Channel sequence of steps 2057 All this negotiation is in the context of an "L2 interface". Alice 2058 and Bob will build ACP connections to each other on every "L2 2059 interface" that they both connect to. An autonomic node MUST NOT 2060 assume that neighbors with the same L2 or link-local IPv6 addresses 2061 on different L2 interfaces are the same node. This can only be 2062 determined after examining the certificate after a successful 2063 security association attempt. 2065 6.6. Candidate ACP Neighbor verification 2067 Independent of the security association protocol chosen, candidate 2068 ACP neighbors need to be authenticated based on their domain 2069 certificate. This implies that any secure channel protocol MUST 2070 support certificate based authentication that can support the ACP 2071 domain membership check as defined in Section 6.1.3. If it fails, 2072 the connection attempt is aborted and an error logged. Attempts to 2073 reconnect MUST be throttled. The RECOMMENDED default is exponential 2074 base 2 backoff with a minimum delay of 10 seconds and a maximum delay 2075 of 640 seconds. 2077 6.7. Security Association (Secure Channel) protocols 2079 This section describes how ACP nodes establish secured data 2080 connections to automatically discovered or configured peers in the 2081 ACP. Section 6.3 above described how IPv6 subnet adjacent peers are 2082 discovered automatically. Section 8.2 describes how non IPv6 subnet 2083 adjacent peers can be configured. 2085 Section 6.12.5.2 describes how secure channels are mapped to virtual 2086 IPv6 subnet interfaces in the ACP. The simple case is to map every 2087 ACP secure channel into a separate ACP point-to-point virtual 2088 interface Section 6.12.5.2.1. When a single subnet has multiple ACP 2089 peers this results in multiple ACP point-to-point virtual interfaces 2090 across that underlying multi-party IPv6 subnet. This can be 2091 optimized with ACP multi-access virtual interfaces Section 6.12.5.2.2 2092 but the benefits of that optimization may not justify the complexity 2093 of that option. 2095 6.7.1. General considerations 2097 Due to Channel Selection (Section 6.5), ACP can support an evolving 2098 set of security association protocols. These protocols only need to 2099 be used to establish secure channels with L2 adjacent ACP neighbors 2100 and only optionally (where needed) across non-ACP capable L3 network 2101 (see Section 8.2). Therefore, there is architecturally no need for 2102 any network wide MTI security association protocols. Instead, ACP 2103 nodes only need to implement those protocols required to interoperate 2104 with their candidate peers, not with potentially any node in the ACP 2105 domain. See Section 6.7.5 for an example of this. 2107 The degree of security required on every hop of an ACP network needs 2108 to be consistent across the network so that there is no designated 2109 "weakest link" because it is that "weakest link" that would otherwise 2110 become the designated point of attack. When the secure channel 2111 protection on one link is compromised, it can be used to send/receive 2112 packets across the whole ACP network. Therefore, even though the 2113 security association protocols can be different, their minimum degree 2114 of security should be comparable. 2116 Secure channel protocols do not need to always support arbitrary L3 2117 connectivity between peers, but can leverage the fact that the 2118 standard use case for ACP secure channels is an L2 adjacency. Hence, 2119 L2 mechanism dependent mechanisms could be adopted for use as secure 2120 channel association protocols: 2122 L2 mechanisms such as strong encrypted radio technologies or [MACSEC] 2123 may offer equivalent encryption and the ACP security association 2124 protocol may only be required to authenticate ACP domain membership 2125 of a peer and/or derive a key for the L2 mechanism. Mechanisms to 2126 auto-discover and associate ACP peers leveraging such underlying L2 2127 security are possible and desirable to avoid duplication of 2128 encryption, but none are specified in this document. 2130 Strong physical security of a link may stand in where cryptographic 2131 security is infeasible. As there is no secure mechanism to 2132 automatically discover strong physical security solely between two 2133 peers, it can only be used with explicit configuration and that 2134 configuration too could become an attack vector. This document 2135 therefore only specifies with ACP connect (Figure 15) one explicitly 2136 configured mechanism without any secure channel association protocol 2137 - for the case where both the link and the nodes attached to it have 2138 strong physical security. 2140 6.7.2. Common requirements 2142 The authentication of peers in any security association protocol MUST 2143 use the ACP domain certificate according to Section 6.1.3. Because 2144 auto-discovery of candidate ACP neighbors via GRASP (see Section 6.3) 2145 as specified in this document does not communicate the neighbors ACP 2146 domain certificate, and ACP nodes may not (yet) have any other 2147 network connectivity to retrieve certificates, any security 2148 association protocol MUST use a mechanism to communicate the 2149 certificate directly instead of relying on a referential mechanism 2150 such as communicating only a hash and/or URL for the certificate. 2152 A security association protocol MUST use Forward Secrecy (whether 2153 inherently or as part of a profile of the security association 2154 protocol). 2156 Because the ACP payload of legacy protocol payloads inside the ACP 2157 and hop-by-hop ACP flooded GRASP information is unencrypted, the ACP 2158 secure channel protocol requires confidentiality. Symmetric 2159 encryption for the transmission of secure channel data MUST use 2160 encryption schemes considered to be security wise equal to or better 2161 than AES256. There MUST NOT be support for NULL encryption. 2163 An ACP secure channel MUST immediately be terminated when the 2164 lifetime of any certificate in the chain used to authenticate the 2165 neighbor expires or becomes revoked. This may not be standard 2166 behavior in secure channel protocols because the certificate 2167 authentication may only influences the setup of the secure channel in 2168 these protocols, but may not be re-validated during the lifetime of 2169 the secure connection in the absence of this requirement. 2171 When introducing the profile for a security association protocol in 2172 support of the ACP, protocol options SHOULD be eliminated that do not 2173 provide benefits for devices that should be able to support the ACP. 2174 For example, definitions for security protocols often include old/ 2175 inferior security options required only to interoperate with existing 2176 devices that will not be a able to update to the currently preferred 2177 security options. Such old/inferior security options do not need to 2178 be supported when a security association protocol is first specified 2179 for the ACP, strengthening the "weakest link" and simplifying ACP 2180 implementation overhead. 2182 6.7.3. ACP via IPsec 2184 An ACP node announces its ability to support IPsec, negotiated via 2185 IKEv2, as the ACP secure channel protocol using the "IKEv2" 2186 objective-value in the "AN_ACP" GRASP objective. 2188 The ACP usage of IPsec and IKEv2 mandates a narrow profile of the 2189 current standards-track usage guidance for IPsec [RFC8221] and IKEv2 2190 [RFC8247]. This profile provides for stringent security properties 2191 and can exclude deprecated/legacy algorithms because there is no need 2192 for interoperability with legacy equipment for ACP secure channels. 2193 Any such backward compatibility would lead only to increased attack 2194 surface and implementation complexity, for no benefit. 2196 6.7.3.1. Native IPsec 2198 An ACP node that is supporting native IPsec MUST use IPsec in tunnel 2199 mode, negotiated via IKEv2, and with IPv6 payload (e.g., ESP Next 2200 Header of 41). It MUST use local and peer link-local IPv6 addresses 2201 for encapsulation. Manual keying MUST NOT be used, see Section 6.1. 2203 IPsec tunnel mode is required because the ACP will route/forward 2204 packets received from any other ACP node across the ACP secure 2205 channels, and not only its own generated ACP packets. With IPsec 2206 transport mode, it would only be possible to send packets originated 2207 by the ACP node itself. 2209 6.7.3.1.1. RFC8221 (IPsec/ESP) 2211 ACP IPsec implementations MUST comply with [RFC8221] (and its 2212 updates). The requirements from above and this section amend and 2213 superceed its requirements. 2215 AH MUST NOT be used (because it does not provide confidentiality). 2217 For the required ESP encryption algorithms in section 5 of [RFC8221] 2218 the following guidance applies: 2220 o ENCR_NULL AH MUST NOT be used (because it does not provide 2221 confidentiality). 2223 o ENCR_AES_GCM_16 is the only MTI ESP encryption algorithm for ACP 2224 via IPsec/ESP (it is already listed as MUST in [RFC8221]). 2226 o ENCR_AES_CBC and ENCR_AES_CCM_8 MAY be supported. If either 2227 provides higher performance than ENCR_AES_GCM_16 it SHOULD be 2228 supported. 2230 o ENCR_CHACHA20_POLY1305 SHOULD be supported at equal or higher 2231 performance than ENCR_AES_GCM_16. If that performance is not 2232 feasible, it MAY be supported. 2234 IKEv2 indicates an order for the offered algorithms. The algorithms 2235 SHOULD be ordered by performance. The first algorithm supported by 2236 both sides is generally choosen. 2238 Explanations: 2240 o There is no requirement to interoperate with legacy equipment in 2241 ACP secure channels, so a single MTI encryption algorithm for 2242 IPsec in ACP secure channels is sufficient for interoperability 2243 and allows for the most lightweight implementations. 2245 o ENCR_AES_GCM_16 is an authenticated encryption with associated 2246 data (AEAD) cipher mode, so no additional ESP authentication 2247 algorithm is needed, simplifying the MTI requirements of IPsec for 2248 the ACP. 2250 o There is no MTI requirement against support of ENCR_AES_CBC 2251 because ENCR_AES_GCM_16 is assumed to be feasible with less cost/ 2252 higher performance in modern devices hardware accelerated 2253 implementations compared to ENCR-AES_CBC. 2255 o ENCR_CHACHA20_POLY1305 is mandatory in [RFC8221] because of its 2256 target use as a fallback algorithm in case weaknesses in AES are 2257 uncoverered. Unfortunately, there is currently no way to 2258 automatically propagate across an ACP a policy to disallow use of 2259 AES based algorithms, so this target benefit of 2260 ENCR_CHACHA20_POLY1305 can not fully be adopted yet for the ACP. 2261 Therefore this algorithm is only recommended. Changing from AES 2262 to this algorithm at potentially big drop in performance could 2263 also render the ACP inoperable. Therefore the performance 2264 requirement against this algorithm so that it could become an 2265 effective security backup to AES for the ACP once a policy to 2266 switch over to it or prefer it is available in an ACP framework. 2268 [RFC8221] allows for 128-bit or 256-bit AES keys. This document 2269 mandates that only 256-bit AES keys MUST be supported. 2271 When [RFC8221] is updated, ACP implementations will need to consider 2272 legacy interoperability, and the IPsec WG has generally done a very 2273 good job of taking that into account in its recommendations. 2275 6.7.3.1.2. RFC847 (IKEv2) 2277 [RFC8247] provides a baseline recommendation for mandatory to 2278 implement ciphers, integrity checks, pseudo-random-functions and 2279 Diffie-Hellman mechanisms. Those recommendations, and the 2280 recommendations of subsequent documents apply well to the ACP. 2281 Because IKEv2 for ACP secure channels is sufficient to be implemented 2282 in control plane software, rather than in ASIC hardware, and ACP 2283 nodes supporting IKEv2 are not assumed to be code-space constrained, 2284 and because existing IKEv2 implementations are expected to support 2285 [RFC8247] recommendations, this documents makes no attempt to 2286 simplify its recommendations for use with the ACP. 2288 This document does establish a policy statement as permitted by 2289 [RFC8247] for the specific case of ACP traffic. 2291 The IKEv2 Diffie-Hellman key exchange group 19 (256-bit random ECP), 2292 listed as a SHOULD, is to be configured, along with the 2048-bit MODP 2293 (group 14). ECC provides a similar security level to finite-field 2294 (MODP) key exchange with a shorter key length, so is generally 2295 preferred absent other considerations. 2297 IKEv2 authentication MUST use the ACP domain certificates. The 2298 Certificate Encoding "PKCS #7 wrapped X.509 certificate" (1) MUST be 2299 supported. See [IKEV2IANA] for this and other IANA IKEv2 parameter 2300 names used in this text. 2302 A certificate payload with the ACP certificate MUST be included 2303 during IKEv2 authentication to support the ACP domain membership 2304 check as described in Section 6.1.3, because it is using additional 2305 elements of the ACP certificates. 2307 If certificate chains are used, all intermediate certificates up to, 2308 and including the locally provisioned trust anchor certificate MUST 2309 be signaled. See Section 6.10.7 for the sub-CA example in which 2310 certificate chains are used. 2312 While the top-trust anchor will never be used by an ACP peer with 2313 proper provisioned ACP TAs, it can provide a significant amount of 2314 useful information to debug an ACP network. There is some small 2315 concern that this might provide useful information to an attacker 2316 about who the network is, but the other certificates that are sent 2317 already clearly indicate this information. 2319 In IKEv2, ACP nodes are identified by their ACP address. The 2320 ID_IPv6_ADDR IKEv2 identification payload MUST be used and MUST 2321 convey the ACP address. If the peer's ACP domain certificate 2322 includes an ACP address in the ACP domain information field (not "0" 2323 or empty), the address in the IKEv2 identification payload MUST match 2324 it. See Section 6.1.3 for more information about "0" or empty ACP 2325 address fields in the ACP domain information field. 2327 IKEv2 authentication MUST use authentication method 14 ("Digital 2328 Signature") for ACP certificates; this authentication method can be 2329 used with both RSA and ECDSA certificates, as indicated by a PKIX- 2330 style OID. 2332 The Digital Signature hash SHA2-512 MUST be supported (in addition to 2333 SHA2-256). 2335 6.7.3.2. IPsec with GRE encapsulation 2337 In network devices it is often more common to implement high 2338 performance virtual interfaces on top of GRE encapsulation than on 2339 top of a "native" IPsec association (without any other encapsulation 2340 than those defined by IPsec). On those devices it may be beneficial 2341 to run the ACP secure channel on top of GRE protected by the IPsec 2342 association. 2344 The requirements for ESP/IPsec/IKEv2 are the same as for native IPsec 2345 (see Section 6.7.3.1) except that IPsec transport mode and next 2346 protocol GRE (47) are to be negotiated. Tunnel mode is not required 2347 because of GRE. 2349 If IKEv2 initiator and responder support IPsec over GRE, it has to be 2350 preferred over native IPsec. The ACP IPv6 traffic has to be carried 2351 across GRE according to [RFC7676]. 2353 6.7.4. ACP via DTLS 2355 We define the use of ACP via DTLS in the assumption that it is likely 2356 the first transport encryption supported in some classes of 2357 constrained devices because DTLS is already used in those devices but 2358 IPsec is not, and code-space may be limited. 2360 An ACP node announces its ability to support DTLS v1.2 compliant with 2361 the requirements defined in this document as an ACP secure channel 2362 protocol in GRASP through the "DTLS" objective-value in the "AN_ACP" 2363 objective. 2365 To run ACP via UDP and DTLS v1.2 [RFC6347], a locally assigned UDP 2366 port is used that is announced as a parameter in the GRASP AN_ACP 2367 objective to candidate neighbors. This port can also be any newer 2368 version of DTLS as long as that version can negotiate a DTLS v1.2 2369 connection in the presence of an DTLS v1.2 only peer. 2371 All ACP nodes supporting DTLS as a secure channel protocol MUST 2372 adhere to the DTLS implementation recommendations and security 2373 considerations of BCP 195 [RFC7525] except with respect to the DTLS 2374 version. ACP nodes supporting DTLS MUST support DTLS 1.2. They MUST 2375 NOT support older versions of DTLS. Implementation MUST comply with 2376 BCP 195, [RFC7525]. 2378 Unlike for IPsec, no attempts are made to simplify the requirements 2379 of the BCP 195 recommendations because the expectation is that DTLS 2380 would be using software-only implementations where the ability to 2381 reuse of widely adopted implementations is more important than 2382 minizing the complexity of a hardware accelerated implementation 2383 which is known to be important for IPsec. 2385 DTLS v1.3 ([I-D.ietf-tls-dtls13]) is "backward compatible" with DTLS 2386 v1.2 (see section 1. of DTLS v1.3): A DTLS implementation supporting 2387 both DTLS v1.2 and DTLS v1.3 does comply with the above requirements 2388 of negoting to DTLS v1.2 in the presence of a DTLS v1.2 only peer, 2389 but using DTLS v1.3 when booth peers support it. 2391 Version v1.2 is the MTI version of DTLS in this specification because 2393 o There is more experience with DTLS v1.2 across the spectrum of 2394 target ACP nodes. 2396 o Firmware of lower end, embedded ACP nodes may not support a newer 2397 version for a long time. 2399 o There are significant changes of DTLS v1.3, such as a different 2400 record layer requiring time to gain implementation and deployment 2401 experience especially on lower end, code space limited devices. 2403 o The existing BCP [RFC7525] for DTLS v1.2 may equally take longer 2404 time to be updated with experience from a newer DTLS version. 2406 o There are no significant use-case relevant benefits of DTLS v1.3 2407 over DTLS v1.2 in the context of the ACP profile for DTLS. For 2408 example, signaling performance improvements for session setup in 2409 DTLS v1.3 is not important for the ACP given the long-lived nature 2410 of ACP secure channel connections and the fact that DTLS 2411 connections are mostly link-local (short RTT). 2413 Nevertheless, newer versions of DTLS, such as DTLS v1.3 have more 2414 strict security requirements and use of the latest standard protocol 2415 version is for IETF security standards in general recommended. 2416 Therefore, ACP implementations are advised to support all the newer 2417 versions of DTLS that can still negotiate down to DTLS v1.2. 2419 [RFC-editor: if by the time of AUTH48, DTLS 1.3 would have evolved to 2420 be an RFC, then not only would the references to the DTLS v1.3 draft 2421 be changed to the RFC number, but that RFC is then going to be put 2422 into the normative list of references and the above paragraph is 2423 going to be amended to say: Implementations SHOULD support 2424 [DTLSv1.3-RFC]. This is not done right now, because there is no 2425 benefit in potentially waiting in RFC-editor queue for that RFC given 2426 how the text alreayd lays out a non-nrmative desire to support 2427 DTLSv1.3.] 2429 There is no additional session setup or other security association 2430 besides this simple DTLS setup. As soon as the DTLS session is 2431 functional, the ACP peers will exchange ACP IPv6 packets as the 2432 payload of the DTLS transport connection. Any DTLS defined security 2433 association mechanisms such as re-keying are used as they would be 2434 for any transport application relying solely on DTLS. 2436 6.7.5. ACP Secure Channel Profiles 2438 As explained in the beginning of Section 6.5, there is no single 2439 secure channel mechanism mandated for all ACP nodes. Instead, this 2440 section defines two ACP profiles (baseline and constrained) for ACP 2441 nodes that do introduce such requirements. 2443 A baseline ACP node MUST support IPsec natively and MAY support IPsec 2444 via GRE. A constrained ACP node that cannot support IPsec MUST 2445 support DTLS. An ACP node connecting an area of constrained ACP 2446 nodes with an area of baseline ACP nodes needs to support IPsec and 2447 DTLS and supports therefore the baseline and constrained profile. 2449 Explanation: Not all type of ACP nodes can or need to connect 2450 directly to each other or are able to support or prefer all possible 2451 secure channel mechanisms. For example, code space limited IoT 2452 devices may only support DTLS because that code exists already on 2453 them for end-to-end security, but high-end core routers may not want 2454 to support DTLS because they can perform IPsec in accelerated 2455 hardware but would need to support DTLS in an underpowered CPU 2456 forwarding path shared with critical control plane operations. This 2457 is not a deployment issue for a single ACP across these type of nodes 2458 as long as there are also appropriate gateway ACP nodes that support 2459 sufficiently many secure channel mechanisms to allow interconnecting 2460 areas of ACP nodes with a more constrained set of secure channel 2461 protocols. On the edge between IoT areas and high-end core networks, 2462 general-purpose routers that act as those gateways and that can 2463 support a variety of secure channel protocols is the norm already. 2465 ACP nodes need to specify in documentation the set of secure ACP 2466 mechanisms they support and should declare which profile they support 2467 according to above requirements. 2469 6.8. GRASP in the ACP 2471 6.8.1. GRASP as a core service of the ACP 2473 The ACP MUST run an instance of GRASP inside of it. It is a key part 2474 of the ACP services. The function in GRASP that makes it fundamental 2475 as a service of the ACP is the ability to provide ACP wide service 2476 discovery (using objectives in GRASP). 2478 ACP provides IP unicast routing via the RPL routing protocol (see 2479 Section 6.11). 2481 The ACP does not use IP multicast routing nor does it provide generic 2482 IP multicast services (the handling of GRASP link-local multicast 2483 messages is explained in Section 6.8.2). Instead, the ACP provides 2484 service discovery via the objective discovery/announcement and 2485 negotiation mechanisms of the ACP GRASP instance (services are a form 2486 of objectives). These mechanisms use hop-by-hop reliable flooding of 2487 GRASP messages for both service discovery (GRASP M_DISCOVERY 2488 messages) and service announcement (GRASP M_FLOOD messages). 2490 See Appendix A.5 for discussion about this design choice of the ACP. 2492 6.8.2. ACP as the Security and Transport substrate for GRASP 2494 In the terminology of GRASP ([I-D.ietf-anima-grasp]), the ACP is the 2495 security and transport substrate for the GRASP instance run inside 2496 the ACP ("ACP GRASP"). 2498 This means that the ACP is responsible for ensuring that this 2499 instance of GRASP is only sending messages across the ACP GRASP 2500 virtual interfaces. Whenever the ACP adds or deletes such an 2501 interface because of new ACP secure channels or loss thereof, the ACP 2502 needs to indicate this to the ACP instance of GRASP. The ACP exists 2503 also in the absence of any active ACP neighbors. It is created when 2504 the node has a domain certificate, and continues to exist even if all 2505 of its neighbors cease operation. 2507 In this case ASAs using GRASP running on the same node would still 2508 need to be able to discover each other's objectives. When the ACP 2509 does not exist, ASAs leveraging the ACP instance of GRASP via APIs 2510 MUST still be able to operate, and MUST be able to understand that 2511 there is no ACP and that therefore the ACP instance of GRASP cannot 2512 operate. 2514 The following explanation how ACP acts as the security and transport 2515 substrate for GRASP is visualized in Figure 8 below. 2517 GRASP unicast messages inside the ACP always use the ACP address. 2518 Link-local addresses from the ACP VRF MUST NOT be used inside 2519 objectives. GRASP unicast messages inside the ACP are transported 2520 via TLS which MUST comply with [RFC7525] execept that only TLS 2521 version 1.2 ([RFC5246]) is REQUIRED and TLS 1.3 ([RFC8446] is 2522 RECOMMENDED. There is no need for older version backward 2523 compatibility in the new use-case of ACP. Mutual authentication MUST 2524 use the ACP domain membership check defined in (Section 6.1.3). 2526 GRASP link-local multicast messages are targeted for a specific ACP 2527 virtual interface (as defined Section 6.12.5) but are sent by the ACP 2528 into an ACP GRASP virtual interface that is constructed from the TCP 2529 connection(s) to the IPv6 link-local neighbor address(es) on the 2530 underlying ACP virtual interface. If the ACP GRASP virtual interface 2531 has two or more neighbors, the GRASP link-local multicast messages 2532 are replicated to all neighbor TCP connections. 2534 TLS for GRASP MUST offer TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and 2535 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 and MUST NOT offer options 2536 with less than 256bit AES or less than SHA384. TLS for GRASP MUST 2537 also include the "Supported Elliptic Curves" extension, it MUST 2538 support support the NIST P-256 (secp256r1) and P-384 (secp384r1(24)) 2539 curves [RFC4492]. In addition, GRASP TLS clients SHOULD send an 2540 ec_point_formats extension with a single element, "uncompressed". 2541 For further interoperability recommendations, GRASP TLS 2542 implementations SHOULD follow [RFC7525]. 2544 TCP and TLS connections for GRASP in the ACP use the IANA assigned 2545 TCP port for GRASP (7107). Effectively the transport stack is 2546 expected to be TLS for connections from/to the ACP address (e.g., 2547 global scope address(es)) and TCP for connections from/to link-local 2548 addresses on the ACP virtual interfaces. The latter ones are only 2549 used for flooding of GRASP messages. 2551 ..............................ACP.............................. 2552 . . 2553 . /-GRASP-flooding-\ ACP GRASP instance . 2554 . / \ A 2555 . GRASP GRASP GRASP C 2556 . link-local unicast link-local P 2557 . multicast messages multicast . 2558 . messages | messages . 2559 . | | | . 2560 ............................................................... 2561 . v v v ACP security and transport . 2562 . | | | substrate for GRASP . 2563 . | | | . 2564 . | ACP GRASP | - ACP GRASP A 2565 . | Loopback | Loopback interface C 2566 . | interface | - ACP-cert auth P 2567 . | TLS | . 2568 . ACP GRASP | ACP GRASP - ACP GRASP virtual . 2569 . subnet1 | subnet2 virtual interfaces . 2570 . TCP | TCP . 2571 . | | | . 2572 ............................................................... 2573 . | | | ^^^ Users of ACP (GRASP/ASA) . 2574 . | | | ACP interfaces/addressing . 2575 . | | | . 2576 . | | | A 2577 . | ACP-Loopback Interf.| <- ACP Loopback interface C 2578 . | ACP-address | - address (global ULA) P 2579 . subnet1 | subnet2 <- ACP virtual interfaces . 2580 . link-local | link-local - link-local addresses . 2581 ............................................................... 2582 . | | | ACP VRF . 2583 . | RPL-routing | virtual routing and forwarding . 2584 . | /IP-Forwarding\ | A 2585 . | / \ | C 2586 . ACP IPv6 packets ACP IPv6 packets P 2587 . |/ \| . 2588 . IPsec/DTLS IPsec/DTLS - ACP-cert auth . 2589 ............................................................... 2590 | | Data-Plane 2591 | | 2592 | | - ACP secure channel 2593 link-local link-local - encapsulation addresses 2594 subnet1 subnet2 - Data-Plane interfaces 2595 | | 2596 ACP-Nbr1 ACP-Nbr2 2598 Figure 8: ACP as security and transport substrate for GRASP 2600 6.8.2.1. Discussion 2602 TCP encapsulation for GRASP M_DISCOVERY and M_FLOOD link local 2603 messages is used because these messages are flooded across 2604 potentially many hops to all ACP nodes and a single link with even 2605 temporary packet loss issues (e.g., WiFi/Powerline link) can reduce 2606 the probability for loss free transmission so much that applications 2607 would want to increase the frequency with which they send these 2608 messages. Such shorter periodic retransmission of datagrams would 2609 result in more traffic and processing overhead in the ACP than the 2610 hop-by-hop reliable retransmission mechanism by TCP and duplicate 2611 elimination by GRASP. 2613 TLS is mandated for GRASP non-link-local unicast because the ACP 2614 secure channel mandatory authentication and encryption protects only 2615 against attacks from the outside but not against attacks from the 2616 inside: Compromised ACP members that have (not yet) been detected and 2617 removed (e.g., via domain certificate revocation / expiry). 2619 If GRASP peer connections were to use just TCP, compromised ACP 2620 members could simply eavesdrop passively on GRASP peer connections 2621 for whom they are on-path ("Man In The Middle" - MITM) or intercept 2622 and modify them. With TLS, it is not possible to completely 2623 eliminate problems with compromised ACP members, but attacks are a 2624 lot more complex: 2626 Eavesdropping/spoofing by a compromised ACP node is still possible 2627 because in the model of the ACP and GRASP, the provider and consumer 2628 of an objective have initially no unique information (such as an 2629 identity) about the other side which would allow them to distinguish 2630 a benevolent from a compromised peer. The compromised ACP node would 2631 simply announce the objective as well, potentially filter the 2632 original objective in GRASP when it is a MITM and act as an 2633 application level proxy. This of course requires that the 2634 compromised ACP node understand the semantics of the GRASP 2635 negotiation to an extent that allows it to proxy it without being 2636 detected, but in an ACP environment this is quite likely public 2637 knowledge or even standardized. 2639 The GRASP TLS connections are run the same as any other ACP traffic 2640 through the ACP secure channels. This leads to double 2641 authentication/encryption, which has the following benefits: 2643 o Secure channel methods such as IPsec may provide protection 2644 against additional attacks, for example reset-attacks. 2646 o The secure channel method may leverage hardware acceleration and 2647 there may be little or no gain in eliminating it. 2649 o There is no different security model for ACP GRASP from other ACP 2650 traffic. Instead, there is just another layer of protection 2651 against certain attacks from the inside which is important due to 2652 the role of GRASP in the ACP. 2654 6.9. Context Separation 2656 The ACP is in a separate context from the normal Data-Plane of the 2657 node. This context includes the ACP channels' IPv6 forwarding and 2658 routing as well as any required higher layer ACP functions. 2660 In classical network system, a dedicated VRF is one logical 2661 implementation option for the ACP. If possible by the systems 2662 software architecture, separation options that minimize shared 2663 components are preferred, such as a logical container or virtual 2664 machine instance. The context for the ACP needs to be established 2665 automatically during bootstrap of a node. As much as possible it 2666 should be protected from being modified unintentionally by ("Data- 2667 Plane") configuration. 2669 Context separation improves security, because the ACP is not 2670 reachable from the Data-Plane routing or forwarding table(s). Also, 2671 configuration errors from the Data-Plane setup do not affect the ACP. 2673 6.10. Addressing inside the ACP 2675 The channels explained above typically only establish communication 2676 between two adjacent nodes. In order for communication to happen 2677 across multiple hops, the autonomic control plane requires ACP 2678 network wide valid addresses and routing. Each ACP node creates a 2679 Loopback interface with an ACP network wide unique address inside the 2680 ACP context (as explained in in Section 6.9). This address may be 2681 used also in other virtual contexts. 2683 With the algorithm introduced here, all ACP nodes in the same routing 2684 subdomain have the same /48 ULA prefix. Conversely, ULA global IDs 2685 from different domains are unlikely to clash, such that two ACP 2686 networks can be merged, as long as the policy allows that merge. See 2687 also Section 9.1 for a discussion on merging domains. 2689 Links inside the ACP only use link-local IPv6 addressing, such that 2690 each node's ACP only requires one routable virtual address. 2692 6.10.1. Fundamental Concepts of Autonomic Addressing 2694 o Usage: Autonomic addresses are exclusively used for self- 2695 management functions inside a trusted domain. They are not used 2696 for user traffic. Communications with entities outside the 2697 trusted domain use another address space, for example normally 2698 managed routable address space (called "Data-Plane" in this 2699 document). 2701 o Separation: Autonomic address space is used separately from user 2702 address space and other address realms. This supports the 2703 robustness requirement. 2705 o Loopback-only: Only ACP Loopback interfaces (and potentially those 2706 configured for "ACP connect", see Section 8.1) carry routable 2707 address(es); all other interfaces (called ACP virtual interfaces) 2708 only use IPv6 link local addresses. The usage of IPv6 link local 2709 addressing is discussed in [RFC7404]. 2711 o Use-ULA: For Loopback interfaces of ACP nodes, we use ULA with L=1 2712 (as defined in section 3.1 of [RFC4193]). Note that the random 2713 hash for ACP Loopback addresses uses the definition in 2714 Section 6.10.2 and not the one of [RFC4193] section 3.2.2. 2716 o No external connectivity: They do not provide access to the 2717 Internet. If a node requires further reaching connectivity, it 2718 should use another, traditionally managed address scheme in 2719 parallel. 2721 o Addresses in the ACP are permanent, and do not support temporary 2722 addresses as defined in [RFC4941]. 2724 o Addresses in the ACP are not considered sensitive on privacy 2725 grounds because ACP nodes are not expected to be end-user host. 2726 All ACP nodes are in one (potentially federated) administrative 2727 domain. They are assumed to be to be candidate hosts of ACP 2728 traffic amongst each other or transit thereof. There are no 2729 transit nodes less privileged to know about the identity of other 2730 hosts in the ACP. Therefore, ACP addresses do not need to be 2731 pseudo-random as discussed in [RFC7721]. Because they are not 2732 propagated to untrusted (non ACP) nodes and stay within a domain 2733 (of trust), we also consider them not to be subject to scanning 2734 attacks. 2736 The ACP is based exclusively on IPv6 addressing, for a variety of 2737 reasons: 2739 o Simplicity, reliability and scale: If other network layer 2740 protocols were supported, each would have to have its own set of 2741 security associations, routing table and process, etc. 2743 o Autonomic functions do not require IPv4: Autonomic functions and 2744 autonomic service agents are new concepts. They can be 2745 exclusively built on IPv6 from day one. There is no need for 2746 backward compatibility. 2748 o OAM protocols do not require IPv4: The ACP may carry OAM 2749 protocols. All relevant protocols (SNMP, TFTP, SSH, SCP, Radius, 2750 Diameter, ...) are available in IPv6. See also [RFC8368] for how 2751 ACP could be made to interoperate with IPv4 only OAM. 2753 6.10.2. The ACP Addressing Base Scheme 2755 The Base ULA addressing scheme for ACP nodes has the following 2756 format: 2758 8 40 2 78 2759 +--+-------------------------+------+------------------------------+ 2760 |fd| hash(routing-subdomain) | Type | (sub-scheme) | 2761 +--+-------------------------+------+------------------------------+ 2763 Figure 9: ACP Addressing Base Scheme 2765 The first 48-bits follow the ULA scheme, as defined in [RFC4193], to 2766 which a type field is added: 2768 o "fd" identifies a locally defined ULA address. 2770 o The 40-bits ULA "global ID" (term from [RFC4193]) for ACP 2771 addresses carried in the domain information field of domain 2772 certificates are the first 40-bits of the SHA256 hash of the 2773 routing subdomain from the same domain information field. In the 2774 example of Section 6.1.2, the routing subdomain is 2775 "area51.research.acp.example.com" and the 40-bits ULA "global ID" 2776 89b714f3db. 2778 o When creating a new routing-subdomain for an existing autonomic 2779 network, it MUST be ensured, that rsub is selected so the 2780 resulting hash of the routing-subdomain does not collide with the 2781 hash of any pre-existing routing-subdomains of the autonomic 2782 network. This ensures that ACP addresses created by registrars 2783 for different routing subdomains do not collide with each others. 2785 o To allow for extensibility, the fact that the ULA "global ID" is a 2786 hash of the routing subdomain SHOULD NOT be assumed by any ACP 2787 node during normal operations. The hash function is only executed 2788 during the creation of the certificate. If BRSKI is used then the 2789 BRSKI registrar will create the domain information field in 2790 response to the EST Certificate Signing Request (CSR) Attribute 2791 Request message by the pledge. 2793 o Establishing connectivity between different ACP (different acp- 2794 domain-name) is outside the scope of this specification. If it is 2795 being done through future extensions, then the rsub of all 2796 routing-subdomains across those autonomic networks need to be 2797 selected so the resulting routing-subdomain hashes do not collide. 2798 For example a large cooperation with its own private Trust Anchor 2799 may want to create different autonomic networks that initially 2800 should not be able to connect but where the option to do so should 2801 be kept open. When taking this future possibility into account, 2802 it is easy to always select rsub so that no collisions happen. 2804 o Type: This field allows different address sub-schemes. This 2805 addresses the "upgradability" requirement. Assignment of types 2806 for this field will be maintained by IANA. 2808 The sub-scheme may imply a range or set of addresses assigned to the 2809 node, this is called the ACP address range/set and explained in each 2810 sub-scheme. 2812 Please refer to Section 6.10.7 and Appendix A.1 for further 2813 explanations why the following Sub-Addressing schemes are used and 2814 why multiple are necessary. 2816 The following summarizes the addressing Sub-Schemes: 2818 +------+-----+----------------+-------+------------+ 2819 | Type | Z | name | F-bit | V-bit size | 2820 +------+-----+----------------+-------+------------+ 2821 | 0x00 | 0 | ACP Zone | N/A | 1 bit | 2822 +------+-----+----------------+-------+------------+ 2823 | 0x00 | 1 | ACP Manual | N/A | 1 bit | 2824 +------+-----+----------------+-------+------------+ 2825 | 0x01 | N/A | VLong-ASA | 0 | 8-bits | 2826 +------+-----+----------------+-------+------------+ 2827 | 0x01 | N/A | VLong-ACP-edge | 1 | 16-bits | 2828 +------+-----+----------------+-------+------------+ 2830 Figure 10: Addressing schemes 2832 6.10.3. ACP Zone Addressing Sub-Scheme 2834 This sub-scheme is used when the Type field of the base scheme is 2835 0x00 and the Z bit is 0x0. 2837 64 64 2838 +-----------------+---+---------++-----------------------------+---+ 2839 | (base scheme) | Z | Zone-ID || Node-ID | 2840 | | | || Registrar-ID | Node-Number| V | 2841 +-----------------+---+---------++--------------+--------------+---+ 2842 50 1 13 48 15 1 2844 Figure 11: ACP Zone Addressing Sub-Scheme 2846 The fields are defined as follows: 2848 o Type: MUST be 0x0. 2850 o Z: MUST be 0x0. 2852 o Zone-ID: If set to all zero bits: The Node-ID bits are used as an 2853 identifier (as opposed to a locator). This results in a non- 2854 hierarchical, flat addressing scheme. Any other value indicates a 2855 zone. See Section 6.10.3.1 on how this field is used in detail. 2857 o Node-ID: A unique value for each node. 2859 The 64-bit Node-ID is derived and composed as follows: 2861 o Registrar-ID (48-bit): A number unique inside the domain that 2862 identifies the ACP registrar which assigned the Node-ID to the 2863 node. One or more domain-wide unique identifiers of the ACP 2864 registrar can be used for this purpose. See Section 6.10.7.2. 2866 o Node-Number: A number which is unique for a given ACP registrar, 2867 to identify the node. This can be a sequentially assigned number. 2869 o V (1-bit): Virtualization bit: 0: Indicates the ACP itself ("ACP 2870 node base system); 1: Indicates the optional "host" context on the 2871 ACP node (see below). 2873 In the ACP Zone Addressing Sub-Scheme, the ACP address in the 2874 certificate has Zone-ID and V fields as all zero bits. The ACP 2875 address set includes addresses with any Zone-ID value and any V 2876 value. 2878 The "Node-ID" itself is unique in a domain (i.e., the Zone-ID is not 2879 required for uniqueness). Therefore, a node can be addressed either 2880 as part of a flat hierarchy (Zone-ID = 0), or with an aggregation 2881 scheme (any other Zone-ID). An address with Zone-ID = 0 is an 2882 identifier, with a Zone-ID !=0 it is a locator. See Section 6.10.3.1 2883 for more details. 2885 The Virtual bit in this sub-scheme allows the easy addition of the 2886 ACP as a component to existing systems without causing problems in 2887 the port number space between the services in the ACP and the 2888 existing system. V:0 is the ACP router (autonomic node base system), 2889 V:1 is the host with pre-existing transport endpoints on it that 2890 could collide with the transport endpoints used by the ACP router. 2891 The ACP host could for example have a p2p virtual interface with the 2892 V:0 address as its router into the ACP. Depending on the software 2893 design of ASAs, which is outside the scope of this specification, 2894 they may use the V:0 or V:1 address. 2896 The location of the V bit(s) at the end of the address allows the 2897 announcement of a single prefix for each ACP node. For example, in a 2898 network with 20,000 ACP nodes, this avoid 20,000 additional routes in 2899 the routing table. 2901 6.10.3.1. Usage of the Zone-ID Field 2903 The Zone-ID allows for the introduction of route prefixes in the 2904 addressing scheme. 2906 Zone-ID = 0 is the default addressing scheme in an ACP domain. Every 2907 ACP node with a Zone Addressing Sub-Scheme address MUST respond to 2908 its ACP address with Zone-ID = 0. Used on its own this leads to a 2909 non-hierarchical address scheme, which is suitable for networks up to 2910 a certain size. Zone-ID = 0 addresses act as identifiers for the 2911 nodes, and aggregation of these address in the ACP routing table is 2912 not possible. 2914 If aggregation is required, the 13-bit Zone-ID value allows for up to 2915 8191 zones. The allocation of Zone-ID's may either happen 2916 automatically through a to-be-defined algorithm; or it could be 2917 configured and maintained explicitly. 2919 If a node learns (see Appendix A.10.1) that it is part of a zone, it 2920 MUST also respond to its ACP address with that Zone-ID. In this case 2921 the ACP Loopback is configured with two ACP addresses: One for Zone- 2922 ID = 0 and one for the assigned Zone-ID. This method allows for a 2923 smooth transition between a flat addressing scheme and a hierarchical 2924 one. 2926 A node knowing it is in a zone MUST use that Zone-ID != 0 address in 2927 GRASP locator fields. This eliminates the use of the identifier 2928 address (Zone-ID = 0) in forwarding and the need for network wide 2929 reachability of those non-aggregable identifier addresses. Zone-ID 2930 != 0 addresses are assumed to be aggregable in routing/forwarding 2931 based on how they are allocated in the ACP topology. 2933 Note: The Zone-ID is one method to introduce structure or hierarchy 2934 into the ACP. Another way is the use of the routing subdomain field 2935 in the ACP that leads to multiple /48 Global IDs within an ACP 2936 domain. 2938 Note: Zones and Zone-ID as defined here are not related to [RFC4007] 2939 zones or zone_id. ACP zone addresses are not scoped (reachable only 2940 from within an RFC4007 zone) but reachable across the whole ACP. An 2941 RFC4007 zone_id is a zone index that has only local significance on a 2942 node, whereas an ACP Zone-ID is an identifier for an ACP zone that is 2943 unique across that ACP. 2945 6.10.4. ACP Manual Addressing Sub-Scheme 2947 This sub-scheme is used when the Type field of the base scheme is 2948 0x00 and the Z bit is 0x1. 2950 64 64 2951 +---------------------+---+----------++-----------------------------+ 2952 | (base scheme) | Z | Subnet-ID|| Interface Identifier | 2953 +---------------------+---+----------++-----------------------------+ 2954 50 1 13 2956 Figure 12: ACP Manual Addressing Sub-Scheme 2958 The fields are defined as follows: 2960 o Type: MUST be 0x0. 2962 o Z: MUST be 0x1. 2964 o Subnet-ID: Configured subnet identifier. 2966 o Interface Identifier. 2968 This sub-scheme is meant for "manual" allocation to subnets where the 2969 other addressing schemes cannot be used. The primary use case is for 2970 assignment to ACP connect subnets (see Section 8.1.1). 2972 "Manual" means that allocations of the Subnet-ID need to be done 2973 today with pre-existing, non-autonomic mechanisms. Every subnet that 2974 uses this addressing sub-scheme needs to use a unique Subnet-ID 2975 (unless some anycast setup is done). 2977 The Z bit field was added to distinguish Zone addressing and manual 2978 addressing sub-schemes without requiring one more bit in the base 2979 scheme and therefore allowing for the Vlong scheme (described below) 2980 to have one more bit available. 2982 Manual addressing sub-scheme addresses SHOULD NOT be used in ACP 2983 domain certificates. Any node capable to build ACP secure channels 2984 and permitted by Registrar policy to participate in building ACP 2985 secure channels SHOULD receive an ACP address (prefix) from one of 2986 the other ACP addressing sub-schemes. Nodes not capable (or 2987 permitted) to participate in ACP secure channels can connect to the 2988 ACP via ACP connect interfaces of ACP edge nodes (see Section 8.1), 2989 without setting up an ACP secure channel. Their ACP domain 2990 certificate MUST include an empty acp-address to indicate that their 2991 ACP domain certificate is only usable for non- ACP secure channel 2992 authentication, such as end-to-end transport connections across the 2993 ACP or Data-Plane. 2995 Address management of ACP connect subnets is done using traditional 2996 assignment methods and existing IPv6 protocols. See Section 8.1.3 2997 for details. 2999 6.10.5. ACP Vlong Addressing Sub-Scheme 3001 This sub-scheme is used when the Type field of the base scheme is 3002 0x01. 3004 50 78 3005 +---------------------++-----------------------------+----------+ 3006 | (base scheme) || Node-ID | 3007 | || Registrar-ID |F| Node-Number| V | 3008 +---------------------++--------------+--------------+----------+ 3009 50 46 1 23/15 8/16 3011 Figure 13: ACP Vlong Addressing Sub-Scheme 3013 This addressing scheme foregoes the Zone-ID field to allow for 3014 larger, flatter routed networks (e.g., as in IoT) with 8421376 Node- 3015 Numbers (2^23+2^15). It also allows for up to 2^16 (i.e. 65536) 3016 different virtualized addresses within a node, which could be used to 3017 address individual software components in an ACP node. 3019 The fields are the same as in the Zone-ID sub-scheme with the 3020 following refinements: 3022 o F: format bit. This bit determines the format of the subsequent 3023 bits. 3025 o V: Virtualization bit: this is a field that is either 8 or 16 3026 bits. For F=0, it is 8 bits, for F=1 it is 16 bits. The V bits 3027 are assigned by the ACP node. In the ACP certificate's ACP 3028 address Section 6.1.2, the V-bits are always set to 0. 3030 o Registrar-ID: To maximize Node-Number and V, the Registrar-ID is 3031 reduced to 46-bits. One or more domain-wide unique identifiers of 3032 the ACP registrar can be used for this purpose. See 3033 Section 6.10.7.2. 3035 o The Node-Number is unique to each ACP node. There are two formats 3036 for the Node-Number. When F=0, the node-number is 23 bits, for 3037 F=1 it is 15 bits. Each format of node-number is considered to be 3038 in a unique number space. 3040 The F=0 bit format addresses are intended to be used for "general 3041 purpose" ACP nodes that would potentially have a limited number (< 3042 256) of clients (ASA/Autonomic Functions or legacy services) of the 3043 ACP that require separate V(irtual) addresses. 3045 The F=1 bit Node-Numbers are intended for ACP nodes that are ACP edge 3046 nodes (see Section 8.1.1) or that have a large number of clients 3047 requiring separate V(irtual) addresses. For example large SDN 3048 controllers with container modular software architecture (see 3049 Section 8.1.2). 3051 In the Vlong addressing sub-scheme, the ACP address in the 3052 certificate has all V field bits as zero. The ACP address set for 3053 the node includes any V value. 3055 6.10.6. Other ACP Addressing Sub-Schemes 3057 Before further addressing sub-schemes are defined, experience with 3058 the schemes defined here should be collected. The schemes defined in 3059 this document have been devised to allow hopefully sufficiently 3060 flexible setup of ACPs for a variety of situation. These reasons 3061 also lead to the fairly liberal use of address space: The Zone 3062 Addressing Sub-Scheme is intended to enable optimized routing in 3063 large networks by reserving bits for Zone-ID's. The Vlong addressing 3064 sub-scheme enables the allocation of 8/16-bit of addresses inside 3065 individual ACP nodes. Both address spaces allow distributed, 3066 uncoordinated allocation of node addresses by reserving bits for the 3067 registrar-ID field in the address. 3069 IANA is asked need to assign a new "type" for each new addressing 3070 sub-scheme. With the current allocations, only 2 more schemes are 3071 possible, so the last addressing scheme MUST provide further 3072 extensions (e.g., by reserving bits from it for further extensions). 3074 6.10.7. ACP Registrars 3076 ACP registrars are responsible to enroll candidate ACP nodes with ACP 3077 domain certificates and associated trust point(s). They are also 3078 responsible that an ACP domain information field is included in the 3079 ACP domain certificate carrying the ACP domain name and the ACP nodes 3080 ACP address prefix. This address prefix is intended to persist 3081 unchanged through the lifetime of the ACP node. 3083 Because of the ACP addressing sub-schemes, an ACP domain can have 3084 multiple distributed ACP registrars that do not need to coordinate 3085 for address assignment. ACP registrars can also be sub-CAs, in which 3086 case they can also assign ACP domain certificates without 3087 dependencies against a (shared) root-CA (except during renewals of 3088 their own certificates). 3090 ACP registrars are PKI registration authorities (RA) enhanced with 3091 the handling of the ACP domain certificate specific fields. They 3092 request certificates for ACP nodes from a Certificate Authority 3093 through any appropriate mechanism (out of scope in this document, but 3094 required to be BRSKI for ANI registrars). Only nodes that are 3095 trusted to be compliant with the requirements against registrar 3096 described in this section can be given the necessary credentials to 3097 perform this RA function, such as credentials for the BRSKI 3098 connection to the CA for ANI registrars. 3100 6.10.7.1. Use of BRSKI or other Mechanism/Protocols 3102 Any protocols or mechanisms may be used as ACP registrars, as long as 3103 the resulting ACP certificate and trust anchors allow to perform the 3104 ACP domain membership described in Section 6.1.3 with other ACP 3105 domain members, and meet the ACP addressing requirements for its ACP 3106 domain information field as described further below in this section. 3108 An ACP registrar could be a person deciding whether to enroll a 3109 candidate ACP node and then orchestrating the enrollment of the ACP 3110 certificate and associated trust anchor, using command line or web 3111 based commands on the candidate ACP node and trust anchor to generate 3112 and sign the ACP domain certificate and configure certificate and 3113 trust anchors onto the node. 3115 The only currently defined protocol for ACP registrars is BRSKI 3116 ([I-D.ietf-anima-bootstrapping-keyinfra]). When BRSKI is used, the 3117 ACP nodes are called ANI nodes, and the ACP registrars are called 3118 BRSKI or ANI registrars. The BRSKI specification does not define the 3119 handling of the ACP domain information field because the rules do not 3120 depend on BRSKI but apply equally to any protocols/mechanisms an ACP 3121 registrar may use. 3123 6.10.7.2. Unique Address/Prefix allocation 3125 ACP registrars MUST NOT allocate ACP address prefixes to ACP nodes 3126 via the ACP domain information field that would collide with the ACP 3127 address prefixes of other ACP nodes in the same ACP domain. This 3128 includes both prefixes allocated by the same ACP registrar to 3129 different ACP nodes as well as prefixes allocated by other ACP 3130 registrars for the same ACP domain. 3132 To support such unique address allocation, an ACP registrar MUST have 3133 one or more 46-bit identifiers unique across the ACP domain which is 3134 called the Registrar-ID. Allocation of Registrar-ID(s) to an ACP 3135 registrar can happen through OAM mechanisms in conjunction with some 3136 database / allocation orchestration. 3138 ACP registrars running on physical devices with known globally unique 3139 EUI-48 MAC address(es) can use the lower 46 bits of those address(es) 3140 as unique Registrar-IDs without requiring any external signaling/ 3141 configuration (the upper two bits, V and U are not uniquely assigned 3142 but functional). This approach is attractive for distributed, non- 3143 centrally administered, lightweight ACP registrar implementations. 3144 There is no mechanism to deduce from a MAC address itself whether it 3145 is actually uniquely assigned. Implementations need to consult 3146 additional offline information before making this assumption. For 3147 example by knowing that a particular physical product/MIC-chip is 3148 guaranteed to use globally unique assigned EUI-48 MAC address(es). 3150 When the candidate ACP device (called Pledge in BRSKI) is to be 3151 enrolled into an ACP domain, the ACP registrar needs to allocate a 3152 unique ACP address to the node and ensure that the ACP certificate 3153 gets a domain information field (Section 6.1.2) with the appropriate 3154 information - ACP domain-name, ACP-address, and so on. If the ACP 3155 registrar uses BRSKI, it signals the ACP domain information field to 3156 the Pledge via the EST /csrattrs command (see 3157 [I-D.ietf-anima-bootstrapping-keyinfra], section 5.9.2 - "EST CSR 3158 Attributes"). 3160 [RFC Editor: please update reference to section 5.9.2 accordingly 3161 with latest BRSKI draft at time of publishing, or RFC] 3163 6.10.7.3. Addressing Sub-Scheme Policies 3165 The ACP registrar selects for the candidate ACP node a unique address 3166 prefix from an appropriate ACP addressing sub-scheme, either a zone 3167 addressing sub-scheme prefix (see Section 6.10.3), or a Vlong 3168 addressing sub-scheme prefix (see Section 6.10.5). The assigned ACP 3169 address prefix encoded in the domain information field of the ACP 3170 domain certificate indicates to the ACP node its ACP address 3171 information. The sub-addressing scheme indicates the prefix length: 3172 /127 for zone address sub-scheme, /120 or /112 for Vlong address sub- 3173 scheme. The first address of the prefix is the ACP address. All 3174 other addresses in the prefix are for other uses by the ACP node as 3175 described in the zone and Vlong addressing sub scheme sections. The 3176 ACP address prefix itself is then signaled by the ACP node into the 3177 ACP routing protocol (see Section 6.11) to establish IPv6 3178 reachability across the ACP. 3180 The choice of addressing sub-scheme and prefix-length in the Vlong 3181 address sub-scheme is subject to ACP registrar policy. It could be 3182 an ACP domain wide policy, or a per ACP node or per ACP node type 3183 policy. For example, in BRSKI, the ACP registrar is aware of the 3184 IDevID of the candidate ACP node, which contains a "serialNnumber" 3185 that is typically indicating the node's vendor and device type and 3186 can be used to drive a policy selecting an appropriate addressing 3187 sub-scheme for the (class of) node(s). 3189 ACP registrars SHOULD default to allocate ACP zone sub-address scheme 3190 addresses with Zone-ID 0. Allocation and use of zone sub-addresses 3191 with Zone-ID != 0 is outside the scope of this specification because 3192 it would need to go along with rules for extending ACP routing to 3193 multiple zones, which is outside the scope of this specification. 3195 ACP registrars that are aware of can use the IDevID of a candidate 3196 ACP device SHOULD be able to choose the zone vs. Vlong sub-address 3197 scheme for ACP nodes based on the "serialNumber" of the IDevID, for 3198 example by the PID (Product Identifier) part which identifies the 3199 product type, or the complete "serialNumber". 3201 In a simple allocation scheme, an ACP registrar remembers 3202 persistently across reboots its currently used Registrar-ID and for 3203 each addressing scheme (zone with Zone-ID 0, Vlong with /112, Vlong 3204 with /120), the next Node-Number available for allocation and 3205 increases it during successful enrollment to an ACP node. In this 3206 simple allocation scheme, the ACP registrar would not recycle ACP 3207 address prefixes from no longer used ACP nodes. 3209 6.10.7.4. Address/Prefix Persistence 3211 When an ACP domain certificate is renewed or rekeyed via EST or other 3212 mechanisms, the ACP address/prefix in the ACP domain information 3213 field MUST be maintained unless security issues or violations of the 3214 unique address assignment requirements exist or are suspected by the 3215 ACP registrar. 3217 ACP address information SHOULD be maintained even when the renewing/ 3218 rekeying ACP registrar is not the same as the one that enrolled the 3219 prior ACP certificate. See Section 10.2.4 for an example. 3221 ACP address information SHOULD also be maintained even after an ACP 3222 certificate did expire or failed. See Section 6.1.5.5 and 3223 Section 6.1.5.6. 3225 6.10.7.5. Further Details 3227 Section 10.2 discusses further informative details of ACP registrars: 3228 What interactions registrars need, what parameters they require, 3229 certificate renewal and limitations, use of sub-CAs on registrars and 3230 centralized policy control. 3232 6.11. Routing in the ACP 3234 Once ULA address are set up all autonomic entities should run a 3235 routing protocol within the autonomic control plane context. This 3236 routing protocol distributes the ULA created in the previous section 3237 for reachability. The use of the autonomic control plane specific 3238 context eliminates the probable clash with Data-Plane routing tables 3239 and also secures the ACP from interference from the configuration 3240 mismatch or incorrect routing updates. 3242 The establishment of the routing plane and its parameters are 3243 automatic and strictly within the confines of the autonomic control 3244 plane. Therefore, no explicit configuration is required. 3246 All routing updates are automatically secured in transit as the 3247 channels of the ACP are encrypted, and this routing runs only inside 3248 the ACP. 3250 The routing protocol inside the ACP is RPL ([RFC6550]). See 3251 Appendix A.4 for more details on the choice of RPL. 3253 RPL adjacencies are set up across all ACP channels in the same domain 3254 including all its routing subdomains. See Appendix A.7 for more 3255 details. 3257 6.11.1. RPL Profile 3259 The following is a description of the RPL profile that ACP nodes need 3260 to support by default. The format of this section is derived from 3261 draft-ietf-roll-applicability-template. 3263 6.11.1.1. Overview 3265 The choosen RPL profile is one that expects a fairly reliable network 3266 with reasonably fast links so that RPL convergence will be triggered 3267 immediately upon recognition of link failure/recovery. 3269 The profile is also designed to not require any RPL Data-Plane 3270 artifacts (such as defined in [RFC6553]). This is largely driven by 3271 the desire to avoid introducing the required Hop-by-Hop headers into 3272 the ACP forwarding plane, especially to support devices with silicon 3273 forwarding planes that cannot support insertion/removal of these 3274 headers in silicon or hop-by-hop forwarding based on them. Note: 3275 Insertion/removal of headers by a (potentially silicon based) ACP 3276 node would be be necessary when senders/receivers of ACP packets are 3277 legacy NOC devices connected via ACP connect (see Section 8.1.1 to 3278 the ACP. Their connectivity can be handled in RPL as non-RPL-aware 3279 leafs (or "Internet") according to the Data-Plane architecture 3280 explained in [I-D.ietf-roll-useofrplinfo]. 3282 This RPL profile avoids the use of Data-Plane artefacts (RPL data 3283 packet headers, see Section 6.11.1.13), because hardware accelerated 3284 forwarding planes most likely can not support them today. To achieve 3285 this, the profile uses a simple destination prefix based routing/ 3286 forwarding table. To achieve this, the profiles uses only one RPL 3287 instanceID. This single instanceID can contain only one Destination 3288 Oriented Directed Acyclic Graph (DODAG), and the routing/forwarding 3289 table can therefore only calculate a single class of service ("best 3290 effort towards the primary NOC/root") and cannot create optimized 3291 routing paths to accomplish latency or energy goals between any two 3292 nodes. 3294 Consider a network that has multiple NOCs in different locations. 3295 Only one NOC will become the DODAG root. Traffic to and from other 3296 NOCs has to be sent through the DODAG (shortest path tree) rooted in 3297 the primary NOC. Depending on topology, this can be an annoyance 3298 from a latency point of view or from minimizing network path 3299 resources, but this is deemed to be acceptable given how ACP traffic 3300 is "only" network management/control traffic. 3302 Using a single instanceID/DODAG does not introduce a single point of 3303 failure, as the DODAG will reconfigure itself when it detects data- 3304 plane forwarding failures including choosing a different root when 3305 the primary one fails. See Appendix A.10.4 for more details. 3307 The benefit of this profile, especially compared to other IGPs is 3308 that it does not calculate routes for node reachable through the same 3309 interface as the DODAG root. This RPL profile can therefore scale to 3310 much larger number of ACP nodes in the same amount of compute and 3311 memory than other routing protocols. Especially on nodes that are 3312 leafs of the topology or those close to those leafs. 3314 The lack of RPL Packet Information (see Section 6.11.1.13), means 3315 that the Data-Plane will have no rank value that can be used to 3316 detect loops. As a result, traffic may loop until the time-to-live 3317 (TTL) of the packet reaches zero. This is the same behavior as that 3318 of other IGPs that do not have the Data-Plane options of RPL. 3320 Since links in the ACP are assumed to be mostly reliable (or have 3321 link layer protection against loss) and because there is no stretch 3322 according to Section 6.11.1.7, loops caused by RPL routing packet 3323 loss should be exceedingly rare. 3325 There are a variety of mechanisms possible in RPL to further avoid 3326 temporary loops: DODAG Information Objects (DIOs) SHOULD be sent 3327 2...3 times to inform children when losing the last parent. The 3328 technique in [RFC6550] section 8.2.2.6. (Detaching) SHOULD be 3329 favored over that in section 8.2.2.5., (Poisoning) because it allows 3330 local connectivity. Nodes SHOULD select more than one parent, at 3331 least 3 if possible, and send Destination Advertisement Objects 3332 (DAO)s to all of them in parallel. 3334 Additionally, failed ACP tunnels can be quickly discovered trough the 3335 secure channel protocol mechanisms such as IKEv2 Dead Peer Detection. 3336 This can function as a replacement for a Low-power and Lossy 3337 Networks' (LLN's) Expected Transmission Count (ETX) feature that is 3338 not used in this profile. A failure of an ACP tunnel should 3339 imediately signal the RPL control plane to pick a different parent. 3341 6.11.1.2. RPL Instances 3343 Single RPL instance. Default RPLInstanceID = 0. 3345 6.11.1.3. Storing vs. Non-Storing Mode 3347 RPL Mode of Operations (MOP): MUST support mode 2 - "Storing Mode of 3348 Operations with no multicast support". Implementations MAY support 3349 mode 3 ("... with multicast support" as that is a superset of mode 3350 2). Note: Root indicates mode in DIO flow. 3352 6.11.1.4. DAO Policy 3354 Proactive, aggressive DAO state maintenance: 3356 o Use K-flag in unsolicited DAO indicating change from previous 3357 information (to require DAO-ACK). 3359 o Retry such DAO DAO-RETRIES(3) times with DAO- ACK_TIME_OUT(256ms) 3360 in between. 3362 6.11.1.5. Path Metric 3364 Hopcount. 3366 6.11.1.6. Objective Function 3368 Objective Function (OF): Use OF0 [RFC6552]. No use of metric 3369 containers. 3371 rank_factor: Derived from link speed: <= 100Mbps: 3372 LOW_SPEED_FACTOR(5), else HIGH_SPEED_FACTOR(1) 3374 6.11.1.7. DODAG Repair 3376 Global Repair: we assume stable links and ranks (metrics), so no need 3377 to periodically rebuild DODAG. DODAG version only incremented under 3378 catastrophic events (e.g., administrative action). 3380 Local Repair: As soon as link breakage is detected, send No-Path DAO 3381 for all the targets that were reachable only via this link. As soon 3382 as link repair is detected, validate if this link provides you a 3383 better parent. If so, compute your new rank, and send new DIO that 3384 advertises your new rank. Then send a DAO with a new path sequence 3385 about yourself. 3387 stretch_rank: none provided ("not stretched"). 3389 Data Path Validation: Not used. 3391 Trickle: Not used. 3393 6.11.1.8. Multicast 3395 Not used yet but possible because of the selected mode of operations. 3397 6.11.1.9. Security 3399 [RFC6550] security not used, substituted by ACP security. 3401 Because the ACP links already include provisions for confidentiality 3402 and integrity protection, their usage at the RPL layer would be 3403 redundant, and so RPL security is not used. 3405 6.11.1.10. P2P communications 3407 Not used. 3409 6.11.1.11. IPv6 address configuration 3411 Every ACP node (RPL node) announces an IPv6 prefix covering the 3412 address(es) used in the ACP node. The prefix length depends on the 3413 chosen addressing sub-scheme of the ACP address provisioned into the 3414 certificate of the ACP node, e.g., /127 for Zone Addressing Sub- 3415 Scheme or /112 or /120 for Vlong addressing sub-scheme. See 3416 Section 6.10 for more details. 3418 Every ACP node MUST install a black hole (aka null) route for 3419 whatever ACP address space that it advertises (i.e.: the /96 or 3420 /127). This is avoid routing loops for addresses that an ACP node 3421 has not (yet) used. 3423 6.11.1.12. Administrative parameters 3425 Administrative Preference ([RFC6550], 3.2.6 - to become root): 3426 Indicated in DODAGPreference field of DIO message. 3428 o Explicit configured "root": 0b100 3430 o ACP registrar (Default): 0b011 3432 o ACP-connect (non-registrar): 0b010 3434 o Default: 0b001. 3436 6.11.1.13. RPL Data-Plane artifacts 3438 RPL Packet Information (RPI) defined in [RFC6550], section 11.2 3439 defines the data packet artefacts required or beneficial in 3440 forwarding of those data packets when their routing information is 3441 derived from RPL. This profile does not use RPI for better 3442 compatibility with accelerated hardeware forwarding planes and 3443 achieves this for the following reasons. 3445 One RPI option is the RPL Source Routing Header (SRH) [RFC6554] which 3446 is not necessary in this profile because it uses storing mode where 3447 each hop has the necessary next-hop forwarding information. 3449 The simpler RPL Option header [RFC6553] is also not necessary in this 3450 profile, because it uses a single RPL instance and data path 3451 validation is also not used. 3453 6.11.1.14. Unknown Destinations 3455 Because RPL minimizes the size of the routing and forwarding table, 3456 prefixes reachable through the same interface as the RPL root are not 3457 known on every ACP node. Therefore traffic to unknown destination 3458 addresses can only be discovered at the RPL root. The RPL root 3459 SHOULD have attach safe mechanisms to operationally discover and log 3460 such packets. 3462 As this requirement raises additional data plane requirements, it 3463 does not apply to nodes where the administrative parameter to become 3464 root (Section 6.11.1.12) can always only be 0b001, e.g.: the node 3465 does not support explicit configuration to be root, or to be ACP 3466 registrar or to have ACP-connect functionality. If an ACP network is 3467 degraded to the point where there are no nodes that could be 3468 configured roots, ACP registrars or ACP-connect nodes, traffic to 3469 unknown destinations could not be diagnosed, but in the absence of 3470 any intelligent nodes supporting other than 0b001 administrative 3471 preference, there is likely also no diagnostic function possible. 3473 6.12. General ACP Considerations 3475 Since channels are by default established between adjacent neighbors, 3476 the resulting overlay network does hop-by-hop encryption. Each node 3477 decrypts incoming traffic from the ACP, and encrypts outgoing traffic 3478 to its neighbors in the ACP. Routing is discussed in Section 6.11. 3480 6.12.1. Performance 3482 There are no performance requirements against ACP implementations 3483 defined in this document because the performance requirements depend 3484 on the intended use case. It is expected that full autonomic node 3485 with a wide range of ASA can require high forwarding plane 3486 performance in the ACP, for example for telemetry. Implementations 3487 of ACP to solely support traditional/SDN style use cases can benefit 3488 from ACP at lower performance, especially if the ACP is used only for 3489 critical operations, e.g., when the Data-Plane is not available. The 3490 design of the ACP as specified in this document is intended to 3491 support a wide range of performance options: It is intended to allow 3492 software-only implementations at potentially low performance, but can 3493 also support high performance options. See [RFC8368] for more 3494 details. 3496 6.12.2. Addressing of Secure Channels 3498 In order to be independent of the Data-Plane routing and addressing, 3499 the GRASP discovered ACP secure channels use IPv6 link local 3500 addresses between adjacent neighbors. Note: Section 8.2 specifies 3501 extensions in which secure channels are configured tunnels operating 3502 over the Data-Plane, so those secure channels cannot be independent 3503 of the Data-Plane. 3505 To avoid that Data-Plane configuration can impact the operations of 3506 the IPv6 (link-local) interface/address used for ACP channels, 3507 appropriate implementation considerations are required. If the IPv6 3508 interface/link-local address is shared with the Data-Plane it needs 3509 to be impossible to unconfigure/disable it through configuration. 3510 Instead of sharing the IPv6 interface/link-local address, a separate 3511 (virtual) interface with a separate IPv6 link-local address can be 3512 used. For example, the ACP interface could be run over a separate 3513 MAC address of an underlying L2 (Ethernet) interface. For more 3514 details and options, see Appendix A.10.2. 3516 Note that other (non-ideal) implementation choices may introduce 3517 additional undesired dependencies against the Data-Plane. For 3518 example shared code and configuration of the secure channel protocols 3519 (IPsec / DTLS). 3521 6.12.3. MTU 3523 The MTU for ACP secure channels MUST be derived locally from the 3524 underlying link MTU minus the secure channel encapsulation overhead. 3526 ACP secure Channel protocols do not need to perform MTU discovery 3527 because they are built across L2 adjacencies - the MTU on both sides 3528 connecting to the L2 connection are assumed to be consistent. 3529 Extensions to ACP where the ACP is for example tunneled need to 3530 consider how to guarantee MTU consistency. This is an issue of 3531 tunnels, not an issue of running the ACP across a tunnel. Transport 3532 stacks running across ACP can perform normal PMTUD (Path MTU 3533 Discovery). Because the ACP is meant to be prioritize reliability 3534 over performance, they MAY opt to only expect IPv6 minimum MTU (1280) 3535 to avoid running into PMTUD implementation bugs or underlying link 3536 MTU mismatch problems. 3538 6.12.4. Multiple links between nodes 3540 If two nodes are connected via several links, the ACP SHOULD be 3541 established across every link, but it is possible to establish the 3542 ACP only on a sub-set of links. Having an ACP channel on every link 3543 has a number of advantages, for example it allows for a faster 3544 failover in case of link failure, and it reflects the physical 3545 topology more closely. Using a subset of links (for example, a 3546 single link), reduces resource consumption on the node, because state 3547 needs to be kept per ACP channel. The negotiation scheme explained 3548 in Section 6.5 allows Alice (the node with the higher ACP address) to 3549 drop all but the desired ACP channels to Bob - and Bob will not re- 3550 try to build these secure channels from his side unless Alice shows 3551 up with a previously unknown GRASP announcement (e.g., on a different 3552 link or with a different address announced in GRASP). 3554 6.12.5. ACP interfaces 3556 The ACP VRF has conceptually two type of interfaces: The "ACP 3557 Loopback interface(s)" to which the ACP ULA address(es) are assigned 3558 and the "ACP virtual interfaces" that are mapped to the ACP secure 3559 channels. 3561 6.12.5.1. ACP loopback interfaces 3563 The term "Loopback interface" was introduced initially to refer to an 3564 internal interface on a node that would allow IP traffic between 3565 transport endpoints on the node in the absence or failure of any or 3566 all external interfaces, see [RFC4291] section 2.5.3. 3568 Even though Loopback interfaces were originally designed to hold only 3569 Loopback addresses not reachable from outside the node, these 3570 interfaces are also commonly used today to hold addresses reachable 3571 from the outside. They are meant to be reachable independent of any 3572 external interface being operational, and therefore to be more 3573 resilient. These addresses on Loopback interfaces can be thought of 3574 as "node addresses" instead of "interface addresses", and that is 3575 what ACP address(es) are. This construct makes it therefore possible 3576 to address ACP nodes with a well-defined set of addresses independent 3577 of the number of external interfaces. 3579 For these reason, the ACP ULA address(es) are assigned to Loopback 3580 interface(s). 3582 6.12.5.2. ACP virtual interfaces 3584 Any ACP secure channel to another ACP node is mapped to ACP virtual 3585 interfaces in one of the following ways. This is independent of the 3586 chosen secure channel protocol (IPsec, DTLS or other future protocol 3587 - standards or non-standards). 3589 Note that all the considerations described here are assuming point- 3590 to-point secure channel associations. Mapping multi-party secure 3591 channel associations such as [RFC6407] is out of scope (but would be 3592 easy to add). 3594 6.12.5.2.1. ACP point-to-point virtual interfaces 3596 In this option, each ACP secure channel is mapped into a separate 3597 point-to-point ACP virtual interface. If a physical subnet has more 3598 than two ACP capable nodes (in the same domain), this implementation 3599 approach will lead to a full mesh of ACP virtual interfaces between 3600 them. 3602 6.12.5.2.2. ACP multi-access virtual interfaces 3604 In a more advanced implementation approach, the ACP will construct a 3605 single multi-access ACP virtual interface for all ACP secure channels 3606 to ACP capable nodes reachable across the same underlying (physical) 3607 subnet. IPv6 link-local multicast packets sent into an ACP multi- 3608 access virtual interface are replicated to every ACP secure channel 3609 mapped into the ACP multicast-access virtual interface. IPv6 unicast 3610 packets sent into an ACP multi-access virtual interface are sent to 3611 the ACP secure channel that belongs to the ACP neighbor that is the 3612 next-hop in the ACP forwarding table entry used to reach the packets 3613 destination address. 3615 There is no requirement for all ACP nodes on the same multi-access 3616 subnet to use the same type of ACP virtual interface. This is purely 3617 a node local decision. 3619 ACP nodes MUST perform standard IPv6 operations across ACP virtual 3620 interfaces including SLAAC (Stateless Address Auto-Configuration) - 3621 [RFC4862]) to assign their IPv6 link local address on the ACP virtual 3622 interface and ND (Neighbor Discovery - [RFC4861]) to discover which 3623 IPv6 link-local neighbor address belongs to which ACP secure channel 3624 mapped to the ACP virtual interface. This is independent of whether 3625 the ACP virtual interface is point-to-point or multi-access. 3627 "Optimistic Duplicate Address Detection (DAD)" according to [RFC4429] 3628 is RECOMMENDED because the likelihood for duplicates between ACP 3629 nodes is highly improbable as long as the address can be formed from 3630 a globally unique local assigned identifier (e.g., EUI-48/EUI-64, see 3631 below). 3633 ACP nodes MAY reduce the amount of link-local IPv6 multicast packets 3634 from ND by learning the IPv6 link-local neighbor address to ACP 3635 secure channel mapping from other messages such as the source address 3636 of IPv6 link-local multicast RPL messages - and therefore forego the 3637 need to send Neighbor Solicitation messages. 3639 The ACP virtual interface IPv6 link local address can be derived from 3640 any appropriate local mechanism such as node local EUI-48 or EUI-64 3641 ("EUI" stands for "Extended Unique Identifier"). It MUST NOT depend 3642 on something that is attackable from the Data-Plane such as the IPv6 3643 link-local address of the underlying physical interface, which can be 3644 attacked by SLAAC, or parameters of the secure channel encapsulation 3645 header that may not be protected by the secure channel mechanism. 3647 The link-layer address of an ACP virtual interface is the address 3648 used for the underlying interface across which the secure tunnels are 3649 built, typically Ethernet addresses. Because unicast IPv6 packets 3650 sent to an ACP virtual interface are not sent to a link-layer 3651 destination address but rather an ACP secure channel, the link-layer 3652 address fields SHOULD be ignored on reception and instead the ACP 3653 secure channel from which the message was received should be 3654 remembered. 3656 Multi-access ACP virtual interfaces are preferable implementations 3657 when the underlying interface is a (broadcast) multi-access subnet 3658 because they do reflect the presence of the underlying multi-access 3659 subnet into the virtual interfaces of the ACP. This makes it for 3660 example simpler to build services with topology awareness inside the 3661 ACP VRF in the same way as they could have been built running 3662 natively on the multi-access interfaces. 3664 Consider also the impact of point-to-point vs. multi-access virtual 3665 interface on the efficiency of flooding via link local multicasted 3666 messages: 3668 Assume a LAN with three ACP neighbors, Alice, Bob and Carol. Alice's 3669 ACP GRASP wants to send a link-local GRASP multicast message to Bob 3670 and Carol. If Alice's ACP emulates the LAN as one point-to-point 3671 virtual interface to Bob and one to Carol, The sending applications 3672 itself will send two copies, if Alice's ACP emulates a LAN, GRASP 3673 will send one packet and the ACP will replicate it. The result is 3674 the same. The difference happens when Bob and Carol receive their 3675 packet. If they use ACP point-to-point virtual interfaces, their 3676 GRASP instance would forward the packet from Alice to each other as 3677 part of the GRASP flooding procedure. These packets are unnecessary 3678 and would be discarded by GRASP on receipt as duplicates (by use of 3679 the GRASP Session ID). If Bob and Carol's ACP would emulate a multi- 3680 access virtual interface, then this would not happen, because GRASPs 3681 flooding procedure does not replicate back packets to the interface 3682 that they were received from. 3684 Note that link-local GRASP multicast messages are not sent directly 3685 as IPv6 link-local multicast UDP messages into ACP virtual 3686 interfaces, but instead into ACP GRASP virtual interfaces, that are 3687 layered on top of ACP virtual interfaces to add TCP reliability to 3688 link-local multicast GRASP messages. Nevertheless, these ACP GRASP 3689 virtual interfaces perform the same replication of message and, 3690 therefore, result in the same impact on flooding. See Section 6.8.2 3691 for more details. 3693 RPL does support operations and correct routing table construction 3694 across non-broadcast multi-access (NBMA) subnets. This is common 3695 when using many radio technologies. When such NBMA subnets are used, 3696 they MUST NOT be represented as ACP multi-access virtual interfaces 3697 because the replication of IPv6 link-local multicast messages will 3698 not reach all NBMA subnet neighbors. In result, GRASP message 3699 flooding would fail. Instead, each ACP secure channel across such an 3700 interface MUST be represented as a ACP point-to-point virtual 3701 interface. See also Appendix A.10.4. 3703 Care needs to be taken when creating multi-access ACP virtual 3704 interfaces across ACP secure channels between ACP nodes in different 3705 domains or routing subdomains. If for example future inter-domain 3706 ACP policies are defined as "peer-to-peer" policies, it is easier to 3707 create ACP point-to-point virtual interfaces for these inter-domain 3708 secure channels. 3710 7. ACP support on L2 switches/ports (Normative) 3712 7.1. Why (Benefits of ACP on L2 switches) 3714 ANrtr1 ------ ANswitch1 --- ANswitch2 ------- ANrtr2 3715 .../ \ \ ... 3716 ANrtrM ------ \ ------- ANrtrN 3717 ANswitchM ... 3719 Figure 14: Topology with L2 ACP switches 3721 Consider a large L2 LAN with ANrtr1...ANrtrN connected via some 3722 topology of L2 switches. Examples include large enterprise campus 3723 networks with an L2 core, IoT networks or broadband aggregation 3724 networks which often have even a multi-level L2 switched topology. 3726 If the discovery protocol used for the ACP is operating at the subnet 3727 level, every ACP router will see all other ACP routers on the LAN as 3728 neighbors and a full mesh of ACP channels will be built. If some or 3729 all of the AN switches are autonomic with the same discovery 3730 protocol, then the full mesh would include those switches as well. 3732 A full mesh of ACP connections can create fundamental scale 3733 challenges. The number of security associations of the secure 3734 channel protocols will likely not scale arbitrarily, especially when 3735 they leverage platform accelerated encryption/decryption. Likewise, 3736 any other ACP operations (such as routing) needs to scale to the 3737 number of direct ACP neighbors. An ACP router with just 4 physical 3738 interfaces might be deployed into a LAN with hundreds of neighbors 3739 connected via switches. Introducing such a new unpredictable scaling 3740 factor requirement makes it harder to support the ACP on arbitrary 3741 platforms and in arbitrary deployments. 3743 Predictable scaling requirements for ACP neighbors can most easily be 3744 achieved if in topologies such as these, ACP capable L2 switches can 3745 ensure that discovery messages terminate on them so that neighboring 3746 ACP routers and switches will only find the physically connected ACP 3747 L2 switches as their candidate ACP neighbors. With such a discovery 3748 mechanism in place, the ACP and its security associations will only 3749 need to scale to the number of physical interfaces instead of a 3750 potentially much larger number of "LAN-connected" neighbors. And the 3751 ACP topology will follow directly the physical topology, something 3752 which can then also be leveraged in management operations or by ASAs. 3754 In the example above, consider ANswitch1 and ANswitchM are ACP 3755 capable, and ANswitch2 is not ACP capable. The desired ACP topology 3756 is that ANrtr1 and ANrtrM only have an ACP connection to ANswitch1, 3757 and that ANswitch1, ANrtr2, ANrtrN have a full mesh of ACP connection 3758 amongst each other. ANswitch1 also has an ACP connection with 3759 ANswitchM and ANswitchM has ACP connections to anything else behind 3760 it. 3762 7.2. How (per L2 port DULL GRASP) 3764 To support ACP on L2 switches or L2 switched ports of an L3 device, 3765 it is necessary to make those L2 ports look like L3 interfaces for 3766 the ACP implementation. This primarily involves the creation of a 3767 separate DULL GRASP instance/domain on every such L2 port. Because 3768 GRASP has a dedicated link-local IPv6 multicast address 3769 (ALL_GRASP_NEIGHBORS), it is sufficient that all packets for this 3770 address are being extracted at the port level and passed to that DULL 3771 GRASP instance. Likewise the IPv6 link-local multicast packets sent 3772 by that DULL GRASP instance need to be sent only towards the L2 port 3773 for this DULL GRASP instance (instead of being flooded across all 3774 ports of the VLAN to which the port belongs). 3776 When Ports/Interfaces across which the ACP is expected to operate in 3777 an ACP-aware L2-switch or L2/L3-switch/router are L2-bridged, packets 3778 for the ALL_GRASP_NEIGHBORS multicast address MUST never be forward 3779 between these ports. If MLD snooping is used, it MUST be prohibited 3780 from bridging packets for the ALL_GRASP_NEIGHBORS IPv6 multicast 3781 address. 3783 On hybrid L2/L3 switches, multiple L2 ports are assigned to a single 3784 L3 VLAN interface. With the aforementioned changes for DULL GRASP, 3785 ACP can simply operate on the L3 VLAN interfaces, so no further 3786 (hardware) forwarding changes are required to make ACP operate on L2 3787 ports. This is possible because the ACP secure channel protocols 3788 only use link-local IPv6 unicast packets, and these packets will be 3789 sent to the correct L2 port towards the peer by the VLAN logic of the 3790 device. 3792 This is sufficient when p2p ACP virtual interfaces are established to 3793 every ACP peer. When it is desired to create multi-access ACP 3794 virtual interfaces (see Section 6.12.5.2.2), it is REQIURED not to 3795 coalesce all the ACP secure channels on the same L3 VLAN interface, 3796 but only all those on the same L2 port. 3798 If VLAN tagging is used, then all the above described logic only 3799 applies to untagged GRASP packets. For the purpose of ACP neighbor 3800 discovery via GRASP, no VLAN tagged packets SHOULD be sent or 3801 received. In a hybrid L2/L3 switch, each VLAN would therefore only 3802 create ACP adjacencies across those ports where the VLAN is carried 3803 untagged. 3805 In result, the simple logic is that ACP secure channels would operate 3806 over the same L3 interfaces that present a single flat bridged 3807 network across all routers, but because DULL GRASP is separated on a 3808 per-port basis, no full mesh of ACP secure channels is created, but 3809 only per-port ACP secure channels to per-port L2-adjacent ACP node 3810 neighbors. 3812 For example, in the above picture, ANswitch1 would run separate DULL 3813 GRASP instances on its ports to ANrtr1, ANswitch2 and ANswitchI, even 3814 though all those three ports may be in the data plane in the same 3815 (V)LAN and perform L2 switching between these ports, ANswitch1 would 3816 perform ACP L3 routing between them. 3818 The description in the previous paragraph was specifically meant to 3819 illustrate that on hybrid L3/L2 devices that are common in 3820 enterprise, IoT and broadband aggregation, there is only the GRASP 3821 packet extraction (by Ethernet address) and GRASP link-local 3822 multicast per L2-port packet injection that has to consider L2 ports 3823 at the hardware forwarding level. The remaining operations are 3824 purely ACP control plane and setup of secure channels across the L3 3825 interface. This hopefully makes support for per-L2 port ACP on those 3826 hybrid devices easy. 3828 In devices without such a mix of L2 port/interfaces and L3 interfaces 3829 (to terminate any transport layer connections), implementation 3830 details will differ. Logically most simply every L2 port is 3831 considered and used as a separate L3 subnet for all ACP operations. 3832 The fact that the ACP only requires IPv6 link-local unicast and 3833 multicast should make support for it on any type of L2 devices as 3834 simple as possible. 3836 A generic issue with ACP in L2 switched networks is the interaction 3837 with the Spanning Tree Protocol. Without further L2 enhancements, 3838 the ACP would run only across the active STP topology and the ACP 3839 would be interrupted and re-converge with STP changes. Ideally, ACP 3840 peering SHOULD be built also across ports that are blocked in STP so 3841 that the ACP does not depend on STP and can continue to run 3842 unaffected across STP topology changes, where re-convergence can be 3843 quite slow. The above described simple implementation options are 3844 not sufficient to achieve this. 3846 8. Support for Non-ACP Components (Normative) 3848 8.1. ACP Connect 3850 8.1.1. Non-ACP Controller / NMS system 3852 The Autonomic Control Plane can be used by management systems, such 3853 as controllers or network management system (NMS) hosts (henceforth 3854 called simply "NMS hosts"), to connect to devices (or other type of 3855 nodes) through it. For this, an NMS host needs to have access to the 3856 ACP. The ACP is a self-protecting overlay network, which allows by 3857 default access only to trusted, autonomic systems. Therefore, a 3858 traditional, non-ACP NMS system does not have access to the ACP by 3859 default, such as any other external node. 3861 If the NMS host is not autonomic, i.e., it does not support autonomic 3862 negotiation of the ACP, then it can be brought into the ACP by 3863 explicit configuration. To support connections to adjacent non-ACP 3864 nodes, an ACP node SHOULD support "ACP connect" (sometimes also 3865 called "autonomic connect"): 3867 "ACP connect" is an interface level configured workaround for 3868 connection of trusted non-ACP nodes to the ACP. The ACP node on 3869 which ACP connect is configured is called an "ACP edge node". With 3870 ACP connect, the ACP is accessible from those non-ACP nodes (such as 3871 NOC systems) on such an interface without those non-ACP nodes having 3872 to support any ACP discovery or ACP channel setup. This is also 3873 called "native" access to the ACP because to those NOC systems the 3874 interface looks like a normal network interface (without any 3875 encryption/novel-signaling). 3877 Data-Plane "native" (no ACP) 3878 . 3879 +--------+ +----------------+ . +-------------+ 3880 | ACP | |ACP Edge Node | . | | 3881 | Node | | | v | | 3882 | |-------|...[ACP VRF]....+-----------------| |+ 3883 | | ^ |. | | NOC Device || 3884 | | . | .[Data-Plane]..+-----------------| "NMS hosts" || 3885 | | . | [ ] | . ^ | || 3886 +--------+ . +----------------+ . . +-------------+| 3887 . . . +-------------+ 3888 . . . 3889 Data-Plane "native" . ACP "native" (unencrypted) 3890 + ACP auto-negotiated . "ACP connect subnet" 3891 and encrypted . 3892 ACP connect interface 3893 e.g., "VRF ACP native" (config) 3895 Figure 15: ACP connect 3897 ACP connect has security consequences: All systems and processes 3898 connected via ACP connect have access to all ACP nodes on the entire 3899 ACP, without further authentication. Thus, the ACP connect interface 3900 and NOC systems connected to it needs to be physically controlled/ 3901 secured. For this reason the mechanisms described here do explicitly 3902 not include options to allow for a non-ACP router to be connected 3903 across an ACP connect interface and addresses behind such a router 3904 routed inside the ACP. 3906 An ACP connect interface provides exclusively access to only the ACP. 3907 This is likely insufficient for many NMS hosts. Instead, they would 3908 require a second "Data-Plane" interface outside the ACP for 3909 connections between the NMS host and administrators, or Internet 3910 based services, or for direct access to the Data-Plane. The document 3911 "Using Autonomic Control Plane for Stable Connectivity of Network 3912 OAM" [RFC8368] explains in more detail how the ACP can be integrated 3913 in a mixed NOC environment. 3915 An ACP connect interface SHOULD use an IPv6 address/prefix from the 3916 ACP Manual Addressing Sub-Scheme (Section 6.10.4), letting the 3917 operator configure for example only the Subnet-ID and having the node 3918 automatically assign the remaining part of the prefix/address. It 3919 SHOULD NOT use a prefix that is also routed outside the ACP so that 3920 the addresses clearly indicate whether it is used inside the ACP or 3921 not. 3923 The prefix of ACP connect subnets MUST be distributed by the ACP edge 3924 node into the ACP routing protocol RPL. The NMS hosts MUST connect 3925 to prefixes in the ACP routing table via its ACP connect interface. 3926 In the simple case where the ACP uses only one ULA prefix and all ACP 3927 connect subnets have prefixes covered by that ULA prefix, NMS hosts 3928 can rely on [RFC6724] to determine longest match prefix routes 3929 towards its different interfaces, ACP and data-plane. With RFC6724, 3930 The NMS host will select the ACP connect interface for all addresses 3931 in the ACP because any ACP destination address is longest matched by 3932 the address on the ACP connect interface. If the NMS hosts ACP 3933 connect interface uses another prefix or if the ACP uses multiple ULA 3934 prefixes, then the NMS hosts require (static) routes towards the ACP 3935 interface for these prefixes. 3937 When an ACP Edge node receives a packet from an ACP connect 3938 interface, the ACP Edge node MUST only forward the packet into the 3939 ACP if the packet has an IPv6 source address from that interface. 3940 This is sometimes called "RPF filtering". This MAY be changed 3941 through administrative measures. 3943 To limit the security impact of ACP connect, nodes supporting it 3944 SHOULD implement a security mechanism to allow configuration/use of 3945 ACP connect interfaces only on nodes explicitly targeted to be 3946 deployed with it (those in physically secure locations such as a 3947 NOC). For example, the registrar could disable the ability to enable 3948 ACP connect on devices during enrollment and that property could only 3949 be changed through re-enrollment. See also Appendix A.10.5. 3951 ACP Edge nodes SHOULD have a configurable option to filter packets 3952 with RPI headers (xsee Section 6.11.1.13 across an ACP connect 3953 interface. These headers are outside the scope of the RPL profile in 3954 this specification but may be used in future extensions of this 3955 specification. 3957 8.1.2. Software Components 3959 The previous section assumed that ACP Edge node and NOC devices are 3960 separate physical devices and the ACP connect interface is a physical 3961 network connection. This section discusses the implication when 3962 these components are instead software components running on a single 3963 physical device. 3965 The ACP connect mechanism can not only be used to connect physically 3966 external systems (NMS hosts) to the ACP but also other applications, 3967 containers or virtual machines. In fact, one possible way to 3968 eliminate the security issue of the external ACP connect interface is 3969 to collocate an ACP edge node and an NMS host by making one a virtual 3970 machine or container inside the other; and therefore converting the 3971 unprotected external ACP subnet into an internal virtual subnet in a 3972 single device. This would ultimately result in a fully ACP enabled 3973 NMS host with minimum impact to the NMS hosts software architecture. 3974 This approach is not limited to NMS hosts but could equally be 3975 applied to devices consisting of one or more VNF (virtual network 3976 functions): An internal virtual subnet connecting out-of-band 3977 management interfaces of the VNFs to an ACP edge router VNF. 3979 The core requirement is that the software components need to have a 3980 network stack that permits access to the ACP and optionally also the 3981 Data-Plane. Like in the physical setup for NMS hosts this can be 3982 realized via two internal virtual subnets. One that is connecting to 3983 the ACP (which could be a container or virtual machine by itself), 3984 and one (or more) connecting into the Data-Plane. 3986 This "internal" use of ACP connect approach should not considered to 3987 be a "workaround" because in this case it is possible to build a 3988 correct security model: It is not necessary to rely on unprovable 3989 external physical security mechanisms as in the case of external NMS 3990 hosts. Instead, the orchestration of the ACP, the virtual subnets 3991 and the software components can be done by trusted software that 3992 could be considered to be part of the ANI (or even an extended ACP). 3993 This software component is responsible for ensuring that only trusted 3994 software components will get access to that virtual subnet and that 3995 only even more trusted software components will get access to both 3996 the ACP virtual subnet and the Data-Plane (because those ACP users 3997 could leak traffic between ACP and Data-Plane). This trust could be 3998 established for example through cryptographic means such as signed 3999 software packages. 4001 8.1.3. Auto Configuration 4003 ACP edge nodes, NMS hosts and software components that as described 4004 in the previous section are meant to be composed via virtual 4005 interfaces SHOULD support on the ACP connect subnet StateLess Address 4006 Autoconfiguration (SLAAC - [RFC4862]) and route auto configuration 4007 according to [RFC4191]. 4009 The ACP edge node acts as the router on the ACP connect subnet, 4010 providing the (auto-)configured prefix for the ACP connect subnet to 4011 NMS hosts and/or software components. The ACP edge node uses route 4012 prefix option of RFC4191 to announce the default route (::/) with a 4013 lifetime of 0 and aggregated prefixes for routes in the ACP routing 4014 table with normal lifetimes. This will ensure that the ACP edge node 4015 does not become a default router, but that the NMS hosts and software 4016 components will route the prefixes used in the ACP to the ACP edge 4017 node. 4019 Aggregated prefix means that the ACP edge node needs to only announce 4020 the /48 ULA prefixes used in the ACP but none of the actual /64 4021 (Manual Addressing Sub-Scheme), /127 (ACP Zone Addressing Sub- 4022 Scheme), /112 or /120 (Vlong Addressing Sub-Scheme) routes of actual 4023 ACP nodes. If ACP interfaces are configured with non ULA prefixes, 4024 then those prefixes cannot be aggregated without further configured 4025 policy on the ACP edge node. This explains the above recommendation 4026 to use ACP ULA prefix covered prefixes for ACP connect interfaces: 4027 They allow for a shorter list of prefixes to be signaled via RFC4191 4028 to NMS hosts and software components. 4030 The ACP edge nodes that have a Vlong ACP address MAY allocate a 4031 subset of their /112 or /120 address prefix to ACP connect 4032 interface(s) to eliminate the need to non-autonomically configure/ 4033 provision the address prefixes for such ACP connect interfaces. 4035 8.1.4. Combined ACP/Data-Plane Interface (VRF Select) 4037 Combined ACP and Data-Plane interface 4038 . 4039 +--------+ +--------------------+ . +--------------+ 4040 | ACP | |ACP Edge No | . | NMS Host(s) | 4041 | Node | | | . | / Software | 4042 | | | [ACP ]. | . | |+ 4043 | | | .[VRF ] .[VRF ] | v | "ACP address"|| 4044 | +-------+. .[Select].+--------+ "Date Plane || 4045 | | ^ | .[Data ]. | | Address(es)"|| 4046 | | . | [Plane] | | || 4047 | | . | [ ] | +--------------+| 4048 +--------+ . +--------------------+ +--------------+ 4049 . 4050 Data-Plane "native" and + ACP auto-negotiated/encrypted 4052 Figure 16: VRF select 4054 Using two physical and/or virtual subnets (and therefore interfaces) 4055 into NMS Hosts (as per Section 8.1.1) or Software (as per 4056 Section 8.1.2) may be seen as additional complexity, for example with 4057 legacy NMS Hosts that support only one IP interface. 4059 To provide a single subnet into both ACP and Data-Plane, the ACP Edge 4060 node needs to de-multiplex packets from NMS hosts into ACP VRF and 4061 Data-Plane. This is sometimes called "VRF select". If the ACP VRF 4062 has no overlapping IPv6 addresses with the Data-Plane (it should have 4063 no overlapping addresses), then this function can use the IPv6 4064 Destination address. The problem is Source Address Selection on the 4065 NMS Host(s) according to RFC6724. 4067 Consider the simple case: The ACP uses only one ULA prefix, the ACP 4068 IPv6 prefix for the Combined ACP and Data-Plane interface is covered 4069 by that ULA prefix. The ACP edge node announces both the ACP IPv6 4070 prefix and one (or more) prefixes for the Data-Plane. Without 4071 further policy configurations on the NMS Host(s), it may select its 4072 ACP address as a source address for Data-Plane ULA destinations 4073 because of Rule 8 of RFC6724. The ACP edge node can pass on the 4074 packet to the Data-Plane, but the ACP source address should not be 4075 used for Data-Plane traffic, and return traffic may fail. 4077 If the ACP carries multiple ULA prefixes or non-ULA ACP connect 4078 prefixes, then the correct source address selection becomes even more 4079 problematic. 4081 With separate ACP connect and Data-Plane subnets and RFC4191 prefix 4082 announcements that are to be routed across the ACP connect interface, 4083 RFC6724 source address selection Rule 5 (use address of outgoing 4084 interface) will be used, so that above problems do not occur, even in 4085 more complex cases of multiple ULA and non-ULA prefixes in the ACP 4086 routing table. 4088 To achieve the same behavior with a Combined ACP and Data-Plane 4089 interface, the ACP Edge Node needs to behave as two separate routers 4090 on the interface: One link-local IPv6 address/router for its ACP 4091 reachability, and one link-local IPv6 address/router for its Data- 4092 Plane reachability. The Router Advertisements for both are as 4093 described above (Section 8.1.3): For the ACP, the ACP prefix is 4094 announced together with RFC4191 option for the prefixes routed across 4095 the ACP and lifetime=0 to disqualify this next-hop as a default 4096 router. For the Data-Plane, the Data-Plane prefix(es) are announced 4097 together with whatever dafault router parameters are used for the 4098 Data-Plane. 4100 In result, RFC6724 source address selection Rule 5.5 may result in 4101 the same correct source address selection behavior of NMS hosts 4102 without further configuration on it as the separate ACP connect and 4103 Data-Plane interfaces. As described in the text for Rule 5.5, this 4104 is only a MAY, because IPv6 hosts are not required to track next-hop 4105 information. If an NMS Host does not do this, then separate ACP 4106 connect and Data-Plane interfaces are the preferable method of 4107 attachment. Hosts implementing [RFC8028] should (instead of may) 4108 implement [RFC6724] Rule 5.5, so it is preferred for hosts to support 4109 [RFC8028]. 4111 ACP edge nodes MAY support the Combined ACP and Data-Plane interface. 4113 8.1.5. Use of GRASP 4115 GRASP can and should be possible to use across ACP connect 4116 interfaces, especially in the architectural correct solution when it 4117 is used as a mechanism to connect Software (e.g., ASA or legacy NMS 4118 applications) to the ACP. 4120 Given how the ACP is the security and transport substrate for GRASP, 4121 the requirements for devices connected via ACP connect is that those 4122 are equivalently (if not better) secured against attacks and run only 4123 software that is equally (if not better) protected, known (or 4124 trusted) not to be malicious and accordingly designed to isolate 4125 access to the ACP against external equipment. 4127 The difference in security is that cryptographic security of the ACP 4128 secure channel is replaced by required physical security of the 4129 network connection between an ACP edge node and the NMS or other host 4130 reachable via the ACP connect interface. Node integrity too is 4131 expected to be easier because the ACP connect node, the ACP connect 4132 link and the nodes connecting to it must be in a contiguous secure 4133 environment, hence assuming there can be no physical attack against 4134 the devices. 4136 When using "Combined ACP and Data-Plane Interfaces", care hasa to be 4137 taken that only GRASP messages intended for the ACP GRASP domain 4138 received from Software or NMS Hosts are forwarded by ACP edge nodes. 4139 Currently there is no definition for a GRASP security and transport 4140 substrate beside the ACP, so there is no definition how such 4141 Software/NMS Host could participate in two separate GRASP Domains 4142 across the same subnet (ACP and Data-Plane domains). At current it 4143 is assumed that all GRASP packets on a Combined ACP and Data-Plane 4144 interface belong to the GRASP ACP Domain. They SHOULD all use the 4145 ACP IPv6 addresses of the Software/NMS Hosts. The link-local IPv6 4146 addresses of Software/NMS Hosts (used for GRASP M_DISCOVERY and 4147 M_FLOOD messages) are also assumed to belong to the ACP address 4148 space. 4150 8.2. Connecting ACP islands over Non-ACP L3 networks (Remote ACP 4151 neighbors) 4153 Not all nodes in a network may support the ACP. If non-ACP Layer-2 4154 devices are between ACP nodes, the ACP will work across it since it 4155 is IP based. However, the autonomic discovery of ACP neighbors via 4156 DULL GRASP is only intended to work across L2 connections, so it is 4157 not sufficient to autonomically create ACP connections across non-ACP 4158 Layer-3 devices. 4160 8.2.1. Configured Remote ACP neighbor 4162 On the ACP node, remote ACP neighbors are configured explicitly. The 4163 parameters of such a "connection" are described in the following 4164 ABNF. 4166 connection = [ method , local-addr, remote-addr, ?pmtu ] 4167 method = [ "IKEv2" , ?port ] 4168 method //= [ "DTLS", port ] 4169 local-addr = [ address , ?vrf ] 4170 remote-addr = [ address ] 4171 address = ("any" | ipv4-address | ipv6-address ) 4172 vrf = tstr ; Name of a VRF on this node with local-address 4174 Figure 17: Parameters for remote ACP neighbors 4176 Explicit configuration of a remote-peer according to this ABNF 4177 provides all the information to build a secure channel without 4178 requiring a tunnel to that peer and running DULL GRASP inside of it. 4180 The configuration includes the parameters otherwise signaled via DULL 4181 GRASP: local address, remote (peer) locator and method. The 4182 differences over DULL GRASP local neighbor discovery and secure 4183 channel creation are as follows: 4185 o The local and remote address can be IPv4 or IPv6 and are typically 4186 global scope addresses. 4188 o The VRF across which the connection is built (and in which local- 4189 addr exists) can to be specified. If vrf is not specified, it is 4190 the default VRF on the node. In DULL GRASP the VRF is implied by 4191 the interface across which DULL GRASP operates. 4193 o If local address is "any", the local address used when initiating 4194 a secure channel connection is decided by source address selection 4195 ([RFC6724] for IPv6). As a responder, the connection listens on 4196 all addresses of the node in the selected VRF. 4198 o Configuration of port is only required for methods where no 4199 defaults exist (e.g., "DTLS"). 4201 o If remote address is "any", the connection is only a responder. 4202 It is a "hub" that can be used by multiple remote peers to connect 4203 simultaneously - without having to know or configure their 4204 addresses. Example: Hub site for remote "spoke" sites reachable 4205 over the Internet. 4207 o Pmtu should be configurable to overcome issues/limitations of Path 4208 MTU Discovery (PMTUD). 4210 o IKEv2/IPsec to remote peers should support the optional NAT 4211 Traversal (NAT-T) procedures. 4213 8.2.2. Tunneled Remote ACP Neighbor 4215 An IPinIP, GRE or other form of pre-existing tunnel is configured 4216 between two remote ACP peers and the virtual interfaces representing 4217 the tunnel are configured for "ACP enable". This will enable IPv6 4218 link local addresses and DULL on this tunnel. In result, the tunnel 4219 is used for normal "L2 adjacent" candidate ACP neighbor discovery 4220 with DULL and secure channel setup procedures described in this 4221 document. 4223 Tunneled Remote ACP Neighbor requires two encapsulations: the 4224 configured tunnel and the secure channel inside of that tunnel. This 4225 makes it in general less desirable than Configured Remote ACP 4226 Neighbor. Benefits of tunnels are that it may be easier to implement 4227 because there is no change to the ACP functionality - just running it 4228 over a virtual (tunnel) interface instead of only native interfaces. 4229 The tunnel itself may also provide PMTUD while the secure channel 4230 method may not. Or the tunnel mechanism is permitted/possible 4231 through some firewall while the secure channel method may not. 4233 8.2.3. Summary 4235 Configured/Tunneled Remote ACP neighbors are less "indestructible" 4236 than L2 adjacent ACP neighbors based on link local addressing, since 4237 they depend on more correct Data-Plane operations, such as routing 4238 and global addressing. 4240 Nevertheless, these options may be crucial to incrementally deploy 4241 the ACP, especially if it is meant to connect islands across the 4242 Internet. Implementations SHOULD support at least Tunneled Remote 4243 ACP Neighbors via GRE tunnels - which is likely the most common 4244 router-to-router tunneling protocol in use today. 4246 9. Benefits (Informative) 4248 9.1. Self-Healing Properties 4250 The ACP is self-healing: 4252 o New neighbors will automatically join the ACP after successful 4253 validation and will become reachable using their unique ULA 4254 address across the ACP. 4256 o When any changes happen in the topology, the routing protocol used 4257 in the ACP will automatically adapt to the changes and will 4258 continue to provide reachability to all nodes. 4260 o The ACP tracks the validity of peer certificates and tears down 4261 ACP secure channels when a peer certificate has expired. When 4262 short-lived certificates with lifetimes in the order of OCSP/CRL 4263 refresh times are used, then this allows for removal of invalid 4264 peers (whose certificate was not renewed) at similar speeds as 4265 when using OCSP/CRL. The same benefit can be achieved when using 4266 CRL/OCSP, periodically refreshing the revocation information and 4267 also tearing down ACP secure channels when the peer's (long-lived) 4268 certificate is revoked. There is no requirement against ACP 4269 implementations to require this enhancement though to keep the 4270 mandatory implementations simpler. 4272 The ACP can also sustain network partitions and mergers. Practically 4273 all ACP operations are link local, where a network partition has no 4274 impact. Nodes authenticate each other using the domain certificates 4275 to establish the ACP locally. Addressing inside the ACP remains 4276 unchanged, and the routing protocol inside both parts of the ACP will 4277 lead to two working (although partitioned) ACPs. 4279 There are few central dependencies: A CRL may not be available during 4280 a network partition; a suitable policy to not immediately disconnect 4281 neighbors when no CRL is available can address this issue. Also, an 4282 ACP registrar or Certificate Authority might not be available during 4283 a partition. This may delay renewal of certificates that are to 4284 expire in the future, and it may prevent the enrollment of new nodes 4285 during the partition. 4287 Highly resilient ACP designs can be built by using ACP registrars 4288 with embedded sub-CA, as outlined in Section 10.2.4. As long as a 4289 partition is left with one or more of such ACP registrars, it can 4290 continue to enroll new candidate ACP nodes as long as the ACP 4291 registrar's sub-CA certificate does not expire. Because the ACP 4292 addressing relies on unique Registrar-IDs, a later re-merge of 4293 partitions will also not cause problems with ACP addresses assigned 4294 during partitioning. 4296 After a network partition, a re-merge will just establish the 4297 previous status, certificates can be renewed, the CRL is available, 4298 and new nodes can be enrolled everywhere. Since all nodes use the 4299 same trust anchor(s), a re-merge will be smooth. 4301 Merging two networks with different trust anchors requires the ACP 4302 nodes to trust the union of Trust Anchors. As long as the routing- 4303 subdomain hashes are different, the addressing will not overlap, 4304 which only happens in the unlikely event of a 40-bit hash collision 4305 in SHA256 (see Section 6.10). Note that the complete mechanisms to 4306 merge networks is out of scope of this specification. 4308 It is also highly desirable for implementation of the ACP to be able 4309 to run it over interfaces that are administratively down. If this is 4310 not feasible, then it might instead be possible to request explicit 4311 operator override upon administrative actions that would 4312 administratively bring down an interface across which the ACP is 4313 running. Especially if bringing down the ACP is known to disconnect 4314 the operator from the node. For example any such down administrative 4315 action could perform a dependency check to see if the transport 4316 connection across which this action is performed is affected by the 4317 down action (with default RPL routing used, packet forwarding will be 4318 symmetric, so this is actually possible to check). 4320 9.2. Self-Protection Properties 4322 9.2.1. From the outside 4324 As explained in Section 6, the ACP is based on secure channels built 4325 between nodes that have mutually authenticated each other with their 4326 domain certificates. The channels themselves are protected using 4327 standard encryption technologies such as DTLS or IPsec which provide 4328 additional authentication during channel establishment, data 4329 integrity and data confidentiality protection of data inside the ACP 4330 and in addition, provide replay protection. 4332 An attacker will not be able to join the ACP unless having a valid 4333 domain certificate, also packet injection and sniffing traffic will 4334 not be possible due to the security provided by the encryption 4335 protocol. 4337 The ACP also serves as protection (through authentication and 4338 encryption) for protocols relevant to OAM that may not have secured 4339 protocol stack options or where implementation or deployment of those 4340 options fail on some vendor/product/customer limitations. This 4341 includes protocols such as SNMP ([RFC3411]), NTP ([RFC5905]), PTP 4342 ([IEEE-1588-2008]), DNS ([RFC3596]), DHCPv6 ([RFC3315]), syslog 4343 ([RFC3164]), Radius ([RFC2865]), Diameter ([RFC6733]), TACACS 4344 ([RFC1492]), IPFIX ([RFC7011]), Netflow ([RFC3954]) - just to name a 4345 few. Protection via the ACP secure hop-by-hop channels for these 4346 protocols is meant to be only a stopgap though: The ultimate goal is 4347 for these and other protocols to use end-to-end encryption utilizing 4348 the domain certificate and rely on the ACP secure channels primarily 4349 for zero-touch reliable connectivity, but not primarily for security. 4351 The remaining attack vector would be to attack the underlying ACP 4352 protocols themselves, either via directed attacks or by denial-of- 4353 service attacks. However, as the ACP is built using link-local IPv6 4354 addresses, remote attacks from the data-plane are impossible as long 4355 as the data-plane has no facilities to remotely sent IPv6 link-local 4356 packets. The only exception are ACP connected interfaces which 4357 require higher physical protection. The ULA addresses are only 4358 reachable inside the ACP context, therefore, unreachable from the 4359 Data-Plane. Also, the ACP protocols should be implemented to be 4360 attack resistant and not consume unnecessary resources even while 4361 under attack. 4363 9.2.2. From the inside 4365 The security model of the ACP is based on trusting all members of the 4366 group of nodes that receive an ACP domain certificate for the same 4367 domain. Attacks from the inside by a compromised group member are 4368 therefore the biggest challenge. 4370 Group members must be protected against attackers so that there is no 4371 easy way to compromise them, or use them as a proxy for attacking 4372 other devices across the ACP. For example, management plane 4373 functions (transport ports) should only be reachable from the ACP but 4374 not the Data-Plane. Especially for those management plane functions 4375 that have no good protection by themselves because they do not have 4376 secure end-to-end transport and to whom ACP not only provides 4377 automatic reliable connectivity but also protection against attacks. 4378 Protection across all potential attack vectors is typically easier to 4379 do in devices whose software is designed from the ground up with 4380 security in mind than with legacy software based systems where the 4381 ACP is added on as another feature. 4383 As explained above, traffic across the ACP SHOULD still be end-to-end 4384 encrypted whenever possible. This includes traffic such as GRASP, 4385 EST and BRSKI inside the ACP. This minimizes man in the middle 4386 attacks by compromised ACP group members. Such attackers cannot 4387 eavesdrop or modify communications, they can just filter them (which 4388 is unavoidable by any means). 4390 See Appendix A.10.8 for further considerations how to avoid and deal 4391 with compromised nodes. 4393 9.3. The Administrator View 4395 An ACP is self-forming, self-managing and self-protecting, therefore 4396 has minimal dependencies on the administrator of the network. 4397 Specifically, since it is (intended to be) independent of 4398 configuration, there is only limited scope for configuration errors 4399 on the ACP itself. The administrator may have the option to enable 4400 or disable the entire approach, but detailed configuration is not 4401 possible. This means that the ACP must not be reflected in the 4402 running configuration of nodes, except a possible on/off switch (and 4403 even that is undesirable). 4405 While configuration (except for Section 8 and Section 10.2) is not 4406 possible, an administrator must have full visibility of the ACP and 4407 all its parameters, to be able to do trouble-shooting. Therefore, an 4408 ACP must support all show and debug options, as for any other network 4409 function. Specifically, a network management system or controller 4410 must be able to discover the ACP, and monitor its health. This 4411 visibility of ACP operations must clearly be separated from 4412 visibility of Data-Plane so automated systems will never have to deal 4413 with ACP aspects unless they explicitly desire to do so. 4415 Since an ACP is self-protecting, a node not supporting the ACP, or 4416 without a valid domain certificate cannot connect to it. This means 4417 that by default a traditional controller or network management system 4418 cannot connect to an ACP. See Section 8.1.1 for more details on how 4419 to connect an NMS host into the ACP. 4421 10. ACP Operations (Informative) 4423 The following sections document important operational aspects of the 4424 ACP. They are not normative because they do not impact the 4425 interoperability between components of the ACP, but they include 4426 recommendations/requirements for the internal operational model 4427 beneficial or necessary to achieve the desired use-case benefits of 4428 the ACP (see Section 3). 4430 o Section 10.1 describes recommended operator diagnostics 4431 capabilities of ACP nodes. The have been derived from diagnostic 4432 of a commercially available ACP implementation. 4434 o Section 10.2 describes high level how an ACP registrar needs to 4435 work, what its configuration parameters are and specific issues 4436 impacting the choices of deployment design due to renewal and 4437 revocation issues. It describes a model where ACP Registrars have 4438 their own sub-CA to provide the most distributed deployment option 4439 for ACP Registrars, and it describes considerations for 4440 centralized policy control of ACP Registrar operations. 4442 o Section 10.3 describes suggested ACP node behavior and operational 4443 interfaces (configuration options) to manage the ACP in so-called 4444 greenfield devices (previously unconfigured) and brownfield 4445 devices (preconfigured). 4447 The recommendations and suggestions of this chapter were derived from 4448 operational experience gained with a commercially available pre- 4449 standard ACP implementation. 4451 10.1. ACP (and BRSKI) Diagnostics 4453 Even though ACP and ANI in general are taking out many manual 4454 configuration mistakes through their automation, it is important to 4455 provide good diagnostics for them. 4457 The basic diagnostics is support of (yang) data models representing 4458 the complete (auto-)configuration and operational state of all 4459 components: BRSKI, GRASP, ACP and the infrastructure used by them: 4460 TLS/DTLS, IPsec, certificates, trust anchors, time, VRF and so on. 4461 While necessary, this is not sufficient: 4463 Simply representing the state of components does not allow operators 4464 to quickly take action - unless they do understand how to interpret 4465 the data, and that can mean a requirement for deep understanding of 4466 all components and how they interact in the ACP/ANI. 4468 Diagnostic supports should help to quickly answer the questions 4469 operators are expected to ask, such as "is the ACP working 4470 correctly?", or "why is there no ACP connection to a known 4471 neighboring node?" 4473 In current network management approaches, the logic to answer these 4474 questions is most often built as centralized diagnostics software 4475 that leverages the above mentioned data models. While this approach 4476 is feasible for components utilizing the ANI, it is not sufficient to 4477 diagnose the ANI itself: 4479 o Developing the logic to identify common issues requires 4480 operational experience with the components of the ANI. Letting 4481 each management system define its own analysis is inefficient. 4483 o When the ANI is not operating correctly, it may not be possible to 4484 run diagnostics from remote because of missing connectivity. The 4485 ANI should therefore have diagnostic capabilities available 4486 locally on the nodes themselves. 4488 o Certain operations are difficult or impossible to monitor in real- 4489 time, such as initial bootstrap issues in a network location where 4490 no capabilities exist to attach local diagnostics. Therefore it 4491 is important to also define means of capturing (logging) 4492 diagnostics locally for later retrieval. Ideally, these captures 4493 are also non-volatile so that they can survive extended power-off 4494 conditions - for example when a device that fails to be brought up 4495 zero-touch is being sent back for diagnostics at a more 4496 appropriate location. 4498 The most simple form of diagnostics answering questions such as the 4499 above is to represent the relevant information sequentially in 4500 dependency order, so that the first non-expected/non-operational item 4501 is the most likely root cause. Or just log/highlight that item. For 4502 example: 4504 Q: Is ACP operational to accept neighbor connections: 4506 o Check if any potentially necessary configuration to make ACP/ANI 4507 operational are correct (see Section 10.3 for a discussion of such 4508 commands). 4510 o Does the system time look reasonable, or could it be the default 4511 system time after clock chip battery failure (certificate checks 4512 depend on reasonable notion of time). 4514 o Does the node have keying material - domain certificate, trust 4515 anchors. 4517 o If no keying material and ANI is supported/enabled, check the 4518 state of BRSKI (not detailed in this example). 4520 o Check the validity of the domain certificate: 4522 * Does the certificate validate against the trust anchor? 4524 * Has it been revoked? 4526 * Was the last scheduled attempt to retrieve a CRL successful 4527 (e.g., do we know that our CRL information is up to date). 4529 * Is the certificate valid: validity start time in the past, 4530 expiration time in the future? 4532 * Does the certificate have a correctly formatted ACP domain 4533 information field? 4535 o Was the ACP VRF successfully created? 4537 o Is ACP enabled on one or more interfaces that are up and running? 4539 If all this looks good, the ACP should be running locally "fine" - 4540 but we did not check any ACP neighbor relationships. 4542 Question: why does the node not create a working ACP connection to a 4543 neighbor on an interface? 4545 o Is the interface physically up? Does it have an IPv6 link-local 4546 address? 4548 o Is it enabled for ACP? 4550 o Do we successfully send DULL GRASP messages to the interface (link 4551 layer errors)? 4553 o Do we receive DULL GRASP messages on the interface? If not, some 4554 intervening L2 equipment performing bad MLD snooping could have 4555 caused problems. Provide e.g., diagnostics of the MLD querier 4556 IPv6 and MAC address. 4558 o Do we see the ACP objective in any DULL GRASP message from that 4559 interface? Diagnose the supported secure channel methods. 4561 o Do we know the MAC address of the neighbor with the ACP objective? 4562 If not, diagnose SLAAC/ND state. 4564 o When did we last attempt to build an ACP secure channel to the 4565 neighbor? 4567 o If it failed, why: 4569 * Did the neighbor close the connection on us or did we close the 4570 connection on it because the domain certificate membership 4571 failed? 4573 * If the neighbor closed the connection on us, provide any error 4574 diagnostics from the secure channel protocol. 4576 * If we failed the attempt, display our local reason: 4578 + There was no common secure channel protocol supported by the 4579 two neighbors (this could not happen on nodes supporting 4580 this specification because it mandates common support for 4581 IPsec). 4583 + The ACP domain certificate membership check (Section 6.1.3) 4584 fails: 4586 - The neighbor's certificate does not have the required 4587 trust anchor. Provide diagnostics which trust anchor it 4588 has (can identify whom the device belongs to). 4590 - The neighbor's certificate does not have the same domain 4591 (or no domain at all). Diagnose domain-name and 4592 potentially other cert info. 4594 - The neighbor's certificate has been revoked or could not 4595 be authenticated by OCSP. 4597 - The neighbor's certificate has expired - or is not yet 4598 valid. 4600 * Any other connection issues in e.g., IKEv2 / IPsec, DTLS?. 4602 Question: Is the ACP operating correctly across its secure channels? 4604 o Are there one or more active ACP neighbors with secure channels? 4606 o Is the RPL routing protocol for the ACP running? 4608 o Is there a default route to the root in the ACP routing table? 4610 o Is there for each direct ACP neighbor not reachable over the ACP 4611 virtual interface to the root a route in the ACP routing table? 4613 o Is ACP GRASP running? 4615 o Is at least one SRV.est objective cached (to support certificate 4616 renewal)? 4618 o Is there at least one BRSKI registrar objective cached (in case 4619 BRSKI is supported) 4621 o Is BRSKI proxy operating normally on all interfaces where ACP is 4622 operating? 4624 o ... 4626 These lists are not necessarily complete, but illustrate the 4627 principle and show that there are variety of issues ranging from 4628 normal operational causes (a neighbor in another ACP domain) over 4629 problems in the credentials management (certificate lifetimes), 4630 explicit security actions (revocation) or unexpected connectivity 4631 issues (intervening L2 equipment). 4633 The items so far are illustrating how the ANI operations can be 4634 diagnosed with passive observation of the operational state of its 4635 components including historic/cached/counted events. This is not 4636 necessary sufficient to provide good enough diagnostics overall: 4638 The components of ACP and BRSKI are designed with security in mind 4639 but they do not attempt to provide diagnostics for building the 4640 network itself. Consider two examples: 4642 1. BRSKI does not allow for a neighboring device to identify the 4643 pledges certificate (IDevID). Only the selected BRSKI registrar 4644 can do this, but it may be difficult to disseminate information 4645 about undesired pledges from those BRSKI registrars to locations/ 4646 nodes where information about those pledges is desired. 4648 2. LLDP disseminates information about nodes to their immediate 4649 neighbors, such as node model/type/software and interface name/ 4650 number of the connection. This information is often helpful or 4651 even necessary in network diagnostics. It can equally considered 4652 to be too insecure to make this information available unprotected 4653 to all possible neighbors. 4655 An "interested adjacent party" can always determine the IDevID of a 4656 BRSKI pledge by behaving like a BRSKI proxy/registrar. Therefore the 4657 IDevID of a BRSKI pledge is not meant to be protected - it just has 4658 to be queried and is not signaled unsolicited (as it would be in 4659 LLDP) so that other observers on the same subnet can determine who is 4660 an "interested adjacent party". 4662 10.2. ACP Registrars 4664 As described in Section 6.10.7, the ACP addressing mechanism is 4665 designed to enable lightweight, distributed and uncoordinated ACP 4666 registrars that are providing ACP address prefixes to candidate ACP 4667 nodes by enrolling them with an ACP domain certificate into an ACP 4668 domain via any appropriate mechanism/protocol, automated or not. 4670 This section discusses informatively more details and options for ACP 4671 registrars. 4673 10.2.1. Registrar interactions 4675 This section summarizes and discusses the interactions with other 4676 entities required by an ACP registrar. 4678 In a simple instance of an ACP network, no central NOC component 4679 beside a trust anchor (root CA) is required. One or more 4680 uncoordinated acting ACP registrar can be set up, performing the 4681 following interactions: 4683 To orchestrate enrolling a candidate ACP node autonomically, the ACP 4684 registrar can rely on the ACP and use Proxies to reach the candidate 4685 ACP node, therefore allowing minimum pre-existing (auto-)configured 4686 network services on the candidate ACP node. BRSKI defines the BRSKI 4687 proxy, a design that can be adopted for various protocols that 4688 Pledges/candidate ACP nodes could want to use, for example BRSKI over 4689 CoAP (Constrained Application Protocol), or proxying of Netconf. 4691 To reach a trust anchor unaware of the ACP, the ACP registrar would 4692 use the Data-Plane. ACP and Data-Plane in an ACP registrar could 4693 (and by default should be) completely isolated from each other at the 4694 network level. Only applications such as the ACP registrar would 4695 need the ability for their transport stacks to access both. 4697 In non-autonomic enrollment options, the Data-Plane between a ACP 4698 registrar and the candidate ACP node needs to be configured first. 4699 This includes the ACP registrar and the candidate ACP node. Then any 4700 appropriate set of protocols can be used between ACP registrar and 4701 candidate ACP node to discover the other side, and then connect and 4702 enroll (configure) the candidate ACP node with an ACP domain 4703 certificate. Netconf ZeroTouch ([RFC8572]) is an example protocol 4704 that could be used for this. BRSKI using optional discovery 4705 mechanisms is equally a possibility for candidate ACP nodes 4706 attempting to be enrolled across non-ACP networks, such as the 4707 Internet. 4709 When candidate ACP nodes have secure bootstrap, such as BRSKI 4710 Pledges, they will not trust to be configured/enrolled across the 4711 network, unless being presented with a voucher (see [RFC8366]) 4712 authorizing the network to take possession of the node. An ACP 4713 registrar will then need a method to retrieve such a voucher, either 4714 offline, or online from a MASA (Manufacturer Authorized Signing 4715 Authority). BRSKI and Netconf ZeroTouch are two protocols that 4716 include capabilities to present the voucher to the candidate ACP 4717 node. 4719 An ACP registrar could operate EST for ACP certificate renewal and/or 4720 act as a CRL Distribution point. A node performing these services 4721 does not need to support performing (initial) enrollment, but it does 4722 require the same above described connectivity as an ACP registrar: 4723 via the ACP to ACP nodes and via the Data-Plane to the trust anchor 4724 and other sources of CRL information. 4726 10.2.2. Registrar Parameter 4728 The interactions of an ACP registrar outlined Section 6.10.7 and 4729 Section 10.2.1 above depend on the following parameters: 4731 A URL to the trust anchor (root CA) and credentials so that the 4732 ACP registrar can let the trust anchor sign candidate ACP member 4733 certificates. 4735 The ACP domain-name. 4737 The Registrar-ID to use. This could default to a MAC address of 4738 the ACP registrar. 4740 For recovery, the next-useable Node-IDs for zone (Zone-ID=0) sub- 4741 addressing scheme, for Vlong /112 and for Vlong /1120 sub- 4742 addressing scheme. These IDs would only need to be provisioned 4743 after recovering from a crash. Some other mechanism would be 4744 required to remember these IDs in a backup location or to recover 4745 them from the set of currently known ACP nodes. 4747 Policies if candidate ACP nodes should receive a domain 4748 certificate or not, for example based on the devices IDevID as in 4749 BRSKI. The ACP registrar may have a whitelist or blacklist of 4750 devices "serialNumbers" from their IDevID. 4752 Policies what type of address prefix to assign to a candidate ACP 4753 devices, based on likely the same information. 4755 For BRSKI or other mechanisms using vouchers: Parameters to 4756 determine how to retrieve vouchers for specific type of secure 4757 bootstrap candidate ACP nodes (such as MASA URLs), unless this 4758 information is automatically learned such as from the IDevID of 4759 candidate ACP nodes (as defined in BRSKI). 4761 10.2.3. Certificate renewal and limitations 4763 When an ACP node renews/rekeys its certificate, it may end up doing 4764 so via a different registrar (e.g., EST server) than the one it 4765 originally received its ACP domain certificate from, for example 4766 because that original ACP registrar is gone. The ACP registrar 4767 through which the renewal/rekeying is performed would by default 4768 trust the ACP domain information from the ACP nodes current ACP 4769 domain certificate and maintain this information so that the ACP node 4770 maintains its ACP address prefix. In EST renewal/rekeying, the ACP 4771 nodes current ACP domain certificate is signaled during the TLS 4772 handshake. 4774 This simple scenario has two limitations: 4776 1. The ACP registrars cannot directly assign certificates to nodes 4777 and therefore needs an "online" connection to the trust anchor 4778 (root CA). 4780 2. Recovery from a compromised ACP registrar is difficult. When an 4781 ACP registrar is compromised, it can insert for example 4782 conflicting ACP domain information and create thereby an attack 4783 against other ACP nodes through the ACP routing protocol. 4785 Even when such a malicious ACP registrar is detected, resolving the 4786 problem may be difficult because it would require identifying all the 4787 wrong ACP domain certificates assigned via the ACP registrar after it 4788 was compromised. And without additional centralized tracking of 4789 assigned certificates there is no way to do this. 4791 10.2.4. ACP Registrars with sub-CA 4793 In situations, where either of the above two limitations are an 4794 issue, ACP registrars could also be sub-CAs. This removes the need 4795 for connectivity to a root-CA whenever an ACP node is enrolled, and 4796 reduces the need for connectivity of such an ACP registrar to a root- 4797 CA to only those times when it needs to renew its own certificate. 4798 The ACP registrar would also now use its own (sub-CA) certificate to 4799 enroll and sign the ACP nodes certificates, and therefore it is only 4800 necessary to revoke a compromised ACP registrars sub-CA certificate. 4801 Alternatively one can let it expire and not renew it, when the 4802 certificate of the sub-CA is appropriately short-lived. 4804 As the ACP domain membership check verifies a peer ACP node's ACP 4805 domain certificate trust chain, it will also verify the signing 4806 certificate which is the compromised/revoked sub-CA certificate. 4807 Therefore ACP domain membership for an ACP node enrolled from a 4808 compromised and discovered ACP registrar will fail. 4810 ACP nodes enrolled by a compromised ACP registrar would automatically 4811 fail to establish ACP channels and ACP domain certificate renewal via 4812 EST and therefore revert to their role as a candidate ACP members and 4813 attempt to get a new ACP domain certificate from an ACP registrar - 4814 for example, via BRSKI. In result, ACP registrars that have an 4815 associated sub-CA makes isolating and resolving issues with 4816 compromised registrars easier. 4818 Note that ACP registrars with sub-CA functionality also can control 4819 the lifetime of ACP domain certificates easier and therefore also be 4820 used as a tool to introduce short lived certificates and not rely on 4821 CRL, whereas the certificates for the sub-CAs themselves could be 4822 longer lived and subject to CRL. 4824 10.2.5. Centralized Policy Control 4826 When using multiple, uncoordinated ACP registrars, several advanced 4827 operations are potentially more complex than with a single, resilient 4828 policy control backend, for example including but not limited to: 4830 Which candidate ACP node is permitted or not permitted into an ACP 4831 domain. This may not be a decision to be taken upfront, so that a 4832 per-"serialNumber" policy can be loaded into every ACP registrar. 4833 Instead, it may better be decided in real-time including 4834 potentially a human decision in a NOC. 4836 Tracking of all enrolled ACP nodes and their certificate 4837 information. For example in support of revoking individual ACP 4838 nodes certificates. 4840 More flexible policies what type of address prefix or even what 4841 specific address prefix to assign to a candidate ACP node. 4843 These and other operations could be introduced more easily by 4844 introducing a centralized Policy Management System (PMS) and 4845 modifying ACP registrar behavior so that it queries the PMS for any 4846 policy decision occurring during the candidate ACP node enrollment 4847 process and/or the ACP node certificate renewal process. For 4848 example, which ACP address prefix to assign. Likewise the ACP 4849 registrar would report any relevant state change information to the 4850 PMS as well, for example when a certificate was successfully enrolled 4851 onto a candidate ACP node. 4853 10.3. Enabling and disabling ACP/ANI 4855 Both ACP and BRSKI require interfaces to be operational enough to 4856 support sending/receiving their packets. In node types where 4857 interfaces are by default (e.g., without operator configuration) 4858 enabled, such as most L2 switches, this would be less of a change in 4859 behavior than in most L3 devices (e.g.: routers), where interfaces 4860 are by default disabled. In almost all network devices it is common 4861 though for configuration to change interfaces to a physically 4862 disabled state and that would break the ACP. 4864 In this section, we discuss a suggested operational model to enable/ 4865 disable interfaces and nodes for ACP/ANI in a way that minimizes the 4866 risk of operator action to break the ACP in this way, and that also 4867 minimizes operator surprise when ACP/ANI becomes supported in node 4868 software. 4870 10.3.1. Filtering for non-ACP/ANI packets 4872 Whenever this document refers to enabling an interface for ACP (or 4873 BRSKI), it only requires to permit the interface to send/receive 4874 packets necessary to operate ACP (or BRSKI) - but not any other Data- 4875 Plane packets. Unless the Data-Plane is explicitly configured/ 4876 enabled, all packets not required for ACP/BRSKI should be filtered on 4877 input and output: 4879 Both BRSKI and ACP require link-local only IPv6 operations on 4880 interfaces and DULL GRASP. IPv6 link-local operations means the 4881 minimum signaling to auto-assign an IPv6 link-local address and talk 4882 to neighbors via their link-local address: SLAAC (Stateless Address 4883 Auto-Configuration - [RFC4862]) and ND (Neighbor Discovery - 4884 [RFC4861]). When the device is a BRSKI pledge, it may also require 4885 TCP/TLS connections to BRSKI proxies on the interface. When the 4886 device has keying material, and the ACP is running, it requires DULL 4887 GRASP packets and packets necessary for the secure-channel mechanism 4888 it supports, e.g., IKEv2 and IPsec ESP packets or DTLS packets to the 4889 IPv6 link-local address of an ACP neighbor on the interface. It also 4890 requires TCP/TLS packets for its BRSKI proxy functionality, if it 4891 does support BRSKI. 4893 10.3.2. Admin Down State 4895 Interfaces on most network equipment have at least two states: "up" 4896 and "down". These may have product specific names. "down" for 4897 example could be called "shutdown" and "up" could be called "no 4898 shutdown". The "down" state disables all interface operations down 4899 to the physical level. The "up" state enables the interface enough 4900 for all possible L2/L3 services to operate on top of it and it may 4901 also auto-enable some subset of them. More commonly, the operations 4902 of various L2/L3 services is controlled via additional node-wide or 4903 interface level options, but they all become only active when the 4904 interface is not "down". Therefore an easy way to ensure that all 4905 L2/L3 operations on an interface are inactive is to put the interface 4906 into "down" state. The fact that this also physically shuts down the 4907 interface is in many cases just a side effect, but it may be 4908 important in other cases (see below, Section 10.3.2.2). 4910 To provide ACP/ANI resilience against operators configuring 4911 interfaces to "down" state, this document recommends to separate the 4912 "down" state of interfaces into an "admin down" state where the 4913 physical layer is kept running and ACP/ANI can use the interface and 4914 a "physical down" state. Any existing "down" configurations would 4915 map to "admin down". In "admin down", any existing L2/L3 services of 4916 the Data-Plane should see no difference to "physical down" state. To 4917 ensure that no Data-Plane packets could be sent/received, packet 4918 filtering could be established automatically as described above in 4919 Section 10.3.1. 4921 As necessary (see discussion below) new configuration options could 4922 be introduced to issue "physical down". The options should be 4923 provided with additional checks to minimize the risk of issuing them 4924 in a way that breaks the ACP without automatic restoration. For 4925 example they could be denied to be issued from a control connection 4926 (netconf/ssh) that goes across the interface itself ("do not 4927 disconnect yourself"). Or they could be performed only temporary and 4928 only be made permanent with additional later reconfirmation. 4930 In the following sub-sections important aspects to the introduction 4931 of "admin down" state are discussed. 4933 10.3.2.1. Security 4935 Interfaces are physically brought down (or left in default down 4936 state) as a form of security. "Admin down" state as described above 4937 provides also a high level of security because it only permits ACP/ 4938 ANI operations which are both well secured. Ultimately, it is 4939 subject to security review for the deployment whether "admin down" is 4940 a feasible replacement for "physical down". 4942 The need to trust the security of ACP/ANI operations needs to be 4943 weighed against the operational benefits of permitting this: Consider 4944 the typical example of a CPE (customer premises equipment) with no 4945 on-site network expert. User ports are in physical down state unless 4946 explicitly configured not to be. In a misconfiguration situation, 4947 the uplink connection is incorrectly plugged into such as user port. 4948 The device is disconnected from the network and therefore no 4949 diagnostics from the network side is possible anymore. 4950 Alternatively, all ports default to "admin down". The ACP (but not 4951 the Data-Plane) would still automatically form. Diagnostics from the 4952 network side is possible and operator reaction could include to 4953 either make this port the operational uplink port or to instruct re- 4954 cabling. Security wise, only ACP/ANI could be attacked, all other 4955 functions are filtered on interfaces in "admin down" state. 4957 10.3.2.2. Fast state propagation and Diagnostics 4959 "Physical down" state propagates on many interface types (e.g., 4960 Ethernet) to the other side. This can trigger fast L2/L3 protocol 4961 reaction on the other side and "admin down" would not have the same 4962 (fast) result. 4964 Bringing interfaces to "physical down" state is to the best of our 4965 knowledge always a result of operator action, but today, never the 4966 result of autonomic L2/L3 services running on the nodes. Therefore 4967 one option is to change the operator action to not rely on link-state 4968 propagation anymore. This may not be possible when both sides are 4969 under different operator control, but in that case it is unlikely 4970 that the ACP is running across the link and actually putting the 4971 interface into "physical down" state may still be a good option. 4973 Ideally, fast physical state propagation is replaced by fast software 4974 driven state propagation. For example a DULL GRASP "admin-state" 4975 objective could be used to auto configure a Bidirectional Forwarding 4976 Protocol (BFD, [RFC5880]) session between the two sides of the link 4977 that would be used to propagate the "up" vs. admin down state. 4979 Triggering physical down state may also be used as a mean of 4980 diagnosing cabling in the absence of easier methods. It is more 4981 complex than automated neighbor diagnostics because it requires 4982 coordinated remote access to both (likely) sides of a link to 4983 determine whether up/down toggling will cause the same reaction on 4984 the remote side. 4986 See Section 10.1 for a discussion about how LLDP and/or diagnostics 4987 via GRASP could be used to provide neighbor diagnostics, and 4988 therefore hopefully eliminating the need for "physical down" for 4989 neighbor diagnostics - as long as both neighbors support ACP/ANI. 4991 10.3.2.3. Low Level Link Diagnostics 4993 "Physical down" is performed to diagnose low-level interface behavior 4994 when higher layer services (e.g., IPv6) are not working. Especially 4995 Ethernet links are subject to a wide variety of possible wrong 4996 configuration/cablings if they do not support automatic selection of 4997 variable parameters such as speed (10/100/1000 Mbps), crossover 4998 (Auto-MDIX) and connector (fiber, copper - when interfaces have 4999 multiple but can only enable one at a time). The need for low level 5000 link diagnostic can therefore be minimized by using fully auto 5001 configuring links. 5003 In addition to "Physical down", low level diagnostics of Ethernet or 5004 other interfaces also involve the creation of other states on 5005 interfaces, such as physical Loopback (internal and/or external) or 5006 bringing down all packet transmissions for reflection/cable-length 5007 measurements. Any of these options would disrupt ACP as well. 5009 In cases where such low-level diagnostics of an operational link is 5010 desired but where the link could be a single point of failure for the 5011 ACP, ASA on both nodes of the link could perform a negotiated 5012 diagnostics that automatically terminates in a predetermined manner 5013 without dependence on external input ensuring the link will become 5014 operational again. 5016 10.3.2.4. Power Consumption Issues 5018 Power consumption of "physical down" interfaces, may be significantly 5019 lower than those in "admin down" state, for example on long-range 5020 fiber interfaces. Bringing up interfaces, for example to probe 5021 reachability, may also consume additional power. This can make these 5022 type of interfaces inappropriate to operate purely for the ACP when 5023 they are not currently needed for the Data-Plane. 5025 10.3.3. Interface level ACP/ANI enable 5027 The interface level configuration option "ACP enable" enables ACP 5028 operations on an interface, starting with ACP neighbor discovery via 5029 DULL GRAP. The interface level configuration option "ANI enable" on 5030 nodes supporting BRSKI and ACP starts with BRSKI pledge operations 5031 when there is no domain certificate on the node. On ACP/BRSKI nodes, 5032 "ACP enable" may not need to be supported, but only "ANI enable". 5033 Unless overridden by global configuration options (see later), "ACP/ 5034 ANI enable" will result in "down" state on an interface to behave as 5035 "admin down". 5037 10.3.4. Which interfaces to auto-enable? 5039 (Section 6.3) requires that "ACP enable" is automatically set on 5040 native interfaces, but not on non-native interfaces (reminder: a 5041 native interface is one that exists without operator configuration 5042 action such as physical interfaces in physical devices). 5044 Ideally, ACP enable is set automatically on all interfaces that 5045 provide access to additional connectivity that allows to reach more 5046 nodes of the ACP domain. The best set of interfaces necessary to 5047 achieve this is not possible to determine automatically. Native 5048 interfaces are the best automatic approximation. 5050 Consider an ACP domain of ACP nodes transitively connected via native 5051 interfaces. A Data-Plane tunnel between two of these nodes that are 5052 non-adjacent is created and "ACP enable" is set for that tunnel. ACP 5053 RPL sees this tunnel as just as a single hop. Routes in the ACP 5054 would use this hop as an attractive path element to connect regions 5055 adjacent to the tunnel nodes. In result, the actual hop-by-hop paths 5056 used by traffic in the ACP can become worse. In addition, correct 5057 forwarding in the ACP now depends on correct Data-Plane forwarding 5058 config including QoS, filtering and other security on the Data-Plane 5059 path across which this tunnel runs. This is the main issue why "ACP/ 5060 ANI enable" should not be set automatically on non-native interfaces. 5062 If the tunnel would connect two previously disjoint ACP regions, then 5063 it likely would be useful for the ACP. A Data-Plane tunnel could 5064 also run across nodes without ACP and provide additional connectivity 5065 for an already connected ACP network. The benefit of this additional 5066 ACP redundancy has to be weighed against the problems of relying on 5067 the Data-Plane. If a tunnel connects two separate ACP regions: how 5068 many tunnels should be created to connect these ACP regions reliably 5069 enough? Between which nodes? These are all standard tunneled 5070 network design questions not specific to the ACP, and there are no 5071 generic fully automated answers. 5073 Instead of automatically setting "ACP enable" on these type of 5074 interfaces, the decision needs to be based on the use purpose of the 5075 non-native interface and "ACP enable" needs to be set in conjunction 5076 with the mechanism through which the non-native interface is created/ 5077 configured. 5079 In addition to explicit setting of "ACP/ANI enable", non-native 5080 interfaces also need to support configuration of the ACP RPL cost of 5081 the link - to avoid the problems of attracting too much traffic to 5082 the link as described above. 5084 Even native interfaces may not be able to automatically perform BRSKI 5085 or ACP because they may require additional operator input to become 5086 operational. Example include DSL interfaces requiring PPPoE 5087 credentials or mobile interfaces requiring credentials from a SIM 5088 card. Whatever mechanism is used to provide the necessary config to 5089 the device to enable the interface can also be expanded to decide on 5090 whether or not to set "ACP/ANI enable". 5092 The goal of automatically setting "ACP/ANI enable" on interfaces 5093 (native or not) is to eliminate unnecessary "touches" to the node to 5094 make its operation as much as possible "zero-touch" with respect to 5095 ACP/ANI. If there are "unavoidable touches" such a creating/ 5096 configuring a non-native interface or provisioning credentials for a 5097 native interface, then "ACP/ANI enable" should be added as an option 5098 to that "touch". If a wrong "touch" is easily fixed (not creating 5099 another high-cost touch), then the default should be not to enable 5100 ANI/ACP, and if it is potentially expensive or slow to fix (e.g., 5101 parameters on SIM card shipped to remote location), then the default 5102 should be to enable ACP/ANI. 5104 10.3.5. Node Level ACP/ANI enable 5106 A node level command "ACP/ANI enable [up-if-only]" enables ACP or ANI 5107 on the node (ANI = ACP + BRSKI). Without this command set, any 5108 interface level "ACP/ANI enable" is ignored. Once set, ACP/ANI will 5109 operate an interface where "ACP/ANI enable" is set. Setting of 5110 interface level "ACP/ANI enable" is either automatic (default) or 5111 explicit through operator action as described in the previous 5112 section. 5114 If the option "up-if-only" is selected, the behavior of "down" 5115 interfaces is unchanged, and ACP/ANI will only operate on interfaces 5116 where "ACP/ANI enable" is set and that are "up". When it is not set, 5117 then "down" state of interfaces with "ACP/ANI enable" is modified to 5118 behave as "admin down". 5120 10.3.5.1. Brownfield nodes 5122 A "brownfield" node is one that already has a configured Data-Plane. 5124 Executing global "ACP/ANI enable [up-if-only]" on each node is the 5125 only command necessary to create an ACP across a network of 5126 brownfield nodes once all the nodes have a domain certificate. When 5127 BRSKI is used ("ANI enable"), provisioning of the certificates only 5128 requires set-up of a single BRSKI registrar node which could also 5129 implement a CA for the network. This is the most simple way to 5130 introduce ACP/ANI into existing (== brownfield) networks. 5132 The need to explicitly enable ACP/ANI is especially important in 5133 brownfield nodes because otherwise software updates may introduce 5134 support for ACP/ANI: Automatic enablement of ACP/ANI in networks 5135 where the operator does not only not want ACP/ANI but where the 5136 operator likely never even heard of it could be quite irritating to 5137 the operator. Especially when "down" behavior is changed to "admin 5138 down". 5140 Automatically setting "ANI enable" on brownfield nodes where the 5141 operator is unaware of BRSKI and MASA operations could also be an 5142 unlikely but then critical security issue. If an attacker could 5143 impersonate the operator and register as the operator at the MASA or 5144 otherwise get hold of vouchers and can get enough physical access to 5145 the network so pledges would register to an attacking registrar, then 5146 the attacker could gain access to the network through the ACP that 5147 the attacker then has access to. 5149 In networks where the operator explicitly wants to enable the ANI 5150 this could not happen, because the operator would create a BRSKI 5151 registrar that would discover attack attempts, and the operator would 5152 be setting up his registrar with the MASA. Nodes requiring 5153 "ownership vouchers" would not be subject to that attack. See 5154 [I-D.ietf-anima-bootstrapping-keyinfra] for more details. Note that 5155 a global "ACP enable" alone is not subject to these type of attacks, 5156 because it always depends on some other mechanism first to provision 5157 domain certificates into the device. 5159 10.3.5.2. Greenfield nodes 5161 A "greenfield" node is one that did not have any prior configuration. 5163 For greenfield nodes, only "ANI enable" is relevant. If another 5164 mechanism than BRSKI is used to (zero-touch) bootstrap a node, then 5165 it is up to that mechanism to provision domain certificates and to 5166 set global "ACP enable" as desired. 5168 Nodes supporting full ANI functionality set "ANI enable" 5169 automatically when they decide that they are greenfield, e.g., that 5170 they are powering on from factory condition. They will then put all 5171 native interfaces into "admin down" state and start to perform BRSKI 5172 pledge functionality - and once a domain certificate is enrolled they 5173 automatically enable ACP. 5175 Attempts for BRSKI pledge operations in greenfield state should 5176 terminate automatically when another method of configuring the node 5177 is used. Methods that indicate some form of physical possession of 5178 the device such as configuration via the serial console port could 5179 lead to immediate termination of BRSKI, while other parallel auto 5180 configuration methods subject to remote attacks might lead to BRSKI 5181 termination only after they were successful. Details of this may 5182 vary widely over different type of nodes. When BRSKI pledge 5183 operation terminates, this will automatically unset "ANI enable" and 5184 should terminate any temporarily needed state on the device to 5185 perform BRSKI - DULL GRASP, BRSKI pledge and any IPv6 configuration 5186 on interfaces. 5188 10.3.6. Undoing ANI/ACP enable 5190 Disabling ANI/ACP by undoing "ACP/ANI enable" is a risk for the 5191 reliable operations of the ACP if it can be executed by mistake or 5192 unauthorized. This behavior could be influenced through some 5193 additional (future) property in the certificate (e.g., in the domain 5194 information extension field): In an ANI deployment intended for 5195 convenience, disabling it could be allowed without further 5196 constraints. In an ANI deployment considered to be critical more 5197 checks would be required. One very controlled option would be to not 5198 permit these commands unless the domain certificate has been revoked 5199 or is denied renewal. Configuring this option would be a parameter 5200 on the BRSKI registrar(s). As long as the node did not receive a 5201 domain certificate, undoing "ANI/ACP enable" should not have any 5202 additional constraints. 5204 10.3.7. Summary 5206 Node-wide "ACP/ANI enable [up-if-only]" commands enable the operation 5207 of ACP/ANI. This is only auto-enabled on ANI greenfield devices, 5208 otherwise it must be configured explicitly. 5210 If the option "up-if-only" is not selected, interfaces enabled for 5211 ACP/ANI interpret "down" state as "admin down" and not "physical 5212 down". In "admin-down" all non-ACP/ANI packets are filtered, but the 5213 physical layer is kept running to permit ACP/ANI to operate. 5215 (New) commands that result in physical interruption ("physical down", 5216 "loopback") of ACP/ANI enabled interfaces should be built to protect 5217 continuance or reestablishment of ACP as much as possible. 5219 Interface level "ACP/ANI enable" control per-interface operations. 5220 It is enabled by default on native interfaces and has to be 5221 configured explicitly on other interfaces. 5223 Disabling "ACP/ANI enable" global and per-interface should have 5224 additional checks to minimize undesired breakage of ACP. The degree 5225 of control could be a domain wide parameter in the domain 5226 certificates. 5228 10.4. Configuration and the ACP (summary) 5230 There is no desirable configuration for the ACP. Instead, all 5231 parameters that need to be configured in support of the ACP are 5232 limitations of the solution, but they are only needed in cases where 5233 not all components are made autonomic. Whereever this is necessary, 5234 it relies on pre-existing mechanisms for configuration such as CLI or 5235 YANG ([RFC7950]) data models. 5237 The most important examples of such configuration include: 5239 o When ACP nodes do not support an autonomic way to receive an ACP 5240 domain certificate, for example BRSKI, then such certificate needs 5241 to be configured via some pre-existing mechanisms outside the 5242 scope of this specification. Today, router have typically a 5243 variety of mechanisms to do this. 5245 o Certificate maintenance requires PKI functions. Discovery of 5246 these functions across the ACP is automated (see Section 6.1.5), 5247 but their configuration is not. 5249 o When non-ACP capable nodes such as pre-existing NMS need to be 5250 physically connected to the ACP, the ACP node to which they attach 5251 needs to be configured with ACP-connect according to Section 8.1. 5252 It is also possible to use that single physical connection to 5253 connect both to ACP and the data-plane of the network as explained 5254 in Section 8.1.4. 5256 o When devices are not autonomically bootstrapped, explicit 5257 configuration to enable the ACP needs to be applied. See 5258 Section 10.3. 5260 o When the ACP needs to be extended across interfacess other than 5261 L2, the ACP as defined in this document can not autodiscover 5262 candidate neighbors automatically. Remote neighbors need to be 5263 configured, see Section 8.2. 5265 Once the ACP is operating, any further configuration for the data- 5266 plane can be configured more reliably across the ACP itself because 5267 the ACP provides addressing and connectivity (routing) independent of 5268 the data-plane itself. For this, the configuration methods simply 5269 need to also allow to operate across the ACP VRF - netconf, ssh or 5270 any other method. 5272 The ACP also provides additional security through its hop-by-hop 5273 encryption for any such configuration operations: Some legacy 5274 configuration methods (SNMP, TFTP, HTTP) may not use end-to-end 5275 encryption, and most of the end-to-end secured configuration methods 5276 still allow for easy passive observation along the path about 5277 configuration taking place (transport flows, port numbers, IP 5278 addresses). 5280 The ACP can and should equally be used as the transport to configure 5281 any of the aforemention non-automic components of the ACP, but in 5282 that case, the same caution needs to be exercised as with data-plane 5283 configuration without ACP: Misconfiguration may cause the configuring 5284 entity to be disconnected from the node it configures - for example 5285 when incorrectly unconfiguring a remote ACP neighbor through which 5286 the configured ACP node is reached. 5288 11. Security Considerations 5290 After seeding an ACP by configuring at least one ACP registrar with 5291 routing-subdomain and a CA, an ACP is self-protecting and there is no 5292 need to apply configuration to make it secure (typically the ACP 5293 Registrar doubles as EST server for certificate renewal). Its 5294 security therefore does not depend on configuration. This does not 5295 include workarounds for non-autonomic components as explained in 5296 Section 8. See Section 9.2 for details of how the ACP protects 5297 itself against attacks from the outside and to a more limited degree 5298 from the inside as well. 5300 However, the security of the ACP depends on a number of other 5301 factors: 5303 o The usage of domain certificates depends on a valid supporting PKI 5304 infrastructure. If the chain of trust of this PKI infrastructure 5305 is compromised, the security of the ACP is also compromised. This 5306 is typically under the control of the network administrator. 5308 o Every ACP registrar is criticial infrastructure that needs to be 5309 hardened against attacks, similar to a CA. A malicious registrar 5310 can enroll enemy plegdes to an ACP network or break ACP routing by 5311 duplicate ACP address assignment to pledges via their ACP domain 5312 certificates. 5314 o Security can be compromised by implementation errors (bugs), as in 5315 all products. 5317 There is no prevention of source-address spoofing inside the ACP. 5318 This implies that if an attacker gains access to the ACP, it can 5319 spoof all addresses inside the ACP and fake messages from any other 5320 node. 5322 The ACP is designed to enable automation of current network 5323 management and future autonomic peer-to-peer/distributed network 5324 automation. Any ACP member can send ACP IPv6 packet to other ACP 5325 members and announce via ACP GRASP services to all ACP members 5326 without depenency against centralized components. 5328 The ACP relies on peer-to-peer authentication and authorization using 5329 ACP certificates. This security model is necessary to enable the 5330 autonomic ad-hoc any-to-any connectivity between ACP nodes. It 5331 provides infrastructure protection through hop by hop authentication 5332 and encryption - without relying on third parties. For any services 5333 where this complete autonomic peer-to-peer group security model is 5334 appropriate, the ACP domain certificate can also be used unchanged. 5335 For example for any type of data-plane routing protocol security. 5337 This ACP security model is designed primarily to protect against 5338 attack from the outside, but not against attacks from the inside. To 5339 protect against spoofing attacks from compromised on-path ACP nodes, 5340 end-to-end encryption inside the ACP is used by new ACP signaling: 5341 GRASP across the ACP using TLS. The same is expected from any non- 5342 legacy services/protocols using the ACP. Because no group-keys are 5343 used, there is no risk for impacted nodes to access end-to-end 5344 encrypted traffic from other ACP nodes. 5346 Attacks from impacted ACP nodes against the ACP are more difficult 5347 than against the data-plane because of the autoconfiguration of the 5348 ACP and the absence of configuration options that could be abused 5349 that allow to change/break ACP behavior. This is excluding 5350 configuration for workaround in support of non-autonomic components. 5352 Mitigation against compromised ACP members is possible through 5353 standard automated certificate management mechanisms including 5354 revocation and non-renewal of short-lived certificates. In this 5355 version of the specification, there are no further optimization of 5356 these mechanisms defined for the ACP (but see Appendix A.10.8). 5358 Higher layer service built using ACP domain certificates should not 5359 solely rely on undifferentiated group security when another model is 5360 more appropriate/more secure. For example central network 5361 configuration relies on a security model where only few especially 5362 trusted nodes are allowed to configure the data-plane of network 5363 nodes (CLIL, Netconf). This can be done through ACP domain 5364 certificates by differentiating them and introduce roles. See 5365 Appendix A.10.5. 5367 Fundamentally, security depends on avoiding operator and network 5368 operations automation mistakes, implementation and architecture. 5369 Autonomic approaches such as the ACP largely eliminate operator 5370 mistakes and make it easier to recover from network operations 5371 mistakes. Implementation and architectural mistakes are still 5372 possible, as in all networking technologies. 5374 Many details of ACP are designed with security in mind and discussed 5375 elsewhere in the document: 5377 IPv6 addresses used by nodes in the ACP are covered as part of the 5378 node's domain certificate as described in Section 6.1.2. This allows 5379 even verification of ownership of a peer's IPv6 address when using a 5380 connection authenticated with the domain certificate. 5382 The ACP acts as a security (and transport) substrate for GRASP inside 5383 the ACP such that GRASP is not only protected by attacks from the 5384 outside, but also by attacks from compromised inside attackers - by 5385 relying not only on hop-by-hop security of ACP secure channels, but 5386 adding end-to-end security for those GRASP messages. See 5387 Section 6.8.2. 5389 ACP provides for secure, resilient zero-touch discovery of EST 5390 servers for certificate renewal. See Section 6.1.5. 5392 ACP provides extensible, auto-configuring hop-by-hop protection of 5393 the ACP infrastructure via the negotiation of hop-by-hop secure 5394 channel protocols. See Section 6.5. 5396 The ACP is designed to minimize attacks from the outside by 5397 minimizing its dependency against any non-ACP (Data-Plane) 5398 operations/configuration on a node. See also Section 6.12.2. 5400 In combination with BRSKI, ACP enables a resilient, fully zero-touch 5401 network solution for short-lived certificates that can be renewed or 5402 re-enrolled even after unintentional expiry (e.g., because of 5403 interrupted connectivity). See Appendix A.2. 5405 Because ACP secure channels can be long lived, but certificates used 5406 may be short lived, secure channels, for example built via IPsec need 5407 to be terminated when peer certificates expire. See Section 6.7.5. 5409 The ACP is designed to minimize attacks from the outside by 5410 minimizing its dependency against any non-ACP (Data-Plane) 5411 operations/configuration on a node. See also Section 6.12.2. 5413 Section 7.2 describes how to implement a routed ACP topology 5414 operating on what effectively is a large bridge-domain when using L3/ 5415 L2 routers that operate at L2 in the data-plane. In this case, the 5416 ACP is subject to much higher likelyhood of attacks by other nodes 5417 "stealing" L2 addresses than in the actual routed case. Especially 5418 when the bridged network includes non-trusted devices such as hosts. 5419 This is a generic issue in L2 LANs. L2/L3 devices often already have 5420 some form of "port security" to prohibit this. They rely on NDP or 5421 DHCP learning of which port/MAC-address and IPv6 address belong 5422 together and block MAC/IPv6 source addresses from wrong ports. This 5423 type of function needs to be enabled to prohibit DoS attacks and 5424 specifically to protect the ACP. Likewise the GRASP DULL instance 5425 needs to ensure that the IPv6 address in the locator-option matches 5426 the source IPv6 address of the DULL GRASP packet. 5428 12. IANA Considerations 5430 This document defines the "Autonomic Control Plane". 5432 The IANA is requested to register the value "AN_ACP" (without quotes) 5433 to the GRASP Objectives Names Table in the GRASP Parameter Registry. 5434 The specification for this value is this document, Section 6.3. 5436 The IANA is requested to register the value "SRV.est" (without 5437 quotes) to the GRASP Objectives Names Table in the GRASP Parameter 5438 Registry. The specification for this value is this document, 5439 Section 6.1.5. 5441 Explanation: This document chooses the initially strange looking 5442 format "SRV." because these objective names would be in 5443 line with potential future simplification of the GRASP objective 5444 registry. Today, every name in the GRASP objective registry needs to 5445 be explicitly allocated with IANA. In the future, this type of 5446 objective names could considered to be automatically registered in 5447 that registry for the same service for which is 5448 registered according to [RFC6335]. This explanation is solely 5449 informational and has no impact on the requested registration. 5451 The IANA is requested to create an ACP Parameter Registry with 5452 currently one registry table - the "ACP Address Type" table. 5454 "ACP Address Type" Table. The value in this table are numeric values 5455 0...3 paired with a name (string). Future values MUST be assigned 5456 using the Standards Action policy defined by [RFC8126]. The 5457 following initial values are assigned by this document: 5459 0: ACP Zone Addressing Sub-Scheme (ACP RFC Figure 11) / ACP Manual 5460 Addressing Sub-Scheme (ACP RFC Section 6.10.4) 5461 1: ACP Vlong Addressing Sub-Scheme (ACP RFC Section 6.10.5) 5463 13. Acknowledgements 5465 This work originated from an Autonomic Networking project at Cisco 5466 Systems, which started in early 2010. Many people contributed to 5467 this project and the idea of the Autonomic Control Plane, amongst 5468 which (in alphabetical order): Ignas Bagdonas, Parag Bhide, Balaji 5469 BL, Alex Clemm, Yves Hertoghs, Bruno Klauser, Max Pritikin, Michael 5470 Richardson, Ravi Kumar Vadapalli. 5472 Special thanks to Brian Carpenter, Elwyn Davies, Joel Halpern and 5473 Sheng Jiang for their thorough reviews and to Pascal Thubert and 5474 Michael Richardson to provide the details for the recommendations of 5475 the use of RPL in the ACP. 5477 Thanks to Valery Smyslov for review of the IPsec and IKEv2 5478 configuration parameters. 5480 Further input, review or suggestions were received from: Rene Struik, 5481 Brian Carpenter, Benoit Claise, William Atwood and Yongkang Zhang. 5483 14. Change log [RFC Editor: Please remove] 5485 14.1. Summary of changes since entering IESG review 5487 This text replaces the prior changelog with a summary to provide 5488 guidance for further IESG review. 5490 Please see revision -21 for the individual changelogs of prior 5491 versions . 5493 14.1.1. Reviews (while in IESG review status) / status 5495 This document entered IESG review with version -13. It has since 5496 seen the following reviews: 5498 IESG: Original owner/Yes: Terry Manderson (INT). 5500 IESG: No Objection: Deborah Brungard (RTG), Alissa Cooper (GEN), 5501 Warren Kumari (OPS), Mirja Kuehlewind (TSV), Alexey Melnikov (ART), 5502 Adam Roach (ART). 5504 IESG: No Objection, not counted anymore as they have left IESG: Ben 5505 Campbell (ART), Spencer Dawkins (TSV). 5507 IESG: Open DISCUSS hopefully resolved by this version: Eric Rescorla 5508 (SEC, left IESG), Benjamin Kaduk (SEC). 5510 Other: Michael Richardson (WG), Brian Carpenter (WG), Pascal Thubert 5511 (WG), Frank Xialiang (WG), Elwyn Davies (GEN), Joel Halpern (RTGdir), 5512 Yongkang Zhang (WG), William Atwood (WG). 5514 14.1.2. BRSKI / ACP registrar related enhancements 5516 Only after ACP entered IESG review did it become clear that the in- 5517 progress BRSKI document would not provide all the explanations needed 5518 for ACP registrars as expected earlier by ACP authors. Instead, 5519 BRSKI will only specify a subset of required ACP behavior related to 5520 certificate handling and registrar. There, it became clear that the 5521 ACP draft should specify generic ACP registrar behavior independent 5522 of BRSKI so ACP could be implemented with or without BRSKI and any 5523 manual/proprietary or future standardized BRSKI alternatives (for 5524 example via NetConf) would understand the requirements for ACP 5525 registrars and its certificate handling. 5527 This lead to additional text about ACP registrars in the ACP 5528 document: 5530 1. Defined relationship ACP / ANI (ANI = ACP + BRSKI). 5532 6.1.4 (new) Overview of trust points and trust anchors required for 5533 ACP. 5535 6.1.5.5 Added explanations/requirements for Re-enrolment. 5537 6.10.7 Normative requirements for ACP registrars (BRSKI or not). 5539 10.2 Operational expectations against ACP registrars (BRSKI or not). 5541 14.1.3. Normative enhancements since start of IESG review 5543 In addition to above ACP registrar / BRSKI related enhancements there 5544 is a range of minor normative (also explanatory) enhancements since 5545 the start of IESG review: 5547 6.1.1 Hex digits in ACP domain information field now upper-case (no 5548 specific reason except that both options are equally good, but 5549 capitalized ones are used in rfc5234). 5551 6.1.5.3 Added explanations about CRLs. 5553 6.1.5.6 Added explanations of behavior under failing certificates. 5555 6.1.2 Allow ACP adddress '0' in ACP domain information field: 5556 presence of address indicates permission to build ACP secure channel 5557 to node, 0 indicates that the address of the node is assigned by 5558 (future) other means than certificate. Non-autonomic nodes have no 5559 address at all (that was in -13), and can only connect via ACP 5560 connect interfaces to ACP. 5562 6.1.3 Distinction of real ACP nodes (with address) and those with 5563 domain certificate without address added as a new rule to ACP domain 5564 membership check. 5566 6.6 Added throttling of secure-channel setup attempts. 5568 6.11.1.14 Removed requirement to handle unknown destination ACP 5569 traffic in low-end nodes that would never be RPL roots. 5571 6.12.5 Added recommendation to use IPv6 DAD. 5573 6.1.1, 6.7.1.1, 6.7.2, 6.7.3, 6.8.2 Various refined additional 5574 certificate, secure channel protocol (IPsec/IKEv2 and DTLS) and ACP 5575 GRASP TLS protocol parameter requirements to ensure interoperating 5576 implementations (from SEC-AD review). 5578 14.1.4. Explanatory enhancements since start of IESG review 5580 Beyond the functional enhancements from the previous two sections, 5581 the mayority of changes since -13 are additional explanations from 5582 review feedback, textual nits and restructuring - with no functional 5583 requirement additions/changes. 5585 1.1 Added "applicability and scope" section with summarized 5586 explanations. 5588 2.Added in-band vs. out-of-band management definitions. 5590 6.1.2 (was 6.1.1) expanded explanations of reasoning for elements of 5591 the ACP domain information field. 5593 6.1.3 refined explanations of ACP domain membership check and 5594 justifications for it. 5596 6.5 Elaborated step-by-step secure channel setup. 5598 6.10 Additional explanations for addressing modes, additional table 5599 of addressing formats (thanks MichaelR). 5601 6.10.5 introduced 'F' bit position as a better visual representation 5602 in the Vlong address space. 5604 6.11.1.1 extensive overhaul to improve readability of use of RPL 5605 (from IESG feedback of non-routing/RPL experts). 5607 6.12.2 Added caution about unconfiguring data-plane IPv6 addresses 5608 and impact to ACP (limitation of current ACP design, and pointint to 5609 more details in 10.2). 5611 10.4 New explanations / summary of configurations for ACP (aka: all 5612 config is undesirable and only required for integrating with non- 5613 autonomic components, primarily ACP-connect and Registrars). 5615 11. Textually enhanced / better structured security considerations 5616 section after IESG security review. 5618 A. (new) Moved all explanations and discussions about futures from 5619 section 10 into this new appendix. This text should not be removed 5620 because it captures a lot of repeated asked questions in WG and 5621 during reviews and from users, and also captures ideas for some 5622 likely important followup work. But none of this is relevant to 5623 implementing (section 6) and operating (section 10) the ACP. 5625 14.2. draft-ietf-anima-autonomic-control-plane-23 5627 Note: big rfcdiff of TOC is an rfcdiff bug, changes really minimal. 5629 Review of IPsec security with Mcr and ipsec mailing list. 5631 6.7.1 - new section: Moved general considerations for secure channel 5632 protocols here, refined them. 5634 6.7.2 - new section: Moved common requirements for secure channel 5635 protocols here, refined them. 5637 6.7.3.1.1. - improved requirements text related to RFC8221, better 5638 explamations re. HW acceleration issues. 5640 6.7.3.1.2. - improved requirements text related to RFC8247, (some 5641 requirements still discussed to be redundant, will be finalized in 5642 next weeks. 5644 Eric Vyncke review of -21: 5646 Only noting most important changes, long list of smaller text/ 5647 readability enhancements. 5649 2. - New explanation of "normative" , "informational" section title 5650 tags. alphabetic reordering of terms, refined definitions for CA, 5651 CRL. root CA. 5653 6.1.1. - explanation when IDevID parameters may be copied into 5654 LDevID. 5656 6.1.2. - Fixed hex digits in ACP domain information to lower case. 5658 6.1.3.1. - New section on Realtime clock and Time Validation. 5660 6.3 - Added explanation that DTLS means >= version 1.2 (not only 5661 1.2). 5663 6.7 - New text in this main section explaing relationship of ACP 5664 secure channels and ACP virtual interfaces - with forward references 5665 to virtual interface section. 5667 6.8.2 - reordered text and picture, no text change. 5669 6.10.7.2 - describe first how Registrar-ID can be allocted for all 5670 type of registrars, then refined text for how to potentially use MAC 5671 addresses on physical registrars. 5673 6.11.1.1 - Added text how this profile does not use data-plane 5674 artefacts (RPI) because hadware forwarding. This was previously 5675 hidden only later in the text. 5677 6.11.1.13. - Rewrote RPL data-plane artefact text. Provide decoder 5678 ring for abbreviations and all relevant RFCs. 5680 6.12.5.2. - Added more explicit text that secure channels are mapped 5681 into virtual interfaces, moved different type of interfaces used by 5682 ACP into seperate subsections to be able to refer to them. 5684 7.2 - Rewrote/refined text for ACP on L2, prior text was confusing 5685 and did not well explain why ACP for L2/L3 switches can be 5686 implemented without any L2 (HW) changes. Also missing explanation of 5687 only running GRASP untagged when VLANs are used. 5689 8.1.1 - Added requirement for ACP Edge nodes to allow configurable 5690 filtering of IPv6 RPI headers. 5692 11. - (security section). Moved explanation of address stealing from 5693 7.2 to here. 5695 14.3. draft-ietf-anima-autonomic-control-plane-22 5697 Ben Kaduk review of -21: 5699 RFC822 encoding of ACP domain information: 5701 6.1.2 rewrote text for explaining / justifying use of rfc822name as 5702 identifier for node CP in certificate (was discussed in thread, but 5703 badly written in prior versions). 5705 6.1.2 Changed EBNF syntax to use "+" after rfcSELF because that is 5706 the known primary name to extensions separator in many email systems 5707 ("." was wrong in prior versions). 5709 6.1.2 Rewrote/improved explanations for use of rfc822name field to 5710 explain better why it is PKIX compliant and the right thing to do. 5712 Crypto parameters for IPsec: 5714 6.1 - Added explanation of why manual keying for ACP is not feasible 5715 for ACP. Surprisingly, that text did not exist. Referred to by 5716 IPsec text (6.7.1), but here is the right place to describe the 5717 reasoning. 5719 6.1.2 - Small textual refinement referring to requirements to 5720 authenticate peers (for the special cases of empty or '0' ACP address 5721 in ACP domain information field. 5723 6.3 - To better justify Bens proposed change of secure channel 5724 protocol being IPsec vs. GRASP objective being IKEv2, better 5725 explained how protocol indicated in GRASP objective-value is name of 5726 protocol used to negotiate secure channel, use example of IKEv2 to 5727 negotiate IPsec. 5729 6.7.1 - refinemenet similar to 6.3. 5731 - moved new paragraph from Bens pull request up from 6.7.1.1 to 6.7.1 5732 as it equally applies to GRE encapped IPsec (looks nicer one level 5733 up). 5735 - created subsections 6.7.1.1 (IPsec/ESP) / 6.7.1.2 (IKEv2) to 5736 clearer distinguish between these two requirements blocks. 5738 - Refined the text in these two sections to hopefully be a good 5739 answer to Valery's concern of not randomnly mocking with existing 5740 requirements docs (rfc8247 / rfc8221). 5742 6.7.1.1.1 - IPsec/ESP requirements section: 5744 - MUST support rfc8221 mandatory EXCEPT for the superceeding 5745 requirements in this section. Previously, this was not quite clear 5746 from the text. 5748 - Hopefully persuasive explanations about the requirements levels for 5749 ENCR_AES_GCM_16, ENCR_AES_CBC, ENCR_AES_CCM_8 and 5750 ENCR_CHACHA20_POLY1305: Restructured text for why not ENCR_AES_CBC 5751 (was in prior version, just not well structured), added new 5752 expanations for ENCR_AES_CCM_8 and ENCR_CHACHA20_POLY130. 5754 - In simple terms, requirements for ENCR_AES_CBC, ENCR_AES_CCM_8, 5755 ENCR_CHACHACHA are SHOULD when they are implementable with rqual or 5756 faster performancce than ENCR_AES_GCM_16. 5758 - Removed text about "additional rfc8221" reqiurements MAY be used. 5759 Now the logic is that all other requirements apply. Hopefully we 5760 have written enough so that we prohibited downgrades. 5762 6.7.1.1.2 - RFC8247 requirements: 5764 - Added mandate to support rfc8247, added explanation that there is 5765 no "stripping down" requirement, just additional stronger 5766 requirements to mandate correct use of ACP certificartes during 5767 authentication. 5769 - refined text on identifying ACP by IPv6 address to be clearer: 5770 Identifying in the context of IKEv2 and cases for '0' in ACP domain 5771 information. 5773 - removed last two paragraphs about relationship to rfc8247, as his 5774 is now written in first paragraph of the section. 5776 End of Ben Kaduk review related fixes. 5778 Other: 5780 Forgot to update example of ACP domain information to use capitalized 5781 hex-digits as required by HEXDIGIT used. 5783 Added reference to RFC8316 (AN use-cases) to beginning of section 3 5784 (ACP use cases). 5786 Small Enhanced IPsec parameters description / requirements fixes 5787 (from Michael Richardson). 5789 15. References 5791 15.1. Normative References 5793 [I-D.ietf-anima-grasp] 5794 Bormann, C., Carpenter, B., and B. Liu, "A Generic 5795 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 5796 grasp-15 (work in progress), July 2017. 5798 [IKEV2IANA] 5799 IANA, "Internet Key Exchange Version 2 (IKEv2) 5800 Parameters", . 5803 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 5804 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 5805 . 5807 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 5808 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 5809 DOI 10.17487/RFC3810, June 2004, 5810 . 5812 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 5813 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 5814 November 2005, . 5816 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 5817 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 5818 . 5820 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 5821 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 5822 2006, . 5824 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 5825 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 5826 December 2005, . 5828 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 5829 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 5830 DOI 10.17487/RFC4861, September 2007, 5831 . 5833 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 5834 Address Autoconfiguration", RFC 4862, 5835 DOI 10.17487/RFC4862, September 2007, 5836 . 5838 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 5839 Specifications: ABNF", STD 68, RFC 5234, 5840 DOI 10.17487/RFC5234, January 2008, 5841 . 5843 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 5844 (TLS) Protocol Version 1.2", RFC 5246, 5845 DOI 10.17487/RFC5246, August 2008, 5846 . 5848 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 5849 Housley, R., and W. Polk, "Internet X.509 Public Key 5850 Infrastructure Certificate and Certificate Revocation List 5851 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 5852 . 5854 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 5855 DOI 10.17487/RFC5322, October 2008, 5856 . 5858 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 5859 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 5860 January 2012, . 5862 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 5863 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 5864 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 5865 Low-Power and Lossy Networks", RFC 6550, 5866 DOI 10.17487/RFC6550, March 2012, 5867 . 5869 [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing 5870 Protocol for Low-Power and Lossy Networks (RPL)", 5871 RFC 6552, DOI 10.17487/RFC6552, March 2012, 5872 . 5874 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 5875 Power and Lossy Networks (RPL) Option for Carrying RPL 5876 Information in Data-Plane Datagrams", RFC 6553, 5877 DOI 10.17487/RFC6553, March 2012, 5878 . 5880 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 5881 "Enrollment over Secure Transport", RFC 7030, 5882 DOI 10.17487/RFC7030, October 2013, 5883 . 5885 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 5886 Kivinen, "Internet Key Exchange Protocol Version 2 5887 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 5888 2014, . 5890 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 5891 "Recommendations for Secure Use of Transport Layer 5892 Security (TLS) and Datagram Transport Layer Security 5893 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 5894 2015, . 5896 [RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support 5897 for Generic Routing Encapsulation (GRE)", RFC 7676, 5898 DOI 10.17487/RFC7676, October 2015, 5899 . 5901 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 5902 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 5903 May 2017, . 5905 [RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T. 5906 Kivinen, "Cryptographic Algorithm Implementation 5907 Requirements and Usage Guidance for Encapsulating Security 5908 Payload (ESP) and Authentication Header (AH)", RFC 8221, 5909 DOI 10.17487/RFC8221, October 2017, 5910 . 5912 [RFC8247] Nir, Y., Kivinen, T., Wouters, P., and D. Migault, 5913 "Algorithm Implementation Requirements and Usage Guidance 5914 for the Internet Key Exchange Protocol Version 2 (IKEv2)", 5915 RFC 8247, DOI 10.17487/RFC8247, September 2017, 5916 . 5918 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 5919 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 5920 . 5922 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 5923 Definition Language (CDDL): A Notational Convention to 5924 Express Concise Binary Object Representation (CBOR) and 5925 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 5926 June 2019, . 5928 15.2. Informative References 5930 [AR8021] Group, W. -. H. L. L. P. W., "IEEE Standard for Local and 5931 metropolitan area networks - Secure Device Identity", 5932 December 2009, . 5935 [CABFORUM] 5936 CA/Browser Forum, "Certificate Contents for Baseline SSL", 5937 Nov 2019, . 5940 [I-D.eckert-anima-noc-autoconfig] 5941 Eckert, T., "Autoconfiguration of NOC services in ACP 5942 networks via GRASP", draft-eckert-anima-noc-autoconfig-00 5943 (work in progress), July 2018. 5945 [I-D.ietf-acme-star] 5946 Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T. 5947 Fossati, "Support for Short-Term, Automatically-Renewed 5948 (STAR) Certificates in Automated Certificate Management 5949 Environment (ACME)", draft-ietf-acme-star-11 (work in 5950 progress), October 2019. 5952 [I-D.ietf-anima-bootstrapping-keyinfra] 5953 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 5954 and K. Watsen, "Bootstrapping Remote Secure Key 5955 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 5956 keyinfra-35 (work in progress), February 2020. 5958 [I-D.ietf-anima-prefix-management] 5959 Jiang, S., Du, Z., Carpenter, B., and Q. Sun, "Autonomic 5960 IPv6 Edge Prefix Management in Large-scale Networks", 5961 draft-ietf-anima-prefix-management-07 (work in progress), 5962 December 2017. 5964 [I-D.ietf-anima-reference-model] 5965 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 5966 and J. Nobre, "A Reference Model for Autonomic 5967 Networking", draft-ietf-anima-reference-model-10 (work in 5968 progress), November 2018. 5970 [I-D.ietf-roll-applicability-template] 5971 Richardson, M., "ROLL Applicability Statement Template", 5972 draft-ietf-roll-applicability-template-09 (work in 5973 progress), May 2016. 5975 [I-D.ietf-roll-useofrplinfo] 5976 Robles, I., Richardson, M., and P. Thubert, "Using RPI 5977 option Type, Routing Header for Source Routes and IPv6-in- 5978 IPv6 encapsulation in the RPL Data Plane", draft-ietf- 5979 roll-useofrplinfo-36 (work in progress), February 2020. 5981 [I-D.ietf-tls-dtls13] 5982 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 5983 Datagram Transport Layer Security (DTLS) Protocol Version 5984 1.3", draft-ietf-tls-dtls13-34 (work in progress), 5985 November 2019. 5987 [IEEE-1588-2008] 5988 IEEE, "IEEE Standard for a Precision Clock Synchronization 5989 Protocol for Networked Measurement and Control Systems", 5990 December 2008, . 5993 [IEEE-802.1X] 5994 Group, W. -. H. L. L. P. W., "IEEE Standard for Local and 5995 Metropolitan Area Networks: Port-Based Network Access 5996 Control", February 2010, 5997 . 6000 [LLDP] Group, W. -. H. L. L. P. W., "IEEE Standard for Local and 6001 Metropolitan Area Networks: Station and Media Access 6002 Control Connectivity Discovery", June 2016, 6003 . 6006 [MACSEC] Group, W. -. H. L. L. P. W., "IEEE Standard for Local and 6007 Metropolitan Area Networks: Media Access Control (MAC) 6008 Security", June 2006, 6009 . 6012 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 6013 RFC 1112, DOI 10.17487/RFC1112, August 1989, 6014 . 6016 [RFC1492] Finseth, C., "An Access Control Protocol, Sometimes Called 6017 TACACS", RFC 1492, DOI 10.17487/RFC1492, July 1993, 6018 . 6020 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 6021 and E. Lear, "Address Allocation for Private Internets", 6022 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 6023 . 6025 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 6026 Requirement Levels", BCP 14, RFC 2119, 6027 DOI 10.17487/RFC2119, March 1997, 6028 . 6030 [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax 6031 Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998, 6032 . 6034 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 6035 (IKE)", RFC 2409, DOI 10.17487/RFC2409, November 1998, 6036 . 6038 [RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", 6039 RFC 2821, DOI 10.17487/RFC2821, April 2001, 6040 . 6042 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 6043 "Remote Authentication Dial In User Service (RADIUS)", 6044 RFC 2865, DOI 10.17487/RFC2865, June 2000, 6045 . 6047 [RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, 6048 DOI 10.17487/RFC3164, August 2001, 6049 . 6051 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 6052 C., and M. Carney, "Dynamic Host Configuration Protocol 6053 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 6054 2003, . 6056 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 6057 Architecture for Describing Simple Network Management 6058 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 6059 DOI 10.17487/RFC3411, December 2002, 6060 . 6062 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 6063 "DNS Extensions to Support IP Version 6", STD 88, 6064 RFC 3596, DOI 10.17487/RFC3596, October 2003, 6065 . 6067 [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export 6068 Version 9", RFC 3954, DOI 10.17487/RFC3954, October 2004, 6069 . 6071 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 6072 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 6073 DOI 10.17487/RFC4007, March 2005, 6074 . 6076 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 6077 "Internet X.509 Public Key Infrastructure Certificate 6078 Management Protocol (CMP)", RFC 4210, 6079 DOI 10.17487/RFC4210, September 2005, 6080 . 6082 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 6083 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 6084 2006, . 6086 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 6087 for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, 6088 . 6090 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 6091 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 6092 for Transport Layer Security (TLS)", RFC 4492, 6093 DOI 10.17487/RFC4492, May 2006, 6094 . 6096 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 6097 "Considerations for Internet Group Management Protocol 6098 (IGMP) and Multicast Listener Discovery (MLD) Snooping 6099 Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, 6100 . 6102 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 6103 Group Management Protocol Version 3 (IGMPv3) and Multicast 6104 Listener Discovery Protocol Version 2 (MLDv2) for Source- 6105 Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, 6106 August 2006, . 6108 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 6109 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 6110 . 6112 [RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol 6113 Independent Multicast (PIM)", RFC 4610, 6114 DOI 10.17487/RFC4610, August 2006, 6115 . 6117 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 6118 Extensions for Stateless Address Autoconfiguration in 6119 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 6120 . 6122 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 6123 DOI 10.17487/RFC5321, October 2008, 6124 . 6126 [RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet 6127 Group Management Protocol Version 3 (IGMPv3) and Multicast 6128 Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, 6129 DOI 10.17487/RFC5790, February 2010, 6130 . 6132 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 6133 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 6134 . 6136 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 6137 "Network Time Protocol Version 4: Protocol and Algorithms 6138 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 6139 . 6141 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 6142 and A. Bierman, Ed., "Network Configuration Protocol 6143 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 6144 . 6146 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 6147 Cheshire, "Internet Assigned Numbers Authority (IANA) 6148 Procedures for the Management of the Service Name and 6149 Transport Protocol Port Number Registry", BCP 165, 6150 RFC 6335, DOI 10.17487/RFC6335, August 2011, 6151 . 6153 [RFC6402] Schaad, J., "Certificate Management over CMS (CMC) 6154 Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011, 6155 . 6157 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 6158 of Interpretation", RFC 6407, DOI 10.17487/RFC6407, 6159 October 2011, . 6161 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 6162 Routing Header for Source Routes with the Routing Protocol 6163 for Low-Power and Lossy Networks (RPL)", RFC 6554, 6164 DOI 10.17487/RFC6554, March 2012, 6165 . 6167 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 6168 "Default Address Selection for Internet Protocol Version 6 6169 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 6170 . 6172 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 6173 Ed., "Diameter Base Protocol", RFC 6733, 6174 DOI 10.17487/RFC6733, October 2012, 6175 . 6177 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 6178 DOI 10.17487/RFC6762, February 2013, 6179 . 6181 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 6182 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 6183 . 6185 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 6186 Locator/ID Separation Protocol (LISP)", RFC 6830, 6187 DOI 10.17487/RFC6830, January 2013, 6188 . 6190 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 6191 "Specification of the IP Flow Information Export (IPFIX) 6192 Protocol for the Exchange of Flow Information", STD 77, 6193 RFC 7011, DOI 10.17487/RFC7011, September 2013, 6194 . 6196 [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local 6197 Addressing inside an IPv6 Network", RFC 7404, 6198 DOI 10.17487/RFC7404, November 2014, 6199 . 6201 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 6202 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 6203 Defined Networking (SDN): Layers and Architecture 6204 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 6205 2015, . 6207 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 6208 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 6209 Networking: Definitions and Design Goals", RFC 7575, 6210 DOI 10.17487/RFC7575, June 2015, 6211 . 6213 [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap 6214 Analysis for Autonomic Networking", RFC 7576, 6215 DOI 10.17487/RFC7576, June 2015, 6216 . 6218 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 6219 Considerations for IPv6 Address Generation Mechanisms", 6220 RFC 7721, DOI 10.17487/RFC7721, March 2016, 6221 . 6223 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 6224 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 6225 Multicast - Sparse Mode (PIM-SM): Protocol Specification 6226 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 6227 2016, . 6229 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 6230 RFC 7950, DOI 10.17487/RFC7950, August 2016, 6231 . 6233 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 6234 Hosts in a Multi-Prefix Network", RFC 8028, 6235 DOI 10.17487/RFC8028, November 2016, 6236 . 6238 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 6239 Writing an IANA Considerations Section in RFCs", BCP 26, 6240 RFC 8126, DOI 10.17487/RFC8126, June 2017, 6241 . 6243 [RFC8316] Nobre, J., Granville, L., Clemm, A., and A. Gonzalez 6244 Prieto, "Autonomic Networking Use Case for Distributed 6245 Detection of Service Level Agreement (SLA) Violations", 6246 RFC 8316, DOI 10.17487/RFC8316, February 2018, 6247 . 6249 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 6250 "A Voucher Artifact for Bootstrapping Protocols", 6251 RFC 8366, DOI 10.17487/RFC8366, May 2018, 6252 . 6254 [RFC8368] Eckert, T., Ed. and M. Behringer, "Using an Autonomic 6255 Control Plane for Stable Connectivity of Network 6256 Operations, Administration, and Maintenance (OAM)", 6257 RFC 8368, DOI 10.17487/RFC8368, May 2018, 6258 . 6260 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 6261 Touch Provisioning (SZTP)", RFC 8572, 6262 DOI 10.17487/RFC8572, April 2019, 6263 . 6265 15.3. URIs 6267 [1] https://en.wikipedia.org/wiki/Operational_Technology 6269 [2] https://en.wikipedia.org/wiki/Single-root_input/ 6270 output_virtualization 6272 Appendix A. Background and Futures (Informative) 6274 The following sections discuss additional background information 6275 about aspects of the normative parts of this document or associated 6276 mechanisms such as BRSKI (such as why specific choices were made by 6277 the ACP) and they provide discussion about possible future variations 6278 of the ACP. 6280 A.1. ACP Address Space Schemes 6282 This document defines the Zone, Vlong and Manual sub address schemes 6283 primarily to support address prefix assignment via distributed, 6284 potentially uncoordinated ACP registrars as defined in 6285 Section 6.10.7. This costs 48/46-bit identifier so that these ACP 6286 registrar can assign non-conflicting address prefixes. This design 6287 does not leave enough bits to simultaneously support a large number 6288 of nodes (Node-ID) plus a large prefix of local addresses for every 6289 node plus a large enough set of bits to identify a routing Zone. In 6290 result, Zone, Vlong 8/16 attempt to support all features, but in via 6291 separate prefixes. 6293 In networks that always expect to rely on a centralized PMS as 6294 described above (Section 10.2.5), the 48/46-bits for the Registrar-ID 6295 could be saved. Such variations of the ACP addressing mechanisms 6296 could be introduced through future work in different ways. If the 6297 prefix rfcSELF in the ACP information field was changed, incompatible 6298 ACP variations could be created where every design aspect of the ACP 6299 could be changed. Including all addressing choices. If instead a 6300 new addressing sub-type would be defined, it could be a backward 6301 compatible extension of this ACP specification. Information such as 6302 the size of a zone-prefix and the length of the prefix assigned to 6303 the ACP node itself could be encoded via the extension field of the 6304 ACP domain information. 6306 Note that an explicitly defined "Manual" addressing sub-scheme is 6307 always beneficial to provide an easy way for ACP nodes to prohibit 6308 incorrect manual configuration of any non-"Manual" ACP address spaces 6309 and therefore ensure that "Manual" operations will never impact 6310 correct routing for any non-"Manual" ACP addresses assigned via ACP 6311 domain certificates. 6313 A.2. BRSKI Bootstrap (ANI) 6315 BRSKI describes how nodes with an IDevID certificate can securely and 6316 zero-touch enroll with an LDevID to support the ACP. BRSKI also 6317 leverages the ACP to enable zero-touch bootstrap of new nodes across 6318 networks without any configuration requirements across the transit 6319 nodes (e.g., no DHCP/DNS forwarding/server setup). This includes 6320 otherwise not configured networks as described in Section 3.2. 6321 Therefore BRSKI in conjunction with ACP provides for a secure and 6322 zero-touch management solution for complete networks. Nodes 6323 supporting such an infrastructure (BRSKI and ACP) are called ANI 6324 nodes (Autonomic Networking Infrastructure), see 6325 [I-D.ietf-anima-reference-model]. Nodes that do not support an 6326 IDevID but only an (insecure) vendor specific Unique Device 6327 Identifier (UDI) or nodes whose manufacturer does not support a MASA 6328 could use some future security reduced version of BRSKI. 6330 When BRSKI is used to provision a domain certificate (which is called 6331 enrollment), the BRSKI registrar (acting as an enhanced EST server) 6332 must include the subjectAltName / rfc822Name encoded ACP address and 6333 domain name to the enrolling node (called pledge) via its response to 6334 the pledges EST CSR Attribute request that is mandatory in BRSKI. 6336 The Certificate Authority in an ACP network must not change the 6337 subjectAltName / rfc822Name in the certificate. The ACP nodes can 6338 therefore find their ACP address and domain using this field in the 6339 domain certificate, both for themselves, as well as for other nodes. 6341 The use of BRSKI in conjunction with the ACP can also help to further 6342 simplify maintenance and renewal of domain certificates. Instead of 6343 relying on CRL, the lifetime of certificates can be made extremely 6344 small, for example in the order of hours. When a node fails to 6345 connect to the ACP within its certificate lifetime, it cannot connect 6346 to the ACP to renew its certificate across it (using just EST), but 6347 it can still renew its certificate as an "enrolled/expired pledge" 6348 via the BRSKI bootstrap proxy. This requires only that the BRSKI 6349 registrar honors expired domain certificates and that the pledge 6350 attempts to perform TLS authentication for BRSKI bootstrap using its 6351 expired domain certificate before falling back to attempting to use 6352 its IDevID for BRSKI. This mechanism could also render CRLs 6353 unnecessary because the BRSKI registrar in conjunction with the CA 6354 would not renew revoked certificates - only a "Do-not-renew" list 6355 would be necessary on BRSKI registrars/CA. 6357 In the absence of BRSKI or less secure variants thereof, provisioning 6358 of certificates may involve one or more touches or non-standardized 6359 automation. Node vendors usually support provisioning of 6360 certificates into nodes via PKCS#7 (see [RFC2315]) and may support 6361 this provisioning through vendor specific models via Netconf 6362 ([RFC6241]). If such nodes also support Netconf Zero-Touch 6363 ([RFC8572]) then this can be combined to zero-touch provisioning of 6364 domain certificates into nodes. Unless there are equivalent 6365 integration of Netconf connections across the ACP as there is in 6366 BRSKI, this combination would not support zero-touch bootstrap across 6367 a not configured network though. 6369 A.3. ACP Neighbor discovery protocol selection 6371 This section discusses why GRASP DULL was chosen as the discovery 6372 protocol for L2 adjacent candidate ACP neighbors. The contenders 6373 considered where GRASP, mDNS or LLDP. 6375 A.3.1. LLDP 6377 LLDP and Cisco's earlier Cisco Discovery Protocol (CDP) are example 6378 of L2 discovery protocols that terminate their messages on L2 ports. 6379 If those protocols would be chosen for ACP neighbor discovery, ACP 6380 neighbor discovery would therefore also terminate on L2 ports. This 6381 would prevent ACP construction over non-ACP capable but LLDP or CDP 6382 enabled L2 switches. LLDP has extensions using different MAC 6383 addresses and this could have been an option for ACP discovery as 6384 well, but the additional required IEEE standardization and definition 6385 of a profile for such a modified instance of LLDP seemed to be more 6386 work than the benefit of "reusing the existing protocol" LLDP for 6387 this very simple purpose. 6389 A.3.2. mDNS and L2 support 6391 Multicast DNNS (mDNS) [RFC6762] with DNS Service Discovery (DNS-SD) 6392 Resource Records (RRs) as defined in [RFC6763] is a key contender as 6393 an ACP discovery protocol. because it relies on link-local IP 6394 multicast, it does operates at the subnet level, and is also found in 6395 L2 switches. The authors of this document are not aware of mDNS 6396 implementation that terminate their mDNS messages on L2 ports instead 6397 of the subnet level. If mDNS was used as the ACP discovery mechanism 6398 on an ACP capable (L3)/L2 switch as outlined in Section 7, then this 6399 would be necessary to implement. It is likely that termination of 6400 mDNS messages could only be applied to all mDNS messages from such a 6401 port, which would then make it necessary to software forward any non- 6402 ACP related mDNS messages to maintain prior non-ACP mDNS 6403 functionality. Adding support for ACP into such L2 switches with 6404 mDNS could therefore create regression problems for prior mDNS 6405 functionality on those nodes. With low performance of software 6406 forwarding in many L2 switches, this could also make the ACP risky to 6407 support on such L2 switches. 6409 A.3.3. Why DULL GRASP 6411 LLDP was not considered because of the above mentioned issues. mDNS 6412 was not selected because of the above L2 mDNS considerations and 6413 because of the following additional points: 6415 If mDNS was not already existing in a node, it would be more work to 6416 implement than DULL GRASP, and if an existing implementation of mDNS 6417 was used, it would likely be more code space than a separate 6418 implementation of DULL GRASP or a shared implementation of DULL GRASP 6419 and GRASP in the ACP. 6421 A.4. Choice of routing protocol (RPL) 6423 This section motivates why RPL - "IPv6 Routing Protocol for Low-Power 6424 and Lossy Networks ([RFC6550] was chosen as the default (and in this 6425 specification only) routing protocol for the ACP. The choice and 6426 above explained profile was derived from a pre-standard 6427 implementation of ACP that was successfully deployed in operational 6428 networks. 6430 Requirements for routing in the ACP are: 6432 o Self-management: The ACP must build automatically, without human 6433 intervention. Therefore routing protocol must also work 6434 completely automatically. RPL is a simple, self-managing 6435 protocol, which does not require zones or areas; it is also self- 6436 configuring, since configuration is carried as part of the 6437 protocol (see Section 6.7.6 of [RFC6550]). 6439 o Scale: The ACP builds over an entire domain, which could be a 6440 large enterprise or service provider network. The routing 6441 protocol must therefore support domains of 100,000 nodes or more, 6442 ideally without the need for zoning or separation into areas. RPL 6443 has this scale property. This is based on extensive use of 6444 default routing. 6446 o Low resource consumption: The ACP supports traditional network 6447 infrastructure, thus runs in addition to traditional protocols. 6448 The ACP, and specifically the routing protocol must have low 6449 resource consumption both in terms of memory and CPU requirements. 6450 Specifically, at edge nodes, where memory and CPU are scarce, 6451 consumption should be minimal. RPL builds a DODAG, where the main 6452 resource consumption is at the root of the DODAG. The closer to 6453 the edge of the network, the less state needs to be maintained. 6454 This adapts nicely to the typical network design. Also, all 6455 changes below a common parent node are kept below that parent 6456 node. 6458 o Support for unstructured address space: In the Autonomic 6459 Networking Infrastructure, node addresses are identifiers, and may 6460 not be assigned in a topological way. Also, nodes may move 6461 topologically, without changing their address. Therefore, the 6462 routing protocol must support completely unstructured address 6463 space. RPL is specifically made for mobile ad-hoc networks, with 6464 no assumptions on topologically aligned addressing. 6466 o Modularity: To keep the initial implementation small, yet allow 6467 later for more complex methods, it is highly desirable that the 6468 routing protocol has a simple base functionality, but can import 6469 new functional modules if needed. RPL has this property with the 6470 concept of "objective function", which is a plugin to modify 6471 routing behavior. 6473 o Extensibility: Since the Autonomic Networking Infrastructure is a 6474 new concept, it is likely that changes in the way of operation 6475 will happen over time. RPL allows for new objective functions to 6476 be introduced later, which allow changes to the way the routing 6477 protocol creates the DAGs. 6479 o Multi-topology support: It may become necessary in the future to 6480 support more than one DODAG for different purposes, using 6481 different objective functions. RPL allow for the creation of 6482 several parallel DODAGs, should this be required. This could be 6483 used to create different topologies to reach different roots. 6485 o No need for path optimization: RPL does not necessarily compute 6486 the optimal path between any two nodes. However, the ACP does not 6487 require this today, since it carries mainly non-delay-sensitive 6488 feedback loops. It is possible that different optimization 6489 schemes become necessary in the future, but RPL can be expanded 6490 (see point "Extensibility" above). 6492 A.5. ACP Information Distribution and multicast 6494 IP multicast is not used by the ACP because the ANI (Autonomic 6495 Networking Infrastructure) itself does not require IP multicast but 6496 only service announcement/discovery. Using IP multicast for that 6497 would have made it necessary to develop a zero-touch auto configuring 6498 solution for ASM (Any Source Multicast - the original form of IP 6499 multicast defined in [RFC1112]), which would be quite complex and 6500 difficult to justify. One aspect of complexity where no attempt at a 6501 solution has been described in IETF documents is the automatic- 6502 selection of routers that should be PIM Sparse Mode (PIM-SM) 6503 Rendezvous Points (RPs) (see [RFC7761]). The other aspects of 6504 complexity are the implementation of MLD ([RFC4604]), PIM-SM and 6505 Anycast-RP (see [RFC4610]). If those implementations already exist 6506 in a product, then they would be very likely tied to accelerated 6507 forwarding which consumes hardware resources, and that in return is 6508 difficult to justify as a cost of performing only service discovery. 6510 Some future ASA may need high performance in-network data 6511 replication. That is the case when the use of IP multicast is 6512 justified. Such an ASA can then use service discovery from ACP 6513 GRASP, and then they do not need ASM but only SSM (Source Specific 6514 Multicast, see [RFC4607]) for the IP multicast replication. SSM 6515 itself can simply be enabled in the Data-Plane (or even in an update 6516 to the ACP) without any other configuration than just enabling it on 6517 all nodes and only requires a simpler version of MLD (see [RFC5790]). 6519 LSP (Link State Protocol) based IGP routing protocols typically have 6520 a mechanism to flood information, and such a mechanism could be used 6521 to flood GRASP objectives by defining them to be information of that 6522 IGP. This would be a possible optimization in future variations of 6523 the ACP that do use an LSP routing protocol. Note though that such a 6524 mechanism would not work easily for GRASP M_DISCOVERY messages which 6525 are intelligently (constrained) flooded not across the whole ACP, but 6526 only up to a node where a responder is found. We do expect that many 6527 future services in ASA will have only few consuming ASA, and for 6528 those cases, M_DISCOVERY is the more efficient method than flooding 6529 across the whole domain. 6531 Because the ACP uses RPL, one desirable future extension is to use 6532 RPLs existing notion of DODAG, which are loop-free distribution 6533 trees, to make GRASP flooding more efficient both for M_FLOOD and 6534 M_DISCOVERY. See Section 6.12.5 how this will be specifically 6535 beneficial when using NBMA interfaces. This is not currently 6536 specified in this document because it is not quite clear yet what 6537 exactly the implications are to make GRASP flooding depend on RPL 6538 DODAG convergence and how difficult it would be to let GRASP flooding 6539 access the DODAG information. 6541 A.6. Extending ACP channel negotiation (via GRASP) 6543 [RFC Editor: This section to be removed before RFC. 6545 [This section kept for informational purposes up until the last draft 6546 version as that would be the version that readers interested in the 6547 changelog would also go to to revisit it.] 6549 The mechanism described in the normative part of this document to 6550 support multiple different ACP secure channel protocols without a 6551 single network wide MTI protocol is important to allow extending 6552 secure ACP channel protocols beyond what is specified in this 6553 document, but it will run into problem if it would be used for 6554 multiple protocols: 6556 The need to potentially have multiple of these security associations 6557 even temporarily run in parallel to determine which of them works 6558 best does not support the most lightweight implementation options. 6560 The simple policy of letting one side (Alice) decide what is best may 6561 not lead to the mutual best result. 6563 The two limitations can easier be solved if the solution was more 6564 modular and as few as possible initial secure channel negotiation 6565 protocols would be used, and these protocols would then take on the 6566 responsibility to support more flexible objectives to negotiate the 6567 mutually preferred ACP security channel protocol. 6569 IKEv2 is the IETF standard protocol to negotiate network security 6570 associations. It is meant to be extensible, but it is unclear 6571 whether it would be feasible to extend IKEv2 to support possible 6572 future requirements for ACP secure channel negotiation: 6574 Consider the simple case where the use of native IPsec vs. IPsec via 6575 GRE is to be negotiated and the objective is the maximum throughput. 6576 Both sides would indicate some agreed upon performance metric and the 6577 preferred encapsulation is the one with the higher performance of the 6578 slower side. IKEv2 does not support negotiation with such 6579 objectives. 6581 Consider DTLS and some form of MacSec are to be added as negotiation 6582 options - and the performance objective should work across all IPsec, 6583 DTLS and MacSec options. In the case of MacSEC, the negotiation 6584 would also need to determine a key for the peering. It is unclear if 6585 it would be even appropriate to consider extending the scope of 6586 negotiation in IKEv2 to those cases. Even if feasible to define, it 6587 is unclear if implementations of IKEv2 would be eager to adopt those 6588 type of extension given the long cycles of security testing that 6589 necessarily goes along with core security protocols such as IKEv2 6590 implementations. 6592 A more modular alternative to extending IKEv2 could be to layer a 6593 modular negotiation mechanism on top of the multitude of existing or 6594 possible future secure channel protocols. For this, GRASP over TLS 6595 could be considered as a first ACP secure channel negotiation 6596 protocol. The following are initial considerations for such an 6597 approach. A full specification is subject to a separate document: 6599 To explicitly allow negotiation of the ACP channel protocol, GRASP 6600 over a TLS connection using the GRASP_LISTEN_PORT and the node's and 6601 peer's link-local IPv6 address is used. When Alice and Bob support 6602 GRASP negotiation, they do prefer it over any other non-explicitly 6603 negotiated security association protocol and should wait trying any 6604 non-negotiated ACP channel protocol until after it is clear that 6605 GRASP/TLS will not work to the peer. 6607 When Alice and Bob successfully establish the GRASP/TSL session, they 6608 will negotiate the channel mechanism to use using objectives such as 6609 performance and perceived quality of the security. After agreeing on 6610 a channel mechanism, Alice and Bob start the selected Channel 6611 protocol. Once the secure channel protocol is successfully running, 6612 the GRASP/TLS connection can be kept alive or timed out as long as 6613 the selected channel protocol has a secure association between Alice 6614 and Bob. When it terminates, it needs to be re-negotiated via GRASP/ 6615 TLS. 6617 Notes: 6619 o Negotiation of a channel type may require IANA assignments of code 6620 points. 6622 o TLS is subject to reset attacks, which IKEv2 is not. Normally, 6623 ACP connections (as specified in this document) will be over link- 6624 local addresses so the attack surface for this one issue in TCP 6625 should be reduced (note that this may not be true when ACP is 6626 tunneled as described in Section 8.2.2. 6628 o GRASP packets received inside a TLS connection established for 6629 GRASP/TLS ACP negotiation are assigned to a separate GRASP domain 6630 unique to that TLS connection. 6632 A.7. CAs, domains and routing subdomains 6634 There is a wide range of setting up different ACP solution by 6635 appropriately using CAs and the domain and rsub elements in the 6636 domain information field of the domain certificate. We summarize 6637 these options here as they have been explained in different parts of 6638 the document in before and discuss possible and desirable extensions: 6640 An ACP domain is the set of all ACP nodes using certificates from one 6641 or more Trust Anchors (typically one CA) using the same domain field. 6642 GRASP inside the ACP is run across all transitively connected ACP 6643 nodes in a domain. 6645 The rsub element in the domain information field permits the use of 6646 addresses from different ULA prefixes. One use case is to create 6647 multiple physical networks that initially may be separated with one 6648 ACP domain but different routing subdomains, so that all nodes can 6649 mutual trust their ACP domain certificates (not depending on rsub) 6650 and so that they could connect later together into a contiguous ACP 6651 network. 6653 One instance of such a use case is an ACP for regions interconnected 6654 via a non-ACP enabled core, for example due to the absence of product 6655 support for ACP on the core nodes. ACP connect configurations as 6656 defined in this document can be used to extend and interconnect those 6657 ACP islands to the NOC and merge them into a single ACP when later 6658 that product support gap is closed. 6660 Note that RPL scales very well. It is not necessary to use multiple 6661 routing subdomains to scale ACP domains in a way it would be possible 6662 if other routing protocols where used. They exist only as options 6663 for the above mentioned reasons. 6665 If different ACP domains are to be created that should not allow to 6666 connect to each other by default, these ACP domains simply need to 6667 have different domain elements in the domain information field. 6668 These domain elements can be arbitrary, including subdomains of one 6669 another: Domains "example.com" and "research.example.com" are 6670 separate domains if both are domain elements in the domain 6671 information element of certificates. 6673 It is not necessary to have a separate CA for different ACP domains: 6674 an operator can use a single CA to sign certificates for multiple ACP 6675 domains that are not allowed to connect to each other because the 6676 checks for ACP adjacencies includes comparison of the domain part. 6678 If multiple independent networks choose the same domain name but had 6679 their own CA, these would not form a single ACP domain because of CA 6680 mismatch. Therefore there is no problem in choosing domain names 6681 that are potentially also used by others. Nevertheless it is highly 6682 recommended to use domain names that one can have high probability to 6683 be unique. It is recommended to use domain names that start with a 6684 DNS domain names owned by the assigning organization and unique 6685 within it. For example "acp.example.com" if you own "example.com". 6687 A.8. Intent for the ACP 6689 Intent is the architecture component of autonomic networks according 6690 to [I-D.ietf-anima-reference-model] that allows operators to issue 6691 policies to the network. Its applicability for use is quite flexible 6692 and freeform, with potential applications including policies flooded 6693 across ACP GRASP and interpreted on every ACP node. 6695 One concern for future definitions of Intent solutions is the problem 6696 of circular dependencies when expressing Intent policies about the 6697 ACP itself. 6699 For example, Intent could indicate the desire to build an ACP across 6700 all domains that have a common parent domain (without relying on the 6701 rsub/routing-subdomain solution defined in this document). For 6702 example ACP nodes with domain "example.com", "access.example.com", 6703 "core.example.com" and "city.core.example.com" should all establish 6704 one single ACP. 6706 If each domain has its own source of Intent, then the Intent would 6707 simply have to allow adding the peer domains TA and domain names to 6708 the parameters for the ACP domain membership check (Section 6.1.3) so 6709 that nodes from those other domains are accepted as ACP peers. 6711 If this Intent was to be originated only from one domain, it could 6712 likely not be made to work because the other domains will not build 6713 any ACP connection amongst each other, whether they use the same or 6714 different CA due to the ACP domain membership check. 6716 If the domains use the same CA one could change the ACP setup to 6717 permit for the ACP to be established between two ACP nodes with 6718 different acp-domain-names, but only for the purpose of disseminating 6719 limited information, such as Intent, but not to set up full ACP 6720 connectivity, specifically not RPL routing and passing of arbitrary 6721 GRASP information. Unless the Intent policies permit this to happen 6722 across domain boundaries. 6724 This type of approach where the ACP first allows Intent to operate 6725 and only then sets up the rest of ACP connectivity based on Intent 6726 policy could also be used to enable Intent policies that would limit 6727 functionality across the ACP inside a domain, as long as no policy 6728 would disturb the distribution of Intent. For example to limit 6729 reachability across the ACP to certain type of nodes or locations of 6730 nodes. 6732 A.9. Adopting ACP concepts for other environments 6734 The ACP as specified in this document is very explicit about the 6735 choice of options to allow interoperable implementations. The 6736 choices made may not be the best for all environments, but the 6737 concepts used by the ACP can be used to build derived solutions: 6739 The ACP specifies the use of ULA and deriving its prefix from the 6740 domain name so that no address allocation is required to deploy the 6741 ACP. The ACP will equally work not using ULA but any other /48 IPv6 6742 prefix. This prefix could simply be a configuration of the ACP 6743 registrars (for example when using BRSKI) to enroll the domain 6744 certificates - instead of the ACP registrar deriving the /48 ULA 6745 prefix from the AN domain name. 6747 Some solutions may already have an auto-addressing scheme, for 6748 example derived from existing unique device identifiers (e.g., MAC 6749 addresses). In those cases it may not be desirable to assign 6750 addresses to devices via the ACP address information field in the way 6751 described in this document. The certificate may simply serve to 6752 identify the ACP domain, and the address field could be empty/unused. 6753 The only fix required in the remaining way the ACP operate is to 6754 define another element in the domain certificate for the two peers to 6755 decide who is Alice and who is Bob during secure channel building. 6756 Note though that future work may leverage the acp address to 6757 authenticate "ownership" of the address by the device. If the 6758 address used by a device is derived from some pre-existing permanent 6759 local ID (such as MAC address), then it would be useful to store that 6760 address in the certificate using the format of the access address 6761 information field or in a similar way. 6763 The ACP is defined as a separate VRF because it intends to support 6764 well managed networks with a wide variety of configurations. 6765 Therefore, reliable, configuration-indestructible connectivity cannot 6766 be achieved from the Data-Plane itself. In solutions where all 6767 transit connectivity impacting functions are fully automated 6768 (including security), indestructible and resilient, it would be 6769 possible to eliminate the need for the ACP to be a separate VRF. 6770 Consider the most simple example system in which there is no separate 6771 Data-Plane, but the ACP is the Data-Plane. Add BRSKI, and it becomes 6772 a fully autonomic network - except that it does not support automatic 6773 addressing for user equipment. This gap can then be closed for 6774 example by adding a solution derived from 6775 [I-D.ietf-anima-prefix-management]. 6777 TCP/TLS as the protocols to provide reliability and security to GRASP 6778 in the ACP may not be the preferred choice in constrained networks. 6779 For example, CoAP/DTLS (Constrained Application Protocol) may be 6780 preferred where they are already used, allowing to reduce the 6781 additional code space footprint for the ACP on those devices. Hop- 6782 by-hop reliability for ACP GRASP messages could be made to support 6783 protocols like DTLS by adding the same type of negotiation as defined 6784 in this document for ACP secure channel protocol negotiation. End- 6785 to-end GRASP connections can be made to select their transport 6786 protocol in future extensions of the ACP meant to better support 6787 constrained devices by indicating the supported transport protocols 6788 (e.g.: TLS/DTLS) via GRASP parameters of the GRASP objective through 6789 which the transport endpoint is discovered. 6791 The routing protocol RPL used for the ACP does explicitly not 6792 optimize for shortest paths and fastest convergence. Variations of 6793 the ACP may want to use a different routing protocol or introduce 6794 more advanced RPL profiles. 6796 Variations such as what routing protocol to use, or whether to 6797 instantiate an ACP in a VRF or (as suggested above) as the actual 6798 Data-Plane, can be automatically chosen in implementations built to 6799 support multiple options by deriving them from future parameters in 6800 the certificate. Parameters in certificates should be limited to 6801 those that would not need to be changed more often than certificates 6802 would need to be updated anyhow; Or by ensuring that these parameters 6803 can be provisioned before the variation of an ACP is activated in a 6804 node. Using BRSKI, this could be done for example as additional 6805 follow-up signaling directly after the certificate enrollment, still 6806 leveraging the BRSKI TLS connection and therefore not introducing any 6807 additional connectivity requirements. 6809 Last but not least, secure channel protocols including their 6810 encapsulations are easily added to ACP solutions. ACP hop-by-hop 6811 network layer secure channels could also be replaced by end-to-end 6812 security plus other means for infrastructure protection. Any future 6813 network OAM should always use end-to-end security anyhow and can 6814 leverage the domain certificates and is therefore not dependent on 6815 security to be provided for by ACP secure channels. 6817 A.10. Further (future) options 6819 A.10.1. Auto-aggregation of routes 6821 Routing in the ACP according to this specification only leverages the 6822 standard RPL mechanism of route optimization, e.g. keeping only 6823 routes that are not towards the RPL root. This is known to scale to 6824 networks with 20,000 or more nodes. There is no auto-aggregation of 6825 routes for /48 ULA prefixes (when using rsub in the domain 6826 information field) and/or Zone-ID based prefixes. 6828 Automatic assignment of Zone-ID and auto-aggregation of routes could 6829 be achieved for example by configuring zone-boundaries, announcing 6830 via GRASP into the zones the zone parameters (zone-ID and /48 ULA 6831 prefix) and auto-aggegating routes on the zone-boundaries. Nodes 6832 would assign their Zone-ID and potentially even /48 prefix based on 6833 the GRASP announcements. 6835 A.10.2. More options for avoiding IPv6 Data-Plane dependency 6837 As described in Section 6.12.2, the ACP depends on the Data-Plane to 6838 establish IPv6 link-local addressing on interfaces. Using a separate 6839 MAC address for the ACP allows to fully isolate the ACP from the 6840 data-plane in a way that is compatible with this specification. It 6841 is also an ideal option when using Single-root input/output 6842 virtualization (SR-IOV - see https://en.wikipedia.org/wiki/Single- 6843 root_input/output_virtualization [2]) in an implementation to isolate 6844 the ACP because different SR-IOV interfaces use different MAC 6845 addresses. 6847 When additional MAC address(es) are not available, separation of the 6848 ACP could be done at different demux points. The same subnet 6849 interface could have a separate IPv6 interface for the ACP and Data- 6850 Plane and therefore separate link-local addresses for both, where the 6851 ACP interface is non-configurable on the Data-Plane. This too would 6852 be compatible with this specification and not impact 6853 interoperability. 6855 An option that would require additional specification is to use a 6856 different Ethertype from 0x86DD (IPv6) to encapsulate IPv6 packets 6857 for the ACP. This would be a similar approach as used for IP 6858 authentication packets in [IEEE-802.1X] which use the Extensible 6859 Authentication Protocol over Local Area Network (EAPoL) ethertype 6860 (0x88A2). 6862 Note that in the case of ANI nodes, all the above considerations 6863 equally apply to the encapsulation of BRSKI packets including GRASP 6864 used for BRSKI. 6866 A.10.3. ACP APIs and operational models (YANG) 6868 Future work should define YANG ([RFC7950]) data model and/or node 6869 internal APIs to monitor and manage the ACP. 6871 Support for the ACP Adjacency Table (Section 6.2) and ACP GRASP need 6872 to be included into such model/API. 6874 A.10.4. RPL enhancements 6876 ..... USA ...... ..... Europe ...... 6878 NOC1 NOC2 6879 | | 6880 | metric 100 | 6881 ACP1 --------------------------- ACP2 . 6882 | | . WAN 6883 | metric 10 metric 20 | . Core 6884 | | . 6885 ACP3 --------------------------- ACP4 . 6886 | metric 100 | 6887 | | . 6888 | | . Sites 6889 ACP10 ACP11 . 6891 Figure 18: Dual NOC 6893 The profile for RPL specified in this document builds only one 6894 spanning-tree path set to a root, typically a registrar in one NOC. 6895 In the presence of multiple NOCs, routing toward the non-root NOCs 6896 may be suboptimal. Figure 18 shows an extreme example. Assuming 6897 that node ACP1 becomes the RPL root, traffic between ACP11 and NOC2 6898 will pass through ACP4-ACP3-ACP1-ACP2 instead of ACP4-ACP2 because 6899 the RPL calculated DODAG/routes are shortest paths towards the RPL 6900 root. 6902 To overcome these limitations, extensions/modifications to the RPL 6903 profile can provide optimality for multiple NOCs. This requires 6904 utilizing Data-Plane artifact including IPinIP encap/decap on ACP 6905 routers and processing of IPv6 RPI headers. Alternatively, (Src,Dst) 6906 routing table entries could be used. 6908 Flooding of ACP GRASP messages can be further constrained and 6909 therefore optimized by flooding only via links that are part of the 6910 RPL DODAG. 6912 A.10.5. Role assignments 6914 ACP connect is an explicit mechanism to "leak" ACP traffic explicitly 6915 (for example in a NOC). It is therefore also a possible security gap 6916 when it is easy to enable ACP connect on arbitrary compromised ACP 6917 nodes. 6919 One simple solution is to define an extension in the ACP certificates 6920 ACP information field indicating the permission for ACP connect to be 6921 configured on that ACP node. This could similarly be done to decide 6922 whether a node is permitted to be a registrar or not. 6924 Tying the permitted "roles" of an ACP node to the ACP domain 6925 certificate provides fairly strong protection against 6926 misconfiguration, but is still subject to code modifications. 6928 Another interesting role to assign to certificates is that of a NOC 6929 node. This would allow to limit certain type of connections such as 6930 OAM TLS connections to only NOC initiator or responders. 6932 A.10.6. Autonomic L3 transit 6934 In this specification, the ACP can only establish autonomic 6935 connectivity across L2 hops and only explicitly configured options to 6936 tunnel across L3. Future work should specify mechanisms to 6937 automatically tunnel ACP across L3 networks. A hub&spoke option 6938 would allow to tunnel across the Internet to a cloud or central 6939 instance of the ACP, a peer-to-peer tunneling mechanism could tunnel 6940 ACP islands across an L3VPN infrastructure. 6942 A.10.7. Diagnostics 6944 Section 10.1 describes diagnostics options that can be done without 6945 changing the external, interoperability affecting characteristics of 6946 ACP implementations. 6948 Even better diagnostics of ACP operations is possible with additional 6949 signaling extensions, such as: 6951 1. Consider if LLDP should be a recommended functionality for ANI 6952 devices to improve diagnostics, and if so, which information 6953 elements it should signal (noting that such information is 6954 conveyed in an insecure manner). Includes potentially new 6955 information elements. 6957 2. In alternative to LLDP, A DULL GRASP diagnostics objective could 6958 be defined to carry these information elements. 6960 3. The IDevID of BRSKI pledges should be included in the selected 6961 insecure diagnostics option. This may be undesirable when 6962 exposure of device information is seen as too much of a security 6963 issue (ability to deduce possible attack vectors from device 6964 model for example). 6966 4. A richer set of diagnostics information should be made available 6967 via the secured ACP channels, using either single-hop GRASP or 6968 network wide "topology discovery" mechanisms. 6970 A.10.8. Avoiding and dealing with compromised ACP nodes 6972 Compromised ACP nodes pose the biggest risk to the operations of the 6973 network. The most common type of compromise is leakage of 6974 credentials to manage/configure the device and the application of 6975 malicious configuration including the change of access credentials, 6976 but not the change of software. Most of todays networking equipment 6977 should have secure boot/software infrastructure anyhow, so attacks 6978 that introduce malicious software should be a lot harder. 6980 The most important aspect of security design against these type of 6981 attacks is to eliminate password based configuration access methods 6982 and instead rely on certificate based credentials handed out only to 6983 nodes where it is clear that the private keys can not leak. This 6984 limits unexpected propagation of credentials. 6986 If password based credentials to configure devices still need to be 6987 supported, they must not be locally configurable, but only be 6988 remotely provisioned or verified (through protocols like Radius or 6989 Diameter), and there must be no local configuration permitting to 6990 change these authentication mechanisms, but ideally they should be 6991 autoconfiguring across the ACP. See 6992 [I-D.eckert-anima-noc-autoconfig]. 6994 Without physical access to the compromised device, attackers with 6995 access to configuration should not be able to break the ACP 6996 connectivity, even when they can break or otherwise manipulate 6997 (spoof) the data-plane connectivity through configuration. To 6998 achieve this, it is necessary to avoid providing configuration 6999 options for the ACP, such as enabling/disabling it on interfaces. 7000 For example there could be an ACP configuration that locks down the 7001 current ACP config unless factory reseet is done. 7003 With such means, the valid administration has the best chances to 7004 maintain access to ACP nodes, discover malicious configuration though 7005 ongoing configuration tracking from central locations for example, 7006 and to react accordingly. 7008 The primary reaction is withdrawal/change of credentials, terminate 7009 malicious existing management sessions and fixing the configuration. 7010 Ensuring that management sessions using invalidated credentials are 7011 terminated automatically without recourse will likely require new 7012 work. 7014 Only when these steps are not feasible would it be necessary to 7015 revoke or expire the ACP domain certificate credentials and consider 7016 the node kicked off the network - until the situation can be further 7017 rectified, likely requiring direct physical access to the node. 7019 Without extensions, compromised ACP nodes can only be removed from 7020 the ACP at the speed of CRL/OCSP information refresh or expiry (and 7021 non-removal) of short lived certificates. Future extensions to the 7022 ACP could for example use GRASP flooding distribution of triggered 7023 updates of CRL/OCSP or explicit removal indication of the compromised 7024 nodes domain certificate. 7026 Authors' Addresses 7028 Toerless Eckert (editor) 7029 Futurewei Technologies Inc. USA 7030 2330 Central Expy 7031 Santa Clara 95050 7032 USA 7034 Email: tte+ietf@cs.fau.de 7036 Michael H. Behringer (editor) 7038 Email: michael.h.behringer@gmail.com 7040 Steinthor Bjarnason 7041 Arbor Networks 7042 2727 South State Street, Suite 200 7043 Ann Arbor MI 48104 7044 United States 7046 Email: sbjarnason@arbor.net