idnits 2.17.1 draft-ietf-anima-autonomic-control-plane-30.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 29 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with non-RFC3849-compliant IPv6 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 1226 has weird spacing: '...address of f...' == Line 2764 has weird spacing: '...k-local unic...' == Line 2765 has weird spacing: '...lticast messa...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (30 October 2020) is 1272 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 508, but not defined -- Looks like a reference, but probably isn't: '1' on line 2183 -- Looks like a reference, but probably isn't: '2' on line 2203 -- Looks like a reference, but probably isn't: '3' on line 2185 -- Looks like a reference, but probably isn't: '5' on line 2191 -- Looks like a reference, but probably isn't: '9' on line 2202 -- Looks like a reference, but probably isn't: '13' on line 2220 == Missing Reference: 'ACP VRF' is mentioned on line 4145, but not defined == Missing Reference: 'Data-Plane' is mentioned on line 4147, but not defined == Missing Reference: 'Select' is mentioned on line 4331, but not defined == Missing Reference: 'Plane' is mentioned on line 4333, but not defined == Missing Reference: 'BCP201' is mentioned on line 8120, but not defined == Unused Reference: 'RFC1034' is defined on line 6868, but no explicit reference was found in the text == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-43 -- 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 (-43) exists of draft-ietf-tls-dtls13-38 -- Obsolete informational reference (is this intentional?): RFC 1654 (Obsoleted by RFC 1771) -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- 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 3920 (Obsoleted by RFC 6120) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 3 errors (**), 0 flaws (~~), 16 warnings (==), 16 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: 3 May 2021 6 S. Bjarnason 7 Arbor Networks 8 30 October 2020 10 An Autonomic Control Plane (ACP) 11 draft-ietf-anima-autonomic-control-plane-30 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 3 May 2021. 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 (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Simplified BSD License text 55 as described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction (Informative) . . . . . . . . . . . . . . . . . 6 61 1.1. Applicability and Scope . . . . . . . . . . . . . . . . . 9 62 2. Acronyms and Terminology (Informative) . . . . . . . . . . . 11 63 3. Use Cases for an Autonomic Control Plane (Informative) . . . 16 64 3.1. An Infrastructure for Autonomic Functions . . . . . . . . 17 65 3.2. Secure Bootstrap over a not configured Network . . . . . 17 66 3.3. Data-Plane Independent Permanent Reachability . . . . . . 17 67 4. Requirements (Informative) . . . . . . . . . . . . . . . . . 19 68 5. Overview (Informative) . . . . . . . . . . . . . . . . . . . 20 69 6. Self-Creation of an Autonomic Control Plane (ACP) 70 (Normative) . . . . . . . . . . . . . . . . . . . . . . . 21 71 6.1. Requirements for use of Transport Layer Security (TLS) . 22 72 6.2. ACP Domain, Certificate and Network . . . . . . . . . . . 23 73 6.2.1. ACP Certificates . . . . . . . . . . . . . . . . . . 24 74 6.2.2. ACP Certificate AcpNodeName . . . . . . . . . . . . . 26 75 6.2.2.1. AcpNodeName ASN.1 Module . . . . . . . . . . . . 29 76 6.2.3. ACP domain membership check . . . . . . . . . . . . . 30 77 6.2.3.1. Realtime clock and Time Validation . . . . . . . 33 78 6.2.4. Trust Anchors (TA) . . . . . . . . . . . . . . . . . 33 79 6.2.5. Certificate and Trust Anchor Maintenance . . . . . . 34 80 6.2.5.1. GRASP objective for EST server . . . . . . . . . 35 81 6.2.5.2. Renewal . . . . . . . . . . . . . . . . . . . . . 37 82 6.2.5.3. Certificate Revocation Lists (CRLs) . . . . . . . 37 83 6.2.5.4. Lifetimes . . . . . . . . . . . . . . . . . . . . 38 84 6.2.5.5. Re-enrollment . . . . . . . . . . . . . . . . . . 38 85 6.2.5.6. Failing Certificates . . . . . . . . . . . . . . 40 86 6.3. ACP Adjacency Table . . . . . . . . . . . . . . . . . . . 41 87 6.4. Neighbor Discovery with DULL GRASP . . . . . . . . . . . 41 88 6.5. Candidate ACP Neighbor Selection . . . . . . . . . . . . 45 89 6.6. Channel Selection . . . . . . . . . . . . . . . . . . . . 45 90 6.7. Candidate ACP Neighbor verification . . . . . . . . . . . 49 91 6.8. Security Association (Secure Channel) protocols . . . . . 49 92 6.8.1. General considerations . . . . . . . . . . . . . . . 50 93 6.8.2. Common requirements . . . . . . . . . . . . . . . . . 51 94 6.8.3. ACP via IPsec . . . . . . . . . . . . . . . . . . . . 52 95 6.8.3.1. Native IPsec . . . . . . . . . . . . . . . . . . 52 96 6.8.3.1.1. RFC8221 (IPsec/ESP) . . . . . . . . . . . . . 53 97 6.8.3.1.2. RFC8247 (IKEv2) . . . . . . . . . . . . . . . 54 98 6.8.3.2. IPsec with GRE encapsulation . . . . . . . . . . 55 99 6.8.4. ACP via DTLS . . . . . . . . . . . . . . . . . . . . 56 100 6.8.5. ACP Secure Channel Profiles . . . . . . . . . . . . . 58 101 6.9. GRASP in the ACP . . . . . . . . . . . . . . . . . . . . 59 102 6.9.1. GRASP as a core service of the ACP . . . . . . . . . 59 103 6.9.2. ACP as the Security and Transport substrate for 104 GRASP . . . . . . . . . . . . . . . . . . . . . . . . 59 105 6.9.2.1. Discussion . . . . . . . . . . . . . . . . . . . 62 106 6.10. Context Separation . . . . . . . . . . . . . . . . . . . 63 107 6.11. Addressing inside the ACP . . . . . . . . . . . . . . . . 63 108 6.11.1. Fundamental Concepts of Autonomic Addressing . . . . 63 109 6.11.2. The ACP Addressing Base Scheme . . . . . . . . . . . 65 110 6.11.3. ACP Zone Addressing Sub-Scheme (ACP-Zone) . . . . . 67 111 6.11.4. ACP Manual Addressing Sub-Scheme (ACP-Manual) . . . 68 112 6.11.5. ACP Vlong Addressing Sub-Scheme (ACP-VLong-8/ 113 ACP-VLong-16 . . . . . . . . . . . . . . . . . . . . 69 114 6.11.6. Other ACP Addressing Sub-Schemes . . . . . . . . . . 70 115 6.11.7. ACP Registrars . . . . . . . . . . . . . . . . . . . 71 116 6.11.7.1. Use of BRSKI or other Mechanism/Protocols . . . 71 117 6.11.7.2. Unique Address/Prefix allocation . . . . . . . . 72 118 6.11.7.3. Addressing Sub-Scheme Policies . . . . . . . . . 72 119 6.11.7.4. Address/Prefix Persistence . . . . . . . . . . . 74 120 6.11.7.5. Further Details . . . . . . . . . . . . . . . . 74 121 6.12. Routing in the ACP . . . . . . . . . . . . . . . . . . . 74 122 6.12.1. ACP RPL Profile . . . . . . . . . . . . . . . . . . 75 123 6.12.1.1. Overview . . . . . . . . . . . . . . . . . . . . 75 124 6.12.1.1.1. Single Instance . . . . . . . . . . . . . . 75 125 6.12.1.1.2. Reconvergence . . . . . . . . . . . . . . . 76 126 6.12.1.2. RPL Instances . . . . . . . . . . . . . . . . . 77 127 6.12.1.3. Storing vs. Non-Storing Mode . . . . . . . . . . 77 128 6.12.1.4. DAO Policy . . . . . . . . . . . . . . . . . . . 77 129 6.12.1.5. Path Metric . . . . . . . . . . . . . . . . . . 77 130 6.12.1.6. Objective Function . . . . . . . . . . . . . . . 77 131 6.12.1.7. DODAG Repair . . . . . . . . . . . . . . . . . . 77 132 6.12.1.8. Multicast . . . . . . . . . . . . . . . . . . . 78 133 6.12.1.9. Security . . . . . . . . . . . . . . . . . . . . 78 134 6.12.1.10. P2P communications . . . . . . . . . . . . . . . 78 135 6.12.1.11. IPv6 address configuration . . . . . . . . . . . 78 136 6.12.1.12. Administrative parameters . . . . . . . . . . . 79 137 6.12.1.13. RPL Packet Information . . . . . . . . . . . . . 79 138 6.12.1.14. Unknown Destinations . . . . . . . . . . . . . . 79 139 6.13. General ACP Considerations . . . . . . . . . . . . . . . 80 140 6.13.1. Performance . . . . . . . . . . . . . . . . . . . . 80 141 6.13.2. Addressing of Secure Channels . . . . . . . . . . . 80 142 6.13.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . 81 143 6.13.4. Multiple links between nodes . . . . . . . . . . . . 81 144 6.13.5. ACP interfaces . . . . . . . . . . . . . . . . . . . 82 145 6.13.5.1. ACP loopback interfaces . . . . . . . . . . . . 82 146 6.13.5.2. ACP virtual interfaces . . . . . . . . . . . . . 84 147 6.13.5.2.1. ACP point-to-point virtual interfaces . . . 84 148 6.13.5.2.2. ACP multi-access virtual interfaces . . . . 84 149 7. ACP support on L2 switches/ports (Normative) . . . . . . . . 87 150 7.1. Why (Benefits of ACP on L2 switches) . . . . . . . . . . 87 151 7.2. How (per L2 port DULL GRASP) . . . . . . . . . . . . . . 88 152 8. Support for Non-ACP Components (Normative) . . . . . . . . . 89 153 8.1. ACP Connect . . . . . . . . . . . . . . . . . . . . . . . 89 154 8.1.1. Non-ACP Controller / NMS system . . . . . . . . . . . 90 155 8.1.2. Software Components . . . . . . . . . . . . . . . . . 92 156 8.1.3. Auto Configuration . . . . . . . . . . . . . . . . . 93 157 8.1.4. Combined ACP/Data-Plane Interface (VRF Select) . . . 94 158 8.1.5. Use of GRASP . . . . . . . . . . . . . . . . . . . . 96 159 8.2. Connecting ACP islands over Non-ACP L3 networks (Remote ACP 160 neighbors) . . . . . . . . . . . . . . . . . . . . . . . 97 161 8.2.1. Configured Remote ACP neighbor . . . . . . . . . . . 97 162 8.2.2. Tunneled Remote ACP Neighbor . . . . . . . . . . . . 98 163 8.2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 98 164 9. ACP Operations (Informative) . . . . . . . . . . . . . . . . 99 165 9.1. ACP (and BRSKI) Diagnostics . . . . . . . . . . . . . . . 99 166 9.1.1. Secure Channel Peer diagnostics . . . . . . . . . . . 103 167 9.2. ACP Registrars . . . . . . . . . . . . . . . . . . . . . 104 168 9.2.1. Registrar interactions . . . . . . . . . . . . . . . 104 169 9.2.2. Registrar Parameter . . . . . . . . . . . . . . . . . 105 170 9.2.3. Certificate renewal and limitations . . . . . . . . . 106 171 9.2.4. ACP Registrars with sub-CA . . . . . . . . . . . . . 107 172 9.2.5. Centralized Policy Control . . . . . . . . . . . . . 107 173 9.3. Enabling and disabling ACP/ANI . . . . . . . . . . . . . 108 174 9.3.1. Filtering for non-ACP/ANI packets . . . . . . . . . . 108 175 9.3.2. Admin Down State . . . . . . . . . . . . . . . . . . 109 176 9.3.2.1. Security . . . . . . . . . . . . . . . . . . . . 110 177 9.3.2.2. Fast state propagation and Diagnostics . . . . . 110 178 9.3.2.3. Low Level Link Diagnostics . . . . . . . . . . . 111 179 9.3.2.4. Power Consumption Issues . . . . . . . . . . . . 112 180 9.3.3. Interface level ACP/ANI enable . . . . . . . . . . . 112 181 9.3.4. Which interfaces to auto-enable? . . . . . . . . . . 112 182 9.3.5. Node Level ACP/ANI enable . . . . . . . . . . . . . . 114 183 9.3.5.1. Brownfield nodes . . . . . . . . . . . . . . . . 114 184 9.3.5.2. Greenfield nodes . . . . . . . . . . . . . . . . 115 185 9.3.6. Undoing ANI/ACP enable . . . . . . . . . . . . . . . 116 186 9.3.7. Summary . . . . . . . . . . . . . . . . . . . . . . . 117 187 9.4. Partial or Incremental adoption . . . . . . . . . . . . . 117 188 9.5. Configuration and the ACP (summary) . . . . . . . . . . . 118 189 10. Summary: Benefits (Informative) . . . . . . . . . . . . . . . 119 190 10.1. Self-Healing Properties . . . . . . . . . . . . . . . . 119 191 10.2. Self-Protection Properties . . . . . . . . . . . . . . . 121 192 10.2.1. From the outside . . . . . . . . . . . . . . . . . . 121 193 10.2.2. From the inside . . . . . . . . . . . . . . . . . . 122 194 10.3. The Administrator View . . . . . . . . . . . . . . . . . 123 195 11. Security Considerations . . . . . . . . . . . . . . . . . . . 124 196 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 129 197 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 130 198 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 130 199 15. Change log [RFC-Editor: Please remove] . . . . . . . . . . . 131 200 15.1. Summary of changes since entering IESG review . . . . . 131 201 15.1.1. Reviews (while in IESG review status) / status . . . 131 202 15.1.2. BRSKI / ACP registrar related enhancements . . . . . 132 203 15.1.3. Normative enhancements since start of IESG review . 132 204 15.1.4. Explanatory enhancements since start of IESG 205 review . . . . . . . . . . . . . . . . . . . . . . . 133 206 15.2. draft-ietf-anima-autonomic-control-plane-30 . . . . . . 134 207 15.3. draft-ietf-anima-autonomic-control-plane-29 . . . . . . 136 208 15.4. draft-ietf-anima-autonomic-control-plane-28 . . . . . . 138 209 15.5. draft-ietf-anima-autonomic-control-plane-27 . . . . . . 140 210 15.6. draft-ietf-anima-autonomic-control-plane-26 . . . . . . 140 211 15.7. draft-ietf-anima-autonomic-control-plane-25 . . . . . . 141 212 15.8. draft-ietf-anima-autonomic-control-plane-24 . . . . . . 144 213 15.9. draft-ietf-anima-autonomic-control-plane-23 . . . . . . 145 214 15.10. draft-ietf-anima-autonomic-control-plane-22 . . . . . . 146 215 16. Normative References . . . . . . . . . . . . . . . . . . . . 148 216 17. Informative References . . . . . . . . . . . . . . . . . . . 151 217 Appendix A. Background and Futures (Informative) . . . . . . . . 160 218 A.1. ACP Address Space Schemes . . . . . . . . . . . . . . . . 160 219 A.2. BRSKI Bootstrap (ANI) . . . . . . . . . . . . . . . . . . 161 220 A.3. ACP Neighbor discovery protocol selection . . . . . . . . 162 221 A.3.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 162 222 A.3.2. mDNS and L2 support . . . . . . . . . . . . . . . . . 163 223 A.3.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 163 224 A.4. Choice of routing protocol (RPL) . . . . . . . . . . . . 163 225 A.5. ACP Information Distribution and multicast . . . . . . . 165 226 A.6. CAs, domains and routing subdomains . . . . . . . . . . . 166 227 A.7. Intent for the ACP . . . . . . . . . . . . . . . . . . . 167 228 A.8. Adopting ACP concepts for other environments . . . . . . 168 229 A.9. Further (future) options . . . . . . . . . . . . . . . . 170 230 A.9.1. Auto-aggregation of routes . . . . . . . . . . . . . 170 231 A.9.2. More options for avoiding IPv6 Data-Plane 232 dependencies . . . . . . . . . . . . . . . . . . . . 170 233 A.9.3. ACP APIs and operational models (YANG) . . . . . . . 171 234 A.9.4. RPL enhancements . . . . . . . . . . . . . . . . . . 171 235 A.9.5. Role assignments . . . . . . . . . . . . . . . . . . 172 236 A.9.6. Autonomic L3 transit . . . . . . . . . . . . . . . . 172 237 A.9.7. Diagnostics . . . . . . . . . . . . . . . . . . . . . 172 238 A.9.8. Avoiding and dealing with compromised ACP nodes . . . 173 239 A.9.9. Detecting ACP secure channel downgrade attacks . . . 174 241 Appendix B. Unfinished considerations (To Be Removed From 242 RFC) . . . . . . . . . . . . . . . . . . . . . . . . . . 175 243 B.1. Considerations for improving secure channel 244 negotiation . . . . . . . . . . . . . . . . . . . . . . . 175 245 B.2. ACP address verification . . . . . . . . . . . . . . . . 176 246 B.3. Public CA considerations . . . . . . . . . . . . . . . . 178 247 B.4. Hardening DULL GRASP considerations . . . . . . . . . . . 179 248 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 179 250 1. Introduction (Informative) 252 Autonomic Networking is a concept of self-management: Autonomic 253 functions self-configure, and negotiate parameters and settings 254 across the network. [RFC7575] defines the fundamental ideas and 255 design goals of Autonomic Networking. A gap analysis of Autonomic 256 Networking is given in [RFC7576]. The reference architecture for 257 Autonomic Networking in the IETF is specified in the document 258 [I-D.ietf-anima-reference-model]. 260 Autonomic functions need an autonomically built communications 261 infrastructure. This infrastructure needs to be secure, resilient 262 and re-usable by all autonomic functions. Section 5 of [RFC7575] 263 introduces that infrastructure and calls it the Autonomic Control 264 Plane (ACP). More descriptively it would be the "Autonomic 265 communications infrastructure for OAM and Control". For naming 266 consistency with that prior document, this document continues to use 267 the name ACP though. 269 Today, the OAM and control plane of IP networks is what is typically 270 called in-band management/signaling: Its management and control 271 protocol traffic depends on the routing and forwarding tables, 272 security, policy, QoS and potentially other configuration that first 273 has to be established through the very same management and control 274 protocols. Misconfigurations including unexpected side effects or 275 mutual dependences can disrupt OAM and control operations and 276 especially disrupt remote management access to the affected node 277 itself and potentially a much larger number of nodes for whom the 278 affected node is on the network path. 280 For an example of inband management failing in the face of operator 281 induced misconfiguration, see [FCC], for example III.B.15 on page 8: 282 "...engineers almost immediately recognized that they had 283 misdiagnosed the problem. However, they were unable to resolve the 284 issue by restoring the link because the network management tools 285 required to do so remotely relied on the same paths they had just 286 disabled". 288 Traditionally, physically separate, so-called out-of-band 289 (management) networks have been used to avoid these problems or at 290 least to allow recovery from such problems. Worst case, personnel 291 are sent on site to access devices through out-of-band management 292 ports (also called craft ports, serial console, management ethernet 293 port). However, both options are expensive. 295 In increasingly automated networks either centralized management 296 systems or distributed autonomic service agents in the network 297 require a control plane which is independent of the configuration of 298 the network they manage, to avoid impacting their own operations 299 through the configuration actions they take. 301 This document describes a modular design for a self-forming, self- 302 managing and self-protecting ACP, which is a virtual out-of-band 303 network designed to be as independent as possible of configuration, 304 addressing and routing to avoid the self-dependency problems of 305 current IP networks while still operating in-band on the same 306 physical network that it is controlling and managing. The ACP design 307 is therefore intended to combine as well as possible the resilience 308 of out-of-band management networks with the low-cost of traditional 309 IP in-band network management. The details how this is achieved are 310 described in Section 6. 312 In a fully autonomic network node without legacy control or 313 management functions/protocols, the Data-Plane would be for example 314 just a forwarding plane for "Data" IPv6 packets, aka: packets other 315 than the control and management plane packets that are forwarded by 316 the ACP itself. In such networks/nodes, there would be no non- 317 autonomous control or non-autonomous management plane. 319 Routing protocols for example would be built inside the ACP as so- 320 called autonomous functions via autonomous service agents, leveraging 321 the ACP's functions instead of implementing them separately for each 322 protocol: discovery, automatically established authenticated and 323 encrypted local and distant peer connectivity for control and 324 management traffic, and common control/management protocol session 325 and presentation functions. 327 When ACP functionality is added to nodes that have non-autonomous 328 management plane and/or control plane functions (henceforth called 329 non-autonomous nodes), the ACP instead is best abstracted as a 330 special Virtual Routing and Forwarding (VRF) instance (or virtual 331 router) and the complete pre-existing non-autonomous management and/ 332 or control plane is considered to be part of the Data-Plane to avoid 333 introduction of more complex, new terminology only for this case. 335 Like the forwarding plane for "Data" packets, the non-autonomous 336 control and management plane functions can then be managed/used via 337 the ACP. This terminology is consistent with pre-existing documents 338 such as [RFC8368]. 340 In both instances (autonomous and non-autonomous nodes), the ACP is 341 built such that it is operating in the absence of the Data-Plane, and 342 in the case of existing non-autonomous (management, control) 343 components in the Data-Plane also in the presence of any 344 (mis-)configuration thereof. 346 The Autonomic Control Plane serves several purposes at the same time: 348 1. Autonomic functions communicate over the ACP. The ACP therefore 349 directly supports Autonomic Networking functions, as described in 350 [I-D.ietf-anima-reference-model]. For example, Generic Autonomic 351 Signaling Protocol (GRASP - [I-D.ietf-anima-grasp]) runs securely 352 inside the ACP and depends on the ACP as its "security and 353 transport substrate". 354 2. A controller or network management system can use it to securely 355 bootstrap network devices in remote locations, even if the (Data- 356 Plane) network in between is not yet configured; no Data-Plane 357 dependent bootstrap configuration is required. An example of 358 such a secure bootstrap process is described in 359 [I-D.ietf-anima-bootstrapping-keyinfra]. 360 3. An operator can use it to access remote devices using protocols 361 such as Secure SHell (SSH) or Network Configuration Protocol 362 (NETCONF) running across the ACP, even if the network is 363 misconfigured or not configured. 365 This document describes these purposes as use cases for the ACP in 366 Section 3, it defines the requirements in Section 4. Section 5 gives 367 an overview of how the ACP is constructed. 369 The normative part of this document starts with Section 6, where the 370 ACP is specified. Section 7 explains how to support ACP on L2 371 switches (normative). Section 8 explains how non-ACP nodes and 372 networks can be integrated (normative). 374 The remaining sections are non-normative: Section 10 reviews benefits 375 of the ACP (after all the details have been defined), Section 9 376 provides operational recommendations, Appendix A provides additional 377 explanations and describes additional details or future standard or 378 proprietary extensions that were considered not to be appropriate for 379 standardization in this document but were considered important to 380 document. There are no dependencies against Appendix A to build a 381 complete working and interoperable ACP according to this document. 383 The ACP provides secure IPv6 connectivity, therefore it can be used 384 not only as the secure connectivity for self-management as required 385 for the ACP in [RFC7575], but it can also be used as the secure 386 connectivity for traditional (centralized) management. The ACP can 387 be implemented and operated without any other components of autonomic 388 networks, except for the GRASP protocol. ACP relies on per-link DULL 389 GRASP (see Section 6.4) to autodiscover ACP neighbors, and includes 390 the ACP GRASP instance to provide service discovery for clients of 391 the ACP (see Section 6.9) including for its own maintenance of ACP 392 certificates. 394 The document "Using Autonomic Control Plane for Stable Connectivity 395 of Network OAM" [RFC8368] describes how the ACP alone can be used to 396 provide secure and stable connectivity for autonomic and non- 397 autonomic OAM applications, specifically for the case of current non- 398 autonomic networks/nodes. That document also explains how existing 399 management solutions can leverage the ACP in parallel with 400 traditional management models, when to use the ACP and how to 401 integrate with potentially IPv4 only OAM backends. 403 Combining ACP with Bootstrapping Remote Secure Key Infrastructures 404 (BRSKI), see [I-D.ietf-anima-bootstrapping-keyinfra]) results in the 405 "Autonomic Network Infrastructure" (ANI) as defined in 406 [I-D.ietf-anima-reference-model], which provides autonomic 407 connectivity (from ACP) with secure zero-touch (automated) bootstrap 408 from BRSKI. The ANI itself does not constitute an Autonomic Network, 409 but it allows the building of more or less autonomic networks on top 410 of it - using either centralized, Software Defined Networking- 411 (SDN-)style (see [RFC7426]) automation or distributed automation via 412 Autonomic Service Agents (ASA) / Autonomic Functions (AF) - or a 413 mixture of both. See [I-D.ietf-anima-reference-model] for more 414 information. 416 1.1. Applicability and Scope 418 Please see the following Terminology section (Section 2) for 419 explanations of terms used in this section. 421 The design of the ACP as defined in this document is considered to be 422 applicable to all types of "professionally managed" networks: Service 423 Provider, Local Area Network (LAN), Metro(politan networks), Wide 424 Area Network (WAN), Enterprise Information Technology (IT) and 425 ->"Operational Technology" (OT) networks. The ACP can operate 426 equally on layer 3 equipment and on layer 2 equipment such as bridges 427 (see Section 7). The hop-by-hop authentication, integrity-protection 428 and confidentiality mechanism used by the ACP is defined to be 429 negotiable, therefore it can be extended to environments with 430 different protocol preferences. The minimum implementation 431 requirements in this document attempt to achieve maximum 432 interoperability by requiring support for multiple options depending 433 on the type of device: IPsec, see [RFC4301], and Datagram Transport 434 Layer Security (DTLS, see Section 6.8.4). 436 The implementation footprint of the ACP consists of Public Key 437 Infrastructure (PKI) code for the ACP certificate including 438 "Enrollment over Secure Transport (EST, see [RFC7030]), the GRASP 439 protocol, UDP, TCP and Transport Layer Security (TLS, see 440 Section 6.1), for security and reliability of GRASP and for EST, the 441 ACP secure channel protocol used (such as IPsec or DTLS), and an 442 instance of IPv6 packet forwarding and routing via the Routing 443 Protocol for Low-power and Lossy Networks (RPL), see [RFC6550], that 444 is separate from routing and forwarding for the Data-Plane (user 445 traffic). 447 The ACP uses only IPv6 to avoid complexity of dual-stack ACP 448 operations (IPv6/IPv4). Nevertheless, it can without any changes be 449 integrated into even otherwise IPv4-only network devices. The Data- 450 Plane itself would not need to change and it could continue to be 451 IPv4 only. For such IPv4-only devices, the IPv6 protocol itself 452 would be additional implementation footprint that is only required 453 for the ACP. 455 The protocol choices of the ACP are primarily based on wide use and 456 support in networks and devices, well understood security properties 457 and required scalability. The ACP design is an attempt to produce 458 the lowest risk combination of existing technologies and protocols to 459 build a widely applicable operational network management solution. 461 RPL was chosen because it requires a smaller routing table footprint 462 in large networks compared to other routing protocols with an 463 autonomically configured single area. The deployment experience of 464 large scale Internet of Things (IoT) networks serves as the basis for 465 wide deployment experience with RPL. The profile chosen for RPL in 466 the ACP does not leverage any RPL specific forwarding plane features 467 (IPv6 extension headers), making its implementation a pure control 468 plane software requirement. 470 GRASP is the only completely novel protocol used in the ACP, and this 471 choice was necessary because there is no existing suitable protocol 472 to provide the necessary functions to the ACP, so GRASP was developed 473 to fill that gap. 475 The ACP design can be applicable to devices constrained with respect 476 to cpu and memory, and to networks constrained with respect to 477 bitrate and reliability, but this document does not attempt to define 478 the most constrained type of devices or networks to which the ACP is 479 applicable. RPL and DTLS for ACP secure channels are two protocol 480 choices already making ACP more applicable to constrained 481 environments. Support for constrained devices in this specification 482 is opportunistic, but not complete, because the reliable transport 483 for GRASP (see Section 6.9.2) only specifies TCP/TLS. See 484 Appendix A.8 for discussions about how future standards or 485 proprietary extensions/variations of the ACP could better meet 486 different expectations from those on which the current design is 487 based including supporting constrained devices better. 489 2. Acronyms and Terminology (Informative) 491 [RFC-Editor: Please add ACP, BRSKI, GRASP, MASA to https://www.rfc- 492 editor.org/materials/abbrev.expansion.txt.] 494 [RFC-Editor: What is the recommended way to reference a hanging text, 495 e.g. to a definition in the list of definitions? Up to -28, this 496 document was using XMLv2 and the only option I could find for RFC/XML 497 to point to a hanging text was format="title", which leads to 498 references such as '->"ACP certificate" ()', aka: redundant empty 499 parenthesis. Many reviewers where concerned about this. I created a 500 ticket to ask for an xml2rfc enhancement to avoid this in the future: 501 https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/347. When i 502 changed to XMLv3 in version -29, i could get rid of the unnecessary 503 () by using format="none", but that format is declared to be 504 deprecated in XMLv3. So i am not aware of any working AND "non- 505 deprecated" option.] 507 [RFC-Editor: Question: Is it possible to change the first occurrences 508 of [RFCxxxx] references to "rfcxxx title" [RFCxxxx]? the XML2RFC 509 format does not seem to offer such a format, but I did not want to 510 duplicate 50 first references - one reference for title mentioning 511 and one for RFC number.] 513 This document serves both as a normative specification for how ACP 514 nodes have to behave as well as describing requirements, benefits, 515 architecture and operational aspects to explain the context. 516 Normative sections are labelled "(Normative)" and use BCP 14 517 keywords. Other sections are labelled "(Informative)" and do not use 518 those normative keywords. 520 In the rest of the document we will refer to systems using the ACP as 521 "nodes". Typically, such a node is a physical (network equipment) 522 device, but it can equally be some virtualized system. Therefore, we 523 do not refer to them as devices unless the context specifically calls 524 for a physical system. 526 This document introduces or uses the following terms (sorted 527 alphabetically). Terms introduced are explained on first use, so 528 this list is for reference only. 530 ACP: "Autonomic Control Plane". The Autonomic Function as defined 531 in this document. It provides secure zero-touch (automated) 532 transitive (network wide) IPv6 connectivity for all nodes in the 533 same ACP domain as well as a GRASP instance running across this 534 ACP IPv6 connectivity. The ACP is primarily meant to be used as a 535 component of the ANI to enable Autonomic Networks but it can 536 equally be used in simple ANI networks (with no other Autonomic 537 Functions) or completely by itself. 538 ACP address: An IPv6 address assigned to the ACP node. It is stored 539 in the acp-node-name of the ->"ACP certificate". 540 ACP address range/set: The ACP address may imply a range or set of 541 addresses that the node can assign for different purposes. This 542 address range/set is derived by the node from the format of the 543 ACP address called the "addressing sub-scheme". 544 ACP connect interface: An interface on an ACP node providing access 545 to the ACP for non ACP capable nodes without using an ACP secure 546 channel. See Section 8.1.1. 547 ACP domain: The ACP domain is the set of nodes with ->"ACP 548 certificates" that allow them to authenticate each other as 549 members of the ACP domain. See also Section 6.2.3. 550 ACP (ANI/AN) certificate: A [RFC5280] certificate (LDevID) carrying 551 the acp-node-name which is used by the ACP to learn its address in 552 the ACP and to derive and cryptographically assert its membership 553 in the ACP domain. 554 ACP acp-node-name field: An information field in the ACP certificate 555 in which the ACP relevant information is encoded: the ACP domain 556 name, the ACP IPv6 address of the node and optional additional 557 role attributes about the node. 558 ACP Loopback interface: The Loopback interface in the ACP Virtual 559 Routing and Forwarding (VRF) that has the ACP address assigned to 560 it. See Section 6.13.5.1. 561 ACP network: The ACP network constitutes all the nodes that have 562 access to the ACP. It is the set of active and transitively 563 connected nodes of an ACP domain plus all nodes that get access to 564 the ACP of that domain via ACP edge nodes. 565 ACP (ULA) prefix(es): The /48 IPv6 address prefixes used across the 566 ACP. In the normal/simple case, the ACP has one ULA prefix, see 567 Section 6.11. The ACP routing table may include multiple ULA 568 prefixes if the "rsub" option is used to create addresses from 569 more than one ULA prefix. See Section 6.2.2. The ACP may also 570 include non-ULA prefixes if those are configured on ACP connect 571 interfaces. See Section 8.1.1. 572 ACP secure channel: A channel authenticated via ->"ACP certificates" 573 providing integrity protection and confidentiality through 574 encryption. These are established between (normally) adjacent ACP 575 nodes to carry traffic of the ACP VRF securely and isolated from 576 Data-Plane traffic in-band over the same link/path as the Data- 577 Plane. 578 ACP secure channel protocol: The protocol used to build an ACP 579 secure channel, e.g., Internet Key Exchange Protocol version 2 580 (IKEv2) with IPsec or Datagram Transport Layer Security (DTLS). 581 ACP virtual interface: An interface in the ACP VRF mapped to one or 582 more ACP secure channels. See Section 6.13.5. 583 AN "Autonomic Network": A network according to 584 [I-D.ietf-anima-reference-model]. Its main components are ANI, 585 Autonomic Functions and Intent. 586 (AN) Domain Name: An FQDN (Fully Qualified Domain Name) in the acp- 587 node-name of the Domain Certificate. See Section 6.2.2. 588 ANI (nodes/network): "Autonomic Network Infrastructure". The ANI is 589 the infrastructure to enable Autonomic Networks. It includes ACP, 590 BRSKI and GRASP. Every Autonomic Network includes the ANI, but 591 not every ANI network needs to include autonomic functions beyond 592 the ANI (nor Intent). An ANI network without further autonomic 593 functions can for example support secure zero-touch (automated) 594 bootstrap and stable connectivity for SDN networks - see 595 [RFC8368]. 596 ANIMA: "Autonomic Networking Integrated Model and Approach". ACP, 597 BRSKI and GRASP are specifications of the IETF ANIMA working 598 group. 599 ASA: "Autonomic Service Agent". Autonomic software modules running 600 on an ANI device. The components making up the ANI (BRSKI, ACP, 601 GRASP) are also described as ASAs. 602 Autonomic Function: A function/service in an Autonomic Network (AN) 603 composed of one or more ASA across one or more ANI nodes. 604 BRSKI: "Bootstrapping Remote Secure Key Infrastructures" 605 ([I-D.ietf-anima-bootstrapping-keyinfra]. A protocol extending 606 EST to enable secure zero-touch bootstrap in conjunction with ACP. 607 ANI nodes use ACP, BRSKI and GRASP. 608 CA: "Certification Authority". An entity that issues digital 609 certificates. A CA uses its private key to sign the certificates 610 it issues. Relying parties use the public key in the CA 611 certificate to validate the signature. 612 CRL: "Certificate Revocation List". A list of revoked certificates. 613 Required to revoke certificates before their lifetime expires. 614 Data-Plane: The counterpoint to the ACP VRF in an ACP node: 615 forwarding of user traffic and in non-autonomous nodes/networks 616 also any non-autonomous control and/or management plane functions. 617 In a fully Autonomic Network node, the Data-Plane is managed 618 autonomically via Autonomic Functions and Intent. See Section 1 619 for more detailed explanations. 620 device: A physical system, or physical node. 622 Enrollment: The process through which a node authenticates itself to 623 a network with an initial identity, which is often called IDevID 624 certificate, and acquires from the network a network specific 625 identity, which is often called LDevID certificate, and 626 certificates of one or more Trust Anchor(s). In the ACP, the 627 LDevID certificate is called the ACP certificate. 628 EST: "Enrollment over Secure Transport" ([RFC7030]). IETF standard- 629 track protocol for enrollment of a node with an LDevID 630 certificate. BRSKI is based on EST. 631 GRASP: "Generic Autonomic Signaling Protocol". An extensible 632 signaling protocol required by the ACP for ACP neighbor discovery. 633 The ACP also provides the "security and transport substrate" for 634 the "ACP instance of GRASP". This instance of GRASP runs across 635 the ACP secure channels to support BRSKI and other NOC/OAM or 636 Autonomic Functions. See [I-D.ietf-anima-grasp]. 637 IDevID: An "Initial Device IDentity" X.509 certificate installed by 638 the vendor on new equipment. Contains information that 639 establishes the identity of the node in the context of its vendor/ 640 manufacturer such as device model/type and serial number. See 641 [AR8021]. The IDevID certificate cannot be used as a node 642 identifier for the ACP because they are not provisioned by the 643 owner of the network, so they can not directly indicate an ACP 644 domain they belong to. 645 in-band (management/signaling): In-band management traffic and/or 646 control plane signaling uses the same network resources such as 647 routers/switches and network links that it manages/controls. In- 648 band is the standard management and signaling mechanism in IP 649 networks. Compared to ->"out-of-band" it requires no additional 650 physical resources, but introduces potentially circular 651 dependencies for its correct operations. See ->"introduction". 652 Intent: Policy language of an autonomic network according to 653 [I-D.ietf-anima-reference-model]. 654 Loopback interface: See ->"ACP Loopback interface". 655 LDevID: A "Local Device IDentity" is an X.509 certificate installed 656 during "enrollment". The Domain Certificate used by the ACP is an 657 LDevID certificate. See [AR8021]. 658 Management: Used in this document as another word for ->"OAM". 659 MASA (service): "Manufacturer Authorized Signing Authority". A 660 vendor/manufacturer or delegated cloud service on the Internet 661 used as part of the BRSKI protocol. 662 MIC: "Manufacturer Installed Certificate". This is another word to 663 describe an IDevID in referenced materials. This term is not used 664 in this document. 665 native interface: Interfaces existing on a node without 666 configuration of the already running node. On physical nodes 667 these are usually physical interfaces; on virtual nodes their 668 equivalent. 669 NOC: Network Operations Center. 671 node: A system supporting the ACP according to this document. Can 672 be virtual or physical. Physical nodes are called devices. 673 Node-ID: The identifier of an ACP node inside that ACP. It is the 674 last 64 (see Section 6.11.3) or 78-bits (see Section 6.11.5) of 675 the ACP address. 676 OAM: Operations, Administration and Management. Includes Network 677 Monitoring. 678 Operational Technology (OT): https://en.wikipedia.org/wiki/ 679 Operational_Technology: "The hardware and software dedicated to 680 detecting or causing changes in physical processes through direct 681 monitoring and/or control of physical devices such as valves, 682 pumps, etc.". OT networks are today in most cases well separated 683 from Information Technology (IT) networks. 684 out-of-band (management) network: An out-of-band network is a 685 secondary network used to manage a primary network. The equipment 686 of the primary network is connected to the out-of-band network via 687 dedicated management ports on the primary network equipment. 688 Serial (console) management ports were historically most common, 689 higher end network equipment now also has ethernet ports dedicated 690 only for management. An out-of-band network provides management 691 access to the primary network independent of the configuration 692 state of the primary network. See ->"Introduction" 693 (virtual) out-of-band network: The ACP can be called a virtual out- 694 of-band network for management and control because it attempts to 695 provide the benefits of a (physical) ->"out-of-band network" even 696 though it is physically carried ->"in-band". See 697 ->"introduction". 698 root CA: "root Certification Authority". A ->"CA" for which the 699 root CA Key update procedures of [RFC7030], Section 4.4 can be 700 applied. 701 RPL: "IPv6 Routing Protocol for Low-Power and Lossy Networks". The 702 routing protocol used in the ACP. See [RFC6550]. 703 (ACP/ANI/BRSKI) Registrar: An ACP registrar is an entity (software 704 and/or person) that is orchestrating the enrollment of ACP nodes 705 with the ACP certificate. ANI nodes use BRSKI, so ANI registrars 706 are also called BRSKI registrars. For non-ANI ACP nodes, the 707 registrar mechanisms are undefined by this document. See 708 Section 6.11.7. Renewal and other maintenance (such as 709 revocation) of ACP certificates may be performed by other entities 710 than registrars. EST must be supported for ACP certificate 711 renewal (see Section 6.2.5). BRSKI is an extension of EST, so 712 ANI/BRSKI registrars can easily support ACP domain certificate 713 renewal in addition to initial enrollment. 714 RPI: "RPL Packet Information". Network extension headers for use 715 with the ->"RPL" routing protocols. Not used with RPL in the ACP. 716 See Section 6.12.1.13. 717 RPL: "Routing Protocol for Low-Power and Lossy Networks". The 718 routing protocol used in the ACP. See Section 6.12. 720 sUDI: "secured Unique Device Identifier". This is another word to 721 describe an IDevID in referenced material. This term is not used 722 in this document. 723 TA: "Trust Anchor". A Trust Anchor is an entity that is trusted for 724 the purpose of certificate validation. Trust Anchor Information 725 such as self-signed certificate(s) of the Trust Anchor is 726 configured into the ACP node as part of Enrollment. See 727 [RFC5280], Section 6.1.1. 728 UDI: "Unique Device Identifier". In the context of this document 729 unsecured identity information of a node typically consisting of 730 at least device model/type and serial number, often in a vendor 731 specific format. See sUDI and LDevID. 732 ULA: (Global ID prefix) A "Unique Local Address" (ULA) is an IPv6 733 address in the block fc00::/7, defined in [RFC4193]. ULA is the 734 IPv6 successor of the IPv4 private address space ([RFC1918]). ULA 735 have important differences over IPv4 private addresses that are 736 beneficial for and exploited by the ACP, such as the Locally 737 Assigned Global ID prefix, which are the first 48-bits of a ULA 738 address [RFC4193], section 3.2.1. In this document this prefix is 739 abbreviated as "ULA prefix". 740 (ACP) VRF: The ACP is modeled in this document as a "Virtual Routing 741 and Forwarding" instance (VRF). This means that it is based on a 742 "virtual router" consisting of a separate IPv6 forwarding table to 743 which the ACP virtual interfaces are attached and an associated 744 IPv6 routing table separate from the Data-Plane. Unlike the VRFs 745 on MPLS/VPN-PE ([RFC4364]) or LISP XTR ([RFC6830]), the ACP VRF 746 does not have any special "core facing" functionality or routing/ 747 mapping protocols shared across multiple VRFs. In vendor products 748 a VRF such as the ACP-VRF may also be referred to as a so called 749 VRF-lite. 750 (ACP) Zone: An ACP zone is a set of ACP nodes using the same zone 751 field value in their ACP address according to Section 6.11.3. 752 Zones are a mechanism to support structured addressing of ACP 753 addresses within the same /48-bit ULA prefix. 755 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 756 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 757 "OPTIONAL" in this document are to be interpreted as described in BCP 758 14 [RFC2119],[RFC8174] when, and only when, they appear in all 759 capitals, as shown here. 761 3. Use Cases for an Autonomic Control Plane (Informative) 763 This section summarizes the use cases that are intended to be 764 supported by an ACP. To understand how these are derived from and 765 relate to the larger set of use cases for autonomic networks, please 766 refer to [RFC8316]. 768 3.1. An Infrastructure for Autonomic Functions 770 Autonomic Functions need a stable infrastructure to run on, and all 771 autonomic functions should use the same infrastructure to minimize 772 the complexity of the network. In this way, there is only need for a 773 single discovery mechanism, a single security mechanism, and single 774 instances of other processes that distributed functions require. 776 3.2. Secure Bootstrap over a not configured Network 778 Today, bootstrapping a new node typically requires all nodes between 779 a controlling node such as an SDN controller ("Software Defined 780 Networking", see [RFC7426]) and the new node to be completely and 781 correctly addressed, configured and secured. Bootstrapping and 782 configuration of a network happens in rings around the controller - 783 configuring each ring of devices before the next one can be 784 bootstrapped. Without console access (for example through an out-of- 785 band network) it is not possible today to make devices securely 786 reachable before having configured the entire network leading up to 787 them. 789 With the ACP, secure bootstrap of new devices and whole new networks 790 can happen without requiring any configuration of unconfigured 791 devices along the path: As long as all devices along the path support 792 ACP and a zero-touch bootstrap mechanism such as BRSKI, the ACP 793 across a whole network of unconfigured devices can be brought up 794 without operator/provisioning intervention. The ACP also provides 795 additional security for any bootstrap mechanism, because it can 796 provide encrypted discovery (via ACP GRASP) of registrars or other 797 bootstrap servers by bootstrap proxies connecting to nodes that are 798 to be bootstrapped and the ACP encryption hides the identities of the 799 communicating entities (pledge and registrar), making it more 800 difficult to learn which network node might be attackable. The ACP 801 certificate can also be used to end-to-end encrypt the bootstrap 802 communication between such proxies and server. Note that 803 bootstrapping here includes not only the first step that can be 804 provided by BRSKI (secure keys), but also later stages where 805 configuration is bootstrapped. 807 3.3. Data-Plane Independent Permanent Reachability 809 Today, most critical control plane protocols and OAM protocols are 810 using the Data-Plane of the network. This leads to often undesirable 811 dependencies between control and OAM plane on one side and the Data- 812 Plane on the other: Only if the forwarding and control plane of the 813 Data-Plane are configured correctly, will the Data-Plane and the OAM/ 814 control plane work as expected. 816 Data-Plane connectivity can be affected by errors and faults, for 817 example misconfigurations that make AAA (Authentication, 818 Authorization and Accounting) servers unreachable or can lock an 819 administrator out of a device; routing or addressing issues can make 820 a device unreachable; shutting down interfaces over which a current 821 management session is running can lock an admin irreversibly out of 822 the device. Traditionally only out-of-band access can help recover 823 from such issues (such as serial console or ethernet management 824 port). 826 Data-Plane dependencies also affect applications in a Network 827 Operations Center (NOC) such as SDN controller applications: Certain 828 network changes are today hard to implement, because the change 829 itself may affect reachability of the devices. Examples are address 830 or mask changes, routing changes, or security policies. Today such 831 changes require precise hop-by-hop planning. 833 Note that specific control plane functions for the Data-Plane often 834 want to depend on forwarding of their packets via the Data-Plane: 835 Aliveness and routing protocol signaling packets across the Data- 836 Plane to verify reachability across the Data-Plane, using IPv4 837 signaling packets for IPv4 routing vs. IPv6 signaling packets for 838 IPv6 routing. 840 Assuming appropriate implementation (see Section 6.13.2 for more 841 details), the ACP provides reachability that is independent of the 842 Data-Plane. This allows the control plane and OAM plane to operate 843 more robustly: 845 * For management plane protocols, the ACP provides the functionality 846 of a Virtual out-of-band (VooB) channel, by providing connectivity 847 to all nodes regardless of their Data-Plane configuration, routing 848 and forwarding tables. 849 * For control plane protocols, the ACP allows their operation even 850 when the Data-Plane is temporarily faulty, or during transitional 851 events, such as routing changes, which may affect the control 852 plane at least temporarily. This is specifically important for 853 autonomic service agents, which could affect Data-Plane 854 connectivity. 856 The document "Using Autonomic Control Plane for Stable Connectivity 857 of Network OAM" [RFC8368] explains this use case for the ACP in 858 significantly more detail and explains how the ACP can be used in 859 practical network operations. 861 4. Requirements (Informative) 863 The following requirements were identified for the design of the ACP 864 based on the above use-cases (Section 3). These requirements are 865 informative. The ACP as specified in the normative parts of this 866 document is meeting or exceeding these use-case requirements: 868 ACP1: The ACP should provide robust connectivity: As far as 869 possible, it should be independent of configured addressing, 870 configuration and routing. Requirements 2 and 3 build on this 871 requirement, but also have value on their own. 872 ACP2: The ACP must have a separate address space from the Data- 873 Plane. Reason: traceability, debug-ability, separation from 874 Data-Plane, infrastructure security (filtering based on known 875 address space). 876 ACP3: The ACP must use autonomically managed address space. Reason: 877 easy bootstrap and setup ("autonomic"); robustness (admin 878 cannot break network easily). This document uses Unique Local 879 Addresses (ULA) for this purpose, see [RFC4193]. 880 ACP4: The ACP must be generic, that is it must be usable by all the 881 functions and protocols of the ANI. Clients of the ACP must 882 not be tied to a particular application or transport protocol. 883 ACP5: The ACP must provide security: Messages coming through the ACP 884 must be authenticated to be from a trusted node, and it is 885 very strongly > recommended that they be encrypted. 887 Explanation for ACP4: In a fully autonomic network (AN), newly 888 written ASAs could potentially all communicate exclusively via GRASP 889 with each other, and if that was assumed to be the only requirement 890 against the ACP, it would not need to provide IPv6 layer connectivity 891 between nodes, but only GRASP connectivity. Nevertheless, because 892 ACP also intends to support non-AN networks, it is crucial to support 893 IPv6 layer connectivity across the ACP to support any transport and 894 application layer protocols. 896 The ACP operates hop-by-hop, because this interaction can be built on 897 IPv6 link local addressing, which is autonomic, and has no dependency 898 on configuration (requirement 1). It may be necessary to have ACP 899 connectivity across non-ACP nodes, for example to link ACP nodes over 900 the general Internet. This is possible, but introduces a dependency 901 against stable/resilient routing over the non-ACP hops (see 902 Section 8.2). 904 5. Overview (Informative) 906 When a node has an ACP certificate (see Section 6.2.1) and is enabled 907 to bring up the ACP (see Section 9.3.5), it will create its ACP 908 without any configuration as follows. For details, see Section 6 and 909 further sections: 911 1. The node creates a VRF instance, or a similar virtual context for 912 the ACP. 913 2. The node assigns its ULA IPv6 address (prefix) (see Section 6.11 914 which is learned from the acp-node-name (see Section 6.2.2) of 915 its ACP certificate (see Section 6.2.1) to an ACP loopback 916 interface (see Section 6.11) and connects this interface into the 917 ACP VRF. 918 3. The node establishes a list of candidate peer adjacencies and 919 candidate channel types to try for the adjacency. This is 920 automatic for all candidate link-local adjacencies, see 921 Section 6.4 across all native interfaces (see Section 9.3.4). If 922 a candidate peer is discovered via multiple interfaces, this will 923 result in one adjacency per interface. If the ACP node has 924 multiple interfaces connecting to the same subnet across which it 925 is also operating as an L2 switch in the Data-Plane, it employs 926 methods for ACP with L2 switching, see Section 7. 927 4. For each entry in the candidate adjacency list, the node 928 negotiates a secure tunnel using the candidate channel types. 929 See Section 6.6. 930 5. The node authenticates the peer node during secure channel setup 931 and authorizes it to become part of the ACP according to 932 Section 6.2.3. 933 6. Unsuccessful authentication of a candidate peer results in 934 throttled connection retries for as long as the candidate peer is 935 discoverable. See Section 6.7. 936 7. Each successfully established secure channel is mapped into an 937 ACP virtual interface, which is placed into the ACP VRF. See 938 Section 6.13.5.2. 939 8. Each node runs a lightweight routing protocol, see Section 6.12, 940 to announce reachability of the ACP loopback address (or prefix) 941 across the ACP. 942 9. This completes the creation of the ACP with hop-by-hop secure 943 tunnels, auto-addressing and auto-routing. The node is now an 944 ACP node with a running ACP. 946 Note: 948 * None of the above operations (except the following explicit 949 configured ones) are reflected in the configuration of the node. 950 * Non-ACP NMS ("Network Management Systems") or SDN controllers have 951 to be explicitly configured for connection into the ACP. 953 * Additional candidate peer adjacencies for ACP connections across 954 non-ACP Layer-3 clouds requires explicit configuration. See 955 Section 8.2. 957 The following figure illustrates the ACP. 959 ACP node 1 ACP node 2 960 ................... ................... 961 secure . . secure . . secure 962 channel: +-----------+ : channel : +-----------+ : channel 963 ..--------| ACP VRF |---------------------| ACP VRF |---------.. 964 : / \ / \ <--routing--> / \ / \ : 965 : \ / \ / \ / \ / : 966 ..--------| Loopback |---------------------| Loopback |---------.. 967 : | interface | : : | interface | : 968 : +-----------+ : : +-----------+ : 969 : : : : 970 : Data-Plane :...............: Data-Plane : 971 : : link : : 972 :.................: :.................: 974 Figure 1: ACP VRF and secure channels 976 The resulting overlay network is normally based exclusively on hop- 977 by-hop tunnels. This is because addressing used on links is IPv6 978 link local addressing, which does not require any prior set-up. In 979 this way the ACP can be built even if there is no configuration on 980 the node, or if the Data-Plane has issues such as addressing or 981 routing problems. 983 6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 985 This section specifies the components and steps to set up an ACP. 986 The ACP is automatically "self-creating", which makes it 987 "indestructible" against most changes to the Data-Plane, including 988 misconfigurations of routing, addressing, NAT, firewall or any other 989 traffic policy filters that inadvertently or otherwise unavoidably 990 would also impact the management plane traffic, such as the actual 991 operator CLI session or controller NETCONF session through which the 992 configuration changes to the Data-Plane are executed. 994 Physical misconfiguration of wiring between ACP nodes will also not 995 break the ACP: As long as there is a transitive physical path between 996 ACP nodes, the ACP should be able to recover given that it 997 automatically operates across all interfaces of the ACP nodes and 998 automatically determines paths between them. 1000 Attacks against the network via incorrect routing or addressing 1001 information for the Data-Plane will not impact the ACP. Even 1002 impaired ACP nodes will have a significantly reduced attack surface 1003 against malicious misconfiguration because only very limited ACP or 1004 interface up/down configuration can affect the ACP, and pending on 1005 their specific designs these type of attacks could also be 1006 eliminated. See more in Section 9.3 and Section 11. 1008 An ACP node can be a router, switch, controller, NMS host, or any 1009 other IPv6 capable node. Initially, it MUST have its ACP 1010 certificate, as well as an (empty) ACP Adjacency Table (described in 1011 Section 6.3). It then can start to discover ACP neighbors and build 1012 the ACP. This is described step by step in the following sections: 1014 6.1. Requirements for use of Transport Layer Security (TLS) 1016 The following requirements apply to TLS required or used by ACP 1017 components. Applicable ACP components include ACP certificate 1018 maintenance via EST, see Section 6.2.5, TLS connections for 1019 Certificate Revocation List (CRL) Distribution Point (CRLDP) or 1020 Online Certificate Status Protocol (OCSP) responder (if used, see 1021 Section 6.2.3) and ACP GRASP (see Section 6.9.2). On ANI nodes these 1022 requirements also apply to BRSKI. 1024 TLS MUST comply with [RFC7525] except that TLS 1.2 ([RFC5246]) is 1025 REQUIRED and that older versions of TLS MUST NOT be used. TLS 1.3 1026 ([RFC8446]) SHOULD be supported. The choice for TLS 1.2 as the 1027 lowest common denominator for the ACP is based on current expected 1028 most likely availability across the wide range of candidate ACP node 1029 types, potentially with non-agile operating system TCP/IP stacks. 1031 TLS MUST offer TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and 1032 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 and MUST NOT offer options 1033 with less than 256-bit symmetric key strength or hash strength of 1034 less than 384 bits. When TLS 1.3 is supported, 1035 TLS_AES_256_GCM_SHA384 MUST be offered and 1036 TLS_CHACHA20_POLY1305_SHA256 MAY be offered. 1038 TLS MUST also include the "Supported Elliptic Curves" extension, it 1039 MUST support the NIST P-256 (secp256r1(22)) and P-384 (secp384r1(24)) 1040 curves [RFC8422]. In addition, TLS 1.2 clients SHOULD send an 1041 ec_point_format extension with a single element, "uncompressed". 1043 6.2. ACP Domain, Certificate and Network 1045 The ACP relies on group security. An ACP domain is a group of nodes 1046 that trust each other to participate in ACP operations such as 1047 creating ACP secure channels in an autonomous peer-to-peer fashion 1048 between ACP domain members via protocols such as IPsec. To 1049 authenticate and authorize another ACP member node with access to the 1050 ACP Domain, each ACP member requires keying material: An ACP node 1051 MUST have a Local Device IDentity (LDevID) certificate, henceforth 1052 called the ACP certificate and information about one or more Trust 1053 Anchor (TA) as required for the ACP domain membership check 1054 (Section 6.2.3). 1056 Manual keying via shared secrets is not usable for an ACP domain 1057 because it would require a single shared secret across all current 1058 and future ACP domain members to meet the expectation of autonomous, 1059 peer-to-peer establishment of ACP secure channels between any ACP 1060 domain members. Such a single shared secret would be an inacceptable 1061 security weakness. Asymmetric keying material (public keys) without 1062 certificates does not provide the mechanisms to authenticate ACP 1063 domain membership in an autonomous, peer-to-peer fashion for current 1064 and future ACP domain members. 1066 The LDevID certificate is called the ACP certificate. The TA is the 1067 Certification Authority (CA) root certificate of the ACP domain. 1069 The ACP does not mandate specific mechanisms by which this keying 1070 material is provisioned into the ACP node. It only requires the 1071 certificate to comply with Section 6.2.1, specifically to have the 1072 acp-node-name as specified in Section 6.2.2 in its domain certificate 1073 as well as those of candidate ACP peers. See Appendix A.2 for more 1074 information about enrollment or provisioning options. 1076 This document uses the term ACP in many places where the Autonomic 1077 Networking reference documents [RFC7575] and 1078 [I-D.ietf-anima-reference-model] use the word autonomic. This is 1079 done because those reference documents consider (only) fully 1080 autonomic networks and nodes, but support of ACP does not require 1081 support for other components of autonomic networks except for relying 1082 on GRASP and providing security and transport for GRASP. Therefore, 1083 the word autonomic might be misleading to operators interested in 1084 only the ACP. 1086 [RFC7575] defines the term "Autonomic Domain" as a collection of 1087 autonomic nodes. ACP nodes do not need to be fully autonomic, but 1088 when they are, then the ACP domain is an autonomic domain. Likewise, 1089 [I-D.ietf-anima-reference-model] defines the term "Domain 1090 Certificate" as the certificate used in an autonomic domain. The ACP 1091 certificate is that domain certificate when ACP nodes are (fully) 1092 autonomic nodes. Finally, this document uses the term ACP network to 1093 refer to the network created by active ACP nodes in an ACP domain. 1094 The ACP network itself can extend beyond ACP nodes through the 1095 mechanisms described in Section 8.1. 1097 6.2.1. ACP Certificates 1099 ACP certificates MUST be [RFC5280] compliant X.509 v3 ([X.509]) 1100 certificates. 1102 ACP nodes MUST support handling ACP certificates, TA certificates and 1103 certificate chain certificates (henceforth just called certificates 1104 in this section) with RSA public keys and certificates with Elliptic 1105 Curve (ECC) public keys. 1107 ACP nodes MUST NOT support certificates with RSA public keys of less 1108 than 2048-bit modulus or curves with group order of less than 1109 256-bit. They MUST support certificates with RSA public keys with 1110 2048-bit modulus and MAY support longer RSA keys. They MUST support 1111 certificates with ECC public keys using NIST P-256 curves and SHOULD 1112 support P-384 and P-521 curves. 1114 ACP nodes MUST NOT support certificates with RSA public keys whose 1115 modulus is less than 2048 bits, or certificates whose ECC public keys 1116 are in groups whose order is less than 256-bits. RSA signing 1117 certificates with 2048-bit public keys MUST be supported, and such 1118 certificates with longer public keys MAY be supported. ECDSA 1119 certificates using the NIST P-256 curve MUST be supported, and such 1120 certificates using the P-384 and P-521 curves SHOULD be supported. 1122 ACP nodes MUST support RSA certificates that are signed by RSA 1123 signatures over the SHA-256 digest of the contents, and SHOULD 1124 additionally support SHA-384 and SHA-512 digests in such signatures. 1125 The same requirements for digest usage in certificate signatures 1126 apply to ECDSA certificates, and additionally, ACP nodes MUST support 1127 ECDSA signatures on ECDSA certificates. 1129 The ACP certificate SHOULD use an RSA key and an RSA signature when 1130 the ACP certificate is intended to be used not only for ACP 1131 authentication but also for other purposes. The ACP certificate MAY 1132 use an ECC key and an ECDSA signature if the ACP certificate is only 1133 used for ACP and ANI authentication and authorization. 1135 Any secure channel protocols used for the ACP as specified in this 1136 document or extensions of this document MUST therefore support 1137 authentication (e.g. signing) starting with these type of 1138 certificates. See [RFC8422] for more information. 1140 The reason for these choices are as follows: As of 2020, RSA is still 1141 more widely used than ECC, therefore the MUST for RSA. ECC offers 1142 equivalent security at (logarithmically) shorter key lengths (see 1143 [RFC8422]). This can be beneficial especially in the presence of 1144 constrained bandwidth or constrained nodes in an ACP/ANI network. 1145 Some ACP functions such as GRASP peer-2-peer across the ACP require 1146 end-to-end/any-to-any authentication/authorization, therefore ECC can 1147 only reliably be used in the ACP when it MUST be supported on all ACP 1148 nodes. RSA signatures are mandatory to be supported also for ECC 1149 certificates because CAs themselves may not support ECC yet. 1151 The ACP certificate SHOULD be used for any authentication between 1152 nodes with ACP domain certificates (ACP nodes and NOC nodes) where a 1153 required authorization condition is ACP domain membership, such as 1154 ACP node to NOC/OAM end-to-end security and ASA to ASA end-to-end 1155 security. Section 6.2.3 defines this "ACP domain membership check". 1156 The uses of this check that are standardized in this document are for 1157 the establishment of hop-by-hop ACP secure channels (Section 6.7) and 1158 for ACP GRASP (Section 6.9.2) end-to-end via TLS. 1160 The ACP domain membership check requires a minimum amount of elements 1161 in a certificate as described in Section 6.2.3. The identity of a 1162 node in the ACP is carried via the acp-node-name as defined in 1163 Section 6.2.2. 1165 To support ECDH directly with the key in the ACP certificate, ACP 1166 certificates with ECC keys need to indicate to be Elliptic Curve 1167 Diffie-Hellman capable (ECDH): If the X.509v3 keyUsage extension is 1168 present, the keyAgreement bit must then be set. Note that this 1169 option is not required for any of the required ciphersuites in this 1170 document and may not be supported by all CA. 1172 Any other fields of the ACP certificate are to be populated as 1173 required by [RFC5280]: As long as they are compliant with [RFC5280], 1174 any other field of an ACP certificate can be set as desired by the 1175 operator of the ACP domain through appropriate ACP registrar/ACP CA 1176 procedures. For example, other fields may be required for other 1177 purposes that the ACP certificate is intended to be used for (such as 1178 elements of a SubjectName). 1180 For further certificate details, ACP certificates may follow the 1181 recommendations from [CABFORUM]. 1183 For diagnostic and other operational purposes, it is beneficial to 1184 copy the device identifying fields of the node's IDevID certificate 1185 into the ACP certificate, such as the [X.520], section 6.2.9 1186 "serialNumber" attribute in the subject field distinguished name 1187 encoding. Note that this is not the certificate serial number. See 1188 also [I-D.ietf-anima-bootstrapping-keyinfra] section 2.3.1. This can 1189 be done for example if it would be acceptable for the device's 1190 "serialNumber" to be signaled via the Link Layer Discovery Protocol 1191 (LLDP, [LLDP]) because like LLDP signaled information, the ACP 1192 certificate information can be retrieved by neighboring nodes without 1193 further authentication and be used either for beneficial diagnostics 1194 or for malicious attacks. Retrieval of the ACP certificate is 1195 possible via a (failing) attempt to set up an ACP secure channel, and 1196 the "serialNumber" usually contains device type information that may 1197 help to faster determine working exploits/attacks against the device. 1199 Note that there is no intention to constrain authorization within the 1200 ACP or autonomic networks using the ACP to just the ACP domain 1201 membership check as defined in this document. It can be extended or 1202 modified with additional requirements. Such future authorizations 1203 can use and require additional elements in certificates or policies 1204 or even additional certificates. See the additional check against 1205 the id-kp-cmcRA [RFC6402] extended key usage attribute 1206 (Section 6.2.5) and for possible future extensions, see 1207 Appendix A.9.5. 1209 6.2.2. ACP Certificate AcpNodeName 1211 acp-node-name = local-part "@" acp-domain-name 1212 local-part = [ acp-address ] [ "+" rsub extensions ] 1213 acp-address = 32HEXDIG | "0" ; HEXDIG as of RFC5234 section B.1 1214 rsub = [ ] ; as of RFC1034, section 3.5 1215 acp-domain-name = ; ; as of RFC 1034, section 3.5 1216 extensions = *( "+" extension ) 1217 extension = 1*etext ; future standard definition. 1218 etext = ALPHA / DIGIT / ; Printable US-ASCII 1219 "!" / "#" / "$" / "%" / "&" / "'" / 1220 "*" / "-" / "/" / "=" / "?" / "^" / 1221 "_" / "`" / "{" / "|" / "}" / "~" 1223 routing-subdomain = [ rsub "." ] acp-domain-name 1225 Example: 1226 given an ACP address of fd89:b714:f3db:0:200:0:6400:0000 1227 and an ACP domain-name of acp.example.com 1228 and an rsub extenstion of area51.research 1230 then this results in: 1231 acp-node-name = fd89b714f3db00000200000064000000 1232 +area51.research@acp.example.com 1233 acp-domain-name = acp.example.com 1234 routing-subdomain = area51.research.acp.example.com 1235 Figure 2: ACP Node Name ABNF 1237 acp-node-name in above Figure 2 is the ABNF ([RFC5234]) definition of 1238 the ACP Node Name. An ACP certificate MUST carry this information. 1239 It MUST be encoded as a subjectAltName / otherName / AcpNodeName as 1240 described in Section 6.2.2.1. 1242 Nodes complying with this specification MUST be able to receive their 1243 ACP address through the domain certificate, in which case their own 1244 ACP certificate MUST have a 32HEXDIG acp-address field. Acp-address 1245 is case insensitive because ABNF HEXDIG is. It is recommended to 1246 encode acp-address with lower case letters. Nodes complying with 1247 this specification MUST also be able to authenticate nodes as ACP 1248 domain members or ACP secure channel peers when they have a 0-value 1249 acp-address field and as ACP domain members (but not as ACP secure 1250 channel peers) when the acp-address field is omitted from their 1251 AcpNodeName. See Section 6.2.3. 1253 acp-domain-name is used to indicate the ACP Domain across which ACP 1254 nodes authenticate and authorize each other, for example to build ACP 1255 secure channels to each other, see Section 6.2.3. acp-domain-name 1256 SHOULD be the FQDN of an Internet domain owned by the network 1257 administration of the ACP and ideally reserved to only be used for 1258 the ACP. In this specification it serves to be a name for the ACP 1259 that ideally is globally unique. When acp-domain-name is a globally 1260 unique name, collision of ACP addresses across different ACP domains 1261 can only happen due to ULA hash collisions (see Section 6.11.2). 1262 Using different acp-domain-names, operators can distinguish multiple 1263 ACP even when using the same TA. 1265 To keep the encoding simple, there is no consideration for 1266 internationalized acp-domain-names. The acp-node-name is not 1267 intended for end user consumption. There is no protection against an 1268 operator to pick any domain name for an ACP whether or not the 1269 operator can claim to own the domain name. Instead, the domain name 1270 only serves as a hash seed for the ULA and for diagnostics to the 1271 operator. Therefore, any operator owning only an internationalized 1272 domain name should be able to pick an equivalently unique 7-bit ASCII 1273 acp-domain-name string representing the internationalized domain 1274 name. 1276 "routing-subdomain" is a string that can be constructed from the acp- 1277 node-name, and it is used in the hash-creation of the ULA (see 1278 below). The presence of the "rsub" component allows a single ACP 1279 domain to employ multiple /48 ULA prefixes. See Appendix A.6 for 1280 example use-cases. 1282 The optional "extensions" field is used for future standardized 1283 extensions to this specification. It MUST be ignored if present and 1284 not understood. 1286 The following points explain and justify the encoding choices 1287 described: 1289 1. Formatting notes: 1290 1.1 "rsub" needs to be in the "local-part": If the format just 1291 had routing-subdomain as the domain part of the acp-node- 1292 name, rsub and acp-domain-name could not be separated from 1293 each other to determine in the ACP domain membership check 1294 which part is the acp-domain-name and which is solely for 1295 creating a different ULA prefix. 1296 1.2 If both "acp-address" and "rsub" are omitted from 1297 AcpNodeName, the "local-part" will have the format 1298 "++extension(s)". The two plus characters are necessary so 1299 the node can unambiguously parse that both "acp-address" and 1300 "rsub" are omitted. 1301 2. The encoding of the ACP domain name and ACP address as described 1302 in this section is used for the following reasons: 1303 2.1 The acp-node-name is the identifier of a node's ACP. It 1304 includes the necessary components to identify a node's ACP 1305 both from within the ACP as well as from the outside of the 1306 ACP. 1307 2.2 For manual and/or automated diagnostics and backend 1308 management of devices and ACPs, it is necessary to have an 1309 easily human readable and software parsed standard, single 1310 string representation of the information in the acp-node- 1311 name. For example, inventory or other backend systems can 1312 always identify an entity by one unique string field but not 1313 by a combination of multiple fields, which would be 1314 necessary if there was no single string representation. 1315 2.3 If the encoding was not that of such a string, it would be 1316 necessary to define a second standard encoding to provide 1317 this format (standard string encoding) for operator 1318 consumption. 1319 2.4 Addresses of the form @ have become the 1320 preferred format for identifiers of entities in many 1321 systems, including the majority of user identification in 1322 web or mobile applications such as multi-domain single-sign- 1323 on systems. 1324 3. Compatibilities: 1325 3.1 It should be possible to use the ACP certificate as an 1326 LDevID certificate on the system for other uses beside the 1327 ACP. Therefore, the information element required for the 1328 ACP should be encoded so that it minimizes the possibility 1329 of creating incompatibilities with such other uses. The 1330 attributes of the subject field for example are often used 1331 in non-ACP applications and should therefore not be occupied 1332 by new ACP values. 1333 3.2 The element should not require additional ASN.1 en/decoding, 1334 because libraries to access certificate information 1335 especially for embedded devices may not support extended 1336 ASN.1 decoding beyond predefined, mandatory fields. 1337 subjectAltName / otherName is already used with a single 1338 string parameter for several otherNames (see [RFC3920], 1339 [RFC7585], [RFC4985], [RFC8398]). 1340 3.3 The element required for the ACP should minimize the risk of 1341 being misinterpreted by other uses of the LDevID 1342 certificate. It also must not be misinterpreted to actually 1343 be an email address, hence the use of the otherName / 1344 rfc822Name option in the certificate would be inappropriate. 1346 See section 4.2.1.6 of [RFC5280] for details on the subjectAltName 1347 field. 1349 6.2.2.1. AcpNodeName ASN.1 Module 1351 The following ASN.1 module normatively specifies the AcpNodeName 1352 structure. This specification uses the ASN.1 definitions from 1353 [RFC5912] with the 2002 ASN.1 notation used in that document. 1354 [RFC5912] updates normative documents using older ASN.1 notation. 1356 ANIMA-ACP-2020 1357 { iso(1) identified-organization(3) dod(6) 1358 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 1359 id-mod-anima-acpnodename-2020(IANA1) } 1361 DEFINITIONS IMPLICIT TAGS ::= 1362 BEGIN 1364 IMPORTS 1365 OTHER-NAME 1366 FROM PKIX1Implicit-2009 1367 { iso(1) identified-organization(3) dod(6) internet(1) 1368 security(5) mechanisms(5) pkix(7) id-mod(0) 1369 id-mod-pkix1-implicit-02(59) } 1371 id-pkix 1372 FROM PKIX1Explicit-2009 1373 { iso(1) identified-organization(3) dod(6) internet(1) 1374 security(5) mechanisms(5) pkix(7) id-mod(0) 1375 id-mod-pkix1-explicit-02(51) } ; 1377 id-on OBJECT IDENTIFIER ::= { id-pkix 8 } 1379 AcpNodeNameOtherNames OTHER-NAME ::= { on-AcpNodeName, ... } 1381 on-AcpNodeName OTHER-NAME ::= { 1382 AcpNodeName IDENTIFIED BY id-on-AcpNodeName 1383 } 1385 id-on-AcpNodeName OBJECT IDENTIFIER ::= { id-on IANA2 } 1387 AcpNodeName ::= IA5String (SIZE (1..MAX)) 1388 -- AcpNodeName as specified in this document carries the 1389 -- acp-node-name as specified in the ABNF in Section 6.1.2 1391 END 1393 Figure 3 1395 6.2.3. ACP domain membership check 1397 The following points constitute the ACP domain membership check of a 1398 candidate peer via its certificate: 1400 1: The peer has proved ownership of the private key associated with 1401 the certificate's public key. This check is performed by the 1402 security association protocol used, for example [RFC7296], section 1403 2.15. 1405 2: The peer's certificate passes certificate path validation as 1406 defined in [RFC5280], section 6 against one of the TA associated 1407 with the ACP node's ACP certificate (see Section 6.2.4 below). 1408 This includes verification of the validity (lifetime) of the 1409 certificates in the path. 1410 3: If the peer's certificate indicates a Certificate Revocation List 1411 (CRL) Distribution Point (CRLDP) ([RFC5280], section 4.2.1.13) or 1412 Online Certificate Status Protocol (OCSP) responder ([RFC5280], 1413 section 4.2.2.1), then the peer's certificate MUST be valid 1414 according to those mechanisms when they are available: An OCSP 1415 check for the peer's certificate across the ACP must succeed or 1416 the peer certificate must not be listed in the CRL retrieved from 1417 the CRLDP. These mechanisms are not available when the ACP node 1418 has no ACP or non-ACP connectivity to retrieve a current CRL or 1419 access an OCSP responder and the security association protocol 1420 itself has also no way to communicate CRL or OCSP check. 1421 Retries to learn revocation via OCSP/CRL SHOULD be made using the 1422 same backoff as described in Section 6.7. If and when the ACP 1423 node then learns that an ACP peer's certificate is invalid for 1424 which rule 3 had to be skipped during ACP secure channel 1425 establishment, then the ACP secure channel to that peer MUST be 1426 closed even if this peer is the only connectivity to access CRL/ 1427 OCSP. This applies (of course) to all ACP secure channels to this 1428 peer if there are multiple. The ACP secure channel connection 1429 MUST be retried periodically to support the case that the neighbor 1430 acquires a new, valid certificate. 1431 4: The peer's certificate has a syntactically valid acp-node-name 1432 field and the acp-domain-name in that peer's acp-node-name is the 1433 same as in this ACP node's certificate (lowercase normalized). 1435 When checking a candidate peer's certificate for the purpose of 1436 establishing an ACP secure channel, one additional check is 1437 performed: 1439 5: The acp-address field of the candidate peer certificate's 1440 AcpNodeName is not omitted but either 32HEXDIG or 0, according to 1441 Figure 2. 1443 Technically, ACP secure channels can only be built with nodes that 1444 have an acp-address. Rule 5 ensures that this is taken into account 1445 during ACP domain membership check. 1447 Nodes with an omitted acp-address field can only use their ACP domain 1448 certificate for non-ACP-secure channel authentication purposes. This 1449 includes for example NMS type nodes permitted to communicate into the 1450 ACP via ACP connect (Section 8.1) 1451 The special value 0 in an ACP certificates acp-address field is used 1452 for nodes that can and should determine their ACP address through 1453 other mechanisms than learning it through the acp-address field in 1454 their ACP certificate. These ACP nodes are permitted to establish 1455 ACP secure channels. Mechanisms for those nodes to determine their 1456 ACP address are outside the scope of this specification, but this 1457 option is defined here so that any ACP nodes can build ACP secure 1458 channels to them according to Rule 5. 1460 The optional rsub field of the AcpNodeName is not relevant to the ACP 1461 domain membership check because it only serves to structure routing 1462 and addressing within an ACP but not to segment mutual 1463 authentication/authorization (hence the name "routing subdomain"). 1465 In summary: 1467 * Steps 1...4 constitute standard certificate validity verification 1468 and private key authentication as defined by [RFC5280] and 1469 security association protocols (such as Internet Key Exchange 1470 Protocol version 2 IKEv2 [RFC7296] when leveraging certificates. 1471 * Steps 1...4 do not include verification of any pre-existing form 1472 of non-public-key-only based identity elements of a certificate 1473 such as a web servers domain name prefix often encoded in 1474 certificate common name. Step 5 is an equivalent step for the 1475 AcpNodeName. 1476 * Step 4 constitutes standard CRL/OCSP checks refined for the case 1477 of missing connectivity and limited functionality security 1478 association protocols. 1479 * Steps 1...4 authorize to build any secure connection between 1480 members of the same ACP domain except for ACP secure channels. 1481 * Step 5 is the additional verification of the presence of an ACP 1482 address as necessary for ACP secure channels. 1483 * Steps 1...5 therefore authorize to build an ACP secure channel. 1485 For brevity, the remainder of this document refers to this process 1486 only as authentication instead of as authentication and 1487 authorization. 1489 [RFC-Editor: Please remove the following paragraph]. 1491 Note that the ACP domain membership check does not verify the network 1492 layer address of the security association. See [ACPDRAFT], 1493 Appendix B.2 for explanations. 1495 6.2.3.1. Realtime clock and Time Validation 1497 An ACP node with a realtime clock in which it has confidence, MUST 1498 check the time stamps when performing ACP domain membership check 1499 such as the certificate validity period in step 1. and the respective 1500 times in step 4 for revocation information (e.g., signingTimes in CMS 1501 signatures). 1503 An ACP node without such a realtime clock MAY ignore those time stamp 1504 validation steps if it does not know the current time. Such an ACP 1505 node SHOULD obtain the current time in a secured fashion, such as via 1506 a Network Time Protocol signaled through the ACP. It then ignores 1507 time stamp validation only until the current time is known. In the 1508 absence of implementing a secured mechanism, such an ACP node MAY use 1509 a current time learned in an insecure fashion in the ACP domain 1510 membership check. 1512 Current time MAY for example be learned unsecured via NTP ([RFC5905]) 1513 over the same link-local IPv6 addresses used for the ACP from 1514 neighboring ACP nodes. ACP nodes that do provide NTP insecure over 1515 their link-local addresses SHOULD primarily run NTP across the ACP 1516 and provide NTP time across the ACP only when they have a trusted 1517 time source. Details for such NTP procedures are beyond the scope of 1518 this specification. 1520 Beside ACP domain membership check, the ACP itself has no dependency 1521 against knowledge of the current time, but protocols and services 1522 using the ACP will likely have the need to know the current time. 1523 For example, event logging. 1525 6.2.4. Trust Anchors (TA) 1527 ACP nodes need TA information according to [RFC5280], section 6.1.1 1528 (d), typically in the form of one or more certificate of the TA to 1529 perform certificate path validation as required by Section 6.2.3, 1530 rule 2. TA information MUST be provisioned to an ACP node (together 1531 with its ACP domain certificate) by an ACP Registrar during initial 1532 enrollment of a candidate ACP node. ACP nodes MUST also support 1533 renewal of TA information via EST as described below in 1534 Section 6.2.5. 1536 The required information about a TA can consist of not only a single, 1537 but multiple certificates as required for dealing with CA certificate 1538 renewals as explained in Section 4.4 of CMP ([RFC4210]). 1540 A certificate path is a chain of certificates starting at the ACP 1541 certificate (leaf/end-entity) followed by zero or more intermediate 1542 CA certificates and ending with the TA information, which are 1543 typically one or two the self-signed certificates of the TA. The CA 1544 that signs the ACP certificate is called the assigning CA. If there 1545 are no intermediate CA, then the assigning CA is the TA. Certificate 1546 path validation authenticates that the ACP certificate is permitted 1547 by a TA associated with the ACP, directly or indirectly via one or 1548 more intermediate CA. 1550 Note that different ACP nodes may have different intermediate CA in 1551 their certificate path and even different TA. The set of TA for an 1552 ACP domain must be consistent across all ACP members so that any ACP 1553 node can authenticate any other ACP node. The protocols through 1554 which ACP domain membership check rules 1-3 are performed need to 1555 support the exchange not only of the ACP nodes certificates, but also 1556 exchange of the intermedia TA. 1558 ACP nodes MUST support for the ACP domain membership check the 1559 certificate path validation with 0 or 1 intermediate CA. They SHOULD 1560 support 2 intermediate CA and two TA (to permit migration to from one 1561 TA to another TA). 1563 Certificates for an ACP MUST only be given to nodes that are allowed 1564 to be members of that ACP. When the signing CA relies on an ACP 1565 Registrar, the CA MUST only sign certificates with acp-node-name 1566 through trusted ACP Registrars. In this setup, any existing CA, 1567 unaware of the formatting of acp-node-name, can be used. 1569 These requirements can be achieved by using a TA private to the owner 1570 of the ACP domain or potentially through appropriate contractual 1571 agreements between the involved parties (Registrar and CA). Using 1572 public CA is out of scope of this document. [RFC-Editor: please 1573 remove the following sentence]. See [ACPDRAFT], Appendix B.3 for 1574 further considerations. 1576 A single owner can operate multiple independent ACP domains from the 1577 same set of TA. Registrars must then know which ACP a node needs to 1578 be enrolled into. 1580 6.2.5. Certificate and Trust Anchor Maintenance 1582 ACP nodes MUST support renewal of their Certificate and TA 1583 information via EST and MAY support other mechanisms. See 1584 Section 6.1 for TLS requirements. An ACP network MUST have at least 1585 one ACP node supporting EST server functionality across the ACP so 1586 that EST renewal is useable. 1588 ACP nodes SHOULD be able to remember the IPv6 locator parameters of 1589 the O_IPv6_LOCATOR in GRASP of the EST server from which they last 1590 renewed their ACP certificate. They SHOULD provide the ability for 1591 these EST server parameters to also be set by the ACP Registrar (see 1592 Section 6.11.7) that initially enrolled the ACP device with its ACP 1593 certificate. When BRSKI (see 1594 [I-D.ietf-anima-bootstrapping-keyinfra]) is used, the IPv6 locator of 1595 the BRSKI registrar from the BRSKI TLS connection SHOULD be 1596 remembered and used for the next renewal via EST if that registrar 1597 also announces itself as an EST server via GRASP (see next section) 1598 on its ACP address. 1600 The EST server MUST present a certificate that is passing ACP domain 1601 membership check in its TLS connection setup (Section 6.2.3, rules 1602 1...4, not rule 5 as this is not for an ACP secure channel setup). 1603 The EST server certificate MUST also contain the id-kp-cmcRA 1604 [RFC6402] extended key usage attribute and the EST client MUST check 1605 its presence. 1607 The additional check against the id-kp-cmcRA extended key usage 1608 extension field ensures that clients do not fall prey to an illicit 1609 EST server. While such illicit EST servers should not be able to 1610 support certificate signing requests (as they are not able to elicit 1611 a signing response from a valid CA), such an illicit EST server would 1612 be able to provide faked CA certificates to EST clients that need to 1613 renew their CA certificates when they expire. 1615 Note that EST servers supporting multiple ACP domains will need to 1616 have for each of these ACP domains a separate certificate and respond 1617 on a different transport address (IPv6 address and/or TCP port), but 1618 this is easily automated on the EST server as long as the CA does not 1619 restrict registrars to request certificates with the id-kp-cmcRA 1620 extended usage extension for themselves. 1622 6.2.5.1. GRASP objective for EST server 1624 ACP nodes that are EST servers MUST announce their service via GRASP 1625 in the ACP through M_FLOOD messages. See [I-D.ietf-anima-grasp], 1626 section 2.8.11 for the definition of this message type: 1628 Example: 1630 [M_FLOOD, 12340815, h'fd89b714f3db0000200000064000001', 210000, 1631 [["SRV.est", 4, 255 ], 1632 [O_IPv6_LOCATOR, 1633 h'fd89b714f3db0000200000064000001', IPPROTO_TCP, 443]] 1634 ] 1636 Figure 4: GRASP SRV.est example 1638 The formal definition of the objective in Concise data definition 1639 language (CDDL) (see [RFC8610]) is as follows: 1641 flood-message = [M_FLOOD, session-id, initiator, ttl, 1642 +[objective, (locator-option / [])]] 1643 ; see example above and explanation 1644 ; below for initiator and ttl 1646 objective = ["SRV.est", objective-flags, loop-count, 1647 objective-value] 1649 objective-flags = sync-only ; as in GRASP spec 1650 sync-only = 4 ; M_FLOOD only requires synchronization 1651 loop-count = 255 ; recommended as there is no mechanism 1652 ; to discover network diameter. 1653 objective-value = any ; reserved for future extensions 1655 Figure 5: GRASP SRV.est definition 1657 The objective name "SRV.est" indicates that the objective is an 1658 [RFC7030] compliant EST server because "est" is an [RFC6335] 1659 registered service name for [RFC7030]. Objective-value MUST be 1660 ignored if present. Backward compatible extensions to [RFC7030] MAY 1661 be indicated through objective-value. Non [RFC7030] compatible 1662 certificate renewal options MUST use a different objective-name. 1663 Non-recognized objective-values (or parts thereof if it is a 1664 structure partially understood) MUST be ignored. 1666 The M_FLOOD message MUST be sent periodically. The default SHOULD be 1667 60 seconds; the value SHOULD be operator configurable but SHOULD be 1668 not smaller than 60 seconds. The frequency of sending MUST be such 1669 that the aggregate amount of periodic M_FLOODs from all flooding 1670 sources cause only negligible traffic across the ACP. The time-to- 1671 live (ttl) parameter SHOULD be 3.5 times the period so that up to 1672 three consecutive messages can be dropped before considering an 1673 announcement expired. In the example above, the ttl is 210000 msec, 1674 3.5 times 60 seconds. When a service announcer using these 1675 parameters unexpectedly dies immediately after sending the M_FLOOD, 1676 receivers would consider it expired 210 seconds later. When a 1677 receiver tries to connect to this dead service before this timeout, 1678 it will experience a failing connection and use that as an indication 1679 that the service instance is dead and select another instance of the 1680 same service instead (from another GRASP announcement). 1682 The "SRV.est" objective(s) SHOULD only be announced when the ACP node 1683 knows that it can successfully communicate with a CA to perform the 1684 EST renewal/rekeying operations for the ACP domain. See also 1685 Section 11. 1687 6.2.5.2. Renewal 1689 When performing renewal, the node SHOULD attempt to connect to the 1690 remembered EST server. If that fails, it SHOULD attempt to connect 1691 to an EST server learned via GRASP. The server with which 1692 certificate renewal succeeds SHOULD be remembered for the next 1693 renewal. 1695 Remembering the last renewal server and preferring it provides 1696 stickiness which can help diagnostics. It also provides some 1697 protection against off-path compromised ACP members announcing bogus 1698 information into GRASP. 1700 Renewal of certificates SHOULD start after less than 50% of the 1701 domain certificate lifetime so that network operations has ample time 1702 to investigate and resolve any problems that causes a node to not 1703 renew its domain certificate in time - and to allow prolonged periods 1704 of running parts of a network disconnected from any CA. 1706 6.2.5.3. Certificate Revocation Lists (CRLs) 1708 The ACP node SHOULD support revocation through CRL(s) via HTTP from 1709 one or more CRL Distribution Points (CRLDP). The CRLDP(s) MUST be 1710 indicated in the Domain Certificate when used. If the CRLDP URL uses 1711 an IPv6 address (ULA address when using the addressing rules 1712 specified in this document), the ACP node will connect to the CRLDP 1713 via the ACP. If the CRLDP uses a domain name, the ACP node will 1714 connect to the CRLDP via the Data-Plane. 1716 It is common to use domain names for CRLDP(s), but there is no 1717 requirement for the ACP to support DNS. Any DNS lookup in the Data- 1718 Plane is not only a possible security issue, but it would also not 1719 indicate whether the resolved address is meant to be reachable across 1720 the ACP. Therefore, the use of an IPv6 address versus the use of a 1721 DNS name doubles as an indicator whether or not to reach the CRLDP 1722 via the ACP. 1724 A CRLDP can be reachable across the ACP either by running it on a 1725 node with ACP or by connecting its node via an ACP connect interface 1726 (see Section 8.1). 1728 When using a private PKI for ACP certificates, the CRL may be need- 1729 to-know, for example to prohibit insight into the operational 1730 practices of the domain by tracking the growth of the CRL. In this 1731 case, HTTPS may be chosen to provide confidentiality, especially when 1732 making the CRL available via the Data-Plane. Authentication and 1733 authorization SHOULD use ACP certificates and ACP domain membership 1734 check. The CRLDP MAY omit the CRL verification during authentication 1735 of the peer to permit retrieval of the CRL by an ACP node with 1736 revoked ACP certificate. This can allow for that (ex) ACP node to 1737 quickly discover its ACP certificate revocation. This may violate 1738 the desired need-to-know requirement though. ACP nodes MAY support 1739 CRLDP operations via HTTPS. 1741 6.2.5.4. Lifetimes 1743 Certificate lifetime may be set to shorter lifetimes than customary 1744 (1 year) because certificate renewal is fully automated via ACP and 1745 EST. The primary limiting factor for shorter certificate lifetimes 1746 is load on the EST server(s) and CA. It is therefore recommended 1747 that ACP certificates are managed via a CA chain where the assigning 1748 CA has enough performance to manage short lived certificates. See 1749 also Section 9.2.4 for discussion about an example setup achieving 1750 this. See also [I-D.ietf-acme-star]. 1752 When certificate lifetimes are sufficiently short, such as few hours, 1753 certificate revocation may not be necessary, allowing to simplify the 1754 overall certificate maintenance infrastructure. 1756 See Appendix A.2 for further optimizations of certificate maintenance 1757 when BRSKI can be used ("Bootstrapping Remote Secure Key 1758 Infrastructures", see [I-D.ietf-anima-bootstrapping-keyinfra]). 1760 6.2.5.5. Re-enrollment 1762 An ACP node may determine that its ACP certificate has expired, for 1763 example because the ACP node was powered down or disconnected longer 1764 than its certificate lifetime. In this case, the ACP node SHOULD 1765 convert to a role of a re-enrolling candidate ACP node. 1767 In this role, the node does maintain the TA and certificate chain 1768 associated with its ACP certificate exclusively for the purpose of 1769 re-enrollment, and attempts (or waits) to get re-enrolled with a new 1770 ACP certificate. The details depend on the mechanisms/protocols used 1771 by the ACP Registrars. 1773 Please refer to Section 6.11.7 and 1774 [I-D.ietf-anima-bootstrapping-keyinfra] for explanations about ACP 1775 Registrars and vouchers as used in the following text. When ACP is 1776 intended to be used without BRSKI, the details about BRSKI and 1777 vouchers in the following text can be skipped. 1779 When BRSKI is used (i.e.: on ACP nodes that are ANI nodes), the re- 1780 enrolling candidate ACP node would attempt to enroll like a candidate 1781 ACP node (BRSKI pledge), but instead of using the ACP nodes IDevID 1782 certificate, it SHOULD first attempt to use its ACP domain 1783 certificate in the BRSKI TLS authentication. The BRSKI registrar MAY 1784 honor this certificate beyond its expiration date purely for the 1785 purpose of re-enrollment. Using the ACP node's domain certificate 1786 allows the BRSKI registrar to learn that node's acp-node-name, so 1787 that the BRSKI registrar can re-assign the same ACP address 1788 information to the ACP node in the new ACP certificate. 1790 If the BRSKI registrar denies the use of the old ACP certificate, the 1791 re-enrolling candidate ACP node MUST re-attempt re-enrollment using 1792 its IDevID certificate as defined in BRSKI during the TLS connection 1793 setup. 1795 Both when the BRSKI connection is attempted with the old ACP 1796 certificate or the IDevID certificate, the re-enrolling candidate ACP 1797 node SHOULD authenticate the BRSKI registrar during TLS connection 1798 setup based on its existing TA certificate chain information 1799 associated with its old ACP certificate. The re-enrolling candidate 1800 ACP node SHOULD only fall back to requesting a voucher from the BRSKI 1801 registrar when this authentication fails during TLS connection setup. 1802 As a countermeasure against attacks that attempt to force the ACP 1803 node to forget its prior (expired) certificate and TA, the ACP node 1804 should alternate between attempting to re-enroll using its old keying 1805 material and attempting to re-enroll with its IDevID and requesting a 1806 voucher. 1808 When other mechanisms than BRSKI are used for ACP certificate 1809 enrollment, the principles of the re-enrolling candidate ACP node are 1810 the same. The re-enrolling candidate ACP node attempts to 1811 authenticate any ACP Registrar peers during re-enrollment protocol/ 1812 mechanisms via its existing certificate chain/TA information and 1813 provides its existing ACP certificate and other identification (such 1814 as the IDevID certificate) as necessary to the registrar. 1816 Maintaining existing TA information is especially important when 1817 enrollment mechanisms are used that unlike BRSKI do not leverage a 1818 mechanism (such as the voucher in BRSKI) to authenticate the ACP 1819 registrar and where therefore the injection of certificate failures 1820 could otherwise make the ACP node easily attackable remotely by 1821 returning the ACP node to a "duckling" state in which it accepts to 1822 be enrolled by any network it connects to. The (expired) ACP 1823 certificate and ACP TA SHOULD therefore be maintained and attempted 1824 to be used as one possible credential for re-enrollment until new 1825 keying material is acquired. 1827 When using BRSKI or other protocol/mechanisms supporting vouchers, 1828 maintaining existing TA information allows for re-enrollment of 1829 expired ACP certificates to be more lightweight, especially in 1830 environments where repeated acquisition of vouchers during the 1831 lifetime of ACP nodes may be operationally expensive or otherwise 1832 undesirable. 1834 6.2.5.6. Failing Certificates 1836 An ACP certificate is called failing in this document, if/when the 1837 ACP node to which the certificate was issued can determine that it 1838 was revoked (or explicitly not renewed), or in the absence of such 1839 explicit local diagnostics, when the ACP node fails to connect to 1840 other ACP nodes in the same ACP domain using its ACP certificate. 1841 For connection failures to determine the ACP certificate as the 1842 culprit, the peer should pass the domain membership check 1843 (Section 6.2.3) and other reasons for the connection failure can be 1844 excluded because of the connection error diagnostics. 1846 This type of failure can happen during setup/refresh of a secure ACP 1847 channel connections or any other use of the ACP certificate, such as 1848 for the TLS connection to an EST server for the renewal of the ACP 1849 domain certificate. 1851 Example reasons for failing certificates that the ACP node can only 1852 discover through connection failure are that the domain certificate 1853 or any of its signing certificates could have been revoked or may 1854 have expired, but the ACP node cannot self-diagnose this condition 1855 directly. Revocation information or clock synchronization may only 1856 be available across the ACP, but the ACP node cannot build ACP secure 1857 channels because ACP peers reject the ACP node's domain certificate. 1859 ACP nodes SHOULD support the option to determines whether its ACP 1860 certificate is failing, and when it does, put itself into the role of 1861 a re-enrolling candidate ACP node as explained above 1862 (Section 6.2.5.5). 1864 6.3. ACP Adjacency Table 1866 To know to which nodes to establish an ACP channel, every ACP node 1867 maintains an adjacency table. The adjacency table contains 1868 information about adjacent ACP nodes, at a minimum: Node-ID 1869 (identifier of the node inside the ACP, see Section 6.11.3 and 1870 Section 6.11.5), interface on which neighbor was discovered (by GRASP 1871 as explained below), link-local IPv6 address of neighbor on that 1872 interface, certificate (including acp-node-name). An ACP node MUST 1873 maintain this adjacency table. This table is used to determine to 1874 which neighbor an ACP connection is established. 1876 Where the next ACP node is not directly adjacent (i.e., not on a link 1877 connected to this node), the information in the adjacency table can 1878 be supplemented by configuration. For example, the Node-ID and IP 1879 address could be configured. See Section 8.2. 1881 The adjacency table MAY contain information about the validity and 1882 trust of the adjacent ACP node's certificate. However, subsequent 1883 steps MUST always start with the ACP domain membership check against 1884 the peer (see Section 6.2.3). 1886 The adjacency table contains information about adjacent ACP nodes in 1887 general, independently of their domain and trust status. The next 1888 step determines to which of those ACP nodes an ACP connection should 1889 be established. 1891 6.4. Neighbor Discovery with DULL GRASP 1893 [RFC-Editor: GRASP draft is in RFC editor queue, waiting for 1894 dependencies, including ACP. Please ensure that references to I- 1895 D.ietf-anima-grasp that include section number references (throughout 1896 this document) will be updated in case any last-minute changes in 1897 GRASP would make those section references change. 1899 Discovery Unsolicited Link-Local (DULL) GRASP is a limited subset of 1900 GRASP intended to operate across an insecure link-local scope. See 1901 section 2.5.2 of [I-D.ietf-anima-grasp] for its formal definition. 1902 The ACP uses one instance of DULL GRASP for every L2 interface of the 1903 ACP node to discover link level adjacent candidate ACP neighbors. 1904 Unless modified by policy as noted earlier (Section 5 bullet point 1905 2.), native interfaces (e.g., physical interfaces on physical nodes) 1906 SHOULD be initialized automatically to a state in which ACP discovery 1907 can be performed and any native interfaces with ACP neighbors can 1908 then be brought into the ACP even if the interface is otherwise not 1909 configured. Reception of packets on such otherwise not configured 1910 interfaces MUST be limited so that at first only IPv6 StateLess 1911 Address Auto Configuration (SLAAC - [RFC4862]) and DULL GRASP work 1912 and then only the following ACP secure channel setup packets - but 1913 not any other unnecessary traffic (e.g., no other link-local IPv6 1914 transport stack responders for example). 1916 Note that the use of the IPv6 link-local multicast address 1917 (ALL_GRASP_NEIGHBORS) implies the need to use Multicast Listener 1918 Discovery Version 2 (MLDv2, see [RFC3810]) to announce the desire to 1919 receive packets for that address. Otherwise DULL GRASP could fail to 1920 operate correctly in the presence of MLD snooping ([RFC4541]) 1921 switches that are not ACP supporting/enabled - because those switches 1922 would stop forwarding DULL GRASP packets. Switches not supporting 1923 MLD snooping simply need to operate as pure L2 bridges for IPv6 1924 multicast packets for DULL GRASP to work. 1926 ACP discovery SHOULD NOT be enabled by default on non-native 1927 interfaces. In particular, ACP discovery MUST NOT run inside the ACP 1928 across ACP virtual interfaces. See Section 9.3 for further, non- 1929 normative suggestions on how to enable/disable ACP at node and 1930 interface level. See Section 8.2.2 for more details about tunnels 1931 (typical non-native interfaces). See Section 7 for how ACP should be 1932 extended on devices operating (also) as L2 bridges. 1934 Note: If an ACP node also implements BRSKI to enroll its ACP 1935 certificate (see Appendix A.2 for a summary), then the above 1936 considerations also apply to GRASP discovery for BRSKI. Each DULL 1937 instance of GRASP set up for ACP is then also used for the discovery 1938 of a bootstrap proxy via BRSKI when the node does not have a domain 1939 certificate. Discovery of ACP neighbors happens only when the node 1940 does have the certificate. The node therefore never needs to 1941 discover both a bootstrap proxy and ACP neighbor at the same time. 1943 An ACP node announces itself to potential ACP peers by use of the 1944 "AN_ACP" objective. This is a synchronization objective intended to 1945 be flooded on a single link using the GRASP Flood Synchronization 1946 (M_FLOOD) message. In accordance with the design of the Flood 1947 message, a locator consisting of a specific link-local IP address, IP 1948 protocol number and port number will be distributed with the flooded 1949 objective. An example of the message is informally: 1951 [M_FLOOD, 12340815, h'fe80000000000000c0011001feef0000', 210000, 1952 [["AN_ACP", 4, 1, "IKEv2" ], 1953 [O_IPv6_LOCATOR, 1954 h'fe80000000000000c0011001feef0000', IPPROTO_UDP, 15000]] 1955 [["AN_ACP", 4, 1, "DTLS" ], 1956 [O_IPv6_LOCATOR, 1957 h'fe80000000000000c0011001feef0000', IPPROTO_UDP, 17000]] 1958 ] 1959 Figure 6: GRASP AN_ACP example 1961 The formal CDDL definition is: 1963 flood-message = [M_FLOOD, session-id, initiator, ttl, 1964 +[objective, (locator-option / [])]] 1966 objective = ["AN_ACP", objective-flags, loop-count, 1967 objective-value] 1969 objective-flags = sync-only ; as in the GRASP specification 1970 sync-only = 4 ; M_FLOOD only requires synchronization 1971 loop-count = 1 ; limit to link-local operation 1973 objective-value = method-name / [ method, *extension ] 1974 method = method-name / [ method-name, *method-param ] 1975 method-name = "IKEv2" / "DTLS" / id 1976 extension = any 1977 method-param = any 1978 id = text .regexp "[A-Za-z@_$]([-.]*[A-Za-z0-9@_$])*" 1980 Figure 7: GRASP AN_ACP definition 1982 The objective-flags field is set to indicate synchronization. 1984 The loop-count is fixed at 1 since this is a link-local operation. 1986 In the above example the RECOMMENDED period of sending of the 1987 objective is 60 seconds. The indicated ttl of 210000 msec means that 1988 the objective would be cached by ACP nodes even when two out of three 1989 messages are dropped in transit. 1991 The session-id is a random number used for loop prevention 1992 (distinguishing a message from a prior instance of the same message). 1993 In DULL this field is irrelevant but has to be set according to the 1994 GRASP specification. 1996 The originator MUST be the IPv6 link local address of the originating 1997 ACP node on the sending interface. 1999 The method-name in the 'objective-value' parameter is a string 2000 indicating the protocol available at the specified or implied 2001 locator. It is a protocol supported by the node to negotiate a 2002 secure channel. IKEv2 as shown above is the protocol used to 2003 negotiate an IPsec secure channel. 2005 Method-params allows to carry method specific parameters. This 2006 specification does not define any method-param(s) for "IKEv2" or 2007 "DTLS". Method-params for these two methods that are not understood 2008 by an ACP node MUST be ignored by it. 2010 extension(s) allows to define method independent parameters. This 2011 specification does not define any extensions. Extensions not 2012 understood by an ACP node MUST be ignored by it. 2014 The locator-option is optional and only required when the secure 2015 channel protocol is not offered at a well-defined port number, or if 2016 there is no well-defined port number. 2018 IKEv2 is the actual protocol used to negotiate an Internet Protocol 2019 security architecture (IPsec) connection. GRASP therefore indicates 2020 "IKEv2" and not "IPsec". If "IPsec" was used, this too could mean 2021 use of the obsolete older version IKE (v1) ([RFC2409]). IKEv2 has an 2022 IANA assigned port number 500, but in the above example, the 2023 candidate ACP neighbor is offering ACP secure channel negotiation via 2024 IKEv2 on port 15000 (purely to show through the example that GRASP 2025 allows to indicate the port number and it does not have to be the 2026 IANA assigned one). 2028 There is no default UDP port for DTLS, it is always locally assigned 2029 by the node. For further details about the "DTLS" secure channel 2030 protocol, see Section 6.8.4. 2032 If a locator is included, it MUST be an O_IPv6_LOCATOR, and the IPv6 2033 address MUST be the same as the initiator address (these are DULL 2034 requirements to minimize third party DoS attacks). 2036 The secure channel methods defined in this document use the 2037 objective-values of "IKEv2" and "DTLS". There is no distinction 2038 between IKEv2 native and GRE-IKEv2 because this is purely negotiated 2039 via IKEv2. 2041 A node that supports more than one secure channel protocol method 2042 needs to flood multiple versions of the "AN_ACP" objective so that 2043 each method can be accompanied by its own locator-option. This can 2044 use a single GRASP M_FLOOD message as shown in Figure 6. 2046 The use of DULL GRASP primarily serves to discover the link-local 2047 IPv6 address of candidate ACP peers on subnets. The signaling of the 2048 supported secure channel option is primarily for diagnostic purposes, 2049 but it is also necessary for discovery when the protocol has no well- 2050 known transport address, such as in the case of DTLS. [RFC-Editor: 2051 Please remove the following sentence]. See [ACPDRAFT], Appendix B.4. 2053 Note that a node serving both as an ACP node and BRSKI Join Proxy may 2054 choose to distribute the "AN_ACP" objective and the respective BRSKI 2055 in the same M_FLOOD message, since GRASP allows multiple objectives 2056 in one message. This may be impractical though if ACP and BRSKI 2057 operations are implemented via separate software modules / ASAs. 2059 The result of the discovery is the IPv6 link-local address of the 2060 neighbor as well as its supported secure channel protocols (and non- 2061 standard port they are running on). It is stored in the ACP 2062 Adjacency Table (see Section 6.3), which then drives the further 2063 building of the ACP to that neighbor. 2065 Note that the DULL GRASP objective described intentionally does not 2066 include the ACP node's ACP certificate even though this would be 2067 useful for diagnostics and to simplify the security exchange in ACP 2068 secure channel security association protocols (see Section 6.8). The 2069 reason is that DULL GRASP messages are periodically multicasted 2070 across IPv6 subnets and full certificates could easily lead to 2071 fragmented IPv6 DULL GRASP multicast packets due to the size of a 2072 certificate. This would be highly undesirable. 2074 6.5. Candidate ACP Neighbor Selection 2076 An ACP node determines to which other ACP nodes in the adjacency 2077 table it should attempt to build an ACP connection. This is based on 2078 the information in the ACP Adjacency table. 2080 The ACP is established exclusively between nodes in the same domain. 2081 This includes all routing subdomains. Appendix A.6 explains how ACP 2082 connections across multiple routing subdomains are special. 2084 The result of the candidate ACP neighbor selection process is a list 2085 of adjacent or configured autonomic neighbors to which an ACP channel 2086 should be established. The next step begins that channel 2087 establishment. 2089 6.6. Channel Selection 2091 To avoid attacks, initial discovery of candidate ACP peers cannot 2092 include any non-protected negotiation. To avoid re-inventing and 2093 validating security association mechanisms, the next step after 2094 discovering the address of a candidate neighbor can only be to try 2095 first to establish a security association with that neighbor using a 2096 well-known security association method. 2098 From the use-cases it seems clear that not all type of ACP nodes can 2099 or need to connect directly to each other or are able to support or 2100 prefer all possible mechanisms. For example, code space limited IoT 2101 devices may only support DTLS because that code exists already on 2102 them for end-to-end security, but low-end in-ceiling L2 switches may 2103 only want to support Media Access Control Security (MacSec, see 2104 802.1AE ([MACSEC]) because that is also supported in their chips. 2105 Only a flexible gateway device may need to support both of these 2106 mechanisms and potentially more. Note that MacSec is not required by 2107 any profiles of the ACP in this specification. Instead, MacSec is 2108 mentioned as a likely next interesting secure channel protocol. Note 2109 also that the security model allows and requires for any-to-any 2110 authentication and authorization between all ACP nodes because there 2111 is also end-to-end and not only hop-by-hop authentication for secure 2112 channels. 2114 To support extensible secure channel protocol selection without a 2115 single common mandatory to implement (MTI) protocol, ACP nodes MUST 2116 try all the ACP secure channel protocols it supports and that are 2117 feasible because the candidate ACP neighbor also announced them via 2118 its AN_ACP GRASP parameters (these are called the "feasible" ACP 2119 secure channel protocols). 2121 To ensure that the selection of the secure channel protocols always 2122 succeeds in a predictable fashion without blocking, the following 2123 rules apply: 2125 * An ACP node may choose to attempt to initiate the different 2126 feasible ACP secure channel protocols it supports according to its 2127 local policies sequentially or in parallel, but it MUST support 2128 acting as a responder to all of them in parallel. 2129 * Once the first ACP secure channel protocol connection to a 2130 specific peer IPv6 address passes peer authentication, the two 2131 peers know each other's certificate because those ACP certificates 2132 are used by all secure channel protocols for mutual 2133 authentication. The peer with the higher Node-ID in the 2134 AcpNodeName of its ACP certificate takes on the role of the 2135 Decider towards the peer. The other peer takes on the role of the 2136 Follower. The Decider selects which secure channel protocol to 2137 ultimately use. 2138 * The Follower becomes passive: it does not attempt to further 2139 initiate ACP secure channel protocol connections with the Decider 2140 and does not consider it to be an error when the Decider closes 2141 secure channels. The Decider becomes the active party, continues 2142 to attempt setting up secure channel protocols with the Follower. 2143 This process terminates when the Decider arrives at the "best" ACP 2144 secure channel connection option that also works with the Follower 2145 ("best" from the Deciders point of view). 2146 * A peer with a "0" acp-address in its AcpNodeName takes on the role 2147 of Follower when peering with a node that has a non-"0" acp- 2148 address (note that this specification does not fully define the 2149 behavior of ACP secure channel negotiation for nodes with a "0" 2150 ACP address field, it only defines interoperability with such ACP 2151 nodes). 2153 In a simple example, ACP peer Node 1 attempts to initiate an IPsec 2154 via IKEv2 connection to peer Node 2. The IKEv2 authentication 2155 succeeds. Node 1 has the lower ACP address and becomes the Follower. 2156 Node 2 becomes the Decider. IKEv2 might not be the preferred ACP 2157 secure channel protocol for the Decider Node 2. Node 2 would 2158 therefore proceed to attempt secure channel setups with (in its view) 2159 more preferred protocol options (e.g., DTLS/UDP). If any such 2160 preferred ACP secure channel connection of the Decider succeeds, it 2161 would close the IPsec connection. If Node 2 has no preferred 2162 protocol option over IPsec, or no such connection attempt from Node 2 2163 to Node 1 succeeds, Node 2 would keep the IPsec connection and use 2164 it. 2166 The Decider SHOULD NOT send actual payload packets across a secure 2167 channel until it has decided to use it. The Follower MAY delay 2168 linking the ACP secure channel into the ACP virtual interface until 2169 it sees the first payload packet from the Decider up to a maximum of 2170 5 seconds to avoid unnecessarily linking a secure channel that will 2171 be terminated as undesired by the Decider shortly afterwards. 2173 The following sequence of steps show this example in more detail. 2174 Each step is tagged with [{:}]. The connection is 2175 included to more easily distinguish which of the two competing 2176 connections the step belongs to, one initiated by Node 1, one 2177 initiated by Node 2. 2179 [1] Node 1 sends GRASP AN_ACP message to announce itself 2181 [2] Node 2 sends GRASP AN_ACP message to announce itself 2183 [3] Node 2 receives [1] from Node 1 2185 [4:C1] Because of [3], Node 2 starts as initiator on its 2186 preferred secure channel protocol towards Node 1. 2187 Connection C1. 2189 [5] Node 1 receives [2] from Node 2 2191 [6:C2] Because of [5], Node 1 starts as initiator on its 2192 preferred secure channel protocol towards Node 2. 2193 Connection C2. 2195 [7:C1] Node1 and Node2 have authenticated each others 2196 certificate on connection C1 as valid ACP peers. 2198 [8:C1] Node 1 certificate has lower ACP Node-ID than Node2, therefore 2199 Node 1 considers itself the Follower and Node 2 the Decider 2200 on connection C1. Connection setup C1 is completed. 2202 [9] Node 1 refrains from attempting any further secure channel 2203 connections to Node 2 (the Decider) as learned from [2] 2204 because it knows from [8:C1] that it is the Follower 2205 relative to Node 1. 2207 [10:C2] Node1 and Node2 have authenticated each others 2208 certificate on connection C2 (like [7:C1]). 2210 [11:C2] Node 1 certificate has lower ACP Node-ID than Node2, 2211 therefore Node 1 considers itself the Follower and Node 2 the 2212 Decider on connection C2, but they also identify that C2 is 2213 to the same mutual peer as their C1, so this has no further 2214 impact: the roles Decider and Follower where already assigned 2215 between these two peers by [8:C1]. 2217 [12:C2] Node 2 (the Decider) closes C1. Node 1 is fine with this, 2218 because of its role as the Follower (from [8:C1]). 2220 [13] Node 2 (the Decider) and Node 1 (the Follower) start data 2221 transfer across C2, which makes it become a secure channel 2222 for the ACP. 2224 Figure 8: Secure Channel sequence of steps 2226 All this negotiation is in the context of an "L2 interface". The 2227 Decider and Follower will build ACP connections to each other on 2228 every "L2 interface" that they both connect to. An autonomic node 2229 MUST NOT assume that neighbors with the same L2 or link-local IPv6 2230 addresses on different L2 interfaces are the same node. This can 2231 only be determined after examining the certificate after a successful 2232 security association attempt. 2234 The Decider SHOULD NOT suppress attempting a particular ACP secure 2235 channel protocol connection on one L2 interface because this type of 2236 ACP secure channel connection has failed to the peer with the same 2237 ACP certificate on another L2 interface: Not only the supported ACP 2238 secure channel protocol options may be different on the same ACP peer 2239 across different L2 interfaces, but also error conditions may cause 2240 inconsistent failures across different L2 interfaces. Avoiding such 2241 connection attempt optimizations can therefore help to increase 2242 robustness in the case of errors. 2244 6.7. Candidate ACP Neighbor verification 2246 Independent of the security association protocol chosen, candidate 2247 ACP neighbors need to be authenticated based on their domain 2248 certificate. This implies that any secure channel protocol MUST 2249 support certificate based authentication that can support the ACP 2250 domain membership check as defined in Section 6.2.3. If it fails, 2251 the connection attempt is aborted and an error logged. Attempts to 2252 reconnect MUST be throttled. The RECOMMENDED default is exponential 2253 base 2 backoff with an initial retransmission time (IRT) of 10 2254 seconds and a maximum retransmission time (MRT) of 640 seconds. 2256 Failure to authenticate an ACP neighbor when acting in the role of a 2257 responder of the security authentication protocol MUST NOT impact the 2258 attempts of the ACP node to attempt establishing a connection as an 2259 initiator. Only failed connection attempts as an initiator must 2260 cause throttling. This rule is meant to increase resilience of 2261 secure channel creation. Section 6.6 shows how simultaneous mutual 2262 secure channel setup collisions are resolved. 2264 6.8. Security Association (Secure Channel) protocols 2266 This section describes how ACP nodes establish secured data 2267 connections to automatically discovered or configured peers in the 2268 ACP. Section 6.4 above described how IPv6 subnet adjacent peers are 2269 discovered automatically. Section 8.2 describes how non IPv6 subnet 2270 adjacent peers can be configured. 2272 Section 6.13.5.2 describes how secure channels are mapped to virtual 2273 IPv6 subnet interfaces in the ACP. The simple case is to map every 2274 ACP secure channel into a separate ACP point-to-point virtual 2275 interface Section 6.13.5.2.1. When a single subnet has multiple ACP 2276 peers this results in multiple ACP point-to-point virtual interfaces 2277 across that underlying multi-party IPv6 subnet. This can be 2278 optimized with ACP multi-access virtual interfaces 2279 (Section 6.13.5.2.2) but the benefits of that optimization may not 2280 justify the complexity of that option. 2282 6.8.1. General considerations 2284 Due to Channel Selection (Section 6.6), ACP can support an evolving 2285 set of security association protocols and does not require support 2286 for a single network wide MTI. ACP nodes only need to implement 2287 those protocols required to interoperate with their candidate peers, 2288 not with potentially any node in the ACP domain. See Section 6.8.5 2289 for an example of this. 2291 The degree of security required on every hop of an ACP network needs 2292 to be consistent across the network so that there is no designated 2293 "weakest link" because it is that "weakest link" that would otherwise 2294 become the designated point of attack. When the secure channel 2295 protection on one link is compromised, it can be used to send/receive 2296 packets across the whole ACP network. Therefore, even though the 2297 security association protocols can be different, their minimum degree 2298 of security should be comparable. 2300 Secure channel protocols do not need to always support arbitrary L3 2301 connectivity between peers, but can leverage the fact that the 2302 standard use case for ACP secure channels is an L2 adjacency. Hence, 2303 L2 dependent mechanisms could be adopted for use as secure channel 2304 association protocols: 2306 L2 mechanisms such as strong encrypted radio technologies or [MACSEC] 2307 may offer equivalent encryption and the ACP security association 2308 protocol may only be required to authenticate ACP domain membership 2309 of a peer and/or derive a key for the L2 mechanism. Mechanisms to 2310 auto-discover and associate ACP peers leveraging such underlying L2 2311 security are possible and desirable to avoid duplication of 2312 encryption, but none are specified in this document. 2314 Strong physical security of a link may stand in where cryptographic 2315 security is infeasible. As there is no secure mechanism to 2316 automatically discover strong physical security solely between two 2317 peers, it can only be used with explicit configuration and that 2318 configuration too could become an attack vector. This document 2319 therefore only specifies with ACP connect (Section 8.1) one 2320 explicitly configured mechanism without any secure channel 2321 association protocol - for the case where both the link and the nodes 2322 attached to it have strong physical security. 2324 6.8.2. Common requirements 2326 The authentication of peers in any security association protocol MUST 2327 use the ACP certificate according to Section 6.2.3. Because auto- 2328 discovery of candidate ACP neighbors via GRASP (see Section 6.4) as 2329 specified in this document does not communicate the neighbors ACP 2330 certificate, and ACP nodes may not (yet) have any other network 2331 connectivity to retrieve certificates, any security association 2332 protocol MUST use a mechanism to communicate the certificate directly 2333 instead of relying on a referential mechanism such as communicating 2334 only a hash and/or URL for the certificate. 2336 A security association protocol MUST use Forward Secrecy (whether 2337 inherently or as part of a profile of the security association 2338 protocol). 2340 Because the ACP payload of legacy protocol payloads inside the ACP 2341 and hop-by-hop ACP flooded GRASP information is unencrypted, the ACP 2342 secure channel protocol requires confidentiality. Symmetric 2343 encryption for the transmission of secure channel data MUST use 2344 encryption schemes considered to be security wise equal to or better 2345 than 256-bit key strength, such as AES256. There MUST NOT be support 2346 for NULL encryption. 2348 Security association protocols typically only signal the End Entity 2349 certificate (e.g. the ACP certificate) and any possible intermediate 2350 CA certificates for successful mutual authentication. The TA has to 2351 be mutually known and trusted and therefore its certificate does not 2352 need to be signaled for successful mutual authentication. 2353 Nevertheless, for use with ACP secure channel setup, there SHOULD be 2354 the option to include the TA certificate in the signaling to aid 2355 troubleshooting, see Section 9.1.1. 2357 Signaling of TA certificates may not be appropriate when the 2358 deployment is relying on a security model where the TA certificate 2359 content is considered confidential and only its hash is appropriate 2360 for signaling. ACP nodes SHOULD have a mechanism to select whether 2361 the TA certificate is signaled or not. Assuming that both options 2362 are possible with a specific secure channel protocol. 2364 An ACP secure channel MUST immediately be terminated when the 2365 lifetime of any certificate in the chain used to authenticate the 2366 neighbor expires or becomes revoked. This may not be standard 2367 behavior in secure channel protocols because the certificate 2368 authentication may only influence the setup of the secure channel in 2369 these protocols, but may not be re-validated during the lifetime of 2370 the secure connection in the absence of this requirement. 2372 When specifying an additional security association protocol for ACP 2373 secure channels beyond those covered in this document, protocol 2374 options SHOULD be eliminated that are not necessary to support 2375 devices that are expected to be able to support the ACP to minimize 2376 implementation complexity. For example, definitions for security 2377 protocols often include old/inferior security options required only 2378 to interoperate with existing devices that will not be able to update 2379 to the currently preferred security options. Such old/inferior 2380 security options do not need to be supported when a security 2381 association protocol is first specified for the ACP, strengthening 2382 the "weakest link" and simplifying ACP implementation overhead. 2384 6.8.3. ACP via IPsec 2386 An ACP node announces its ability to support IPsec, negotiated via 2387 IKEv2, as the ACP secure channel protocol using the "IKEv2" 2388 objective-value in the "AN_ACP" GRASP objective. 2390 The ACP usage of IPsec and IKEv2 mandates a profile with a narrow set 2391 of options of the current standards-track usage guidance for IPsec 2392 [RFC8221] and IKEv2 [RFC8247]. These option result in stringent 2393 security properties and can exclude deprecated/legacy algorithms 2394 because there is no need for interoperability with legacy equipment 2395 for ACP secure channels. Any such backward compatibility would lead 2396 only to increased attack surface and implementation complexity, for 2397 no benefit. 2399 6.8.3.1. Native IPsec 2401 An ACP node that is supporting native IPsec MUST use IPsec in tunnel 2402 mode, negotiated via IKEv2, and with IPv6 payload (e.g., ESP Next 2403 Header of 41). It MUST use local and peer link-local IPv6 addresses 2404 for encapsulation. Manual keying MUST NOT be used, see Section 6.2. 2405 Traffic Selectors are: 2407 TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 2409 TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 2410 IPsec tunnel mode is required because the ACP will route/forward 2411 packets received from any other ACP node across the ACP secure 2412 channels, and not only its own generated ACP packets. With IPsec 2413 transport mode (and no additional encapsulation header in the ESP 2414 payload), it would only be possible to send packets originated by the 2415 ACP node itself because the IPv6 addresses of the ESP must be the 2416 same as that of the outer IPv6 header. 2418 6.8.3.1.1. RFC8221 (IPsec/ESP) 2420 ACP IPsec implementations MUST comply with [RFC8221] (and its 2421 updates). The requirements from above and this section amend and 2422 superseded its requirements. 2424 The IP Authentication Header (AH) MUST NOT be used (because it does 2425 not provide confidentiality). 2427 For the required ESP encryption algorithms in section 5 of [RFC8221] 2428 the following guidance applies: 2430 * ENCR_NULL AH MUST NOT be used (because it does not provide 2431 confidentiality). 2432 * ENCR_AES_GCM_16 is the only MTI ESP encryption algorithm for ACP 2433 via IPsec/ESP (it is already listed as MUST in [RFC8221]). 2434 * ENCR_AES_CBC with AUTH_HMAC_SHA2_256_128 (as the ESP 2435 authentication algorithm) and ENCR_AES_CCM_8 MAY be supported. If 2436 either provides higher performance than ENCR_AES_GCM_16 it SHOULD 2437 be supported. 2438 * ENCR_CHACHA20_POLY1305 SHOULD be supported at equal or higher 2439 performance than ENCR_AES_GCM_16. If that performance is not 2440 feasible, it MAY be supported. 2442 IKEv2 indicates an order for the offered algorithms. The algorithms 2443 SHOULD be ordered by performance. The first algorithm supported by 2444 both sides is generally chosen. 2446 Explanations: 2448 * There is no requirement to interoperate with legacy equipment in 2449 ACP secure channels, so a single MTI encryption algorithm for 2450 IPsec in ACP secure channels is sufficient for interoperability 2451 and allows for the most lightweight implementations. 2452 * ENCR_AES_GCM_16 is an authenticated encryption with associated 2453 data (AEAD) cipher mode, so no additional ESP authentication 2454 algorithm is needed, simplifying the MTI requirements of IPsec for 2455 the ACP. 2457 * There is no MTI requirement for the support of ENCR_AES_CBC 2458 because ENCR_AES_GCM_16 is assumed to be feasible with less cost/ 2459 higher performance in modern devices hardware accelerated 2460 implementations compared to ENCR-AES_CBC. 2461 * ENCR_CHACHA20_POLY1305 is mandatory in [RFC8221] because of its 2462 target use as a fallback algorithm in case weaknesses in AES are 2463 uncovered. Unfortunately, there is currently no way to 2464 automatically propagate across an ACP a policy to disallow use of 2465 AES based algorithms, so this target benefit of 2466 ENCR_CHACHA20_POLY1305 cannot fully be adopted yet for the ACP. 2467 Therefore, this algorithm is only recommended. Changing from AES 2468 to this algorithm at potentially big drop in performance could 2469 also render the ACP inoperable. Therefore, the performance 2470 requirement against this algorithm so that it could become an 2471 effective security backup to AES for the ACP once a policy to 2472 switch over to it or prefer it is available in an ACP framework. 2474 [RFC8221] allows for 128-bit or 256-bit AES keys. This document 2475 mandates that only 256-bit AES keys MUST be supported. 2477 When [RFC8221] is updated, ACP implementations will need to consider 2478 legacy interoperability, and the IPsec WG has generally done a very 2479 good job of taking that into account in its recommendations. 2481 6.8.3.1.2. RFC8247 (IKEv2) 2483 [RFC8247] provides a baseline recommendation for mandatory to 2484 implement ciphers, integrity checks, pseudo-random-functions and 2485 Diffie-Hellman mechanisms. Those recommendations, and the 2486 recommendations of subsequent documents apply well to the ACP. 2487 Because IKEv2 for ACP secure channels is sufficient to be implemented 2488 in control plane software, rather than in ASIC hardware, and ACP 2489 nodes supporting IKEv2 are not assumed to be code-space constrained, 2490 and because existing IKEv2 implementations are expected to support 2491 [RFC8247] recommendations, this documents makes no attempt to 2492 simplify its recommendations for use with the ACP. 2494 See [IKEV2IANA] for IANA IKEv2 parameter names used in this text. 2496 ACP Nodes supporting IKEv2 MUST comply with [RFC8247] amended by the 2497 following requirements which constitute a policy statement as 2498 permitted by [RFC8247]. 2500 To signal the ACP certificate chain (including TA) as required by 2501 Section 6.8.2, "X.509 Certificate - Signature" payload in IKEv2 can 2502 be used. It is mandatory according to [RFC7296] section 3.6. 2504 ACP nodes SHOULD set up IKEv2 to only use the ACP certificate and TA 2505 when acting as an IKEv2 responder on the IPv6 link local address and 2506 port number indicated in the AN_ACP DULL GRASP announcements (see 2507 Section 6.4). 2509 When CERTREQ is received from a peer, and does not indicate any of 2510 this ACP nodes TA certificates, the ACP node SHOULD ignore the 2511 CERTREQ and continue sending its certificate chain including its TA 2512 as subject to the requirements and explanations in Section 6.8.2. 2513 This will not result in successful mutual authentication but assists 2514 diagnostics. 2516 Note that with IKEv2, failing authentication will only result in the 2517 responder receiving the certificate chain from the initiator, but not 2518 vice versa. Because ACP secure channel setup is symmetric (see 2519 Section 6.7), every non-malicious ACP neighbor will attempt to 2520 connect as an initiator though, allowing to obtain the diagnostic 2521 information about the neighbors certificate. 2523 In IKEv2, ACP nodes are identified by their ACP address. The 2524 ID_IPv6_ADDR IKEv2 identification payload MUST be used and MUST 2525 convey the ACP address. If the peer's ACP certificate includes a 2526 32HEXDIG ACP address in the acp-node-name (not "0" or omitted), the 2527 address in the IKEv2 identification payload MUST match it. See 2528 Section 6.2.3 for more information about "0" or omitted ACP address 2529 fields in the acp-node-name. 2531 IKEv2 authentication MUST use authentication method 14 ("Digital 2532 Signature") for ACP certificates; this authentication method can be 2533 used with both RSA and ECDSA certificates, indicated by an ASN.1 2534 object AlgorithmIdentifier. 2536 The Digital Signature hash SHA2-512 MUST be supported (in addition to 2537 SHA2-256). 2539 The IKEv2 Diffie-Hellman key exchange group 19 (256-bit random ECP), 2540 MUST be supported. Reason: ECC provides a similar security level to 2541 finite-field (MODP) key exchange with a shorter key length, so is 2542 generally preferred absent other considerations. 2544 6.8.3.2. IPsec with GRE encapsulation 2546 In network devices it is often more common to implement high 2547 performance virtual interfaces on top of GRE encapsulation than on 2548 top of a "native" IPsec association (without any other encapsulation 2549 than those defined by IPsec). On those devices it may be beneficial 2550 to run the ACP secure channel on top of GRE protected by the IPsec 2551 association. 2553 The requirements for ESP/IPsec/IKEv2 with GRE are the same as for 2554 native IPsec (see Section 6.8.3.1) except that IPsec transport mode 2555 and next protocol GRE (47) are to be negotiated. Tunnel mode is not 2556 required because of GRE. Traffic Selectors are: 2558 TSi = (47, 0-65535, Initiator-IPv6-LL-addr ... Initiator-IPv6-LL- 2559 addr) 2561 TSr = (47, 0-65535, Responder-IPv6-LL-addr ... Responder-IPv6-LL- 2562 addr) 2564 If IKEv2 initiator and responder support IPsec over GRE, it will be 2565 preferred over native IPsec because of the way how IKEv2 negotiates 2566 transport mode (as used by this IPsec over GRE profile) versus tunnel 2567 mode as used by native IPsec (see [RFC7296], section 1.3.1). The ACP 2568 IPv6 traffic has to be carried across GRE according to [RFC7676]. 2570 6.8.4. ACP via DTLS 2572 This document defines the use of ACP via DTLS, on the assumption that 2573 it is likely the first transport encryption supported in some classes 2574 of constrained devices: DTLS is commonly used in constrained devices 2575 when IPsec is not. Code-space on those devices may be also be too 2576 limited to support more than the minimum number of required 2577 protocols. 2579 An ACP node announces its ability to support DTLS version 1.2 2580 ([RFC6347]) compliant with the requirements defined in this document 2581 as an ACP secure channel protocol in GRASP through the "DTLS" 2582 objective-value in the "AN_ACP" objective (see Section 6.4). 2584 To run ACP via UDP and DTLS, a locally assigned UDP port is used that 2585 is announced as a parameter in the GRASP AN_ACP objective to 2586 candidate neighbors. This port can also be any newer version of DTLS 2587 as long as that version can negotiate a DTLS v1.2 connection in the 2588 presence of an DTLS v1.2 only peer. 2590 All ACP nodes supporting DTLS as a secure channel protocol MUST 2591 adhere to the DTLS implementation recommendations and security 2592 considerations of BCP 195, BCP 195 [RFC7525] except with respect to 2593 the DTLS version. ACP nodes supporting DTLS MUST support DTLS 1.2. 2594 They MUST NOT support older versions of DTLS. 2596 Unlike for IPsec, no attempts are made to simplify the requirements 2597 of the BCP 195 recommendations because the expectation is that DTLS 2598 would be using software-only implementations where the ability to 2599 reuse of widely adopted implementations is more important than 2600 minimizing the complexity of a hardware accelerated implementation 2601 which is known to be important for IPsec. 2603 DTLS v1.3 ([I-D.ietf-tls-dtls13]) is "backward compatible" with DTLS 2604 v1.2 (see section 1. of DTLS v1.3). A DTLS implementation supporting 2605 both DTLS v1.2 and DTLS v1.3 does comply with the above requirements 2606 of negotiating to DTLS v1.2 in the presence of a DTLS v1.2 only peer, 2607 but using DTLS v1.3 when booth peers support it. 2609 Version v1.2 is the MTI version of DTLS in this specification because 2611 * There is more experience with DTLS v1.2 across the spectrum of 2612 target ACP nodes. 2613 * Firmware of lower end, embedded ACP nodes may not support a newer 2614 version for a long time. 2615 * There are significant changes of DTLS v1.3, such as a different 2616 record layer requiring time to gain implementation and deployment 2617 experience especially on lower end, code space limited devices. 2618 * The existing BCP [RFC7525] for DTLS v1.2 may equally take longer 2619 time to be updated with experience from a newer DTLS version. 2620 * There are no significant use-case relevant benefits of DTLS v1.3 2621 over DTLS v1.2 in the context of the ACP options for DTLS. For 2622 example, signaling performance improvements for session setup in 2623 DTLS v1.3 is not important for the ACP given the long-lived nature 2624 of ACP secure channel connections and the fact that DTLS 2625 connections are mostly link-local (short RTT). 2627 Nevertheless, newer versions of DTLS, such as DTLS v1.3 have stricter 2628 security requirements and use of the latest standard protocol version 2629 is for IETF security standards in general recommended. Therefore, 2630 ACP implementations are advised to support all the newer versions of 2631 DTLS that can still negotiate down to DTLS v1.2. 2633 [RFC-editor: if by the time of AUTH48, DTLS 1.3 would have evolved to 2634 be an RFC, then not only would the references to the DTLS v1.3 draft 2635 be changed to the RFC number, but that RFC is then going to be put 2636 into the normative list of references and the above paragraph is 2637 going to be amended to say: Implementations SHOULD support 2638 [DTLSv1.3-RFC]. This is not done right now, because there is no 2639 benefit in potentially waiting in RFC-editor queue for that RFC given 2640 how the text already lays out a non-normative desire to support 2641 DTLSv1.3.] 2642 There is no additional session setup or other security association 2643 besides this simple DTLS setup. As soon as the DTLS session is 2644 functional, the ACP peers will exchange ACP IPv6 packets as the 2645 payload of the DTLS transport connection. oAny DTLS defined security 2646 association mechanisms such as re-keying are used as they would be 2647 for any transport application relying solely on DTLS. 2649 6.8.5. ACP Secure Channel Profiles 2651 As explained in the beginning of Section 6.6, there is no single 2652 secure channel mechanism mandated for all ACP nodes. Instead, this 2653 section defines two ACP profiles (baseline and constrained) for ACP 2654 nodes that do introduce such requirements. 2656 An ACP node supporting the "baseline" profile MUST support IPsec 2657 natively and MAY support IPsec via GRE. An ACP node supporting the 2658 "constrained" profile node that cannot support IPsec MUST support 2659 DTLS. An ACP node connecting an area of constrained ACP nodes with 2660 an area of baseline ACP nodes needs to support IPsec and DTLS and 2661 supports therefore the baseline and constrained profile. 2663 Explanation: Not all type of ACP nodes can or need to connect 2664 directly to each other or are able to support or prefer all possible 2665 secure channel mechanisms. For example, code space limited IoT 2666 devices may only support DTLS because that code exists already on 2667 them for end-to-end security, but high-end core routers may not want 2668 to support DTLS because they can perform IPsec in accelerated 2669 hardware but would need to support DTLS in an underpowered CPU 2670 forwarding path shared with critical control plane operations. This 2671 is not a deployment issue for a single ACP across these type of nodes 2672 as long as there are also appropriate gateway ACP nodes that support 2673 sufficiently many secure channel mechanisms to allow interconnecting 2674 areas of ACP nodes with a more constrained set of secure channel 2675 protocols. On the edge between IoT areas and high-end core networks, 2676 general-purpose routers that act as those gateways and that can 2677 support a variety of secure channel protocols is the norm already. 2679 IPsec natively with tunnel mode provides the shortest encapsulation 2680 overhead. GRE may be preferred by legacy implementations because the 2681 virtual interfaces required by ACP design in conjunction with secure 2682 channels have in the past more often been implemented for GRE than 2683 purely for native IPsec. 2685 ACP nodes need to specify in documentation the set of secure ACP 2686 mechanisms they support and should declare which profile they support 2687 according to above requirements. 2689 6.9. GRASP in the ACP 2691 6.9.1. GRASP as a core service of the ACP 2693 The ACP MUST run an instance of GRASP inside of it. It is a key part 2694 of the ACP services. The function in GRASP that makes it fundamental 2695 as a service of the ACP is the ability to provide ACP wide service 2696 discovery (using objectives in GRASP). 2698 ACP provides IP unicast routing via the RPL routing protocol (see 2699 Section 6.12). 2701 The ACP does not use IP multicast routing nor does it provide generic 2702 IP multicast services (the handling of GRASP link-local multicast 2703 messages is explained in Section 6.9.2). Instead, the ACP provides 2704 service discovery via the objective discovery/announcement and 2705 negotiation mechanisms of the ACP GRASP instance (services are a form 2706 of objectives). These mechanisms use hop-by-hop reliable flooding of 2707 GRASP messages for both service discovery (GRASP M_DISCOVERY 2708 messages) and service announcement (GRASP M_FLOOD messages). 2710 See Appendix A.5 for discussion about this design choice of the ACP. 2712 6.9.2. ACP as the Security and Transport substrate for GRASP 2714 In the terminology of GRASP ([I-D.ietf-anima-grasp]), the ACP is the 2715 security and transport substrate for the GRASP instance run inside 2716 the ACP ("ACP GRASP"). 2718 This means that the ACP is responsible for ensuring that this 2719 instance of GRASP is only sending messages across the ACP GRASP 2720 virtual interfaces. Whenever the ACP adds or deletes such an 2721 interface because of new ACP secure channels or loss thereof, the ACP 2722 needs to indicate this to the ACP instance of GRASP. The ACP exists 2723 also in the absence of any active ACP neighbors. It is created when 2724 the node has a domain certificate, and continues to exist even if all 2725 of its neighbors cease operation. 2727 In this case ASAs using GRASP running on the same node would still 2728 need to be able to discover each other's objectives. When the ACP 2729 does not exist, ASAs leveraging the ACP instance of GRASP via APIs 2730 MUST still be able to operate, and MUST be able to understand that 2731 there is no ACP and that therefore the ACP instance of GRASP cannot 2732 operate. 2734 The following explanation how ACP acts as the security and transport 2735 substrate for GRASP is visualized in Figure 9 below. 2737 GRASP unicast messages inside the ACP always use the ACP address. 2738 Link-local addresses from the ACP VRF MUST NOT be used inside 2739 objectives. GRASP unicast messages inside the ACP are transported 2740 via TLS. See Section 6.1 for TLS requirements. TLS mutual 2741 authentication MUST use the ACP domain membership check defined in 2742 (Section 6.2.3). 2744 GRASP link-local multicast messages are targeted for a specific ACP 2745 virtual interface (as defined Section 6.13.5) but are sent by the ACP 2746 into an ACP GRASP virtual interface that is constructed from the TCP 2747 connection(s) to the IPv6 link-local neighbor address(es) on the 2748 underlying ACP virtual interface. If the ACP GRASP virtual interface 2749 has two or more neighbors, the GRASP link-local multicast messages 2750 are replicated to all neighbor TCP connections. 2752 TCP and TLS connections for GRASP in the ACP use the IANA assigned 2753 TCP port for GRASP (7107). Effectively the transport stack is 2754 expected to be TLS for connections from/to the ACP address (e.g., 2755 global scope address(es)) and TCP for connections from/to link-local 2756 addresses on the ACP virtual interfaces. The latter ones are only 2757 used for flooding of GRASP messages. 2759 ..............................ACP.............................. 2760 . . 2761 . /-GRASP-flooding-\ ACP GRASP instance . 2762 . / \ A 2763 . GRASP GRASP GRASP C 2764 . link-local unicast link-local P 2765 . multicast messages multicast . 2766 . messages | messages . 2767 . | | | . 2768 ............................................................... 2769 . v v v ACP security and transport . 2770 . | | | substrate for GRASP . 2771 . | | | . 2772 . | ACP GRASP | - ACP GRASP A 2773 . | Loopback | Loopback interface C 2774 . | interface | - ACP-cert auth P 2775 . | TLS | . 2776 . ACP GRASP | ACP GRASP - ACP GRASP virtual . 2777 . subnet1 | subnet2 virtual interfaces . 2778 . TCP | TCP . 2779 . | | | . 2780 ............................................................... 2781 . | | | ^^^ Users of ACP (GRASP/ASA) . 2782 . | | | ACP interfaces/addressing . 2783 . | | | . 2784 . | | | A 2785 . | ACP-Loopback Interf.| <- ACP Loopback interface C 2786 . | ACP-address | - address (global ULA) P 2787 . subnet1 | subnet2 <- ACP virtual interfaces . 2788 . link-local | link-local - link-local addresses . 2789 ............................................................... 2790 . | | | ACP VRF . 2791 . | RPL-routing | virtual routing and forwarding . 2792 . | /IP-Forwarding\ | A 2793 . | / \ | C 2794 . ACP IPv6 packets ACP IPv6 packets P 2795 . |/ \| . 2796 . IPsec/DTLS IPsec/DTLS - ACP-cert auth . 2797 ............................................................... 2798 | | Data-Plane 2799 | | 2800 | | - ACP secure channel 2801 link-local link-local - encapsulation addresses 2802 subnet1 subnet2 - Data-Plane interfaces 2803 | | 2804 ACP-Nbr1 ACP-Nbr2 2806 Figure 9: ACP as security and transport substrate for GRASP 2808 6.9.2.1. Discussion 2810 TCP encapsulation for GRASP M_DISCOVERY and M_FLOOD link local 2811 messages is used because these messages are flooded across 2812 potentially many hops to all ACP nodes and a single link with even 2813 temporary packet loss issues (e.g., WiFi/Powerline link) can reduce 2814 the probability for loss free transmission so much that applications 2815 would want to increase the frequency with which they send these 2816 messages. Such shorter periodic retransmission of datagrams would 2817 result in more traffic and processing overhead in the ACP than the 2818 hop-by-hop reliable retransmission mechanism by TCP and duplicate 2819 elimination by GRASP. 2821 TLS is mandated for GRASP non-link-local unicast because the ACP 2822 secure channel mandatory authentication and encryption protects only 2823 against attacks from the outside but not against attacks from the 2824 inside: Compromised ACP members that have (not yet) been detected and 2825 removed (e.g., via domain certificate revocation / expiry). 2827 If GRASP peer connections were to use just TCP, compromised ACP 2828 members could simply eavesdrop passively on GRASP peer connections 2829 for whom they are on-path ("man in the middle" - MITM) or intercept 2830 and modify them. With TLS, it is not possible to completely 2831 eliminate problems with compromised ACP members, but attacks are a 2832 lot more complex: 2834 Eavesdropping/spoofing by a compromised ACP node is still possible 2835 because in the model of the ACP and GRASP, the provider and consumer 2836 of an objective have initially no unique information (such as an 2837 identity) about the other side which would allow them to distinguish 2838 a benevolent from a compromised peer. The compromised ACP node would 2839 simply announce the objective as well, potentially filter the 2840 original objective in GRASP when it is a MITM and act as an 2841 application level proxy. This of course requires that the 2842 compromised ACP node understand the semantics of the GRASP 2843 negotiation to an extent that allows it to proxy it without being 2844 detected, but in an ACP environment this is quite likely public 2845 knowledge or even standardized. 2847 The GRASP TLS connections are run the same as any other ACP traffic 2848 through the ACP secure channels. This leads to double 2849 authentication/encryption, which has the following benefits: 2851 * Secure channel methods such as IPsec may provide protection 2852 against additional attacks, for example reset-attacks. 2853 * The secure channel method may leverage hardware acceleration and 2854 there may be little or no gain in eliminating it. 2856 * There is no different security model for ACP GRASP from other ACP 2857 traffic. Instead, there is just another layer of protection 2858 against certain attacks from the inside which is important due to 2859 the role of GRASP in the ACP. 2861 6.10. Context Separation 2863 The ACP is in a separate context from the normal Data-Plane of the 2864 node. This context includes the ACP channels' IPv6 forwarding and 2865 routing as well as any required higher layer ACP functions. 2867 In classical network system, a dedicated VRF is one logical 2868 implementation option for the ACP. If possible by the systems 2869 software architecture, separation options that minimize shared 2870 components are preferred, such as a logical container or virtual 2871 machine instance. The context for the ACP needs to be established 2872 automatically during bootstrap of a node. As much as possible it 2873 should be protected from being modified unintentionally by ("Data- 2874 Plane") configuration. 2876 Context separation improves security, because the ACP is not 2877 reachable from the Data-Plane routing or forwarding table(s). Also, 2878 configuration errors from the Data-Plane setup do not affect the ACP. 2880 6.11. Addressing inside the ACP 2882 The channels explained above typically only establish communication 2883 between two adjacent nodes. In order for communication to happen 2884 across multiple hops, the autonomic control plane requires ACP 2885 network wide valid addresses and routing. Each ACP node creates a 2886 Loopback interface with an ACP network wide unique address (prefix) 2887 inside the ACP context (as explained in in Section 6.10). This 2888 address may be used also in other virtual contexts. 2890 With the algorithm introduced here, all ACP nodes in the same routing 2891 subdomain have the same /48 ULA prefix. Conversely, ULA global IDs 2892 from different domains are unlikely to clash, such that two ACP 2893 networks can be merged, as long as the policy allows that merge. See 2894 also Section 10.1 for a discussion on merging domains. 2896 Links inside the ACP only use link-local IPv6 addressing, such that 2897 each node's ACP only requires one routable address prefix. 2899 6.11.1. Fundamental Concepts of Autonomic Addressing 2901 * Usage: Autonomic addresses are exclusively used for self- 2902 management functions inside a trusted domain. They are not used 2903 for user traffic. Communications with entities outside the 2904 trusted domain use another address space, for example normally 2905 managed routable address space (called "Data-Plane" in this 2906 document). 2907 * Separation: Autonomic address space is used separately from user 2908 address space and other address realms. This supports the 2909 robustness requirement. 2910 * Loopback-only: Only ACP Loopback interfaces (and potentially those 2911 configured for "ACP connect", see Section 8.1) carry routable 2912 address(es); all other interfaces (called ACP virtual interfaces) 2913 only use IPv6 link local addresses. The usage of IPv6 link local 2914 addressing is discussed in [RFC7404]. 2915 * Use-ULA: For Loopback interfaces of ACP nodes, we use ULA with L=1 2916 (as defined in section 3.1 of [RFC4193]). Note that the random 2917 hash for ACP Loopback addresses uses the definition in 2918 Section 6.11.2 and not the one of [RFC4193] section 3.2.2. 2919 * No external connectivity: They do not provide access to the 2920 Internet. If a node requires further reaching connectivity, it 2921 should use another, traditionally managed address scheme in 2922 parallel. 2923 * Addresses in the ACP are permanent, and do not support temporary 2924 addresses as defined in [RFC4941]. 2925 * Addresses in the ACP are not considered sensitive on privacy 2926 grounds because ACP nodes are not expected to be end-user hosts 2927 and ACP addresses do therefore not represent end-users or groups 2928 of end-users. All ACP nodes are in one (potentially federated) 2929 administrative domain. They are assumed to be to be candidate 2930 hosts of ACP traffic amongst each other or transit thereof. There 2931 are no transit nodes less privileged to know about the identity of 2932 other hosts in the ACP. Therefore, ACP addresses do not need to 2933 be pseudo-random as discussed in [RFC7721]. Because they are not 2934 propagated to untrusted (non ACP) nodes and stay within a domain 2935 (of trust), we also consider them not to be subject to scanning 2936 attacks. 2938 The ACP is based exclusively on IPv6 addressing, for a variety of 2939 reasons: 2941 * Simplicity, reliability and scale: If other network layer 2942 protocols were supported, each would have to have its own set of 2943 security associations, routing table and process, etc. 2944 * Autonomic functions do not require IPv4: Autonomic functions and 2945 autonomic service agents are new concepts. They can be 2946 exclusively built on IPv6 from day one. There is no need for 2947 backward compatibility. 2948 * OAM protocols do not require IPv4: The ACP may carry OAM 2949 protocols. All relevant protocols (SNMP, TFTP, SSH, SCP, RADIUS, 2950 Diameter, NETCONF ...) are available in IPv6. See also [RFC8368] 2951 for how ACP could be made to interoperate with IPv4 only OAM. 2953 Further explanation about the addressing and routing related reasons 2954 for the choice of the autonomous ACP addressing can be found in 2955 Section 6.13.5.1. 2957 6.11.2. The ACP Addressing Base Scheme 2959 The Base ULA addressing scheme for ACP nodes has the following 2960 format: 2962 8 40 2 78 2963 +--+-------------------------+------+------------------------------+ 2964 |fd| hash(routing-subdomain) | Type | (sub-scheme) | 2965 +--+-------------------------+------+------------------------------+ 2967 Figure 10: ACP Addressing Base Scheme 2969 The first 48-bits follow the ULA scheme, as defined in [RFC4193], to 2970 which a type field is added: 2972 * "fd" identifies a locally defined ULA address. 2973 * The 40-bits ULA "global ID" (term from [RFC4193]) for ACP 2974 addresses carried in the acp-node-name in the ACP certificates are 2975 the first 40-bits of the SHA256 hash of the routing subdomain from 2976 the same acp-node-name. In the example of Section 6.2.2, the 2977 routing subdomain is "area51.research.acp.example.com" and the 2978 40-bits ULA "global ID" 89b714f3db. 2979 * When creating a new routing-subdomain for an existing autonomic 2980 network, it MUST be ensured, that rsub is selected so the 2981 resulting hash of the routing-subdomain does not collide with the 2982 hash of any pre-existing routing-subdomains of the autonomic 2983 network. This ensures that ACP addresses created by registrars 2984 for different routing subdomains do not collide with each other. 2985 * To allow for extensibility, the fact that the ULA "global ID" is a 2986 hash of the routing subdomain SHOULD NOT be assumed by any ACP 2987 node during normal operations. The hash function is only executed 2988 during the creation of the certificate. If BRSKI is used, then 2989 the BRSKI registrar will create the acp-node-name in response to 2990 the EST Certificate Signing Request (CSR) Attribute Request 2991 message by the pledge. 2993 * Establishing connectivity between different ACP (different acp- 2994 domain-name) is outside the scope of this specification. If it is 2995 being done through future extensions, then the rsub of all 2996 routing-subdomains across those autonomic networks need to be 2997 selected so the resulting routing-subdomain hashes do not collide. 2998 For example, a large cooperation with its own private TA may want 2999 to create different autonomic networks that initially should not 3000 be able to connect but where the option to do so should be kept 3001 open. When taking this future possibility into account, it is 3002 easy to always select rsub so that no collisions happen. 3003 * Type: This field allows different address sub-schemes. This 3004 addresses the "upgradability" requirement. Assignment of types 3005 for this field will be maintained by IANA. 3007 The sub-scheme may imply a range or set of addresses assigned to the 3008 node, this is called the ACP address range/set and explained in each 3009 sub-scheme. 3011 Please refer to Section 6.11.7 and Appendix A.1 for further 3012 explanations why the following Sub-Addressing schemes are used and 3013 why multiple are necessary. 3015 The following summarizes the addressing Sub-Schemes: 3017 +------+-----------------+-----------+-------------------+ 3018 | Type | Name |F-bit| Z | V-bits | Prefix | 3019 +------+-----------------+-----+-----+----------+--------+ 3020 | 0x00 | ACP-Zone | N/A | 0 | 1 bit | /127 | 3021 +------+-----------------+-----+-----+----------+--------+ 3022 | 0x00 | ACP-Manual | N/A | 1 | N/A | /64 | 3023 +------+-----------------+-----+-----+----------+--------+ 3024 | 0x01 | ACP-VLong-8 | 0 | N/A | 8 bits | /120 | 3025 +------+-----------------+-----+-----+----------+--------+ 3026 | 0x01 | ACP-VLong-16 | 1 | N/A | 16 bits | /112 | 3027 +------+-----------------+-----+-----+----------+--------+ 3028 | 0x10 | Reserved / For future definition/allocation | 3029 +------+-----------------+-----+-----+----------+--------+ 3030 | 0x11 | Reserved / For future definition/allocation | 3031 +------+-----------------+-----+-----+----------+--------+ 3033 Figure 11: Addressing Sub-Schemes 3035 F-Bit and Z are two encoding fields explained below for the Sub- 3036 Schemes that introduce/use them. V-bits is the number of bits of 3037 addresses allocated to the ACP node. Prefix is the prefix the ACP 3038 node is announcing into the RPL routing protocol. 3040 6.11.3. ACP Zone Addressing Sub-Scheme (ACP-Zone) 3042 This sub-scheme is used when the Type field of the base scheme is 3043 0x00 and the Z bit is 0x0. 3045 64 64 3046 +-----------------+---+---------++-----------------------------+---+ 3047 | (base scheme) | Z | Zone-ID || Node-ID | 3048 | | | || Registrar-ID | Node-Number| V | 3049 +-----------------+---+---------++--------------+--------------+---+ 3050 50 1 13 48 15 1 3052 Figure 12: ACP Zone Addressing Sub-Scheme 3054 The fields are defined as follows: 3056 * Type: MUST be 0x0. 3057 * Z: MUST be 0x0. 3058 * Zone-ID: A value for a network zone. 3059 * Node-ID: A unique value for each node. 3061 The 64-bit Node-ID must be unique across the ACP domain for each 3062 node. It is derived and composed as follows: 3064 * Registrar-ID (48-bit): A number unique inside the domain that 3065 identifies the ACP registrar which assigned the Node-ID to the 3066 node. One or more domain-wide unique identifiers of the ACP 3067 registrar can be used for this purpose. See Section 6.11.7.2. 3068 * Node-Number: Number to make the Node-ID unique. This can be 3069 sequentially assigned by the ACP Registrar owning the Registrar- 3070 ID. 3071 * V (1-bit): Virtualization bit: 0: Indicates the ACP itself ("ACP 3072 node base system); 1: Indicates the optional "host" context on the 3073 ACP node (see below). 3075 In the ACP Zone Addressing Sub-Scheme, the ACP address in the 3076 certificate has V field as all zero bits. 3078 The ACP address set of the node includes addresses with any Zone-ID 3079 value and any V value. No two nodes in the same ACP can have the 3080 same Node-ID, but different Zone-IDs. 3082 The Virtual bit in this sub-scheme allows the easy addition of the 3083 ACP as a component to existing systems without causing problems in 3084 the port number space between the services in the ACP and the 3085 existing system. V:0 is the ACP router (autonomic node base system), 3086 V:1 is the host with pre-existing transport endpoints on it that 3087 could collide with the transport endpoints used by the ACP router. 3088 The ACP host could for example have a p2p virtual interface with the 3089 V:0 address as its router into the ACP. Depending on the software 3090 design of ASAs, which is outside the scope of this specification, 3091 they may use the V:0 or V:1 address. 3093 The location of the V bit(s) at the end of the address allows the 3094 announcement of a single prefix for each ACP node. For example, in a 3095 network with 20,000 ACP nodes, this avoid 20,000 additional routes in 3096 the routing table. 3098 It is RECOMMENDED that only Zone-ID 0 is used unless it is meant to 3099 be used in conjunction with operational practices for partial/ 3100 incremental adoption of the ACP as described in Section 9.4. 3102 Note: Zones and Zone-ID as defined here are not related to [RFC4007] 3103 zones or zone_id. ACP zone addresses are not scoped (reachable only 3104 from within an RFC4007 zone) but reachable across the whole ACP. An 3105 RFC4007 zone_id is a zone index that has only local significance on a 3106 node, whereas an ACP Zone-ID is an identifier for an ACP zone that is 3107 unique across that ACP. 3109 6.11.4. ACP Manual Addressing Sub-Scheme (ACP-Manual) 3111 This sub-scheme is used when the Type field of the base scheme is 3112 0x00 and the Z bit is 0x1. 3114 64 64 3115 +---------------------+---+----------++-----------------------------+ 3116 | (base scheme) | Z | Subnet-ID|| Interface Identifier | 3117 +---------------------+---+----------++-----------------------------+ 3118 50 1 13 3120 Figure 13: ACP Manual Addressing Sub-Scheme 3122 The fields are defined as follows: 3124 * Type: MUST be 0x0. 3125 * Z: MUST be 0x1. 3126 * Subnet-ID: Configured subnet identifier. 3127 * Interface Identifier. 3129 This sub-scheme is meant for "manual" allocation to subnets where the 3130 other addressing schemes cannot be used. The primary use case is for 3131 assignment to ACP connect subnets (see Section 8.1.1). 3133 "Manual" means that allocations of the Subnet-ID need to be done 3134 today with pre-existing, non-autonomic mechanisms. Every subnet that 3135 uses this addressing sub-scheme needs to use a unique Subnet-ID 3136 (unless some anycast setup is done). 3138 The Z bit field was added to distinguish Zone addressing and manual 3139 addressing sub-schemes without requiring one more bit in the base 3140 scheme and therefore allowing for the Vlong scheme (described below) 3141 to have one more bit available. 3143 Manual addressing sub-scheme addresses SHOULD NOT be used in ACP 3144 certificates. Any node capable to build ACP secure channels and 3145 permitted by Registrar policy to participate in building ACP secure 3146 channels SHOULD receive an ACP address (prefix) from one of the other 3147 ACP addressing sub-schemes. Nodes not capable (or permitted) to 3148 participate in ACP secure channels can connect to the ACP via ACP 3149 connect interfaces of ACP edge nodes (see Section 8.1), without 3150 setting up an ACP secure channel. Their ACP certificate MUST omit 3151 the acp-address field to indicate that their ACP certificate is only 3152 usable for non- ACP secure channel authentication, such as end-to-end 3153 transport connections across the ACP or Data-Plane. 3155 Address management of ACP connect subnets is done using traditional 3156 assignment methods and existing IPv6 protocols. See Section 8.1.3 3157 for details. Therefore, the notion of V-bit many addresses assigned 3158 to the ACP nodes does not apply to this Sub-Scheme. 3160 6.11.5. ACP Vlong Addressing Sub-Scheme (ACP-VLong-8/ACP-VLong-16 3162 This sub-scheme is used when the Type field of the base scheme is 3163 0x01. 3165 50 78 3166 +---------------------++-----------------------------+----------+ 3167 | (base scheme) || Node-ID | 3168 | || Registrar-ID |F| Node-Number| V | 3169 +---------------------++--------------+--------------+----------+ 3170 50 46 1 23/15 8/16 3172 Figure 14: ACP Vlong Addressing Sub-Scheme 3174 This addressing scheme foregoes the Zone-ID field to allow for 3175 larger, flatter routed networks (e.g., as in IoT) with 8421376 Node- 3176 Numbers (2^23+2^15). It also allows for up to 2^16 (i.e. 65536) 3177 different virtualized addresses within a node, which could be used to 3178 address individual software components in an ACP node. 3180 The fields are the same as in the Zone-ID sub-scheme with the 3181 following refinements: 3183 * F: format bit. This bit determines the format of the subsequent 3184 bits. 3185 * V: Virtualization bit: this is a field that is either 8 or 16 3186 bits. For F=0, it is 8 bits, for F=1 it is 16 bits. The V bits 3187 are assigned by the ACP node. In the ACP certificate's ACP 3188 address Section 6.2.2, the V-bits are always set to 0. 3189 * Registrar-ID: To maximize Node-Number and V, the Registrar-ID is 3190 reduced to 46-bits. One or more domain-wide unique identifiers of 3191 the ACP registrar can be used for this purpose. See 3192 Section 6.11.7.2. 3193 * The Node-Number is unique to each ACP node. There are two formats 3194 for the Node-Number. When F=0, the node-number is 23 bits, for 3195 F=1 it is 15 bits. Each format of node-number is considered to be 3196 in a unique number space. 3198 The F=0 bit format addresses are intended to be used for "general 3199 purpose" ACP nodes that would potentially have a limited number (< 3200 256) of clients (ASA/Autonomic Functions or legacy services) of the 3201 ACP that require separate V(irtual) addresses. 3203 The F=1 bit Node-Numbers are intended for ACP nodes that are ACP edge 3204 nodes (see Section 8.1.1) or that have a large number of clients 3205 requiring separate V(irtual) addresses. For example, large SDN 3206 controllers with container modular software architecture (see 3207 Section 8.1.2). 3209 In the Vlong addressing sub-scheme, the ACP address in the 3210 certificate has all V field bits as zero. The ACP address set for 3211 the node includes any V value. 3213 6.11.6. Other ACP Addressing Sub-Schemes 3215 Before further addressing sub-schemes are defined, experience with 3216 the schemes defined here should be collected. The schemes defined in 3217 this document have been devised to allow hopefully sufficiently 3218 flexible setup of ACPs for a variety of situation. These reasons 3219 also lead to the fairly liberal use of address space: The Zone 3220 Addressing Sub-Scheme is intended to enable optimized routing in 3221 large networks by reserving bits for Zone-ID's. The Vlong addressing 3222 sub-scheme enables the allocation of 8/16-bit of addresses inside 3223 individual ACP nodes. Both address spaces allow distributed, 3224 uncoordinated allocation of node addresses by reserving bits for the 3225 registrar-ID field in the address. 3227 6.11.7. ACP Registrars 3229 ACP registrars are responsible to enroll candidate ACP nodes with ACP 3230 certificates and associated trust anchor(s). They are also 3231 responsible that an acp-node-name field is included in the ACP 3232 certificate carrying the ACP domain name and the ACP nodes ACP 3233 address prefix. This address prefix is intended to persist unchanged 3234 through the lifetime of the ACP node. 3236 Because of the ACP addressing sub-schemes, an ACP domain can have 3237 multiple distributed ACP registrars that do not need to coordinate 3238 for address assignment. ACP registrars can also be sub-CAs, in which 3239 case they can also assign ACP certificates without dependencies 3240 against a (shared) TA (except during renewals of their own 3241 certificates). 3243 ACP registrars are PKI registration authorities (RA) enhanced with 3244 the handling of the ACP certificate specific fields. They request 3245 certificates for ACP nodes from a Certification Authority through any 3246 appropriate mechanism (out of scope in this document, but required to 3247 be BRSKI for ANI registrars). Only nodes that are trusted to be 3248 compliant with the requirements against registrar described in this 3249 section can be given the necessary credentials to perform this RA 3250 function, such as credentials for the BRSKI connection to the CA for 3251 ANI registrars. 3253 6.11.7.1. Use of BRSKI or other Mechanism/Protocols 3255 Any protocols or mechanisms may be used by ACP registrars, as long as 3256 the resulting ACP certificate and TA certificate(s) allow to perform 3257 the ACP domain membership described in Section 6.2.3 with other ACP 3258 domain members, and meet the ACP addressing requirements for its acp- 3259 node-name as described further below in this section. 3261 An ACP registrar could be a person deciding whether to enroll a 3262 candidate ACP node and then orchestrating the enrollment of the ACP 3263 certificate and associated TA, using command line or web based 3264 commands on the candidate ACP node and TA to generate and sign the 3265 ACP certificate and configure certificate and TA onto the node. 3267 The only currently defined protocol for ACP registrars is BRSKI 3268 ([I-D.ietf-anima-bootstrapping-keyinfra]). When BRSKI is used, the 3269 ACP nodes are called ANI nodes, and the ACP registrars are called 3270 BRSKI or ANI registrars. The BRSKI specification does not define the 3271 handling of the acp-node-name field because the rules do not depend 3272 on BRSKI but apply equally to any protocols/mechanisms an ACP 3273 registrar may use. 3275 6.11.7.2. Unique Address/Prefix allocation 3277 ACP registrars MUST NOT allocate ACP address prefixes to ACP nodes 3278 via the acp-node-name that would collide with the ACP address 3279 prefixes of other ACP nodes in the same ACP domain. This includes 3280 both prefixes allocated by the same ACP registrar to different ACP 3281 nodes as well as prefixes allocated by other ACP registrars for the 3282 same ACP domain. 3284 To support such unique address allocation, an ACP registrar MUST have 3285 one or more 46-bit identifiers unique across the ACP domain which is 3286 called the Registrar-ID. Allocation of Registrar-ID(s) to an ACP 3287 registrar can happen through OAM mechanisms in conjunction with some 3288 database / allocation orchestration. 3290 ACP registrars running on physical devices with known globally unique 3291 EUI-48 MAC address(es) can use the lower 46 bits of those address(es) 3292 as unique Registrar-IDs without requiring any external signaling/ 3293 configuration (the upper two bits, V and U are not uniquely assigned 3294 but functional). This approach is attractive for distributed, non- 3295 centrally administered, lightweight ACP registrar implementations. 3296 There is no mechanism to deduce from a MAC address itself whether it 3297 is actually uniquely assigned. Implementations need to consult 3298 additional offline information before making this assumption. For 3299 example by knowing that a particular physical product/MIC-chip is 3300 guaranteed to use globally unique assigned EUI-48 MAC address(es). 3302 When the candidate ACP device (called Pledge in BRSKI) is to be 3303 enrolled into an ACP domain, the ACP registrar needs to allocate a 3304 unique ACP address to the node and ensure that the ACP certificate 3305 gets a acp-node-name field (Section 6.2.2) with the appropriate 3306 information - ACP domain-name, ACP-address, and so on. If the ACP 3307 registrar uses BRSKI, it signals the ACP acp-node-name field to the 3308 Pledge via the EST /csrattrs command (see 3309 [I-D.ietf-anima-bootstrapping-keyinfra], section 5.9.2 - "EST CSR 3310 Attributes"). 3312 [RFC-Editor: please update reference to section 5.9.2 accordingly 3313 with latest BRSKI draft at time of publishing, or RFC] 3315 6.11.7.3. Addressing Sub-Scheme Policies 3317 The ACP registrar selects for the candidate ACP node a unique address 3318 prefix from an appropriate ACP addressing sub-scheme, either a zone 3319 addressing sub-scheme prefix (see Section 6.11.3), or a Vlong 3320 addressing sub-scheme prefix (see Section 6.11.5). The assigned ACP 3321 address prefix encoded in the acp-node-name field of the ACP 3322 certificate indicates to the ACP node its ACP address information. 3324 The sub-addressing scheme indicates the prefix length: /127 for zone 3325 address sub-scheme, /120 or /112 for Vlong address sub-scheme. The 3326 first address of the prefix is the ACP address. All other addresses 3327 in the prefix are for other uses by the ACP node as described in the 3328 zone and Vlong addressing sub scheme sections. The ACP address 3329 prefix itself is then signaled by the ACP node into the ACP routing 3330 protocol (see Section 6.12) to establish IPv6 reachability across the 3331 ACP. 3333 The choice of addressing sub-scheme and prefix-length in the Vlong 3334 address sub-scheme is subject to ACP registrar policy. It could be 3335 an ACP domain wide policy, or a per ACP node or per ACP node type 3336 policy. For example, in BRSKI, the ACP registrar is aware of the 3337 IDevID certificate of the candidate ACP node, which typically 3338 contains a "serialNumber" attribute in the subject field 3339 distinguished name encoding that is often indicating the node's 3340 vendor and device type and can be used to drive a policy selecting an 3341 appropriate addressing sub-scheme for the (class of) node(s). 3343 ACP registrars SHOULD default to allocate ACP zone sub-address scheme 3344 addresses with Zone-ID 0. 3346 ACP registrars that are aware of the IDevID certificate of a 3347 candidate ACP device SHOULD be able to choose the zone vs. Vlong sub- 3348 address scheme for ACP nodes based on the [X.520] "serialNumber" 3349 attribute in the subject field distinguished name encoding of the 3350 IDevID certificate, for example by the PID (Product Identifier) part 3351 which identifies the product type, or the complete "serialNumber". 3352 The PID for example could identify nodes that allow for specialized 3353 ASA requiring multiple addresses or non-autonomic VMs for services 3354 and those nodes could receive Vlong sub-address scheme ACP addresses. 3356 In a simple allocation scheme, an ACP registrar remembers 3357 persistently across reboots its currently used Registrar-ID and for 3358 each addressing scheme (Zone with Zone-ID 0, Vlong with /112, Vlong 3359 with /120), the next Node-Number available for allocation and 3360 increases it during successful enrollment to an ACP node. In this 3361 simple allocation scheme, the ACP registrar would not recycle ACP 3362 address prefixes from no longer used ACP nodes. 3364 If allocated addresses cannot be remembered by registrars, then it is 3365 necessary to either use a new value for the Register-ID field in the 3366 ACP addresses, or determine allocated ACP addresses from determining 3367 the addresses of reachable ACP nodes, which is not necessarily the 3368 set of all ACP nodes. Non-tracked ACP addresses can be reclaimed by 3369 revoking or not renewing their certificates and instead handing out 3370 new certificate with new addresses (for example with a new Registrar- 3371 ID value). Note that such strategies may require coordination 3372 amongst registrars. 3374 6.11.7.4. Address/Prefix Persistence 3376 When an ACP certificate is renewed or rekeyed via EST or other 3377 mechanisms, the ACP address/prefix in the acp-node-name field MUST be 3378 maintained unless security issues or violations of the unique address 3379 assignment requirements exist or are suspected by the ACP registrar. 3381 ACP address information SHOULD be maintained even when the renewing/ 3382 rekeying ACP registrar is not the same as the one that enrolled the 3383 prior ACP certificate. See Section 9.2.4 for an example. 3385 ACP address information SHOULD also be maintained even after an ACP 3386 certificate did expire or failed. See Section 6.2.5.5 and 3387 Section 6.2.5.6. 3389 6.11.7.5. Further Details 3391 Section 9.2 discusses further informative details of ACP registrars: 3392 What interactions registrars need, what parameters they require, 3393 certificate renewal and limitations, use of sub-CAs on registrars and 3394 centralized policy control. 3396 6.12. Routing in the ACP 3398 Once ULA address are set up all autonomic entities should run a 3399 routing protocol within the autonomic control plane context. This 3400 routing protocol distributes the ULA created in the previous section 3401 for reachability. The use of the autonomic control plane specific 3402 context eliminates the probable clash with Data-Plane routing tables 3403 and also secures the ACP from interference from the configuration 3404 mismatch or incorrect routing updates. 3406 The establishment of the routing plane and its parameters are 3407 automatic and strictly within the confines of the autonomic control 3408 plane. Therefore, no explicit configuration is required. 3410 All routing updates are automatically secured in transit as the 3411 channels of the ACP are encrypted, and this routing runs only inside 3412 the ACP. 3414 The routing protocol inside the ACP is RPL ([RFC6550]). See 3415 Appendix A.4 for more details on the choice of RPL. 3417 RPL adjacencies are set up across all ACP channels in the same domain 3418 including all its routing subdomains. See Appendix A.6 for more 3419 details. 3421 6.12.1. ACP RPL Profile 3423 The following is a description of the RPL profile that ACP nodes need 3424 to support by default. The format of this section is derived from 3425 [I-D.ietf-roll-applicability-template]. 3427 6.12.1.1. Overview 3429 RPL Packet Information (RPI) defined in [RFC6550], section 11.2 3430 defines the data packet artefacts required or beneficial in 3431 forwarding of packets routed by RPL. This profile does not use RPI 3432 for better compatibility with accelerated hardware forwarding planes 3433 which most often does not support the Hop-by-Hop headers used for 3434 RPI, but also to avoid the overhead of the RPI header on the wire and 3435 cost of adding/removing them. 3437 6.12.1.1.1. Single Instance 3439 To avoid the need for RPI, the ACP RPL profile uses a simple 3440 destination prefix based routing/forwarding table. To achieve this, 3441 the profiles uses only one RPL instanceID. This single instanceID 3442 can contain only one Destination Oriented Directed Acyclic Graph 3443 (DODAG), and the routing/forwarding table can therefore only 3444 calculate a single class of service ("best effort towards the primary 3445 NOC/root") and cannot create optimized routing paths to accomplish 3446 latency or energy goals between any two nodes. 3448 This choice is a compromise. Consider a network that has multiple 3449 NOCs in different locations. Only one NOC will become the DODAG 3450 root. Traffic to and from other NOCs has to be sent through the 3451 DODAG (shortest path tree) rooted in the primary NOC. Depending on 3452 topology, this can be an annoyance from a latency point of view or 3453 from minimizing network path resources, but this is deemed to be 3454 acceptable given how ACP traffic is "only" network management/control 3455 traffic. See Appendix A.9.4 for more details. 3457 Using a single instanceID/DODAG does not introduce a single point of 3458 failure, as the DODAG will reconfigure itself when it detects Data- 3459 Plane forwarding failures including choosing a different root when 3460 the primary one fails. 3462 The benefit of this profile, especially compared to other IGPs is 3463 that it does not calculate routes for node reachable through the same 3464 interface as the DODAG root. This RPL profile can therefore scale to 3465 much larger number of ACP nodes in the same amount of compute and 3466 memory than other routing protocols. Especially on nodes that are 3467 leafs of the topology or those close to those leafs. 3469 6.12.1.1.2. Reconvergence 3471 In RPL profiles where RPL Packet Information (RPI, see 3472 Section 6.12.1.13) is present, it is also used to trigger 3473 reconvergence when misrouted, for example looping, packets are 3474 recognized because of their RPI data. This helps to minimize RPL 3475 signaling traffic especially in networks without stable topology and 3476 slow links. 3478 The ACP RPL profile instead relies on quick reconverging the DODAG by 3479 recognizing link state change (down/up) and triggering reconvergence 3480 signaling as described in Section 6.12.1.7. Since links in the ACP 3481 are assumed to be mostly reliable (or have link layer protection 3482 against loss) and because there is no stretch according to 3483 Section 6.12.1.7, loops caused by loss of RPL routing protocol 3484 signaling packets should be exceedingly rare. 3486 In addition, there are a variety of mechanisms possible in RPL to 3487 further avoid temporary loops RECOMMENDED to be used for the ACPL RPL 3488 profile: DODAG Information Objects (DIOs) SHOULD be sent 2 or 3 times 3489 to inform children when losing the last parent. The technique in 3490 [RFC6550] section 8.2.2.6. (Detaching) SHOULD be favored over that 3491 in section 8.2.2.5., (Poisoning) because it allows local 3492 connectivity. Nodes SHOULD select more than one parent, at least 3 3493 if possible, and send Destination Advertisement Objects (DAO)s to all 3494 of them in parallel. 3496 Additionally, failed ACP tunnels can be quickly discovered trough the 3497 secure channel protocol mechanisms such as IKEv2 Dead Peer Detection. 3498 This can function as a replacement for a Low-power and Lossy 3499 Networks' (LLN's) Expected Transmission Count (ETX) feature that is 3500 not used in this profile. A failure of an ACP tunnel should 3501 immediately signal the RPL control plane to pick a different parent. 3503 6.12.1.2. RPL Instances 3505 Single RPL instance. Default RPLInstanceID = 0. 3507 6.12.1.3. Storing vs. Non-Storing Mode 3509 RPL Mode of Operations (MOP): MUST support mode 2 - "Storing Mode of 3510 Operations with no multicast support". Implementations MAY support 3511 mode 3 ("... with multicast support" as that is a superset of mode 3512 2). Note: Root indicates mode in DIO flow. 3514 6.12.1.4. DAO Policy 3516 Proactive, aggressive DAO state maintenance: 3518 * Use K-flag in unsolicited DAO indicating change from previous 3519 information (to require DAO-ACK). 3520 * Retry such DAO DAO-RETRIES(3) times with DAO- ACK_TIME_OUT(256ms) 3521 in between. 3523 6.12.1.5. Path Metric 3525 Use Hopcount according to [RFC6551]. Note that this is solely for 3526 diagnostic purposes as it is not used by the objective function. 3528 6.12.1.6. Objective Function 3530 Objective Function (OF): Use OF0 [RFC6552]. No use of metric 3531 containers. 3533 rank_factor: Derived from link speed: <= 100Mbps: 3534 LOW_SPEED_FACTOR(5), else HIGH_SPEED_FACTOR(1) 3536 This is a simple rank differentiation between typical "low speed" or 3537 "IoT" links that commonly max out at 100 Mbps and typical 3538 infrastructure links with speeds of 1 Gbps or higher. Given how the 3539 path selection for the ACP focusses only on reachability but not on 3540 path cost optimization, no attempts at finer grained path 3541 optimization are made. 3543 6.12.1.7. DODAG Repair 3545 Global Repair: we assume stable links and ranks (metrics), so there 3546 is no need to periodically rebuild the DODAG. The DODAG version is 3547 only incremented under catastrophic events (e.g., administrative 3548 action). 3550 Local Repair: As soon as link breakage is detected, the ACP node send 3551 No-Path DAO for all the targets that were reachable only via this 3552 link. As soon as link repair is detected, the ACP node validates if 3553 this link provides a better parent. If so, a new rank is computed by 3554 the ACP node and it sends new DIO that advertise the new rank. Then 3555 it sends a DAO with a new path sequence about itself. 3557 When using ACP multi-access virtual interfaces, local repair can be 3558 triggered directly by peer breakage, see Section 6.13.5.2.2. 3560 stretch_rank: none provided ("not stretched"). 3562 Data Path Validation: Not used. 3564 Trickle: Not used. 3566 6.12.1.8. Multicast 3568 Not used yet but possible because of the selected mode of operations. 3570 6.12.1.9. Security 3572 [RFC6550] security not used, substituted by ACP security. 3574 Because the ACP links already include provisions for confidentiality 3575 and integrity protection, their usage at the RPL layer would be 3576 redundant, and so RPL security is not used. 3578 6.12.1.10. P2P communications 3580 Not used. 3582 6.12.1.11. IPv6 address configuration 3584 Every ACP node (RPL node) announces an IPv6 prefix covering the 3585 addresses assigned to the ACP node via the AcpNodeName. The prefix 3586 length depends on the addressing sub-scheme of the acp-address, /127 3587 for Zone Addressing Sub-Scheme and /112 or /120 for Vlong addressing 3588 sub-scheme. See Section 6.11 for more details. 3590 Every ACP node MUST install a black hole (aka null) route if there 3591 are unused parts of the ACP address space assigned to the ACP node 3592 via its AcpNodeName. This is superseded by longer prefixes assigned 3593 to interfaces for the address space actually used by the node. For 3594 example, when the node has an ACP-VLong-8 address space, it installs 3595 a /120 black hole route. If it then for example only uses the ACP 3596 address (first address from the space), it would assign that address 3597 via a /128 address prefix to the ACP loopback interface (see 3598 Section 6.13.5.1). None of those longer prefixes are announced into 3599 RPL. 3601 For ACP-Manual address prefixes configured on an ACP node, for 3602 example for ACP connect subnets (see Section 8.1.1), the node 3603 announces the /64 subnet prefix. 3605 6.12.1.12. Administrative parameters 3607 Administrative Preference ([RFC6550], 3.2.6 - to become root): 3608 Indicated in DODAGPreference field of DIO message. 3610 * Explicit configured "root": 0b100 3611 * ACP registrar (Default): 0b011 3612 * ACP-connect (non-registrar): 0b010 3613 * Default: 0b001. 3615 6.12.1.13. RPL Packet Information 3617 RPI is not required in the ACP RPL profile for the following reasons. 3619 One RPI option is the RPL Source Routing Header (SRH) [RFC6554] which 3620 is not necessary because the ACP RPL profile uses storing mode where 3621 each hop has the necessary next-hop forwarding information. 3623 The simpler RPL Option header [RFC6553] is also not necessary in this 3624 profile, because it uses a single RPL instance and data path 3625 validation is also not used. 3627 6.12.1.14. Unknown Destinations 3629 Because RPL minimizes the size of the routing and forwarding table, 3630 prefixes reachable through the same interface as the RPL root are not 3631 known on every ACP node. Therefore, traffic to unknown destination 3632 addresses can only be discovered at the RPL root. The RPL root 3633 SHOULD have attach safe mechanisms to operationally discover and log 3634 such packets. 3636 As this requirement places additional constraints on the Data-Plane 3637 functionality of the RPL root, it does not apply to "normal" nodes 3638 that are not configured to have special functionality (i.e., the 3639 administrative parameter from Section 6.12.1.12 has value 0b001). If 3640 the ACP network is degraded to the point where there are no nodes 3641 that could be configured as root, registrar, or ACP-connect nodes, it 3642 is possible that the RPL root (and thus the ACP as a whole) would be 3643 unable to detect traffic to unknown destinations. However, in the 3644 absence of nodes with administrative preference other than 0b001, 3645 there is also unlikely to be a way to get diagnostic information out 3646 of the ACP, so detection of traffic to unknown destinations would not 3647 be actionable anyway. 3649 6.13. General ACP Considerations 3651 Since channels are by default established between adjacent neighbors, 3652 the resulting overlay network does hop-by-hop encryption. Each node 3653 decrypts incoming traffic from the ACP, and encrypts outgoing traffic 3654 to its neighbors in the ACP. Routing is discussed in Section 6.12. 3656 6.13.1. Performance 3658 There are no performance requirements against ACP implementations 3659 defined in this document because the performance requirements depend 3660 on the intended use case. It is expected that full autonomic node 3661 with a wide range of ASA can require high forwarding plane 3662 performance in the ACP, for example for telemetry. Implementations 3663 of ACP to solely support traditional/SDN style use cases can benefit 3664 from ACP at lower performance, especially if the ACP is used only for 3665 critical operations, e.g., when the Data-Plane is not available. The 3666 design of the ACP as specified in this document is intended to 3667 support a wide range of performance options: It is intended to allow 3668 software-only implementations at potentially low performance, but can 3669 also support high performance options. See [RFC8368] for more 3670 details. 3672 6.13.2. Addressing of Secure Channels 3674 In order to be independent of the Data-Plane routing and addressing, 3675 the GRASP discovered ACP secure channels use IPv6 link local 3676 addresses between adjacent neighbors. Note: Section 8.2 specifies 3677 extensions in which secure channels are configured tunnels operating 3678 over the Data-Plane, so those secure channels cannot be independent 3679 of the Data-Plane. 3681 To avoid that Data-Plane configuration can impact the operations of 3682 the IPv6 (link-local) interface/address used for ACP channels, 3683 appropriate implementation considerations are required. If the IPv6 3684 interface/link-local address is shared with the Data-Plane, it needs 3685 to be impossible to unconfigure/disable it through configuration. 3686 Instead of sharing the IPv6 interface/link-local address, a separate 3687 (virtual) interface with a separate IPv6 link-local address can be 3688 used. For example, the ACP interface could be run over a separate 3689 MAC address of an underlying L2 (Ethernet) interface. For more 3690 details and options, see Appendix A.9.2. 3692 Note that other (non-ideal) implementation choices may introduce 3693 additional undesired dependencies against the Data-Plane. For 3694 example, shared code and configuration of the secure channel 3695 protocols (IPsec / DTLS). 3697 6.13.3. MTU 3699 The MTU for ACP secure channels MUST be derived locally from the 3700 underlying link MTU minus the secure channel encapsulation overhead. 3702 ACP secure Channel protocols do not need to perform MTU discovery 3703 because they are built across L2 adjacencies - the MTU on both sides 3704 connecting to the L2 connection are assumed to be consistent. 3705 Extensions to ACP where the ACP is for example tunneled need to 3706 consider how to guarantee MTU consistency. This is an issue of 3707 tunnels, not an issue of running the ACP across a tunnel. Transport 3708 stacks running across ACP can perform normal PMTUD (Path MTU 3709 Discovery). Because the ACP is meant to prioritize reliability over 3710 performance, they MAY opt to only expect IPv6 minimum MTU (1280) to 3711 avoid running into PMTUD implementation bugs or underlying link MTU 3712 mismatch problems. 3714 6.13.4. Multiple links between nodes 3716 If two nodes are connected via several links, the ACP SHOULD be 3717 established across every link, but it is possible to establish the 3718 ACP only on a sub-set of links. Having an ACP channel on every link 3719 has a number of advantages, for example it allows for a faster 3720 failover in case of link failure, and it reflects the physical 3721 topology more closely. Using a subset of links (for example, a 3722 single link), reduces resource consumption on the node, because state 3723 needs to be kept per ACP channel. The negotiation scheme explained 3724 in Section 6.6 allows the Decider (the node with the higher ACP 3725 address) to drop all but the desired ACP channels to the Follower - 3726 and the Follower will not re-try to build these secure channels from 3727 its side unless the Decider shows up with a previously unknown GRASP 3728 announcement (e.g., on a different link or with a different address 3729 announced in GRASP). 3731 6.13.5. ACP interfaces 3733 The ACP VRF has conceptually two type of interfaces: The "ACP 3734 Loopback interface(s)" to which the ACP ULA address(es) are assigned 3735 and the "ACP virtual interfaces" that are mapped to the ACP secure 3736 channels. 3738 6.13.5.1. ACP loopback interfaces 3740 For autonomous operations of the ACP, as described in Section 6 and 3741 Section 7, the ACP node uses the first address from the N bit ACP 3742 prefix (N = 128 - number of Vbits of the ACP address) assigned to the 3743 node. This address is assigned with an address prefix of N or larger 3744 to a loopback interface. 3746 Other addresses from the prefix can be used by the ACP of the node as 3747 desired. The autonomous operations of the ACP does not require 3748 additional global scope IPv6 addresses, they are instead intended for 3749 ASA or non-autonomous functions. Non fully autonomic components of 3750 the ACP such as ACP connect interfaces (see Figure 16) may also 3751 introduce additional global scope IPv6 addresses on other types of 3752 interfaces into the ACP. 3754 [RFC-Editor: please remove this paragraph: Note to reviewers: Please 3755 do not complain again about an obsolete RFC number in the following 3756 paragraph. The text should make it clear that the reference was 3757 chosen to indicate a particular point in time, but not to recommend/ 3758 use a particularly obsolete protocol spec.] 3760 The use of loopback interfaces for global scope addresses is common 3761 operational configuration practice on routers, for example in IBGP 3762 connections since BGP4 (see [RFC1654]) or earlier. The ACP adopts 3763 and automates this operational practice. 3765 A loopback interface for use with the ACP as described above is an 3766 interface behaving according to [RFC6724] Section 4., paragraph 2: 3767 Packets sent by the host of the node from the loopback interface 3768 behave as if they are looped back by the interface so that they look 3769 as if they originated from the loopback interface, are then received 3770 by the node and forwarded by it towards the destination. 3772 The word loopback only indicates this behavior, but not the actual 3773 name of the interface type choosen in an actual implementation. A 3774 loopback interface for use with the ACP can be a virtual/software 3775 construct without any associated hardware, or it can be a hardware 3776 interface operating in loopback mode. 3778 A loopback interface used for the ACP MUST NOT have connectivity to 3779 other nodes. 3781 The following reviews the reasons for the choice of loopback 3782 addresses for ACP addresses is based on the IPv6 address architecture 3783 and common challenges: 3785 1. IPv6 addresses are assigned to interfaces, not nodes. IPv6 3786 continues the IPv4 model that a subnet prefix is associated with 3787 one link, see [RFC4291], Section 2.1. 3788 2. IPv6 implementations commonly do not allow assignment of the same 3789 IPv6 global scope address in the same VRF to more than one 3790 interface. 3791 3. Global scope addresses assigned to interfaces that are connecting 3792 to other nodes (external interfaces) may not be stable addresses 3793 for communications because any such interface could fail due to 3794 reasons external to the node. This could render the addresses 3795 assigned to that interface unusable. 3796 4. If failure of the subnet does not result in bringing down the 3797 interface and making the addresses unusable, it could result in 3798 unreachability of the address because the shortest path to the 3799 node might go through one of the other nodes on the same subnet 3800 which could equally consider the subnet to be operational even 3801 though it is not. 3802 5. Many OAM service implementations on routers cannot deal with more 3803 than one peer address, often because they do already expect that 3804 a single loopback address can be used, especially to provide a 3805 stable address under failure of external interfaces or links. 3806 6. Even when an application supports multiple addresses to a peer, 3807 it can only use one address for a connection at a time with the 3808 most widely deployed transport protocols TCP and UDP. While 3809 [RFC6824] solves this problem, it is not widely adopted for 3810 router OAM services implementations. 3811 7. To completely autonomously assign global scope addresses to 3812 subnets connecting to other nodes, it would be necessary for 3813 every node to have an amount of prefix address space in the order 3814 of the maximum number of subnets that the node could connect to 3815 and then the node would have to negotiate with adjacent nodes 3816 across those subnets whose address space to use for each subnet. 3817 8. Using global scope addresses for subnets between nodes is 3818 unnecessary if those subnets only connect routers, such as ACP 3819 secure channels, because they can communicate to remote nodes via 3820 their global scope loopback addresses. Using global scope 3821 addresses for those extern subnets is therefore wasteful for the 3822 address space and also unnecessarily increasing the size of 3823 routing and forwarding tables, which especially for the ACP is 3824 highly undesirable because it should attempt to minimize the per- 3825 node overhead of the ACP VRF. 3827 9. For all these reasons, the ACP addressing schemes do not consider 3828 ACP addresses for subnets connecting ACP nodes. 3830 Note that [RFC8402] introduces the term Node-SID to refer to IGP 3831 prefix segments that identify a specific router, for example on a 3832 loopback interface. An ACP loopback address prefix may similarly be 3833 called an ACP Node Identifier. 3835 6.13.5.2. ACP virtual interfaces 3837 Any ACP secure channel to another ACP node is mapped to ACP virtual 3838 interfaces in one of the following ways. This is independent of the 3839 chosen secure channel protocol (IPsec, DTLS or other future protocol 3840 - standards or non-standards). 3842 Note that all the considerations described here are assuming point- 3843 to-point secure channel associations. Mapping multi-party secure 3844 channel associations such as [RFC6407] is out of scope. 3846 6.13.5.2.1. ACP point-to-point virtual interfaces 3848 In this option, each ACP secure channel is mapped into a separate 3849 point-to-point ACP virtual interface. If a physical subnet has more 3850 than two ACP capable nodes (in the same domain), this implementation 3851 approach will lead to a full mesh of ACP virtual interfaces between 3852 them. 3854 When the secure channel protocol determines a peer to be dead, this 3855 SHOULD result in indicating link breakage to trigger RPL DODAG 3856 repair, see Section 6.12.1.7. 3858 6.13.5.2.2. ACP multi-access virtual interfaces 3860 In a more advanced implementation approach, the ACP will construct a 3861 single multi-access ACP virtual interface for all ACP secure channels 3862 to ACP capable nodes reachable across the same underlying (physical) 3863 subnet. IPv6 link-local multicast packets sent into an ACP multi- 3864 access virtual interface are replicated to every ACP secure channel 3865 mapped into the ACP multicast-access virtual interface. IPv6 unicast 3866 packets sent into an ACP multi-access virtual interface are sent to 3867 the ACP secure channel that belongs to the ACP neighbor that is the 3868 next-hop in the ACP forwarding table entry used to reach the packets 3869 destination address. 3871 When the secure channel protocol determines a peer to be dead for a 3872 secure channel mapped into an ACP multi-access virtual interface, 3873 this SHOULD result in signaling breakage of that peer to RPL, so it 3874 can trigger RPL DODAG repair, see Section 6.12.1.7. 3876 There is no requirement for all ACP nodes on the same multi-access 3877 subnet to use the same type of ACP virtual interface. This is purely 3878 a node local decision. 3880 ACP nodes MUST perform standard IPv6 operations across ACP virtual 3881 interfaces including SLAAC (Stateless Address Auto-Configuration) - 3882 [RFC4862]) to assign their IPv6 link local address on the ACP virtual 3883 interface and ND (Neighbor Discovery - [RFC4861]) to discover which 3884 IPv6 link-local neighbor address belongs to which ACP secure channel 3885 mapped to the ACP virtual interface. This is independent of whether 3886 the ACP virtual interface is point-to-point or multi-access. 3888 "Optimistic Duplicate Address Detection (DAD)" according to [RFC4429] 3889 is RECOMMENDED because the likelihood for duplicates between ACP 3890 nodes is highly improbable as long as the address can be formed from 3891 a globally unique local assigned identifier (e.g., EUI-48/EUI-64, see 3892 below). 3894 ACP nodes MAY reduce the amount of link-local IPv6 multicast packets 3895 from ND by learning the IPv6 link-local neighbor address to ACP 3896 secure channel mapping from other messages such as the source address 3897 of IPv6 link-local multicast RPL messages - and therefore forego the 3898 need to send Neighbor Solicitation messages. 3900 The ACP virtual interface IPv6 link local address can be derived from 3901 any appropriate local mechanism such as node local EUI-48 or EUI-64 3902 ("EUI" stands for "Extended Unique Identifier"). It MUST NOT depend 3903 on something that is attackable from the Data-Plane such as the IPv6 3904 link-local address of the underlying physical interface, which can be 3905 attacked by SLAAC, or parameters of the secure channel encapsulation 3906 header that may not be protected by the secure channel mechanism. 3908 The link-layer address of an ACP virtual interface is the address 3909 used for the underlying interface across which the secure tunnels are 3910 built, typically Ethernet addresses. Because unicast IPv6 packets 3911 sent to an ACP virtual interface are not sent to a link-layer 3912 destination address but rather an ACP secure channel, the link-layer 3913 address fields SHOULD be ignored on reception and instead the ACP 3914 secure channel from which the message was received should be 3915 remembered. 3917 Multi-access ACP virtual interfaces are preferable implementations 3918 when the underlying interface is a (broadcast) multi-access subnet 3919 because they do reflect the presence of the underlying multi-access 3920 subnet into the virtual interfaces of the ACP. This makes it for 3921 example simpler to build services with topology awareness inside the 3922 ACP VRF in the same way as they could have been built running 3923 natively on the multi-access interfaces. 3925 Consider also the impact of point-to-point vs. multi-access virtual 3926 interface on the efficiency of flooding via link local multicasted 3927 messages: 3929 Assume a LAN with three ACP neighbors, Alice, Bob and Carol. Alice's 3930 ACP GRASP wants to send a link-local GRASP multicast message to Bob 3931 and Carol. If Alice's ACP emulates the LAN as per-peer, point-to- 3932 point virtual interfaces, one to Bob and one to Carol, Alice's ACP 3933 GRASP will send two copies of multicast GRASP messages: One to Bob 3934 and one to Carol. If Alice's ACP emulates a LAN via a multipoint 3935 virtual interface, Alice's ACP GRASP will send one packet to that 3936 interface and the ACP multipoint virtual interface will replicate the 3937 packet to each secure channel, one to Bob, one to Carol. The result 3938 is the same. The difference happens when Bob and Carol receive their 3939 packet. If they use ACP point-to-point virtual interfaces, their 3940 GRASP instance would forward the packet from Alice to each other as 3941 part of the GRASP flooding procedure. These packets are unnecessary 3942 and would be discarded by GRASP on receipt as duplicates (by use of 3943 the GRASP Session ID). If Bob and Carol's ACP would emulate a multi- 3944 access virtual interface, then this would not happen, because GRASPs 3945 flooding procedure does not replicate back packets to the interface 3946 that they were received from. 3948 Note that link-local GRASP multicast messages are not sent directly 3949 as IPv6 link-local multicast UDP messages into ACP virtual 3950 interfaces, but instead into ACP GRASP virtual interfaces, that are 3951 layered on top of ACP virtual interfaces to add TCP reliability to 3952 link-local multicast GRASP messages. Nevertheless, these ACP GRASP 3953 virtual interfaces perform the same replication of message and, 3954 therefore, result in the same impact on flooding. See Section 6.9.2 3955 for more details. 3957 RPL does support operations and correct routing table construction 3958 across non-broadcast multi-access (NBMA) subnets. This is common 3959 when using many radio technologies. When such NBMA subnets are used, 3960 they MUST NOT be represented as ACP multi-access virtual interfaces 3961 because the replication of IPv6 link-local multicast messages will 3962 not reach all NBMA subnet neighbors. In result, GRASP message 3963 flooding would fail. Instead, each ACP secure channel across such an 3964 interface MUST be represented as a ACP point-to-point virtual 3965 interface. See also Appendix A.9.4. 3967 Care needs to be taken when creating multi-access ACP virtual 3968 interfaces across ACP secure channels between ACP nodes in different 3969 domains or routing subdomains. If for example future inter-domain 3970 ACP policies are defined as "peer-to-peer" policies, it is easier to 3971 create ACP point-to-point virtual interfaces for these inter-domain 3972 secure channels. 3974 7. ACP support on L2 switches/ports (Normative) 3976 7.1. Why (Benefits of ACP on L2 switches) 3978 ANrtr1 ------ ANswitch1 --- ANswitch2 ------- ANrtr2 3979 .../ \ \ ... 3980 ANrtrM ------ \ ------- ANrtrN 3981 ANswitchM ... 3983 Figure 15: Topology with L2 ACP switches 3985 Consider a large L2 LAN with ANrtr1...ANrtrN connected via some 3986 topology of L2 switches. Examples include large enterprise campus 3987 networks with an L2 core, IoT networks or broadband aggregation 3988 networks which often have even a multi-level L2 switched topology. 3990 If the discovery protocol used for the ACP is operating at the subnet 3991 level, every ACP router will see all other ACP routers on the LAN as 3992 neighbors and a full mesh of ACP channels will be built. If some or 3993 all of the AN switches are autonomic with the same discovery 3994 protocol, then the full mesh would include those switches as well. 3996 A full mesh of ACP connections can create fundamental scale 3997 challenges. The number of security associations of the secure 3998 channel protocols will likely not scale arbitrarily, especially when 3999 they leverage platform accelerated encryption/decryption. Likewise, 4000 any other ACP operations (such as routing) needs to scale to the 4001 number of direct ACP neighbors. An ACP router with just 4 physical 4002 interfaces might be deployed into a LAN with hundreds of neighbors 4003 connected via switches. Introducing such a new unpredictable scaling 4004 factor requirement makes it harder to support the ACP on arbitrary 4005 platforms and in arbitrary deployments. 4007 Predictable scaling requirements for ACP neighbors can most easily be 4008 achieved if in topologies such as these, ACP capable L2 switches can 4009 ensure that discovery messages terminate on them so that neighboring 4010 ACP routers and switches will only find the physically connected ACP 4011 L2 switches as their candidate ACP neighbors. With such a discovery 4012 mechanism in place, the ACP and its security associations will only 4013 need to scale to the number of physical interfaces instead of a 4014 potentially much larger number of "LAN-connected" neighbors. And the 4015 ACP topology will follow directly the physical topology, something 4016 which can then also be leveraged in management operations or by ASAs. 4018 In the example above, consider ANswitch1 and ANswitchM are ACP 4019 capable, and ANswitch2 is not ACP capable. The desired ACP topology 4020 is that ANrtr1 and ANrtrM only have an ACP connection to ANswitch1, 4021 and that ANswitch1, ANrtr2, ANrtrN have a full mesh of ACP connection 4022 amongst each other. ANswitch1 also has an ACP connection with 4023 ANswitchM and ANswitchM has ACP connections to anything else behind 4024 it. 4026 7.2. How (per L2 port DULL GRASP) 4028 To support ACP on L2 switches or L2 switched ports of an L3 device, 4029 it is necessary to make those L2 ports look like L3 interfaces for 4030 the ACP implementation. This primarily involves the creation of a 4031 separate DULL GRASP instance/domain on every such L2 port. Because 4032 GRASP has a dedicated link-local IPv6 multicast address 4033 (ALL_GRASP_NEIGHBORS), it is sufficient that all packets for this 4034 address are being extracted at the port level and passed to that DULL 4035 GRASP instance. Likewise the IPv6 link-local multicast packets sent 4036 by that DULL GRASP instance need to be sent only towards the L2 port 4037 for this DULL GRASP instance (instead of being flooded across all 4038 ports of the VLAN to which the port belongs). 4040 When Ports/Interfaces across which the ACP is expected to operate in 4041 an ACP-aware L2-switch or L2/L3-switch/router are L2-bridged, packets 4042 for the ALL_GRASP_NEIGHBORS multicast address MUST never be forward 4043 between these ports. If MLD snooping is used, it MUST be prohibited 4044 from bridging packets for the ALL_GRASP_NEIGHBORS IPv6 multicast 4045 address. 4047 On hybrid L2/L3 switches, multiple L2 ports are assigned to a single 4048 L3 VLAN interface. With the aforementioned changes for DULL GRASP, 4049 ACP can simply operate on the L3 VLAN interfaces, so no further 4050 (hardware) forwarding changes are required to make ACP operate on L2 4051 ports. This is possible because the ACP secure channel protocols 4052 only use link-local IPv6 unicast packets, and these packets will be 4053 sent to the correct L2 port towards the peer by the VLAN logic of the 4054 device. 4056 This is sufficient when p2p ACP virtual interfaces are established to 4057 every ACP peer. When it is desired to create multi-access ACP 4058 virtual interfaces (see Section 6.13.5.2.2), it is REQIURED not to 4059 coalesce all the ACP secure channels on the same L3 VLAN interface, 4060 but only all those on the same L2 port. 4062 If VLAN tagging is used, then all the above described logic only 4063 applies to untagged GRASP packets. For the purpose of ACP neighbor 4064 discovery via GRASP, no VLAN tagged packets SHOULD be sent or 4065 received. In a hybrid L2/L3 switch, each VLAN would therefore only 4066 create ACP adjacencies across those ports where the VLAN is carried 4067 untagged. 4069 In result, the simple logic is that ACP secure channels would operate 4070 over the same L3 interfaces that present a single flat bridged 4071 network across all routers, but because DULL GRASP is separated on a 4072 per-port basis, no full mesh of ACP secure channels is created, but 4073 only per-port ACP secure channels to per-port L2-adjacent ACP node 4074 neighbors. 4076 For example, in the above picture, ANswitch1 would run separate DULL 4077 GRASP instances on its ports to ANrtr1, ANswitch2 and ANswitchI, even 4078 though all those three ports may be in the data plane in the same 4079 (V)LAN and perform L2 switching between these ports, ANswitch1 would 4080 perform ACP L3 routing between them. 4082 The description in the previous paragraph was specifically meant to 4083 illustrate that on hybrid L3/L2 devices that are common in 4084 enterprise, IoT and broadband aggregation, there is only the GRASP 4085 packet extraction (by Ethernet address) and GRASP link-local 4086 multicast per L2-port packet injection that has to consider L2 ports 4087 at the hardware forwarding level. The remaining operations are 4088 purely ACP control plane and setup of secure channels across the L3 4089 interface. This hopefully makes support for per-L2 port ACP on those 4090 hybrid devices easy. 4092 In devices without such a mix of L2 port/interfaces and L3 interfaces 4093 (to terminate any transport layer connections), implementation 4094 details will differ. Logically most simply every L2 port is 4095 considered and used as a separate L3 subnet for all ACP operations. 4096 The fact that the ACP only requires IPv6 link-local unicast and 4097 multicast should make support for it on any type of L2 devices as 4098 simple as possible. 4100 A generic issue with ACP in L2 switched networks is the interaction 4101 with the Spanning Tree Protocol. Without further L2 enhancements, 4102 the ACP would run only across the active STP topology and the ACP 4103 would be interrupted and re-converge with STP changes. Ideally, ACP 4104 peering SHOULD be built also across ports that are blocked in STP so 4105 that the ACP does not depend on STP and can continue to run 4106 unaffected across STP topology changes, where re-convergence can be 4107 quite slow. The above described simple implementation options are 4108 not sufficient to achieve this. 4110 8. Support for Non-ACP Components (Normative) 4112 8.1. ACP Connect 4113 8.1.1. Non-ACP Controller / NMS system 4115 The Autonomic Control Plane can be used by management systems, such 4116 as controllers or network management system (NMS) hosts (henceforth 4117 called simply "NMS hosts"), to connect to devices (or other type of 4118 nodes) through it. For this, an NMS host needs to have access to the 4119 ACP. The ACP is a self-protecting overlay network, which allows by 4120 default access only to trusted, autonomic systems. Therefore, a 4121 traditional, non-ACP NMS system does not have access to the ACP by 4122 default, such as any other external node. 4124 If the NMS host is not autonomic, i.e., it does not support autonomic 4125 negotiation of the ACP, then it can be brought into the ACP by 4126 explicit configuration. To support connections to adjacent non-ACP 4127 nodes, an ACP node SHOULD support "ACP connect" (sometimes also 4128 called "autonomic connect"): 4130 "ACP connect" is an interface level configured workaround for 4131 connection of trusted non-ACP nodes to the ACP. The ACP node on 4132 which ACP connect is configured is called an "ACP edge node". With 4133 ACP connect, the ACP is accessible from those non-ACP nodes (such as 4134 NOC systems) on such an interface without those non-ACP nodes having 4135 to support any ACP discovery or ACP channel setup. This is also 4136 called "native" access to the ACP because to those NOC systems the 4137 interface looks like a normal network interface without any ACP 4138 secure channel that is encapsulating the traffic. 4140 Data-Plane "native" (no ACP) 4141 . 4142 +--------+ +----------------+ . +-------------+ 4143 | ACP | |ACP Edge Node | . | | 4144 | Node | | | v | | 4145 | |-------|...[ACP VRF]....+----------------| |+ 4146 | | ^ |. | | NOC Device || 4147 | | . | .[Data-Plane]..+----------------| "NMS hosts" || 4148 | | . | [ ] | . ^ | || 4149 +--------+ . +----------------+ . . +-------------+| 4150 . . . +-------------+ 4151 . . . 4152 Data-Plane "native" . ACP "native" (unencrypted) 4153 + ACP auto-negotiated . "ACP connect subnet" 4154 and encrypted . 4155 ACP connect interface 4156 e.g., "VRF ACP native" (config) 4158 Figure 16: ACP connect 4160 ACP connect has security consequences: All systems and processes 4161 connected via ACP connect have access to all ACP nodes on the entire 4162 ACP, without further authentication. Thus, the ACP connect interface 4163 and NOC systems connected to it needs to be physically controlled/ 4164 secured. For this reason the mechanisms described here do explicitly 4165 not include options to allow for a non-ACP router to be connected 4166 across an ACP connect interface and addresses behind such a router 4167 routed inside the ACP. 4169 Physical controlled/secured means that attackers can gain no access 4170 to the physical device hosting the ACP Edge Node, the physical 4171 interfaces and links providing the ACP connect link nor the physical 4172 devices hosting the NOC Device. In a simple case, ACP Edge node and 4173 NOC Device are co-located in an access controlled room, such as a 4174 NOC, to which attackers cannot gain physical access. 4176 An ACP connect interface provides exclusively access to only the ACP. 4177 This is likely insufficient for many NMS hosts. Instead, they would 4178 require a second "Data-Plane" interface outside the ACP for 4179 connections between the NMS host and administrators, or Internet 4180 based services, or for direct access to the Data-Plane. The document 4181 "Using Autonomic Control Plane for Stable Connectivity of Network 4182 OAM" [RFC8368] explains in more detail how the ACP can be integrated 4183 in a mixed NOC environment. 4185 An ACP connect interface SHOULD use an IPv6 address/prefix from the 4186 ACP Manual Addressing Sub-Scheme (Section 6.11.4), letting the 4187 operator configure for example only the Subnet-ID and having the node 4188 automatically assign the remaining part of the prefix/address. It 4189 SHOULD NOT use a prefix that is also routed outside the ACP so that 4190 the addresses clearly indicate whether it is used inside the ACP or 4191 not. 4193 The prefix of ACP connect subnets MUST be distributed by the ACP edge 4194 node into the ACP routing protocol RPL. The NMS hosts MUST connect 4195 to prefixes in the ACP routing table via its ACP connect interface. 4196 In the simple case where the ACP uses only one ULA prefix and all ACP 4197 connect subnets have prefixes covered by that ULA prefix, NMS hosts 4198 can rely on [RFC6724] to determine longest match prefix routes 4199 towards its different interfaces, ACP and Data-Plane. With RFC6724, 4200 The NMS host will select the ACP connect interface for all addresses 4201 in the ACP because any ACP destination address is longest matched by 4202 the address on the ACP connect interface. If the NMS hosts ACP 4203 connect interface uses another prefix or if the ACP uses multiple ULA 4204 prefixes, then the NMS hosts require (static) routes towards the ACP 4205 interface for these prefixes. 4207 When an ACP Edge node receives a packet from an ACP connect 4208 interface, the ACP Edge node MUST only forward the packet into the 4209 ACP if the packet has an IPv6 source address from that interface 4210 (this is sometimes called "RPF filtering"). This filtering rule MAY 4211 be changed through administrative measures. The more any such 4212 administrative action enable reachability of non ACP nodes to the 4213 ACP, the more this may cause security issues. 4215 To limit the security impact of ACP connect, nodes supporting it 4216 SHOULD implement a security mechanism to allow configuration/use of 4217 ACP connect interfaces only on nodes explicitly targeted to be 4218 deployed with it (those in physically secure locations such as a 4219 NOC). For example, the registrar could disable the ability to enable 4220 ACP connect on devices during enrollment and that property could only 4221 be changed through re-enrollment. See also Appendix A.9.5. 4223 ACP Edge nodes SHOULD have a configurable option to prohibit packets 4224 with RPI headers (see Section 6.12.1.13 across an ACP connect 4225 interface. These headers are outside the scope of the RPL profile in 4226 this specification but may be used in future extensions of this 4227 specification. 4229 8.1.2. Software Components 4231 The previous section assumed that ACP Edge node and NOC devices are 4232 separate physical devices and the ACP connect interface is a physical 4233 network connection. This section discusses the implication when 4234 these components are instead software components running on a single 4235 physical device. 4237 The ACP connect mechanism cannot only be used to connect physically 4238 external systems (NMS hosts) to the ACP but also other applications, 4239 containers or virtual machines. In fact, one possible way to 4240 eliminate the security issue of the external ACP connect interface is 4241 to collocate an ACP edge node and an NMS host by making one a virtual 4242 machine or container inside the other; and therefore converting the 4243 unprotected external ACP subnet into an internal virtual subnet in a 4244 single device. This would ultimately result in a fully ACP enabled 4245 NMS host with minimum impact to the NMS hosts software architecture. 4246 This approach is not limited to NMS hosts but could equally be 4247 applied to devices consisting of one or more VNF (virtual network 4248 functions): An internal virtual subnet connecting out-of-band 4249 management interfaces of the VNFs to an ACP edge router VNF. 4251 The core requirement is that the software components need to have a 4252 network stack that permits access to the ACP and optionally also the 4253 Data-Plane. Like in the physical setup for NMS hosts this can be 4254 realized via two internal virtual subnets. One that is connecting to 4255 the ACP (which could be a container or virtual machine by itself), 4256 and one (or more) connecting into the Data-Plane. 4258 This "internal" use of ACP connect approach should not be considered 4259 to be a "workaround" because in this case it is possible to build a 4260 correct security model: It is not necessary to rely on unprovable 4261 external physical security mechanisms as in the case of external NMS 4262 hosts. Instead, the orchestration of the ACP, the virtual subnets 4263 and the software components can be done by trusted software that 4264 could be considered to be part of the ANI (or even an extended ACP). 4265 This software component is responsible for ensuring that only trusted 4266 software components will get access to that virtual subnet and that 4267 only even more trusted software components will get access to both 4268 the ACP virtual subnet and the Data-Plane (because those ACP users 4269 could leak traffic between ACP and Data-Plane). This trust could be 4270 established for example through cryptographic means such as signed 4271 software packages. 4273 8.1.3. Auto Configuration 4275 ACP edge nodes, NMS hosts and software components that as described 4276 in the previous section are meant to be composed via virtual 4277 interfaces SHOULD support on the ACP connect subnet StateLess Address 4278 Autoconfiguration (SLAAC - [RFC4862]) and route auto configuration 4279 according to [RFC4191]. 4281 The ACP edge node acts as the router towards the ACP on the ACP 4282 connect subnet, providing the (auto-)configured prefix for the ACP 4283 connect subnet and (auto-)configured routes into the ACP to NMS hosts 4284 and/or software components. 4286 The ACP edge node uses the Route Information Option (RIO) of RFC4191 4287 to announce aggregated prefixes for address prefixes used in the ACP 4288 (with normal RIO lifetimes. In addition, the ACP edge node also uses 4289 a RIO to announce the default route (::/0) with a lifetime of 0. 4291 These RIOs allow to connect Type C hosts to the ACP via an ACP 4292 connect subnet on one interface and another network (Data Plane / NMS 4293 network) on the same or another interface of the Type C host, relying 4294 on other routers than the ACP edge node. The RIOs ensure that these 4295 hosts will only route the prefixes used in the ACP to the ACP edge 4296 node. 4298 Type A/B host ignore the RIOs and will consider the ACP node to be 4299 their default router for all destination. This is sufficient when 4300 type A/B hosts only need to connect to the ACP but not to other 4301 networks. Attaching Type A/B hosts to both the ACP and other 4302 networks, requires either explicit ACP prefix route configuration on 4303 the Type A/B hosts or the combined ACP/Data-Plane interface on the 4304 ACP edge node, see Section 8.1.4. 4306 Aggregated prefix means that the ACP edge node needs to only announce 4307 the /48 ULA prefixes used in the ACP but none of the actual /64 4308 (Manual Addressing Sub-Scheme), /127 (ACP Zone Addressing Sub- 4309 Scheme), /112 or /120 (Vlong Addressing Sub-Scheme) routes of actual 4310 ACP nodes. If ACP interfaces are configured with non ULA prefixes, 4311 then those prefixes cannot be aggregated without further configured 4312 policy on the ACP edge node. This explains the above recommendation 4313 to use ACP ULA prefix covered prefixes for ACP connect interfaces: 4314 They allow for a shorter list of prefixes to be signaled via RFC4191 4315 to NMS hosts and software components. 4317 The ACP edge nodes that have a Vlong ACP address MAY allocate a 4318 subset of their /112 or /120 address prefix to ACP connect 4319 interface(s) to eliminate the need to non-autonomically configure/ 4320 provision the address prefixes for such ACP connect interfaces. 4322 8.1.4. Combined ACP/Data-Plane Interface (VRF Select) 4324 Combined ACP and Data-Plane interface 4325 . 4326 +--------+ +--------------------+ . +--------------+ 4327 | ACP | |ACP Edge No | . | NMS Host(s) | 4328 | Node | | | . | / Software | 4329 | | | [ACP ]. | . | |+ 4330 | | | .[VRF ] .[VRF ] | v | "ACP address"|| 4331 | +-------+. .[Select].+--------+ "Date Plane || 4332 | | ^ | .[Data ]. | | Address(es)"|| 4333 | | . | [Plane] | | || 4334 | | . | [ ] | +--------------+| 4335 +--------+ . +--------------------+ +--------------+ 4336 . 4337 Data-Plane "native" and + ACP auto-negotiated/encrypted 4339 Figure 17: VRF select 4341 Using two physical and/or virtual subnets (and therefore interfaces) 4342 into NMS Hosts (as per Section 8.1.1) or Software (as per 4343 Section 8.1.2) may be seen as additional complexity, for example with 4344 legacy NMS Hosts that support only one IP interface, or it may be 4345 insufficient to support [RFC4191] Type A or B host (see 4346 Section 8.1.3). 4348 To provide a single subnet into both ACP and Data-Plane, the ACP Edge 4349 node needs to de-multiplex packets from NMS hosts into ACP VRF and 4350 Data-Plane. This is sometimes called "VRF select". If the ACP VRF 4351 has no overlapping IPv6 addresses with the Data-Plane (it should have 4352 no overlapping addresses), then this function can use the IPv6 4353 Destination address. The problem is Source Address Selection on the 4354 NMS Host(s) according to RFC6724. 4356 Consider the simple case: The ACP uses only one ULA prefix, the ACP 4357 IPv6 prefix for the Combined ACP and Data-Plane interface is covered 4358 by that ULA prefix. The ACP edge node announces both the ACP IPv6 4359 prefix and one (or more) prefixes for the Data-Plane. Without 4360 further policy configurations on the NMS Host(s), it may select its 4361 ACP address as a source address for Data-Plane ULA destinations 4362 because of Rule 8 of RFC6724. The ACP edge node can pass on the 4363 packet to the Data-Plane, but the ACP source address should not be 4364 used for Data-Plane traffic, and return traffic may fail. 4366 If the ACP carries multiple ULA prefixes or non-ULA ACP connect 4367 prefixes, then the correct source address selection becomes even more 4368 problematic. 4370 With separate ACP connect and Data-Plane subnets and RFC4191 prefix 4371 announcements that are to be routed across the ACP connect interface, 4372 RFC6724 source address selection Rule 5 (use address of outgoing 4373 interface) will be used, so that above problems do not occur, even in 4374 more complex cases of multiple ULA and non-ULA prefixes in the ACP 4375 routing table. 4377 To achieve the same behavior with a Combined ACP and Data-Plane 4378 interface, the ACP Edge Node needs to behave as two separate routers 4379 on the interface: One link-local IPv6 address/router for its ACP 4380 reachability, and one link-local IPv6 address/router for its Data- 4381 Plane reachability. The Router Advertisements for both are as 4382 described above (Section 8.1.3): For the ACP, the ACP prefix is 4383 announced together with RFC4191 option for the prefixes routed across 4384 the ACP and lifetime=0 to disqualify this next-hop as a default 4385 router. For the Data-Plane, the Data-Plane prefix(es) are announced 4386 together with whatever dafault router parameters are used for the 4387 Data-Plane. 4389 In result, RFC6724 source address selection Rule 5.5 may result in 4390 the same correct source address selection behavior of NMS hosts 4391 without further configuration on it as the separate ACP connect and 4392 Data-Plane interfaces. As described in the text for Rule 5.5, this 4393 is only a MAY, because IPv6 hosts are not required to track next-hop 4394 information. If an NMS Host does not do this, then separate ACP 4395 connect and Data-Plane interfaces are the preferable method of 4396 attachment. Hosts implementing [RFC8028] should (instead of may) 4397 implement [RFC6724] Rule 5.5, so it is preferred for hosts to support 4398 [RFC8028]. 4400 ACP edge nodes MAY support the Combined ACP and Data-Plane interface. 4402 8.1.5. Use of GRASP 4404 GRASP can and should be possible to use across ACP connect 4405 interfaces, especially in the architectural correct solution when it 4406 is used as a mechanism to connect Software (e.g., ASA or legacy NMS 4407 applications) to the ACP. 4409 Given how the ACP is the security and transport substrate for GRASP, 4410 the requirements for devices connected via ACP connect is that those 4411 are equivalently (if not better) secured against attacks than ACP 4412 nodes that do not use ACP connect and run only software that is 4413 equally (if not better) protected, known (or trusted) not to be 4414 malicious and accordingly designed to isolate access to the ACP 4415 against external equipment. 4417 The difference in security is that cryptographic security of the ACP 4418 secure channel is replaced by required physical security/control of 4419 the network connection between an ACP edge node and the NMS or other 4420 host reachable via the ACP connect interface. See Section 8.1.1. 4422 When using "Combined ACP and Data-Plane Interfaces", care has to be 4423 taken that only GRASP messages intended for the ACP GRASP domain 4424 received from Software or NMS Hosts are forwarded by ACP edge nodes. 4425 Currently there is no definition for a GRASP security and transport 4426 substrate beside the ACP, so there is no definition how such 4427 Software/NMS Host could participate in two separate GRASP Domains 4428 across the same subnet (ACP and Data-Plane domains). At current it 4429 is assumed that all GRASP packets on a Combined ACP and Data-Plane 4430 interface belong to the GRASP ACP Domain. They SHOULD all use the 4431 ACP IPv6 addresses of the Software/NMS Hosts. The link-local IPv6 4432 addresses of Software/NMS Hosts (used for GRASP M_DISCOVERY and 4433 M_FLOOD messages) are also assumed to belong to the ACP address 4434 space. 4436 8.2. Connecting ACP islands over Non-ACP L3 networks (Remote ACP 4437 neighbors) 4439 Not all nodes in a network may support the ACP. If non-ACP Layer-2 4440 devices are between ACP nodes, the ACP will work across it since it 4441 is IP based. However, the autonomic discovery of ACP neighbors via 4442 DULL GRASP is only intended to work across L2 connections, so it is 4443 not sufficient to autonomically create ACP connections across non-ACP 4444 Layer-3 devices. 4446 8.2.1. Configured Remote ACP neighbor 4448 On the ACP node, remote ACP neighbors are configured explicitly. The 4449 parameters of such a "connection" are described in the following 4450 ABNF. 4452 connection = [ method , local-addr, remote-addr, ?pmtu ] 4453 method = [ "IKEv2", ?port ] 4454 method =/ [ "DTLS", port ] 4455 local-addr = [ address , ?vrf ] 4456 remote-addr = [ address ] 4457 address = ("any" | ipv4-address | ipv6-address ) 4458 vrf = tstr ; Name of a VRF on this node with local-address 4460 Figure 18: Parameters for remote ACP neighbors 4462 Explicit configuration of a remote-peer according to this ABNF 4463 provides all the information to build a secure channel without 4464 requiring a tunnel to that peer and running DULL GRASP inside of it. 4466 The configuration includes the parameters otherwise signaled via DULL 4467 GRASP: local address, remote (peer) locator and method. The 4468 differences over DULL GRASP local neighbor discovery and secure 4469 channel creation are as follows: 4471 * The local and remote address can be IPv4 or IPv6 and are typically 4472 global scope addresses. 4473 * The VRF across which the connection is built (and in which local- 4474 addr exists) can to be specified. If vrf is not specified, it is 4475 the default VRF on the node. In DULL GRASP the VRF is implied by 4476 the interface across which DULL GRASP operates. 4477 * If local address is "any", the local address used when initiating 4478 a secure channel connection is decided by source address selection 4479 ([RFC6724] for IPv6). As a responder, the connection listens on 4480 all addresses of the node in the selected VRF. 4481 * Configuration of port is only required for methods where no 4482 defaults exist (e.g., "DTLS"). 4484 * If remote address is "any", the connection is only a responder. 4485 It is a "hub" that can be used by multiple remote peers to connect 4486 simultaneously - without having to know or configure their 4487 addresses. Example: Hub site for remote "spoke" sites reachable 4488 over the Internet. 4489 * Pmtu should be configurable to overcome issues/limitations of Path 4490 MTU Discovery (PMTUD). 4491 * IKEv2/IPsec to remote peers should support the optional NAT 4492 Traversal (NAT-T) procedures. 4494 8.2.2. Tunneled Remote ACP Neighbor 4496 An IPinIP, GRE or other form of pre-existing tunnel is configured 4497 between two remote ACP peers and the virtual interfaces representing 4498 the tunnel are configured for "ACP enable". This will enable IPv6 4499 link local addresses and DULL on this tunnel. In result, the tunnel 4500 is used for normal "L2 adjacent" candidate ACP neighbor discovery 4501 with DULL and secure channel setup procedures described in this 4502 document. 4504 Tunneled Remote ACP Neighbor requires two encapsulations: the 4505 configured tunnel and the secure channel inside of that tunnel. This 4506 makes it in general less desirable than Configured Remote ACP 4507 Neighbor. Benefits of tunnels are that it may be easier to implement 4508 because there is no change to the ACP functionality - just running it 4509 over a virtual (tunnel) interface instead of only native interfaces. 4510 The tunnel itself may also provide PMTUD while the secure channel 4511 method may not. Or the tunnel mechanism is permitted/possible 4512 through some firewall while the secure channel method may not. 4514 Tunneling using an insecure tunnel encapsulation increases on average 4515 the risk of a MITM downgrade attack somewhere along the underlay path 4516 that blocks all but the most easily attacked ACP secure channel 4517 option. ACP nodes supporting tunneled remote ACP Neighbors SHOULD 4518 support configuration on such tunnel interfaces to restrict or 4519 explicitly select the available ACP secure channel protocols (if the 4520 ACP node supports more than one ACP secure channel protocol in the 4521 first place). 4523 8.2.3. Summary 4525 Configured/Tunneled Remote ACP neighbors are less "indestructible" 4526 than L2 adjacent ACP neighbors based on link local addressing, since 4527 they depend on more correct Data-Plane operations, such as routing 4528 and global addressing. 4530 Nevertheless, these options may be crucial to incrementally deploy 4531 the ACP, especially if it is meant to connect islands across the 4532 Internet. Implementations SHOULD support at least Tunneled Remote 4533 ACP Neighbors via GRE tunnels - which is likely the most common 4534 router-to-router tunneling protocol in use today. 4536 9. ACP Operations (Informative) 4538 The following sections document important operational aspects of the 4539 ACP. They are not normative because they do not impact the 4540 interoperability between components of the ACP, but they include 4541 recommendations/requirements for the internal operational model 4542 beneficial or necessary to achieve the desired use-case benefits of 4543 the ACP (see Section 3). 4545 * Section 9.1 describes recommended operator diagnostics 4546 capabilities of ACP nodes. 4547 * Section 9.2 describes high level how an ACP registrar needs to 4548 work, what its configuration parameters are and specific issues 4549 impacting the choices of deployment design due to renewal and 4550 revocation issues. It describes a model where ACP Registrars have 4551 their own sub-CA to provide the most distributed deployment option 4552 for ACP Registrars, and it describes considerations for 4553 centralized policy control of ACP Registrar operations. 4554 * Section 9.3 describes suggested ACP node behavior and operational 4555 interfaces (configuration options) to manage the ACP in so-called 4556 greenfield devices (previously unconfigured) and brownfield 4557 devices (preconfigured). 4559 The recommendations and suggestions of this chapter were derived from 4560 operational experience gained with a commercially available pre- 4561 standard ACP implementation. 4563 9.1. ACP (and BRSKI) Diagnostics 4565 Even though ACP and ANI in general are taking out many manual 4566 configuration mistakes through their automation, it is important to 4567 provide good diagnostics for them. 4569 Basic standardized diagnostics would require support for (yang) 4570 models representing the complete (auto-)configuration and operational 4571 state of all components: GRASP, ACP and the infrastructure used by 4572 them: TLS/DTLS, IPsec, certificates, TA, time, VRF and so on. While 4573 necessary, this is not sufficient: 4575 Simply representing the state of components does not allow operators 4576 to quickly take action - unless they do understand how to interpret 4577 the data, and that can mean a requirement for deep understanding of 4578 all components and how they interact in the ACP/ANI. 4580 Diagnostic supports should help to quickly answer the questions 4581 operators are expected to ask, such as "is the ACP working 4582 correctly?", or "why is there no ACP connection to a known 4583 neighboring node?" 4585 In current network management approaches, the logic to answer these 4586 questions is most often built as centralized diagnostics software 4587 that leverages the above mentioned data models. While this approach 4588 is feasible for components utilizing the ANI, it is not sufficient to 4589 diagnose the ANI itself: 4591 * Developing the logic to identify common issues requires 4592 operational experience with the components of the ANI. Letting 4593 each management system define its own analysis is inefficient. 4594 * When the ANI is not operating correctly, it may not be possible to 4595 run diagnostics from remote because of missing connectivity. The 4596 ANI should therefore have diagnostic capabilities available 4597 locally on the nodes themselves. 4598 * Certain operations are difficult or impossible to monitor in real- 4599 time, such as initial bootstrap issues in a network location where 4600 no capabilities exist to attach local diagnostics. Therefore, it 4601 is important to also define means of capturing (logging) 4602 diagnostics locally for later retrieval. Ideally, these captures 4603 are also non-volatile so that they can survive extended power-off 4604 conditions - for example when a device that fails to be brought up 4605 zero-touch is being sent back for diagnostics at a more 4606 appropriate location. 4608 The simplest form of diagnostics answering questions such as the 4609 above is to represent the relevant information sequentially in 4610 dependency order, so that the first non-expected/non-operational item 4611 is the most likely root cause. Or just log/highlight that item. For 4612 example: 4614 Q: Is ACP operational to accept neighbor connections: 4616 * Check if any potentially necessary configuration to make ACP/ANI 4617 operational are correct (see Section 9.3 for a discussion of such 4618 commands). 4619 * Does the system time look reasonable, or could it be the default 4620 system time after clock chip battery failure (certificate checks 4621 depend on reasonable notion of time)?. 4623 * Does the node have keying material - domain certificate, TA 4624 certificates, ...> 4625 * If no keying material and ANI is supported/enabled, check the 4626 state of BRSKI (not detailed in this example). 4627 * Check the validity of the domain certificate: 4628 - Does the certificate validate against the TA? 4629 - Has it been revoked? 4630 - Was the last scheduled attempt to retrieve a CRL successful 4631 (e.g., do we know that our CRL information is up to date). 4632 - Is the certificate valid: validity start time in the past, 4633 expiration time in the future? 4634 - Does the certificate have a correctly formatted acp-node-name 4635 field? 4636 * Was the ACP VRF successfully created? 4637 * Is ACP enabled on one or more interfaces that are up and running? 4639 If all this looks good, the ACP should be running locally "fine" - 4640 but we did not check any ACP neighbor relationships. 4642 Question: why does the node not create a working ACP connection to a 4643 neighbor on an interface? 4645 * Is the interface physically up? Does it have an IPv6 link-local 4646 address? 4647 * Is it enabled for ACP? 4648 * Do we successfully send DULL GRASP messages to the interface (link 4649 layer errors)? 4650 * Do we receive DULL GRASP messages on the interface? If not, some 4651 intervening L2 equipment performing bad MLD snooping could have 4652 caused problems. Provide e.g., diagnostics of the MLD querier 4653 IPv6 and MAC address. 4654 * Do we see the ACP objective in any DULL GRASP message from that 4655 interface? Diagnose the supported secure channel methods. 4656 * Do we know the MAC address of the neighbor with the ACP objective? 4657 If not, diagnose SLAAC/ND state. 4658 * When did we last attempt to build an ACP secure channel to the 4659 neighbor? 4660 * If it failed, why: 4661 - Did the neighbor close the connection on us or did we close the 4662 connection on it because the domain certificate membership 4663 failed? 4664 - If the neighbor closed the connection on us, provide any error 4665 diagnostics from the secure channel protocol. 4666 - If we failed the attempt, display our local reason: 4667 o There was no common secure channel protocol supported by the 4668 two neighbors (this could not happen on nodes supporting 4669 this specification because it mandates common support for 4670 IPsec). 4672 o The ACP certificate membership check (Section 6.2.3) fails: 4673 + The neighbor's certificate is not signed directly or 4674 indirectly by one of the nodes TA. Provide diagnostics 4675 which TA it has (can identify whom the device belongs 4676 to). 4677 + The neighbor's certificate does not have the same domain 4678 (or no domain at all). Diagnose domain-name and 4679 potentially other cert info. 4680 + The neighbor's certificate has been revoked or could not 4681 be authenticated by OCSP. 4682 + The neighbor's certificate has expired - or is not yet 4683 valid. 4684 - Any other connection issues in e.g., IKEv2 / IPsec, DTLS?. 4686 Question: Is the ACP operating correctly across its secure channels? 4688 * Are there one or more active ACP neighbors with secure channels? 4689 * Is the RPL routing protocol for the ACP running? 4690 * Is there a default route to the root in the ACP routing table? 4691 * Is there for each direct ACP neighbor not reachable over the ACP 4692 virtual interface to the root a route in the ACP routing table? 4693 * Is ACP GRASP running? 4694 * Is at least one SRV.est objective cached (to support certificate 4695 renewal)? 4696 * Is there at least one BRSKI registrar objective cached (in case 4697 BRSKI is supported) 4698 * Is BRSKI proxy operating normally on all interfaces where ACP is 4699 operating? 4700 * ... 4702 These lists are not necessarily complete, but illustrate the 4703 principle and show that there are variety of issues ranging from 4704 normal operational causes (a neighbor in another ACP domain) over 4705 problems in the credentials management (certificate lifetimes), 4706 explicit security actions (revocation) or unexpected connectivity 4707 issues (intervening L2 equipment). 4709 The items so far are illustrating how the ANI operations can be 4710 diagnosed with passive observation of the operational state of its 4711 components including historic/cached/counted events. This is not 4712 necessary sufficient to provide good enough diagnostics overall: 4714 The components of ACP and BRSKI are designed with security in mind 4715 but they do not attempt to provide diagnostics for building the 4716 network itself. Consider two examples: 4718 1. BRSKI does not allow for a neighboring device to identify the 4719 pledges IDevID certificate. Only the selected BRSKI registrar 4720 can do this, but it may be difficult to disseminate information 4721 about undesired pledges from those BRSKI registrars to locations/ 4722 nodes where information about those pledges is desired. 4723 2. LLDP disseminates information about nodes to their immediate 4724 neighbors, such as node model/type/software and interface name/ 4725 number of the connection. This information is often helpful or 4726 even necessary in network diagnostics. It can equally be 4727 considered to be too insecure to make this information available 4728 unprotected to all possible neighbors. 4730 An "interested adjacent party" can always determine the IDevID 4731 certificate of a BRSKI pledge by behaving like a BRSKI proxy/ 4732 registrar. Therefore, the IDevID certificate of a BRSKI pledge is 4733 not meant to be protected - it just has to be queried and is not 4734 signaled unsolicited (as it would be in LLDP) so that other observers 4735 on the same subnet can determine who is an "interested adjacent 4736 party". 4738 9.1.1. Secure Channel Peer diagnostics 4740 When using mutual certificate authentication, the TA certificate is 4741 not required to be signaled explicitly because its hash is sufficient 4742 for certificate chain validation. In the case of ACP secure channel 4743 setup this leads to limited diagnostics when authentication fails 4744 because of TA mismatch. For this reason, Section 6.8.2 recommends to 4745 also include the TA certificate in the secure channel signaling. 4746 This should be possible to do without protocol modifications in the 4747 security association protocols used by the ACP. For example, while 4748 [RFC7296] does not mention this, it also does not prohibit it. 4750 One common deployment use case where the diagnostic through the 4751 signaled TA of a candidate peer is very helpful are multi-tenant 4752 environments such as office buildings, where different tenants run 4753 their own networks and ACPs. Each tenant is given supposedly 4754 disjoint L2 connectivity through the building infrastructure. In 4755 these environments there are various common errors through which a 4756 device may receive L2 connectivity into the wrong tenants network. 4758 While the ACP itself is not impact by this, the Data-Plane to be 4759 built later may be impacted. Therefore, it is important to be able 4760 to diagnose such undesirable connectivity from the ACP so that any 4761 autonomic or non-autonomic mechanisms to configure the Data-Plane can 4762 accordingly treat such interfaces. The information in the TA of the 4763 peer can then ease troubleshooting of such issues. 4765 Another example case is the intended or accidental re-activation of 4766 equipment whose TA certificate has long expired, such as redundant 4767 gear taken from storage after years. 4769 A third example case is when in a mergers & acquisition case ACP 4770 nodes have not been correctly provisioned with the mutual TA of 4771 previously disjoint ACP. This is assuming that the ACP domain names 4772 where already aligned so that the ACP domain membership check is only 4773 failing on the TA. 4775 A fourth example case is when multiple registrars where set up for 4776 the same ACP but without correctly setting up the same TA. For 4777 example, when registrars support to also be CA themselves but are 4778 misconfigured to become TA instead of intermediate CA. 4780 9.2. ACP Registrars 4782 As described in Section 6.11.7, the ACP addressing mechanism is 4783 designed to enable lightweight, distributed and uncoordinated ACP 4784 registrars that are providing ACP address prefixes to candidate ACP 4785 nodes by enrolling them with an ACP certificate into an ACP domain 4786 via any appropriate mechanism/protocol, automated or not. 4788 This section discusses informatively more details and options for ACP 4789 registrars. 4791 9.2.1. Registrar interactions 4793 This section summarizes and discusses the interactions with other 4794 entities required by an ACP registrar. 4796 In a simple instance of an ACP network, no central NOC component 4797 beside a TA is required. Typically, this is a root CA. One or more 4798 uncoordinated acting ACP registrar can be set up, performing the 4799 following interactions: 4801 To orchestrate enrolling a candidate ACP node autonomically, the ACP 4802 registrar can rely on the ACP and use Proxies to reach the candidate 4803 ACP node, therefore allowing minimum pre-existing (auto-)configured 4804 network services on the candidate ACP node. BRSKI defines the BRSKI 4805 proxy, a design that can be adopted for various protocols that 4806 Pledges/candidate ACP nodes could want to use, for example BRSKI over 4807 CoAP (Constrained Application Protocol), or proxying of NETCONF. 4809 To reach a TA that has no ACP connectivity, the ACP registrar would 4810 use the Data-Plane. ACP and Data-Plane in an ACP registrar could 4811 (and by default should be) completely isolated from each other at the 4812 network level. Only applications such as the ACP registrar would 4813 need the ability for their transport stacks to access both. 4815 In non-autonomic enrollment options, the Data-Plane between a ACP 4816 registrar and the candidate ACP node needs to be configured first. 4817 This includes the ACP registrar and the candidate ACP node. Then any 4818 appropriate set of protocols can be used between ACP registrar and 4819 candidate ACP node to discover the other side, and then connect and 4820 enroll (configure) the candidate ACP node with an ACP certificate. 4821 NETCONF ZeroTouch ([RFC8572]) is an example protocol that could be 4822 used for this. BRSKI using optional discovery mechanisms is equally 4823 a possibility for candidate ACP nodes attempting to be enrolled 4824 across non-ACP networks, such as the Internet. 4826 When candidate ACP nodes have secure bootstrap, such as BRSKI 4827 Pledges, they will not trust to be configured/enrolled across the 4828 network, unless being presented with a voucher (see [RFC8366]) 4829 authorizing the network to take possession of the node. An ACP 4830 registrar will then need a method to retrieve such a voucher, either 4831 offline, or online from a MASA (Manufacturer Authorized Signing 4832 Authority). BRSKI and NETCONF ZeroTouch are two protocols that 4833 include capabilities to present the voucher to the candidate ACP 4834 node. 4836 An ACP registrar could operate EST for ACP certificate renewal and/or 4837 act as a CRL Distribution point. A node performing these services 4838 does not need to support performing (initial) enrollment, but it does 4839 require the same above described connectivity as an ACP registrar: 4840 via the ACP to ACP nodes and via the Data-Plane to the TA and other 4841 sources of CRL information. 4843 9.2.2. Registrar Parameter 4845 The interactions of an ACP registrar outlined Section 6.11.7 and 4846 Section 9.2.1 above depend on the following parameters: 4848 * A URL to the TA and credentials so that the ACP registrar can let 4849 the TA sign candidate ACP node certificates. 4850 * The ACP domain-name. 4851 * The Registrar-ID to use. This could default to a MAC address of 4852 the ACP registrar. 4854 * For recovery, the next-useable Node-IDs for zone (Zone-ID=0) sub- 4855 addressing scheme, for Vlong /112 and for Vlong /120 sub- 4856 addressing scheme. These IDs would only need to be provisioned 4857 after recovering from a crash. Some other mechanism would be 4858 required to remember these IDs in a backup location or to recover 4859 them from the set of currently known ACP nodes. 4860 * Policies if candidate ACP nodes should receive a domain 4861 certificate or not, for example based on the devices IDevID 4862 certificate as in BRSKI. The ACP registrar may have a whitelist 4863 or blacklist of devices [X.520] "serialNumbers" attribute in the 4864 subject field distinguished name encoding from their IDevID 4865 certificate. 4866 * Policies what type of address prefix to assign to a candidate ACP 4867 devices, based on likely the same information. 4868 * For BRSKI or other mechanisms using vouchers: Parameters to 4869 determine how to retrieve vouchers for specific type of secure 4870 bootstrap candidate ACP nodes (such as MASA URLs), unless this 4871 information is automatically learned such as from the IDevID 4872 certificate of candidate ACP nodes (as defined in BRSKI). 4874 9.2.3. Certificate renewal and limitations 4876 When an ACP node renews/rekeys its certificate, it may end up doing 4877 so via a different registrar (e.g., EST server) than the one it 4878 originally received its ACP certificate from, for example because 4879 that original ACP registrar is gone. The ACP registrar through which 4880 the renewal/rekeying is performed would by default trust the acp- 4881 node-name from the ACP nodes current ACP certificate and maintain 4882 this information so that the ACP node maintains its ACP address 4883 prefix. In EST renewal/rekeying, the ACP nodes current ACP 4884 certificate is signaled during the TLS handshake. 4886 This simple scenario has two limitations: 4888 1. The ACP registrars cannot directly assign certificates to nodes 4889 and therefore needs an "online" connection to the TA. 4890 2. Recovery from a compromised ACP registrar is difficult. When an 4891 ACP registrar is compromised, it can insert for example a 4892 conflicting acp-node-name and create thereby an attack against 4893 other ACP nodes through the ACP routing protocol. 4895 Even when such a malicious ACP registrar is detected, resolving the 4896 problem may be difficult because it would require identifying all the 4897 wrong ACP certificates assigned via the ACP registrar after it was 4898 compromised. And without additional centralized tracking of assigned 4899 certificates there is no way to do this. 4901 9.2.4. ACP Registrars with sub-CA 4903 In situations, where either of the above two limitations are an 4904 issue, ACP registrars could also be sub-CAs. This removes the need 4905 for connectivity to a TA whenever an ACP node is enrolled, and 4906 reduces the need for connectivity of such an ACP registrar to a TA to 4907 only those times when it needs to renew its own certificate. The ACP 4908 registrar would also now use its own (sub-CA) certificate to enroll 4909 and sign the ACP nodes certificates, and therefore it is only 4910 necessary to revoke a compromised ACP registrars sub-CA certificate. 4911 Alternatively one can let it expire and not renew it, when the 4912 certificate of the sub-CA is appropriately short-lived. 4914 As the ACP domain membership check verifies a peer ACP node's ACP 4915 certificate trust chain, it will also verify the signing certificate 4916 which is the compromised/revoked sub-CA certificate. Therefore, ACP 4917 domain membership for an ACP node enrolled from a compromised and 4918 discovered ACP registrar will fail. 4920 ACP nodes enrolled by a compromised ACP registrar would automatically 4921 fail to establish ACP channels and ACP domain certificate renewal via 4922 EST and therefore revert to their role as a candidate ACP members and 4923 attempt to get a new ACP certificate from an ACP registrar - for 4924 example, via BRSKI. In result, ACP registrars that have an 4925 associated sub-CA makes isolating and resolving issues with 4926 compromised registrars easier. 4928 Note that ACP registrars with sub-CA functionality also can control 4929 the lifetime of ACP certificates easier and therefore also be used as 4930 a tool to introduce short lived certificates and not rely on CRL, 4931 whereas the certificates for the sub-CAs themselves could be longer 4932 lived and subject to CRL. 4934 9.2.5. Centralized Policy Control 4936 When using multiple, uncoordinated ACP registrars, several advanced 4937 operations are potentially more complex than with a single, resilient 4938 policy control backend, for example including but not limited to: 4940 * Which candidate ACP node is permitted or not permitted into an ACP 4941 domain. This may not be a decision to be taken upfront, so that a 4942 policy per "serialNumber" attribute in the subject field 4943 distinguished name encoding can be loaded into every ACP 4944 registrar. Instead, it may better be decided in real-time 4945 including potentially a human decision in a NOC. 4946 * Tracking of all enrolled ACP nodes and their certificate 4947 information. For example, in support of revoking individual ACP 4948 nodes certificates. 4950 * More flexible policies what type of address prefix or even what 4951 specific address prefix to assign to a candidate ACP node. 4953 These and other operations could be introduced more easily by 4954 introducing a centralized Policy Management System (PMS) and 4955 modifying ACP registrar behavior so that it queries the PMS for any 4956 policy decision occurring during the candidate ACP node enrollment 4957 process and/or the ACP node certificate renewal process. For 4958 example, which ACP address prefix to assign. Likewise the ACP 4959 registrar would report any relevant state change information to the 4960 PMS as well, for example when a certificate was successfully enrolled 4961 onto a candidate ACP node. 4963 9.3. Enabling and disabling ACP/ANI 4965 Both ACP and BRSKI require interfaces to be operational enough to 4966 support sending/receiving their packets. In node types where 4967 interfaces are by default (e.g., without operator configuration) 4968 enabled, such as most L2 switches, this would be less of a change in 4969 behavior than in most L3 devices (e.g. routers), where interfaces are 4970 by default disabled. In almost all network devices it is common 4971 though for configuration to change interfaces to a physically 4972 disabled state and that would break the ACP. 4974 In this section, we discuss a suggested operational model to enable/ 4975 disable interfaces and nodes for ACP/ANI in a way that minimizes the 4976 risk of operator action to break the ACP in this way, and that also 4977 minimizes operator surprise when ACP/ANI becomes supported in node 4978 software. 4980 9.3.1. Filtering for non-ACP/ANI packets 4982 Whenever this document refers to enabling an interface for ACP (or 4983 BRSKI), it only requires to permit the interface to send/receive 4984 packets necessary to operate ACP (or BRSKI) - but not any other Data- 4985 Plane packets. Unless the Data-Plane is explicitly configured/ 4986 enabled, all packets not required for ACP/BRSKI should be filtered on 4987 input and output: 4989 Both BRSKI and ACP require link-local only IPv6 operations on 4990 interfaces and DULL GRASP. IPv6 link-local operations means the 4991 minimum signaling to auto-assign an IPv6 link-local address and talk 4992 to neighbors via their link-local address: SLAAC (Stateless Address 4993 Auto-Configuration - [RFC4862]) and ND (Neighbor Discovery - 4994 [RFC4861]). When the device is a BRSKI pledge, it may also require 4995 TCP/TLS connections to BRSKI proxies on the interface. When the 4996 device has keying material, and the ACP is running, it requires DULL 4997 GRASP packets and packets necessary for the secure-channel mechanism 4998 it supports, e.g., IKEv2 and IPsec ESP packets or DTLS packets to the 4999 IPv6 link-local address of an ACP neighbor on the interface. It also 5000 requires TCP/TLS packets for its BRSKI proxy functionality, if it 5001 does support BRSKI. 5003 9.3.2. Admin Down State 5005 Interfaces on most network equipment have at least two states: "up" 5006 and "down". These may have product specific names. "down" for 5007 example could be called "shutdown" and "up" could be called "no 5008 shutdown". The "down" state disables all interface operations down 5009 to the physical level. The "up" state enables the interface enough 5010 for all possible L2/L3 services to operate on top of it and it may 5011 also auto-enable some subset of them. More commonly, the operations 5012 of various L2/L3 services is controlled via additional node-wide or 5013 interface level options, but they all become only active when the 5014 interface is not "down". Therefore, an easy way to ensure that all 5015 L2/L3 operations on an interface are inactive is to put the interface 5016 into "down" state. The fact that this also physically shuts down the 5017 interface is in many cases just a side effect, but it may be 5018 important in other cases (see below, Section 9.3.2.2). 5020 One of the common problems of remote management is for the operator 5021 or SDN controller to cut its own connectivity to the remote node by a 5022 configuration impacting its own management connection into the node. 5023 The ACP itself should have no dedicated configuration other than 5024 aforementioned enablement of the ACP on brownfield ACP nodes. This 5025 leaves configuration that cannot distinguish between ACP and Data- 5026 Plane as sources of configuration mistakes as these commands will 5027 impact the ACP even though they should only impact the Data-Plane. 5029 The one ubiquitous type of commands that do this on many type of 5030 routers are interface "down" commands/configurations. When such a 5031 command is applied to the interface through which the ACP provides 5032 access for remote management it would cut the remote management 5033 connection through the ACP because, as outlined above, the "down" 5034 commands typically impact the physical layer too and not only the 5035 Data-Plane services. 5037 To provide ACP/ANI resilience against such operator misconfiguration, 5038 this document recommends to separate the "down" state of interfaces 5039 into an "admin down" state where the physical layer is kept running 5040 and ACP/ANI can use the interface and a "physical down" state. Any 5041 existing "down" configurations would map to "admin down". In "admin 5042 down", any existing L2/L3 services of the Data-Plane should see no 5043 difference to "physical down" state. To ensure that no Data-Plane 5044 packets could be sent/received, packet filtering could be established 5045 automatically as described above in Section 9.3.1. 5047 An example of non-ACP but ANI traffic that should be permitted to 5048 pass even in "admin-down" state is BRSKI enrollment traffic between 5049 BRSKI pledge and a BRSKI proxy. 5051 As necessary (see discussion below) new configuration options could 5052 be introduced to issue "physical down". The options should be 5053 provided with additional checks to minimize the risk of issuing them 5054 in a way that breaks the ACP without automatic restoration. For 5055 example, they could be denied to be issued from a control connection 5056 (NETCONF/SSH) that goes across the interface itself ("do not 5057 disconnect yourself"). Or they could be performed only temporary and 5058 only be made permanent with additional later reconfirmation. 5060 In the following sub-sections important aspects to the introduction 5061 of "admin down" state are discussed. 5063 9.3.2.1. Security 5065 Interfaces are physically brought down (or left in default down 5066 state) as a form of security. "Admin down" state as described above 5067 provides also a high level of security because it only permits ACP/ 5068 ANI operations which are both well secured. Ultimately, it is 5069 subject to security review for the deployment whether "admin down" is 5070 a feasible replacement for "physical down". 5072 The need to trust the security of ACP/ANI operations needs to be 5073 weighed against the operational benefits of permitting this: Consider 5074 the typical example of a CPE (customer premises equipment) with no 5075 on-site network expert. User ports are in physical down state unless 5076 explicitly configured not to be. In a misconfiguration situation, 5077 the uplink connection is incorrectly plugged into such as user port. 5078 The device is disconnected from the network and therefore no 5079 diagnostics from the network side is possible anymore. 5080 Alternatively, all ports default to "admin down". The ACP (but not 5081 the Data-Plane) would still automatically form. Diagnostics from the 5082 network side is possible and operator reaction could include to 5083 either make this port the operational uplink port or to instruct re- 5084 cabling. Security wise, only ACP/ANI could be attacked, all other 5085 functions are filtered on interfaces in "admin down" state. 5087 9.3.2.2. Fast state propagation and Diagnostics 5089 "Physical down" state propagates on many interface types (e.g., 5090 Ethernet) to the other side. This can trigger fast L2/L3 protocol 5091 reaction on the other side and "admin down" would not have the same 5092 (fast) result. 5094 Bringing interfaces to "physical down" state is to the best of our 5095 knowledge always a result of operator action, but today, never the 5096 result of autonomic L2/L3 services running on the nodes. Therefore, 5097 one option is to change the operator action to not rely on link-state 5098 propagation anymore. This may not be possible when both sides are 5099 under different operator control, but in that case it is unlikely 5100 that the ACP is running across the link and actually putting the 5101 interface into "physical down" state may still be a good option. 5103 Ideally, fast physical state propagation is replaced by fast software 5104 driven state propagation. For example, a DULL GRASP "admin-state" 5105 objective could be used to auto configure a Bidirectional Forwarding 5106 Protocol (BFD, [RFC5880]) session between the two sides of the link 5107 that would be used to propagate the "up" vs. admin down state. 5109 Triggering physical down state may also be used as a mean of 5110 diagnosing cabling in the absence of easier methods. It is more 5111 complex than automated neighbor diagnostics because it requires 5112 coordinated remote access to both (likely) sides of a link to 5113 determine whether up/down toggling will cause the same reaction on 5114 the remote side. 5116 See Section 9.1 for a discussion about how LLDP and/or diagnostics 5117 via GRASP could be used to provide neighbor diagnostics, and 5118 therefore hopefully eliminating the need for "physical down" for 5119 neighbor diagnostics - as long as both neighbors support ACP/ANI. 5121 9.3.2.3. Low Level Link Diagnostics 5123 "Physical down" is performed to diagnose low-level interface behavior 5124 when higher layer services (e.g., IPv6) are not working. Especially 5125 Ethernet links are subject to a wide variety of possible wrong 5126 configuration/cablings if they do not support automatic selection of 5127 variable parameters such as speed (10/100/1000 Mbps), crossover 5128 (Auto-MDIX) and connector (fiber, copper - when interfaces have 5129 multiple but can only enable one at a time). The need for low level 5130 link diagnostic can therefore be minimized by using fully auto 5131 configuring links. 5133 In addition to "Physical down", low level diagnostics of Ethernet or 5134 other interfaces also involve the creation of other states on 5135 interfaces, such as physical Loopback (internal and/or external) or 5136 bringing down all packet transmissions for reflection/cable-length 5137 measurements. Any of these options would disrupt ACP as well. 5139 In cases where such low-level diagnostics of an operational link is 5140 desired but where the link could be a single point of failure for the 5141 ACP, ASA on both nodes of the link could perform a negotiated 5142 diagnostic that automatically terminates in a predetermined manner 5143 without dependence on external input ensuring the link will become 5144 operational again. 5146 9.3.2.4. Power Consumption Issues 5148 Power consumption of "physical down" interfaces, may be significantly 5149 lower than those in "admin down" state, for example on long-range 5150 fiber interfaces. Bringing up interfaces, for example to probe 5151 reachability, may also consume additional power. This can make these 5152 type of interfaces inappropriate to operate purely for the ACP when 5153 they are not currently needed for the Data-Plane. 5155 9.3.3. Interface level ACP/ANI enable 5157 The interface level configuration option "ACP enable" enables ACP 5158 operations on an interface, starting with ACP neighbor discovery via 5159 DULL GRAP. The interface level configuration option "ANI enable" on 5160 nodes supporting BRSKI and ACP starts with BRSKI pledge operations 5161 when there is no domain certificate on the node. On ACP/BRSKI nodes, 5162 "ACP enable" may not need to be supported, but only "ANI enable". 5163 Unless overridden by global configuration options (see later), "ACP/ 5164 ANI enable" will result in "down" state on an interface to behave as 5165 "admin down". 5167 9.3.4. Which interfaces to auto-enable? 5169 (Section 6.4) requires that "ACP enable" is automatically set on 5170 native interfaces, but not on non-native interfaces (reminder: a 5171 native interface is one that exists without operator configuration 5172 action such as physical interfaces in physical devices). 5174 Ideally, ACP enable is set automatically on all interfaces that 5175 provide access to additional connectivity that allows to reach more 5176 nodes of the ACP domain. The best set of interfaces necessary to 5177 achieve this is not possible to determine automatically. Native 5178 interfaces are the best automatic approximation. 5180 Consider an ACP domain of ACP nodes transitively connected via native 5181 interfaces. A Data-Plane tunnel between two of these nodes that are 5182 non-adjacent is created and "ACP enable" is set for that tunnel. ACP 5183 RPL sees this tunnel as just as a single hop. Routes in the ACP 5184 would use this hop as an attractive path element to connect regions 5185 adjacent to the tunnel nodes. In result, the actual hop-by-hop paths 5186 used by traffic in the ACP can become worse. In addition, correct 5187 forwarding in the ACP now depends on correct Data-Plane forwarding 5188 config including QoS, filtering and other security on the Data-Plane 5189 path across which this tunnel runs. This is the main issue why "ACP/ 5190 ANI enable" should not be set automatically on non-native interfaces. 5192 If the tunnel would connect two previously disjoint ACP regions, then 5193 it likely would be useful for the ACP. A Data-Plane tunnel could 5194 also run across nodes without ACP and provide additional connectivity 5195 for an already connected ACP network. The benefit of this additional 5196 ACP redundancy has to be weighed against the problems of relying on 5197 the Data-Plane. If a tunnel connects two separate ACP regions: how 5198 many tunnels should be created to connect these ACP regions reliably 5199 enough? Between which nodes? These are all standard tunneled 5200 network design questions not specific to the ACP, and there are no 5201 generic fully automated answers. 5203 Instead of automatically setting "ACP enable" on these type of 5204 interfaces, the decision needs to be based on the use purpose of the 5205 non-native interface and "ACP enable" needs to be set in conjunction 5206 with the mechanism through which the non-native interface is created/ 5207 configured. 5209 In addition to explicit setting of "ACP/ANI enable", non-native 5210 interfaces also need to support configuration of the ACP RPL cost of 5211 the link - to avoid the problems of attracting too much traffic to 5212 the link as described above. 5214 Even native interfaces may not be able to automatically perform BRSKI 5215 or ACP because they may require additional operator input to become 5216 operational. Example include DSL interfaces requiring PPPoE 5217 credentials or mobile interfaces requiring credentials from a SIM 5218 card. Whatever mechanism is used to provide the necessary config to 5219 the device to enable the interface can also be expanded to decide on 5220 whether or not to set "ACP/ANI enable". 5222 The goal of automatically setting "ACP/ANI enable" on interfaces 5223 (native or not) is to eliminate unnecessary "touches" to the node to 5224 make its operation as much as possible "zero-touch" with respect to 5225 ACP/ANI. If there are "unavoidable touches" such a creating/ 5226 configuring a non-native interface or provisioning credentials for a 5227 native interface, then "ACP/ANI enable" should be added as an option 5228 to that "touch". If a wrong "touch" is easily fixed (not creating 5229 another high-cost touch), then the default should be not to enable 5230 ANI/ACP, and if it is potentially expensive or slow to fix (e.g., 5231 parameters on SIM card shipped to remote location), then the default 5232 should be to enable ACP/ANI. 5234 9.3.5. Node Level ACP/ANI enable 5236 A node level command "ACP/ANI enable [up-if-only]" enables ACP or ANI 5237 on the node (ANI = ACP + BRSKI). Without this command set, any 5238 interface level "ACP/ANI enable" is ignored. Once set, ACP/ANI will 5239 operate an interface where "ACP/ANI enable" is set. Setting of 5240 interface level "ACP/ANI enable" is either automatic (default) or 5241 explicit through operator action as described in the previous 5242 section. 5244 If the option "up-if-only" is selected, the behavior of "down" 5245 interfaces is unchanged, and ACP/ANI will only operate on interfaces 5246 where "ACP/ANI enable" is set and that are "up". When it is not set, 5247 then "down" state of interfaces with "ACP/ANI enable" is modified to 5248 behave as "admin down". 5250 9.3.5.1. Brownfield nodes 5252 A "brownfield" node is one that already has a configured Data-Plane. 5254 Executing global "ACP/ANI enable [up-if-only]" on each node is the 5255 only command necessary to create an ACP across a network of 5256 brownfield nodes once all the nodes have a domain certificate. When 5257 BRSKI is used ("ANI enable"), provisioning of the certificates only 5258 requires set-up of a single BRSKI registrar node which could also 5259 implement a CA for the network. This is the simplest way to 5260 introduce ACP/ANI into existing (== brownfield) networks. 5262 The need to explicitly enable ACP/ANI is especially important in 5263 brownfield nodes because otherwise software updates may introduce 5264 support for ACP/ANI: Automatic enablement of ACP/ANI in networks 5265 where the operator does not only not want ACP/ANI but where the 5266 operator likely never even heard of it could be quite irritating to 5267 the operator. Especially when "down" behavior is changed to "admin 5268 down". 5270 Automatically setting "ANI enable" on brownfield nodes where the 5271 operator is unaware of BRSKI and MASA operations could also be an 5272 unlikely but then critical security issue. If an attacker could 5273 impersonate the operator and register as the operator at the MASA or 5274 otherwise get hold of vouchers and can get enough physical access to 5275 the network so pledges would register to an attacking registrar, then 5276 the attacker could gain access to the ACP, and through the ACP gain 5277 access to the Data-Plane. 5279 In networks where the operator explicitly wants to enable the ANI 5280 this could not happen, because the operator would create a BRSKI 5281 registrar that would discover attack attempts, and the operator would 5282 be setting up his registrar with the MASA. Nodes requiring 5283 "ownership vouchers" would not be subject to that attack. See 5284 [I-D.ietf-anima-bootstrapping-keyinfra] for more details. Note that 5285 a global "ACP enable" alone is not subject to these type of attacks, 5286 because it always depends on some other mechanism first to provision 5287 domain certificates into the device. 5289 9.3.5.2. Greenfield nodes 5291 An ACP "greenfield" node is one that does not have any prior 5292 configuration and that can be bootstrapped into the ACP across the 5293 network. To support greenfield nodes, ACP as described in this 5294 document needs to be combined with a bootstrap protocol/mechanism 5295 that will enroll the node with the ACP keying material - ACP 5296 certificate and TA. For ANI nodes, this protocol/mechanism is BRSKI. 5298 When such a node is powered on and determines it is in greenfield 5299 condition, it enables the bootstrap protocol(s)/mechanism(s), and 5300 once the ACP keying material is enrolled, greenfield state ends and 5301 the ACP is started. When BRSKI is used, the node's state reflects 5302 this by setting "ANI enable" upon determination of greenfield state 5303 at power on. 5305 ACP greenfield nodes that in the absence of ACP would have their 5306 interfaces in "down" state SHOULD set all native interfaces into 5307 "admin down" state and only permit Data-Plane traffic required for 5308 the bootstrap protocol/mechanisms. 5310 ACP greenfield state ends either through successful enrolment of ACP 5311 keying material (certificate, TA) or detection of a permitted 5312 termination of ACP greenfield operations. 5314 ACP nodes supporting greenfield operations MAY want to provide 5315 backward compatibility with other forms of configuration/ 5316 provisioning, especially when only a subset of nodes are expected to 5317 be deployed with ACP. Such an ACP node SHOULD observe attempts to 5318 provision/configure the node via interfaces/methods that 5319 traditionally indicate physical possession of the node, such as a 5320 serial or USB console port or a USB memory stick with a bootstrap 5321 configuration. When such an operation is observed before enrollment 5322 of the ACP keying material has completed, the node SHOULD put itself 5323 into the state the node would have been in, if ACP/ANI was disabled 5324 at boot (terminate ACP greenfield operations). 5326 When an ACP greenfield node enables multiple automated ACP or non-ACP 5327 enrollment/bootstrap protocols/mechanisms in parallel, care must be 5328 taken not to terminate any protocol/mechanism before another one has 5329 succeeded to enroll ACP keying material or has progressed to a point 5330 where it is permitted to be a termination reason for ACP greenfield 5331 operations. 5333 Highly secure ACP greenfield nodes may not permit any reason to 5334 terminate ACP greenfield operations, including physical access. 5336 Nodes that claim to support ANI greenfield operations SHOULD NOT 5337 enable in parallel to BRSKI any enrollment/bootstrap protocol/ 5338 mechanism that allows Trust On First Use (TOFU, [RFC7435]) over 5339 interfaces other than those traditionally indicating physical 5340 possession of the node. Protocols/mechanisms with published default 5341 username/password authentication are considered to suffer from TOFU. 5342 Securing the bootstrap protocol/mechanism by requiring a voucher 5343 ([RFC8366]) can be used to avoid TOFU. 5345 In summary, the goal of ACP greenfield support is to allow remote 5346 automated enrollment of ACP keying materials, and therefore automated 5347 bootstrap into the ACP and to prohibit TOFU during bootstrap with the 5348 likely exception (for backward compatibility) of bootstrapping via 5349 interfaces traditionally indicating physical possession of the node. 5351 9.3.6. Undoing ANI/ACP enable 5353 Disabling ANI/ACP by undoing "ACP/ANI enable" is a risk for the 5354 reliable operations of the ACP if it can be executed by mistake or 5355 unauthorized. This behavior could be influenced through some 5356 additional (future) property in the certificate (e.g., in the acp- 5357 node-name extension field): In an ANI deployment intended for 5358 convenience, disabling it could be allowed without further 5359 constraints. In an ANI deployment considered to be critical more 5360 checks would be required. One very controlled option would be to not 5361 permit these commands unless the domain certificate has been revoked 5362 or is denied renewal. Configuring this option would be a parameter 5363 on the BRSKI registrar(s). As long as the node did not receive a 5364 domain certificate, undoing "ANI/ACP enable" should not have any 5365 additional constraints. 5367 9.3.7. Summary 5369 Node-wide "ACP/ANI enable [up-if-only]" commands enable the operation 5370 of ACP/ANI. This is only auto-enabled on ANI greenfield devices, 5371 otherwise it must be configured explicitly. 5373 If the option "up-if-only" is not selected, interfaces enabled for 5374 ACP/ANI interpret "down" state as "admin down" and not "physical 5375 down". In "admin-down" all non-ACP/ANI packets are filtered, but the 5376 physical layer is kept running to permit ACP/ANI to operate. 5378 (New) commands that result in physical interruption ("physical down", 5379 "loopback") of ACP/ANI enabled interfaces should be built to protect 5380 continuance or reestablishment of ACP as much as possible. 5382 Interface level "ACP/ANI enable" control per-interface operations. 5383 It is enabled by default on native interfaces and has to be 5384 configured explicitly on other interfaces. 5386 Disabling "ACP/ANI enable" global and per-interface should have 5387 additional checks to minimize undesired breakage of ACP. The degree 5388 of control could be a domain wide parameter in the domain 5389 certificates. 5391 9.4. Partial or Incremental adoption 5393 The ACP Zone Addressing Sub-Scheme (see Section 6.11.3) allows 5394 incremental adoption of the ACP in a network where ACP can be 5395 deployed on edge areas, but not across the core that is connecting 5396 those edges. 5398 In such a setup, each edge network, such as a branch or campus of an 5399 enterprise network has a disjoined ACP to which one or more unique 5400 Zone-IDs are assigned: ACP nodes registered for a specific ACP zone 5401 have to receive ACP Zone Addressing Sub-scheme addresses, for example 5402 by virtue of configuring for each such zone one or more ACP 5403 Registrars with that Zone-ID. All the Registrars for these ACP Zones 5404 need to get ACP certificates from CAs relying on a common set of TA 5405 and of course the same ACP domain name. 5407 These ACP zones can first be brought up as separate networks without 5408 any connection between them and/or they can be connected across a 5409 non-ACP enabled core network through various non-autonomic 5410 operational practices. For example, each separate ACP Zone can have 5411 an edge node that is a layer 3 VPN PE (MPLS or IPv6 layer 3 VPN), 5412 where a complete non-autonomic ACP-Core VPN is created by using the 5413 ACP VRFs and exchanging the routes from those ACP VRFs across the 5414 VPNs non-autonomic routing protocol(s). 5416 While such a setup is possible with any ACP addressing sub-scheme, 5417 the ACP-Zone Addressing sub-scheme makes it easy to configure and 5418 scalable for any VPN routing protocols because every ACP zone would 5419 only need to indicate one or more /64 ACP Zone Addressing prefix 5420 routes into the ACP-Core VPN as opposed to routes for every 5421 individual ACP node as required in the other ACP addressing schemes. 5423 Note that the non-autonomous ACP-Core VPN would require additional 5424 extensions to propagate GRASP messages when GRASP discovery is 5425 desired across the zones. 5427 For example, one could set up on each Zone edge router a remote ACP 5428 tunnel to a GRASP hub. The GRASP hub could be implemented at the 5429 application level and could run in the NOC of the network. It would 5430 serve to propagate GRASP announcements between ACP Zones and/or 5431 generate GRASP announcements for NOC services. 5433 Such a partial deployment may prove to be sufficient or could evolve 5434 to become more autonomous through future standardized or non- 5435 standardized enhancements, for example by allowing GRASP messages to 5436 be propagated across the layer 3 VPN, leveraging for example L3VPN 5437 Multicast support. 5439 Finally, these partial deployments can be merged into a single 5440 contiguous complete autonomous ACP (given appropriate ACP support 5441 across the core) without changes in the crypto material, because the 5442 node's ACP certificates are from a single ACP. 5444 9.5. Configuration and the ACP (summary) 5446 There is no desirable configuration for the ACP. Instead, all 5447 parameters that need to be configured in support of the ACP are 5448 limitations of the solution, but they are only needed in cases where 5449 not all components are made autonomic. Wherever this is necessary, 5450 it relies on pre-existing mechanisms for configuration such as CLI or 5451 YANG ([RFC7950]) data models. 5453 The most important examples of such configuration include: 5455 * When ACP nodes do not support an autonomic way to receive an ACP 5456 certificate, for example BRSKI, then such certificate needs to be 5457 configured via some pre-existing mechanisms outside the scope of 5458 this specification. Today, router have typically a variety of 5459 mechanisms to do this. 5460 * Certificate maintenance requires PKI functions. Discovery of 5461 these functions across the ACP is automated (see Section 6.2.5), 5462 but their configuration is not. 5464 * When non-ACP capable nodes such as pre-existing NMS need to be 5465 physically connected to the ACP, the ACP node to which they attach 5466 needs to be configured with ACP-connect according to Section 8.1. 5467 It is also possible to use that single physical connection to 5468 connect both to ACP and the Data-Plane of the network as explained 5469 in Section 8.1.4. 5470 * When devices are not autonomically bootstrapped, explicit 5471 configuration to enable the ACP needs to be applied. See 5472 Section 9.3. 5473 * When the ACP needs to be extended across interfaces other than L2, 5474 the ACP as defined in this document cannot autodiscover candidate 5475 neighbors automatically. Remote neighbors need to be configured, 5476 see Section 8.2. 5478 Once the ACP is operating, any further configuration for the Data- 5479 Plane can be configured more reliably across the ACP itself because 5480 the ACP provides addressing and connectivity (routing) independent of 5481 the Data-Plane itself. For this, the configuration methods simply 5482 need to also allow to operate across the ACP VRF - NETCONF, SSH or 5483 any other method. 5485 The ACP also provides additional security through its hop-by-hop 5486 encryption for any such configuration operations: Some legacy 5487 configuration methods (SNMP, TFTP, HTTP) may not use end-to-end 5488 encryption, and most of the end-to-end secured configuration methods 5489 still allow for easy passive observation along the path about 5490 configuration taking place (transport flows, port numbers, IP 5491 addresses). 5493 The ACP can and should equally be used as the transport to configure 5494 any of the aforementioned non-autonomic components of the ACP, but in 5495 that case, the same caution needs to be exercised as with Data-Plane 5496 configuration without ACP: Misconfiguration may cause the configuring 5497 entity to be disconnected from the node it configures - for example 5498 when incorrectly unconfiguring a remote ACP neighbor through which 5499 the configured ACP node is reached. 5501 10. Summary: Benefits (Informative) 5503 10.1. Self-Healing Properties 5505 The ACP is self-healing: 5507 * New neighbors will automatically join the ACP after successful 5508 validation and will become reachable using their unique ULA 5509 address across the ACP. 5511 * When any changes happen in the topology, the routing protocol used 5512 in the ACP will automatically adapt to the changes and will 5513 continue to provide reachability to all nodes. 5514 * The ACP tracks the validity of peer certificates and tears down 5515 ACP secure channels when a peer certificate has expired. When 5516 short-lived certificates with lifetimes in the order of OCSP/CRL 5517 refresh times are used, then this allows for removal of invalid 5518 peers (whose certificate was not renewed) at similar speeds as 5519 when using OCSP/CRL. The same benefit can be achieved when using 5520 CRL/OCSP, periodically refreshing the revocation information and 5521 also tearing down ACP secure channels when the peer's (long-lived) 5522 certificate is revoked. There is no requirement against ACP 5523 implementations to require this enhancement though to keep the 5524 mandatory implementations simpler. 5526 The ACP can also sustain network partitions and mergers. Practically 5527 all ACP operations are link local, where a network partition has no 5528 impact. Nodes authenticate each other using the domain certificates 5529 to establish the ACP locally. Addressing inside the ACP remains 5530 unchanged, and the routing protocol inside both parts of the ACP will 5531 lead to two working (although partitioned) ACPs. 5533 There are few central dependencies: A CRL may not be available during 5534 a network partition; a suitable policy to not immediately disconnect 5535 neighbors when no CRL is available can address this issue. Also, an 5536 ACP Registrar or Certification Authority might not be available 5537 during a partition. This may delay renewal of certificates that are 5538 to expire in the future, and it may prevent the enrollment of new 5539 nodes during the partition. 5541 Highly resilient ACP designs can be built by using ACP Registrars 5542 with embedded sub-CA, as outlined in Section 9.2.4. As long as a 5543 partition is left with one or more of such ACP Registrars, it can 5544 continue to enroll new candidate ACP nodes as long as the ACP 5545 Registrar's sub-CA certificate does not expire. Because the ACP 5546 addressing relies on unique Registrar-IDs, a later re-merge of 5547 partitions will also not cause problems with ACP addresses assigned 5548 during partitioning. 5550 After a network partition, a re-merge will just establish the 5551 previous status, certificates can be renewed, the CRL is available, 5552 and new nodes can be enrolled everywhere. Since all nodes use the 5553 same TA, a re-merge will be smooth. 5555 Merging two networks with different TA requires the ACP nodes to 5556 trust the union of TA. As long as the routing-subdomain hashes are 5557 different, the addressing will not overlap. Accidentally, overlaps 5558 will only happen in the unlikely event of a 40-bit hash collision in 5559 SHA256 (see Section 6.11). Note that the complete mechanisms to 5560 merge networks is out of scope of this specification. 5562 It is also highly desirable for implementation of the ACP to be able 5563 to run it over interfaces that are administratively down. If this is 5564 not feasible, then it might instead be possible to request explicit 5565 operator override upon administrative actions that would 5566 administratively bring down an interface across which the ACP is 5567 running. Especially if bringing down the ACP is known to disconnect 5568 the operator from the node. For example, any such down 5569 administrative action could perform a dependency check to see if the 5570 transport connection across which this action is performed is 5571 affected by the down action (with default RPL routing used, packet 5572 forwarding will be symmetric, so this is actually possible to check). 5574 10.2. Self-Protection Properties 5576 10.2.1. From the outside 5578 As explained in Section 6, the ACP is based on secure channels built 5579 between nodes that have mutually authenticated each other with their 5580 domain certificates. The channels themselves are protected using 5581 standard encryption technologies such as DTLS or IPsec which provide 5582 additional authentication during channel establishment, data 5583 integrity and data confidentiality protection of data inside the ACP 5584 and in addition, provide replay protection. 5586 Attacker will not be able to join the ACP unless they have a valid 5587 ACP certificate. On-path attackers without a valid ACP certificate 5588 cannot inject packets into the ACP due to ACP secure channels. They 5589 can also not decrypt ACP traffic except if they can crack the 5590 encryption. They can attempt behavioral traffic analysis on the 5591 encrypted ACP traffic. 5593 The degree to which compromised ACP nodes can impact the ACP depends 5594 on the implementation of the ACP nodes and their impairment. When an 5595 attacker has only gained administrative privileges to configure ACP 5596 nodes remotely, the attacker can disrupt the ACP only through one of 5597 the few configuration options to disable it, see Section 9.3, or by 5598 configuring of non-autonomic ACP options if those are supported on 5599 the impaired ACP nodes, see Section 8. Injecting or extracting 5600 traffic into/from an impaired ACP node is only possible when an 5601 impaired ACP node supports ACP connect (see Section 8.1) and the 5602 attacker can control traffic into/from one of the ACP nodes 5603 interfaces, such as by having physical access to the ACP node. 5605 The ACP also serves as protection (through authentication and 5606 encryption) for protocols relevant to OAM that may not have secured 5607 protocol stack options or where implementation or deployment of those 5608 options fail on some vendor/product/customer limitations. This 5609 includes protocols such as SNMP ([RFC3411]), NTP ([RFC5905]), PTP 5610 ([IEEE-1588-2008]), DNS ([RFC3596]), DHCPv6 ([RFC3315]), syslog 5611 ([RFC3164]), RADIUS ([RFC2865]), Diameter ([RFC6733]), TACACS 5612 ([RFC1492]), IPFIX ([RFC7011]), Netflow ([RFC3954]) - just to name a 5613 few. Not all of these protocol references are necessarily the latest 5614 version of protocols but versions that are still widely deployed. 5616 Protection via the ACP secure hop-by-hop channels for these protocols 5617 is meant to be only a stopgap though: The ultimate goal is for these 5618 and other protocols to use end-to-end encryption utilizing the domain 5619 certificate and rely on the ACP secure channels primarily for zero- 5620 touch reliable connectivity, but not primarily for security. 5622 The remaining attack vector would be to attack the underlying ACP 5623 protocols themselves, either via directed attacks or by denial-of- 5624 service attacks. However, as the ACP is built using link-local IPv6 5625 addresses, remote attacks from the Data-Plane are impossible as long 5626 as the Data-Plane has no facilities to remotely send IPv6 link-local 5627 packets. The only exceptions are ACP connected interfaces which 5628 require higher physical protection. The ULA addresses are only 5629 reachable inside the ACP context, therefore, unreachable from the 5630 Data-Plane. Also, the ACP protocols should be implemented to be 5631 attack resistant and not consume unnecessary resources even while 5632 under attack. 5634 10.2.2. From the inside 5636 The security model of the ACP is based on trusting all members of the 5637 group of nodes that receive an ACP certificate for the same domain. 5638 Attacks from the inside by a compromised group member are therefore 5639 the biggest challenge. 5641 Group members must be protected against attackers so that there is no 5642 easy way to compromise them, or use them as a proxy for attacking 5643 other devices across the ACP. For example, management plane 5644 functions (transport ports) should only be reachable from the ACP but 5645 not the Data-Plane. Especially for those management plane functions 5646 that have no good protection by themselves because they do not have 5647 secure end-to-end transport and to whom ACP not only provides 5648 automatic reliable connectivity but also protection against attacks. 5649 Protection across all potential attack vectors is typically easier to 5650 do in devices whose software is designed from the ground up with ACP 5651 in mind than with legacy software based systems where the ACP is 5652 added on as another feature. 5654 As explained above, traffic across the ACP should still be end-to-end 5655 encrypted whenever possible. This includes traffic such as GRASP, 5656 EST and BRSKI inside the ACP. This minimizes man in the middle 5657 attacks by compromised ACP group members. Such attackers cannot 5658 eavesdrop or modify communications, they can just filter them (which 5659 is unavoidable by any means). 5661 See Appendix A.9.8 for further considerations how to avoid and deal 5662 with compromised nodes. 5664 10.3. The Administrator View 5666 An ACP is self-forming, self-managing and self-protecting, therefore 5667 has minimal dependencies on the administrator of the network. 5668 Specifically, since it is (intended to be) independent of 5669 configuration, there is only limited scope for configuration errors 5670 on the ACP itself. The administrator may have the option to enable 5671 or disable the entire approach, but detailed configuration is not 5672 possible. This means that the ACP must not be reflected in the 5673 running configuration of nodes, except a possible on/off switch (and 5674 even that is undesirable). 5676 While configuration (except for Section 8 and Section 9.2) is not 5677 possible, an administrator must have full visibility of the ACP and 5678 all its parameters, to be able to do trouble-shooting. Therefore, an 5679 ACP must support all show and debug options, as for any other network 5680 function. Specifically, a network management system or controller 5681 must be able to discover the ACP, and monitor its health. This 5682 visibility of ACP operations must clearly be separated from 5683 visibility of Data-Plane so automated systems will never have to deal 5684 with ACP aspects unless they explicitly desire to do so. 5686 Since an ACP is self-protecting, a node not supporting the ACP, or 5687 without a valid domain certificate cannot connect to it. This means 5688 that by default a traditional controller or network management system 5689 cannot connect to an ACP. See Section 8.1.1 for more details on how 5690 to connect an NMS host into the ACP. 5692 11. Security Considerations 5694 A set of ACP nodes with ACP certificates for the same ACP domain and 5695 with ACP functionality enabled is automatically "self-building": The 5696 ACP is automatically established between neighboring ACP nodes. It 5697 is also "self-protecting": The ACP secure channels are authenticated 5698 and encrypted. No configuration is required for this. 5700 The self-protecting property does not include workarounds for non- 5701 autonomic components as explained in Section 8. See Section 10.2 for 5702 details of how the ACP protects itself against attacks from the 5703 outside and to a more limited degree from the inside as well. 5705 However, the security of the ACP depends on a number of other 5706 factors: 5708 * The usage of domain certificates depends on a valid supporting PKI 5709 infrastructure. If the chain of trust of this PKI infrastructure 5710 is compromised, the security of the ACP is also compromised. This 5711 is typically under the control of the network administrator. 5712 * ACP nodes receive their certificates from ACP registrars. These 5713 ACP registrars are security critical dependencies of the ACP: 5714 Procedures and protocols for ACP registrars are outside the scope 5715 of this specification as explained in Section 6.11.7.1, only 5716 requirements against the resulting ACP certificates are specified. 5717 * Every ACP registrar (for enrollment of ACP certificates) and ACP 5718 EST server (for renewal of ACP certificates) is a security 5719 critical entity and its protocols are security critical protocols. 5720 Both need to be hardened against attacks, similar to a CA and its 5721 protocols. A malicious registrar can enroll malicious nodes to an 5722 ACP network (if the CA delegates this policy to the registrar) or 5723 break ACP routing for example by assigning duplicate ACP address 5724 assignment to ACP nodes via their ACP certificates. 5725 * ACP nodes that are ANI nodes rely on BRSKI as the protocol for ACP 5726 registrars. For ANI type ACP nodes, the security considerations 5727 of BRSKI apply. It enables automated, secure enrollment of ACP 5728 certificates. 5729 * BRSKI and potentially other ACP registrar protocol options require 5730 that nodes have an (X.509v3 based) IDevID. IDevIDs are an option 5731 for ACP registrars to securely identify candidate ACP nodes that 5732 should be enrolled into an ACP domain. 5734 * For IDevIDs to securely identify the node to which it IDevID is 5735 assigned, the node needs to (1) utilize hardware support such as a 5736 Trusted Platform Module (TPM) to protect against extraction/ 5737 cloning of the private key of the IDevID and (2) a hardware/ 5738 software infrastructure to prohibit execution of non-authenticated 5739 software to protect against malicious use of the IDevID. 5740 * Like the IDevID, the ACP certificate should equally be protected 5741 from extraction or other abuse by the same ACP node 5742 infrastructure. This infrastructure for IDevID and ACP 5743 certificate is beneficial independent of the ACP registrar 5744 protocol used (BRSKI or other). 5745 * Renewal of ACP certificates requires support for EST, therefore 5746 the security considerations of [RFC7030] related to certificate 5747 renewal/rekeying and TP renewal apply to the ACP. EST security 5748 considerations when using other than mutual certificate 5749 authentication do not apply nor do considerations for initial 5750 enrollment via EST apply, except for ANI type ACP nodes because 5751 BRSKI leverages EST. 5752 * A malicious ACP node could declare itself to be an EST server via 5753 GRASP across the ACP if malicious software could be executed on 5754 it. CA should therefore authenticate only known trustworthy EST 5755 servers, such as nodes with hardware protections against malicious 5756 software. When Registrars use their ACP certificate to 5757 authenticate towards a CA, the id-kp-cmcRA [RFC6402] extended key 5758 usage attribute allows the CA to determine that the ACP node was 5759 permitted during enrollment to act as an ACP registrar. Without 5760 the ability to talk to the CA, a malicious EST server can still 5761 attract ACP nodes attempting to renew their keying material, but 5762 they will fail to perform successful renewal of a valid ACP 5763 certificate. The ACP node attempting to use the malicious EST 5764 server can then continue to use a different EST server, and log a 5765 failure against a malicious EST server. 5766 * Malicious on-path ACP nodes may filter valid EST server 5767 announcements across the ACP, but such malicious ACP nodes could 5768 equally filter any ACP traffic such as the EST traffic itself. 5769 Either attack requires the ability to execute malicious software 5770 on an impaired ACP node though. 5771 * In the absence of malicious software injection, an attacker that 5772 can misconfigure an ACP node which is supporting EST server 5773 functionality could attempt to configure a malicious CA. This 5774 would not result in the ability to successfully renew ACP 5775 certificates, but it could result in DoS attacks by becoming an 5776 EST server and making ACP nodes attempting their ACP certificate 5777 renewal via this impaired ACP node. This problem can be avoided 5778 when the EST server implementation can verify that the CA 5779 configured is indeed providing renewal for certificates of the 5780 node's ACP. The ability to do so depends on the EST-Server to CA 5781 protocol, which is outside the scope of this document. 5783 In summary, attacks against the PKI/certificate dependencies of the 5784 ACP can be minimized by a variety of hardware/software components 5785 including options such as TPM for IDevID/ACP-certificate, 5786 prohibitions against execution of non-trusted software and design 5787 aspects of the EST Server functionality for the ACP to eliminate 5788 configuration level impairment. 5790 Because ACP peers select one out of potentially more than one 5791 mutually supported ACP secure channel protocols via the approach 5792 described in Section 6.6, ACP secure channel setup is subject to 5793 downgrade attacks by MITM attackers. This can be discovered after 5794 such an attack by additional mechanisms described in Appendix A.9.9. 5795 Alternatively, more advanced channel selection mechanisms can be 5796 devised. [RFC-Editor: Please remove the following sentence]. See 5797 [ACPDRAFT] Appendix B.1. Both options are out of scope of this 5798 document. 5800 The security model of the ACP as defined in this document is tailored 5801 for use with private PKI. The TA of a private PKI provide the 5802 security against maliciously created ACP certificates to give access 5803 to an ACP. Such attacks can create fake ACP certificates with 5804 correct looking AcpNodeNames, but those certificates would not pass 5805 the certificate path validation of the ACP domain membership check 5806 (see Section 6.2.3, point 2). 5808 [RFC-Editor: please remove the following paragraph]. 5810 Using public CA is out of scope of this document. See [ACPDRAFT], 5811 Appendix B.3 for further considerations. 5813 There is no prevention of source-address spoofing inside the ACP. 5814 This implies that if an attacker gains access to the ACP, it can 5815 spoof all addresses inside the ACP and fake messages from any other 5816 node. New protocol/services run across the ACP should therefore use 5817 end-to-end authentication inside the ACP. This is already done by 5818 GRASP as specified in this document. 5820 The ACP is designed to enable automation of current network 5821 management and future autonomic peer-to-peer/distributed network 5822 automation. Any ACP member can send ACP IPv6 packet to other ACP 5823 members and announce via ACP GRASP services to all ACP members 5824 without dependency against centralized components. 5826 The ACP relies on peer-to-peer authentication and authorization using 5827 ACP certificates. This security model is necessary to enable the 5828 autonomic ad-hoc any-to-any connectivity between ACP nodes. It 5829 provides infrastructure protection through hop by hop authentication 5830 and encryption - without relying on third parties. For any services 5831 where this complete autonomic peer-to-peer group security model is 5832 appropriate, the ACP certificate can also be used unchanged. For 5833 example, for any type of Data-Plane routing protocol security. 5835 This ACP security model is designed primarily to protect against 5836 attack from the outside, but not against attacks from the inside. To 5837 protect against spoofing attacks from compromised on-path ACP nodes, 5838 end-to-end encryption inside the ACP is used by new ACP signaling: 5839 GRASP across the ACP using TLS. The same is expected from any non- 5840 legacy services/protocols using the ACP. Because no group-keys are 5841 used, there is no risk for impacted nodes to access end-to-end 5842 encrypted traffic from other ACP nodes. 5844 Attacks from impacted ACP nodes against the ACP are more difficult 5845 than against the Data-Plane because of the autoconfiguration of the 5846 ACP and the absence of configuration options that could be abused 5847 that allow to change/break ACP behavior. This is excluding 5848 configuration for workaround in support of non-autonomic components. 5850 Mitigation against compromised ACP members is possible through 5851 standard automated certificate management mechanisms including 5852 revocation and non-renewal of short-lived certificates. In this 5853 version of the specification, there are no further optimization of 5854 these mechanisms defined for the ACP (but see Appendix A.9.8). 5856 Higher layer service built using ACP certificates should not solely 5857 rely on undifferentiated group security when another model is more 5858 appropriate/more secure. For example, central network configuration 5859 relies on a security model where only few especially trusted nodes 5860 are allowed to configure the Data-Plane of network nodes (CLI, 5861 NETCONF). This can be done through ACP certificates by 5862 differentiating them and introduce roles. See Appendix A.9.5. 5864 Operators and provisioning software developers need to be aware of 5865 how the provisioning/configuration of network devices impacts the 5866 ability of the operator / provisioning software to remotely access 5867 the network nodes. By using the ACP, most of the issues of 5868 configuration/provisioning caused loss of connectivity for remote 5869 provisioning/configuration will be eliminated, see Section 6. Only 5870 few exceptions such as explicit physical interface down configuration 5871 will be left Section 9.3.2. 5873 Many details of ACP are designed with security in mind and discussed 5874 elsewhere in the document: 5876 IPv6 addresses used by nodes in the ACP are covered as part of the 5877 node's domain certificate as described in Section 6.2.2. This allows 5878 even verification of ownership of a peer's IPv6 address when using a 5879 connection authenticated with the domain certificate. 5881 The ACP acts as a security (and transport) substrate for GRASP inside 5882 the ACP such that GRASP is not only protected by attacks from the 5883 outside, but also by attacks from compromised inside attackers - by 5884 relying not only on hop-by-hop security of ACP secure channels, but 5885 adding end-to-end security for those GRASP messages. See 5886 Section 6.9.2. 5888 ACP provides for secure, resilient zero-touch discovery of EST 5889 servers for certificate renewal. See Section 6.2.5. 5891 ACP provides extensible, auto-configuring hop-by-hop protection of 5892 the ACP infrastructure via the negotiation of hop-by-hop secure 5893 channel protocols. See Section 6.6. 5895 The ACP is designed to minimize attacks from the outside by 5896 minimizing its dependency against any non-ACP (Data-Plane) 5897 operations/configuration on a node. See also Section 6.13.2. 5899 In combination with BRSKI, ACP enables a resilient, fully zero-touch 5900 network solution for short-lived certificates that can be renewed or 5901 re-enrolled even after unintentional expiry (e.g., because of 5902 interrupted connectivity). See Appendix A.2. 5904 Because ACP secure channels can be long lived, but certificates used 5905 may be short lived, secure channels, for example built via IPsec need 5906 to be terminated when peer certificates expire. See Section 6.8.5. 5908 Section 7.2 describes how to implement a routed ACP topology 5909 operating on what effectively is a large bridge-domain when using L3/ 5910 L2 routers that operate at L2 in the Data-Plane. In this case, the 5911 ACP is subject to much higher likelihood of attacks by other nodes 5912 "stealing" L2 addresses than in the actual routed case. Especially 5913 when the bridged network includes non-trusted devices such as hosts. 5914 This is a generic issue in L2 LANs. L2/L3 devices often already have 5915 some form of "port security" to prohibit this. They rely on NDP or 5916 DHCP learning of which port/MAC-address and IPv6 address belong 5917 together and block MAC/IPv6 source addresses from wrong ports. This 5918 type of function needs to be enabled to prohibit DoS attacks and 5919 specifically to protect the ACP. Likewise the GRASP DULL instance 5920 needs to ensure that the IPv6 address in the locator-option matches 5921 the source IPv6 address of the DULL GRASP packet. 5923 12. IANA Considerations 5925 This document defines the "Autonomic Control Plane". 5927 For the ANIMA-ACP-2020 ASN.1 module, IANA is asked to register value 5928 IANA1 for "id-mod-anima-acpnodename-2020" in the "SMI Security for 5929 PKIX Module Identifier" (1.3.6.1.5.5.7.0) registry. 5931 For the otherName / AcpNodeName, IANA is asked to register a value 5932 for IANA2 for id-on-AcpNodeName in the "SMI Security for PKIX Other 5933 Name Forms" (1.3.6.1.5.5.7.8) registry. 5935 The IANA is requested to register the value "AN_ACP" (without quotes) 5936 to the GRASP Objectives Names Table in the GRASP Parameter Registry. 5937 The specification for this value is this document, Section 6.4. 5939 The IANA is requested to register the value "SRV.est" (without 5940 quotes) to the GRASP Objectives Names Table in the GRASP Parameter 5941 Registry. The specification for this value is this document, 5942 Section 6.2.5. 5944 Explanation: This document chooses the initially strange looking 5945 format "SRV." because these objective names would be in 5946 line with potential future simplification of the GRASP objective 5947 registry. Today, every name in the GRASP objective registry needs to 5948 be explicitly allocated with IANA. In the future, this type of 5949 objective names could be considered to be automatically registered in 5950 that registry for the same service for which a is 5951 registered according to [RFC6335]. This explanation is solely 5952 informational and has no impact on the requested registration. 5954 The IANA is requested to create an ACP Parameter Registry with 5955 currently one registry table - the "ACP Address Type" table. 5957 "ACP Address Type" Table. The value in this table are numeric values 5958 0...3 paired with a name (string). Future values MUST be assigned 5959 using the Standards Action policy defined by [RFC8126]. The 5960 following initial values are assigned by this document: 5962 0: ACP Zone Addressing Sub-Scheme (ACP RFC Section 6.11.3) 5964 1: ACP Vlong Addressing Sub-Scheme (ACP RFC Section 6.11.5) / ACP 5965 Manual Addressing Sub-Scheme (ACP RFC Section 6.11.4) 5967 13. Acknowledgements 5969 This work originated from an Autonomic Networking project at Cisco 5970 Systems, which started in early 2010. Many people contributed to 5971 this project and the idea of the Autonomic Control Plane, amongst 5972 which (in alphabetical order): Ignas Bagdonas, Parag Bhide, Balaji 5973 BL, Alex Clemm, Yves Hertoghs, Bruno Klauser, Max Pritikin, Michael 5974 Richardson, Ravi Kumar Vadapalli. 5976 Special thanks to Brian Carpenter, Elwyn Davies, Joel Halpern and 5977 Sheng Jiang for their thorough reviews. 5979 Many thanks Ben Kaduk, Roman Danyliv and Eric Rescorla for their 5980 thorough SEC AD reviews, Russ Housley and Erik Kline for their 5981 reviews and to Valery Smyslov, Tero Kivinen, Paul Wouters and Yoav 5982 Nir for review of IPsec and IKEv2 parameters and helping to 5983 understand those and other security protocol details better. Thanks 5984 for Carsten Borman for CBOR/CDDL help. 5986 Further input, review or suggestions were received from: Rene Struik, 5987 Benoit Claise, William Atwood and Yongkang Zhang. 5989 14. Contributors 5991 For all things GRASP including validation code, ongoing document text 5992 support and technical input. 5994 Brian Carpenter 5995 School of Computer Science 5996 University of Auckland 5997 PB 92019 5998 Auckland 1142 5999 New Zealand 6001 Email: brian.e.carpenter@gmail.com 6003 For RPL contributions and all things BRSKI/bootstrap including 6004 validation code, ongoing document text support and technical input. 6006 Michael C. Richardson 6007 Sandelman Software Works 6009 Email: mcr+ietf@sandelman.ca 6010 URI: http://www.sandelman.ca/mcr/ 6012 For the RPL technology choices and text. 6014 Pascal Thubert 6015 Cisco Systems, Inc 6016 Building D 6017 45 Allee des Ormes - BP1200 6018 06254 MOUGINS - Sophia Antipolis 6019 France 6021 Phone: +33 497 23 26 34 6022 Email: pthubert@cisco.com 6024 15. Change log [RFC-Editor: Please remove] 6026 This document was developed on https://github.com/anima-wg/autonomic- 6027 control-plane/tree/master/draft-ietf-anima-autonomic-control-plane. 6028 That github repository also contains the document review/reply 6029 emails. 6031 15.1. Summary of changes since entering IESG review 6033 This text replaces the prior changelog with a summary to provide 6034 guidance for further IESG review. 6036 Please see revision -21 for the individual changelogs of prior 6037 versions . 6039 15.1.1. Reviews (while in IESG review status) / status 6041 This document entered IESG review with version -13. It has since 6042 seen the following reviews: 6044 IESG: Original owner/Yes: Terry Manderson (INT). 6046 IESG: No Objection: Deborah Brungard (RTG), Alissa Cooper (GEN), 6047 Warren Kumari (OPS), Mirja Kuehlewind (TSV), Alexey Melnikov (ART), 6048 Adam Roach (ART). 6050 IESG: No Objection, not counted anymore as they have left IESG: Ben 6051 Campbell (ART), Spencer Dawkins (TSV). 6053 IESG: Open DISCUSS hopefully resolved by this version: Eric Rescorla 6054 (SEC, left IESG), Benjamin Kaduk (SEC). 6056 Other: Michael Richardson (WG), Brian Carpenter (WG), Pascal Thubert 6057 (WG), Frank Xialiang (WG), Elwyn Davies (GEN), Joel Halpern (RTGdir), 6058 Yongkang Zhang (WG), William Atwood (WG). 6060 15.1.2. BRSKI / ACP registrar related enhancements 6062 Only after ACP entered IESG review did it become clear that the in- 6063 progress BRSKI document would not provide all the explanations needed 6064 for ACP registrars as expected earlier by ACP authors. Instead, 6065 BRSKI will only specify a subset of required ACP behavior related to 6066 certificate handling and registrar. There, it became clear that the 6067 ACP draft should specify generic ACP registrar behavior independent 6068 of BRSKI so ACP could be implemented with or without BRSKI and any 6069 manual/proprietary or future standardized BRSKI alternatives (for 6070 example via NETCONF) would understand the requirements for ACP 6071 registrars and its certificate handling. 6073 This lead to additional text about ACP registrars in the ACP 6074 document: 6076 1. Defined relationship ACP / ANI (ANI = ACP + BRSKI). 6078 6.1.4 (new) Overview of TA required for ACP. 6080 6.1.5.5 Added explanations/requirements for Re-enrollment. 6082 6.10.7 Normative requirements for ACP registrars (BRSKI or not). 6084 10.2 Operational expectations against ACP registrars (BRSKI or not). 6086 15.1.3. Normative enhancements since start of IESG review 6088 In addition to above ACP registrar / BRSKI related enhancements there 6089 is a range of minor normative (also explanatory) enhancements since 6090 the start of IESG review: 6092 6.1.1 Hex digits in ACP domain information field now upper-case (no 6093 specific reason except that both options are equally good, but 6094 capitalized ones are used in rfc5234). 6096 6.1.5.3 Added explanations about CRLs. 6098 6.1.5.6 Added explanations of behavior under failing certificates. 6100 6.1.2 Allow ACP address '0' in ACP domain information field: presence 6101 of address indicates permission to build ACP secure channel to node, 6102 0 indicates that the address of the node is assigned by (future) 6103 other means than certificate. Non-autonomic nodes have no address at 6104 all (that was in -13), and can only connect via ACP connect 6105 interfaces to ACP. 6107 6.1.3 Distinction of real ACP nodes (with address) and those with 6108 domain certificate without address added as a new rule to ACP domain 6109 membership check. 6111 6.6 Added throttling of secure-channel setup attempts. 6113 6.11.1.14 Removed requirement to handle unknown destination ACP 6114 traffic in low-end nodes that would never be RPL roots. 6116 6.12.5 Added recommendation to use IPv6 DAD. 6118 6.1.1, 6.7.1.1, 6.7.2, 6.7.3, 6.8.2 Various refined additional 6119 certificate, secure channel protocol (IPsec/IKEv2 and DTLS) and ACP 6120 GRASP TLS protocol parameter requirements to ensure interoperating 6121 implementations (from SEC-AD review). 6123 15.1.4. Explanatory enhancements since start of IESG review 6125 Beyond the functional enhancements from the previous two sections, 6126 the mayority of changes since -13 are additional explanations from 6127 review feedback, textual nits and restructuring - with no functional 6128 requirement additions/changes. 6130 1.1 Added "applicability and scope" section with summarized 6131 explanations. 6133 2.Added in-band vs. out-of-band management definitions. 6135 6.1.2 (was 6.1.1) expanded explanations of reasoning for elements of 6136 the ACP domain information field. 6138 6.1.3 refined explanations of ACP domain membership check and 6139 justifications for it. 6141 6.5 Elaborated step-by-step secure channel setup. 6143 6.10 Additional explanations for addressing modes, additional table 6144 of addressing formats (thanks MichaelR). 6146 6.10.5 introduced 'F' bit position as a better visual representation 6147 in the Vlong address space. 6149 6.11.1.1 extensive overhaul to improve readability of use of RPL 6150 (from IESG feedback of non-routing/RPL experts). 6152 6.12.2 Added caution about unconfiguring Data-Plane IPv6 addresses 6153 and impact to ACP (limitation of current ACP design, and pointint to 6154 more details in 10.2). 6156 10.4 New explanations / summary of configurations for ACP (aka: all 6157 config is undesirable and only required for integrating with non- 6158 autonomic components, primarily ACP-connect and Registrars). 6160 11. Textually enhanced / better structured security considerations 6161 section after IESG security review. 6163 A. (new) Moved all explanations and discussions about futures from 6164 section 10 into this new appendix. This text should not be removed 6165 because it captures a lot of repeated asked questions in WG and 6166 during reviews and from users, and also captures ideas for some 6167 likely important followup work. But none of this is relevant to 6168 implementing (section 6) and operating (section 10) the ACP. 6170 15.2. draft-ietf-anima-autonomic-control-plane-30 6172 -29 did pass all IESG DISCUSS. This version cleans up reamining 6173 comments. 6175 Planned to be removed section Appendix A.6 was moved into new 6176 Appendix B.1 to be amended by further A.2, A.3 containing text felt 6177 to be unfit for publication in RFC (see below). Added reference to 6178 this last draft, and referencing those sections ([ACPDRAFT]). 6180 Final discussion with responsible AD (Eric Vyncke): marked all 6181 references to [ACPDRAFT] as to be removed from RFC, as this would be 6182 too unconventional. Likewise also [ACPDRAFT] reference itself. 6183 Added explanation to appendix B. 6185 Comments from Erik Kline: 6187 2. Fine tuned ULA definition. 6189 Comments Michael Richardson / Eric Vyncke. 6191 6.2.4. / 11. Removed text arguing ability how to use public CA (or 6192 not). Replaced with reference to new [ACPDRAFT] section B.3 (not in 6193 RFC) that explains current state of understanding (unfinished). 6195 B.3 New text detailling authors understanding of use of public CA 6196 (will not be in RFC). 6198 Comments/proposals from Ben Kaduk: 6200 Various: Replaced RFC4492 with RFC8422 which is superceeding it. 6202 6.1 Text fix for hash strength 384 bits (from SHA384); Text fix for 6203 ec_point_format extension. 6205 6.2.1 Text fixup. Removed requirements for ECDH support in 6206 certificate, instead merely explaining the dependencies required IF 6207 this is desired (educational). 6209 6.2.5.4. Fine tuning 2 sentences. 6211 6.3.2. (ACP domain memebership check) Add reference to ACPDRAFT B.2 6212 explaining why ACP domain membership does not validate ACP address of 6213 the connection. 6215 6.4. Downgraded SHOULD to MAY in new -29 suggestion how to deal with 6216 DoS attacks with many GRASP announcements. Will also separately ask 6217 TSV ADs. 6219 6.4. Fixed extension points in CDDL objective-value definitions 6220 (with help from Carsten/Brian). 6222 9.3.5.2. Added explanation when ACP greenfield state ends, and 6223 refined text explaining how to deal with this. 6225 11. removed duplicate paragraph (first, kept paragraph was the fixed 6226 up, improved correct version). 6228 11. Added references to ACPDRAFT B.1, B.2 as possible future 6229 solutions for downgrade attacks. 6231 12. Fixed up text for IANA code point allocation request. 6233 A.6 - removed. 6235 A.9.9 - added one explanatory intro paragraph to makes it easier to 6236 distinguish this option from the B.1 considerations. 6238 B.1 - new text suggested from Ben, replacing A.6 (will not be in 6239 RFC). 6241 B.2 - new text discussing why there is no network layer address 6242 verification in ACP domain membership check (will not be in RFC). 6244 B.4 - Text discussing DULL GRASP attacks via port sweeps and what do 6245 do against it. 6247 Other. 6249 1. Added sentence about FCC outage report from June as example for 6250 in-band management. 6252 15. added reference to github where document was developed (removed 6253 in RFC, part of changelog). 6255 15.3. draft-ietf-anima-autonomic-control-plane-29 6257 Comments from Robert Wilton: 6259 Improved several textual nits. 6261 Discuss/Comments from Erik Kline: 6263 Editorial suggestions and nits. Thanks!. 6265 6.1.3 Added text about how/why rsub is irrelevant for domain 6266 membership check. 6268 6.3 Added extension points to AN_ACP DULL GRASP objective because for 6269 example ACP domain certificate could be a nice optional additional 6270 parameter and prior syntax would have forced us to encode into 6271 separate objective unnecessarily. 6273 6.7 Using RFC8415 terminology for exponential backoff parameters. 6275 6.11.2 Amended ACP Sub-Addressing table with future code points, 6276 explanations and prefix announced into RPL. 6278 6.12.1.11. Reworked text to better explain how black hole route 6279 works and added expanation for prefix for manual address scheme. 6281 8.1.3. Reworked explanation of RIOs for ACP connect interfaces for 6282 Type C vs. Type A/B hosts. 6284 8.1.4. Added explanation how this "VRF select" option is required 6285 for auto-attachment of Type A/B hosts to ACP and other networks. 6287 Discuss/Comments from Barry Leiba: 6289 Various editorial nits - thanks. 6291 6.1 New section pulling in TLS requirements, no need anymore to 6292 duplicat for ACP GRASP, EST, BRSKI (ACP/ANI nodes) and (if desired) 6293 OCSP/CRLDP. Added rule to start use secure channel only after 6294 negotiation has finished. Added rules not to optimize negotiation 6295 across multiple L2 interfaces to the same peer. 6297 6.6 Changed role names in secure channel negotiation process: Alice/ 6298 Bob -> Decider/Follower. Explanation enhancements. Added definition 6299 for ACP nodes with "0" address. 6301 6.8.3 Improved explanation how IKEv2 forces preference of IPsec over 6302 GRE due to ACP IPsec profiles being Tunneled vs. Transport. 6304 6.8.4 Limited mentioning of DTLS version requirements to this 6305 section. 6307 6.9.2 Removed TLS requirements, they are now in 6.1. 6309 6.10.6 Removed explanation of IANA allocation requirement. Redundant 6310 - already in IANA section, and was seen as confusing. 6312 8.1.1 Clarified that there can be security impacts when weakening 6313 directly connected address RPF filtering for ACP connect interfaces. 6315 Discuss/Comments from Ben Kaduk: 6317 Many good editorial improvements - thanks!. 6319 5. added explanation of what to do upon failed secure channel 6320 establishment. 6322 6.1.1. refined/extended cert public cey crypto algo and better 6323 distinguished algo for the keys of the cert and the key of the 6324 signer. 6326 6.1.1. and following: explicitly defining "serialNumber" to be the 6327 X.520 subject name serialNumber, not the certificate serial Number. 6329 6.1.1. emhasize additional authorization step for EST servers (id-kp- 6330 cmcRA). 6332 6.1.2 changed AcpNodeName ABNF to again use 32HEXDIG instead of self- 6333 defined variation, because authors overlooked that ABNF is case 6334 agnostic (which is fine). Added recommendation to encode as lower 6335 case. Added full ABNF encoding for extensions (any characters as in 6336 "atoms" except the new "+" separator). 6338 6.1.5.3. New text to explain reason for use of HTTPS (instead of 6339 HTTP) for CRLDP and when and how to use HTTPS then. 6341 6.1.5.5. added text explaning why/how and when to maintain TA data 6342 upon failing cert renewal (one version with BRSKI, one version with 6343 other, ess secure bootstrap protocols). 6345 6.3. new text and requirement about the signaling of transport ports 6346 in DULL GRASP - benefits (no well-known ports required), and problems 6347 (additional DoS attack vector, albeit not worse than pre-existing 6348 ones, depending on setup of L2 subnets.). 6350 6.7.3.1.1. Specified AUTH_HMAC_SHA2_256_128 (as the ESP 6351 authentication algorithm). 6353 6.8.2. Added recommendations for TLS_AES_256_GCM_SHA384, 6354 TLS_CHACHA20_POLY1305_SHA256 when supporting TLS 1.3. 6356 8.2.2. Added explanation about downgrade attack across configured 6357 ACP tunnels and what to do against it. 6359 9.3.5.2. Rewrote most of section as it originally was too centric on 6360 BRSKI. Should now well describe expectations against automated 6361 bootstrap. Introduces new requirement not to call node as in support 6362 of ANI if is ALSO has TOFU bootstrap. 6364 11. Expanded text about malicious EST servers. Added paragraph 6365 about ACP secure channel downgrade attacks. Added paragraphs about 6366 private PKI as a core to allow security against fake certificates, 6367 added paragraph about considerationsproblems when using public PI. 6369 A.10.9 New appendix suggesting how to discover ACP secure channel 6370 negotiation downgrade attacks. 6372 Discuss from Roman Danyliw: 6374 6.1.5.1 - Added requirement to only announce SRV.est when a working 6375 CA connection. 6377 15 - Amended security considerations with text about registrar 6378 dependencies, security of IDevID/ACP-certificate, EST-Server and 6379 GRASP for EST server discovery. 6381 Other: 6383 Conversion to XML v3. Solved empty () taxonomy xref problems. 6384 Various formatting fixes for v3. 6386 Added contributors section. 6388 15.4. draft-ietf-anima-autonomic-control-plane-28 6390 IESG review Roman Danyliw: 6392 6. Requested additional text elaborating misconfiguration plus 6393 attack vectors. 6395 6.1.3.1 Added paragraph about unsecured NTP as basis for time in the 6396 absence of other options. 6398 6.7.2 reworded text about additional secure channel protocol 6399 reqiurements. 6401 6.7.3.1.2. Added requirement for ACP nodes supporting IKEv2 to 6402 support RFC8247 (not sure how that got dropped from prior versions. 6404 Replaced minimum crypto requirements definition via specific AES 6405 options with more generic "symmetric key/hash strength" requirements. 6407 6.10.7.3. Added example how to derive addressing scheme from IDevID 6408 (PID). Added explanation how to deal with non-persistant registrar 6409 address database (hint: it sucks or is wasteful, what did you 6410 expect). 6412 8.1.1. Added explanation for 'Physical controlled/secured'. 6414 8.1.5. Removed 'Physical controlled/secured' text, refer back to 6415 8.1.1. 6417 8.2.1. Fixed ABNF 'or' syntax line. 6419 9.3.2. Added explanation of remote management problem with interface 6420 "down" type commands. 6422 10.2.1. Added explanations for attacks from impaired ACP nodes. 6424 11. Rewrote intro paragraph. Removed text referring to enrollment/ 6425 registrars as they are out of scope of ACP (dependencies only). 6427 11. Added note about need for new protocols inside ACP to use end- 6428 to-end authentication. 6430 11. Rewrote paragraph about operator mistakes so as to be 6431 actionably. Operators must not make mistakes - but ACP minimizes the 6432 mistakes they can make. 6434 ACP domain certificate -> ACP certificate. 6436 Various other cosmetic edits (thanks!) and typo fixes (sorry for not 6437 running full spell check for every version. Will definitely do 6438 before RFC editor). 6440 Other: 6442 6.12.5.2.1./6.12.5.2.2. Added text explaining link breakage wrt. 6443 RTL (came about re-analyzing behavior after question about hop 6444 count). 6446 Removed now unnecessary references for earlier rrc822Name otherName 6447 choice. 6449 15.5. draft-ietf-anima-autonomic-control-plane-27 6451 Too many revisions with too many fixes. Lets do a one-word change 6452 revision for a change now if it helps to accelerate the review 6453 process. 6455 Added "subjectAltName /" to make it unambiguous that AcpNodeName is 6456 indeed a SAN (from Russ). 6458 15.6. draft-ietf-anima-autonomic-control-plane-26 6460 Russ Housley review of -25. 6462 1.1 Explicit reference for TLS 1.2 RFC. 6464 2. Changed term of "ACP Domain Information" to AcpNodeName (ASN.1) / 6465 acp-node-name (ABNF), also through rest of document. 6467 2. Improved CA behavior definition. changed IDevID/LDevID to IDevID/ 6468 LDevID certificate to be more unambiguous. 6470 2. Changed definition of root CA to just refer to how its used in 6471 RFC7030 CA root key update, because thats the only thing relevant to 6472 ACP. 6474 6.1.1 Moved ECDH requirement to end of text as it was not related to 6475 the subject of the initial paragraps. Likewise reference to 6476 CABFORUM. 6478 6.1.1 Reduced cert key requirements to only be MUST for certs with 6479 2048 RSA public key and P-256 curves. Reduced longer keys to SHOULD. 6481 6.1.2 Changed text for conversion from rfc822Name to otherName / 6482 AcpNode, removed all the explanations of benefits coming with 6483 rfc822Name *sob* *sob* *sob*. 6485 6.1.2.1 New ASN.1 definition for otherName / AcpNodeName. 6487 6.1.3 Fixed up text. re the handling of missing connectivity for 6488 CRLDP / OCSP. 6490 6.1.4 Fixed up text re. inability to use public CA to situation with 6491 otherName / AcpNodeName (no more ACME rfc822Name validation for us 6492 *sob* *sob* *sob*). 6494 12. Added ASN.1 registration requests to IANA section. 6496 Appenices. Minor changes for rfc822Name to otherName change. 6498 Various minor verbal fixes/enhancements. 6500 15.7. draft-ietf-anima-autonomic-control-plane-25 6502 Crypto parameter discuss from Valery Smyslov and Paul Wouters and 6503 resulting changes. 6505 6.7.2 Moved Michael Richardson suggested diagnostic of signaling TA 6506 from IPsec section to this general requirements section and added 6507 explanation how this may be inappropriate if TA payload is considered 6508 secret by TA owner. 6510 6.7.3.1 Added traffic selectors for native IPsec. Improved text 6511 explanation. 6513 6.7.3.1.2 removed misleading text about signaling TA when using 6514 intermediate certs. 6516 6.7.3.1.2 Removed requirement for 'PKCS #7 wrapped X.509 certificate' 6517 requirement on request of Valery Smyslov as it is not defined in 6518 RFC7296 and there are enough options mandated in RFC7296. Replaced 6519 with just informative text to educate readers who are not IPsec 6520 experts what the mandatory option in RFC7296 is that allows to signal 6521 certificates. 6523 6.7.3.1.2 Added SHOULD requirement how to deal with CERTREQ so that 6524 6.7.2 requirement for TA diagnostics will work in IKEv2 (ignoring 6525 CERTREQ is permitted by IKEv2). Added explanation how this will 6526 result in TA cert diagnostics. 6528 6.7.3.1.2 Added requirement for IKEv2 to operate on link-local 6529 addresses for ACP so at to assume ACT cert as the only possible 6530 authenticator - to avoid potentialy failing section from multiple 6531 available certs on a router. 6533 6.7.3.1.2 fixed PKIX- style OID to ASN.1 object AlgorithmIdentifier 6534 (Paul). 6536 6.7.3.2 Added IPsec traffic selectors for IPsec with GRE. 6538 6.7.5 Added notion that IPsec/GRE MAY be preferred over IPsec/native. 6539 Luckily IPsec/native uses tunneling, whereas IPsec/GRE uses transport 6540 mode, and there is a long discuss whether it is permitted to even 6541 build IPsec connectings that only support transports instead of 6542 always being able to fall back to tunnel mode. Added explanatory 6543 paragraph why ACP nodes may prefer GRE over native (wonder how that 6544 was missing..). 6546 9.1.1 Added section to explain need for secure channel peer 6547 diagnostics via signaling of TA. Four examples given. 6549 Paul Wouters mentioned that ipkcs7 had to be used in some interop 6550 cases with windows CA, but that is an issue of ACP Registrar having 6551 to convert into PKCS#7 to talk to a windows CA, and this spec is not 6552 concerned with that, except to know that it is feasible, so not 6553 mentioned in text anywhere, just tracking discussion here in 6554 changelog. 6556 Michael Richardson: 6558 3.1.3 Added point in support of rfc822address that CA may not support 6559 to sign certificates with new attributes (such as new otherName). 6561 Michael Richardson/Brian Carpenter fix: 6563 6.1.5.1/6.3 Fixed GRASP examples. 6565 Joe Halpern review: 6567 1. Enhanded introduction text for in-band and of out-of-band, 6568 explaining how ACP is an in-band network aiming to achieve all 6569 possible benefits of an out-of-band network. 6571 1. Comprehensive explanation for term Data-Plane as it is only 6572 logically following pre-established terminology on a fully autonomic 6573 node, when used for existing nodes augmented with ACP, Data-Plane has 6574 more functionality than usually associated with the term. 6576 2. Removed explanatory text for Data-Plane, referring to section 1. 6578 2. Reduced explanation in definition of in-band (management/ 6579 signaling), out-of-band-signaling, now pointing to section 1. 6581 5. Rewrote a lot of the steps (overview) as this text was not 6582 reviewed for long time. Added references to normative section for 6583 each step to hopefully avoid feedback of not explaining terms used 6584 (really not possible to give good summary without using forward 6585 references). 6587 2. Separate out-of-band-management definition from virtual out-of- 6588 band-management definition (later one for ACP). 6590 2. Added definitions for RPI and RPL. 6592 6.1.1. added note about end-to-end authentication to distinguish 6593 channel security from overall ACP security model. 6595 6.5 Fixed bugs in channel selection signaling step description (Alice 6596 vs. Bob). 6598 6.7.1 Removed redundant channel selection explanation. 6600 6.10.3 remove locator/identifier terminology from zone addressing 6601 scheme description (unnecessary), removed explanations (now in 9.4), 6602 simplified text, clarified requirement for Node-ID to be unique, 6603 recommend to use primarily zone 0. 6605 6.10.3.1 Removed. Included a lot of insufficient suggestions for 6606 future stanards extensions, most of it was wrong or would need to be 6607 revisited by WG anyhow. Idea now (just here for comment): Announce 6608 via GRASP Zone-ID (e.g. from per-zone edge-node/registrar) into a 6609 zone of the ACP so all nodes supporting the scheme can automatically 6610 self-allocate the Zone-ID. 6612 6.11.1.1 (RPL overview), eliminated redundant text. 6614 6.11.1.1.1 New subsection to better structure overview. 6616 6.11.1.1.2 New subsection to better group overview, replaced TTL 6617 explanation (just the symptom) with hopefully better reconvergence 6618 text (intent of the profile) for the ACP RPL profile. 6620 6.11.1.1.6 Added text to explain simple choice for rank_factor. 6622 6.11.1.13 moved explanation for RPI up into 6.11.1.1. 6624 6.12.5.1 rewrote section for ACP Loopback Interface. 6626 9.4 New informative/informational section for partial or incremental 6627 adoption of ACP to help understand why there is the Zone interface 6628 sub-scheme, and how to use it. 6630 Unrelated fixes: 6632 Ask to RFC editor to add most important abbreviations to RFC editor 6633 abbreviation list. 6635 6.10.2 changed names in ACP addressing scheme table to be less 6636 suggestive of use. 6638 Russ Hously review: 6640 2. Fixed definition of "Enrollment", "Trust Anchor", "CA", and "root 6641 CA". Changed "Certificate Authority" to "Certification Authority" 6642 throughout the document (correct term according to X.509). 6644 6.1 Fixed explanation of mutual ACP trust. 6646 6.1.1 s/X509/X509v3/. 6648 6.1.2 created bulleted lists for explanations and justifications for 6649 choices of ACP certificate encoding. No semantic changes, just to 6650 make it easier to refer to the points in discussions (rfcdiff seems 6651 to have a bug showing text differences due to formatting changes). 6653 6.1.3 Moved content of rule #1 into previous rule #2 because 6654 certification chain validation does imply validation of lifetime. 6655 numbers of all rules reduced by 1, changed hopefully all references 6656 to the rule numbers in the document. 6658 Rule #3, Hopefully fixed linguistic problem self-contradiction of 6659 MUST by lower casing MUST in the explanation part and rewriting the 6660 condition when this is not applicable. 6662 6.1.4 Replaced redundant term "Trust Point" (TP) with Trust Anchor 6663 (TA"). Replaced throughout document Trust Anchor with abbreviation 6664 TA. 6666 Enhanced several sentences/rewrote paragraphs to make explanations 6667 clearer. 6669 6.6 Added explanation how ACP nodes must throttle their attempts for 6670 connection making purely on the result of their own connection 6671 attempts, not based on those connections where they are responder. 6673 15.8. draft-ietf-anima-autonomic-control-plane-24 6675 Leftover from -23 review by Eric Vyncke: 6677 Swapping sections 9 and 10, section 9 was meant to be at end of 6678 document and summarize. Its not meant to be misinterpreted as 6679 introducing any new information. This did happen because section 10 6680 was added after section 9. 6682 15.9. draft-ietf-anima-autonomic-control-plane-23 6684 Note: big rfcdiff of TOC is an rfcdiff bug, changes really minimal. 6686 Review of IPsec security with Mcr and ipsec mailing list. 6688 6.7.1 - new section: Moved general considerations for secure channel 6689 protocols here, refined them. 6691 6.7.2 - new section: Moved common requirements for secure channel 6692 protocols here, refined them. 6694 6.7.3.1.1. - improved requirements text related to RFC8221, better 6695 explamations re. HW acceleration issues. 6697 6.7.3.1.2. - improved requirements text related to RFC8247, (some 6698 requirements still discussed to be redundant, will be finalized in 6699 next weeks. 6701 Eric Vyncke review of -21: 6703 Only noting most important changes, long list of smaller text/ 6704 readability enhancements. 6706 2. - New explanation of "normative", "informational" section title 6707 tags. alphabetic reordering of terms, refined definitions for CA, 6708 CRL. root CA. 6710 6.1.1. - explanation when IDevID parameters may be copied into 6711 LDevID. 6713 6.1.2. - Fixed hex digits in ACP domain information to lower case. 6715 6.1.3.1. - New section on Realtime clock and Time Validation. 6717 6.3 - Added explanation that DTLS means >= version 1.2 (not only 6718 1.2). 6720 6.7 - New text in this main section explaing relationship of ACP 6721 secure channels and ACP virtual interfaces - with forward references 6722 to virtual interface section. 6724 6.8.2 - reordered text and picture, no text change. 6726 6.10.7.2 - describe first how Registrar-ID can be allocted for all 6727 type of registrars, then refined text for how to potentially use MAC 6728 addresses on physical registrars. 6730 6.11.1.1 - Added text how this profile does not use Data-Plane 6731 artefacts (RPI) because hadware forwarding. This was previously 6732 hidden only later in the text. 6734 6.11.1.13. - Rewrote RPL Data-Plane artefact text. Provide decoder 6735 ring for abbreviations and all relevant RFCs. 6737 6.12.5.2. - Added more explicit text that secure channels are mapped 6738 into virtual interfaces, moved different type of interfaces used by 6739 ACP into separate subsections to be able to refer to them. 6741 7.2 - Rewrote/refined text for ACP on L2, prior text was confusing 6742 and did not well explain why ACP for L2/L3 switches can be 6743 implemented without any L2 (HW) changes. Also missing explanation of 6744 only running GRASP untagged when VLANs are used. 6746 8.1.1 - Added requirement for ACP Edge nodes to allow configurable 6747 filtering of IPv6 RPI headers. 6749 11. - (security section). Moved explanation of address stealing from 6750 7.2 to here. 6752 15.10. draft-ietf-anima-autonomic-control-plane-22 6754 Ben Kaduk review of -21: 6756 RFC822 encoding of ACP domain information: 6758 6.1.2 rewrote text for explaining / justifying use of rfc822name as 6759 identifier for node CP in certificate (was discussed in thread, but 6760 badly written in prior versions). 6762 6.1.2 Changed EBNF syntax to use "+" after rfcSELF because that is 6763 the known primary name to extensions separator in many email systems 6764 ("." was wrong in prior versions). 6766 6.1.2 Rewrote/improved explanations for use of rfc822name field to 6767 explain better why it is PKIX compliant and the right thing to do. 6769 Crypto parameters for IPsec: 6771 6.1 - Added explanation of why manual keying for ACP is not feasible 6772 for ACP. Surprisingly, that text did not exist. Referred to by 6773 IPsec text (6.7.1), but here is the right place to describe the 6774 reasoning. 6776 6.1.2 - Small textual refinement referring to requirements to 6777 authenticate peers (for the special cases of empty or '0' ACP address 6778 in ACP domain information field. 6780 6.3 - To better justify Bens proposed change of secure channel 6781 protocol being IPsec vs. GRASP objective being IKEv2, better 6782 explained how protocol indicated in GRASP objective-value is name of 6783 protocol used to negotiate secure channel, use example of IKEv2 to 6784 negotiate IPsec. 6786 6.7.1 - refinemenet similar to 6.3. 6788 - moved new paragraph from Bens pull request up from 6.7.1.1 to 6.7.1 6789 as it equally applies to GRE encapped IPsec (looks nicer one level 6790 up). 6792 - created subsections 6.7.1.1 (IPsec/ESP) / 6.7.1.2 (IKEv2) to 6793 clearer distinguish between these two requirements blocks. 6795 - Refined the text in these two sections to hopefully be a good 6796 answer to Valery's concern of not randomnly mocking with existing 6797 requirements docs (rfc8247 / rfc8221). 6799 6.7.1.1.1 - IPsec/ESP requirements section: 6801 - MUST support rfc8221 mandatory EXCEPT for the superceeding 6802 requirements in this section. Previously, this was not quite clear 6803 from the text. 6805 - Hopefully persuasive explanations about the requirements levels for 6806 ENCR_AES_GCM_16, ENCR_AES_CBC, ENCR_AES_CCM_8 and 6807 ENCR_CHACHA20_POLY1305: Restructured text for why not ENCR_AES_CBC 6808 (was in prior version, just not well structured), added new 6809 expanations for ENCR_AES_CCM_8 and ENCR_CHACHA20_POLY130. 6811 - In simple terms, requirements for ENCR_AES_CBC, ENCR_AES_CCM_8, 6812 ENCR_CHACHACHA are SHOULD when they are implementable with rqual or 6813 faster performancce than ENCR_AES_GCM_16. 6815 - Removed text about "additional rfc8221" reqiurements MAY be used. 6816 Now the logic is that all other requirements apply. Hopefully we 6817 have written enough so that we prohibited downgrades. 6819 6.7.1.1.2 - RFC8247 requirements: 6821 - Added mandate to support rfc8247, added explanation that there is 6822 no "stripping down" requirement, just additional stronger 6823 requirements to mandate correct use of ACP certificartes during 6824 authentication. 6826 - refined text on identifying ACP by IPv6 address to be clearer: 6827 Identifying in the context of IKEv2 and cases for '0' in ACP domain 6828 information. 6830 - removed last two paragraphs about relationship to rfc8247, as his 6831 is now written in first paragraph of the section. 6833 End of Ben Kaduk review related fixes. 6835 Other: 6837 Forgot to update example of ACP domain information to use capitalized 6838 hex-digits as required by HEXDIG used. 6840 Added reference to RFC8316 (AN use-cases) to beginning of section 3 6841 (ACP use cases). 6843 Small Enhanced IPsec parameters description / requirements fixes 6844 (from Michael Richardson). 6846 16. Normative References 6848 [I-D.ietf-anima-bootstrapping-keyinfra] 6849 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 6850 and K. Watsen, "Bootstrapping Remote Secure Key 6851 Infrastructures (BRSKI)", Work in Progress, Internet- 6852 Draft, draft-ietf-anima-bootstrapping-keyinfra-43, 7 6853 August 2020, . 6856 [I-D.ietf-anima-grasp] 6857 Bormann, C., Carpenter, B., and B. Liu, "A Generic 6858 Autonomic Signaling Protocol (GRASP)", Work in Progress, 6859 Internet-Draft, draft-ietf-anima-grasp-15, 13 July 2017, 6860 . 6863 [IKEV2IANA] 6864 IANA, "Internet Key Exchange Version 2 (IKEv2) 6865 Parameters", . 6868 [RFC1034] Mockapetris, P.V., "Domain names - concepts and 6869 facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, 6870 November 1987, . 6872 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 6873 Requirement Levels", BCP 14, RFC 2119, 6874 DOI 10.17487/RFC2119, March 1997, 6875 . 6877 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 6878 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 6879 DOI 10.17487/RFC3810, June 2004, 6880 . 6882 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 6883 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 6884 November 2005, . 6886 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 6887 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 6888 . 6890 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 6891 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 6892 2006, . 6894 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 6895 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 6896 December 2005, . 6898 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 6899 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 6900 DOI 10.17487/RFC4861, September 2007, 6901 . 6903 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 6904 Address Autoconfiguration", RFC 4862, 6905 DOI 10.17487/RFC4862, September 2007, 6906 . 6908 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 6909 Specifications: ABNF", STD 68, RFC 5234, 6910 DOI 10.17487/RFC5234, January 2008, 6911 . 6913 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 6914 (TLS) Protocol Version 1.2", RFC 5246, 6915 DOI 10.17487/RFC5246, August 2008, 6916 . 6918 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 6919 Housley, R., and W. Polk, "Internet X.509 Public Key 6920 Infrastructure Certificate and Certificate Revocation List 6921 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 6922 . 6924 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 6925 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 6926 January 2012, . 6928 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 6929 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 6930 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 6931 Low-Power and Lossy Networks", RFC 6550, 6932 DOI 10.17487/RFC6550, March 2012, 6933 . 6935 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 6936 and D. Barthel, "Routing Metrics Used for Path Calculation 6937 in Low-Power and Lossy Networks", RFC 6551, 6938 DOI 10.17487/RFC6551, March 2012, 6939 . 6941 [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing 6942 Protocol for Low-Power and Lossy Networks (RPL)", 6943 RFC 6552, DOI 10.17487/RFC6552, March 2012, 6944 . 6946 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 6947 Power and Lossy Networks (RPL) Option for Carrying RPL 6948 Information in Data-Plane Datagrams", RFC 6553, 6949 DOI 10.17487/RFC6553, March 2012, 6950 . 6952 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 6953 "Enrollment over Secure Transport", RFC 7030, 6954 DOI 10.17487/RFC7030, October 2013, 6955 . 6957 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 6958 Kivinen, "Internet Key Exchange Protocol Version 2 6959 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 6960 2014, . 6962 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 6963 "Recommendations for Secure Use of Transport Layer 6964 Security (TLS) and Datagram Transport Layer Security 6965 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 6966 2015, . 6968 [RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support 6969 for Generic Routing Encapsulation (GRE)", RFC 7676, 6970 DOI 10.17487/RFC7676, October 2015, 6971 . 6973 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 6974 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 6975 May 2017, . 6977 [RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T. 6978 Kivinen, "Cryptographic Algorithm Implementation 6979 Requirements and Usage Guidance for Encapsulating Security 6980 Payload (ESP) and Authentication Header (AH)", RFC 8221, 6981 DOI 10.17487/RFC8221, October 2017, 6982 . 6984 [RFC8247] Nir, Y., Kivinen, T., Wouters, P., and D. Migault, 6985 "Algorithm Implementation Requirements and Usage Guidance 6986 for the Internet Key Exchange Protocol Version 2 (IKEv2)", 6987 RFC 8247, DOI 10.17487/RFC8247, September 2017, 6988 . 6990 [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic 6991 Curve Cryptography (ECC) Cipher Suites for Transport Layer 6992 Security (TLS) Versions 1.2 and Earlier", RFC 8422, 6993 DOI 10.17487/RFC8422, August 2018, 6994 . 6996 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 6997 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 6998 . 7000 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 7001 Definition Language (CDDL): A Notational Convention to 7002 Express Concise Binary Object Representation (CBOR) and 7003 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 7004 June 2019, . 7006 17. Informative References 7008 [ACPDRAFT] Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 7009 Control Plane (ACP)", Work in Progress, Internet-Draft, 7010 draft-ietf-anima-autonomic-control-plane-30, 7011 . [RFC-Editor: Please remove this 7013 complete reference from the RFC] Refer to the IETF working 7014 group draft for the few sections removed from this 7015 document for various reasons. They capture the state of 7016 discussion about unresolved issues that may need to be 7017 revisited in future work. 7019 [AR8021] Group, W. -. H. L. L. P. W., "IEEE Standard for Local and 7020 metropolitan area networks - Secure Device Identity", 7021 December 2009, . 7024 [CABFORUM] CA/Browser Forum, "Certificate Contents for Baseline SSL", 7025 November 2019, . 7028 [FCC] FCC, "FCC STAFF REPORT ON NATIONWIDE T-MOBILE NETWORK 7029 OUTAGE ON JUNE 15, 2020 (PS Docket No. 20-183)", 2020, 7030 . The FCC's Public Safety and Homeland 7032 Security Bureau issues a report on a nationwide T-Mobile 7033 outage that occurred on June 15, 2020. Action by: Public 7034 Safety and Homeland Security Bureau. 7036 [I-D.eckert-anima-noc-autoconfig] 7037 Eckert, T., "Autoconfiguration of NOC services in ACP 7038 networks via GRASP", Work in Progress, Internet-Draft, 7039 draft-eckert-anima-noc-autoconfig-00, 2 July 2018, 7040 . 7043 [I-D.ietf-acme-star] 7044 Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T. 7045 Fossati, "Support for Short-Term, Automatically-Renewed 7046 (STAR) Certificates in Automated Certificate Management 7047 Environment (ACME)", Work in Progress, Internet-Draft, 7048 draft-ietf-acme-star-11, 24 October 2019, 7049 . 7052 [I-D.ietf-anima-prefix-management] 7053 Jiang, S., Du, Z., Carpenter, B., and Q. Sun, "Autonomic 7054 IPv6 Edge Prefix Management in Large-scale Networks", Work 7055 in Progress, Internet-Draft, draft-ietf-anima-prefix- 7056 management-07, 18 December 2017, . 7060 [I-D.ietf-anima-reference-model] 7061 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 7062 and J. Nobre, "A Reference Model for Autonomic 7063 Networking", Work in Progress, Internet-Draft, draft-ietf- 7064 anima-reference-model-10, 22 November 2018, 7065 . 7068 [I-D.ietf-roll-applicability-template] 7069 Richardson, M., "ROLL Applicability Statement Template", 7070 Work in Progress, Internet-Draft, draft-ietf-roll- 7071 applicability-template-09, 3 May 2016, 7072 . 7075 [I-D.ietf-tls-dtls13] 7076 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 7077 Datagram Transport Layer Security (DTLS) Protocol Version 7078 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 7079 dtls13-38, 29 May 2020, . 7082 [IEEE-1588-2008] 7083 IEEE, "IEEE Standard for a Precision Clock Synchronization 7084 Protocol for Networked Measurement and Control Systems", 7085 December 2008, . 7088 [IEEE-802.1X] 7089 Group, W. -. H. L. L. P. W., "IEEE Standard for Local and 7090 Metropolitan Area Networks: Port-Based Network Access 7091 Control", February 2010, 7092 . 7095 [LLDP] Group, W. -. H. L. L. P. W., "IEEE Standard for Local and 7096 Metropolitan Area Networks: Station and Media Access 7097 Control Connectivity Discovery", June 2016, 7098 . 7101 [MACSEC] Group, W. -. H. L. L. P. W., "IEEE Standard for Local and 7102 Metropolitan Area Networks: Media Access Control (MAC) 7103 Security", June 2006, 7104 . 7107 [RFC1112] Deering, S.E., "Host extensions for IP multicasting", 7108 STD 5, RFC 1112, DOI 10.17487/RFC1112, August 1989, 7109 . 7111 [RFC1492] Finseth, C., "An Access Control Protocol, Sometimes Called 7112 TACACS", RFC 1492, DOI 10.17487/RFC1492, July 1993, 7113 . 7115 [RFC1654] Rekhter, Y., Ed. and T. Li, Ed., "A Border Gateway 7116 Protocol 4 (BGP-4)", RFC 1654, DOI 10.17487/RFC1654, July 7117 1994, . 7119 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. 7120 J., and E. Lear, "Address Allocation for Private 7121 Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, 7122 February 1996, . 7124 [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax 7125 Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998, 7126 . 7128 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 7129 (IKE)", RFC 2409, DOI 10.17487/RFC2409, November 1998, 7130 . 7132 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 7133 "Remote Authentication Dial In User Service (RADIUS)", 7134 RFC 2865, DOI 10.17487/RFC2865, June 2000, 7135 . 7137 [RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, 7138 DOI 10.17487/RFC3164, August 2001, 7139 . 7141 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 7142 C., and M. Carney, "Dynamic Host Configuration Protocol 7143 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 7144 2003, . 7146 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 7147 Architecture for Describing Simple Network Management 7148 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 7149 DOI 10.17487/RFC3411, December 2002, 7150 . 7152 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 7153 "DNS Extensions to Support IP Version 6", STD 88, 7154 RFC 3596, DOI 10.17487/RFC3596, October 2003, 7155 . 7157 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 7158 Protocol (XMPP): Core", RFC 3920, DOI 10.17487/RFC3920, 7159 October 2004, . 7161 [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export 7162 Version 9", RFC 3954, DOI 10.17487/RFC3954, October 2004, 7163 . 7165 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 7166 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 7167 DOI 10.17487/RFC4007, March 2005, 7168 . 7170 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 7171 "Internet X.509 Public Key Infrastructure Certificate 7172 Management Protocol (CMP)", RFC 4210, 7173 DOI 10.17487/RFC4210, September 2005, 7174 . 7176 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 7177 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 7178 2006, . 7180 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 7181 for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, 7182 . 7184 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 7185 "Considerations for Internet Group Management Protocol 7186 (IGMP) and Multicast Listener Discovery (MLD) Snooping 7187 Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, 7188 . 7190 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 7191 Group Management Protocol Version 3 (IGMPv3) and Multicast 7192 Listener Discovery Protocol Version 2 (MLDv2) for Source- 7193 Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, 7194 August 2006, . 7196 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 7197 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 7198 . 7200 [RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol 7201 Independent Multicast (PIM)", RFC 4610, 7202 DOI 10.17487/RFC4610, August 2006, 7203 . 7205 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 7206 Extensions for Stateless Address Autoconfiguration in 7207 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 7208 . 7210 [RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure 7211 Subject Alternative Name for Expression of Service Name", 7212 RFC 4985, DOI 10.17487/RFC4985, August 2007, 7213 . 7215 [RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet 7216 Group Management Protocol Version 3 (IGMPv3) and Multicast 7217 Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, 7218 DOI 10.17487/RFC5790, February 2010, 7219 . 7221 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 7222 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 7223 . 7225 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 7226 "Network Time Protocol Version 4: Protocol and Algorithms 7227 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 7228 . 7230 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 7231 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 7232 DOI 10.17487/RFC5912, June 2010, 7233 . 7235 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 7236 and A. Bierman, Ed., "Network Configuration Protocol 7237 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 7238 . 7240 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 7241 Cheshire, "Internet Assigned Numbers Authority (IANA) 7242 Procedures for the Management of the Service Name and 7243 Transport Protocol Port Number Registry", BCP 165, 7244 RFC 6335, DOI 10.17487/RFC6335, August 2011, 7245 . 7247 [RFC6402] Schaad, J., "Certificate Management over CMS (CMC) 7248 Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011, 7249 . 7251 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 7252 of Interpretation", RFC 6407, DOI 10.17487/RFC6407, 7253 October 2011, . 7255 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 7256 Routing Header for Source Routes with the Routing Protocol 7257 for Low-Power and Lossy Networks (RPL)", RFC 6554, 7258 DOI 10.17487/RFC6554, March 2012, 7259 . 7261 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 7262 "Default Address Selection for Internet Protocol Version 6 7263 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 7264 . 7266 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 7267 Ed., "Diameter Base Protocol", RFC 6733, 7268 DOI 10.17487/RFC6733, October 2012, 7269 . 7271 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 7272 DOI 10.17487/RFC6762, February 2013, 7273 . 7275 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 7276 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 7277 . 7279 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 7280 "TCP Extensions for Multipath Operation with Multiple 7281 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 7282 . 7284 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 7285 Locator/ID Separation Protocol (LISP)", RFC 6830, 7286 DOI 10.17487/RFC6830, January 2013, 7287 . 7289 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 7290 "Specification of the IP Flow Information Export (IPFIX) 7291 Protocol for the Exchange of Flow Information", STD 77, 7292 RFC 7011, DOI 10.17487/RFC7011, September 2013, 7293 . 7295 [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local 7296 Addressing inside an IPv6 Network", RFC 7404, 7297 DOI 10.17487/RFC7404, November 2014, 7298 . 7300 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 7301 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 7302 Defined Networking (SDN): Layers and Architecture 7303 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 7304 2015, . 7306 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 7307 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 7308 December 2014, . 7310 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 7311 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 7312 Networking: Definitions and Design Goals", RFC 7575, 7313 DOI 10.17487/RFC7575, June 2015, 7314 . 7316 [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap 7317 Analysis for Autonomic Networking", RFC 7576, 7318 DOI 10.17487/RFC7576, June 2015, 7319 . 7321 [RFC7585] Winter, S. and M. McCauley, "Dynamic Peer Discovery for 7322 RADIUS/TLS and RADIUS/DTLS Based on the Network Access 7323 Identifier (NAI)", RFC 7585, DOI 10.17487/RFC7585, October 7324 2015, . 7326 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 7327 Considerations for IPv6 Address Generation Mechanisms", 7328 RFC 7721, DOI 10.17487/RFC7721, March 2016, 7329 . 7331 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 7332 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 7333 Multicast - Sparse Mode (PIM-SM): Protocol Specification 7334 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 7335 2016, . 7337 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 7338 RFC 7950, DOI 10.17487/RFC7950, August 2016, 7339 . 7341 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 7342 Hosts in a Multi-Prefix Network", RFC 8028, 7343 DOI 10.17487/RFC8028, November 2016, 7344 . 7346 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 7347 Writing an IANA Considerations Section in RFCs", BCP 26, 7348 RFC 8126, DOI 10.17487/RFC8126, June 2017, 7349 . 7351 [RFC8316] Nobre, J., Granville, L., Clemm, A., and A. Gonzalez 7352 Prieto, "Autonomic Networking Use Case for Distributed 7353 Detection of Service Level Agreement (SLA) Violations", 7354 RFC 8316, DOI 10.17487/RFC8316, February 2018, 7355 . 7357 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 7358 "A Voucher Artifact for Bootstrapping Protocols", 7359 RFC 8366, DOI 10.17487/RFC8366, May 2018, 7360 . 7362 [RFC8368] Eckert, T., Ed. and M. Behringer, "Using an Autonomic 7363 Control Plane for Stable Connectivity of Network 7364 Operations, Administration, and Maintenance (OAM)", 7365 RFC 8368, DOI 10.17487/RFC8368, May 2018, 7366 . 7368 [RFC8398] Melnikov, A., Ed. and W. Chuang, Ed., "Internationalized 7369 Email Addresses in X.509 Certificates", RFC 8398, 7370 DOI 10.17487/RFC8398, May 2018, 7371 . 7373 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 7374 Decraene, B., Litkowski, S., and R. Shakir, "Segment 7375 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 7376 July 2018, . 7378 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 7379 Touch Provisioning (SZTP)", RFC 8572, 7380 DOI 10.17487/RFC8572, April 2019, 7381 . 7383 [X.509] International Telecommunication Union, "Information 7384 technology - Open Systems Interconnection - The Directory: 7385 Public-key and attribute certificate frameworks", ITU-T 7386 Recommendation X.509, ISO/IEC 9594-8, October 2016, 7387 . 7389 [X.520] International Telecommunication Union, "Information 7390 technology - Open Systems Interconnection - The Directory: 7391 Selected attribute types", ITU-T Recommendation 7392 X.520, ISO/IEC 9594-6, October 2016, 7393 . 7395 Appendix A. Background and Futures (Informative) 7397 The following sections discuss additional background information 7398 about aspects of the normative parts of this document or associated 7399 mechanisms such as BRSKI (such as why specific choices were made by 7400 the ACP) and they provide discussion about possible future variations 7401 of the ACP. 7403 A.1. ACP Address Space Schemes 7405 This document defines the Zone, Vlong and Manual sub address schemes 7406 primarily to support address prefix assignment via distributed, 7407 potentially uncoordinated ACP registrars as defined in 7408 Section 6.11.7. This costs 48/46-bit identifier so that these ACP 7409 registrar can assign non-conflicting address prefixes. This design 7410 does not leave enough bits to simultaneously support a large number 7411 of nodes (Node-ID) plus a large prefix of local addresses for every 7412 node plus a large enough set of bits to identify a routing Zone. In 7413 result, Zone, Vlong 8/16 attempt to support all features, but via 7414 separate prefixes. 7416 In networks that always expect to rely on a centralized PMS as 7417 described above (Section 9.2.5), the 48/46-bits for the Registrar-ID 7418 could be saved. Such variations of the ACP addressing mechanisms 7419 could be introduced through future work in different ways. If a new 7420 otherName was introduced, incompatible ACP variations could be 7421 created where every design aspect of the ACP could be changed. 7422 Including all addressing choices. If instead a new addressing sub- 7423 type would be defined, it could be a backward compatible extension of 7424 this ACP specification. Information such as the size of a zone- 7425 prefix and the length of the prefix assigned to the ACP node itself 7426 could be encoded via the extension field of the acp-node-name. 7428 Note that an explicitly defined "Manual" addressing sub-scheme is 7429 always beneficial to provide an easy way for ACP nodes to prohibit 7430 incorrect manual configuration of any non-"Manual" ACP address spaces 7431 and therefore ensure that "Manual" operations will never impact 7432 correct routing for any non-"Manual" ACP addresses assigned via ACP 7433 certificates. 7435 A.2. BRSKI Bootstrap (ANI) 7437 BRSKI describes how nodes with an IDevID certificate can securely and 7438 zero-touch enroll with an LDevID certificate to support the ACP. 7439 BRSKI also leverages the ACP to enable zero-touch bootstrap of new 7440 nodes across networks without any configuration requirements across 7441 the transit nodes (e.g., no DHCP/DNS forwarding/server setup). This 7442 includes otherwise not configured networks as described in 7443 Section 3.2. Therefore, BRSKI in conjunction with ACP provides for a 7444 secure and zero-touch management solution for complete networks. 7445 Nodes supporting such an infrastructure (BRSKI and ACP) are called 7446 ANI nodes (Autonomic Networking Infrastructure), see 7447 [I-D.ietf-anima-reference-model]. Nodes that do not support an 7448 IDevID certificate but only an (insecure) vendor specific Unique 7449 Device Identifier (UDI) or nodes whose manufacturer does not support 7450 a MASA could use some future security reduced version of BRSKI. 7452 When BRSKI is used to provision a domain certificate (which is called 7453 enrollment), the BRSKI registrar (acting as an enhanced EST server) 7454 must include the otherName / AcpNodeName encoded ACP address and 7455 domain name to the enrolling node (called pledge) via its response to 7456 the pledges EST CSR Attribute request that is mandatory in BRSKI. 7458 The Certification Authority in an ACP network must not change the 7459 otherName / AcpNodeName in the certificate. The ACP nodes can 7460 therefore find their ACP address and domain using this field in the 7461 domain certificate, both for themselves, as well as for other nodes. 7463 The use of BRSKI in conjunction with the ACP can also help to further 7464 simplify maintenance and renewal of domain certificates. Instead of 7465 relying on CRL, the lifetime of certificates can be made extremely 7466 small, for example in the order of hours. When a node fails to 7467 connect to the ACP within its certificate lifetime, it cannot connect 7468 to the ACP to renew its certificate across it (using just EST), but 7469 it can still renew its certificate as an "enrolled/expired pledge" 7470 via the BRSKI bootstrap proxy. This requires only that the BRSKI 7471 registrar honors expired domain certificates and that the pledge 7472 attempts to perform TLS authentication for BRSKI bootstrap using its 7473 expired domain certificate before falling back to attempting to use 7474 its IDevID certificate for BRSKI. This mechanism could also render 7475 CRLs unnecessary because the BRSKI registrar in conjunction with the 7476 CA would not renew revoked certificates - only a "Do-not-renew" list 7477 would be necessary on BRSKI registrars/CA. 7479 In the absence of BRSKI or less secure variants thereof, provisioning 7480 of certificates may involve one or more touches or non-standardized 7481 automation. Node vendors usually support provisioning of 7482 certificates into nodes via PKCS#7 (see [RFC2315]) and may support 7483 this provisioning through vendor specific models via NETCONF 7484 ([RFC6241]). If such nodes also support NETCONF Zero-Touch 7485 ([RFC8572]) then this can be combined to zero-touch provisioning of 7486 domain certificates into nodes. Unless there are equivalent 7487 integration of NETCONF connections across the ACP as there is in 7488 BRSKI, this combination would not support zero-touch bootstrap across 7489 a not configured network though. 7491 A.3. ACP Neighbor discovery protocol selection 7493 This section discusses why GRASP DULL was chosen as the discovery 7494 protocol for L2 adjacent candidate ACP neighbors. The contenders 7495 considered where GRASP, mDNS or LLDP. 7497 A.3.1. LLDP 7499 LLDP and Cisco's earlier Cisco Discovery Protocol (CDP) are example 7500 of L2 discovery protocols that terminate their messages on L2 ports. 7501 If those protocols would be chosen for ACP neighbor discovery, ACP 7502 neighbor discovery would therefore also terminate on L2 ports. This 7503 would prevent ACP construction over non-ACP capable but LLDP or CDP 7504 enabled L2 switches. LLDP has extensions using different MAC 7505 addresses and this could have been an option for ACP discovery as 7506 well, but the additional required IEEE standardization and definition 7507 of a profile for such a modified instance of LLDP seemed to be more 7508 work than the benefit of "reusing the existing protocol" LLDP for 7509 this very simple purpose. 7511 A.3.2. mDNS and L2 support 7513 Multicast DNNS (mDNS) [RFC6762] with DNS Service Discovery (DNS-SD) 7514 Resource Records (RRs) as defined in [RFC6763] is a key contender as 7515 an ACP discovery protocol. because it relies on link-local IP 7516 multicast, it does operates at the subnet level, and is also found in 7517 L2 switches. The authors of this document are not aware of mDNS 7518 implementation that terminate their mDNS messages on L2 ports instead 7519 of the subnet level. If mDNS was used as the ACP discovery mechanism 7520 on an ACP capable (L3)/L2 switch as outlined in Section 7, then this 7521 would be necessary to implement. It is likely that termination of 7522 mDNS messages could only be applied to all mDNS messages from such a 7523 port, which would then make it necessary to software forward any non- 7524 ACP related mDNS messages to maintain prior non-ACP mDNS 7525 functionality. Adding support for ACP into such L2 switches with 7526 mDNS could therefore create regression problems for prior mDNS 7527 functionality on those nodes. With low performance of software 7528 forwarding in many L2 switches, this could also make the ACP risky to 7529 support on such L2 switches. 7531 A.3.3. Why DULL GRASP 7533 LLDP was not considered because of the above mentioned issues. mDNS 7534 was not selected because of the above L2 mDNS considerations and 7535 because of the following additional points: 7537 If mDNS was not already existing in a node, it would be more work to 7538 implement than DULL GRASP, and if an existing implementation of mDNS 7539 was used, it would likely be more code space than a separate 7540 implementation of DULL GRASP or a shared implementation of DULL GRASP 7541 and GRASP in the ACP. 7543 A.4. Choice of routing protocol (RPL) 7545 This section motivates why RPL - "IPv6 Routing Protocol for Low-Power 7546 and Lossy Networks ([RFC6550] was chosen as the default (and in this 7547 specification only) routing protocol for the ACP. The choice and 7548 above explained profile was derived from a pre-standard 7549 implementation of ACP that was successfully deployed in operational 7550 networks. 7552 Requirements for routing in the ACP are: 7554 * Self-management: The ACP must build automatically, without human 7555 intervention. Therefore, routing protocol must also work 7556 completely automatically. RPL is a simple, self-managing 7557 protocol, which does not require zones or areas; it is also self- 7558 configuring, since configuration is carried as part of the 7559 protocol (see Section 6.7.6 of [RFC6550]). 7560 * Scale: The ACP builds over an entire domain, which could be a 7561 large enterprise or service provider network. The routing 7562 protocol must therefore support domains of 100,000 nodes or more, 7563 ideally without the need for zoning or separation into areas. RPL 7564 has this scale property. This is based on extensive use of 7565 default routing. 7566 * Low resource consumption: The ACP supports traditional network 7567 infrastructure, thus runs in addition to traditional protocols. 7568 The ACP, and specifically the routing protocol must have low 7569 resource consumption both in terms of memory and CPU requirements. 7570 Specifically, at edge nodes, where memory and CPU are scarce, 7571 consumption should be minimal. RPL builds a DODAG, where the main 7572 resource consumption is at the root of the DODAG. The closer to 7573 the edge of the network, the less state needs to be maintained. 7574 This adapts nicely to the typical network design. Also, all 7575 changes below a common parent node are kept below that parent 7576 node. 7577 * Support for unstructured address space: In the Autonomic 7578 Networking Infrastructure, node addresses are identifiers, and may 7579 not be assigned in a topological way. Also, nodes may move 7580 topologically, without changing their address. Therefore, the 7581 routing protocol must support completely unstructured address 7582 space. RPL is specifically made for mobile ad-hoc networks, with 7583 no assumptions on topologically aligned addressing. 7584 * Modularity: To keep the initial implementation small, yet allow 7585 later for more complex methods, it is highly desirable that the 7586 routing protocol has a simple base functionality, but can import 7587 new functional modules if needed. RPL has this property with the 7588 concept of "objective function", which is a plugin to modify 7589 routing behavior. 7590 * Extensibility: Since the Autonomic Networking Infrastructure is a 7591 new concept, it is likely that changes in the way of operation 7592 will happen over time. RPL allows for new objective functions to 7593 be introduced later, which allow changes to the way the routing 7594 protocol creates the DAGs. 7595 * Multi-topology support: It may become necessary in the future to 7596 support more than one DODAG for different purposes, using 7597 different objective functions. RPL allow for the creation of 7598 several parallel DODAGs, should this be required. This could be 7599 used to create different topologies to reach different roots. 7601 * No need for path optimization: RPL does not necessarily compute 7602 the optimal path between any two nodes. However, the ACP does not 7603 require this today, since it carries mainly non-delay-sensitive 7604 feedback loops. It is possible that different optimization 7605 schemes become necessary in the future, but RPL can be expanded 7606 (see point "Extensibility" above). 7608 A.5. ACP Information Distribution and multicast 7610 IP multicast is not used by the ACP because the ANI (Autonomic 7611 Networking Infrastructure) itself does not require IP multicast but 7612 only service announcement/discovery. Using IP multicast for that 7613 would have made it necessary to develop a zero-touch auto configuring 7614 solution for ASM (Any Source Multicast - the original form of IP 7615 multicast defined in [RFC1112]), which would be quite complex and 7616 difficult to justify. One aspect of complexity where no attempt at a 7617 solution has been described in IETF documents is the automatic- 7618 selection of routers that should be PIM Sparse Mode (PIM-SM) 7619 Rendezvous Points (RPs) (see [RFC7761]). The other aspects of 7620 complexity are the implementation of MLD ([RFC4604]), PIM-SM and 7621 Anycast-RP (see [RFC4610]). If those implementations already exist 7622 in a product, then they would be very likely tied to accelerated 7623 forwarding which consumes hardware resources, and that in return is 7624 difficult to justify as a cost of performing only service discovery. 7626 Some future ASA may need high performance in-network data 7627 replication. That is the case when the use of IP multicast is 7628 justified. Such an ASA can then use service discovery from ACP 7629 GRASP, and then they do not need ASM but only SSM (Source Specific 7630 Multicast, see [RFC4607]) for the IP multicast replication. SSM 7631 itself can simply be enabled in the Data-Plane (or even in an update 7632 to the ACP) without any other configuration than just enabling it on 7633 all nodes and only requires a simpler version of MLD (see [RFC5790]). 7635 LSP (Link State Protocol) based IGP routing protocols typically have 7636 a mechanism to flood information, and such a mechanism could be used 7637 to flood GRASP objectives by defining them to be information of that 7638 IGP. This would be a possible optimization in future variations of 7639 the ACP that do use an LSP routing protocol. Note though that such a 7640 mechanism would not work easily for GRASP M_DISCOVERY messages which 7641 are intelligently (constrained) flooded not across the whole ACP, but 7642 only up to a node where a responder is found. We do expect that many 7643 future services in ASA will have only few consuming ASA, and for 7644 those cases, M_DISCOVERY is the more efficient method than flooding 7645 across the whole domain. 7647 Because the ACP uses RPL, one desirable future extension is to use 7648 RPLs existing notion of DODAG, which are loop-free distribution 7649 trees, to make GRASP flooding more efficient both for M_FLOOD and 7650 M_DISCOVERY. See Section 6.13.5 how this will be specifically 7651 beneficial when using NBMA interfaces. This is not currently 7652 specified in this document because it is not quite clear yet what 7653 exactly the implications are to make GRASP flooding depend on RPL 7654 DODAG convergence and how difficult it would be to let GRASP flooding 7655 access the DODAG information. 7657 A.6. CAs, domains and routing subdomains 7659 There is a wide range of setting up different ACP solution by 7660 appropriately using CAs and the domain and rsub elements in the acp- 7661 node-name in the domain certificate. We summarize these options here 7662 as they have been explained in different parts of the document in 7663 before and discuss possible and desirable extensions: 7665 An ACP domain is the set of all ACP nodes that can authenticate each 7666 other as belonging to the same ACP network using the ACP domain 7667 membership check (Section 6.2.3). GRASP inside the ACP is run across 7668 all transitively connected ACP nodes in a domain. 7670 The rsub element in the acp-node-name permits the use of addresses 7671 from different ULA prefixes. One use case is to create multiple 7672 physical networks that initially may be separated with one ACP domain 7673 but different routing subdomains, so that all nodes can mutual trust 7674 their ACP certificates (not depending on rsub) and so that they could 7675 connect later together into a contiguous ACP network. 7677 One instance of such a use case is an ACP for regions interconnected 7678 via a non-ACP enabled core, for example due to the absence of product 7679 support for ACP on the core nodes. ACP connect configurations as 7680 defined in this document can be used to extend and interconnect those 7681 ACP islands to the NOC and merge them into a single ACP when later 7682 that product support gap is closed. 7684 Note that RPL scales very well. It is not necessary to use multiple 7685 routing subdomains to scale ACP domains in a way that would be 7686 required if other routing protocols where used. They exist only as 7687 options for the above mentioned reasons. 7689 If different ACP domains are to be created that should not allow to 7690 connect to each other by default, these ACP domains simply need to 7691 have different domain elements in the acp-node-name. These domain 7692 elements can be arbitrary, including subdomains of one another: 7693 Domains "example.com" and "research.example.com" are separate domains 7694 if both are domain elements in the acp-node-name of certificates. 7696 It is not necessary to have a separate CA for different ACP domains: 7697 an operator can use a single CA to sign certificates for multiple ACP 7698 domains that are not allowed to connect to each other because the 7699 checks for ACP adjacencies includes comparison of the domain part. 7701 If multiple independent networks choose the same domain name but had 7702 their own CA, these would not form a single ACP domain because of CA 7703 mismatch. Therefore, there is no problem in choosing domain names 7704 that are potentially also used by others. Nevertheless it is highly 7705 recommended to use domain names that one can have high probability to 7706 be unique. It is recommended to use domain names that start with a 7707 DNS domain names owned by the assigning organization and unique 7708 within it. For example, "acp.example.com" if you own "example.com". 7710 A.7. Intent for the ACP 7712 Intent is the architecture component of autonomic networks according 7713 to [I-D.ietf-anima-reference-model] that allows operators to issue 7714 policies to the network. Its applicability for use is quite flexible 7715 and freeform, with potential applications including policies flooded 7716 across ACP GRASP and interpreted on every ACP node. 7718 One concern for future definitions of Intent solutions is the problem 7719 of circular dependencies when expressing Intent policies about the 7720 ACP itself. 7722 For example, Intent could indicate the desire to build an ACP across 7723 all domains that have a common parent domain (without relying on the 7724 rsub/routing-subdomain solution defined in this document). For 7725 example, ACP nodes with domain "example.com", "access.example.com", 7726 "core.example.com" and "city.core.example.com" should all establish 7727 one single ACP. 7729 If each domain has its own source of Intent, then the Intent would 7730 simply have to allow adding the peer domains TA and domain names to 7731 the parameters for the ACP domain membership check (Section 6.2.3) so 7732 that nodes from those other domains are accepted as ACP peers. 7734 If this Intent was to be originated only from one domain, it could 7735 likely not be made to work because the other domains will not build 7736 any ACP connection amongst each other, whether they use the same or 7737 different CA due to the ACP domain membership check. 7739 If the domains use the same CA one could change the ACP setup to 7740 permit for the ACP to be established between two ACP nodes with 7741 different acp-domain-names, but only for the purpose of disseminating 7742 limited information, such as Intent, but not to set up full ACP 7743 connectivity, specifically not RPL routing and passing of arbitrary 7744 GRASP information. Unless the Intent policies permit this to happen 7745 across domain boundaries. 7747 This type of approach where the ACP first allows Intent to operate 7748 and only then sets up the rest of ACP connectivity based on Intent 7749 policy could also be used to enable Intent policies that would limit 7750 functionality across the ACP inside a domain, as long as no policy 7751 would disturb the distribution of Intent. For example, to limit 7752 reachability across the ACP to certain type of nodes or locations of 7753 nodes. 7755 A.8. Adopting ACP concepts for other environments 7757 The ACP as specified in this document is very explicit about the 7758 choice of options to allow interoperable implementations. The 7759 choices made may not be the best for all environments, but the 7760 concepts used by the ACP can be used to build derived solutions: 7762 The ACP specifies the use of ULA and deriving its prefix from the 7763 domain name so that no address allocation is required to deploy the 7764 ACP. The ACP will equally work not using ULA but any other /48 IPv6 7765 prefix. This prefix could simply be a configuration of the ACP 7766 registrars (for example when using BRSKI) to enroll the domain 7767 certificates - instead of the ACP registrar deriving the /48 ULA 7768 prefix from the AN domain name. 7770 Some solutions may already have an auto-addressing scheme, for 7771 example derived from existing unique device identifiers (e.g., MAC 7772 addresses). In those cases it may not be desirable to assign 7773 addresses to devices via the ACP address information field in the way 7774 described in this document. The certificate may simply serve to 7775 identify the ACP domain, and the address field could be omitted. The 7776 only fix required in the remaining way the ACP operate is to define 7777 another element in the domain certificate for the two peers to decide 7778 who is the Decider and who is the Follower during secure channel 7779 building. Note though that future work may leverage the acp address 7780 to authenticate "ownership" of the address by the device. If the 7781 address used by a device is derived from some pre-existing permanent 7782 local ID (such as MAC address), then it would be useful to store that 7783 address in the certificate using the format of the access address 7784 information field or in a similar way. 7786 The ACP is defined as a separate VRF because it intends to support 7787 well managed networks with a wide variety of configurations. 7788 Therefore, reliable, configuration-indestructible connectivity cannot 7789 be achieved from the Data-Plane itself. In solutions where all 7790 transit connectivity impacting functions are fully automated 7791 (including security), indestructible and resilient, it would be 7792 possible to eliminate the need for the ACP to be a separate VRF. 7793 Consider the most simple example system in which there is no separate 7794 Data-Plane, but the ACP is the Data-Plane. Add BRSKI, and it becomes 7795 a fully autonomic network - except that it does not support automatic 7796 addressing for user equipment. This gap can then be closed for 7797 example by adding a solution derived from 7798 [I-D.ietf-anima-prefix-management]. 7800 TCP/TLS as the protocols to provide reliability and security to GRASP 7801 in the ACP may not be the preferred choice in constrained networks. 7802 For example, CoAP/DTLS (Constrained Application Protocol) may be 7803 preferred where they are already used, allowing to reduce the 7804 additional code space footprint for the ACP on those devices. Hop- 7805 by-hop reliability for ACP GRASP messages could be made to support 7806 protocols like DTLS by adding the same type of negotiation as defined 7807 in this document for ACP secure channel protocol negotiation. End- 7808 to-end GRASP connections can be made to select their transport 7809 protocol in future extensions of the ACP meant to better support 7810 constrained devices by indicating the supported transport protocols 7811 (e.g. TLS/DTLS) via GRASP parameters of the GRASP objective through 7812 which the transport endpoint is discovered. 7814 The routing protocol RPL used for the ACP does explicitly not 7815 optimize for shortest paths and fastest convergence. Variations of 7816 the ACP may want to use a different routing protocol or introduce 7817 more advanced RPL profiles. 7819 Variations such as what routing protocol to use, or whether to 7820 instantiate an ACP in a VRF or (as suggested above) as the actual 7821 Data-Plane, can be automatically chosen in implementations built to 7822 support multiple options by deriving them from future parameters in 7823 the certificate. Parameters in certificates should be limited to 7824 those that would not need to be changed more often than certificates 7825 would need to be updated anyhow; Or by ensuring that these parameters 7826 can be provisioned before the variation of an ACP is activated in a 7827 node. Using BRSKI, this could be done for example as additional 7828 follow-up signaling directly after the certificate enrollment, still 7829 leveraging the BRSKI TLS connection and therefore not introducing any 7830 additional connectivity requirements. 7832 Last but not least, secure channel protocols including their 7833 encapsulations are easily added to ACP solutions. ACP hop-by-hop 7834 network layer secure channels could also be replaced by end-to-end 7835 security plus other means for infrastructure protection. Any future 7836 network OAM should always use end-to-end security anyhow and can 7837 leverage the domain certificates and is therefore not dependent on 7838 security to be provided for by ACP secure channels. 7840 A.9. Further (future) options 7842 A.9.1. Auto-aggregation of routes 7844 Routing in the ACP according to this specification only leverages the 7845 standard RPL mechanism of route optimization, e.g. keeping only 7846 routes that are not towards the RPL root. This is known to scale to 7847 networks with 20,000 or more nodes. There is no auto-aggregation of 7848 routes for /48 ULA prefixes (when using rsub in the acp-node-name) 7849 and/or Zone-ID based prefixes. 7851 Automatic assignment of Zone-ID and auto-aggregation of routes could 7852 be achieved for example by configuring zone-boundaries, announcing 7853 via GRASP into the zones the zone parameters (zone-ID and /48 ULA 7854 prefix) and auto-aggregating routes on the zone-boundaries. Nodes 7855 would assign their Zone-ID and potentially even /48 prefix based on 7856 the GRASP announcements. 7858 A.9.2. More options for avoiding IPv6 Data-Plane dependencies 7860 As described in Section 6.13.2, the ACP depends on the Data-Plane to 7861 establish IPv6 link-local addressing on interfaces. Using a separate 7862 MAC address for the ACP allows to fully isolate the ACP from the 7863 Data-Plane in a way that is compatible with this specification. It 7864 is also an ideal option when using Single-root input/output 7865 virtualization (SR-IOV - see https://en.wikipedia.org/wiki/Single- 7866 root_input/output_virtualization) in an implementation to isolate the 7867 ACP because different SR-IOV interfaces use different MAC addresses. 7869 When additional MAC address(es) are not available, separation of the 7870 ACP could be done at different demux points. The same subnet 7871 interface could have a separate IPv6 interface for the ACP and Data- 7872 Plane and therefore separate link-local addresses for both, where the 7873 ACP interface is non-configurable on the Data-Plane. This too would 7874 be compatible with this specification and not impact 7875 interoperability. 7877 An option that would require additional specification is to use a 7878 different Ethertype from 0x86DD (IPv6) to encapsulate IPv6 packets 7879 for the ACP. This would be a similar approach as used for IP 7880 authentication packets in [IEEE-802.1X] which use the Extensible 7881 Authentication Protocol over Local Area Network (EAPoL) ethertype 7882 (0x88A2). 7884 Note that in the case of ANI nodes, all the above considerations 7885 equally apply to the encapsulation of BRSKI packets including GRASP 7886 used for BRSKI. 7888 A.9.3. ACP APIs and operational models (YANG) 7890 Future work should define YANG ([RFC7950]) data model and/or node 7891 internal APIs to monitor and manage the ACP. 7893 Support for the ACP Adjacency Table (Section 6.3) and ACP GRASP need 7894 to be included into such model/API. 7896 A.9.4. RPL enhancements 7898 ..... USA ...... ..... Europe ...... 7900 NOC1 NOC2 7901 | | 7902 | metric 100 | 7903 ACP1 --------------------------- ACP2 . 7904 | | . WAN 7905 | metric 10 metric 20 | . Core 7906 | | . 7907 ACP3 --------------------------- ACP4 . 7908 | metric 100 | 7909 | | . 7910 | | . Sites 7911 ACP10 ACP11 . 7913 Figure 19: Dual NOC 7915 The profile for RPL specified in this document builds only one 7916 spanning-tree path set to a root, typically a registrar in one NOC. 7917 In the presence of multiple NOCs, routing toward the non-root NOCs 7918 may be suboptimal. Figure 19 shows an extreme example. Assuming 7919 that node ACP1 becomes the RPL root, traffic between ACP11 and NOC2 7920 will pass through ACP4-ACP3-ACP1-ACP2 instead of ACP4-ACP2 because 7921 the RPL calculated DODAG/routes are shortest paths towards the RPL 7922 root. 7924 To overcome these limitations, extensions/modifications to the RPL 7925 profile can provide optimality for multiple NOCs. This requires 7926 utilizing Data-Plane artifact including IPinIP encap/decap on ACP 7927 routers and processing of IPv6 RPI headers. Alternatively, (Src,Dst) 7928 routing table entries could be used. 7930 Flooding of ACP GRASP messages can be further constrained and 7931 therefore optimized by flooding only via links that are part of the 7932 RPL DODAG. 7934 A.9.5. Role assignments 7936 ACP connect is an explicit mechanism to "leak" ACP traffic explicitly 7937 (for example in a NOC). It is therefore also a possible security gap 7938 when it is easy to enable ACP connect on arbitrary compromised ACP 7939 nodes. 7941 One simple solution is to define an extension in the ACP certificates 7942 ACP information field indicating the permission for ACP connect to be 7943 configured on that ACP node. This could similarly be done to decide 7944 whether a node is permitted to be a registrar or not. 7946 Tying the permitted "roles" of an ACP node to the ACP certificate 7947 provides fairly strong protection against misconfiguration, but is 7948 still subject to code modifications. 7950 Another interesting role to assign to certificates is that of a NOC 7951 node. This would allow to limit certain type of connections such as 7952 OAM TLS connections to only NOC initiator or responders. 7954 A.9.6. Autonomic L3 transit 7956 In this specification, the ACP can only establish autonomic 7957 connectivity across L2 hops and only explicitly configured options to 7958 tunnel across L3. Future work should specify mechanisms to 7959 automatically tunnel ACP across L3 networks. A hub&spoke option 7960 would allow to tunnel across the Internet to a cloud or central 7961 instance of the ACP, a peer-to-peer tunneling mechanism could tunnel 7962 ACP islands across an L3VPN infrastructure. 7964 A.9.7. Diagnostics 7966 Section 9.1 describes diagnostics options that can be done without 7967 changing the external, interoperability affecting characteristics of 7968 ACP implementations. 7970 Even better diagnostics of ACP operations is possible with additional 7971 signaling extensions, such as: 7973 1. Consider if LLDP should be a recommended functionality for ANI 7974 devices to improve diagnostics, and if so, which information 7975 elements it should signal (noting that such information is 7976 conveyed in an insecure manner). Includes potentially new 7977 information elements. 7978 2. In alternative to LLDP, A DULL GRASP diagnostics objective could 7979 be defined to carry these information elements. 7980 3. The IDevID certificate of BRSKI pledges should be included in the 7981 selected insecure diagnostics option. This may be undesirable 7982 when exposure of device information is seen as too much of a 7983 security issue (ability to deduce possible attack vectors from 7984 device model for example). 7985 4. A richer set of diagnostics information should be made available 7986 via the secured ACP channels, using either single-hop GRASP or 7987 network wide "topology discovery" mechanisms. 7989 A.9.8. Avoiding and dealing with compromised ACP nodes 7991 Compromised ACP nodes pose the biggest risk to the operations of the 7992 network. The most common type of compromise is leakage of 7993 credentials to manage/configure the device and the application of 7994 malicious configuration including the change of access credentials, 7995 but not the change of software. Most of today's networking equipment 7996 should have secure boot/software infrastructure anyhow, so attacks 7997 that introduce malicious software should be a lot harder. 7999 The most important aspect of security design against these type of 8000 attacks is to eliminate password based configuration access methods 8001 and instead rely on certificate based credentials handed out only to 8002 nodes where it is clear that the private keys cannot leak. This 8003 limits unexpected propagation of credentials. 8005 If password based credentials to configure devices still need to be 8006 supported, they must not be locally configurable, but only be 8007 remotely provisioned or verified (through protocols like RADIUS or 8008 Diameter), and there must be no local configuration permitting to 8009 change these authentication mechanisms, but ideally they should be 8010 autoconfiguring across the ACP. See 8011 [I-D.eckert-anima-noc-autoconfig]. 8013 Without physical access to the compromised device, attackers with 8014 access to configuration should not be able to break the ACP 8015 connectivity, even when they can break or otherwise manipulate 8016 (spoof) the Data-Plane connectivity through configuration. To 8017 achieve this, it is necessary to avoid providing configuration 8018 options for the ACP, such as enabling/disabling it on interfaces. 8019 For example, there could be an ACP configuration that locks down the 8020 current ACP config unless factory reset is done. 8022 With such means, the valid administration has the best chances to 8023 maintain access to ACP nodes, discover malicious configuration though 8024 ongoing configuration tracking from central locations for example, 8025 and to react accordingly. 8027 The primary reaction is withdrawal/change of credentials, terminate 8028 malicious existing management sessions and fixing the configuration. 8029 Ensuring that management sessions using invalidated credentials are 8030 terminated automatically without recourse will likely require new 8031 work. 8033 Only when these steps are not feasible would it be necessary to 8034 revoke or expire the ACP certificate credentials and consider the 8035 node kicked off the network - until the situation can be further 8036 rectified, likely requiring direct physical access to the node. 8038 Without extensions, compromised ACP nodes can only be removed from 8039 the ACP at the speed of CRL/OCSP information refresh or expiry (and 8040 non-removal) of short lived certificates. Future extensions to the 8041 ACP could for example use GRASP flooding distribution of triggered 8042 updates of CRL/OCSP or explicit removal indication of the compromised 8043 nodes domain certificate. 8045 A.9.9. Detecting ACP secure channel downgrade attacks 8047 The following text proposes a mechanism to protect against downgrade 8048 attacks without introducing a new specialized UPFRONT GRASP secure 8049 channel mechanism. Instead, it relies on running GRASP after 8050 establishing a secure channel protocol to verify if the established 8051 secure channel option could have been the result of a MITM downgrade 8052 attack: 8054 MITM attackers can force downgrade attacks for ACP secure channel 8055 selection by filtering/modifying DULL GRASP messages and/or actual 8056 secure channel data packets. For example, if at some point in time 8057 DTLS traffic could be easier decrypted than traffic of IKEv2, the 8058 MITM could filter all IKEv2 packets to force ACP nodes to use DTLS 8059 (assuming the ACP nodes in question supported both DTLS and IKEv2). 8061 For cases where such MITM attacks are not capable to inject malicious 8062 traffic (but only to decrypt the traffic), a downgrade attack could 8063 be discovered after a secure channel connection is established, for 8064 example by use of the following type of mechanism: 8066 After the secure channel connection is established, the two ACP peers 8067 negotiate via an appropriate (To Be Defined) GRASP negotiation which 8068 ACP secure channel protocol should have been selected between them 8069 (in the absence of a MITM attacker). This negotiation would have to 8070 signal the DULL GRASP announced ACP secure channel options by each 8071 peer followed by an announcement of the preferred secure channel 8072 protocol by the ACP peer that is the Decider in the secure channel 8073 setup, e.g. the ACP peer that is deciding which secure channel 8074 protocol to pick. If that chosen secure channel protocol is 8075 different from the one that actually was chosen, then this mismatch 8076 is an indication that there is a MITM attacker or other similar issue 8077 (firewall prohibiting the use of specific protocols) that caused a 8078 non-preferred secure channel protocol to be chosen. This discovery 8079 could then result in mitigation options such as logging and ensuing 8080 investigations. 8082 Appendix B. Unfinished considerations (To Be Removed From RFC) 8084 [RFC-Editor: This whole appendix B. and its subsections to be removed 8085 for the RFC. 8087 This appendix contains unfinished considerations that are removed 8088 from the RFC, they are maintained in this draft as a log of the state 8089 of discussion and point of reference. Together with this appendix, 8090 also the references pointing to it are marked to be removed from the 8091 RFC because no consensus could be reached that a self-reference to a 8092 draft version of the RFC is an appropriate breadcrumb to point to 8093 unfinished considerations. 8095 The authors plan to move these considerations into a new target 8096 informational draft, please look for draft-eckert-anima-acp- 8097 considerations. 8099 B.1. Considerations for improving secure channel negotiation 8101 Proposed text from Benjamin Kaduk. It is suggested to replace the 8102 text of appendix A.6 in previous versions of this draft (up to 8103 version 29). 8105 The discovery procedure in this specification for low-level ACP 8106 channel support by layer-2 peers involves DULL GRASP and attempting 8107 (usually in parallel) to establish all supported channel types, 8108 learning the peer ACP address and correspondingly the assignment of 8109 Decider and Follower roles, and tearing down all channels other than 8110 the one preferred by the Decider. This procedure, in general, 8111 becomes resource intensive as the number of possible secure channels 8112 grows; even worse, under some threat models, the security of the 8113 discovery result is only as strong as the weakest supported secure 8114 channel protocol. Furthermore, the unilateral determination of 8115 "best" channel type by the Decider does not result in the optimal 8116 outcome in all possible scenarios. 8118 This situation is tolerable at present, with only two secure channels 8119 (DTLS and IPsec) defined, but long-term agility in the vein of 8120 [BCP201] will require the introduction of an alternate discovery/ 8121 negotiation procedure. While IKEv2 is the IETF standard protocol for 8122 negotiating security associations, it currently does not have a 8123 defined mechanism flexible enough to negotiate the parameters needed 8124 for, e.g., an ACP DTLS channel, let alone for allowing ACP peers to 8125 indicate their preference metrics for channel selection. Such a 8126 mechanism or mechanisms could be defined, but if ACP agility requires 8127 introducing a new channel type, for example MacSec, IKEv2 would again 8128 need to be extended in order to negotiate an ACP MacSec association. 8129 Making ACP channel agility dependent on updates to IKEv2 is likely to 8130 result in obstacles due to different timescales of evolution, since 8131 IKEv2 implementations help form the core of Internet-scale security 8132 infrastructure and must accordingly be robust and thoroughly tested. 8134 Accordingly, a dedicated ACP channel negotiation mechanism is 8135 appropriate as a way to provide long-term algorithm and secure- 8136 channel protocol agility. Such a mechanism is not currently defined, 8137 but one possible design is as follows. A new DULL GRASP objective is 8138 defined to indicate the GRASP-over-TLS channel, which is by 8139 definition preferred to other channel types (including DTLS and 8140 IPsec). When both peers advertise support for GRASP-over-TLS, GRASP- 8141 over-TLS must run to completion before other channel types are 8142 attempted. The GRASP-over-TLS channel performs the necessary 8143 negotiation by establishing a TLS connection between the peers and 8144 using that connection to secure a dedicated GRASP instance for 8145 negotiating supported channel types and preference metrics. This 8146 provides a rich language for determining what secure channel protocol 8147 to use for the ACP link while taking into account the capabilities 8148 and preferences of the ACP peers, all protected by the security of 8149 the TLS channel. 8151 B.2. ACP address verification 8153 The AcpNodeName of most ACP nodes contains in the acp-address field 8154 the primary ACP address to be used by the node for end-to-end 8155 connections across ACP secure channels. Nevertheless, there is no 8156 verification of an ACP peers address specified in this document. 8157 This section explains the current understanding as to why this is not 8158 done. 8160 Not all ACP nodes will have an actual IPv6 address in the acp-address 8161 field of their AcpNodeName. Those who do not include nodes that do 8162 not support ACP secure channels, such as pre-existing NOC equipment 8163 that only connects to the ACP via ACP connect interfaces. Likewise, 8164 future ACP node type that may want to have their Node-ID not be 8165 defined by an ACP registrar, but differently cannot have the ACP 8166 address be provided in their ACP certificate where it would be 8167 defined by the registrar. In result, any scheme that would rely on 8168 verification of the acp-address in the ACP certificate would only 8169 apply to a subset of ACP nodes. 8171 The transport stack network layer address used for ACP secure 8172 channels is not the acp-address. For automatically established ACP 8173 secure channels, it is a link-local IPv6 address. For explicitly 8174 configured ACP secure channels (to reach across non ACP L3 network 8175 segments), the address is any IPv4 or IPv6 address routable to that 8176 remote destination. 8178 When the acp-address is actually used across the ACP, it can only be 8179 verified by a peer when the peer has the certificate of the peer. 8180 Unless further higher layer mechanisms are developed on top of the 8181 ACP (for example via ASA), the only mechanism to access a peers ACP 8182 certificate is for secure connections in which the peers certificates 8183 are exchanged and cryptographically verified, e.g. TLS and DTLS. 8184 Initially, it is expected that the ACP will carry many legacy network 8185 management control connections that unfortunately not end-to-end 8186 authenticated but that are solely protected by being carried across 8187 the ACP secure channels. ACP address verification therefore cannot 8188 be used for such connections without additional higher layer 8189 components. 8191 For the remaining (TLS/DTLS) connections for which address 8192 verification can be used, the main question is: what additional 8193 benefit would address verification provide? 8195 The main value that transport stack network layer address 8196 verification could provide for these type of connections would be the 8197 discovery of on-path transport proxies. For example, in case of 8198 BRSKI, pledges connect to an ACP registrar via an ASA implementing a 8199 TCP proxy because the pledge itself has at that point in time no ACP 8200 certificate valid to build ACP secure channels and hence needs to 8201 rely on such a proxy. This is one example where such a TCP proxy is 8202 required and not a form of attack. 8204 In general, on path TCP proxies could be a form of attack, but it 8205 stands to reason, that an attacker that manages to enable a malicious 8206 TCP proxy could likely equally build a transparent proxy not changing 8207 the network layer addresses. Only when the attacker operates off- 8208 path would this option not be possible. Such attacks could indeed be 8209 possible: An impaired ACP node could announce itself as another 8210 service instance for a service whose utilization it wants to attack. 8211 It could then attempt to look like a valid server by simply TCP 8212 proxying the clients connections to a valid server and then attack 8213 the connections passing through it (passive decrypting or passive 8214 fingerprint analysis). But like the BRSKI proxy, this behavior could 8215 be perfectly legitimate and not an attack. For example, TCP has in 8216 the past often suffered from performance issues across difficult 8217 (high capacity, high loss) paths, and TCP proxies where and are being 8218 used simply as a tool for isolating such path segments (such as a 8219 WAN), and providing caching and local-retransmit of in-transit 8220 packets, reducing the effective path segment capacity. 8222 As explained elsewhere in this document already, considerations for 8223 these type of attack are therefore outside the scope of the ACP but 8224 fundametal to further design of the ASA infrastructure. Beyond 8225 distinguishing whether a TCP proxy would be beneficial or malicious, 8226 the even more fundamental question is how to determine from a 8227 multitude of service announcements which instance is the most 8228 trustworthy and functionally best. In the Internet/web, this 8229 question is NOT solved inside the network but through off-net human 8230 interaction ("trust me, the best search engine is www..com"). 8233 B.3. Public CA considerations 8235 Public CAs are outside the scope of this document for the following 8236 reasons. This appendix describes the current state of understanding 8237 for those interested to consider utilizing public CA for the ACP in 8238 the future. 8240 If public CA where to be used to enroll ACP nodes and act as TA, this 8241 would require a model in which the public CA would be able to assert 8242 the ownership of the information requested in the certificate, 8243 especially the AcpNodeName, for example mitigated by the domain 8244 registrar(s). Due to the use of a new, ACP unique encoding of the 8245 AcpNodeName, there is no mechanism for public CA to do so. More 8246 importantly though, isolation between ACPs of disjoint operated ACPs 8247 is achieved in the current ACP design through disjoint TA. A public 8248 CA is in general based on a single (set of) TA shared across all 8249 certificates signed by the CA. 8251 Due to the fact that the ACP domain membership check also validates 8252 that a peers domain name in the AcpNodeName matches that of the ACP 8253 node itself, it would be possible to use the same TA across disjoint 8254 ACP domains, but the security and attack implications of such an 8255 approach are beyond the scope of this document. 8257 The use of ULA addresses in the AcpNodeName is another novel aspect 8258 for certificates from a possible public CA. Typically, ULA addresses 8259 are not meant to be signed by a public CA when carried in an address 8260 field, because there is no ownership of a particular ULA address in 8261 the scope of the Internet, which is what public CA operate on. 8263 Nevertheless, the ULA addresses used by the ACP are scoped to be 8264 valid only within the confines of a specific ACP as defined by the 8265 domain name in the AcpNodeName. However, this understanding has not 8266 been reviewed or accepted by any bodies responsible for policies of 8267 public CA. 8269 Because in this specification, ACPs are isolated from each other 8270 primarily by their TA, when a public CA would intend to sign ACP 8271 certificates and using a single TA to sign TA of ACP certificates 8272 from different operators/domain, it could do so by ensuring that the 8273 domain name in the AcpNodeName was a globally owned DNS ACP domain 8274 name of the organization, and beyond that, it would need to validate 8275 that the ACP registrar of that domain who is mitigating the 8276 enrollment is authorized to vouch for the ownership of the acp- 8277 address within the scope of the ACP domain name. 8279 B.4. Hardening DULL GRASP considerations 8281 DULL GRASP suffers from similar type of DoS attacks as many link- 8282 local multicast discovery protocols, for example mDNS. Attackers on 8283 a subnet may be able to inject malicious DULL GRASP messages that are 8284 indistinguishable from non-malicious DULL GRASP messages to create 8285 Denial-of-Service (DoS) attacks that force ACP nodes to attempt many 8286 unsuccessful ACP secure channel connections. 8288 When an ACP node sees multiple AN_ACP objectives for the same secure 8289 channel protocol on different transport addresses, it could prefer 8290 connecting via the well-known transport address if the secure channel 8291 method has one, such as UDP port 500 for IKEv2. For protocols such 8292 as (ACP secure channel over) DTLS for which there are no well defined 8293 port number, this heuristic does not provide benefits though. 8295 DoS attack with port numbers can also be eliminated by relying on 8296 well known-port numbers implied by the GRASP method-name. For 8297 example, a future service name of "DTLSacp" could be defined to be 8298 associated only to a newly to be assigned well known UDP port for ACP 8299 over DTLS, and the port number in the GRASP transport address 8300 information would be ignored. Note that there is already a variety 8301 of ports assigned to specific protocols over DTLS by IANA, so 8302 especially for DTLS this would not be uncommon. 8304 Authors' Addresses 8305 Toerless Eckert (editor) 8306 Futurewei Technologies Inc. USA 8307 2330 Central Expy 8308 Santa Clara, 95050 8309 United States of America 8311 Email: tte+ietf@cs.fau.de 8313 Michael H. Behringer (editor) 8315 Email: michael.h.behringer@gmail.com 8317 Steinthor Bjarnason 8318 Arbor Networks 8319 2727 South State Street, Suite 200 8320 Ann Arbor, MI 48104 8321 United States 8323 Email: sbjarnason@arbor.net