idnits 2.17.1 draft-ietf-anima-autonomic-control-plane-28.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 22 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 1216 has weird spacing: '...address of f...' == Line 2707 has weird spacing: '...k-local unic...' == Line 2708 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 (July 28, 2020) is 1368 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 485, but not defined -- Looks like a reference, but probably isn't: '1' on line 6954 -- Looks like a reference, but probably isn't: '2' on line 7528 -- Looks like a reference, but probably isn't: '3' on line 2121 -- Looks like a reference, but probably isn't: '5' on line 2127 -- Looks like a reference, but probably isn't: '9' on line 2138 -- Looks like a reference, but probably isn't: '13' on line 2156 == Missing Reference: 'ACP VRF' is mentioned on line 4100, but not defined == Missing Reference: 'Data-Plane' is mentioned on line 4102, but not defined == Missing Reference: 'Select' is mentioned on line 4269, but not defined == Missing Reference: 'Plane' is mentioned on line 4271, but not defined == Unused Reference: 'RFC1034' is defined on line 6464, but no explicit reference was found in the text == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-41 -- 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 4492 (Obsoleted by RFC 8422) -- 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 (~~), 15 warnings (==), 17 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: January 29, 2021 6 S. Bjarnason 7 Arbor Networks 8 July 28, 2020 10 An Autonomic Control Plane (ACP) 11 draft-ietf-anima-autonomic-control-plane-28 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 January 29, 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 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction (Informative) . . . . . . . . . . . . . . . . . 6 62 1.1. Applicability and Scope . . . . . . . . . . . . . . . . . 9 63 2. Acronyms and Terminology (Informative) . . . . . . . . . . . 10 64 3. Use Cases for an Autonomic Control Plane (Informative) . . . 17 65 3.1. An Infrastructure for Autonomic Functions . . . . . . . . 17 66 3.2. Secure Bootstrap over a not configured Network . . . . . 17 67 3.3. Data-Plane Independent Permanent Reachability . . . . . . 18 68 4. Requirements (Informative) . . . . . . . . . . . . . . . . . 19 69 5. Overview (Informative) . . . . . . . . . . . . . . . . . . . 20 70 6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 22 71 6.1. ACP Domain, Certificate and Network . . . . . . . . . . . 23 72 6.1.1. ACP Certificates . . . . . . . . . . . . . . . . . . 24 73 6.1.2. ACP Certificate AcpNodeName . . . . . . . . . . . . . 26 74 6.1.2.1. AcpNodeName ASN.1 Module . . . . . . . . . . . . 29 75 6.1.3. ACP domain membership check . . . . . . . . . . . . . 30 76 6.1.3.1. Realtime clock and Time Validation . . . . . . . 32 77 6.1.4. Trust Anchors (TA) . . . . . . . . . . . . . . . . . 33 78 6.1.5. Certificate and Trust Anchor Maintenance . . . . . . 34 79 6.1.5.1. GRASP objective for EST server . . . . . . . . . 35 80 6.1.5.2. Renewal . . . . . . . . . . . . . . . . . . . . . 36 81 6.1.5.3. Certificate Revocation Lists (CRLs) . . . . . . . 37 82 6.1.5.4. Lifetimes . . . . . . . . . . . . . . . . . . . . 37 83 6.1.5.5. Re-enrollment . . . . . . . . . . . . . . . . . . 38 84 6.1.5.6. Failing Certificates . . . . . . . . . . . . . . 39 85 6.2. ACP Adjacency Table . . . . . . . . . . . . . . . . . . . 40 86 6.3. Neighbor Discovery with DULL GRASP . . . . . . . . . . . 40 87 6.4. Candidate ACP Neighbor Selection . . . . . . . . . . . . 44 88 6.5. Channel Selection . . . . . . . . . . . . . . . . . . . . 44 89 6.6. Candidate ACP Neighbor verification . . . . . . . . . . . 48 90 6.7. Security Association (Secure Channel) protocols . . . . . 48 91 6.7.1. General considerations . . . . . . . . . . . . . . . 49 92 6.7.2. Common requirements . . . . . . . . . . . . . . . . . 49 93 6.7.3. ACP via IPsec . . . . . . . . . . . . . . . . . . . . 51 94 6.7.3.1. Native IPsec . . . . . . . . . . . . . . . . . . 51 95 6.7.3.1.1. RFC8221 (IPsec/ESP) . . . . . . . . . . . . . 51 96 6.7.3.1.2. RFC8247 (IKEv2) . . . . . . . . . . . . . . . 53 98 6.7.3.2. IPsec with GRE encapsulation . . . . . . . . . . 54 99 6.7.4. ACP via DTLS . . . . . . . . . . . . . . . . . . . . 55 100 6.7.5. ACP Secure Channel Profiles . . . . . . . . . . . . . 56 101 6.8. GRASP in the ACP . . . . . . . . . . . . . . . . . . . . 57 102 6.8.1. GRASP as a core service of the ACP . . . . . . . . . 57 103 6.8.2. ACP as the Security and Transport substrate for GRASP 58 104 6.8.2.1. Discussion . . . . . . . . . . . . . . . . . . . 61 105 6.9. Context Separation . . . . . . . . . . . . . . . . . . . 62 106 6.10. Addressing inside the ACP . . . . . . . . . . . . . . . . 62 107 6.10.1. Fundamental Concepts of Autonomic Addressing . . . . 62 108 6.10.2. The ACP Addressing Base Scheme . . . . . . . . . . . 64 109 6.10.3. ACP Zone Addressing Sub-Scheme (ACP-Zone) . . . . . 65 110 6.10.4. ACP Manual Addressing Sub-Scheme (ACP-Manual) . . . 67 111 6.10.5. ACP Vlong Addressing Sub-Scheme (ACP-VLong-8/ACP- 112 VLong-16 . . . . . . . . . . . . . . . . . . . . . . 68 113 6.10.6. Other ACP Addressing Sub-Schemes . . . . . . . . . . 69 114 6.10.7. ACP Registrars . . . . . . . . . . . . . . . . . . . 70 115 6.10.7.1. Use of BRSKI or other Mechanism/Protocols . . . 70 116 6.10.7.2. Unique Address/Prefix allocation . . . . . . . . 71 117 6.10.7.3. Addressing Sub-Scheme Policies . . . . . . . . . 72 118 6.10.7.4. Address/Prefix Persistence . . . . . . . . . . . 73 119 6.10.7.5. Further Details . . . . . . . . . . . . . . . . 73 120 6.11. Routing in the ACP . . . . . . . . . . . . . . . . . . . 73 121 6.11.1. ACP RPL Profile . . . . . . . . . . . . . . . . . . 74 122 6.11.1.1. Overview . . . . . . . . . . . . . . . . . . . . 74 123 6.11.1.1.1. Single Instance . . . . . . . . . . . . . . 74 124 6.11.1.1.2. Reconvergence . . . . . . . . . . . . . . . 75 125 6.11.1.2. RPL Instances . . . . . . . . . . . . . . . . . 76 126 6.11.1.3. Storing vs. Non-Storing Mode . . . . . . . . . . 76 127 6.11.1.4. DAO Policy . . . . . . . . . . . . . . . . . . . 76 128 6.11.1.5. Path Metric . . . . . . . . . . . . . . . . . . 76 129 6.11.1.6. Objective Function . . . . . . . . . . . . . . . 76 130 6.11.1.7. DODAG Repair . . . . . . . . . . . . . . . . . . 76 131 6.11.1.8. Multicast . . . . . . . . . . . . . . . . . . . 77 132 6.11.1.9. Security . . . . . . . . . . . . . . . . . . . . 77 133 6.11.1.10. P2P communications . . . . . . . . . . . . . . . 77 134 6.11.1.11. IPv6 address configuration . . . . . . . . . . . 77 135 6.11.1.12. Administrative parameters . . . . . . . . . . . 78 136 6.11.1.13. RPL Packet Information . . . . . . . . . . . . . 78 137 6.11.1.14. Unknown Destinations . . . . . . . . . . . . . . 78 138 6.12. General ACP Considerations . . . . . . . . . . . . . . . 79 139 6.12.1. Performance . . . . . . . . . . . . . . . . . . . . 79 140 6.12.2. Addressing of Secure Channels . . . . . . . . . . . 79 141 6.12.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . 80 142 6.12.4. Multiple links between nodes . . . . . . . . . . . . 80 143 6.12.5. ACP interfaces . . . . . . . . . . . . . . . . . . . 80 144 6.12.5.1. ACP loopback interfaces . . . . . . . . . . . . 80 145 6.12.5.2. ACP virtual interfaces . . . . . . . . . . . . . 83 146 6.12.5.2.1. ACP point-to-point virtual interfaces . . . 83 147 6.12.5.2.2. ACP multi-access virtual interfaces . . . . 83 148 7. ACP support on L2 switches/ports (Normative) . . . . . . . . 85 149 7.1. Why (Benefits of ACP on L2 switches) . . . . . . . . . . 86 150 7.2. How (per L2 port DULL GRASP) . . . . . . . . . . . . . . 87 151 8. Support for Non-ACP Components (Normative) . . . . . . . . . 88 152 8.1. ACP Connect . . . . . . . . . . . . . . . . . . . . . . . 88 153 8.1.1. Non-ACP Controller / NMS system . . . . . . . . . . . 88 154 8.1.2. Software Components . . . . . . . . . . . . . . . . . 91 155 8.1.3. Auto Configuration . . . . . . . . . . . . . . . . . 92 156 8.1.4. Combined ACP/Data-Plane Interface (VRF Select) . . . 93 157 8.1.5. Use of GRASP . . . . . . . . . . . . . . . . . . . . 94 158 8.2. Connecting ACP islands over Non-ACP L3 networks (Remote 159 ACP neighbors) . . . . . . . . . . . . . . . . . . . . . 95 160 8.2.1. Configured Remote ACP neighbor . . . . . . . . . . . 95 161 8.2.2. Tunneled Remote ACP Neighbor . . . . . . . . . . . . 96 162 8.2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 97 163 9. ACP Operations (Informative) . . . . . . . . . . . . . . . . 97 164 9.1. ACP (and BRSKI) Diagnostics . . . . . . . . . . . . . . . 98 165 9.1.1. Secure Channel Peer diagnostics . . . . . . . . . . . 102 166 9.2. ACP Registrars . . . . . . . . . . . . . . . . . . . . . 103 167 9.2.1. Registrar interactions . . . . . . . . . . . . . . . 103 168 9.2.2. Registrar Parameter . . . . . . . . . . . . . . . . . 104 169 9.2.3. Certificate renewal and limitations . . . . . . . . . 105 170 9.2.4. ACP Registrars with sub-CA . . . . . . . . . . . . . 106 171 9.2.5. Centralized Policy Control . . . . . . . . . . . . . 106 172 9.3. Enabling and disabling ACP/ANI . . . . . . . . . . . . . 107 173 9.3.1. Filtering for non-ACP/ANI packets . . . . . . . . . . 107 174 9.3.2. Admin Down State . . . . . . . . . . . . . . . . . . 108 175 9.3.2.1. Security . . . . . . . . . . . . . . . . . . . . 109 176 9.3.2.2. Fast state propagation and Diagnostics . . . . . 109 177 9.3.2.3. Low Level Link Diagnostics . . . . . . . . . . . 110 178 9.3.2.4. Power Consumption Issues . . . . . . . . . . . . 111 179 9.3.3. Interface level ACP/ANI enable . . . . . . . . . . . 111 180 9.3.4. Which interfaces to auto-enable? . . . . . . . . . . 111 181 9.3.5. Node Level ACP/ANI enable . . . . . . . . . . . . . . 113 182 9.3.5.1. Brownfield nodes . . . . . . . . . . . . . . . . 113 183 9.3.5.2. Greenfield nodes . . . . . . . . . . . . . . . . 114 184 9.3.6. Undoing ANI/ACP enable . . . . . . . . . . . . . . . 114 185 9.3.7. Summary . . . . . . . . . . . . . . . . . . . . . . . 115 186 9.4. Partial or Incremental adoption . . . . . . . . . . . . . 115 187 9.5. Configuration and the ACP (summary) . . . . . . . . . . . 116 188 10. Summary: Benefits (Informative) . . . . . . . . . . . . . . . 117 189 10.1. Self-Healing Properties . . . . . . . . . . . . . . . . 118 190 10.2. Self-Protection Properties . . . . . . . . . . . . . . . 119 191 10.2.1. From the outside . . . . . . . . . . . . . . . . . . 119 192 10.2.2. From the inside . . . . . . . . . . . . . . . . . . 120 193 10.3. The Administrator View . . . . . . . . . . . . . . . . . 121 195 11. Security Considerations . . . . . . . . . . . . . . . . . . . 122 196 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 125 197 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 125 198 14. Change log [RFC Editor: Please remove] . . . . . . . . . . . 126 199 14.1. Summary of changes since entering IESG review . . . . . 126 200 14.1.1. Reviews (while in IESG review status) / status . . . 126 201 14.1.2. BRSKI / ACP registrar related enhancements . . . . . 127 202 14.1.3. Normative enhancements since start of IESG review . 127 203 14.1.4. Explanatory enhancements since start of IESG review 128 204 14.2. draft-ietf-anima-autonomic-control-plane-28 . . . . . . 129 205 14.3. draft-ietf-anima-autonomic-control-plane-27 . . . . . . 130 206 14.4. draft-ietf-anima-autonomic-control-plane-26 . . . . . . 130 207 14.5. draft-ietf-anima-autonomic-control-plane-25 . . . . . . 131 208 14.6. draft-ietf-anima-autonomic-control-plane-24 . . . . . . 135 209 14.7. draft-ietf-anima-autonomic-control-plane-23 . . . . . . 135 210 14.8. draft-ietf-anima-autonomic-control-plane-22 . . . . . . 136 211 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 138 212 15.1. Normative References . . . . . . . . . . . . . . . . . . 138 213 15.2. Informative References . . . . . . . . . . . . . . . . . 142 214 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 149 215 Appendix A. Background and Futures (Informative) . . . . . . . . 150 216 A.1. ACP Address Space Schemes . . . . . . . . . . . . . . . . 150 217 A.2. BRSKI Bootstrap (ANI) . . . . . . . . . . . . . . . . . . 150 218 A.3. ACP Neighbor discovery protocol selection . . . . . . . . 152 219 A.3.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 152 220 A.3.2. mDNS and L2 support . . . . . . . . . . . . . . . . . 152 221 A.3.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 152 222 A.4. Choice of routing protocol (RPL) . . . . . . . . . . . . 153 223 A.5. ACP Information Distribution and multicast . . . . . . . 154 224 A.6. Extending ACP channel negotiation (via GRASP) . . . . . . 155 225 A.7. CAs, domains and routing subdomains . . . . . . . . . . . 157 226 A.8. Intent for the ACP . . . . . . . . . . . . . . . . . . . 158 227 A.9. Adopting ACP concepts for other environments . . . . . . 159 228 A.10. Further (future) options . . . . . . . . . . . . . . . . 161 229 A.10.1. Auto-aggregation of routes . . . . . . . . . . . . . 161 230 A.10.2. More options for avoiding IPv6 Data-Plane dependency 161 231 A.10.3. ACP APIs and operational models (YANG) . . . . . . . 162 232 A.10.4. RPL enhancements . . . . . . . . . . . . . . . . . . 162 233 A.10.5. Role assignments . . . . . . . . . . . . . . . . . . 163 234 A.10.6. Autonomic L3 transit . . . . . . . . . . . . . . . . 163 235 A.10.7. Diagnostics . . . . . . . . . . . . . . . . . . . . 164 236 A.10.8. Avoiding and dealing with compromised ACP nodes . . 164 237 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 165 239 1. Introduction (Informative) 241 Autonomic Networking is a concept of self-management: Autonomic 242 functions self-configure, and negotiate parameters and settings 243 across the network. [RFC7575] defines the fundamental ideas and 244 design goals of Autonomic Networking. A gap analysis of Autonomic 245 Networking is given in [RFC7576]. The reference architecture for 246 Autonomic Networking in the IETF is specified in the document 247 [I-D.ietf-anima-reference-model]. 249 Autonomic functions need an autonomically built communications 250 infrastructure. This infrastructure needs to be secure, resilient 251 and re-usable by all autonomic functions. Section 5 of [RFC7575] 252 introduces that infrastructure and calls it the Autonomic Control 253 Plane (ACP). More descriptively it would be the "Autonomic 254 communications infrastructure for OAM and Control". For naming 255 consistency with that prior document, this document continues to use 256 the name ACP though. 258 Today, the OAM and control plane of IP networks is what is typically 259 called in-band management/signaling: Its management and control 260 protocol traffic depends on the routing and forwarding tables, 261 security, policy, QoS and potentially other configuration that first 262 has to be established through the very same management and control 263 protocols. Misconfigurations including unexpected side effects or 264 mutual dependences can disrupt OAM and control operations and 265 especially disrupt remote management access to the affected node 266 itself and potentially a much larger number of nodes for whom the 267 affected node is on the network path. Traditionally, physically 268 separate, so-called out-of-band (management) networks have been used 269 to avoid these problems or at least to allow recovery from such 270 problems. Worst case, personnel are sent on site to access devices 271 through out-of-band management ports (also called craft ports, serial 272 console, management ethernet port). However, both options are 273 expensive. 275 In increasingly automated networks either centralized management 276 systems or distributed autonomic service agents in the network 277 require a control plane which is independent of the configuration of 278 the network they manage, to avoid impacting their own operations 279 through the configuration actions they take. 281 This document describes a modular design for a self-forming, self- 282 managing and self-protecting ACP, which is a virtual out-of-band 283 network designed to be as independent as possible of configuration, 284 addressing and routing and similar self-dependency problems in 285 current IP networks, but which is still operating in-band on the same 286 physical network that it is controlling and managing. The ACP design 287 is therefore intended to combine as good as possible the resilience 288 of out-of-band management networks with the low-cost of traditional 289 IP in-band network management. The details how this is achieved are 290 described in Section 6. 292 In a fully autonomic network node without legacy control or 293 management functions/protocols, the Data-Plane would be for example 294 just a forwarding plane for "Data" IPv6 packets, aka: packets that 295 are not forwarded by the ACP itself such as control or management 296 plane packets. In such networks/nodes, there would be no non- 297 autonomous control or non-autonomous management plane. 299 Routing protocols for example would be built inside the ACP as so- 300 called autonomous functions via autonomous service agents, leveraging 301 the ACPs functions instead of implementing them seperately for each 302 protocol: discovery, automatically established authenticated and 303 encrypted local and distant peer connectivity for control and 304 management traffic and common control/management protocol session and 305 presentation functions. 307 When ACP functionality is added to nodes that have non-autonomous 308 management plane and/or control plane functions (henceforth called 309 non-autonomous nodes), the ACP instead is best abstracted as a 310 special Virtual Routing and Forwarding (VRF) instance (or virtual 311 router) and the complete pre-existing non-autonomous management and/ 312 or control plane is considered to be part of the Data-Plane to avoid 313 introduction of more complex, new terminology only for this case. 315 Like the forwarding plane for "Data" packets, the non-autonomous 316 control and management plane functions can then be managed/used via 317 the ACP. This terminology is consistent with pre-existing documents 318 such as [RFC8368]. 320 In both instances (autonomous and non-autonomous nodes), the ACP is 321 built such that it is operating in the absence of the Data-Plane, and 322 in the case of existing non-autonomous (management, control) 323 components in the Data-Plane also in the presence of any 324 (mis-)configuration thereof. 326 The Autonomic Control Plane serves several purposes at the same time: 328 1. Autonomic functions communicate over the ACP. The ACP therefore 329 directly supports Autonomic Networking functions, as described in 330 [I-D.ietf-anima-reference-model]. For example, Generic Autonomic 331 Signaling Protocol (GRASP - [I-D.ietf-anima-grasp]) runs securely 332 inside the ACP and depends on the ACP as its "security and 333 transport substrate". 335 2. A controller or network management system can use it to securely 336 bootstrap network devices in remote locations, even if the (Data- 337 Plane) network in between is not yet configured; no Data-Plane 338 dependent bootstrap configuration is required. An example of 339 such a secure bootstrap process is described in 340 [I-D.ietf-anima-bootstrapping-keyinfra]. 342 3. An operator can use it to access remote devices using protocols 343 such as Secure SHell (SSH) or Network Configuration Protocol 344 (NETCONF) running across the ACP, even if the network is 345 misconfigured or not configured. 347 This document describes these purposes as use cases for the ACP in 348 Section 3, it defines the requirements in Section 4. Section 5 gives 349 an overview how the ACP is constructed. 351 The normative part of this document starts with Section 6, where the 352 ACP is specified. Section 7 explains how to support ACP on L2 353 switches (normative). Section 8 explains how non-ACP nodes and 354 networks can be integrated (normative). 356 The remaining sections are non-normative: Section 10 reviews benefits 357 of the ACP (after all the details have been defined), Section 9 358 provides operational recommendations, Appendix A provides additional 359 explanations and describes additional details or future standard or 360 propriety extensions that were considered not to be appropriate for 361 standardization in this document but were considered important to 362 document. There are no dependencies against Appendix A to build a 363 complete working and interoperable ACP according to this document. 365 The ACP provides secure IPv6 connectivity, therefore it can be used 366 not only as the secure connectivity for self-management as required 367 for the ACP in [RFC7575], but it can also be used as the secure 368 connectivity for traditional (centralized) management. The ACP can 369 be implemented and operated without any other components of autonomic 370 networks, except for the GRASP protocol. ACP relies on per-link DULL 371 GRASP (see Section 6.3) to autodiscover ACP neighbors, and includes 372 the ACP GRASP instance to provide service discovery for clients of 373 the ACP (see Section 6.8) including for its own maintenance of ACP 374 certificates. 376 The document "Using Autonomic Control Plane for Stable Connectivity 377 of Network OAM" [RFC8368] describes how the ACP alone can be used to 378 provide secure and stable connectivity for autonomic and non- 379 autonomic OAM applications, specifically for the case of current non- 380 autonomic networks/nodes. That document also explains how existing 381 management solutions can leverage the ACP in parallel with 382 traditional management models, when to use the ACP and how to 383 integrate with potentially IPv4 only OAM backends. 385 Combining ACP with Bootstrapping Remote Secure Key Infrastructures 386 (BRSKI), see [I-D.ietf-anima-bootstrapping-keyinfra]) results in the 387 "Autonomic Network Infrastructure" (ANI) as defined in 388 [I-D.ietf-anima-reference-model], which provides autonomic 389 connectivity (from ACP) with secure zero-touch (automated) bootstrap 390 from BRSKI. The ANI itself does not constitute an Autonomic Network, 391 but it allows the building of more or less autonomic networks on top 392 of it - using either centralized, Software Defined Networking- 393 (SDN-)style (see [RFC7426]) automation or distributed automation via 394 Autonomic Service Agents (ASA) / Autonomic Functions (AF) - or a 395 mixture of both. See [I-D.ietf-anima-reference-model] for more 396 information. 398 1.1. Applicability and Scope 400 Please see the following Terminology section (Section 2) for 401 explanations of terms used in this section. 403 The design of the ACP as defined in this document is considered to be 404 applicable to all types of "professionally managed" networks: Service 405 Provider, Local Area Network (LAN), Metro(politan networks), Wide 406 Area Network (WAN), Enterprise Information Technology (IT) and 407 ->"Operational Technology" () (OT) networks. The ACP can operate 408 equally on layer 3 equipment and on layer 2 equipment such as bridges 409 (see Section 7). The hop-by-hop authentication, integrity-protection 410 and confidentiality mechanism used by the ACP is defined to be 411 negotiable, therefore it can be extended to environments with 412 different protocol preferences. The minimum implementation 413 requirements in this document attempt to achieve maximum 414 interoperability by requiring support for multiple options depending 415 on the type of device: IPsec, see [RFC4301], and datagram Transport 416 Layer Security (DTLS) version 1.2, see [RFC6347]). 418 The implementation footprint of the ACP consists of Public Key 419 Infrastructure (PKI) code for the ACP certificate, the GRASP 420 protocol, UDP, TCP and TLS 1.2 ([RFC5246], for security and 421 reliability of GRASP), the ACP secure channel protocol used (such as 422 IPsec or DTLS), and an instance of IPv6 packet forwarding and routing 423 via the Routing Protocol for Low-power and Lossy Networks (RPL), see 424 [RFC6550], that is separate from routing and forwarding for the Data- 425 Plane (user traffic). 427 The ACP uses only IPv6 to avoid complexity of dual-stack ACP 428 operations (IPv6/IPv4). Nevertheless, it can without any changes be 429 integrated into even otherwise IPv4-only network devices. The Data- 430 Plane itself would not need to change, it could continue to be IPv4 431 only. For such IPv4 only devices, the IPv6 protocol itself would be 432 additional implementation footprint only used for the ACP. 434 The protocol choices of the ACP are primarily based on wide use and 435 support in networks and devices, well understood security properties 436 and required scalability. The ACP design is an attempt to produce 437 the lowest risk combination of existing technologies and protocols to 438 build a widely applicable operational network management solution. 440 RPL was chosen because it requires a smaller routing table footprint 441 in large networks compared to other routing protocols with an 442 autonomically configured single area. The deployment experience of 443 large scale Internet of Things (IoT) networks serves as the basis for 444 wide deployment experience with RPL. The profile chosen for RPL in 445 the ACP does not leverage any RPL specific forwarding plane features 446 (IPv6 extension headers), making its implementation a pure control 447 plane software requirement. 449 GRASP is the only completely novel protocol used in the ACP, and this 450 choice was necessary because there is no existing suitable protocol 451 to provide the necessary functions to the ACP, so GRASP was developed 452 to fill that gap. 454 The ACP design can be applicable to (cpu, memory) constrained devices 455 and (bitrate, reliability) constrained networks, but this document 456 does not attempt to define the most constrained type of devices or 457 networks to which the ACP is applicable. RPL and DTLS for ACP secure 458 channels are two protocol choices already making ACP more applicable 459 to constrained environments. Support for constrained devices in this 460 specification is opportunistic, but not complete, because the 461 reliable transport for GRASP (see Section 6.8.2) only specifies TCP/ 462 TLS). See Appendix A.9 for discussions about how future standards or 463 proprietary extensions/variations of the ACP could better meet 464 different expectations from those on which the current design is 465 based including supporting constrained devices better. 467 2. Acronyms and Terminology (Informative) 469 [RFC Editor: Please add ACP, BRSKI, GRASP, MASA to https://www.rfc- 470 editor.org/materials/abbrev.expansion.txt.] 472 [RFC Editor: WG/IETF/IESG review of the terms below asked for 473 references between these terms when they refer to each other. The 474 only option I could find for RFC/XML to point to a hanging text 475 acronym definition that also displays the actual term is the 476 format="title" version, which leads to references such as '->"ACP 477 certificate" ()'. I found no reasonable way to eliminate the 478 trailing '()' generated by this type of cross references. Can you 479 please take care of removing these artefacts during editing (after 480 conversion to nroff ?). I also created a ticket to ask for an 481 xml2rfc enhancement to avoid this in the future: 482 https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/347.] 484 [RFC Editor: Question: Is it possible to change the first occurrences 485 of [RFCxxxx] references to "rfcxxx title" [RFCxxxx]? the XML2RFC 486 format does not seem to offer such a format, but I did not want to 487 duplicate 50 first references - one reference for title mentioning 488 and one for RFC number.] 490 This document serves both as a normative specification for how ACP 491 nodes have to behave as well as describing requirements, benefits, 492 architecture and operational aspects to explain the context. 493 Normative sections are labelled "(Normative)" and use 494 [RFC2119]/[RFC8174] keywords. Other sections are labelled 495 "(Informative)" and do not use those normative keywords. 497 In the rest of the document we will refer to systems using the ACP as 498 "nodes". Typically such a node is a physical (network equipment) 499 device, but it can equally be some virtualized system. Therefore, we 500 do not refer to them as devices unless the context specifically calls 501 for a physical system. 503 This document introduces or uses the following terms (sorted 504 alphabetically). Terms introduced are explained on first use, so 505 this list is for reference only. 507 ACP: "Autonomic Control Plane". The Autonomic Function as defined 508 in this document. It provides secure zero-touch (automated) 509 transitive (network wide) IPv6 connectivity for all nodes in the 510 same ACP domain as well as a GRASP instance running across this 511 ACP IPv6 connectivity. The ACP is primarily meant to be used as a 512 component of the ANI to enable Autonomic Networks but it can 513 equally be used in simple ANI networks (with no other Autonomic 514 Functions) or completely by itself. 516 ACP address: An IPv6 address assigned to the ACP node. It is stored 517 in the acp-node-name of the ->"ACP certificate" (). 519 ACP address range/set: The ACP address may imply a range or set of 520 addresses that the node can assign for different purposes. This 521 address range/set is derived by the node from the format of the 522 ACP address called the "addressing sub-scheme". 524 ACP connect interface: An interface on an ACP node providing access 525 to the ACP for non ACP capable nodes without using an ACP secure 526 channel. See Section 8.1.1. 528 ACP domain: The ACP domain is the set of nodes with ->"ACP 529 certificates" that allow them to authenticate each other as 530 members of the ACP domain. See also Section 6.1.3. 532 ACP (ANI/AN) Domain Certificate: A [RFC5280] certificate (LDevID) 533 carrying the acp-node-name which is used by the ACP to learn its 534 address in the ACP and to derive and cryptographically assert its 535 membership in the ACP domain. 537 ACP acp-node-name field: An information field in the ACP certificate 538 in which the ACP relevant information is encoded: the ACP domain 539 name, the ACP IPv6 address of the node and optional additional 540 role attributes about the node. 542 ACP Loopback interface: The Loopback interface in the ACP Virtual 543 Routing and Forwarding (VRF) that has the ACP address assigned to 544 it. See Section 6.12.5.1. 546 ACP network: The ACP network constitutes all the nodes that have 547 access to the ACP. It is the set of active and transitively 548 connected nodes of an ACP domain plus all nodes that get access to 549 the ACP of that domain via ACP edge nodes. 551 ACP (ULA) prefix(es): The /48 IPv6 address prefixes used across the 552 ACP. In the normal/simple case, the ACP has one ULA prefix, see 553 Section 6.10. The ACP routing table may include multiple ULA 554 prefixes if the "rsub" option is used to create addresses from 555 more than one ULA prefix. See Section 6.1.2. The ACP may also 556 include non-ULA prefixes if those are configured on ACP connect 557 interfaces. See Section 8.1.1. 559 ACP secure channel: A channel authenticated via ->"ACP certificates" 560 () providing integrity protection and confidentiality through 561 encryption. These are established between (normally) adjacent ACP 562 nodes to carry traffic of the ACP VRF securely and isolated from 563 Data-Plane traffic in-band over the same link/path as the Data- 564 Plane. 566 ACP secure channel protocol: The protocol used to build an ACP 567 secure channel, e.g., Internet Key Exchange Protocol version 2 568 (IKEv2) with IPsec or Datagram Transport Layer Security (DTLS). 570 ACP virtual interface: An interface in the ACP VRF mapped to one or 571 more ACP secure channels. See Section 6.12.5. 573 AN "Autonomic Network": A network according to 574 [I-D.ietf-anima-reference-model]. Its main components are ANI, 575 Autonomic Functions and Intent. 577 (AN) Domain Name: An FQDN (Fully Qualified Domain Name) in the acp- 578 node-name of the Domain Certificate. See Section 6.1.2. 580 ANI (nodes/network): "Autonomic Network Infrastructure". The ANI is 581 the infrastructure to enable Autonomic Networks. It includes ACP, 582 BRSKI and GRASP. Every Autonomic Network includes the ANI, but 583 not every ANI network needs to include autonomic functions beyond 584 the ANI (nor Intent). An ANI network without further autonomic 585 functions can for example support secure zero-touch (automated) 586 bootstrap and stable connectivity for SDN networks - see 587 [RFC8368]. 589 ANIMA: "Autonomic Networking Integrated Model and Approach". ACP, 590 BRSKI and GRASP are specifications of the IETF ANIMA working 591 group. 593 ASA: "Autonomic Service Agent". Autonomic software modules running 594 on an ANI device. The components making up the ANI (BRSKI, ACP, 595 GRASP) are also described as ASAs. 597 Autonomic Function: A function/service in an Autonomic Network (AN) 598 composed of one or more ASA across one or more ANI nodes. 600 BRSKI: "Bootstrapping Remote Secure Key Infrastructures" 601 ([I-D.ietf-anima-bootstrapping-keyinfra]. A protocol extending 602 EST to enable secure zero-touch bootstrap in conjunction with ACP. 603 ANI nodes use ACP, BRSKI and GRASP. 605 CA: "Certification Authority". An entity that issues digital 606 certificates. A CA uses its private key to sign the certificates 607 it issues, relying parties use the public key in the CA 608 certificate to validate the signature. This signing certificate 609 can be considered to be an identifier of the CA, so the term CA is 610 also loosely used to refer to the certificate used by the CA for 611 signing. 613 CRL: "Certificate Revocation List". A list of revoked certificates. 614 Required to revoke certificates before their lifetime expires. 616 Data-Plane: The counterpoint to the ACP VRF in an ACP node: 617 forwarding of user traffic and in non-autonomous nodes/networks 618 also any non-autonomous control and/or management plane functions. 619 In a fully Autonomic Network node, the Data-Plane is managed 620 autonomically via Autonomic Functions and Intent. See Section 1 621 for more detailed explanations. 623 device: A physical system, or physical node. 625 Enrollment: The process through which a node authenticates itself to 626 a network with an initial identity, which is often called IDevID 627 certificate, and acquires from the network a network specific 628 identity, which is often called LDevID certificate, and 629 certificates of one or more Trust Anchor(s). In the ACP, the 630 LDevID certificate is called the ACP certificate. 632 EST: "Enrollment over Secure Transport" ([RFC7030]). IETF standard- 633 track protocol for enrollment of a node with an LDevID 634 certificate. BRSKI is based on EST. 636 GRASP: "Generic Autonomic Signaling Protocol". An extensible 637 signaling protocol required by the ACP for ACP neighbor discovery. 639 The ACP also provides the "security and transport substrate" for 640 the "ACP instance of GRASP". This instance of GRASP runs across 641 the ACP secure channels to support BRSKI and other NOC/OAM or 642 Autonomic Functions. See [I-D.ietf-anima-grasp]. 644 IDevID: An "Initial Device IDentity" X.509 certificate installed by 645 the vendor on new equipment. Contains information that 646 establishes the identity of the node in the context of its vendor/ 647 manufacturer such as device model/type and serial number. See 648 [AR8021]. The IDevID certificate cannot be used as a node 649 identifier for the ACP because they are not provisioned by the 650 owner of the network, so they can not directly indicate an ACP 651 domain they belong to. 653 in-band (management/signaling): In-band management traffic and/or 654 control plane signaling uses the same network resources such as 655 routers/switches and network links that it manages/controls. In- 656 band is the standard management and signaling mechanism in IP 657 networks. Compared to ->"out-of-band" () it requires no 658 additional physical resources, but introduces potentially circular 659 dependencies for its correct operations. See ->"introduction" 660 (Introduction (Informative)). 662 Intent: Policy language of an autonomic network according to 663 [I-D.ietf-anima-reference-model]. 665 Loopback interface: See ->"ACP Loopback interface" (). 667 LDevID: A "Local Device IDentity" is an X.509 certificate installed 668 during "enrollment". The Domain Certificate used by the ACP is an 669 LDevID certificate. See [AR8021]. 671 Management: Used in this document as another word for ->"OAM" (). 673 MASA (service): "Manufacturer Authorized Signing Authority". A 674 vendor/manufacturer or delegated cloud service on the Internet 675 used as part of the BRSKI protocol. 677 MIC: "Manufacturer Installed Certificate". This is another word to 678 describe an IDevID in referenced materials. This term is not used 679 in this document. 681 native interface: Interfaces existing on a node without 682 configuration of the already running node. On physical nodes 683 these are usually physical interfaces. On virtual nodes their 684 equivalent. 686 NOC: Network Operations Center. 688 node: A system supporting the ACP according to this document. Can 689 be virtual or physical. Physical nodes are called devices. 691 Node-ID: The identifier of an ACP node inside that ACP. It is the 692 last 64 (see Section 6.10.3) or 78-bits (see Section 6.10.5) of 693 the ACP address. 695 OAM: Operations, Administration and Management. Includes Network 696 Monitoring. 698 Operational Technology (OT): "https://en.wikipedia.org/wiki/ 699 Operational_Technology" [1]: "The hardware and software dedicated 700 to detecting or causing changes in physical processes through 701 direct monitoring and/or control of physical devices such as 702 valves, pumps, etc.". OT networks are today in most cases well 703 separated from Information Technology (IT) networks. 705 out-of-band (management) network: An out-of-band network is a 706 secondary network used to manage a primary network. The equipment 707 of the primary network is connected to the out-of-band network via 708 dedicated management ports on the primary network equipment. 709 Serial (console) management ports were historically most common, 710 higher end network equipment now also has ethernet ports dedicated 711 only for management. An out-of-band network provides management 712 access to the primary network independent of the configuration 713 state of the primary network. See ->"introduction" 714 (Introduction (Informative)) 716 (virtual) out-of-band network: The ACP can be called a virtual out- 717 of-band network for management and control because it attempts to 718 provide the benefits of a (physical) ->"out-of-band network" () 719 even though it is physically carried ->"in-band" (). See 720 ->"introduction" (Introduction (Informative)). 722 root CA: "root Certification Authority". A ->"CA" () for which the 723 root CA Key update procedures of [RFC7030], Section 4.4 can be 724 applied. 726 RPL: "IPv6 Routing Protocol for Low-Power and Lossy Networks". The 727 routing protocol used in the ACP. See [RFC6550]. 729 (ACP/ANI/BRSKI) Registrar: An ACP registrar is an entity (software 730 and/or person) that is orchestrating the enrollment of ACP nodes 731 with the ACP certificate. ANI nodes use BRSKI, so ANI registrars 732 are also called BRSKI registrars. For non-ANI ACP nodes, the 733 registrar mechanisms are undefined by this document. See 734 Section 6.10.7. Renewal and other maintenance (such as 735 revocation) of ACP certificates may be performed by other entities 736 than registrars. EST must be supported for ACP certificate 737 renewal (see Section 6.1.5). BRSKI is an extension of EST, so 738 ANI/BRSKI registrars can easily support ACP domain certificate 739 renewal in addition to initial enrollment. 741 RPI: "RPL Packet Information". Network extension headers for use 742 with the ->"RPL" () routing protocols. Not used with RPL in the 743 ACP. See Section 6.11.1.13. 745 RPL: "Routing Protocol for Low-Power and Lossy Networks". The 746 routing protocol used in the ACP. See Section 6.11. 748 sUDI: "secured Unique Device Identifier". This is another word to 749 describe an IDevID in referenced material. This term is not used 750 in this document. 752 TA: "Trust Anchor". A Trust Anchor is an entity that is trusted for 753 the purpose of certificate validation. Trust Anchor Information 754 such as self-signed certificate(s) of the Trust Anchor is 755 configured into the ACP node as part of Enrollment. See 756 [RFC5280], Section 6.1.1. 758 UDI: "Unique Device Identifier". In the context of this document 759 unsecured identity information of a node typically consisting of 760 at least device model/type and serial number, often in a vendor 761 specific format. See sUDI and LDevID. 763 ULA: (Global ID prefix) A "Unique Local Address" (ULA) is an IPv6 764 address in the block fc00::/7, defined in [RFC4193]. It is the 765 approximate IPv6 counterpart of the IPv4 private address 766 ([RFC1918]). The ULA Global ID prefix are the first 48-bits of a 767 ULA address. In this document it is abbreviated as "ULA prefix". 769 (ACP) VRF: The ACP is modeled in this document as a "Virtual Routing 770 and Forwarding" instance (VRF). This means that it is based on a 771 "virtual router" consisting of a separate IPv6 forwarding table to 772 which the ACP virtual interfaces are attached and an associated 773 IPv6 routing table separate from the Data-Plane. Unlike the VRFs 774 on MPLS/VPN-PE ([RFC4364]) or LISP XTR ([RFC6830]), the ACP VRF 775 does not have any special "core facing" functionality or routing/ 776 mapping protocols shared across multiple VRFs. In vendor products 777 a VRF such as the ACP-VRF may also be referred to as a so called 778 VRF-lite. 780 (ACP) Zone: An ACP zone is a set of ACP nodes using the same zone 781 field value in their ACP address according to Section 6.10.3. 782 Zones are a mechanism to support structured addressing of ACP 783 addresses within the same /48-bit ULA prefix. 785 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 786 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 787 "OPTIONAL" in this document are to be interpreted as described in BCP 788 14 [RFC2119],[RFC8174] when, and only when, they appear in all 789 capitals, as shown here. 791 3. Use Cases for an Autonomic Control Plane (Informative) 793 This section summarizes the use cases that are intended to be 794 supported by an ACP. To understand how these are derived from and 795 relate to the larger set of use cases for autonomic networks, please 796 refer to [RFC8316]. 798 3.1. An Infrastructure for Autonomic Functions 800 Autonomic Functions need a stable infrastructure to run on, and all 801 autonomic functions should use the same infrastructure to minimize 802 the complexity of the network. In this way, there is only need for a 803 single discovery mechanism, a single security mechanism, and single 804 instances of other processes that distributed functions require. 806 3.2. Secure Bootstrap over a not configured Network 808 Today, bootstrapping a new node typically requires all nodes between 809 a controlling node such as an SDN controller ("Software Defined 810 Networking", see [RFC7426]) and the new node to be completely and 811 correctly addressed, configured and secured. Bootstrapping and 812 configuration of a network happens in rings around the controller - 813 configuring each ring of devices before the next one can be 814 bootstrapped. Without console access (for example through an out-of- 815 band network) it is not possible today to make devices securely 816 reachable before having configured the entire network leading up to 817 them. 819 With the ACP, secure bootstrap of new devices and whole new networks 820 can happen without requiring any configuration of unconfigured 821 devices along the path: As long as all devices along the path support 822 ACP and a zero-touch bootstrap mechanism such as BRSKI, the ACP 823 across a whole network of unconfigured devices can be brought up 824 without operator/provisioning intervention. The ACP also provides 825 additional security for any bootstrap mechanism, because it can 826 provide encrypted discovery (via ACP GRASP) of registrars or other 827 bootstrap servers by bootstrap proxies connecting to nodes that are 828 to be bootstrapped and the ACP encryption hides the identities of the 829 communicating entities (pledge and registrar), making it more 830 difficult to learn which network node might be attackable. The ACP 831 certificate can also be used to end-to-end encrypt the bootstrap 832 communication between such proxies and server. Note that 833 bootstrapping here includes not only the first step that can be 834 provided by BRSKI (secure keys), but also later stages where 835 configuration is bootstrapped. 837 3.3. Data-Plane Independent Permanent Reachability 839 Today, most critical control plane protocols and OAM protocols are 840 using the Data-Plane of the network. This leads to often undesirable 841 dependencies between control and OAM plane on one side and the Data- 842 Plane on the other: Only if the forwarding and control plane of the 843 Data-Plane are configured correctly, will the Data-Plane and the OAM/ 844 control plane work as expected. 846 Data-Plane connectivity can be affected by errors and faults, for 847 example misconfigurations that make AAA (Authentication, 848 Authorization and Accounting) servers unreachable or can lock an 849 administrator out of a device; routing or addressing issues can make 850 a device unreachable; shutting down interfaces over which a current 851 management session is running can lock an admin irreversibly out of 852 the device. Traditionally only out-of-band access can help recover 853 from such issues (such as serial console or ethernet management 854 port). 856 Data-Plane dependencies also affect applications in a Network 857 Operations Center (NOC) such as SDN controller applications: Certain 858 network changes are today hard to implement, because the change 859 itself may affect reachability of the devices. Examples are address 860 or mask changes, routing changes, or security policies. Today such 861 changes require precise hop-by-hop planning. 863 Note that specific control plane functions for the Data-Plane often 864 want to depend on forwarding of their packets via the Data-Plane: 865 Aliveness and routing protocol signaling packets across the Data- 866 Plane to verify reachability across the Data-Plane, using IPv4 867 signaling packets for IPv4 routing vs. IPv6 signaling packets for 868 IPv6 routing. 870 Assuming appropriate implementation (see Section 6.12.2 for more 871 details), the ACP provides reachability that is independent of the 872 Data-Plane. This allows the control plane and OAM plane to operate 873 more robustly: 875 o For management plane protocols, the ACP provides the functionality 876 of a Virtual out-of-band (VooB) channel, by providing connectivity 877 to all nodes regardless of their Data-Plane configuration, routing 878 and forwarding tables. 880 o For control plane protocols, the ACP allows their operation even 881 when the Data-Plane is temporarily faulty, or during transitional 882 events, such as routing changes, which may affect the control 883 plane at least temporarily. This is specifically important for 884 autonomic service agents, which could affect Data-Plane 885 connectivity. 887 The document "Using Autonomic Control Plane for Stable Connectivity 888 of Network OAM" [RFC8368] explains this use case for the ACP in 889 significantly more detail and explains how the ACP can be used in 890 practical network operations. 892 4. Requirements (Informative) 894 The following requirements were identified for the design of the ACP 895 based on the above use-cases (Section 3). These requirements are 896 informative. The ACP as specified in the normative parts of this 897 document is meeting or exceeding these use-case requirements: 899 ACP1: The ACP should provide robust connectivity: As far as 900 possible, it should be independent of configured addressing, 901 configuration and routing. Requirements 2 and 3 build on this 902 requirement, but also have value on their own. 904 ACP2: The ACP must have a separate address space from the Data- 905 Plane. Reason: traceability, debug-ability, separation from 906 Data-Plane, infrastructure security (filtering based on known 907 address space). 909 ACP3: The ACP must use autonomically managed address space. Reason: 910 easy bootstrap and setup ("autonomic"); robustness (admin 911 cannot break network easily). This document uses Unique Local 912 Addresses (ULA) for this purpose, see [RFC4193]. 914 ACP4: The ACP must be generic, that is it must be usable by all the 915 functions and protocols of the ANI. Clients of the ACP must 916 not be tied to a particular application or transport protocol. 918 ACP5: The ACP must provide security: Messages coming through the ACP 919 must be authenticated to be from a trusted node, and should 920 (very strong should) be encrypted. 922 Explanation for ACP4: In a fully autonomic network (AN), newly 923 written ASA could potentially all communicate exclusively via GRASP 924 with each other, and if that was assumed to be the only requirement 925 against the ACP, it would not need to provide IPv6 layer connectivity 926 between nodes, but only GRASP connectivity. Nevertheless, because 927 ACP also intends to support non-AN networks, it is crucial to support 928 IPv6 layer connectivity across the ACP to support any transport and 929 application layer protocols. 931 The ACP operates hop-by-hop, because this interaction can be built on 932 IPv6 link local addressing, which is autonomic, and has no dependency 933 on configuration (requirement 1). It may be necessary to have ACP 934 connectivity across non-ACP nodes, for example to link ACP nodes over 935 the general Internet. This is possible, but introduces a dependency 936 against stable/resilient routing over the non-ACP hops (see 937 Section 8.2). 939 5. Overview (Informative) 941 When a node has an ACP certificate (see Section 6.1.1) and is enabled 942 to bring up the ACP (see Section 9.3.5), it will create its ACP 943 without any configuration as follows. For details, see Section 6 and 944 further sections: 946 1. The node creates a VRF instance, or a similar virtual context for 947 the ACP. 949 2. The node assigns its ULA IPv6 address (prefix) (see Section 6.10 950 which is learned from the acp-node-name (see Section 6.1.2) of 951 its ACP certificate (see Section 6.1.1) to an ACP loopback 952 interface (see Section 6.10) and connects this interface into the 953 ACP VRF. 955 3. The node establishes a list of candidate peer adjacencies and 956 candidate channel types to try for the adjacency. This is 957 automatic for all candidate link-local adjacencies, see 958 Section 6.3 across all native interfaces (see Section 9.3.4). If 959 a candidate peer is discovered via multiple interfaces, this will 960 result in one adjacency per interface. If the ACP node has 961 multiple interfaces connecting to the same subnet across which it 962 is also operating as an L2 switch in the Data-Plane, it employs 963 methods for ACP with L2 switching, see Section 7. 965 4. For each entry in the candidate adjacency list, the node 966 negotiates a secure tunnel using the candidate channel types. 967 See Section 6.5. 969 5. The node authenticates the peer node during secure channel setup 970 and authorizes it to become part of the ACP according to 971 Section 6.1.3. 973 6. Each successfully established secure channel is mapped into an 974 ACP virtual interface, which is placed into the ACP VRF. See 975 Section 6.12.5.2. 977 7. Each node runs a lightweight routing protocol, see Section 6.11, 978 to announce reachability of the ACP loopback address (or prefix) 979 across the ACP. 981 8. This completes the creation of the ACP with hop-by-hop secure 982 tunnels, auto-addressing and auto-routing. The node is now an 983 ACP node with a running ACP. 985 Note: 987 o None of the above operations (except the following explicit 988 configured ones) are reflected in the configuration of the node. 990 o Non-ACP NMS ("Network Management Systems") or SDN controllers have 991 to be explicitly configured for connection into the ACP. 993 o Additional candidate peer adjacencies for ACP connections across 994 non-ACP Layer-3 clouds requires explicit configuration. See 995 Section 8.2. 997 The following figure illustrates the ACP. 999 ACP node 1 ACP node 2 1000 ................... ................... 1001 secure . . secure . . secure 1002 channel: +-----------+ : channel : +-----------+ : channel 1003 ..--------| ACP VRF |---------------------| ACP VRF |---------.. 1004 : / \ / \ <--routing--> / \ / \ : 1005 : \ / \ / \ / \ / : 1006 ..--------| Loopback |---------------------| Loopback |---------.. 1007 : | interface | : : | interface | : 1008 : +-----------+ : : +-----------+ : 1009 : : : : 1010 : Data-Plane :...............: Data-Plane : 1011 : : link : : 1012 :.................: :.................: 1014 Figure 1: ACP VRF and secure channels 1016 The resulting overlay network is normally based exclusively on hop- 1017 by-hop tunnels. This is because addressing used on links is IPv6 1018 link local addressing, which does not require any prior set-up. In 1019 this way the ACP can be built even if there is no configuration on 1020 the node, or if the Data-Plane has issues such as addressing or 1021 routing problems. 1023 6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 1025 This section specifies the components and steps to set up an ACP. 1026 The ACP is automatically "self-creating", which makes it 1027 "indestructible" against most changes to the Data-Plane, including 1028 misconfigurations of routing, addressing, NAT, firewall or any other 1029 traffic policy filters that inadvertently or otherwise unavoidably 1030 would also impact the management plane traffic, such as the actual 1031 operator CLI session or controller NetConf session through which the 1032 configuration changes to the Data-Plane are executed. 1034 Physical misconfiguration of wiring between ACP nodes will also not 1035 break the ACP: As long as there is a transitive physical path between 1036 ACP nodes, the ACP should be able to recover given that it 1037 automatically operates across all interfaces of the ACP nodes and 1038 automatically determines paths between them. 1040 Attacks against the network via incorrect routing or addressing 1041 information for the Data-Plane will not impact the ACP. Even 1042 impaired ACP nodes will have a significantly reduced attack surface 1043 against malicious misconfiguration because only very limited ACP or 1044 interface up/down configuration can affect the ACP, and pending on 1045 their specific designs these type of attacks could also be 1046 eliminated. See more in Section 9.3 and Section 11. 1048 An ACP node can be a router, switch, controller, NMS host, or any 1049 other IPv6 capable node. Initially, it MUST have its ACP 1050 certificate, as well as an (empty) ACP Adjacency Table (described in 1051 Section 6.2). It then can start to discover ACP neighbors and build 1052 the ACP. This is described step by step in the following sections: 1054 6.1. ACP Domain, Certificate and Network 1056 The ACP relies on group security. An ACP domain is a group of nodes 1057 that trust each other to participate in ACP operations such as 1058 creating ACP secure channels in an autonomous peer-to-peer fashion 1059 between ACP domain members via protocols such as IPsec. To 1060 authenticate and authorize another ACP member node with access to the 1061 ACP Domain, each ACP member requires keying material: An ACP node 1062 MUST have a Local Device IDentity (LDevID) certificate, henceforth 1063 called the ACP certificate and information about one or more Trust 1064 Anchor (TA) as required for the ACP domain membership check 1065 (Section 6.1.3). 1067 Manual keying via shared secrets is not usable for an ACP domain 1068 because it would require a single shared secret across all current 1069 and future ACP domain members to meet the expectation of autonomous, 1070 peer-to-peer establishment of ACP secure channels between any ACP 1071 domain members. Such a single shared secret would be an inacceptable 1072 security weakness. Asymmetric keying material (public keys) without 1073 certificates does not provide the mechanisms to authenticate ACP 1074 domain membership in an autonomous, peer-to-peer fashion for current 1075 and future ACP domain members. 1077 The LDevID certificate is called the ACP certificate, the TA is the 1078 Certification Authority (CA) root certificate of the ACP domain. 1080 The ACP does not mandate specific mechanisms by which this keying 1081 material is provisioned into the ACP node. It only requires the 1082 certificate to comply with Section 6.1.1, specifically to have the 1083 acp-node-name as specified in Section 6.1.2 in its domain certificate 1084 as well as those of candidate ACP peers. See Appendix A.2 for more 1085 information about enrollment or provisioning options. 1087 This document uses the term ACP in many places where the Autonomic 1088 Networking reference documents [RFC7575] and 1089 [I-D.ietf-anima-reference-model] use the word autonomic. This is 1090 done because those reference documents consider (only) fully 1091 autonomic networks and nodes, but support of ACP does not require 1092 support for other components of autonomic networks except for relying 1093 on GRASP and providing security and transport for GRASP. Therefore 1094 the word autonomic might be misleading to operators interested in 1095 only the ACP. 1097 [RFC7575] defines the term "Autonomic Domain" as a collection of 1098 autonomic nodes. ACP nodes do not need to be fully autonomic, but 1099 when they are, then the ACP domain is an autonomic domain. Likewise, 1100 [I-D.ietf-anima-reference-model] defines the term "Domain 1101 Certificate" as the certificate used in an autonomic domain. The ACP 1102 certificate is that domain certificate when ACP nodes are (fully) 1103 autonomic nodes. Finally, this document uses the term ACP network to 1104 refer to the network created by active ACP nodes in an ACP domain. 1105 The ACP network itself can extend beyond ACP nodes through the 1106 mechanisms described in Section 8.1. 1108 6.1.1. ACP Certificates 1110 ACP certificates MUST be [RFC5280] compliant X.509 v3 ([X.509]) 1111 certificates. 1113 ACP nodes MUST support handling ACP certificates, TA certificates and 1114 certificate chain certificates (henceforth just called certificates 1115 in this section) with RSA public keys and certificates with Elliptic 1116 Curve (ECC) public keys. 1118 ACP nodes MUST NOT support certificates with RSA public keys of less 1119 than 2048 bit modulus or curves with group order of less than 256 1120 bit. They MUST support certificates with RSA public keys with 2048 1121 bit modulus and MAY support longer RSA keys. They MUST support 1122 certificates with ECC public keys using NIST P-256 curves and SHOULD 1123 support P-384 and P-521 curves. 1125 ACP nodes MUST support SHA-256 and SHOULD support SHA-384, SHA-512 1126 signatures for certificates with RSA key and the same RSA signatures 1127 plus ECDSA signatures for certificates with ECC key. 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 [RFC4492] 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 [RFC4492]). This can be beneficial especially in the presence of 1144 constrained bandwidth or constrained nodes in an ACP/ANI network. 1146 Some ACP functions such as GRASP peer-2-peer across the ACP require 1147 end-to-end/any-to-any authentication/authorization, therefore ECC can 1148 only reliably be used in the ACP when it MUST be supported on all ACP 1149 nodes. RSA signatures are mandatory to be supported also for ECC 1150 certificates because CAs themselves may not support ECC yet. 1152 The ACP certificate SHOULD be used for any authentication between 1153 nodes with ACP domain certificates (ACP nodes and NOC nodes) where 1154 the required authorization condition is ACP domain membership, such 1155 as ACP node to NOC/OAM end-to-end security and ASA to ASA end-to-end 1156 security. Section 6.1.3 defines this "ACP domain membership check". 1157 The uses of this check that are standardized in this document are for 1158 the establishment of hop-by-hop ACP secure channels (Section 6.6) and 1159 for ACP GRASP (Section 6.8.2) end-to-end via TLS 1.2 ([RFC5246]). 1161 The ACP domain membership check requires a minimum amount of elements 1162 in a certificate as described in Section 6.1.3. The identity of a 1163 node in the ACP is carried via the acp-node-name as defined in 1164 Section 6.1.2. 1166 In support of ECDH key establishment, ACP certificates with ECC keys 1167 MUST indicate to be Elliptic Curve Diffie-Hellman capable (ECDH) if 1168 X.509 v3 keyUsage and extendedKeyUsage are included in the 1169 certificate. 1171 Any other field of the ACP certificate is to be populated as required 1172 by [RFC5280] or desired by the operator of the ACP domain ACP 1173 registrars/CA and required by other purposes that the ACP certificate 1174 is intended to be used for. 1176 For further certificate details, ACP certificates may follow the 1177 recommendations from [CABFORUM]. 1179 For diagnostic and other operational purposes, it is beneficial to 1180 copy the device identifying fields of the node's IDevID certificate 1181 into the ACP certificate, such as the "serialNumber" (see 1182 [I-D.ietf-anima-bootstrapping-keyinfra] section 2.3.1). This can be 1183 done for example if it would be acceptable for the devices 1184 "serialNumber" to be signalled via the Link Layer Discovery Protocol 1185 (LLDP, [LLDP]) because like LLDP signalled information, the ACP 1186 certificate information can be retrieved by neighboring nodes without 1187 further authentication and be used either for beneficial diagnostics 1188 or for malicious attacks. Retrieval of the ACP certificate is 1189 possible via a (failing) attempt to set up an ACP secure channel, and 1190 the "serialNumber" contains usually device type information that may 1191 help to faster determine working exploits/attacks against the device. 1193 Note that there is no intention to constrain authorization within the 1194 ACP or autonomic networks using the ACP to just the ACP domain 1195 membership check as defined in this document. It can be extended or 1196 modified with future requirements. Such future authorizations can 1197 use and require additional elements in certificates or policies or 1198 even additional certificates. For an example, see Appendix A.10.5. 1200 6.1.2. ACP Certificate AcpNodeName 1202 acp-node-name = local-part "@" acp-domain-name 1203 local-part = [ acp-address ] [ "+" rsub extensions ] 1204 HEXLC = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" 1205 ; DIGIT as of RFC5234 section B.1 1206 acp-address = 32HEXLC | "0" 1207 rsub = [ ] ; as of RFC1034, section 3.5 1208 acp-domain-name = ; ; as of RFC 1034, section 3.5 1209 extensions = *( "+" extension ) 1210 extension = ; future standard definition. 1211 ; Must fit RFC5322 simple dot-atom format. 1213 routing-subdomain = [ rsub "." ] acp-domain-name 1215 Example: 1216 given an ACP address of fd89:b714:f3db:0:200:0:6400:0000 1217 and an ACP domain-name of acp.example.com 1218 and an rsub extenstion of area51.research 1220 then this results in: 1221 acp-node-name = fd89b714F3db00000200000064000000 1222 +area51.research@acp.example.com 1223 acp-domain-name = acp.example.com 1224 routing-subdomain = area51.research.acp.example.com 1226 Figure 2: ACP Node Name ABNF 1228 acp-node-name in above Figure 2 is the ABNF ([RFC5234]) definition of 1229 the ACP Node Name. An ACP certificate MUST carry this information. 1230 It MUST be encoded as a subjectAltName / otherName / AcpNodeName as 1231 described in Section 6.1.2.1. 1233 Nodes complying with this specification MUST be able to receive their 1234 ACP address through the domain certificate, in which case their own 1235 ACP certificate MUST have a 32HEXLC "acp-address" field. Nodes 1236 complying with this specification MUST also be able to authenticate 1237 nodes as ACP domain members or ACP secure channel peers when they 1238 have a 0-value acp-address field and as ACP domain members (but not 1239 as ACP secure channel peers) when they have an empty acp-address 1240 field. See Section 6.1.3. 1242 acp-domain-name is used to indicate the ACP Domain across which ACP 1243 nodes authenticate and authorize each other, for example to build ACP 1244 secure channels to each other, see Section 6.1.3. acp-domain-name 1245 SHOULD be the FQDN of an Internet domain owned by the network 1246 administration of the ACP and ideally reserved to only be used for 1247 the ACP. In this specification it serves to be a name for the ACP 1248 that ideally is globally unique. When acp-domain-name is a globally 1249 unique name, collision of ACP addresses across different ACP domains 1250 can only happen due to ULA hash collisions (see Section 6.10.2). 1251 Using different acp-domain-names, operators can distinguish multiple 1252 ACP even when using the same TA. 1254 To keep the encoding simple, there is no consideration for 1255 internationalized acp-domain-names. The acp-node-name is not 1256 intended for end user consumption, and there is no protection against 1257 someone not owning a domain name to simply choose it. Instead, it 1258 serves as a hash seed for the ULA and for diagnostics to the 1259 operator. Therefore, any operator owning only an internationalized 1260 domain name should be able to pick an equivalently unique 7-bit ASCII 1261 acp-domain-name string representing the internationalized domain 1262 name. 1264 "routing-subdomain" is a string that can be constructed from the acp- 1265 node-name, and it is used in the hash-creation of the ULA (see 1266 below). The presence of the "rsub" component allows a single ACP 1267 domain to employ multiple /48 ULA prefixes. See Appendix A.7 for 1268 example use-cases. 1270 The optional "extensions" field is used for future standardized 1271 extensions to this specification. It MUST be ignored if present and 1272 not understood. 1274 The following points explain and justify the encoding choices 1275 described: 1277 1. Formatting notes: 1279 1.1 "rsub" needs to be in the "local-part": If the format just 1280 had routing-subdomain as the domain part of the acp-node- 1281 name, rsub and acp-domain-name could not be separated from 1282 each other to determine in the ACP domain membership check 1283 which part is the acp-domain-name and which is solely for 1284 creating a different ULA prefix. 1286 1.2 If "acp-address" is empty, and "rsub" is empty too, the 1287 "local-part" will have the format ":++extension(s)". The 1288 two plus characters are necessary so the node can 1289 unambiguously parse that both "acp-address" and "rsub" are 1290 empty. 1292 2. The encoding of the ACP domain name and ACP address as described 1293 in this section is used for the following reasons: 1295 2.1 The acp-node-name is the identifier of a node's ACP. It 1296 includes the necessary components to identify a nodes ACP 1297 both from within the ACP as well as from the outside of the 1298 ACP. 1300 2.2 For manual and/or automated diagnostics and backend 1301 management of devices and ACPs, it is necessary to have an 1302 easily human readable and software parsed standard, single 1303 string representation of the information in the acp-node- 1304 name. For example, inventory or other backend systems can 1305 always identify an entity by one unique string field but not 1306 by a combination of multiple fields, which would be 1307 necessary if there was no single string representation. 1309 2.3 If the encoding was not that of such a string, it would be 1310 necessary to define a second standard encoding to provide 1311 this format (standard string encoding) for operator 1312 consumption. 1314 2.4 Addresses of the form <@domain> have become the 1315 preferred format for identifiers of entities in many 1316 systems, including the majority of user identification in 1317 web or mobile applications such as multi-domain single-sign- 1318 on systems. 1320 3. Compatibilities: 1322 3.1 It should be possible to use the ACP certificate as an 1323 LDevID certificate on the system for other uses beside the 1324 ACP. Therefore, the information element required for the 1325 ACP should be encoded so that it minimizes the possibility 1326 of creating incompatibilities with such other uses. The 1327 subjectName is for example often used as an entity 1328 identifier in non-ACP uses of a the ACP certificate. 1330 3.2 The element should not require additional ASN.1 en/decoding, 1331 because libraries to access certificate information 1332 especially for embedded devices may not support extended 1333 ASN.1 decoding beyond predefined, mandatory fields. 1334 subjectAltName / otherName is already used with a single 1335 string parameter for several otherNames (see [RFC3920], 1336 [RFC7585], [RFC4985], [RFC8398]). 1338 3.3 The element required for the ACP should minimize the risk of 1339 being misinterpreted by other uses of the LDevID 1340 certificate. It also must not be misinterpreted to actually 1341 be an email address, hence the use of the otherName / 1342 rfc822Name option in the certificate would be inappropriate. 1344 See section 4.2.1.6 of [RFC5280] for details on the subjectAltName 1345 field. 1347 6.1.2.1. AcpNodeName ASN.1 Module 1349 The following ASN.1 module normatively specifies the AcpNodeName 1350 structure. This specification uses the ASN.1 definitions from 1351 [RFC5912] with the 2002 ASN.1 notation used in that document. 1352 [RFC5912] updates normative documents using older ASN.1 notation. 1354 ANIMA-ACP-2020 1355 { iso(1) identified-organization(3) dod(6) 1356 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 1357 id-mod-anima-acpnodename-2020(IANA1) } 1359 DEFINITIONS IMPLICIT TAGS ::= 1360 BEGIN 1362 IMPORTS 1363 OTHER-NAME 1364 FROM PKIX1Implicit-2009 1365 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 1366 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59) } 1368 id-pkix 1369 FROM PKIX1Explicit-2009 1370 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 1371 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51) } ; 1373 id-on OBJECT IDENTIFIER ::= { id-pkix 8 } 1375 AcpNodeNameOtherNames OTHER-NAME ::= { on-AcpNodeName, ... } 1377 on-AcpNodeName OTHER-NAME ::= { 1378 AcpNodeName IDENTIFIED BY id-on-AcpNodeName 1379 } 1381 id-on-AcpNodeName OBJECT IDENTIFIER ::= { id-on IANA2 } 1383 AcpNodeName ::= IA5String (SIZE (1..MAX)) 1384 -- AcpNodeName as specified in this document carries the 1385 -- acp-node-name as specified in the ABNF in Section 6.1.2 1387 END 1389 6.1.3. ACP domain membership check 1391 The following points constitute the ACP domain membership check of a 1392 candidate peer via its certificate: 1394 1: The peer has proved ownership of the private key associated with 1395 the certificate's public key. This check is performed by the 1396 security association protocol used, for example [RFC7296], section 1397 2.15. 1399 2: The peer's certificate passes certificate path validation as 1400 defined in [RFC5280], section 6 against one of the TA associated 1401 with the ACP node's ACP certificate (see Section 6.1.4 below). 1403 This includes verification of the validity (lifetime) of the 1404 certificates in the path. 1406 3: If the node certificate indicates a Certificate Revocation List 1407 (CRL) Distribution Point (CRLDP) ([RFC5280], section 4.2.1.13) or 1408 Online Certificate Status Protocol (OCSP) responder ([RFC5280], 1409 section 4.2.2.1), then the peer's certificate MUST be valid 1410 according to those mechanisms when they are available: An OCSP 1411 check for the peer's certificate across the ACP must succeed or 1412 the peer certificate must not be listed in the CRL retrieved from 1413 the CRLDP. These mechanisms are not available when the node has 1414 no ACP or non-ACP connectivity to retrieve a current CRL or access 1415 an OCSP responder and the security association protocol itself has 1416 also no way to communicate CRL or OCSP check. 1418 Retries to learn revocation via OCSP/CRL SHOULD be made using 1419 the same backoff as described in Section 6.6. If and when the ACP 1420 node then learns that an ACP peer's certificate is invalid for 1421 which rule 3 had to be skipped during ACP secure channel 1422 establishment, then the ACP secure channel to that peer MUST be 1423 closed even if this peer is the only connectivity to access CRL/ 1424 OCSP. This applies (of course) to all ACP secure channels to this 1425 peer if there are multiple. The ACP secure channel connection 1426 MUST be retried periodically to support the case that the neighbor 1427 acquires a new, valid certificate. 1429 4: The peer's certificate has a syntactically valid acp-node-name 1430 field and the acp-domain-name in that peer's acp-node-name is the 1431 same as in this ACP node's certificate (lowercase normalized). 1433 When checking a candidate peer's certificate for the purpose of 1434 establishing an ACP secure channel, one additional check is 1435 performed: 1437 5: The candidate peer certificate's acp-node-name has a non-empty 1438 acp-address field (either 32HEXLC or 0, according to Figure 2). 1440 Technically, ACP secure channels can only be built with nodes that 1441 have an acp-address. Rule 5 ensures that this is taken into account 1442 during ACP domain membership check. 1444 Nodes with an empty acp-address field can only use their ACP domain 1445 certificate for non-ACP-secure channel authentication purposes. This 1446 includes for example NMS type nodes permitted to communicate into the 1447 ACP via ACP connect (Section 8.1) 1449 The special value 0 in an ACP certificates acp-address field is used 1450 for nodes that can and should determine their ACP address through 1451 other mechanisms than learning it through the acp-address field in 1452 their ACP certificate. These ACP nodes are permitted to establish 1453 ACP secure channels. Mechanisms for those nodes to determine their 1454 ACP address are outside the scope of this specification, but this 1455 option is defined here so that any ACP nodes can build ACP secure 1456 channels to them according to Rule 5. 1458 In summary: 1460 Steps 1...4 constitute standard certificate validity verification 1461 and private key authentication as defined by [RFC5280] and 1462 security association protocols (such as Internet Key Exchange 1463 Protocol version 2 IKEv2 [RFC7296] when leveraging certificates. 1465 Steps 1...4 do not include verification of any pre-existing form 1466 of non-public-key-only based identity elements of a certificate 1467 such as a web servers domain name prefix often encoded in 1468 certificate common name. Steps 5 and 6 are the equivalent steps. 1470 Step 4 Constitutes standard CRL/OCSP checks refined for the case 1471 of missing connectivity and limited functionality security 1472 association protocols. 1474 Step 5 Checks for the presence of an ACP identity for the peer. 1476 Steps 1...5 authorize to build any secure connection between 1477 members of the same ACP domain except for ACP secure channels. 1479 Step 6 is the additional verification of the presence of an ACP 1480 address. 1482 Steps 1...6 authorize to build an ACP secure channel. 1484 For brevity, the remainder of this document refers to this process 1485 only as authentication instead of as authentication and 1486 authorization. 1488 6.1.3.1. Realtime clock and Time Validation 1490 An ACP node with a realtime clock in which it has confidence, MUST 1491 check the time stamps when performing ACP domain membership check 1492 such as as the certificate validity period in step 1. and the 1493 respective times in step 4 for revocation information (e.g., 1494 signingTimes in CMS signatures). 1496 An ACP node without such a realtime clock MAY ignore those time stamp 1497 validation steps if it does not know the current time. Such an ACP 1498 node SHOULD obtain the current time in a secured fashion, such as via 1499 a Network Time Protocol signaled through the ACP. It then ignores 1500 time stamp validation only until the current time is known. In the 1501 absence of implementing a secured mechanism, such an ACP node MAY use 1502 a current time learned in an insecure fashion in the ACP domain 1503 membership check. 1505 Current time MAY for example be learned unsecured via NTP ([RFC5905]) 1506 over the same link-local IPv6 addresses used for the ACP from 1507 neighboring ACP nodes. ACP nodes that do provide NTP insecure over 1508 their link-local addresses SHOULD primarily run NTP across the ACP 1509 and provide NTP time across the ACP only when they have a trusted 1510 time source. Details for such NTP procedures are beyond the scope of 1511 this specification. 1513 Beside ACP domain membership check, the ACP itself has no dependency 1514 against knowledge of the current time, but protocols and services 1515 using the ACP will likeley have the need to know the current time. 1516 For example event logging. 1518 6.1.4. Trust Anchors (TA) 1520 ACP nodes need TA information according to [RFC5280], section 6.1.1 1521 (d), typically in the form of one or more certificate of the TA to 1522 perform certificate path validation as required by Section 6.1.3, 1523 rule 2. TA information MUST be provisioned to an ACP node (together 1524 with its ACP domain certificate) by an ACP Registrar during initial 1525 enrolment of a candidate ACP node. ACP nodes MUST also support 1526 renewal of TA information via Enrollment over Secure Transport (EST, 1527 see [RFC7030]), as described below in Section 6.1.5. 1529 The required information about a TA can consist of not only a single, 1530 but multiple certificates as required for dealing with CA certificate 1531 renewals as explained in Section 4.4 of CMP ([RFC4210]). 1533 A certificate path is a chain of certificates starting at the ACP 1534 certificate (leaf/end-entity) followed by zero or more intermediate 1535 CA certificates and ending with the TA information, which are 1536 typically one or two the self-signed certificates of the TA. The CA 1537 that signs the ACP certificate is called the assigning CA. If there 1538 are no intermediate CA, then the assigning CA is the TA. Certificate 1539 path validation authenticates that the ACP certificate is permitted 1540 by a TA associated with the ACP, directly or indirectly via one or 1541 more intermediate CA. 1543 Note that different ACP nodes may have different intermediate CA in 1544 their certificate path and even different TA. The set of TA for an 1545 ACP domain must be consistent across all ACP members so that any ACP 1546 node can authenticate any other ACP node. The protocols through 1547 which ACP domain membership check rules 1-3 are performed need to 1548 support the exchange not only of the ACP nodes certificates, but also 1549 exchange of the intermedia TA. 1551 ACP nodes MUST support for the ACP domain membership check the 1552 certificate path validation with 0 or 1 intermediate CA. They SHOULD 1553 support 2 intermediate CA and two TA (to permit migration to from one 1554 TA to another TA). 1556 Certificates for an ACP MUST only be given to nodes that are allowed 1557 to be members of that ACP. When the signing CA relies on an ACP 1558 Registrar, the CA MUST only sign certificates with acp-node-name 1559 through trusted ACP Registrars. In this setup, any existing CA, 1560 unaware of the formatting of acp-node-name, can be used. 1562 These requirements can be achieved by using a TA private to the owner 1563 of the ACP domain or potentially through appropriate contractual 1564 agreements between the involved parties (Registrar and CA). These 1565 requirements typically exclude public CA, because they in general do 1566 not support the notion of trusted registrars vouching for the 1567 correctness of the fields of a requested certificate or would by 1568 themselves not be capable to validate the correctness of otherName / 1569 AcpNodeName. 1571 A single owner can operate multiple independent ACP domains from the 1572 same set of TA. Registrars must then know which ACP a node needs to 1573 be enrolled into. 1575 6.1.5. Certificate and Trust Anchor Maintenance 1577 ACP nodes MUST support renewal of their Certificate and TA 1578 information via EST ("Enrollment over Secure Transport", see 1579 [RFC7030]) and MAY support other mechanisms. An ACP network MUST 1580 have at least one ACP node supporting EST server functionality across 1581 the ACP so that EST renewal is useable. 1583 ACP nodes SHOULD be able to remember the IPv6 locator parameters of 1584 the O_IPv6_LOCATOR in GRASP of the EST server from which they last 1585 renewed their ACP certificate. They SHOULD provide the ability for 1586 these EST server parameters to also be set by the ACP Registrar (see 1587 Section 6.10.7) that initially enrolled the ACP device with its ACP 1588 certificate. When BRSKI (see 1589 [I-D.ietf-anima-bootstrapping-keyinfra]) is used, the IPv6 locator of 1590 the BRSKI registrar from the BRSKI TLS connection SHOULD be 1591 remembered and used for the next renewal via EST if that registrar 1592 also announces itself as an EST server via GRASP (see next section) 1593 on its ACP address. 1595 The EST server MUST present a certificate that is passing ACP domain 1596 membership check in its TLS connection setup (Section 6.1.3, rules 1597 1..4, not rule 5 as this is not for an ACP secure channel setup). 1598 The EST server certificate MUST also contain the id-kp-cmcRA 1599 [RFC6402] extended key usage extension and the EST client MUST check 1600 its presence. 1602 The additional check against the id-kp-cmcRA extended key usage 1603 extension field ensures that clients do not fall prey to an illicit 1604 EST server. While such illicit EST servers should not be able to 1605 support certificate signing requests (as they are not able to elicit 1606 a signing response from a valid CA), such an illicit EST server would 1607 be able to provide faked CA certificates to EST clients that need to 1608 renew their CA certificates when they expire. 1610 Note that EST servers supporting multiple ACP domains will need to 1611 have for each of these ACP domains a separate certificate and respond 1612 on a different transport address (IPv6 address and/or TCP port), but 1613 this is easily automated on the EST server as long as the CA does not 1614 restrict registrars to request certificates with the id-kp-cmcRA 1615 extended usage extension for themselves. 1617 6.1.5.1. GRASP objective for EST server 1619 ACP nodes that are EST servers MUST announce their service via GRASP 1620 in the ACP through M_FLOOD messages. See [I-D.ietf-anima-grasp], 1621 section 2.8.11 for the definition of this message type: 1623 Example: 1625 [M_FLOOD, 12340815, h'fd89b714f3db0000200000064000001', 210000, 1626 [["SRV.est", 4, 255 ], 1627 [O_IPv6_LOCATOR, 1628 h'fd89b714f3db0000200000064000001', IPPROTO_TCP, 443]] 1629 ] 1631 Figure 3: GRASP SRV.est example 1633 The formal definition of the objective in Concise data definition 1634 language (CDDL) (see [RFC8610]) is as follows: 1636 flood-message = [M_FLOOD, session-id, initiator, ttl, 1637 +[objective, (locator-option / [])]] 1638 ; see example above and explanation 1639 ; below for initiator and ttl 1641 objective = ["SRV.est", objective-flags, loop-count, 1642 objective-value] 1644 objective-flags = sync-only ; as in GRASP spec 1645 sync-only = 4 ; M_FLOOD only requires synchronization 1646 loop-count = 255 ; recommended as there is no mechanism 1647 ; to discover network diameter. 1648 objective-value = any ; reserved for future extensions 1650 Figure 4: GRASP SRV.est definition 1652 The objective name "SRV.est" indicates that the objective is an 1653 [RFC7030] compliant EST server because "est" is an [RFC6335] 1654 registered service name for [RFC7030]. Objective-value MUST be 1655 ignored if present. Backward compatible extensions to [RFC7030] MAY 1656 be indicated through objective-value. Non [RFC7030] compatible 1657 certificate renewal options MUST use a different objective-name. 1658 Non-recognized objective-values (or parts thereof if it is a 1659 structure partially understood) MUST be ignored. 1661 The M_FLOOD message MUST be sent periodically. The default SHOULD be 1662 60 seconds, the value SHOULD be operator configurable but SHOULD be 1663 not smaller than 60 seconds. The frequency of sending MUST be such 1664 that the aggregate amount of periodic M_FLOODs from all flooding 1665 sources cause only negligible traffic across the ACP. The time-to- 1666 live (ttl) parameter SHOULD be 3.5 times the period so that up to 1667 three consecutive messages can be dropped before considering an 1668 announcement expired. In the example above, the ttl is 210000 msec, 1669 3.5 times 60 seconds. When a service announcer using these 1670 parameters unexpectedly dies immediately after sending the M_FLOOD, 1671 receivers would consider it expired 210 seconds later. When a 1672 receiver tries to connect to this dead service before this timeout, 1673 it will experience a failing connection and use that as an indication 1674 that the service instance is dead and select another instance of the 1675 same service instead (from another GRASP announcement). 1677 6.1.5.2. Renewal 1679 When performing renewal, the node SHOULD attempt to connect to the 1680 remembered EST server. If that fails, it SHOULD attempt to connect 1681 to an EST server learned via GRASP. The server with which 1682 certificate renewal succeeds SHOULD be remembered for the next 1683 renewal. 1685 Remembering the last renewal server and preferring it provides 1686 stickiness which can help diagnostics. It also provides some 1687 protection against off-path compromised ACP members announcing bogus 1688 information into GRASP. 1690 Renewal of certificates SHOULD start after less than 50% of the 1691 domain certificate lifetime so that network operations has ample time 1692 to investigate and resolve any problems that causes a node to not 1693 renew its domain certificate in time - and to allow prolonged periods 1694 of running parts of a network disconnected from any CA. 1696 6.1.5.3. Certificate Revocation Lists (CRLs) 1698 The ACP node SHOULD support revocation through CRL(s) via HTTP from 1699 one or more CRL Distribution Points (CRLDP). The CRLDP(s) MUST be 1700 indicated in the Domain Certificate when used. If the CRLDP URL uses 1701 an IPv6 address (ULA address when using the addressing rules 1702 specified in this document), the ACP node will connect to the CRLDP 1703 via the ACP. If the CRLDP uses a domain name, the ACP node will 1704 connect to the CRLDP via the Data-Plane. 1706 It is common to use domain names for CRLDP(s), but there is no 1707 requirement for the ACP to support DNS. Any DNS lookup in the Data- 1708 Plane is not only a possible security issue, but it would also not 1709 indicate whether the resolved address is meant to be reachable across 1710 the ACP. Therefore, the use of an IPv6 address versus the use of a 1711 DNS name doubles as an indicator whether or not to reach the CRLDP 1712 via the ACP. 1714 A CRLDP can be reachable across the ACP either by running it on a 1715 node with ACP or by connecting its node via an ACP connect interface 1716 (see Section 8.1). The CRLDP SHOULD use an ACP certificate for its 1717 HTTPs connections. The connecting ACP node SHOULD verify that the 1718 CRLDP certificate used during the HTTPs connection has the same ACP 1719 address as indicated in the CRLDP URL of the node's ACP certificate 1720 if the CRLDP URL uses an IPv6 address. 1722 6.1.5.4. Lifetimes 1724 Certificate lifetime may be set to shorter lifetimes than customary 1725 (1 year) because certificate renewal is fully automated via ACP and 1726 EST. The primary limiting factor for shorter certificate lifetimes 1727 is load on the EST server(s) and CA. It is therefore recommended 1728 that ACP certificates are managed via a CA chain where the assigning 1729 CA has enough performance to manage short lived certificates. See 1730 also Section 9.2.4 for discussion about an example setup achieving 1731 this. See also [I-D.ietf-acme-star]. 1733 When certificate lifetimes are sufficiently short, such as few hours, 1734 certificate revocation may not be necessary, allowing to simplify the 1735 overall certificate maintenance infrastructure. 1737 See Appendix A.2 for further optimizations of certificate maintenance 1738 when BRSKI can be used ("Bootstrapping Remote Secure Key 1739 Infrastructures", see [I-D.ietf-anima-bootstrapping-keyinfra]). 1741 6.1.5.5. Re-enrollment 1743 An ACP node may determine that its ACP certificate has expired, for 1744 example because the ACP node was powered down or disconnected longer 1745 than its certificate lifetime. In this case, the ACP node SHOULD 1746 convert to a role of a re-enrolling candidate ACP node. 1748 In this role, the node does maintain the TA and certificate chain 1749 associated with its ACP certificate exclusively for the purpose of 1750 re-enrollment, and attempts (or waits) to get re-enrolled with a new 1751 ACP certificate. The details depend on the mechanisms/protocols used 1752 by the ACP Registrars. 1754 Please refer to Section 6.10.7 and 1755 [I-D.ietf-anima-bootstrapping-keyinfra] for explanations about ACP 1756 Registrars and vouchers as used in the following text. When ACP is 1757 intended to be used without BRSKI, the details about BRSKI and 1758 vouchers in the following text can be skipped. 1760 When BRSKI is used (i.e.: on ACP nodes that are ANI nodes), the re- 1761 enrolling candidate ACP node would attempt to enroll like a candidate 1762 ACP node (BRSKI pledge), but instead of using the ACP nodes IDevID 1763 certificate, it SHOULD first attempt to use its ACP domain 1764 certificate in the BRSKI TLS authentication. The BRSKI registrar MAY 1765 honor this certificate beyond its expiration date purely for the 1766 purpose of re-enrollment. Using the ACP node's domain certificate 1767 allows the BRSKI registrar to learn that node's acp-node-name, so 1768 that the BRSKI registrar can re-assign the same ACP address 1769 information to the ACP node in the new ACP certificate. 1771 If the BRSKI registrar denies the use of the old ACP certificate, the 1772 re-enrolling candidate ACP node MUST re-attempt re-enrollment using 1773 its IDevID certificate as defined in BRSKI during the TLS connection 1774 setup. 1776 Both when the BRSKI connection is attempted with the old ACP 1777 certificate or the IDevID certificate, the re-enrolling candidate ACP 1778 node SHOULD authenticate the BRSKI registrar during TLS connection 1779 setup based on its existing TA certificate chain information 1780 associated with its old ACP certificate. The re-enrolling candidate 1781 ACP node SHOULD only fall back to requesting a voucher from the BRSKI 1782 registrar when this authentication fails during TLS connection setup. 1784 When other mechanisms than BRSKI are used for ACP certificate 1785 enrollment, the principles of the re-enrolling candidate ACP node are 1786 the same. The re-enrolling candidate ACP node attempts to 1787 authenticate any ACP Registrar peers during re-enrollment protocol/ 1788 mechanisms via its existing certificate chain/TA information and 1789 provides its existing ACP certificate and other identification (such 1790 as the IDevID certificate) as necessary to the registrar. 1792 Maintaining existing TA information is especially important when 1793 enrollment mechanisms are used that unlike BRSKI do not leverage a 1794 voucher mechanism to authenticate the ACP registrar and where 1795 therefore the injection of certificate failures could otherwise make 1796 the ACP node easily attackable remotely. 1798 When using BRSKI or other protocol/mechanisms supporting vouchers, 1799 maintaining existing TA information allows for re-enrollment of 1800 expired ACP certificates to be more lightweight, especially in 1801 environments where repeated acquisition of vouchers during the 1802 lifetime of ACP nodes may be operationally expensive or otherwise 1803 undesirable. 1805 6.1.5.6. Failing Certificates 1807 An ACP certificate is called failing in this document, if/when the 1808 ACP node to which the certificate was issued can determine that it 1809 was revoked (or explicitly not renewed), or in the absence of such 1810 explicit local diagnostics, when the ACP node fails to connect to 1811 other ACP nodes in the same ACP domain using its ACP certificate. 1812 For connection failures to determine the ACP certificate as the 1813 culprit, the peer should pass the domain membership check 1814 (Section 6.1.3) and other reasons for the connection failure can be 1815 excluded because of the connection error diagnostics. 1817 This type of failure can happen during setup/refresh of a secure ACP 1818 channel connections or any other use of the ACP certificate, such as 1819 for the TLS connection to an EST server for the renewal of the ACP 1820 domain certificate. 1822 Example reasons for failing certificates that the ACP node can only 1823 discover through connection failure are that the domain certificate 1824 or any of its signing certificates could have been revoked or may 1825 have expired, but the ACP node cannot self-diagnose this condition 1826 directly. Revocation information or clock synchronization may only 1827 be available across the ACP, but the ACP node cannot build ACP secure 1828 channels because ACP peers reject the ACP node's domain certificate. 1830 ACP nodes SHOULD support the option to determines whether its ACP 1831 certificate is failing, and when it does, put itself into the role of 1832 a re-enrolling candidate ACP node as explained above 1833 (Section 6.1.5.5). 1835 6.2. ACP Adjacency Table 1837 To know to which nodes to establish an ACP channel, every ACP node 1838 maintains an adjacency table. The adjacency table contains 1839 information about adjacent ACP nodes, at a minimum: Node-ID 1840 (identifier of the node inside the ACP, see Section 6.10.3 and 1841 Section 6.10.5), interface on which neighbor was discovered (by GRASP 1842 as explained below), link-local IPv6 address of neighbor on that 1843 interface, certificate (including acp-node-name). An ACP node MUST 1844 maintain this adjacency table. This table is used to determine to 1845 which neighbor an ACP connection is established. 1847 Where the next ACP node is not directly adjacent (i.e., not on a link 1848 connected to this node), the information in the adjacency table can 1849 be supplemented by configuration. For example, the Node-ID and IP 1850 address could be configured. See Section 8.2. 1852 The adjacency table MAY contain information about the validity and 1853 trust of the adjacent ACP node's certificate. However, subsequent 1854 steps MUST always start with the ACP domain membership check against 1855 the peer (see Section 6.1.3). 1857 The adjacency table contains information about adjacent ACP nodes in 1858 general, independently of their domain and trust status. The next 1859 step determines to which of those ACP nodes an ACP connection should 1860 be established. 1862 6.3. Neighbor Discovery with DULL GRASP 1864 [RFC Editor: GRASP draft is in RFC editor queue, waiting for 1865 dependencies, including ACP. Please ensure that references to I- 1866 D.ietf-anima-grasp that include section number references (throughout 1867 this document) will be updated in case any last-minute changes in 1868 GRASP would make those section references change. 1870 Discovery Unsolicited Link-Local (DULL) GRASP is a limited subset of 1871 GRASP intended to operate across an insecure link-local scope. See 1872 section 2.5.2 of [I-D.ietf-anima-grasp] for its formal definition. 1873 The ACP uses one instance of DULL GRASP for every L2 interface of the 1874 ACP node to discover link level adjacent candidate ACP neighbors. 1875 Unless modified by policy as noted earlier (Section 5 bullet point 1876 2.), native interfaces (e.g., physical interfaces on physical nodes) 1877 SHOULD be initialized automatically to a state in which ACP discovery 1878 can be performed and any native interfaces with ACP neighbors can 1879 then be brought into the ACP even if the interface is otherwise not 1880 configured. Reception of packets on such otherwise not configured 1881 interfaces MUST be limited so that at first only IPv6 StateLess 1882 Address Auto Configuration (SLAAC - [RFC4862]) and DULL GRASP work 1883 and then only the following ACP secure channel setup packets - but 1884 not any other unnecessary traffic (e.g., no other link-local IPv6 1885 transport stack responders for example). 1887 Note that the use of the IPv6 link-local multicast address 1888 (ALL_GRASP_NEIGHBORS) implies the need to use Multicast Listener 1889 Discovery Version 2 (MLDv2, see [RFC3810]) to announce the desire to 1890 receive packets for that address. Otherwise DULL GRASP could fail to 1891 operate correctly in the presence of MLD snooping, non-ACP enabled L2 1892 switches ([RFC4541]) - because those would stop forwarding DULL GRASP 1893 packets. Switches not supporting MLD snooping simply need to operate 1894 as pure L2 bridges for IPv6 multicast packets for DULL GRASP to work. 1896 ACP discovery SHOULD NOT be enabled by default on non-native 1897 interfaces. In particular, ACP discovery MUST NOT run inside the ACP 1898 across ACP virtual interfaces. See Section 9.3 for further, non- 1899 normative suggestions on how to enable/disable ACP at node and 1900 interface level. See Section 8.2.2 for more details about tunnels 1901 (typical non-native interfaces). See Section 7 for how ACP should be 1902 extended on devices operating (also) as L2 bridges. 1904 Note: If an ACP node also implements BRSKI to enroll its ACP 1905 certificate (see Appendix A.2 for a summary), then the above 1906 considerations also apply to GRASP discovery for BRSKI. Each DULL 1907 instance of GRASP set up for ACP is then also used for the discovery 1908 of a bootstrap proxy via BRSKI when the node does not have a domain 1909 certificate. Discovery of ACP neighbors happens only when the node 1910 does have the certificate. The node therefore never needs to 1911 discover both a bootstrap proxy and ACP neighbor at the same time. 1913 An ACP node announces itself to potential ACP peers by use of the 1914 "AN_ACP" objective. This is a synchronization objective intended to 1915 be flooded on a single link using the GRASP Flood Synchronization 1916 (M_FLOOD) message. In accordance with the design of the Flood 1917 message, a locator consisting of a specific link-local IP address, IP 1918 protocol number and port number will be distributed with the flooded 1919 objective. An example of the message is informally: 1921 [M_FLOOD, 12340815, h'fe80000000000000c0011001feef0000', 210000, 1922 [["AN_ACP", 4, 1, "IKEv2" ], 1923 [O_IPv6_LOCATOR, 1924 h'fe80000000000000c0011001feef0000', IPPROTO_UDP, 15000]] 1925 [["AN_ACP", 4, 1, "DTLS" ], 1926 [O_IPv6_LOCATOR, 1927 h'fe80000000000000c0011001feef0000', IPPROTO_UDP, 17000]] 1928 ] 1930 Figure 5: GRASP AN_ACP example 1932 The formal CDDL definition is: 1934 flood-message = [M_FLOOD, session-id, initiator, ttl, 1935 +[objective, (locator-option / [])]] 1937 objective = ["AN_ACP", objective-flags, loop-count, 1938 objective-value] 1940 objective-flags = sync-only ; as in the GRASP specification 1941 sync-only = 4 ; M_FLOOD only requires synchronization 1942 loop-count = 1 ; limit to link-local operation 1943 objective-value = method 1944 method = "IKEv2" / "DTLS" ; or future standard methods 1946 Figure 6: GRASP AN_ACP definition 1948 The objective-flags field is set to indicate synchronization. 1950 The loop-count is fixed at 1 since this is a link-local operation. 1952 In the above example the RECOMMENDED period of sending of the 1953 objective is 60 seconds. The indicated ttl of 210000 msec means that 1954 the objective would be cached by ACP nodes even when two out of three 1955 messages are dropped in transit. 1957 The session-id is a random number used for loop prevention 1958 (distinguishing a message from a prior instance of the same message). 1959 In DULL this field is irrelevant but has to be set according to the 1960 GRASP specification. 1962 The originator MUST be the IPv6 link local address of the originating 1963 ACP node on the sending interface. 1965 The 'objective-value' parameter is a string indicating the protocol 1966 available at the specified or implied locator. It is a protocol 1967 supported by the node to negotiate a secure channel. IKEv2 as shown 1968 above is the protocol used to negotiate an IPsec secure channel. 1970 The locator-option is optional and only required when the secure 1971 channel protocol is not offered at a well-defined port number, or if 1972 there is no well-defined port number. 1974 IKEv2 is the actual protocol used to negotiate an Internet Protocol 1975 security architecture (IPsec) connection. GRASP therefore indicates 1976 "IKEv2" and not "IPsec". If "IPsec" was used, this too could mean 1977 use of the obsolete older version IKE (v1) ([RFC2409]). IKEv2 has an 1978 IANA assigned port number 500, but in the above example, the 1979 candidate ACP neighbor is offering ACP secure channel negotiation via 1980 IKEv2 on port 15000 (purely to show through the example that GRASP 1981 allows to indicate the port number and it does not have to be the 1982 IANA assigned one). 1984 "DTLS" indicates DTLS 1.2. This can also be a newer version of the 1985 protocol as long as it can negotiate down to version 1.2 in the 1986 presence of a peer only speaking DTLS 1.2. There is no default UDP 1987 port for DTLS, it is always locally assigned by the node. For 1988 details, see Section 6.7.4. 1990 If a locator is included, it MUST be an O_IPv6_LOCATOR, and the IPv6 1991 address MUST be the same as the initiator address (these are DULL 1992 requirements to minimize third party DoS attacks). 1994 The secure channel methods defined in this document use the 1995 objective-values of "IKEv2" and "DTLS". There is no distinction 1996 between IKEv2 native and GRE-IKEv2 because this is purely negotiated 1997 via IKEv2. 1999 A node that supports more than one secure channel protocol method 2000 needs to flood multiple versions of the "AN_ACP" objective so that 2001 each method can be accompanied by its own locator-option. This can 2002 use a single GRASP M_FLOOD message as shown in Figure 5. 2004 Note that a node serving both as an ACP node and BRSKI Join Proxy may 2005 choose to distribute the "AN_ACP" objective and the respective BRSKI 2006 in the same M_FLOOD message, since GRASP allows multiple objectives 2007 in one message. This may be impractical though if ACP and BRSKI 2008 operations are implemented via separate software modules / ASAs. 2010 The result of the discovery is the IPv6 link-local address of the 2011 neighbor as well as its supported secure channel protocols (and non- 2012 standard port they are running on). It is stored in the ACP 2013 Adjacency Table (see Section 6.2), which then drives the further 2014 building of the ACP to that neighbor. 2016 Note that the DULL GRASP objective described intentionally does not 2017 include ACP nodes ACP certificate even though this would be useful 2018 for diagnostics and to simplify the security exchange in ACP secure 2019 channel security association protocols (see Section 6.7). The reason 2020 is that DULL GRASP messages are periodically multicasted across IPv6 2021 subnets and full certificates could easily lead to fragmented IPv6 2022 DULL GRASP multicast packets due to the size of a certificate. This 2023 would be highly undesirable. 2025 6.4. Candidate ACP Neighbor Selection 2027 An ACP node determines to which other ACP nodes in the adjacency 2028 table it should attempt to build an ACP connection. This is based on 2029 the information in the ACP Adjacency table. 2031 The ACP is established exclusively between nodes in the same domain. 2032 This includes all routing subdomains. Appendix A.7 explains how ACP 2033 connections across multiple routing subdomains are special. 2035 The result of the candidate ACP neighbor selection process is a list 2036 of adjacent or configured autonomic neighbors to which an ACP channel 2037 should be established. The next step begins that channel 2038 establishment. 2040 6.5. Channel Selection 2042 To avoid attacks, initial discovery of candidate ACP peers cannot 2043 include any non-protected negotiation. To avoid re-inventing and 2044 validating security association mechanisms, the next step after 2045 discovering the address of a candidate neighbor can only be to try 2046 first to establish a security association with that neighbor using a 2047 well-known security association method. 2049 From the use-cases it seems clear that not all type of ACP nodes can 2050 or need to connect directly to each other or are able to support or 2051 prefer all possible mechanisms. For example, code space limited IoT 2052 devices may only support DTLS because that code exists already on 2053 them for end-to-end security, but low-end in-ceiling L2 switches may 2054 only want to support Media Access Control Security (MacSec, see 2055 802.1AE ([MACSEC]) because that is also supported in their chips. 2056 Only a flexible gateway device may need to support both of these 2057 mechanisms and potentially more. Note that MacSec is not required by 2058 any profiles of the ACP in this specification. Instead, MacSec is 2059 mentioned as a likely next interesting secure channel protocol. Note 2060 also that the security model allows and requires for any-to-any 2061 authentication and authorization between all ACP nodes because there 2062 is also end-to-end and not only hop-by-hop authentication for secure 2063 channels. 2065 To support extensible secure channel protocol selection without a 2066 single common mandatory to implement (MTI) protocol, ACP nodes MUST 2067 try all the ACP secure channel protocols it supports and that are 2068 feasible because the candidate ACP neighbor also announced them via 2069 its AN_ACP GRASP parameters (these are called the "feasible" ACP 2070 secure channel protocols). 2072 To ensure that the selection of the secure channel protocols always 2073 succeeds in a predictable fashion without blocking, the following 2074 rules apply: 2076 o An ACP node may choose to attempt to initiate the different 2077 feasible ACP secure channel protocols it supports according to its 2078 local policies sequentially or in parallel, but it MUST support 2079 acting as a responder to all of them in parallel. 2081 o Once the first secure channel protocol succeeds, the two peers 2082 know each other's certificates because they are used by all secure 2083 channel protocols for mutual authentication. The node with the 2084 lower Node-ID in the ACP address of its ACP certificate becomes 2085 Bob, the one with the higher Node-ID in the certificate Alice. A 2086 peer with an empty ACP address field in its ACP certificate 2087 becomes Bob (this specification does not define such peers, only 2088 the interoperability with them). 2090 o Bob becomes passive, he does not attempt to further initiate ACP 2091 secure channel protocols with Alice and does not consider it to be 2092 an error when Alice closes secure channels. Alice becomes the 2093 active party, continues to attempt setting up secure channel 2094 protocols with Bob until she arrives at the best one from her view 2095 that also works with Bob. 2097 For example, originally Bob could have been the initiator of one ACP 2098 secure channel protocol that Bob prefers and the security association 2099 succeeded. The roles of Bob and Alice are then assigned and the 2100 connection setup is completed. The protocol could for example be 2101 IPsec via IKEv2 ("IP security", see [RFC4301] and "Internet Key 2102 Exchange protocol version 2", see [RFC7296]. It is now up to Alice 2103 to decide how to proceed. Even if the IPsec connection from Bob 2104 succeeded, Alice might prefer another secure protocol over IPsec 2105 (e.g., FOOBAR), and try to set that up with Bob. If that preference 2106 of Alice succeeds, she would close the IPsec connection. If no 2107 better protocol attempt succeeds, she would keep the IPsec 2108 connection. 2110 The following sequence of steps show this example in more detail. 2111 Each step is tagged with [{:}]. The connection is 2112 included to easier distinguish which of the two competing connections 2113 the step belong to, one initiated by Node 1, one initiated by Node 2. 2115 [1] Node 1 sends GRASP AN_ACP message to announce itself 2117 [2] Node 2 sends GRASP AN_ACP message to announce itself 2119 [3] Node 2 receives [1] from Node 1 2121 [4:C1] Because of [3], Node 2 starts as initiator on its 2122 preferred secure channel protocol towards Node 1. 2123 Connection C1. 2125 [5] Node 1 receives [2] from Node 2 2127 [6:C2] Because of [5], Node 1 starts as initiator on its 2128 preferred secure channel protocol towards Node 2. 2129 Connection C2. 2131 [7:C1] Node1 and Node2 have authenticated each others 2132 certificate on connection C1 as valid ACP peers. 2134 [8:C1] Node 1 certificate has lower ACP Node-ID than Node2, 2135 therefore Node 1 considers itself Bob and Node 2 Alice 2136 on connection C1. Connection setup C1 is completed. 2138 [9] Node 1 (Bob)) refrains from attempting any further secure 2139 channel connections to Node 2 (Alice) as learned from [2] 2140 because it knows from [8:C1] that it is Bob relative 2141 to Node 1. 2143 [10:C2] Node1 and Node2 have authenticated each others 2144 certificate on connection C2 (like [7:C1]). 2146 [11:C2] Node 1 certificate has lower ACP Node-ID than Node2, 2147 therefore Node 1 considers itself Bob and Node 2 Alice 2148 on connection C2, but they also identify that C2 is to the 2149 same mutual peer as their C1, so this has no further impact: 2150 the roles Alice and Bob where already assigned between these 2151 two peers by [8:C1]. 2153 [12:C2] Node 2 (Alice) closes C1. Node 1 (Bob) is fine with this, 2154 because of his role as Bob (since [8:C1]). 2156 [13] Node 2 (Alice) and Node 1 (Bob) start data transfer across 2157 C2, which makes it become a secure channel for the ACP. 2159 Figure 7: Secure Channel sequence of steps 2161 All this negotiation is in the context of an "L2 interface". Alice 2162 and Bob will build ACP connections to each other on every "L2 2163 interface" that they both connect to. An autonomic node MUST NOT 2164 assume that neighbors with the same L2 or link-local IPv6 addresses 2165 on different L2 interfaces are the same node. This can only be 2166 determined after examining the certificate after a successful 2167 security association attempt. 2169 6.6. Candidate ACP Neighbor verification 2171 Independent of the security association protocol chosen, candidate 2172 ACP neighbors need to be authenticated based on their domain 2173 certificate. This implies that any secure channel protocol MUST 2174 support certificate based authentication that can support the ACP 2175 domain membership check as defined in Section 6.1.3. If it fails, 2176 the connection attempt is aborted and an error logged. Attempts to 2177 reconnect MUST be throttled. The RECOMMENDED default is exponential 2178 base 2 backoff with a minimum delay of 10 seconds and a maximum delay 2179 of 640 seconds. 2181 Failure to authenticate an ACP neighbor when acting in the role of a 2182 responder of the security authentication protocol MUST NOT impact the 2183 attempts of the ACP node to attempt establishing a connection as an 2184 initiator. Only failed connection attempts as an initiator must 2185 cause throttling. This rule is meant to increase resilience of 2186 secure channel creation. Section 6.5 shows how simultaneous mutual 2187 secure channel setup collisions are resolved. 2189 6.7. Security Association (Secure Channel) protocols 2191 This section describes how ACP nodes establish secured data 2192 connections to automatically discovered or configured peers in the 2193 ACP. Section 6.3 above described how IPv6 subnet adjacent peers are 2194 discovered automatically. Section 8.2 describes how non IPv6 subnet 2195 adjacent peers can be configured. 2197 Section 6.12.5.2 describes how secure channels are mapped to virtual 2198 IPv6 subnet interfaces in the ACP. The simple case is to map every 2199 ACP secure channel into a separate ACP point-to-point virtual 2200 interface Section 6.12.5.2.1. When a single subnet has multiple ACP 2201 peers this results in multiple ACP point-to-point virtual interfaces 2202 across that underlying multi-party IPv6 subnet. This can be 2203 optimized with ACP multi-access virtual interfaces Section 6.12.5.2.2 2204 but the benefits of that optimization may not justify the complexity 2205 of that option. 2207 6.7.1. General considerations 2209 Due to Channel Selection (Section 6.5), ACP can support an evolving 2210 set of security association protocols and does not require support 2211 for a single network wide MTI. ACP nodes only need to implement 2212 those protocols required to interoperate with their candidate peers, 2213 not with potentially any node in the ACP domain. See Section 6.7.5 2214 for an example of this. 2216 The degree of security required on every hop of an ACP network needs 2217 to be consistent across the network so that there is no designated 2218 "weakest link" because it is that "weakest link" that would otherwise 2219 become the designated point of attack. When the secure channel 2220 protection on one link is compromised, it can be used to send/receive 2221 packets across the whole ACP network. Therefore, even though the 2222 security association protocols can be different, their minimum degree 2223 of security should be comparable. 2225 Secure channel protocols do not need to always support arbitrary L3 2226 connectivity between peers, but can leverage the fact that the 2227 standard use case for ACP secure channels is an L2 adjacency. Hence, 2228 L2 dependent mechanisms could be adopted for use as secure channel 2229 association protocols: 2231 L2 mechanisms such as strong encrypted radio technologies or [MACSEC] 2232 may offer equivalent encryption and the ACP security association 2233 protocol may only be required to authenticate ACP domain membership 2234 of a peer and/or derive a key for the L2 mechanism. Mechanisms to 2235 auto-discover and associate ACP peers leveraging such underlying L2 2236 security are possible and desirable to avoid duplication of 2237 encryption, but none are specified in this document. 2239 Strong physical security of a link may stand in where cryptographic 2240 security is infeasible. As there is no secure mechanism to 2241 automatically discover strong physical security solely between two 2242 peers, it can only be used with explicit configuration and that 2243 configuration too could become an attack vector. This document 2244 therefore only specifies with ACP connect (Section 8.1) one 2245 explicitly configured mechanism without any secure channel 2246 association protocol - for the case where both the link and the nodes 2247 attached to it have strong physical security. 2249 6.7.2. Common requirements 2251 The authentication of peers in any security association protocol MUST 2252 use the ACP certificate according to Section 6.1.3. Because auto- 2253 discovery of candidate ACP neighbors via GRASP (see Section 6.3) as 2254 specified in this document does not communicate the neighbors ACP 2255 certificate, and ACP nodes may not (yet) have any other network 2256 connectivity to retrieve certificates, any security association 2257 protocol MUST use a mechanism to communicate the certificate directly 2258 instead of relying on a referential mechanism such as communicating 2259 only a hash and/or URL for the certificate. 2261 A security association protocol MUST use Forward Secrecy (whether 2262 inherently or as part of a profile of the security association 2263 protocol). 2265 Because the ACP payload of legacy protocol payloads inside the ACP 2266 and hop-by-hop ACP flooded GRASP information is unencrypted, the ACP 2267 secure channel protocol requires confidentiality. Symmetric 2268 encryption for the transmission of secure channel data MUST use 2269 encryption schemes considered to be security wise equal to or better 2270 than 256 bit key strength, such as AES256. There MUST NOT be support 2271 for NULL encryption. 2273 Security association protocols typically only signal the End Entity 2274 certificate (e.g.: the ACP certificate) and any possible intermediate 2275 CA certificates for successful mutual authentication. The TA has to 2276 be mutually known and trusted and therefore its certificate does not 2277 need to be signalled for successful mutual authentication. 2278 Nevertheless, for use with ACP secure channel setup, there SHOULD be 2279 the option to include the TA certificate in the signaling to aid 2280 troubleshooting, see Section 9.1.1. 2282 Signalling of TA certificates may not be appropriate when the 2283 deployment is relying on a security model where the TA certificate 2284 content is considered confidential and only its hash is appropriate 2285 for signalling. ACP nodes SHOULD have a mechanism to select whether 2286 the TA certificate is signalled or not. Assuming that both options 2287 are possible with a specific secure channel protocol. 2289 An ACP secure channel MUST immediately be terminated when the 2290 lifetime of any certificate in the chain used to authenticate the 2291 neighbor expires or becomes revoked. This may not be standard 2292 behavior in secure channel protocols because the certificate 2293 authentication may only influences the setup of the secure channel in 2294 these protocols, but may not be re-validated during the lifetime of 2295 the secure connection in the absence of this requirement. 2297 When specifying an additional security association protocol for ACP 2298 secure channels beyond those covered in this document, protocol 2299 options SHOULD be eliminated that are not necessary to support 2300 devices that are expected to be able to support the ACP to minimize 2301 implementation complexity. For example, definitions for security 2302 protocols often include old/inferior security options required only 2303 to interoperate with existing devices that will not be a able to 2304 update to the currently preferred security options. Such old/ 2305 inferior security options do not need to be supported when a security 2306 association protocol is first specified for the ACP, strengthening 2307 the "weakest link" and simplifying ACP implementation overhead. 2309 6.7.3. ACP via IPsec 2311 An ACP node announces its ability to support IPsec, negotiated via 2312 IKEv2, as the ACP secure channel protocol using the "IKEv2" 2313 objective-value in the "AN_ACP" GRASP objective. 2315 The ACP usage of IPsec and IKEv2 mandates a profile with a narrow set 2316 of options of the current standards-track usage guidance for IPsec 2317 [RFC8221] and IKEv2 [RFC8247]. These option result in stringent 2318 security properties and can exclude deprecated/legacy algorithms 2319 because there is no need for interoperability with legacy equipment 2320 for ACP secure channels. Any such backward compatibility would lead 2321 only to increased attack surface and implementation complexity, for 2322 no benefit. 2324 6.7.3.1. Native IPsec 2326 An ACP node that is supporting native IPsec MUST use IPsec in tunnel 2327 mode, negotiated via IKEv2, and with IPv6 payload (e.g., ESP Next 2328 Header of 41). It MUST use local and peer link-local IPv6 addresses 2329 for encapsulation. Manual keying MUST NOT be used, see Section 6.1. 2330 Traffic Selectors are: 2332 TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 2334 TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 2336 IPsec tunnel mode is required because the ACP will route/forward 2337 packets received from any other ACP node across the ACP secure 2338 channels, and not only its own generated ACP packets. With IPsec 2339 transport mode (and no additional encapsulation header in the ESP 2340 payload), it would only be possible to send packets originated by the 2341 ACP node itself because the IPv6 addresses of the ESP must be the 2342 same as that of the outer IPv6 header. 2344 6.7.3.1.1. RFC8221 (IPsec/ESP) 2346 ACP IPsec implementations MUST comply with [RFC8221] (and its 2347 updates). The requirements from above and this section amend and 2348 superseded its requirements. 2350 AH MUST NOT be used (because it does not provide confidentiality). 2352 For the required ESP encryption algorithms in section 5 of [RFC8221] 2353 the following guidance applies: 2355 o ENCR_NULL AH MUST NOT be used (because it does not provide 2356 confidentiality). 2358 o ENCR_AES_GCM_16 is the only MTI ESP encryption algorithm for ACP 2359 via IPsec/ESP (it is already listed as MUST in [RFC8221]). 2361 o ENCR_AES_CBC and ENCR_AES_CCM_8 MAY be supported. If either 2362 provides higher performance than ENCR_AES_GCM_16 it SHOULD be 2363 supported. 2365 o ENCR_CHACHA20_POLY1305 SHOULD be supported at equal or higher 2366 performance than ENCR_AES_GCM_16. If that performance is not 2367 feasible, it MAY be supported. 2369 IKEv2 indicates an order for the offered algorithms. The algorithms 2370 SHOULD be ordered by performance. The first algorithm supported by 2371 both sides is generally choosen. 2373 Explanations: 2375 o There is no requirement to interoperate with legacy equipment in 2376 ACP secure channels, so a single MTI encryption algorithm for 2377 IPsec in ACP secure channels is sufficient for interoperability 2378 and allows for the most lightweight implementations. 2380 o ENCR_AES_GCM_16 is an authenticated encryption with associated 2381 data (AEAD) cipher mode, so no additional ESP authentication 2382 algorithm is needed, simplifying the MTI requirements of IPsec for 2383 the ACP. 2385 o There is no MTI requirement against support of ENCR_AES_CBC 2386 because ENCR_AES_GCM_16 is assumed to be feasible with less cost/ 2387 higher performance in modern devices hardware accelerated 2388 implementations compared to ENCR-AES_CBC. 2390 o ENCR_CHACHA20_POLY1305 is mandatory in [RFC8221] because of its 2391 target use as a fallback algorithm in case weaknesses in AES are 2392 uncoverered. Unfortunately, there is currently no way to 2393 automatically propagate across an ACP a policy to disallow use of 2394 AES based algorithms, so this target benefit of 2395 ENCR_CHACHA20_POLY1305 can not fully be adopted yet for the ACP. 2396 Therefore this algorithm is only recommended. Changing from AES 2397 to this algorithm at potentially big drop in performance could 2398 also render the ACP inoperable. Therefore the performance 2399 requirement against this algorithm so that it could become an 2400 effective security backup to AES for the ACP once a policy to 2401 switch over to it or prefer it is available in an ACP framework. 2403 [RFC8221] allows for 128-bit or 256-bit AES keys. This document 2404 mandates that only 256-bit AES keys MUST be supported. 2406 When [RFC8221] is updated, ACP implementations will need to consider 2407 legacy interoperability, and the IPsec WG has generally done a very 2408 good job of taking that into account in its recommendations. 2410 6.7.3.1.2. RFC8247 (IKEv2) 2412 [RFC8247] provides a baseline recommendation for mandatory to 2413 implement ciphers, integrity checks, pseudo-random-functions and 2414 Diffie-Hellman mechanisms. Those recommendations, and the 2415 recommendations of subsequent documents apply well to the ACP. 2416 Because IKEv2 for ACP secure channels is sufficient to be implemented 2417 in control plane software, rather than in ASIC hardware, and ACP 2418 nodes supporting IKEv2 are not assumed to be code-space constrained, 2419 and because existing IKEv2 implementations are expected to support 2420 [RFC8247] recommendations, this documents makes no attempt to 2421 simplify its recommendations for use with the ACP. 2423 See [IKEV2IANA] for IANA IKEv2 parameter names used in this text. 2425 ACP Nodes supporting IKEv2 MUST comply with [RFC8247] amended by the 2426 following requirements which constitute a policy statement as 2427 permitted by [RFC8247]. 2429 To signal the ACP certificate chain (including TA) as required by 2430 Section 6.7.2, "X.509 Certificate - Signature" payload in IKEv2 can 2431 be used. It is mandatory according to [RFC7296] section 3.6. 2433 ACP nodes SHOULD set up IKEv2 to only use the ACP certificate and TA 2434 when acting as an IKEv2 responder on the IPv6 link local address and 2435 port number indicated in the AN_ACP DULL GRASP announcements (see 2436 Section 6.3). 2438 When CERTREQ is received from a peer, and does not indicate any of 2439 this ACP nodes TA certificates, the ACP node SHOULD ignore the 2440 CERTREQ and continue sending its certificate chain including its TA 2441 as subject to the requirements and explanations in Section 6.7.2. 2442 This will not result in successful mutual authentication but assists 2443 diagnostics. 2445 Note that with IKEv2, failing authentication will only result in the 2446 responder receiving the certificate chain from the initiator, but not 2447 vice versa. Because ACP secure channel setup is symmetric (see 2448 Section 6.6), every non-malicious ACP neighbor will attempt to 2449 connect as an initiator though, allowing to obtain the diagnostic 2450 information about the neighbors certificate. 2452 In IKEv2, ACP nodes are identified by their ACP address. The 2453 ID_IPv6_ADDR IKEv2 identification payload MUST be used and MUST 2454 convey the ACP address. If the peer's ACP certificate includes a 2455 32HEXLC ACP address in the acp-node-name (not "0" or empty), the 2456 address in the IKEv2 identification payload MUST match it. See 2457 Section 6.1.3 for more information about "0" or empty ACP address 2458 fields in the acp-node-name. 2460 IKEv2 authentication MUST use authentication method 14 ("Digital 2461 Signature") for ACP certificates; this authentication method can be 2462 used with both RSA and ECDSA certificates, indicated by an ASN.1 2463 object AlgorithmIdentifier. 2465 The Digital Signature hash SHA2-512 MUST be supported (in addition to 2466 SHA2-256). 2468 The IKEv2 Diffie-Hellman key exchange group 19 (256-bit random ECP), 2469 listed as a SHOULD, is to be configured, along with the 2048-bit MODP 2470 (group 14). ECC provides a similar security level to finite-field 2471 (MODP) key exchange with a shorter key length, so is generally 2472 preferred absent other considerations. 2474 6.7.3.2. IPsec with GRE encapsulation 2476 In network devices it is often more common to implement high 2477 performance virtual interfaces on top of GRE encapsulation than on 2478 top of a "native" IPsec association (without any other encapsulation 2479 than those defined by IPsec). On those devices it may be beneficial 2480 to run the ACP secure channel on top of GRE protected by the IPsec 2481 association. 2483 The requirements for ESP/IPsec/IKEv2 with GRE are the same as for 2484 native IPsec (see Section 6.7.3.1) except that IPsec transport mode 2485 and next protocol GRE (47) are to be negotiated. Tunnel mode is not 2486 required because of GRE. Traffic Selectors are: 2488 TSi = (47, 0-65535, Initiator-IPv6-LL-addr ... Initiator-ACP-LL-addr) 2490 TSr = (47, 0-65535, Responder-IPv6-LL-addr ... Responder-IPv6-LL- 2491 addr) 2493 If IKEv2 initiator and responder support IPsec over GRE, it has to be 2494 preferred over native IPsec. The ACP IPv6 traffic has to be carried 2495 across GRE according to [RFC7676]. 2497 6.7.4. ACP via DTLS 2499 We define the use of ACP via DTLS in the assumption that it is likely 2500 the first transport encryption supported in some classes of 2501 constrained devices because DTLS is already used in those devices but 2502 IPsec is not, and code-space may be limited. 2504 An ACP node announces its ability to support DTLS v1.2 compliant with 2505 the requirements defined in this document as an ACP secure channel 2506 protocol in GRASP through the "DTLS" objective-value in the "AN_ACP" 2507 objective. 2509 To run ACP via UDP and DTLS v1.2 [RFC6347], a locally assigned UDP 2510 port is used that is announced as a parameter in the GRASP AN_ACP 2511 objective to candidate neighbors. This port can also be any newer 2512 version of DTLS as long as that version can negotiate a DTLS v1.2 2513 connection in the presence of an DTLS v1.2 only peer. 2515 All ACP nodes supporting DTLS as a secure channel protocol MUST 2516 adhere to the DTLS implementation recommendations and security 2517 considerations of BCP 195 [RFC7525] except with respect to the DTLS 2518 version. ACP nodes supporting DTLS MUST support DTLS 1.2. They MUST 2519 NOT support older versions of DTLS. Implementation MUST comply with 2520 BCP 195, [RFC7525]. 2522 Unlike for IPsec, no attempts are made to simplify the requirements 2523 of the BCP 195 recommendations because the expectation is that DTLS 2524 would be using software-only implementations where the ability to 2525 reuse of widely adopted implementations is more important than 2526 minizing the complexity of a hardware accelerated implementation 2527 which is known to be important for IPsec. 2529 DTLS v1.3 ([I-D.ietf-tls-dtls13]) is "backward compatible" with DTLS 2530 v1.2 (see section 1. of DTLS v1.3): A DTLS implementation supporting 2531 both DTLS v1.2 and DTLS v1.3 does comply with the above requirements 2532 of negoting to DTLS v1.2 in the presence of a DTLS v1.2 only peer, 2533 but using DTLS v1.3 when booth peers support it. 2535 Version v1.2 is the MTI version of DTLS in this specification because 2537 o There is more experience with DTLS v1.2 across the spectrum of 2538 target ACP nodes. 2540 o Firmware of lower end, embedded ACP nodes may not support a newer 2541 version for a long time. 2543 o There are significant changes of DTLS v1.3, such as a different 2544 record layer requiring time to gain implementation and deployment 2545 experience especially on lower end, code space limited devices. 2547 o The existing BCP [RFC7525] for DTLS v1.2 may equally take longer 2548 time to be updated with experience from a newer DTLS version. 2550 o There are no significant use-case relevant benefits of DTLS v1.3 2551 over DTLS v1.2 in the context of the ACP options for DTLS. For 2552 example, signaling performance improvements for session setup in 2553 DTLS v1.3 is not important for the ACP given the long-lived nature 2554 of ACP secure channel connections and the fact that DTLS 2555 connections are mostly link-local (short RTT). 2557 Nevertheless, newer versions of DTLS, such as DTLS v1.3 have more 2558 strict security requirements and use of the latest standard protocol 2559 version is for IETF security standards in general recommended. 2560 Therefore, ACP implementations are advised to support all the newer 2561 versions of DTLS that can still negotiate down to DTLS v1.2. 2563 [RFC-editor: if by the time of AUTH48, DTLS 1.3 would have evolved to 2564 be an RFC, then not only would the references to the DTLS v1.3 draft 2565 be changed to the RFC number, but that RFC is then going to be put 2566 into the normative list of references and the above paragraph is 2567 going to be amended to say: Implementations SHOULD support 2568 [DTLSv1.3-RFC]. This is not done right now, because there is no 2569 benefit in potentially waiting in RFC-editor queue for that RFC given 2570 how the text alreayd lays out a non-nrmative desire to support 2571 DTLSv1.3.] 2573 There is no additional session setup or other security association 2574 besides this simple DTLS setup. As soon as the DTLS session is 2575 functional, the ACP peers will exchange ACP IPv6 packets as the 2576 payload of the DTLS transport connection. Any DTLS defined security 2577 association mechanisms such as re-keying are used as they would be 2578 for any transport application relying solely on DTLS. 2580 6.7.5. ACP Secure Channel Profiles 2582 As explained in the beginning of Section 6.5, there is no single 2583 secure channel mechanism mandated for all ACP nodes. Instead, this 2584 section defines two ACP profiles (baseline and constrained) for ACP 2585 nodes that do introduce such requirements. 2587 A baseline ACP node MUST support IPsec natively and MAY support IPsec 2588 via GRE. If GRE is supported, it MAY be preferred over native IPec. 2589 A constrained ACP node that cannot support IPsec MUST support DTLS. 2590 An ACP node connecting an area of constrained ACP nodes with an area 2591 of baseline ACP nodes needs to support IPsec and DTLS and supports 2592 therefore the baseline and constrained profile. 2594 Explanation: Not all type of ACP nodes can or need to connect 2595 directly to each other or are able to support or prefer all possible 2596 secure channel mechanisms. For example, code space limited IoT 2597 devices may only support DTLS because that code exists already on 2598 them for end-to-end security, but high-end core routers may not want 2599 to support DTLS because they can perform IPsec in accelerated 2600 hardware but would need to support DTLS in an underpowered CPU 2601 forwarding path shared with critical control plane operations. This 2602 is not a deployment issue for a single ACP across these type of nodes 2603 as long as there are also appropriate gateway ACP nodes that support 2604 sufficiently many secure channel mechanisms to allow interconnecting 2605 areas of ACP nodes with a more constrained set of secure channel 2606 protocols. On the edge between IoT areas and high-end core networks, 2607 general-purpose routers that act as those gateways and that can 2608 support a variety of secure channel protocols is the norm already. 2610 IPsec natively with tunnel mode provides the shortest encapsulation 2611 overhead. GRE may be preferred by legacy implementations because the 2612 virtual interfaces required by ACP design in conjunction with secure 2613 channels have in the past more often been implemented for GRE than 2614 purely for native IPsec. 2616 ACP nodes need to specify in documentation the set of secure ACP 2617 mechanisms they support and should declare which profile they support 2618 according to above requirements. 2620 6.8. GRASP in the ACP 2622 6.8.1. GRASP as a core service of the ACP 2624 The ACP MUST run an instance of GRASP inside of it. It is a key part 2625 of the ACP services. The function in GRASP that makes it fundamental 2626 as a service of the ACP is the ability to provide ACP wide service 2627 discovery (using objectives in GRASP). 2629 ACP provides IP unicast routing via the RPL routing protocol (see 2630 Section 6.11). 2632 The ACP does not use IP multicast routing nor does it provide generic 2633 IP multicast services (the handling of GRASP link-local multicast 2634 messages is explained in Section 6.8.2). Instead, the ACP provides 2635 service discovery via the objective discovery/announcement and 2636 negotiation mechanisms of the ACP GRASP instance (services are a form 2637 of objectives). These mechanisms use hop-by-hop reliable flooding of 2638 GRASP messages for both service discovery (GRASP M_DISCOVERY 2639 messages) and service announcement (GRASP M_FLOOD messages). 2641 See Appendix A.5 for discussion about this design choice of the ACP. 2643 6.8.2. ACP as the Security and Transport substrate for GRASP 2645 In the terminology of GRASP ([I-D.ietf-anima-grasp]), the ACP is the 2646 security and transport substrate for the GRASP instance run inside 2647 the ACP ("ACP GRASP"). 2649 This means that the ACP is responsible for ensuring that this 2650 instance of GRASP is only sending messages across the ACP GRASP 2651 virtual interfaces. Whenever the ACP adds or deletes such an 2652 interface because of new ACP secure channels or loss thereof, the ACP 2653 needs to indicate this to the ACP instance of GRASP. The ACP exists 2654 also in the absence of any active ACP neighbors. It is created when 2655 the node has a domain certificate, and continues to exist even if all 2656 of its neighbors cease operation. 2658 In this case ASAs using GRASP running on the same node would still 2659 need to be able to discover each other's objectives. When the ACP 2660 does not exist, ASAs leveraging the ACP instance of GRASP via APIs 2661 MUST still be able to operate, and MUST be able to understand that 2662 there is no ACP and that therefore the ACP instance of GRASP cannot 2663 operate. 2665 The following explanation how ACP acts as the security and transport 2666 substrate for GRASP is visualized in Figure 8 below. 2668 GRASP unicast messages inside the ACP always use the ACP address. 2669 Link-local addresses from the ACP VRF MUST NOT be used inside 2670 objectives. GRASP unicast messages inside the ACP are transported 2671 via TLS which MUST comply with [RFC7525] execept that only TLS 1.2 2672 ([RFC5246]) is REQUIRED and TLS 1.3 ([RFC8446] is RECOMMENDED. There 2673 is no need for older version backward compatibility in the new use- 2674 case of ACP. Mutual authentication MUST use the ACP domain 2675 membership check defined in (Section 6.1.3). 2677 GRASP link-local multicast messages are targeted for a specific ACP 2678 virtual interface (as defined Section 6.12.5) but are sent by the ACP 2679 into an ACP GRASP virtual interface that is constructed from the TCP 2680 connection(s) to the IPv6 link-local neighbor address(es) on the 2681 underlying ACP virtual interface. If the ACP GRASP virtual interface 2682 has two or more neighbors, the GRASP link-local multicast messages 2683 are replicated to all neighbor TCP connections. 2685 TLS for GRASP MUST offer TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and 2686 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 and MUST NOT offer options 2687 with less than 256 bit symmetric key strength or hash strength of 2688 less han SHA384. TLS for GRASP MUST also include the "Supported 2689 Elliptic Curves" extension, it MUST support support the NIST P-256 2690 (secp256r1) and P-384 (secp384r1(24)) curves [RFC4492]. In addition, 2691 GRASP TLS clients SHOULD send an ec_point_formats extension with a 2692 single element, "uncompressed". For further interoperability 2693 recommendations, GRASP TLS implementations SHOULD follow [RFC7525]. 2695 TCP and TLS connections for GRASP in the ACP use the IANA assigned 2696 TCP port for GRASP (7107). Effectively the transport stack is 2697 expected to be TLS for connections from/to the ACP address (e.g., 2698 global scope address(es)) and TCP for connections from/to link-local 2699 addresses on the ACP virtual interfaces. The latter ones are only 2700 used for flooding of GRASP messages. 2702 ..............................ACP.............................. 2703 . . 2704 . /-GRASP-flooding-\ ACP GRASP instance . 2705 . / \ A 2706 . GRASP GRASP GRASP C 2707 . link-local unicast link-local P 2708 . multicast messages multicast . 2709 . messages | messages . 2710 . | | | . 2711 ............................................................... 2712 . v v v ACP security and transport . 2713 . | | | substrate for GRASP . 2714 . | | | . 2715 . | ACP GRASP | - ACP GRASP A 2716 . | Loopback | Loopback interface C 2717 . | interface | - ACP-cert auth P 2718 . | TLS | . 2719 . ACP GRASP | ACP GRASP - ACP GRASP virtual . 2720 . subnet1 | subnet2 virtual interfaces . 2721 . TCP | TCP . 2722 . | | | . 2723 ............................................................... 2724 . | | | ^^^ Users of ACP (GRASP/ASA) . 2725 . | | | ACP interfaces/addressing . 2726 . | | | . 2727 . | | | A 2728 . | ACP-Loopback Interf.| <- ACP Loopback interface C 2729 . | ACP-address | - address (global ULA) P 2730 . subnet1 | subnet2 <- ACP virtual interfaces . 2731 . link-local | link-local - link-local addresses . 2732 ............................................................... 2733 . | | | ACP VRF . 2734 . | RPL-routing | virtual routing and forwarding . 2735 . | /IP-Forwarding\ | A 2736 . | / \ | C 2737 . ACP IPv6 packets ACP IPv6 packets P 2738 . |/ \| . 2739 . IPsec/DTLS IPsec/DTLS - ACP-cert auth . 2740 ............................................................... 2741 | | Data-Plane 2742 | | 2743 | | - ACP secure channel 2744 link-local link-local - encapsulation addresses 2745 subnet1 subnet2 - Data-Plane interfaces 2746 | | 2747 ACP-Nbr1 ACP-Nbr2 2749 Figure 8: ACP as security and transport substrate for GRASP 2751 6.8.2.1. Discussion 2753 TCP encapsulation for GRASP M_DISCOVERY and M_FLOOD link local 2754 messages is used because these messages are flooded across 2755 potentially many hops to all ACP nodes and a single link with even 2756 temporary packet loss issues (e.g., WiFi/Powerline link) can reduce 2757 the probability for loss free transmission so much that applications 2758 would want to increase the frequency with which they send these 2759 messages. Such shorter periodic retransmission of datagrams would 2760 result in more traffic and processing overhead in the ACP than the 2761 hop-by-hop reliable retransmission mechanism by TCP and duplicate 2762 elimination by GRASP. 2764 TLS is mandated for GRASP non-link-local unicast because the ACP 2765 secure channel mandatory authentication and encryption protects only 2766 against attacks from the outside but not against attacks from the 2767 inside: Compromised ACP members that have (not yet) been detected and 2768 removed (e.g., via domain certificate revocation / expiry). 2770 If GRASP peer connections were to use just TCP, compromised ACP 2771 members could simply eavesdrop passively on GRASP peer connections 2772 for whom they are on-path ("Man In The Middle" - MITM) or intercept 2773 and modify them. With TLS, it is not possible to completely 2774 eliminate problems with compromised ACP members, but attacks are a 2775 lot more complex: 2777 Eavesdropping/spoofing by a compromised ACP node is still possible 2778 because in the model of the ACP and GRASP, the provider and consumer 2779 of an objective have initially no unique information (such as an 2780 identity) about the other side which would allow them to distinguish 2781 a benevolent from a compromised peer. The compromised ACP node would 2782 simply announce the objective as well, potentially filter the 2783 original objective in GRASP when it is a MITM and act as an 2784 application level proxy. This of course requires that the 2785 compromised ACP node understand the semantics of the GRASP 2786 negotiation to an extent that allows it to proxy it without being 2787 detected, but in an ACP environment this is quite likely public 2788 knowledge or even standardized. 2790 The GRASP TLS connections are run the same as any other ACP traffic 2791 through the ACP secure channels. This leads to double 2792 authentication/encryption, which has the following benefits: 2794 o Secure channel methods such as IPsec may provide protection 2795 against additional attacks, for example reset-attacks. 2797 o The secure channel method may leverage hardware acceleration and 2798 there may be little or no gain in eliminating it. 2800 o There is no different security model for ACP GRASP from other ACP 2801 traffic. Instead, there is just another layer of protection 2802 against certain attacks from the inside which is important due to 2803 the role of GRASP in the ACP. 2805 6.9. Context Separation 2807 The ACP is in a separate context from the normal Data-Plane of the 2808 node. This context includes the ACP channels' IPv6 forwarding and 2809 routing as well as any required higher layer ACP functions. 2811 In classical network system, a dedicated VRF is one logical 2812 implementation option for the ACP. If possible by the systems 2813 software architecture, separation options that minimize shared 2814 components are preferred, such as a logical container or virtual 2815 machine instance. The context for the ACP needs to be established 2816 automatically during bootstrap of a node. As much as possible it 2817 should be protected from being modified unintentionally by ("Data- 2818 Plane") configuration. 2820 Context separation improves security, because the ACP is not 2821 reachable from the Data-Plane routing or forwarding table(s). Also, 2822 configuration errors from the Data-Plane setup do not affect the ACP. 2824 6.10. Addressing inside the ACP 2826 The channels explained above typically only establish communication 2827 between two adjacent nodes. In order for communication to happen 2828 across multiple hops, the autonomic control plane requires ACP 2829 network wide valid addresses and routing. Each ACP node creates a 2830 Loopback interface with an ACP network wide unique address (prefix) 2831 inside the ACP context (as explained in in Section 6.9). This 2832 address may be used also in other virtual contexts. 2834 With the algorithm introduced here, all ACP nodes in the same routing 2835 subdomain have the same /48 ULA prefix. Conversely, ULA global IDs 2836 from different domains are unlikely to clash, such that two ACP 2837 networks can be merged, as long as the policy allows that merge. See 2838 also Section 10.1 for a discussion on merging domains. 2840 Links inside the ACP only use link-local IPv6 addressing, such that 2841 each node's ACP only requires one routable address prefix. 2843 6.10.1. Fundamental Concepts of Autonomic Addressing 2845 o Usage: Autonomic addresses are exclusively used for self- 2846 management functions inside a trusted domain. They are not used 2847 for user traffic. Communications with entities outside the 2848 trusted domain use another address space, for example normally 2849 managed routable address space (called "Data-Plane" in this 2850 document). 2852 o Separation: Autonomic address space is used separately from user 2853 address space and other address realms. This supports the 2854 robustness requirement. 2856 o Loopback-only: Only ACP Loopback interfaces (and potentially those 2857 configured for "ACP connect", see Section 8.1) carry routable 2858 address(es); all other interfaces (called ACP virtual interfaces) 2859 only use IPv6 link local addresses. The usage of IPv6 link local 2860 addressing is discussed in [RFC7404]. 2862 o Use-ULA: For Loopback interfaces of ACP nodes, we use ULA with L=1 2863 (as defined in section 3.1 of [RFC4193]). Note that the random 2864 hash for ACP Loopback addresses uses the definition in 2865 Section 6.10.2 and not the one of [RFC4193] section 3.2.2. 2867 o No external connectivity: They do not provide access to the 2868 Internet. If a node requires further reaching connectivity, it 2869 should use another, traditionally managed address scheme in 2870 parallel. 2872 o Addresses in the ACP are permanent, and do not support temporary 2873 addresses as defined in [RFC4941]. 2875 o Addresses in the ACP are not considered sensitive on privacy 2876 grounds because ACP nodes are not expected to be end-user host. 2877 All ACP nodes are in one (potentially federated) administrative 2878 domain. They are assumed to be to be candidate hosts of ACP 2879 traffic amongst each other or transit thereof. There are no 2880 transit nodes less privileged to know about the identity of other 2881 hosts in the ACP. Therefore, ACP addresses do not need to be 2882 pseudo-random as discussed in [RFC7721]. Because they are not 2883 propagated to untrusted (non ACP) nodes and stay within a domain 2884 (of trust), we also consider them not to be subject to scanning 2885 attacks. 2887 The ACP is based exclusively on IPv6 addressing, for a variety of 2888 reasons: 2890 o Simplicity, reliability and scale: If other network layer 2891 protocols were supported, each would have to have its own set of 2892 security associations, routing table and process, etc. 2894 o Autonomic functions do not require IPv4: Autonomic functions and 2895 autonomic service agents are new concepts. They can be 2896 exclusively built on IPv6 from day one. There is no need for 2897 backward compatibility. 2899 o OAM protocols do not require IPv4: The ACP may carry OAM 2900 protocols. All relevant protocols (SNMP, TFTP, SSH, SCP, Radius, 2901 Diameter, ...) are available in IPv6. See also [RFC8368] for how 2902 ACP could be made to interoperate with IPv4 only OAM. 2904 Further explanation about the addressing and routing related reasons 2905 for the choice of the autonomous ACP addressing can be found in 2906 Section 6.12.5.1. 2908 6.10.2. The ACP Addressing Base Scheme 2910 The Base ULA addressing scheme for ACP nodes has the following 2911 format: 2913 8 40 2 78 2914 +--+-------------------------+------+------------------------------+ 2915 |fd| hash(routing-subdomain) | Type | (sub-scheme) | 2916 +--+-------------------------+------+------------------------------+ 2918 Figure 9: ACP Addressing Base Scheme 2920 The first 48-bits follow the ULA scheme, as defined in [RFC4193], to 2921 which a type field is added: 2923 o "fd" identifies a locally defined ULA address. 2925 o The 40-bits ULA "global ID" (term from [RFC4193]) for ACP 2926 addresses carried in the acp-node-name in the ACP certificates are 2927 the first 40-bits of the SHA256 hash of the routing subdomain from 2928 the same acp-node-name. In the example of Section 6.1.2, the 2929 routing subdomain is "area51.research.acp.example.com" and the 2930 40-bits ULA "global ID" 89b714f3db. 2932 o When creating a new routing-subdomain for an existing autonomic 2933 network, it MUST be ensured, that rsub is selected so the 2934 resulting hash of the routing-subdomain does not collide with the 2935 hash of any pre-existing routing-subdomains of the autonomic 2936 network. This ensures that ACP addresses created by registrars 2937 for different routing subdomains do not collide with each others. 2939 o To allow for extensibility, the fact that the ULA "global ID" is a 2940 hash of the routing subdomain SHOULD NOT be assumed by any ACP 2941 node during normal operations. The hash function is only executed 2942 during the creation of the certificate. If BRSKI is used then the 2943 BRSKI registrar will create the acp-node-name in response to the 2944 EST Certificate Signing Request (CSR) Attribute Request message by 2945 the pledge. 2947 o Establishing connectivity between different ACP (different acp- 2948 domain-name) is outside the scope of this specification. If it is 2949 being done through future extensions, then the rsub of all 2950 routing-subdomains across those autonomic networks need to be 2951 selected so the resulting routing-subdomain hashes do not collide. 2952 For example a large cooperation with its own private TA may want 2953 to create different autonomic networks that initially should not 2954 be able to connect but where the option to do so should be kept 2955 open. When taking this future possibility into account, it is 2956 easy to always select rsub so that no collisions happen. 2958 o Type: This field allows different address sub-schemes. This 2959 addresses the "upgradability" requirement. Assignment of types 2960 for this field will be maintained by IANA. 2962 The sub-scheme may imply a range or set of addresses assigned to the 2963 node, this is called the ACP address range/set and explained in each 2964 sub-scheme. 2966 Please refer to Section 6.10.7 and Appendix A.1 for further 2967 explanations why the following Sub-Addressing schemes are used and 2968 why multiple are necessary. 2970 The following summarizes the addressing Sub-Schemes: 2972 +------+-----+-----------------+-------+------------+ 2973 | Type | Z | name | F-bit | V-bit size | 2974 +------+-----+-----------------+-------+------------+ 2975 | 0x00 | 0 | ACP-Zone | N/A | 1 bit | 2976 +------+-----+-----------------+-------+------------+ 2977 | 0x00 | 1 | ACP-Manual | N/A | 1 bit | 2978 +------+-----+-----------------+-------+------------+ 2979 | 0x01 | N/A | ACP-VLong-8 | 0 | 8 bits | 2980 +------+-----+-----------------+-------+------------+ 2981 | 0x01 | N/A | ACP-VLong-16 | 1 | 16 bits | 2982 +------+-----+-----------------+-------+------------+ 2984 Figure 10: Addressing schemes 2986 6.10.3. ACP Zone Addressing Sub-Scheme (ACP-Zone) 2988 This sub-scheme is used when the Type field of the base scheme is 2989 0x00 and the Z bit is 0x0. 2991 64 64 2992 +-----------------+---+---------++-----------------------------+---+ 2993 | (base scheme) | Z | Zone-ID || Node-ID | 2994 | | | || Registrar-ID | Node-Number| V | 2995 +-----------------+---+---------++--------------+--------------+---+ 2996 50 1 13 48 15 1 2998 Figure 11: ACP Zone Addressing Sub-Scheme 3000 The fields are defined as follows: 3002 o Type: MUST be 0x0. 3004 o Z: MUST be 0x0. 3006 o Zone-ID: A value for a network zone. 3008 o Node-ID: A unique value for each node. 3010 The 64-bit Node-ID must be unique across the ACP domain for each 3011 node. It is derived and composed as follows: 3013 o Registrar-ID (48-bit): A number unique inside the domain that 3014 identifies the ACP registrar which assigned the Node-ID to the 3015 node. One or more domain-wide unique identifiers of the ACP 3016 registrar can be used for this purpose. See Section 6.10.7.2. 3018 o Node-Number: Number to make the Node-ID unique. This can be 3019 sequentially assigned by the ACP Registrar owning the Registrar- 3020 ID. 3022 o V (1-bit): Virtualization bit: 0: Indicates the ACP itself ("ACP 3023 node base system); 1: Indicates the optional "host" context on the 3024 ACP node (see below). 3026 In the ACP Zone Addressing Sub-Scheme, the ACP address in the 3027 certificate has V field as all zero bits. 3029 The ACP address set of the node includes addresses with any Zone-ID 3030 value and any V value. No two nodes in the same ACP can have the 3031 same Node-ID, but differerent Zone-IDs. 3033 The Virtual bit in this sub-scheme allows the easy addition of the 3034 ACP as a component to existing systems without causing problems in 3035 the port number space between the services in the ACP and the 3036 existing system. V:0 is the ACP router (autonomic node base system), 3037 V:1 is the host with pre-existing transport endpoints on it that 3038 could collide with the transport endpoints used by the ACP router. 3039 The ACP host could for example have a p2p virtual interface with the 3040 V:0 address as its router into the ACP. Depending on the software 3041 design of ASAs, which is outside the scope of this specification, 3042 they may use the V:0 or V:1 address. 3044 The location of the V bit(s) at the end of the address allows the 3045 announcement of a single prefix for each ACP node. For example, in a 3046 network with 20,000 ACP nodes, this avoid 20,000 additional routes in 3047 the routing table. 3049 It is RECOMMENDED that only Zone-ID 0 is used unless it is meant to 3050 be used in conjunction with operational practices for partial/ 3051 incremental adoption of the ACP as described in Section 9.4. 3053 Note: Zones and Zone-ID as defined here are not related to [RFC4007] 3054 zones or zone_id. ACP zone addresses are not scoped (reachable only 3055 from within an RFC4007 zone) but reachable across the whole ACP. An 3056 RFC4007 zone_id is a zone index that has only local significance on a 3057 node, whereas an ACP Zone-ID is an identifier for an ACP zone that is 3058 unique across that ACP. 3060 6.10.4. ACP Manual Addressing Sub-Scheme (ACP-Manual) 3062 This sub-scheme is used when the Type field of the base scheme is 3063 0x00 and the Z bit is 0x1. 3065 64 64 3066 +---------------------+---+----------++-----------------------------+ 3067 | (base scheme) | Z | Subnet-ID|| Interface Identifier | 3068 +---------------------+---+----------++-----------------------------+ 3069 50 1 13 3071 Figure 12: ACP Manual Addressing Sub-Scheme 3073 The fields are defined as follows: 3075 o Type: MUST be 0x0. 3077 o Z: MUST be 0x1. 3079 o Subnet-ID: Configured subnet identifier. 3081 o Interface Identifier. 3083 This sub-scheme is meant for "manual" allocation to subnets where the 3084 other addressing schemes cannot be used. The primary use case is for 3085 assignment to ACP connect subnets (see Section 8.1.1). 3087 "Manual" means that allocations of the Subnet-ID need to be done 3088 today with pre-existing, non-autonomic mechanisms. Every subnet that 3089 uses this addressing sub-scheme needs to use a unique Subnet-ID 3090 (unless some anycast setup is done). 3092 The Z bit field was added to distinguish Zone addressing and manual 3093 addressing sub-schemes without requiring one more bit in the base 3094 scheme and therefore allowing for the Vlong scheme (described below) 3095 to have one more bit available. 3097 Manual addressing sub-scheme addresses SHOULD NOT be used in ACP 3098 certificates. Any node capable to build ACP secure channels and 3099 permitted by Registrar policy to participate in building ACP secure 3100 channels SHOULD receive an ACP address (prefix) from one of the other 3101 ACP addressing sub-schemes. Nodes not capable (or permitted) to 3102 participate in ACP secure channels can connect to the ACP via ACP 3103 connect interfaces of ACP edge nodes (see Section 8.1), without 3104 setting up an ACP secure channel. Their ACP certificate MUST include 3105 an empty acp-address to indicate that their ACP certificate is only 3106 usable for non- ACP secure channel authentication, such as end-to-end 3107 transport connections across the ACP or Data-Plane. 3109 Address management of ACP connect subnets is done using traditional 3110 assignment methods and existing IPv6 protocols. See Section 8.1.3 3111 for details. 3113 6.10.5. ACP Vlong Addressing Sub-Scheme (ACP-VLong-8/ACP-VLong-16 3115 This sub-scheme is used when the Type field of the base scheme is 3116 0x01. 3118 50 78 3119 +---------------------++-----------------------------+----------+ 3120 | (base scheme) || Node-ID | 3121 | || Registrar-ID |F| Node-Number| V | 3122 +---------------------++--------------+--------------+----------+ 3123 50 46 1 23/15 8/16 3125 Figure 13: ACP Vlong Addressing Sub-Scheme 3127 This addressing scheme foregoes the Zone-ID field to allow for 3128 larger, flatter routed networks (e.g., as in IoT) with 8421376 Node- 3129 Numbers (2^23+2^15). It also allows for up to 2^16 (i.e. 65536) 3130 different virtualized addresses within a node, which could be used to 3131 address individual software components in an ACP node. 3133 The fields are the same as in the Zone-ID sub-scheme with the 3134 following refinements: 3136 o F: format bit. This bit determines the format of the subsequent 3137 bits. 3139 o V: Virtualization bit: this is a field that is either 8 or 16 3140 bits. For F=0, it is 8 bits, for F=1 it is 16 bits. The V bits 3141 are assigned by the ACP node. In the ACP certificate's ACP 3142 address Section 6.1.2, the V-bits are always set to 0. 3144 o Registrar-ID: To maximize Node-Number and V, the Registrar-ID is 3145 reduced to 46-bits. One or more domain-wide unique identifiers of 3146 the ACP registrar can be used for this purpose. See 3147 Section 6.10.7.2. 3149 o The Node-Number is unique to each ACP node. There are two formats 3150 for the Node-Number. When F=0, the node-number is 23 bits, for 3151 F=1 it is 15 bits. Each format of node-number is considered to be 3152 in a unique number space. 3154 The F=0 bit format addresses are intended to be used for "general 3155 purpose" ACP nodes that would potentially have a limited number (< 3156 256) of clients (ASA/Autonomic Functions or legacy services) of the 3157 ACP that require separate V(irtual) addresses. 3159 The F=1 bit Node-Numbers are intended for ACP nodes that are ACP edge 3160 nodes (see Section 8.1.1) or that have a large number of clients 3161 requiring separate V(irtual) addresses. For example large SDN 3162 controllers with container modular software architecture (see 3163 Section 8.1.2). 3165 In the Vlong addressing sub-scheme, the ACP address in the 3166 certificate has all V field bits as zero. The ACP address set for 3167 the node includes any V value. 3169 6.10.6. Other ACP Addressing Sub-Schemes 3171 Before further addressing sub-schemes are defined, experience with 3172 the schemes defined here should be collected. The schemes defined in 3173 this document have been devised to allow hopefully sufficiently 3174 flexible setup of ACPs for a variety of situation. These reasons 3175 also lead to the fairly liberal use of address space: The Zone 3176 Addressing Sub-Scheme is intended to enable optimized routing in 3177 large networks by reserving bits for Zone-ID's. The Vlong addressing 3178 sub-scheme enables the allocation of 8/16-bit of addresses inside 3179 individual ACP nodes. Both address spaces allow distributed, 3180 uncoordinated allocation of node addresses by reserving bits for the 3181 registrar-ID field in the address. 3183 IANA is asked need to assign a new "type" for each new addressing 3184 sub-scheme. With the current allocations, only 2 more schemes are 3185 possible, so the last addressing scheme MUST provide further 3186 extensions (e.g., by reserving bits from it for further extensions). 3188 6.10.7. ACP Registrars 3190 ACP registrars are responsible to enroll candidate ACP nodes with ACP 3191 certificates and associated trust anchor(s). They are also 3192 responsible that an acp-node-name field is included in the ACP 3193 certificate carrying the ACP domain name and the ACP nodes ACP 3194 address prefix. This address prefix is intended to persist unchanged 3195 through the lifetime of the ACP node. 3197 Because of the ACP addressing sub-schemes, an ACP domain can have 3198 multiple distributed ACP registrars that do not need to coordinate 3199 for address assignment. ACP registrars can also be sub-CAs, in which 3200 case they can also assign ACP certificates without dependencies 3201 against a (shared) TA (except during renewals of their own 3202 certificates). 3204 ACP registrars are PKI registration authorities (RA) enhanced with 3205 the handling of the ACP certificate specific fields. They request 3206 certificates for ACP nodes from a Certification Authority through any 3207 appropriate mechanism (out of scope in this document, but required to 3208 be BRSKI for ANI registrars). Only nodes that are trusted to be 3209 compliant with the requirements against registrar described in this 3210 section can be given the necessary credentials to perform this RA 3211 function, such as credentials for the BRSKI connection to the CA for 3212 ANI registrars. 3214 6.10.7.1. Use of BRSKI or other Mechanism/Protocols 3216 Any protocols or mechanisms may be used as ACP registrars, as long as 3217 the resulting ACP certificate and TA certificate(s) allow to perform 3218 the ACP domain membership described in Section 6.1.3 with other ACP 3219 domain members, and meet the ACP addressing requirements for its acp- 3220 node-name as described further below in this section. 3222 An ACP registrar could be a person deciding whether to enroll a 3223 candidate ACP node and then orchestrating the enrollment of the ACP 3224 certificate and associated TA, using command line or web based 3225 commands on the candidate ACP node and TA to generate and sign the 3226 ACP certificate and configure certificate and TA onto the node. 3228 The only currently defined protocol for ACP registrars is BRSKI 3229 ([I-D.ietf-anima-bootstrapping-keyinfra]). When BRSKI is used, the 3230 ACP nodes are called ANI nodes, and the ACP registrars are called 3231 BRSKI or ANI registrars. The BRSKI specification does not define the 3232 handling of the acp-node-name field because the rules do not depend 3233 on BRSKI but apply equally to any protocols/mechanisms an ACP 3234 registrar may use. 3236 6.10.7.2. Unique Address/Prefix allocation 3238 ACP registrars MUST NOT allocate ACP address prefixes to ACP nodes 3239 via the acp-node-name that would collide with the ACP address 3240 prefixes of other ACP nodes in the same ACP domain. This includes 3241 both prefixes allocated by the same ACP registrar to different ACP 3242 nodes as well as prefixes allocated by other ACP registrars for the 3243 same ACP domain. 3245 To support such unique address allocation, an ACP registrar MUST have 3246 one or more 46-bit identifiers unique across the ACP domain which is 3247 called the Registrar-ID. Allocation of Registrar-ID(s) to an ACP 3248 registrar can happen through OAM mechanisms in conjunction with some 3249 database / allocation orchestration. 3251 ACP registrars running on physical devices with known globally unique 3252 EUI-48 MAC address(es) can use the lower 46 bits of those address(es) 3253 as unique Registrar-IDs without requiring any external signaling/ 3254 configuration (the upper two bits, V and U are not uniquely assigned 3255 but functional). This approach is attractive for distributed, non- 3256 centrally administered, lightweight ACP registrar implementations. 3257 There is no mechanism to deduce from a MAC address itself whether it 3258 is actually uniquely assigned. Implementations need to consult 3259 additional offline information before making this assumption. For 3260 example by knowing that a particular physical product/MIC-chip is 3261 guaranteed to use globally unique assigned EUI-48 MAC address(es). 3263 When the candidate ACP device (called Pledge in BRSKI) is to be 3264 enrolled into an ACP domain, the ACP registrar needs to allocate a 3265 unique ACP address to the node and ensure that the ACP certificate 3266 gets a acp-node-name field (Section 6.1.2) with the appropriate 3267 information - ACP domain-name, ACP-address, and so on. If the ACP 3268 registrar uses BRSKI, it signals the ACP acp-node-name field to the 3269 Pledge via the EST /csrattrs command (see 3270 [I-D.ietf-anima-bootstrapping-keyinfra], section 5.9.2 - "EST CSR 3271 Attributes"). 3273 [RFC Editor: please update reference to section 5.9.2 accordingly 3274 with latest BRSKI draft at time of publishing, or RFC] 3276 6.10.7.3. Addressing Sub-Scheme Policies 3278 The ACP registrar selects for the candidate ACP node a unique address 3279 prefix from an appropriate ACP addressing sub-scheme, either a zone 3280 addressing sub-scheme prefix (see Section 6.10.3), or a Vlong 3281 addressing sub-scheme prefix (see Section 6.10.5). The assigned ACP 3282 address prefix encoded in the acp-node-name field of the ACP 3283 certificate indicates to the ACP node its ACP address information. 3284 The sub-addressing scheme indicates the prefix length: /127 for zone 3285 address sub-scheme, /120 or /112 for Vlong address sub-scheme. The 3286 first address of the prefix is the ACP address. All other addresses 3287 in the prefix are for other uses by the ACP node as described in the 3288 zone and Vlong addressing sub scheme sections. The ACP address 3289 prefix itself is then signaled by the ACP node into the ACP routing 3290 protocol (see Section 6.11) to establish IPv6 reachability across the 3291 ACP. 3293 The choice of addressing sub-scheme and prefix-length in the Vlong 3294 address sub-scheme is subject to ACP registrar policy. It could be 3295 an ACP domain wide policy, or a per ACP node or per ACP node type 3296 policy. For example, in BRSKI, the ACP registrar is aware of the 3297 IDevID certificate of the candidate ACP node, which contains a 3298 "serialNnumber" that is typically indicating the node's vendor and 3299 device type and can be used to drive a policy selecting an 3300 appropriate addressing sub-scheme for the (class of) node(s). 3302 ACP registrars SHOULD default to allocate ACP zone sub-address scheme 3303 addresses with Zone-ID 0. 3305 ACP registrars that are aware of the IDevID certificate of a 3306 candidate ACP device SHOULD be able to choose the zone vs. Vlong sub- 3307 address scheme for ACP nodes based on the "serialNumber" of the 3308 IDevID certificate, for example by the PID (Product Identifier) part 3309 which identifies the product type, or the complete "serialNumber". 3310 The PID for example could identify nodes that allow for specialized 3311 ASA requiring multiple addresses or non-autonomic VMs for services 3312 and those nodes could receive Vlong sub-address scheme ACP addresses. 3314 In a simple allocation scheme, an ACP registrar remembers 3315 persistently across reboots its currently used Registrar-ID and for 3316 each addressing scheme (Zone with Zone-ID 0, Vlong with /112, Vlong 3317 with /120), the next Node-Number available for allocation and 3318 increases it during successful enrollment to an ACP node. In this 3319 simple allocation scheme, the ACP registrar would not recycle ACP 3320 address prefixes from no longer used ACP nodes. 3322 If allocated addresses can not be remembered by registrars, then it 3323 is necessary to either use a new value for the Register-ID field in 3324 the ACP addresses, or determine allocated ACP addresses from 3325 determining the addresses of reachable ACP nodes, which is not 3326 necessarily the set of all ACP nodes. Non-tracked ACP addresses can 3327 be reclaimed by revoking or not renewing their certificates and 3328 instead handing out new certificate with new addresses (for example 3329 with a new Registrar-ID value). Note that such strategies may 3330 require coordination amongst registrars. 3332 6.10.7.4. Address/Prefix Persistence 3334 When an ACP certificate is renewed or rekeyed via EST or other 3335 mechanisms, the ACP address/prefix in the acp-node-name field MUST be 3336 maintained unless security issues or violations of the unique address 3337 assignment requirements exist or are suspected by the ACP registrar. 3339 ACP address information SHOULD be maintained even when the renewing/ 3340 rekeying ACP registrar is not the same as the one that enrolled the 3341 prior ACP certificate. See Section 9.2.4 for an example. 3343 ACP address information SHOULD also be maintained even after an ACP 3344 certificate did expire or failed. See Section 6.1.5.5 and 3345 Section 6.1.5.6. 3347 6.10.7.5. Further Details 3349 Section 9.2 discusses further informative details of ACP registrars: 3350 What interactions registrars need, what parameters they require, 3351 certificate renewal and limitations, use of sub-CAs on registrars and 3352 centralized policy control. 3354 6.11. Routing in the ACP 3356 Once ULA address are set up all autonomic entities should run a 3357 routing protocol within the autonomic control plane context. This 3358 routing protocol distributes the ULA created in the previous section 3359 for reachability. The use of the autonomic control plane specific 3360 context eliminates the probable clash with Data-Plane routing tables 3361 and also secures the ACP from interference from the configuration 3362 mismatch or incorrect routing updates. 3364 The establishment of the routing plane and its parameters are 3365 automatic and strictly within the confines of the autonomic control 3366 plane. Therefore, no explicit configuration is required. 3368 All routing updates are automatically secured in transit as the 3369 channels of the ACP are encrypted, and this routing runs only inside 3370 the ACP. 3372 The routing protocol inside the ACP is RPL ([RFC6550]). See 3373 Appendix A.4 for more details on the choice of RPL. 3375 RPL adjacencies are set up across all ACP channels in the same domain 3376 including all its routing subdomains. See Appendix A.7 for more 3377 details. 3379 6.11.1. ACP RPL Profile 3381 The following is a description of the RPL profile that ACP nodes need 3382 to support by default. The format of this section is derived from 3383 [I-D.ietf-roll-applicability-template]. 3385 6.11.1.1. Overview 3387 RPL Packet Information (RPI) defined in [RFC6550], section 11.2 3388 defines the data packet artefacts required or beneficial in 3389 forwarding of packets routed by RPL. This profile does not use RPI 3390 for better compatibility with accelerated hardware forwarding planes 3391 which most often does not support the Hop-by-Hop headers used for 3392 RPI, but also to avoid the overhead of the RPI header on the wire and 3393 cost of adding/removing them. 3395 6.11.1.1.1. Single Instance 3397 To avoid the need for RPI, the ACP RPL profile uses a simple 3398 destination prefix based routing/forwarding table. To achieve this, 3399 the profiles uses only one RPL instanceID. This single instanceID 3400 can contain only one Destination Oriented Directed Acyclic Graph 3401 (DODAG), and the routing/forwarding table can therefore only 3402 calculate a single class of service ("best effort towards the primary 3403 NOC/root") and cannot create optimized routing paths to accomplish 3404 latency or energy goals between any two nodes. 3406 This choice is a compromise. Consider a network that has multiple 3407 NOCs in different locations. Only one NOC will become the DODAG 3408 root. Traffic to and from other NOCs has to be sent through the 3409 DODAG (shortest path tree) rooted in the primary NOC. Depending on 3410 topology, this can be an annoyance from a latency point of view or 3411 from minimizing network path resources, but this is deemed to be 3412 acceptable given how ACP traffic is "only" network management/control 3413 traffic. See Appendix A.10.4 for more details. 3415 Using a single instanceID/DODAG does not introduce a single point of 3416 failure, as the DODAG will reconfigure itself when it detects Data- 3417 Plane forwarding failures including choosing a different root when 3418 the primary one fails. 3420 The benefit of this profile, especially compared to other IGPs is 3421 that it does not calculate routes for node reachable through the same 3422 interface as the DODAG root. This RPL profile can therefore scale to 3423 much larger number of ACP nodes in the same amount of compute and 3424 memory than other routing protocols. Especially on nodes that are 3425 leafs of the topology or those close to those leafs. 3427 6.11.1.1.2. Reconvergence 3429 In RPL profiles where RPL Packet Information (RPI, see 3430 Section 6.11.1.13) is present, it is also used to trigger 3431 reconvergence when misrouted, for example looping, packets are 3432 recognized because of their RPI data. This helps to minimize RPL 3433 signaling traffic especially in networks without stable topology and 3434 slow links. 3436 The ACP RPL profile instead relies on quick reconverging the DODAG by 3437 recognizing link state change (down/up) and triggering reconvergence 3438 signaling as described in Section 6.11.1.7. Since links in the ACP 3439 are assumed to be mostly reliable (or have link layer protection 3440 against loss) and because there is no stretch according to 3441 Section 6.11.1.7, loops caused by loss of RPL routing protocol 3442 signaling packets should be exceedingly rare. 3444 In addition, there are a variety of mechanisms possible in RPL to 3445 further avoid temporary loops RECOMMENDED to be used for the ACPL RPL 3446 profile: DODAG Information Objects (DIOs) SHOULD be sent 2 or 3 times 3447 to inform children when losing the last parent. The technique in 3448 [RFC6550] section 8.2.2.6. (Detaching) SHOULD be favored over that 3449 in section 8.2.2.5., (Poisoning) because it allows local 3450 connectivity. Nodes SHOULD select more than one parent, at least 3 3451 if possible, and send Destination Advertisement Objects (DAO)s to all 3452 of them in parallel. 3454 Additionally, failed ACP tunnels can be quickly discovered trough the 3455 secure channel protocol mechanisms such as IKEv2 Dead Peer Detection. 3456 This can function as a replacement for a Low-power and Lossy 3457 Networks' (LLN's) Expected Transmission Count (ETX) feature that is 3458 not used in this profile. A failure of an ACP tunnel should 3459 imediately signal the RPL control plane to pick a different parent. 3461 6.11.1.2. RPL Instances 3463 Single RPL instance. Default RPLInstanceID = 0. 3465 6.11.1.3. Storing vs. Non-Storing Mode 3467 RPL Mode of Operations (MOP): MUST support mode 2 - "Storing Mode of 3468 Operations with no multicast support". Implementations MAY support 3469 mode 3 ("... with multicast support" as that is a superset of mode 3470 2). Note: Root indicates mode in DIO flow. 3472 6.11.1.4. DAO Policy 3474 Proactive, aggressive DAO state maintenance: 3476 o Use K-flag in unsolicited DAO indicating change from previous 3477 information (to require DAO-ACK). 3479 o Retry such DAO DAO-RETRIES(3) times with DAO- ACK_TIME_OUT(256ms) 3480 in between. 3482 6.11.1.5. Path Metric 3484 Use Hopcount according to [RFC6551]. Note that this is solely for 3485 diagnostic purposes as it is not used by the objective function. 3487 6.11.1.6. Objective Function 3489 Objective Function (OF): Use OF0 [RFC6552]. No use of metric 3490 containers. 3492 rank_factor: Derived from link speed: <= 100Mbps: 3493 LOW_SPEED_FACTOR(5), else HIGH_SPEED_FACTOR(1) 3495 This is a simple rank differentiation between typical "low speed" or 3496 "IoT" links that commonly max out at 100 Mbps and typical 3497 infrastructure links with speeds of 1 Gbps or higher. Given how the 3498 path selection for the ACP focusses only on reachability but not on 3499 path cost optimization, no attempts at finer grained path 3500 optimization are made. 3502 6.11.1.7. DODAG Repair 3504 Global Repair: we assume stable links and ranks (metrics), so no need 3505 to periodically rebuild DODAG. DODAG version only incremented under 3506 catastrophic events (e.g., administrative action). 3508 Local Repair: As soon as link breakage is detected, send No-Path DAO 3509 for all the targets that were reachable only via this link. As soon 3510 as link repair is detected, validate if this link provides you a 3511 better parent. If so, compute your new rank, and send new DIO that 3512 advertises your new rank. Then send a DAO with a new path sequence 3513 about yourself. 3515 When using ACP multi-access virtual interfaces, local repair can be 3516 directly by peer breakage, see Section 6.12.5.2.2. 3518 stretch_rank: none provided ("not stretched"). 3520 Data Path Validation: Not used. 3522 Trickle: Not used. 3524 6.11.1.8. Multicast 3526 Not used yet but possible because of the selected mode of operations. 3528 6.11.1.9. Security 3530 [RFC6550] security not used, substituted by ACP security. 3532 Because the ACP links already include provisions for confidentiality 3533 and integrity protection, their usage at the RPL layer would be 3534 redundant, and so RPL security is not used. 3536 6.11.1.10. P2P communications 3538 Not used. 3540 6.11.1.11. IPv6 address configuration 3542 Every ACP node (RPL node) announces an IPv6 prefix covering the 3543 address(es) used in the ACP node. The prefix length depends on the 3544 chosen addressing sub-scheme of the ACP address provisioned into the 3545 certificate of the ACP node, e.g., /127 for Zone Addressing Sub- 3546 Scheme or /112 or /120 for Vlong addressing sub-scheme. See 3547 Section 6.10 for more details. 3549 Every ACP node MUST install a black hole (aka null) route for 3550 whatever ACP address space that it advertises (i.e.: the /96 or 3551 /127). This is avoid routing loops for addresses that an ACP node 3552 has not (yet) used. 3554 6.11.1.12. Administrative parameters 3556 Administrative Preference ([RFC6550], 3.2.6 - to become root): 3557 Indicated in DODAGPreference field of DIO message. 3559 o Explicit configured "root": 0b100 3561 o ACP registrar (Default): 0b011 3563 o ACP-connect (non-registrar): 0b010 3565 o Default: 0b001. 3567 6.11.1.13. RPL Packet Information 3569 RPI is not required in the ACP RPL profile for the following reasons. 3571 One RPI option is the RPL Source Routing Header (SRH) [RFC6554] which 3572 is not necessary because the ACP RPL profile uses storing mode where 3573 each hop has the necessary next-hop forwarding information. 3575 The simpler RPL Option header [RFC6553] is also not necessary in this 3576 profile, because it uses a single RPL instance and data path 3577 validation is also not used. 3579 6.11.1.14. Unknown Destinations 3581 Because RPL minimizes the size of the routing and forwarding table, 3582 prefixes reachable through the same interface as the RPL root are not 3583 known on every ACP node. Therefore traffic to unknown destination 3584 addresses can only be discovered at the RPL root. The RPL root 3585 SHOULD have attach safe mechanisms to operationally discover and log 3586 such packets. 3588 As this requirement raises additional Data-Plane, it does not apply 3589 to nodes where the administrative parameter to become root 3590 (Section 6.11.1.12) can always only be 0b001, e.g.: the node does not 3591 support explicit configuration to be root, or to be ACP registrar or 3592 to have ACP-connect functionality. If an ACP network is degraded to 3593 the point where there are no nodes that could be configured roots, 3594 ACP registrars or ACP-connect nodes, traffic to unknown destinations 3595 could not be diagnosed, but in the absence of any intelligent nodes 3596 supporting other than 0b001 administrative preference, there is 3597 likely also no diagnostic function possible. 3599 6.12. General ACP Considerations 3601 Since channels are by default established between adjacent neighbors, 3602 the resulting overlay network does hop-by-hop encryption. Each node 3603 decrypts incoming traffic from the ACP, and encrypts outgoing traffic 3604 to its neighbors in the ACP. Routing is discussed in Section 6.11. 3606 6.12.1. Performance 3608 There are no performance requirements against ACP implementations 3609 defined in this document because the performance requirements depend 3610 on the intended use case. It is expected that full autonomic node 3611 with a wide range of ASA can require high forwarding plane 3612 performance in the ACP, for example for telemetry. Implementations 3613 of ACP to solely support traditional/SDN style use cases can benefit 3614 from ACP at lower performance, especially if the ACP is used only for 3615 critical operations, e.g., when the Data-Plane is not available. The 3616 design of the ACP as specified in this document is intended to 3617 support a wide range of performance options: It is intended to allow 3618 software-only implementations at potentially low performance, but can 3619 also support high performance options. See [RFC8368] for more 3620 details. 3622 6.12.2. Addressing of Secure Channels 3624 In order to be independent of the Data-Plane routing and addressing, 3625 the GRASP discovered ACP secure channels use IPv6 link local 3626 addresses between adjacent neighbors. Note: Section 8.2 specifies 3627 extensions in which secure channels are configured tunnels operating 3628 over the Data-Plane, so those secure channels cannot be independent 3629 of the Data-Plane. 3631 To avoid that Data-Plane configuration can impact the operations of 3632 the IPv6 (link-local) interface/address used for ACP channels, 3633 appropriate implementation considerations are required. If the IPv6 3634 interface/link-local address is shared with the Data-Plane it needs 3635 to be impossible to unconfigure/disable it through configuration. 3636 Instead of sharing the IPv6 interface/link-local address, a separate 3637 (virtual) interface with a separate IPv6 link-local address can be 3638 used. For example, the ACP interface could be run over a separate 3639 MAC address of an underlying L2 (Ethernet) interface. For more 3640 details and options, see Appendix A.10.2. 3642 Note that other (non-ideal) implementation choices may introduce 3643 additional undesired dependencies against the Data-Plane. For 3644 example shared code and configuration of the secure channel protocols 3645 (IPsec / DTLS). 3647 6.12.3. MTU 3649 The MTU for ACP secure channels MUST be derived locally from the 3650 underlying link MTU minus the secure channel encapsulation overhead. 3652 ACP secure Channel protocols do not need to perform MTU discovery 3653 because they are built across L2 adjacencies - the MTU on both sides 3654 connecting to the L2 connection are assumed to be consistent. 3655 Extensions to ACP where the ACP is for example tunneled need to 3656 consider how to guarantee MTU consistency. This is an issue of 3657 tunnels, not an issue of running the ACP across a tunnel. Transport 3658 stacks running across ACP can perform normal PMTUD (Path MTU 3659 Discovery). Because the ACP is meant to be prioritize reliability 3660 over performance, they MAY opt to only expect IPv6 minimum MTU (1280) 3661 to avoid running into PMTUD implementation bugs or underlying link 3662 MTU mismatch problems. 3664 6.12.4. Multiple links between nodes 3666 If two nodes are connected via several links, the ACP SHOULD be 3667 established across every link, but it is possible to establish the 3668 ACP only on a sub-set of links. Having an ACP channel on every link 3669 has a number of advantages, for example it allows for a faster 3670 failover in case of link failure, and it reflects the physical 3671 topology more closely. Using a subset of links (for example, a 3672 single link), reduces resource consumption on the node, because state 3673 needs to be kept per ACP channel. The negotiation scheme explained 3674 in Section 6.5 allows Alice (the node with the higher ACP address) to 3675 drop all but the desired ACP channels to Bob - and Bob will not re- 3676 try to build these secure channels from his side unless Alice shows 3677 up with a previously unknown GRASP announcement (e.g., on a different 3678 link or with a different address announced in GRASP). 3680 6.12.5. ACP interfaces 3682 The ACP VRF has conceptually two type of interfaces: The "ACP 3683 Loopback interface(s)" to which the ACP ULA address(es) are assigned 3684 and the "ACP virtual interfaces" that are mapped to the ACP secure 3685 channels. 3687 6.12.5.1. ACP loopback interfaces 3689 For autonomous operations of the ACP, as described in Section 6 and 3690 Section 7, the ACP node uses the first address from the N bit ACP 3691 prefix (N = 128 - number of Vbits of the ACP address) assigned to the 3692 node. This address is assigned with an adddress prefix of N or 3693 larger to a loopback interface. 3695 Other addresses from the prefix can be used by the ACP of the node as 3696 desired. The autonomous operations of the ACP does not require 3697 additional global scope IPv6 addresses, they are instead intended for 3698 ASA or non-autonomous functions. Non fully autonomic components of 3699 the ACP such as ACP connect interfaces (see Figure 15 may also 3700 introduce additional global scope IPv6 addresses on other type of 3701 interfaces into the ACP. 3703 [RFC Editor: please remove this paragraph: Note to reviewers: Please 3704 do not complain again about an obsolete RFC number in the following 3705 paragraph. The text should make it clear that the reference was 3706 choosen to indicate a particular point in time, but not to recommend/ 3707 use a particularily obsolete protocol spec.] 3709 The use of loopback interfaces for global scope addresses is common 3710 operational configuration practice on routers, for example in IBGP 3711 connections since BGP4 (see [RFC1654]) or earlier. The ACP adopts 3712 and automates this operational practice. 3714 A loopback interface for use with the ACP as described above is an 3715 interface behaving according to [RFC6724] Section 4., paragraph 2: 3716 Packets sent by the host of the node from the loopback interface 3717 behave as if they are looped back by the interface so that they look 3718 as if they originated from the loopback interface, are then received 3719 by the node and forwarded by it towards the destination. 3721 The word loopback only indicates this behavior, but not the actual 3722 name of the interface type choosen in an actual implementation. A 3723 loopback interface for use with the ACP can be a virtual/software 3724 construct without any associated hardware, or it can be a hardware 3725 interface operating in loopback mode. 3727 A loopback interface used for the ACP MUST NOT have connectivity to 3728 other nodes. 3730 The following reviews the reasons for the choice of loopback 3731 addresses for ACP addresses is based on the IPv6 address architecture 3732 and common challenges: 3734 1. IPv6 addresses are assigned to interfaces, not nodes. IPv6 3735 continues the IPv4 model that a subnet prefix is associated with 3736 one link, see [RFC4291], Section 2.1. 3738 2. IPv6 implementations do commonly not allow to assign the same 3739 IPv6 global scope address in the same VRF to more than one 3740 interface. 3742 3. Global scope addresses assigned to interfaces that are connecting 3743 to other nodes (external interfaces) may not be stable addresses 3744 for communications because any such interface could fail due to 3745 reasons external to the node. This could render the addresses 3746 assigned to that interface unusable. 3748 4. If failure of the subnet does not result in bringing down the 3749 interface and making the addresses unusable, it could result in 3750 unreachability of the address because the shortest path to the 3751 node might go through one of the other nodes on the same subnet 3752 which could equally consider the subnet to be operational even 3753 though it is not. 3755 5. Many OAM service implementations on routers can not deal with 3756 more than one peer address, often because they do already expect 3757 that a single loopback address can be used, especially to provide 3758 a stable address under failure of external interfaces or links. 3760 6. Even when an application supports multiple addresses to a peer, 3761 it can only use one adddress for a connection at a time with the 3762 most widely deployed transport protocols TCP and UDP. While 3763 [RFC6824] solves this problem, it is not widely adopted for 3764 router OAM services implementations. 3766 7. To completely autonomously assign global scope addresses to 3767 subnets connecting to other nodes, it would be necessary for 3768 every node to have an amount of prefix address space in the order 3769 of the maximum number of subnets that the node could connect to 3770 and then the node would have to negotiate with adjacent nodes 3771 across those subnet whose address space to use for each subnet. 3773 8. Using global scope addresses for subnets between nodes is 3774 unnecessary if those subnets only connect routers, such as ACP 3775 secure channels because they can communicate to remote nodes via 3776 their global scope loopback addresses. Using global scope 3777 addresses for those extern subnets is therefore wasteful for the 3778 address space and also unnecessarily increasing the size of 3779 routing and forwarding tables, which especially for the ACP is 3780 highly undesirable because it should attempt to minimize the per- 3781 node overhead of the ACP VRF. 3783 9. For all these reasons, the ACP addressing schemes do not consider 3784 ACP addresses for subnets connecting ACP nodes. 3786 Note that [RFC8402] introduces the term Node-SID to refer to IGP 3787 prefix segments that identify a specific rouer, for example on a 3788 loopback interface. An ACP loopback address prefix may similarily be 3789 called an ACP Node Identifier. 3791 6.12.5.2. ACP virtual interfaces 3793 Any ACP secure channel to another ACP node is mapped to ACP virtual 3794 interfaces in one of the following ways. This is independent of the 3795 chosen secure channel protocol (IPsec, DTLS or other future protocol 3796 - standards or non-standards). 3798 Note that all the considerations described here are assuming point- 3799 to-point secure channel associations. Mapping multi-party secure 3800 channel associations such as [RFC6407] is out of scope (but would be 3801 easy to add). 3803 6.12.5.2.1. ACP point-to-point virtual interfaces 3805 In this option, each ACP secure channel is mapped into a separate 3806 point-to-point ACP virtual interface. If a physical subnet has more 3807 than two ACP capable nodes (in the same domain), this implementation 3808 approach will lead to a full mesh of ACP virtual interfaces between 3809 them. 3811 When the secure channel protocol determines a peer to be dead, this 3812 SHOULD result in indicating link breakage to trigger RPL DODAG 3813 repair, see Section 6.11.1.7. 3815 6.12.5.2.2. ACP multi-access virtual interfaces 3817 In a more advanced implementation approach, the ACP will construct a 3818 single multi-access ACP virtual interface for all ACP secure channels 3819 to ACP capable nodes reachable across the same underlying (physical) 3820 subnet. IPv6 link-local multicast packets sent into an ACP multi- 3821 access virtual interface are replicated to every ACP secure channel 3822 mapped into the ACP multicast-access virtual interface. IPv6 unicast 3823 packets sent into an ACP multi-access virtual interface are sent to 3824 the ACP secure channel that belongs to the ACP neighbor that is the 3825 next-hop in the ACP forwarding table entry used to reach the packets 3826 destination address. 3828 When the secure channel protocol determines a peer to be dead for a 3829 secure channel mapped into an ACP multi-access virtual interface, 3830 this SHOULD result in signaling breakage of that peer to RPL, so it 3831 can trigger RPL DODAG repair, see Section 6.11.1.7. 3833 There is no requirement for all ACP nodes on the same multi-access 3834 subnet to use the same type of ACP virtual interface. This is purely 3835 a node local decision. 3837 ACP nodes MUST perform standard IPv6 operations across ACP virtual 3838 interfaces including SLAAC (Stateless Address Auto-Configuration) - 3840 [RFC4862]) to assign their IPv6 link local address on the ACP virtual 3841 interface and ND (Neighbor Discovery - [RFC4861]) to discover which 3842 IPv6 link-local neighbor address belongs to which ACP secure channel 3843 mapped to the ACP virtual interface. This is independent of whether 3844 the ACP virtual interface is point-to-point or multi-access. 3846 "Optimistic Duplicate Address Detection (DAD)" according to [RFC4429] 3847 is RECOMMENDED because the likelihood for duplicates between ACP 3848 nodes is highly improbable as long as the address can be formed from 3849 a globally unique local assigned identifier (e.g., EUI-48/EUI-64, see 3850 below). 3852 ACP nodes MAY reduce the amount of link-local IPv6 multicast packets 3853 from ND by learning the IPv6 link-local neighbor address to ACP 3854 secure channel mapping from other messages such as the source address 3855 of IPv6 link-local multicast RPL messages - and therefore forego the 3856 need to send Neighbor Solicitation messages. 3858 The ACP virtual interface IPv6 link local address can be derived from 3859 any appropriate local mechanism such as node local EUI-48 or EUI-64 3860 ("EUI" stands for "Extended Unique Identifier"). It MUST NOT depend 3861 on something that is attackable from the Data-Plane such as the IPv6 3862 link-local address of the underlying physical interface, which can be 3863 attacked by SLAAC, or parameters of the secure channel encapsulation 3864 header that may not be protected by the secure channel mechanism. 3866 The link-layer address of an ACP virtual interface is the address 3867 used for the underlying interface across which the secure tunnels are 3868 built, typically Ethernet addresses. Because unicast IPv6 packets 3869 sent to an ACP virtual interface are not sent to a link-layer 3870 destination address but rather an ACP secure channel, the link-layer 3871 address fields SHOULD be ignored on reception and instead the ACP 3872 secure channel from which the message was received should be 3873 remembered. 3875 Multi-access ACP virtual interfaces are preferable implementations 3876 when the underlying interface is a (broadcast) multi-access subnet 3877 because they do reflect the presence of the underlying multi-access 3878 subnet into the virtual interfaces of the ACP. This makes it for 3879 example simpler to build services with topology awareness inside the 3880 ACP VRF in the same way as they could have been built running 3881 natively on the multi-access interfaces. 3883 Consider also the impact of point-to-point vs. multi-access virtual 3884 interface on the efficiency of flooding via link local multicasted 3885 messages: 3887 Assume a LAN with three ACP neighbors, Alice, Bob and Carol. Alice's 3888 ACP GRASP wants to send a link-local GRASP multicast message to Bob 3889 and Carol. If Alice's ACP emulates the LAN as one point-to-point 3890 virtual interface to Bob and one to Carol, The sending applications 3891 itself will send two copies, if Alice's ACP emulates a LAN, GRASP 3892 will send one packet and the ACP will replicate it. The result is 3893 the same. The difference happens when Bob and Carol receive their 3894 packet. If they use ACP point-to-point virtual interfaces, their 3895 GRASP instance would forward the packet from Alice to each other as 3896 part of the GRASP flooding procedure. These packets are unnecessary 3897 and would be discarded by GRASP on receipt as duplicates (by use of 3898 the GRASP Session ID). If Bob and Carol's ACP would emulate a multi- 3899 access virtual interface, then this would not happen, because GRASPs 3900 flooding procedure does not replicate back packets to the interface 3901 that they were received from. 3903 Note that link-local GRASP multicast messages are not sent directly 3904 as IPv6 link-local multicast UDP messages into ACP virtual 3905 interfaces, but instead into ACP GRASP virtual interfaces, that are 3906 layered on top of ACP virtual interfaces to add TCP reliability to 3907 link-local multicast GRASP messages. Nevertheless, these ACP GRASP 3908 virtual interfaces perform the same replication of message and, 3909 therefore, result in the same impact on flooding. See Section 6.8.2 3910 for more details. 3912 RPL does support operations and correct routing table construction 3913 across non-broadcast multi-access (NBMA) subnets. This is common 3914 when using many radio technologies. When such NBMA subnets are used, 3915 they MUST NOT be represented as ACP multi-access virtual interfaces 3916 because the replication of IPv6 link-local multicast messages will 3917 not reach all NBMA subnet neighbors. In result, GRASP message 3918 flooding would fail. Instead, each ACP secure channel across such an 3919 interface MUST be represented as a ACP point-to-point virtual 3920 interface. See also Appendix A.10.4. 3922 Care needs to be taken when creating multi-access ACP virtual 3923 interfaces across ACP secure channels between ACP nodes in different 3924 domains or routing subdomains. If for example future inter-domain 3925 ACP policies are defined as "peer-to-peer" policies, it is easier to 3926 create ACP point-to-point virtual interfaces for these inter-domain 3927 secure channels. 3929 7. ACP support on L2 switches/ports (Normative) 3930 7.1. Why (Benefits of ACP on L2 switches) 3932 ANrtr1 ------ ANswitch1 --- ANswitch2 ------- ANrtr2 3933 .../ \ \ ... 3934 ANrtrM ------ \ ------- ANrtrN 3935 ANswitchM ... 3937 Figure 14: Topology with L2 ACP switches 3939 Consider a large L2 LAN with ANrtr1...ANrtrN connected via some 3940 topology of L2 switches. Examples include large enterprise campus 3941 networks with an L2 core, IoT networks or broadband aggregation 3942 networks which often have even a multi-level L2 switched topology. 3944 If the discovery protocol used for the ACP is operating at the subnet 3945 level, every ACP router will see all other ACP routers on the LAN as 3946 neighbors and a full mesh of ACP channels will be built. If some or 3947 all of the AN switches are autonomic with the same discovery 3948 protocol, then the full mesh would include those switches as well. 3950 A full mesh of ACP connections can create fundamental scale 3951 challenges. The number of security associations of the secure 3952 channel protocols will likely not scale arbitrarily, especially when 3953 they leverage platform accelerated encryption/decryption. Likewise, 3954 any other ACP operations (such as routing) needs to scale to the 3955 number of direct ACP neighbors. An ACP router with just 4 physical 3956 interfaces might be deployed into a LAN with hundreds of neighbors 3957 connected via switches. Introducing such a new unpredictable scaling 3958 factor requirement makes it harder to support the ACP on arbitrary 3959 platforms and in arbitrary deployments. 3961 Predictable scaling requirements for ACP neighbors can most easily be 3962 achieved if in topologies such as these, ACP capable L2 switches can 3963 ensure that discovery messages terminate on them so that neighboring 3964 ACP routers and switches will only find the physically connected ACP 3965 L2 switches as their candidate ACP neighbors. With such a discovery 3966 mechanism in place, the ACP and its security associations will only 3967 need to scale to the number of physical interfaces instead of a 3968 potentially much larger number of "LAN-connected" neighbors. And the 3969 ACP topology will follow directly the physical topology, something 3970 which can then also be leveraged in management operations or by ASAs. 3972 In the example above, consider ANswitch1 and ANswitchM are ACP 3973 capable, and ANswitch2 is not ACP capable. The desired ACP topology 3974 is that ANrtr1 and ANrtrM only have an ACP connection to ANswitch1, 3975 and that ANswitch1, ANrtr2, ANrtrN have a full mesh of ACP connection 3976 amongst each other. ANswitch1 also has an ACP connection with 3977 ANswitchM and ANswitchM has ACP connections to anything else behind 3978 it. 3980 7.2. How (per L2 port DULL GRASP) 3982 To support ACP on L2 switches or L2 switched ports of an L3 device, 3983 it is necessary to make those L2 ports look like L3 interfaces for 3984 the ACP implementation. This primarily involves the creation of a 3985 separate DULL GRASP instance/domain on every such L2 port. Because 3986 GRASP has a dedicated link-local IPv6 multicast address 3987 (ALL_GRASP_NEIGHBORS), it is sufficient that all packets for this 3988 address are being extracted at the port level and passed to that DULL 3989 GRASP instance. Likewise the IPv6 link-local multicast packets sent 3990 by that DULL GRASP instance need to be sent only towards the L2 port 3991 for this DULL GRASP instance (instead of being flooded across all 3992 ports of the VLAN to which the port belongs). 3994 When Ports/Interfaces across which the ACP is expected to operate in 3995 an ACP-aware L2-switch or L2/L3-switch/router are L2-bridged, packets 3996 for the ALL_GRASP_NEIGHBORS multicast address MUST never be forward 3997 between these ports. If MLD snooping is used, it MUST be prohibited 3998 from bridging packets for the ALL_GRASP_NEIGHBORS IPv6 multicast 3999 address. 4001 On hybrid L2/L3 switches, multiple L2 ports are assigned to a single 4002 L3 VLAN interface. With the aforementioned changes for DULL GRASP, 4003 ACP can simply operate on the L3 VLAN interfaces, so no further 4004 (hardware) forwarding changes are required to make ACP operate on L2 4005 ports. This is possible because the ACP secure channel protocols 4006 only use link-local IPv6 unicast packets, and these packets will be 4007 sent to the correct L2 port towards the peer by the VLAN logic of the 4008 device. 4010 This is sufficient when p2p ACP virtual interfaces are established to 4011 every ACP peer. When it is desired to create multi-access ACP 4012 virtual interfaces (see Section 6.12.5.2.2), it is REQIURED not to 4013 coalesce all the ACP secure channels on the same L3 VLAN interface, 4014 but only all those on the same L2 port. 4016 If VLAN tagging is used, then all the above described logic only 4017 applies to untagged GRASP packets. For the purpose of ACP neighbor 4018 discovery via GRASP, no VLAN tagged packets SHOULD be sent or 4019 received. In a hybrid L2/L3 switch, each VLAN would therefore only 4020 create ACP adjacencies across those ports where the VLAN is carried 4021 untagged. 4023 In result, the simple logic is that ACP secure channels would operate 4024 over the same L3 interfaces that present a single flat bridged 4025 network across all routers, but because DULL GRASP is separated on a 4026 per-port basis, no full mesh of ACP secure channels is created, but 4027 only per-port ACP secure channels to per-port L2-adjacent ACP node 4028 neighbors. 4030 For example, in the above picture, ANswitch1 would run separate DULL 4031 GRASP instances on its ports to ANrtr1, ANswitch2 and ANswitchI, even 4032 though all those three ports may be in the data plane in the same 4033 (V)LAN and perform L2 switching between these ports, ANswitch1 would 4034 perform ACP L3 routing between them. 4036 The description in the previous paragraph was specifically meant to 4037 illustrate that on hybrid L3/L2 devices that are common in 4038 enterprise, IoT and broadband aggregation, there is only the GRASP 4039 packet extraction (by Ethernet address) and GRASP link-local 4040 multicast per L2-port packet injection that has to consider L2 ports 4041 at the hardware forwarding level. The remaining operations are 4042 purely ACP control plane and setup of secure channels across the L3 4043 interface. This hopefully makes support for per-L2 port ACP on those 4044 hybrid devices easy. 4046 In devices without such a mix of L2 port/interfaces and L3 interfaces 4047 (to terminate any transport layer connections), implementation 4048 details will differ. Logically most simply every L2 port is 4049 considered and used as a separate L3 subnet for all ACP operations. 4050 The fact that the ACP only requires IPv6 link-local unicast and 4051 multicast should make support for it on any type of L2 devices as 4052 simple as possible. 4054 A generic issue with ACP in L2 switched networks is the interaction 4055 with the Spanning Tree Protocol. Without further L2 enhancements, 4056 the ACP would run only across the active STP topology and the ACP 4057 would be interrupted and re-converge with STP changes. Ideally, ACP 4058 peering SHOULD be built also across ports that are blocked in STP so 4059 that the ACP does not depend on STP and can continue to run 4060 unaffected across STP topology changes, where re-convergence can be 4061 quite slow. The above described simple implementation options are 4062 not sufficient to achieve this. 4064 8. Support for Non-ACP Components (Normative) 4066 8.1. ACP Connect 4068 8.1.1. Non-ACP Controller / NMS system 4070 The Autonomic Control Plane can be used by management systems, such 4071 as controllers or network management system (NMS) hosts (henceforth 4072 called simply "NMS hosts"), to connect to devices (or other type of 4073 nodes) through it. For this, an NMS host needs to have access to the 4074 ACP. The ACP is a self-protecting overlay network, which allows by 4075 default access only to trusted, autonomic systems. Therefore, a 4076 traditional, non-ACP NMS system does not have access to the ACP by 4077 default, such as any other external node. 4079 If the NMS host is not autonomic, i.e., it does not support autonomic 4080 negotiation of the ACP, then it can be brought into the ACP by 4081 explicit configuration. To support connections to adjacent non-ACP 4082 nodes, an ACP node SHOULD support "ACP connect" (sometimes also 4083 called "autonomic connect"): 4085 "ACP connect" is an interface level configured workaround for 4086 connection of trusted non-ACP nodes to the ACP. The ACP node on 4087 which ACP connect is configured is called an "ACP edge node". With 4088 ACP connect, the ACP is accessible from those non-ACP nodes (such as 4089 NOC systems) on such an interface without those non-ACP nodes having 4090 to support any ACP discovery or ACP channel setup. This is also 4091 called "native" access to the ACP because to those NOC systems the 4092 interface looks like a normal network interface (without any 4093 encryption/novel-signaling). 4095 Data-Plane "native" (no ACP) 4096 . 4097 +--------+ +----------------+ . +-------------+ 4098 | ACP | |ACP Edge Node | . | | 4099 | Node | | | v | | 4100 | |-------|...[ACP VRF]....+-----------------| |+ 4101 | | ^ |. | | NOC Device || 4102 | | . | .[Data-Plane]..+-----------------| "NMS hosts" || 4103 | | . | [ ] | . ^ | || 4104 +--------+ . +----------------+ . . +-------------+| 4105 . . . +-------------+ 4106 . . . 4107 Data-Plane "native" . ACP "native" (unencrypted) 4108 + ACP auto-negotiated . "ACP connect subnet" 4109 and encrypted . 4110 ACP connect interface 4111 e.g., "VRF ACP native" (config) 4113 Figure 15: ACP connect 4115 ACP connect has security consequences: All systems and processes 4116 connected via ACP connect have access to all ACP nodes on the entire 4117 ACP, without further authentication. Thus, the ACP connect interface 4118 and NOC systems connected to it needs to be physically controlled/ 4119 secured. For this reason the mechanisms described here do explicitly 4120 not include options to allow for a non-ACP router to be connected 4121 across an ACP connect interface and addresses behind such a router 4122 routed inside the ACP. 4124 Physical controlled/secured means that attackers can gain no access 4125 to the physical device hosting the ACP Edge Node, the physical 4126 interfaces and links providing the ACP connect link nor the physical 4127 devices hosting the NOC Device. In a simple case, ACP Edge node and 4128 NOC Device are co-located in an access controlled room, such as a 4129 NOC, to which attackers can not gain physical access. 4131 An ACP connect interface provides exclusively access to only the ACP. 4132 This is likely insufficient for many NMS hosts. Instead, they would 4133 require a second "Data-Plane" interface outside the ACP for 4134 connections between the NMS host and administrators, or Internet 4135 based services, or for direct access to the Data-Plane. The document 4136 "Using Autonomic Control Plane for Stable Connectivity of Network 4137 OAM" [RFC8368] explains in more detail how the ACP can be integrated 4138 in a mixed NOC environment. 4140 An ACP connect interface SHOULD use an IPv6 address/prefix from the 4141 ACP Manual Addressing Sub-Scheme (Section 6.10.4), letting the 4142 operator configure for example only the Subnet-ID and having the node 4143 automatically assign the remaining part of the prefix/address. It 4144 SHOULD NOT use a prefix that is also routed outside the ACP so that 4145 the addresses clearly indicate whether it is used inside the ACP or 4146 not. 4148 The prefix of ACP connect subnets MUST be distributed by the ACP edge 4149 node into the ACP routing protocol RPL. The NMS hosts MUST connect 4150 to prefixes in the ACP routing table via its ACP connect interface. 4151 In the simple case where the ACP uses only one ULA prefix and all ACP 4152 connect subnets have prefixes covered by that ULA prefix, NMS hosts 4153 can rely on [RFC6724] to determine longest match prefix routes 4154 towards its different interfaces, ACP and Data-Plane. With RFC6724, 4155 The NMS host will select the ACP connect interface for all addresses 4156 in the ACP because any ACP destination address is longest matched by 4157 the address on the ACP connect interface. If the NMS hosts ACP 4158 connect interface uses another prefix or if the ACP uses multiple ULA 4159 prefixes, then the NMS hosts require (static) routes towards the ACP 4160 interface for these prefixes. 4162 When an ACP Edge node receives a packet from an ACP connect 4163 interface, the ACP Edge node MUST only forward the packet into the 4164 ACP if the packet has an IPv6 source address from that interface. 4165 This is sometimes called "RPF filtering". This MAY be changed 4166 through administrative measures. 4168 To limit the security impact of ACP connect, nodes supporting it 4169 SHOULD implement a security mechanism to allow configuration/use of 4170 ACP connect interfaces only on nodes explicitly targeted to be 4171 deployed with it (those in physically secure locations such as a 4172 NOC). For example, the registrar could disable the ability to enable 4173 ACP connect on devices during enrollment and that property could only 4174 be changed through re-enrollment. See also Appendix A.10.5. 4176 ACP Edge nodes SHOULD have a configurable option to filter packets 4177 with RPI headers (xsee Section 6.11.1.13 across an ACP connect 4178 interface. These headers are outside the scope of the RPL profile in 4179 this specification but may be used in future extensions of this 4180 specification. 4182 8.1.2. Software Components 4184 The previous section assumed that ACP Edge node and NOC devices are 4185 separate physical devices and the ACP connect interface is a physical 4186 network connection. This section discusses the implication when 4187 these components are instead software components running on a single 4188 physical device. 4190 The ACP connect mechanism can not only be used to connect physically 4191 external systems (NMS hosts) to the ACP but also other applications, 4192 containers or virtual machines. In fact, one possible way to 4193 eliminate the security issue of the external ACP connect interface is 4194 to collocate an ACP edge node and an NMS host by making one a virtual 4195 machine or container inside the other; and therefore converting the 4196 unprotected external ACP subnet into an internal virtual subnet in a 4197 single device. This would ultimately result in a fully ACP enabled 4198 NMS host with minimum impact to the NMS hosts software architecture. 4199 This approach is not limited to NMS hosts but could equally be 4200 applied to devices consisting of one or more VNF (virtual network 4201 functions): An internal virtual subnet connecting out-of-band 4202 management interfaces of the VNFs to an ACP edge router VNF. 4204 The core requirement is that the software components need to have a 4205 network stack that permits access to the ACP and optionally also the 4206 Data-Plane. Like in the physical setup for NMS hosts this can be 4207 realized via two internal virtual subnets. One that is connecting to 4208 the ACP (which could be a container or virtual machine by itself), 4209 and one (or more) connecting into the Data-Plane. 4211 This "internal" use of ACP connect approach should not considered to 4212 be a "workaround" because in this case it is possible to build a 4213 correct security model: It is not necessary to rely on unprovable 4214 external physical security mechanisms as in the case of external NMS 4215 hosts. Instead, the orchestration of the ACP, the virtual subnets 4216 and the software components can be done by trusted software that 4217 could be considered to be part of the ANI (or even an extended ACP). 4218 This software component is responsible for ensuring that only trusted 4219 software components will get access to that virtual subnet and that 4220 only even more trusted software components will get access to both 4221 the ACP virtual subnet and the Data-Plane (because those ACP users 4222 could leak traffic between ACP and Data-Plane). This trust could be 4223 established for example through cryptographic means such as signed 4224 software packages. 4226 8.1.3. Auto Configuration 4228 ACP edge nodes, NMS hosts and software components that as described 4229 in the previous section are meant to be composed via virtual 4230 interfaces SHOULD support on the ACP connect subnet StateLess Address 4231 Autoconfiguration (SLAAC - [RFC4862]) and route auto configuration 4232 according to [RFC4191]. 4234 The ACP edge node acts as the router on the ACP connect subnet, 4235 providing the (auto-)configured prefix for the ACP connect subnet to 4236 NMS hosts and/or software components. The ACP edge node uses route 4237 prefix option of RFC4191 to announce the default route (::/) with a 4238 lifetime of 0 and aggregated prefixes for routes in the ACP routing 4239 table with normal lifetimes. This will ensure that the ACP edge node 4240 does not become a default router, but that the NMS hosts and software 4241 components will route the prefixes used in the ACP to the ACP edge 4242 node. 4244 Aggregated prefix means that the ACP edge node needs to only announce 4245 the /48 ULA prefixes used in the ACP but none of the actual /64 4246 (Manual Addressing Sub-Scheme), /127 (ACP Zone Addressing Sub- 4247 Scheme), /112 or /120 (Vlong Addressing Sub-Scheme) routes of actual 4248 ACP nodes. If ACP interfaces are configured with non ULA prefixes, 4249 then those prefixes cannot be aggregated without further configured 4250 policy on the ACP edge node. This explains the above recommendation 4251 to use ACP ULA prefix covered prefixes for ACP connect interfaces: 4252 They allow for a shorter list of prefixes to be signaled via RFC4191 4253 to NMS hosts and software components. 4255 The ACP edge nodes that have a Vlong ACP address MAY allocate a 4256 subset of their /112 or /120 address prefix to ACP connect 4257 interface(s) to eliminate the need to non-autonomically configure/ 4258 provision the address prefixes for such ACP connect interfaces. 4260 8.1.4. Combined ACP/Data-Plane Interface (VRF Select) 4262 Combined ACP and Data-Plane interface 4263 . 4264 +--------+ +--------------------+ . +--------------+ 4265 | ACP | |ACP Edge No | . | NMS Host(s) | 4266 | Node | | | . | / Software | 4267 | | | [ACP ]. | . | |+ 4268 | | | .[VRF ] .[VRF ] | v | "ACP address"|| 4269 | +-------+. .[Select].+--------+ "Date Plane || 4270 | | ^ | .[Data ]. | | Address(es)"|| 4271 | | . | [Plane] | | || 4272 | | . | [ ] | +--------------+| 4273 +--------+ . +--------------------+ +--------------+ 4274 . 4275 Data-Plane "native" and + ACP auto-negotiated/encrypted 4277 Figure 16: VRF select 4279 Using two physical and/or virtual subnets (and therefore interfaces) 4280 into NMS Hosts (as per Section 8.1.1) or Software (as per 4281 Section 8.1.2) may be seen as additional complexity, for example with 4282 legacy NMS Hosts that support only one IP interface. 4284 To provide a single subnet into both ACP and Data-Plane, the ACP Edge 4285 node needs to de-multiplex packets from NMS hosts into ACP VRF and 4286 Data-Plane. This is sometimes called "VRF select". If the ACP VRF 4287 has no overlapping IPv6 addresses with the Data-Plane (it should have 4288 no overlapping addresses), then this function can use the IPv6 4289 Destination address. The problem is Source Address Selection on the 4290 NMS Host(s) according to RFC6724. 4292 Consider the simple case: The ACP uses only one ULA prefix, the ACP 4293 IPv6 prefix for the Combined ACP and Data-Plane interface is covered 4294 by that ULA prefix. The ACP edge node announces both the ACP IPv6 4295 prefix and one (or more) prefixes for the Data-Plane. Without 4296 further policy configurations on the NMS Host(s), it may select its 4297 ACP address as a source address for Data-Plane ULA destinations 4298 because of Rule 8 of RFC6724. The ACP edge node can pass on the 4299 packet to the Data-Plane, but the ACP source address should not be 4300 used for Data-Plane traffic, and return traffic may fail. 4302 If the ACP carries multiple ULA prefixes or non-ULA ACP connect 4303 prefixes, then the correct source address selection becomes even more 4304 problematic. 4306 With separate ACP connect and Data-Plane subnets and RFC4191 prefix 4307 announcements that are to be routed across the ACP connect interface, 4308 RFC6724 source address selection Rule 5 (use address of outgoing 4309 interface) will be used, so that above problems do not occur, even in 4310 more complex cases of multiple ULA and non-ULA prefixes in the ACP 4311 routing table. 4313 To achieve the same behavior with a Combined ACP and Data-Plane 4314 interface, the ACP Edge Node needs to behave as two separate routers 4315 on the interface: One link-local IPv6 address/router for its ACP 4316 reachability, and one link-local IPv6 address/router for its Data- 4317 Plane reachability. The Router Advertisements for both are as 4318 described above (Section 8.1.3): For the ACP, the ACP prefix is 4319 announced together with RFC4191 option for the prefixes routed across 4320 the ACP and lifetime=0 to disqualify this next-hop as a default 4321 router. For the Data-Plane, the Data-Plane prefix(es) are announced 4322 together with whatever dafault router parameters are used for the 4323 Data-Plane. 4325 In result, RFC6724 source address selection Rule 5.5 may result in 4326 the same correct source address selection behavior of NMS hosts 4327 without further configuration on it as the separate ACP connect and 4328 Data-Plane interfaces. As described in the text for Rule 5.5, this 4329 is only a MAY, because IPv6 hosts are not required to track next-hop 4330 information. If an NMS Host does not do this, then separate ACP 4331 connect and Data-Plane interfaces are the preferable method of 4332 attachment. Hosts implementing [RFC8028] should (instead of may) 4333 implement [RFC6724] Rule 5.5, so it is preferred for hosts to support 4334 [RFC8028]. 4336 ACP edge nodes MAY support the Combined ACP and Data-Plane interface. 4338 8.1.5. Use of GRASP 4340 GRASP can and should be possible to use across ACP connect 4341 interfaces, especially in the architectural correct solution when it 4342 is used as a mechanism to connect Software (e.g., ASA or legacy NMS 4343 applications) to the ACP. 4345 Given how the ACP is the security and transport substrate for GRASP, 4346 the requirements for devices connected via ACP connect is that those 4347 are equivalently (if not better) secured against attacks than ACP 4348 nodes that do not use ACP connect and run only software that is 4349 equally (if not better) protected, known (or trusted) not to be 4350 malicious and accordingly designed to isolate access to the ACP 4351 against external equipment. 4353 The difference in security is that cryptographic security of the ACP 4354 secure channel is replaced by required physical security/control of 4355 the network connection between an ACP edge node and the NMS or other 4356 host reachable via the ACP connect interface. See Section 8.1.1. 4358 When using "Combined ACP and Data-Plane Interfaces", care hasa to be 4359 taken that only GRASP messages intended for the ACP GRASP domain 4360 received from Software or NMS Hosts are forwarded by ACP edge nodes. 4361 Currently there is no definition for a GRASP security and transport 4362 substrate beside the ACP, so there is no definition how such 4363 Software/NMS Host could participate in two separate GRASP Domains 4364 across the same subnet (ACP and Data-Plane domains). At current it 4365 is assumed that all GRASP packets on a Combined ACP and Data-Plane 4366 interface belong to the GRASP ACP Domain. They SHOULD all use the 4367 ACP IPv6 addresses of the Software/NMS Hosts. The link-local IPv6 4368 addresses of Software/NMS Hosts (used for GRASP M_DISCOVERY and 4369 M_FLOOD messages) are also assumed to belong to the ACP address 4370 space. 4372 8.2. Connecting ACP islands over Non-ACP L3 networks (Remote ACP 4373 neighbors) 4375 Not all nodes in a network may support the ACP. If non-ACP Layer-2 4376 devices are between ACP nodes, the ACP will work across it since it 4377 is IP based. However, the autonomic discovery of ACP neighbors via 4378 DULL GRASP is only intended to work across L2 connections, so it is 4379 not sufficient to autonomically create ACP connections across non-ACP 4380 Layer-3 devices. 4382 8.2.1. Configured Remote ACP neighbor 4384 On the ACP node, remote ACP neighbors are configured explicitly. The 4385 parameters of such a "connection" are described in the following 4386 ABNF. 4388 connection = [ method , local-addr, remote-addr, ?pmtu ] 4389 method = [ "IKEv2" , ?port ] 4390 method =/ [ "DTLS", port ] 4391 local-addr = [ address , ?vrf ] 4392 remote-addr = [ address ] 4393 address = ("any" | ipv4-address | ipv6-address ) 4394 vrf = tstr ; Name of a VRF on this node with local-address 4396 Figure 17: Parameters for remote ACP neighbors 4398 Explicit configuration of a remote-peer according to this ABNF 4399 provides all the information to build a secure channel without 4400 requiring a tunnel to that peer and running DULL GRASP inside of it. 4402 The configuration includes the parameters otherwise signaled via DULL 4403 GRASP: local address, remote (peer) locator and method. The 4404 differences over DULL GRASP local neighbor discovery and secure 4405 channel creation are as follows: 4407 o The local and remote address can be IPv4 or IPv6 and are typically 4408 global scope addresses. 4410 o The VRF across which the connection is built (and in which local- 4411 addr exists) can to be specified. If vrf is not specified, it is 4412 the default VRF on the node. In DULL GRASP the VRF is implied by 4413 the interface across which DULL GRASP operates. 4415 o If local address is "any", the local address used when initiating 4416 a secure channel connection is decided by source address selection 4417 ([RFC6724] for IPv6). As a responder, the connection listens on 4418 all addresses of the node in the selected VRF. 4420 o Configuration of port is only required for methods where no 4421 defaults exist (e.g., "DTLS"). 4423 o If remote address is "any", the connection is only a responder. 4424 It is a "hub" that can be used by multiple remote peers to connect 4425 simultaneously - without having to know or configure their 4426 addresses. Example: Hub site for remote "spoke" sites reachable 4427 over the Internet. 4429 o Pmtu should be configurable to overcome issues/limitations of Path 4430 MTU Discovery (PMTUD). 4432 o IKEv2/IPsec to remote peers should support the optional NAT 4433 Traversal (NAT-T) procedures. 4435 8.2.2. Tunneled Remote ACP Neighbor 4437 An IPinIP, GRE or other form of pre-existing tunnel is configured 4438 between two remote ACP peers and the virtual interfaces representing 4439 the tunnel are configured for "ACP enable". This will enable IPv6 4440 link local addresses and DULL on this tunnel. In result, the tunnel 4441 is used for normal "L2 adjacent" candidate ACP neighbor discovery 4442 with DULL and secure channel setup procedures described in this 4443 document. 4445 Tunneled Remote ACP Neighbor requires two encapsulations: the 4446 configured tunnel and the secure channel inside of that tunnel. This 4447 makes it in general less desirable than Configured Remote ACP 4448 Neighbor. Benefits of tunnels are that it may be easier to implement 4449 because there is no change to the ACP functionality - just running it 4450 over a virtual (tunnel) interface instead of only native interfaces. 4451 The tunnel itself may also provide PMTUD while the secure channel 4452 method may not. Or the tunnel mechanism is permitted/possible 4453 through some firewall while the secure channel method may not. 4455 8.2.3. Summary 4457 Configured/Tunneled Remote ACP neighbors are less "indestructible" 4458 than L2 adjacent ACP neighbors based on link local addressing, since 4459 they depend on more correct Data-Plane operations, such as routing 4460 and global addressing. 4462 Nevertheless, these options may be crucial to incrementally deploy 4463 the ACP, especially if it is meant to connect islands across the 4464 Internet. Implementations SHOULD support at least Tunneled Remote 4465 ACP Neighbors via GRE tunnels - which is likely the most common 4466 router-to-router tunneling protocol in use today. 4468 9. ACP Operations (Informative) 4470 The following sections document important operational aspects of the 4471 ACP. They are not normative because they do not impact the 4472 interoperability between components of the ACP, but they include 4473 recommendations/requirements for the internal operational model 4474 beneficial or necessary to achieve the desired use-case benefits of 4475 the ACP (see Section 3). 4477 o Section 9.1 describes recommended operator diagnostics 4478 capabilities of ACP nodes. 4480 o Section 9.2 describes high level how an ACP registrar needs to 4481 work, what its configuration parameters are and specific issues 4482 impacting the choices of deployment design due to renewal and 4483 revocation issues. It describes a model where ACP Registrars have 4484 their own sub-CA to provide the most distributed deployment option 4485 for ACP Registrars, and it describes considerations for 4486 centralized policy control of ACP Registrar operations. 4488 o Section 9.3 describes suggested ACP node behavior and operational 4489 interfaces (configuration options) to manage the ACP in so-called 4490 greenfield devices (previously unconfigured) and brownfield 4491 devices (preconfigured). 4493 The recommendations and suggestions of this chapter were derived from 4494 operational experience gained with a commercially available pre- 4495 standard ACP implementation. 4497 9.1. ACP (and BRSKI) Diagnostics 4499 Even though ACP and ANI in general are taking out many manual 4500 configuration mistakes through their automation, it is important to 4501 provide good diagnostics for them. 4503 Basic standardized diagnostics would require support for (yang) 4504 models representing the complete (auto-)configuration and operational 4505 state of all components: GRASP, ACP and the infrastructure used by 4506 them: TLS/DTLS, IPsec, certificates, TA, time, VRF and so on. While 4507 necessary, this is not sufficient: 4509 Simply representing the state of components does not allow operators 4510 to quickly take action - unless they do understand how to interpret 4511 the data, and that can mean a requirement for deep understanding of 4512 all components and how they interact in the ACP/ANI. 4514 Diagnostic supports should help to quickly answer the questions 4515 operators are expected to ask, such as "is the ACP working 4516 correctly?", or "why is there no ACP connection to a known 4517 neighboring node?" 4519 In current network management approaches, the logic to answer these 4520 questions is most often built as centralized diagnostics software 4521 that leverages the above mentioned data models. While this approach 4522 is feasible for components utilizing the ANI, it is not sufficient to 4523 diagnose the ANI itself: 4525 o Developing the logic to identify common issues requires 4526 operational experience with the components of the ANI. Letting 4527 each management system define its own analysis is inefficient. 4529 o When the ANI is not operating correctly, it may not be possible to 4530 run diagnostics from remote because of missing connectivity. The 4531 ANI should therefore have diagnostic capabilities available 4532 locally on the nodes themselves. 4534 o Certain operations are difficult or impossible to monitor in real- 4535 time, such as initial bootstrap issues in a network location where 4536 no capabilities exist to attach local diagnostics. Therefore it 4537 is important to also define means of capturing (logging) 4538 diagnostics locally for later retrieval. Ideally, these captures 4539 are also non-volatile so that they can survive extended power-off 4540 conditions - for example when a device that fails to be brought up 4541 zero-touch is being sent back for diagnostics at a more 4542 appropriate location. 4544 The most simple form of diagnostics answering questions such as the 4545 above is to represent the relevant information sequentially in 4546 dependency order, so that the first non-expected/non-operational item 4547 is the most likely root cause. Or just log/highlight that item. For 4548 example: 4550 Q: Is ACP operational to accept neighbor connections: 4552 o Check if any potentially necessary configuration to make ACP/ANI 4553 operational are correct (see Section 9.3 for a discussion of such 4554 commands). 4556 o Does the system time look reasonable, or could it be the default 4557 system time after clock chip battery failure (certificate checks 4558 depend on reasonable notion of time). 4560 o Does the node have keying material - domain certificate, TA 4561 certificates, .... 4563 o If no keying material and ANI is supported/enabled, check the 4564 state of BRSKI (not detailed in this example). 4566 o Check the validity of the domain certificate: 4568 * Does the certificate validate against the TA? 4570 * Has it been revoked? 4572 * Was the last scheduled attempt to retrieve a CRL successful 4573 (e.g., do we know that our CRL information is up to date). 4575 * Is the certificate valid: validity start time in the past, 4576 expiration time in the future? 4578 * Does the certificate have a correctly formatted acp-node-name 4579 field? 4581 o Was the ACP VRF successfully created? 4583 o Is ACP enabled on one or more interfaces that are up and running? 4585 If all this looks good, the ACP should be running locally "fine" - 4586 but we did not check any ACP neighbor relationships. 4588 Question: why does the node not create a working ACP connection to a 4589 neighbor on an interface? 4590 o Is the interface physically up? Does it have an IPv6 link-local 4591 address? 4593 o Is it enabled for ACP? 4595 o Do we successfully send DULL GRASP messages to the interface (link 4596 layer errors)? 4598 o Do we receive DULL GRASP messages on the interface? If not, some 4599 intervening L2 equipment performing bad MLD snooping could have 4600 caused problems. Provide e.g., diagnostics of the MLD querier 4601 IPv6 and MAC address. 4603 o Do we see the ACP objective in any DULL GRASP message from that 4604 interface? Diagnose the supported secure channel methods. 4606 o Do we know the MAC address of the neighbor with the ACP objective? 4607 If not, diagnose SLAAC/ND state. 4609 o When did we last attempt to build an ACP secure channel to the 4610 neighbor? 4612 o If it failed, why: 4614 * Did the neighbor close the connection on us or did we close the 4615 connection on it because the domain certificate membership 4616 failed? 4618 * If the neighbor closed the connection on us, provide any error 4619 diagnostics from the secure channel protocol. 4621 * If we failed the attempt, display our local reason: 4623 + There was no common secure channel protocol supported by the 4624 two neighbors (this could not happen on nodes supporting 4625 this specification because it mandates common support for 4626 IPsec). 4628 + The ACP certificate membership check (Section 6.1.3) fails: 4630 - The neighbor's certificate is not signed directly or 4631 indirectly by one of the nodes TA. Provide diagnostics 4632 which TA it has (can identify whom the device belongs 4633 to). 4635 - The neighbor's certificate does not have the same domain 4636 (or no domain at all). Diagnose domain-name and 4637 potentially other cert info. 4639 - The neighbor's certificate has been revoked or could not 4640 be authenticated by OCSP. 4642 - The neighbor's certificate has expired - or is not yet 4643 valid. 4645 * Any other connection issues in e.g., IKEv2 / IPsec, DTLS?. 4647 Question: Is the ACP operating correctly across its secure channels? 4649 o Are there one or more active ACP neighbors with secure channels? 4651 o Is the RPL routing protocol for the ACP running? 4653 o Is there a default route to the root in the ACP routing table? 4655 o Is there for each direct ACP neighbor not reachable over the ACP 4656 virtual interface to the root a route in the ACP routing table? 4658 o Is ACP GRASP running? 4660 o Is at least one SRV.est objective cached (to support certificate 4661 renewal)? 4663 o Is there at least one BRSKI registrar objective cached (in case 4664 BRSKI is supported) 4666 o Is BRSKI proxy operating normally on all interfaces where ACP is 4667 operating? 4669 o ... 4671 These lists are not necessarily complete, but illustrate the 4672 principle and show that there are variety of issues ranging from 4673 normal operational causes (a neighbor in another ACP domain) over 4674 problems in the credentials management (certificate lifetimes), 4675 explicit security actions (revocation) or unexpected connectivity 4676 issues (intervening L2 equipment). 4678 The items so far are illustrating how the ANI operations can be 4679 diagnosed with passive observation of the operational state of its 4680 components including historic/cached/counted events. This is not 4681 necessary sufficient to provide good enough diagnostics overall: 4683 The components of ACP and BRSKI are designed with security in mind 4684 but they do not attempt to provide diagnostics for building the 4685 network itself. Consider two examples: 4687 1. BRSKI does not allow for a neighboring device to identify the 4688 pledges IDevID certificate. Only the selected BRSKI registrar 4689 can do this, but it may be difficult to disseminate information 4690 about undesired pledges from those BRSKI registrars to locations/ 4691 nodes where information about those pledges is desired. 4693 2. LLDP disseminates information about nodes to their immediate 4694 neighbors, such as node model/type/software and interface name/ 4695 number of the connection. This information is often helpful or 4696 even necessary in network diagnostics. It can equally considered 4697 to be too insecure to make this information available unprotected 4698 to all possible neighbors. 4700 An "interested adjacent party" can always determine the IDevID 4701 certificate of a BRSKI pledge by behaving like a BRSKI proxy/ 4702 registrar. Therefore the IDevID certificate of a BRSKI pledge is not 4703 meant to be protected - it just has to be queried and is not signaled 4704 unsolicited (as it would be in LLDP) so that other observers on the 4705 same subnet can determine who is an "interested adjacent party". 4707 9.1.1. Secure Channel Peer diagnostics 4709 When using mutual certificate authentication, the TA certificate is 4710 not required to be signalled explicitly because its hash is 4711 sufficient for certificate chain validation. In the case of ACP 4712 secure channel setup this leads to limited diagnostics when 4713 authentication fails because of TA mismatch. For this reason, 4714 Section 6.7.2 recommends to also include the TA certificate in the 4715 secure channel signalling. This should be possible to do without 4716 protocol modifications in the security association protocols used by 4717 the ACP. For example, while [RFC7296] does not mention this, it also 4718 does not prohibit it. 4720 One common deployment use case where the diagnostic through the 4721 signalled TA of a candidate peer is very helpfull are multi-tenant 4722 environments such as office buildings, where different tenants run 4723 their own networks and ACPs. Each tenant is given supposedly 4724 disjoint L2 connectivity through the building infrastructure. In 4725 these environments there are various common errors through which a 4726 device may receive L2 connectivity into the wrong tenants network. 4728 While the ACP itself is not impact by this, the Data-Plane to be 4729 built later may be impacted. Therefore it is important to be able to 4730 diagnose such undesirable connectivity from the ACP so that any 4731 autonomic or non-autonomic mechanisms to configure the Data-Plane can 4732 accordingly treat such interfaces. The information in the TA of the 4733 peer can then ease troubleshooting of such issues. 4735 Another example case is the intended or accidental re-activation of 4736 equipment whose TA certificate has long expired, such as redundant 4737 gear taken from storage after years. Potentially without following 4738 the correct process set up for such cases. 4740 A third example case is when in a mergers&aquisition case ACP nodes 4741 have not been correctly provisioned with the mutual TA of previously 4742 disjoint ACP. This is assuming that the ACP domain names where 4743 already aligned so that the ACP domain membership check is only 4744 failing on the TA. 4746 A fourth example case is when multiple registrars where set up for 4747 the same ACP but without correctly setting up the same TA. For 4748 example when registrars support to also be CA themselves but are 4749 misconfigured to become TA instead of intermediate CA. 4751 9.2. ACP Registrars 4753 As described in Section 6.10.7, the ACP addressing mechanism is 4754 designed to enable lightweight, distributed and uncoordinated ACP 4755 registrars that are providing ACP address prefixes to candidate ACP 4756 nodes by enrolling them with an ACP certificate into an ACP domain 4757 via any appropriate mechanism/protocol, automated or not. 4759 This section discusses informatively more details and options for ACP 4760 registrars. 4762 9.2.1. Registrar interactions 4764 This section summarizes and discusses the interactions with other 4765 entities required by an ACP registrar. 4767 In a simple instance of an ACP network, no central NOC component 4768 beside a TA is required. Typically, this is a root CA. One or more 4769 uncoordinated acting ACP registrar can be set up, performing the 4770 following interactions: 4772 To orchestrate enrolling a candidate ACP node autonomically, the ACP 4773 registrar can rely on the ACP and use Proxies to reach the candidate 4774 ACP node, therefore allowing minimum pre-existing (auto-)configured 4775 network services on the candidate ACP node. BRSKI defines the BRSKI 4776 proxy, a design that can be adopted for various protocols that 4777 Pledges/candidate ACP nodes could want to use, for example BRSKI over 4778 CoAP (Constrained Application Protocol), or proxying of Netconf. 4780 To reach a TA that has no ACP connectivity, the ACP registrar would 4781 use the Data-Plane. ACP and Data-Plane in an ACP registrar could 4782 (and by default should be) completely isolated from each other at the 4783 network level. Only applications such as the ACP registrar would 4784 need the ability for their transport stacks to access both. 4786 In non-autonomic enrollment options, the Data-Plane between a ACP 4787 registrar and the candidate ACP node needs to be configured first. 4788 This includes the ACP registrar and the candidate ACP node. Then any 4789 appropriate set of protocols can be used between ACP registrar and 4790 candidate ACP node to discover the other side, and then connect and 4791 enroll (configure) the candidate ACP node with an ACP certificate. 4792 Netconf ZeroTouch ([RFC8572]) is an example protocol that could be 4793 used for this. BRSKI using optional discovery mechanisms is equally 4794 a possibility for candidate ACP nodes attempting to be enrolled 4795 across non-ACP networks, such as the Internet. 4797 When candidate ACP nodes have secure bootstrap, such as BRSKI 4798 Pledges, they will not trust to be configured/enrolled across the 4799 network, unless being presented with a voucher (see [RFC8366]) 4800 authorizing the network to take possession of the node. An ACP 4801 registrar will then need a method to retrieve such a voucher, either 4802 offline, or online from a MASA (Manufacturer Authorized Signing 4803 Authority). BRSKI and Netconf ZeroTouch are two protocols that 4804 include capabilities to present the voucher to the candidate ACP 4805 node. 4807 An ACP registrar could operate EST for ACP certificate renewal and/or 4808 act as a CRL Distribution point. A node performing these services 4809 does not need to support performing (initial) enrollment, but it does 4810 require the same above described connectivity as an ACP registrar: 4811 via the ACP to ACP nodes and via the Data-Plane to the TA and other 4812 sources of CRL information. 4814 9.2.2. Registrar Parameter 4816 The interactions of an ACP registrar outlined Section 6.10.7 and 4817 Section 9.2.1 above depend on the following parameters: 4819 A URL to the TA and credentials so that the ACP registrar can let 4820 the TA sign candidate ACP node certificates. 4822 The ACP domain-name. 4824 The Registrar-ID to use. This could default to a MAC address of 4825 the ACP registrar. 4827 For recovery, the next-useable Node-IDs for zone (Zone-ID=0) sub- 4828 addressing scheme, for Vlong /112 and for Vlong /120 sub- 4829 addressing scheme. These IDs would only need to be provisioned 4830 after recovering from a crash. Some other mechanism would be 4831 required to remember these IDs in a backup location or to recover 4832 them from the set of currently known ACP nodes. 4834 Policies if candidate ACP nodes should receive a domain 4835 certificate or not, for example based on the devices IDevID 4836 certificate as in BRSKI. The ACP registrar may have a whitelist 4837 or blacklist of devices "serialNumbers" from their IDevID 4838 certificate. 4840 Policies what type of address prefix to assign to a candidate ACP 4841 devices, based on likely the same information. 4843 For BRSKI or other mechanisms using vouchers: Parameters to 4844 determine how to retrieve vouchers for specific type of secure 4845 bootstrap candidate ACP nodes (such as MASA URLs), unless this 4846 information is automatically learned such as from the IDevID 4847 certificate of candidate ACP nodes (as defined in BRSKI). 4849 9.2.3. Certificate renewal and limitations 4851 When an ACP node renews/rekeys its certificate, it may end up doing 4852 so via a different registrar (e.g., EST server) than the one it 4853 originally received its ACP certificate from, for example because 4854 that original ACP registrar is gone. The ACP registrar through which 4855 the renewal/rekeying is performed would by default trust the acp- 4856 node-name from the ACP nodes current ACP certificate and maintain 4857 this information so that the ACP node maintains its ACP address 4858 prefix. In EST renewal/rekeying, the ACP nodes current ACP 4859 certificate is signaled during the TLS handshake. 4861 This simple scenario has two limitations: 4863 1. The ACP registrars cannot directly assign certificates to nodes 4864 and therefore needs an "online" connection to the TA. 4866 2. Recovery from a compromised ACP registrar is difficult. When an 4867 ACP registrar is compromised, it can insert for example a 4868 conflicting acp-node-name and create thereby an attack against 4869 other ACP nodes through the ACP routing protocol. 4871 Even when such a malicious ACP registrar is detected, resolving the 4872 problem may be difficult because it would require identifying all the 4873 wrong ACP certificates assigned via the ACP registrar after it was 4874 compromised. And without additional centralized tracking of assigned 4875 certificates there is no way to do this. 4877 9.2.4. ACP Registrars with sub-CA 4879 In situations, where either of the above two limitations are an 4880 issue, ACP registrars could also be sub-CAs. This removes the need 4881 for connectivity to a TA whenever an ACP node is enrolled, and 4882 reduces the need for connectivity of such an ACP registrar to a TA to 4883 only those times when it needs to renew its own certificate. The ACP 4884 registrar would also now use its own (sub-CA) certificate to enroll 4885 and sign the ACP nodes certificates, and therefore it is only 4886 necessary to revoke a compromised ACP registrars sub-CA certificate. 4887 Alternatively one can let it expire and not renew it, when the 4888 certificate of the sub-CA is appropriately short-lived. 4890 As the ACP domain membership check verifies a peer ACP node's ACP 4891 certificate trust chain, it will also verify the signing certificate 4892 which is the compromised/revoked sub-CA certificate. Therefore ACP 4893 domain membership for an ACP node enrolled from a compromised and 4894 discovered ACP registrar will fail. 4896 ACP nodes enrolled by a compromised ACP registrar would automatically 4897 fail to establish ACP channels and ACP domain certificate renewal via 4898 EST and therefore revert to their role as a candidate ACP members and 4899 attempt to get a new ACP certificate from an ACP registrar - for 4900 example, via BRSKI. In result, ACP registrars that have an 4901 associated sub-CA makes isolating and resolving issues with 4902 compromised registrars easier. 4904 Note that ACP registrars with sub-CA functionality also can control 4905 the lifetime of ACP certificates easier and therefore also be used as 4906 a tool to introduce short lived certificates and not rely on CRL, 4907 whereas the certificates for the sub-CAs themselves could be longer 4908 lived and subject to CRL. 4910 9.2.5. Centralized Policy Control 4912 When using multiple, uncoordinated ACP registrars, several advanced 4913 operations are potentially more complex than with a single, resilient 4914 policy control backend, for example including but not limited to: 4916 Which candidate ACP node is permitted or not permitted into an ACP 4917 domain. This may not be a decision to be taken upfront, so that a 4918 per-"serialNumber" policy can be loaded into every ACP registrar. 4919 Instead, it may better be decided in real-time including 4920 potentially a human decision in a NOC. 4922 Tracking of all enrolled ACP nodes and their certificate 4923 information. For example in support of revoking individual ACP 4924 nodes certificates. 4926 More flexible policies what type of address prefix or even what 4927 specific address prefix to assign to a candidate ACP node. 4929 These and other operations could be introduced more easily by 4930 introducing a centralized Policy Management System (PMS) and 4931 modifying ACP registrar behavior so that it queries the PMS for any 4932 policy decision occurring during the candidate ACP node enrollment 4933 process and/or the ACP node certificate renewal process. For 4934 example, which ACP address prefix to assign. Likewise the ACP 4935 registrar would report any relevant state change information to the 4936 PMS as well, for example when a certificate was successfully enrolled 4937 onto a candidate ACP node. 4939 9.3. Enabling and disabling ACP/ANI 4941 Both ACP and BRSKI require interfaces to be operational enough to 4942 support sending/receiving their packets. In node types where 4943 interfaces are by default (e.g., without operator configuration) 4944 enabled, such as most L2 switches, this would be less of a change in 4945 behavior than in most L3 devices (e.g.: routers), where interfaces 4946 are by default disabled. In almost all network devices it is common 4947 though for configuration to change interfaces to a physically 4948 disabled state and that would break the ACP. 4950 In this section, we discuss a suggested operational model to enable/ 4951 disable interfaces and nodes for ACP/ANI in a way that minimizes the 4952 risk of operator action to break the ACP in this way, and that also 4953 minimizes operator surprise when ACP/ANI becomes supported in node 4954 software. 4956 9.3.1. Filtering for non-ACP/ANI packets 4958 Whenever this document refers to enabling an interface for ACP (or 4959 BRSKI), it only requires to permit the interface to send/receive 4960 packets necessary to operate ACP (or BRSKI) - but not any other Data- 4961 Plane packets. Unless the Data-Plane is explicitly configured/ 4962 enabled, all packets not required for ACP/BRSKI should be filtered on 4963 input and output: 4965 Both BRSKI and ACP require link-local only IPv6 operations on 4966 interfaces and DULL GRASP. IPv6 link-local operations means the 4967 minimum signaling to auto-assign an IPv6 link-local address and talk 4968 to neighbors via their link-local address: SLAAC (Stateless Address 4969 Auto-Configuration - [RFC4862]) and ND (Neighbor Discovery - 4970 [RFC4861]). When the device is a BRSKI pledge, it may also require 4971 TCP/TLS connections to BRSKI proxies on the interface. When the 4972 device has keying material, and the ACP is running, it requires DULL 4973 GRASP packets and packets necessary for the secure-channel mechanism 4974 it supports, e.g., IKEv2 and IPsec ESP packets or DTLS packets to the 4975 IPv6 link-local address of an ACP neighbor on the interface. It also 4976 requires TCP/TLS packets for its BRSKI proxy functionality, if it 4977 does support BRSKI. 4979 9.3.2. Admin Down State 4981 Interfaces on m ost network equipment have at least two states: "up" 4982 and "down". These may have product specific names. "down" for 4983 example could be called "shutdown" and "up" could be called "no 4984 shutdown". The "down" state disables all interface operations down 4985 to the physical level. The "up" state enables the interface enough 4986 for all possible L2/L3 services to operate on top of it and it may 4987 also auto-enable some subset of them. More commonly, the operations 4988 of various L2/L3 services is controlled via additional node-wide or 4989 interface level options, but they all become only active when the 4990 interface is not "down". Therefore an easy way to ensure that all 4991 L2/L3 operations on an interface are inactive is to put the interface 4992 into "down" state. The fact that this also physically shuts down the 4993 interface is in many cases just a side effect, but it may be 4994 important in other cases (see below, Section 9.3.2.2). 4996 One of the common problems of remote management is for the operator 4997 or SDN controller to cut its own connectivity to the remote node by a 4998 configuration impacting its own management connection into the node. 4999 The ACP itself should have no dedicated configuration other than 5000 aforementioned enablement of the ACP on brownfield ACP nodes. This 5001 leaves configuration that can not distinguish between ACP and Data- 5002 Plane as sources of configuration mistakes as these commands will 5003 impact the ACP even though they should only impact the Data-Plane. 5005 The one ubiquitous type of commands that do this on many type of 5006 routers are interface "down" commands/configurations. When such a 5007 command is applied to the interface through which the ACP provides 5008 access for remote management it would cut the remote management 5009 connection through the ACP because, as outlined above, the "down" 5010 commands typically impact the physical layer too and not only the 5011 Data-Plane services. 5013 To provide ACP/ANI resilience against such operator misconfiguration, 5014 this document recommends to separate the "down" state of interfaces 5015 into an "admin down" state where the physical layer is kept running 5016 and ACP/ANI can use the interface and a "physical down" state. Any 5017 existing "down" configurations would map to "admin down". In "admin 5018 down", any existing L2/L3 services of the Data-Plane should see no 5019 difference to "physical down" state. To ensure that no Data-Plane 5020 packets could be sent/received, packet filtering could be established 5021 automatically as described above in Section 9.3.1. 5023 An example of non-ACP but ANI traffic that should be permitted to 5024 pass even in "admin-down" state is BRSKI enrollment traffic between 5025 BRSKI pledge and a BRSKI proxy. 5027 As necessary (see discussion below) new configuration options could 5028 be introduced to issue "physical down". The options should be 5029 provided with additional checks to minimize the risk of issuing them 5030 in a way that breaks the ACP without automatic restoration. For 5031 example they could be denied to be issued from a control connection 5032 (netconf/ssh) that goes across the interface itself ("do not 5033 disconnect yourself"). Or they could be performed only temporary and 5034 only be made permanent with additional later reconfirmation. 5036 In the following sub-sections important aspects to the introduction 5037 of "admin down" state are discussed. 5039 9.3.2.1. Security 5041 Interfaces are physically brought down (or left in default down 5042 state) as a form of security. "Admin down" state as described above 5043 provides also a high level of security because it only permits ACP/ 5044 ANI operations which are both well secured. Ultimately, it is 5045 subject to security review for the deployment whether "admin down" is 5046 a feasible replacement for "physical down". 5048 The need to trust the security of ACP/ANI operations needs to be 5049 weighed against the operational benefits of permitting this: Consider 5050 the typical example of a CPE (customer premises equipment) with no 5051 on-site network expert. User ports are in physical down state unless 5052 explicitly configured not to be. In a misconfiguration situation, 5053 the uplink connection is incorrectly plugged into such as user port. 5054 The device is disconnected from the network and therefore no 5055 diagnostics from the network side is possible anymore. 5056 Alternatively, all ports default to "admin down". The ACP (but not 5057 the Data-Plane) would still automatically form. Diagnostics from the 5058 network side is possible and operator reaction could include to 5059 either make this port the operational uplink port or to instruct re- 5060 cabling. Security wise, only ACP/ANI could be attacked, all other 5061 functions are filtered on interfaces in "admin down" state. 5063 9.3.2.2. Fast state propagation and Diagnostics 5065 "Physical down" state propagates on many interface types (e.g., 5066 Ethernet) to the other side. This can trigger fast L2/L3 protocol 5067 reaction on the other side and "admin down" would not have the same 5068 (fast) result. 5070 Bringing interfaces to "physical down" state is to the best of our 5071 knowledge always a result of operator action, but today, never the 5072 result of autonomic L2/L3 services running on the nodes. Therefore 5073 one option is to change the operator action to not rely on link-state 5074 propagation anymore. This may not be possible when both sides are 5075 under different operator control, but in that case it is unlikely 5076 that the ACP is running across the link and actually putting the 5077 interface into "physical down" state may still be a good option. 5079 Ideally, fast physical state propagation is replaced by fast software 5080 driven state propagation. For example a DULL GRASP "admin-state" 5081 objective could be used to auto configure a Bidirectional Forwarding 5082 Protocol (BFD, [RFC5880]) session between the two sides of the link 5083 that would be used to propagate the "up" vs. admin down state. 5085 Triggering physical down state may also be used as a mean of 5086 diagnosing cabling in the absence of easier methods. It is more 5087 complex than automated neighbor diagnostics because it requires 5088 coordinated remote access to both (likely) sides of a link to 5089 determine whether up/down toggling will cause the same reaction on 5090 the remote side. 5092 See Section 9.1 for a discussion about how LLDP and/or diagnostics 5093 via GRASP could be used to provide neighbor diagnostics, and 5094 therefore hopefully eliminating the need for "physical down" for 5095 neighbor diagnostics - as long as both neighbors support ACP/ANI. 5097 9.3.2.3. Low Level Link Diagnostics 5099 "Physical down" is performed to diagnose low-level interface behavior 5100 when higher layer services (e.g., IPv6) are not working. Especially 5101 Ethernet links are subject to a wide variety of possible wrong 5102 configuration/cablings if they do not support automatic selection of 5103 variable parameters such as speed (10/100/1000 Mbps), crossover 5104 (Auto-MDIX) and connector (fiber, copper - when interfaces have 5105 multiple but can only enable one at a time). The need for low level 5106 link diagnostic can therefore be minimized by using fully auto 5107 configuring links. 5109 In addition to "Physical down", low level diagnostics of Ethernet or 5110 other interfaces also involve the creation of other states on 5111 interfaces, such as physical Loopback (internal and/or external) or 5112 bringing down all packet transmissions for reflection/cable-length 5113 measurements. Any of these options would disrupt ACP as well. 5115 In cases where such low-level diagnostics of an operational link is 5116 desired but where the link could be a single point of failure for the 5117 ACP, ASA on both nodes of the link could perform a negotiated 5118 diagnostics that automatically terminates in a predetermined manner 5119 without dependence on external input ensuring the link will become 5120 operational again. 5122 9.3.2.4. Power Consumption Issues 5124 Power consumption of "physical down" interfaces, may be significantly 5125 lower than those in "admin down" state, for example on long-range 5126 fiber interfaces. Bringing up interfaces, for example to probe 5127 reachability, may also consume additional power. This can make these 5128 type of interfaces inappropriate to operate purely for the ACP when 5129 they are not currently needed for the Data-Plane. 5131 9.3.3. Interface level ACP/ANI enable 5133 The interface level configuration option "ACP enable" enables ACP 5134 operations on an interface, starting with ACP neighbor discovery via 5135 DULL GRAP. The interface level configuration option "ANI enable" on 5136 nodes supporting BRSKI and ACP starts with BRSKI pledge operations 5137 when there is no domain certificate on the node. On ACP/BRSKI nodes, 5138 "ACP enable" may not need to be supported, but only "ANI enable". 5139 Unless overridden by global configuration options (see later), "ACP/ 5140 ANI enable" will result in "down" state on an interface to behave as 5141 "admin down". 5143 9.3.4. Which interfaces to auto-enable? 5145 (Section 6.3) requires that "ACP enable" is automatically set on 5146 native interfaces, but not on non-native interfaces (reminder: a 5147 native interface is one that exists without operator configuration 5148 action such as physical interfaces in physical devices). 5150 Ideally, ACP enable is set automatically on all interfaces that 5151 provide access to additional connectivity that allows to reach more 5152 nodes of the ACP domain. The best set of interfaces necessary to 5153 achieve this is not possible to determine automatically. Native 5154 interfaces are the best automatic approximation. 5156 Consider an ACP domain of ACP nodes transitively connected via native 5157 interfaces. A Data-Plane tunnel between two of these nodes that are 5158 non-adjacent is created and "ACP enable" is set for that tunnel. ACP 5159 RPL sees this tunnel as just as a single hop. Routes in the ACP 5160 would use this hop as an attractive path element to connect regions 5161 adjacent to the tunnel nodes. In result, the actual hop-by-hop paths 5162 used by traffic in the ACP can become worse. In addition, correct 5163 forwarding in the ACP now depends on correct Data-Plane forwarding 5164 config including QoS, filtering and other security on the Data-Plane 5165 path across which this tunnel runs. This is the main issue why "ACP/ 5166 ANI enable" should not be set automatically on non-native interfaces. 5168 If the tunnel would connect two previously disjoint ACP regions, then 5169 it likely would be useful for the ACP. A Data-Plane tunnel could 5170 also run across nodes without ACP and provide additional connectivity 5171 for an already connected ACP network. The benefit of this additional 5172 ACP redundancy has to be weighed against the problems of relying on 5173 the Data-Plane. If a tunnel connects two separate ACP regions: how 5174 many tunnels should be created to connect these ACP regions reliably 5175 enough? Between which nodes? These are all standard tunneled 5176 network design questions not specific to the ACP, and there are no 5177 generic fully automated answers. 5179 Instead of automatically setting "ACP enable" on these type of 5180 interfaces, the decision needs to be based on the use purpose of the 5181 non-native interface and "ACP enable" needs to be set in conjunction 5182 with the mechanism through which the non-native interface is created/ 5183 configured. 5185 In addition to explicit setting of "ACP/ANI enable", non-native 5186 interfaces also need to support configuration of the ACP RPL cost of 5187 the link - to avoid the problems of attracting too much traffic to 5188 the link as described above. 5190 Even native interfaces may not be able to automatically perform BRSKI 5191 or ACP because they may require additional operator input to become 5192 operational. Example include DSL interfaces requiring PPPoE 5193 credentials or mobile interfaces requiring credentials from a SIM 5194 card. Whatever mechanism is used to provide the necessary config to 5195 the device to enable the interface can also be expanded to decide on 5196 whether or not to set "ACP/ANI enable". 5198 The goal of automatically setting "ACP/ANI enable" on interfaces 5199 (native or not) is to eliminate unnecessary "touches" to the node to 5200 make its operation as much as possible "zero-touch" with respect to 5201 ACP/ANI. If there are "unavoidable touches" such a creating/ 5202 configuring a non-native interface or provisioning credentials for a 5203 native interface, then "ACP/ANI enable" should be added as an option 5204 to that "touch". If a wrong "touch" is easily fixed (not creating 5205 another high-cost touch), then the default should be not to enable 5206 ANI/ACP, and if it is potentially expensive or slow to fix (e.g., 5207 parameters on SIM card shipped to remote location), then the default 5208 should be to enable ACP/ANI. 5210 9.3.5. Node Level ACP/ANI enable 5212 A node level command "ACP/ANI enable [up-if-only]" enables ACP or ANI 5213 on the node (ANI = ACP + BRSKI). Without this command set, any 5214 interface level "ACP/ANI enable" is ignored. Once set, ACP/ANI will 5215 operate an interface where "ACP/ANI enable" is set. Setting of 5216 interface level "ACP/ANI enable" is either automatic (default) or 5217 explicit through operator action as described in the previous 5218 section. 5220 If the option "up-if-only" is selected, the behavior of "down" 5221 interfaces is unchanged, and ACP/ANI will only operate on interfaces 5222 where "ACP/ANI enable" is set and that are "up". When it is not set, 5223 then "down" state of interfaces with "ACP/ANI enable" is modified to 5224 behave as "admin down". 5226 9.3.5.1. Brownfield nodes 5228 A "brownfield" node is one that already has a configured Data-Plane. 5230 Executing global "ACP/ANI enable [up-if-only]" on each node is the 5231 only command necessary to create an ACP across a network of 5232 brownfield nodes once all the nodes have a domain certificate. When 5233 BRSKI is used ("ANI enable"), provisioning of the certificates only 5234 requires set-up of a single BRSKI registrar node which could also 5235 implement a CA for the network. This is the most simple way to 5236 introduce ACP/ANI into existing (== brownfield) networks. 5238 The need to explicitly enable ACP/ANI is especially important in 5239 brownfield nodes because otherwise software updates may introduce 5240 support for ACP/ANI: Automatic enablement of ACP/ANI in networks 5241 where the operator does not only not want ACP/ANI but where the 5242 operator likely never even heard of it could be quite irritating to 5243 the operator. Especially when "down" behavior is changed to "admin 5244 down". 5246 Automatically setting "ANI enable" on brownfield nodes where the 5247 operator is unaware of BRSKI and MASA operations could also be an 5248 unlikely but then critical security issue. If an attacker could 5249 impersonate the operator and register as the operator at the MASA or 5250 otherwise get hold of vouchers and can get enough physical access to 5251 the network so pledges would register to an attacking registrar, then 5252 the attacker could gain access to the network through the ACP that 5253 the attacker then has access to. 5255 In networks where the operator explicitly wants to enable the ANI 5256 this could not happen, because the operator would create a BRSKI 5257 registrar that would discover attack attempts, and the operator would 5258 be setting up his registrar with the MASA. Nodes requiring 5259 "ownership vouchers" would not be subject to that attack. See 5260 [I-D.ietf-anima-bootstrapping-keyinfra] for more details. Note that 5261 a global "ACP enable" alone is not subject to these type of attacks, 5262 because it always depends on some other mechanism first to provision 5263 domain certificates into the device. 5265 9.3.5.2. Greenfield nodes 5267 A "greenfield" node is one that did not have any prior configuration. 5269 For greenfield nodes, only "ANI enable" is relevant. If another 5270 mechanism than BRSKI is used to (zero-touch) bootstrap a node, then 5271 it is up to that mechanism to provision domain certificates and to 5272 set global "ACP enable" as desired. 5274 Nodes supporting full ANI functionality set "ANI enable" 5275 automatically when they decide that they are greenfield, e.g., that 5276 they are powering on from factory condition. They will then put all 5277 native interfaces into "admin down" state and start to perform BRSKI 5278 pledge functionality - and once a domain certificate is enrolled they 5279 automatically enable ACP. 5281 Attempts for BRSKI pledge operations in greenfield state should 5282 terminate automatically when another method of configuring the node 5283 is used. Methods that indicate some form of physical possession of 5284 the device such as configuration via the serial console port could 5285 lead to immediate termination of BRSKI, while other parallel auto 5286 configuration methods subject to remote attacks might lead to BRSKI 5287 termination only after they were successful. Details of this may 5288 vary widely over different type of nodes. When BRSKI pledge 5289 operation terminates, this will automatically unset "ANI enable" and 5290 should terminate any temporarily needed state on the device to 5291 perform BRSKI - DULL GRASP, BRSKI pledge and any IPv6 configuration 5292 on interfaces. 5294 9.3.6. Undoing ANI/ACP enable 5296 Disabling ANI/ACP by undoing "ACP/ANI enable" is a risk for the 5297 reliable operations of the ACP if it can be executed by mistake or 5298 unauthorized. This behavior could be influenced through some 5299 additional (future) property in the certificate (e.g., in the acp- 5300 node-name extension field): In an ANI deployment intended for 5301 convenience, disabling it could be allowed without further 5302 constraints. In an ANI deployment considered to be critical more 5303 checks would be required. One very controlled option would be to not 5304 permit these commands unless the domain certificate has been revoked 5305 or is denied renewal. Configuring this option would be a parameter 5306 on the BRSKI registrar(s). As long as the node did not receive a 5307 domain certificate, undoing "ANI/ACP enable" should not have any 5308 additional constraints. 5310 9.3.7. Summary 5312 Node-wide "ACP/ANI enable [up-if-only]" commands enable the operation 5313 of ACP/ANI. This is only auto-enabled on ANI greenfield devices, 5314 otherwise it must be configured explicitly. 5316 If the option "up-if-only" is not selected, interfaces enabled for 5317 ACP/ANI interpret "down" state as "admin down" and not "physical 5318 down". In "admin-down" all non-ACP/ANI packets are filtered, but the 5319 physical layer is kept running to permit ACP/ANI to operate. 5321 (New) commands that result in physical interruption ("physical down", 5322 "loopback") of ACP/ANI enabled interfaces should be built to protect 5323 continuance or reestablishment of ACP as much as possible. 5325 Interface level "ACP/ANI enable" control per-interface operations. 5326 It is enabled by default on native interfaces and has to be 5327 configured explicitly on other interfaces. 5329 Disabling "ACP/ANI enable" global and per-interface should have 5330 additional checks to minimize undesired breakage of ACP. The degree 5331 of control could be a domain wide parameter in the domain 5332 certificates. 5334 9.4. Partial or Incremental adoption 5336 The ACP Zone Addressing Sub-Scheme (see Section 6.10.3) allows 5337 incremental adoption of the ACP in a network where ACP can be 5338 deployed on edge areas, but not across the core that is connecting 5339 those edges. 5341 In such a setup, each edge network, such as a branch or campus of an 5342 enterprise network has a disjoined ACP to which one or more unique 5343 Zone-IDs are assigned: ACP nodes registered for a specific ACP zone 5344 have to receive ACP Zone Addressing Sub-scheme addresses, for example 5345 by virtue of configuring for each such zone one or more ACP 5346 Registrars with that Zone-ID. All the Registrars for these ACP Zones 5347 need to get ACP certificates from CAs relying on a common set of TA 5348 and of course the same ACP domain name. 5350 These ACP zones can first be brought up as separate networks without 5351 any connection between them and/or they can be connected across a 5352 non-ACP enabled core network through various non-autonomic 5353 operational practices. For example, each separate ACP Zone can have 5354 an edge node that is a layer 3 VPN PE (MPLS or IPv6 layer 3 VPN), 5355 where a complete non-autonomic ACP-Core VPN is created by using the 5356 ACP VRFs and exchanging the routes from those ACP VRFs across the 5357 VPNs non-autonomic routing protocol(s). 5359 While such a setup is possible with any ACP addressing sub-scheme, 5360 the ACP-Zone Addressing sub-scheme makes it easy to configure and 5361 scalable for any VPN routing protocols because every ACP zone would 5362 only need to indicate one or more /64 ACP Zone Addressing prefix 5363 routes into the ACP-Core VPN as opposed to routes for every 5364 individual ACP node as required in the other ACP addressing schemes. 5366 Note that the non-autonomous ACP-Core VPN would require additional 5367 extensions to propagate GRASP messages when GRASP discovery is 5368 desired across the zones. For example, one could set up on each Zone 5369 edge router remote ACP tunnel to an appplication level implemented 5370 GRASP hub running in the networks NOC that is generating GRASP 5371 announcements for NOC services into the ACP Zones or propagating them 5372 between ACP Zones. 5374 Such partial deployment may prove to be sufficient or could evolve to 5375 become more autonomous through future standardized or non- 5376 standardized enhancements, for example by allowing GRASP messages to 5377 be propagated across the layer 3 VPN, leveraging for example L3VPN 5378 Multicast support. 5380 Finally, these partial deployments can be merged into a single 5381 contiguous complete autonomous ACP (given appropriate ACP support 5382 across the core) without changes in the crypto material, because the 5383 nodes ACP certificates are fromm a single ACP. 5385 9.5. Configuration and the ACP (summary) 5387 There is no desirable configuration for the ACP. Instead, all 5388 parameters that need to be configured in support of the ACP are 5389 limitations of the solution, but they are only needed in cases where 5390 not all components are made autonomic. Whereever this is necessary, 5391 it relies on pre-existing mechanisms for configuration such as CLI or 5392 YANG ([RFC7950]) data models. 5394 The most important examples of such configuration include: 5396 o When ACP nodes do not support an autonomic way to receive an ACP 5397 certificate, for example BRSKI, then such certificate needs to be 5398 configured via some pre-existing mechanisms outside the scope of 5399 this specification. Today, router have typically a variety of 5400 mechanisms to do this. 5402 o Certificate maintenance requires PKI functions. Discovery of 5403 these functions across the ACP is automated (see Section 6.1.5), 5404 but their configuration is not. 5406 o When non-ACP capable nodes such as pre-existing NMS need to be 5407 physically connected to the ACP, the ACP node to which they attach 5408 needs to be configured with ACP-connect according to Section 8.1. 5409 It is also possible to use that single physical connection to 5410 connect both to ACP and the Data-Plane of the network as explained 5411 in Section 8.1.4. 5413 o When devices are not autonomically bootstrapped, explicit 5414 configuration to enable the ACP needs to be applied. See 5415 Section 9.3. 5417 o When the ACP needs to be extended across interfacess other than 5418 L2, the ACP as defined in this document can not autodiscover 5419 candidate neighbors automatically. Remote neighbors need to be 5420 configured, see Section 8.2. 5422 Once the ACP is operating, any further configuration for the Data- 5423 Plane can be configured more reliably across the ACP itself because 5424 the ACP provides addressing and connectivity (routing) independent of 5425 the Data-Plane itself. For this, the configuration methods simply 5426 need to also allow to operate across the ACP VRF - netconf, ssh or 5427 any other method. 5429 The ACP also provides additional security through its hop-by-hop 5430 encryption for any such configuration operations: Some legacy 5431 configuration methods (SNMP, TFTP, HTTP) may not use end-to-end 5432 encryption, and most of the end-to-end secured configuration methods 5433 still allow for easy passive observation along the path about 5434 configuration taking place (transport flows, port numbers, IP 5435 addresses). 5437 The ACP can and should equally be used as the transport to configure 5438 any of the aforemention non-automic components of the ACP, but in 5439 that case, the same caution needs to be exercised as with Data-Plane 5440 configuration without ACP: Misconfiguration may cause the configuring 5441 entity to be disconnected from the node it configures - for example 5442 when incorrectly unconfiguring a remote ACP neighbor through which 5443 the configured ACP node is reached. 5445 10. Summary: Benefits (Informative) 5446 10.1. Self-Healing Properties 5448 The ACP is self-healing: 5450 o New neighbors will automatically join the ACP after successful 5451 validation and will become reachable using their unique ULA 5452 address across the ACP. 5454 o When any changes happen in the topology, the routing protocol used 5455 in the ACP will automatically adapt to the changes and will 5456 continue to provide reachability to all nodes. 5458 o The ACP tracks the validity of peer certificates and tears down 5459 ACP secure channels when a peer certificate has expired. When 5460 short-lived certificates with lifetimes in the order of OCSP/CRL 5461 refresh times are used, then this allows for removal of invalid 5462 peers (whose certificate was not renewed) at similar speeds as 5463 when using OCSP/CRL. The same benefit can be achieved when using 5464 CRL/OCSP, periodically refreshing the revocation information and 5465 also tearing down ACP secure channels when the peer's (long-lived) 5466 certificate is revoked. There is no requirement against ACP 5467 implementations to require this enhancement though to keep the 5468 mandatory implementations simpler. 5470 The ACP can also sustain network partitions and mergers. Practically 5471 all ACP operations are link local, where a network partition has no 5472 impact. Nodes authenticate each other using the domain certificates 5473 to establish the ACP locally. Addressing inside the ACP remains 5474 unchanged, and the routing protocol inside both parts of the ACP will 5475 lead to two working (although partitioned) ACPs. 5477 There are few central dependencies: A CRL may not be available during 5478 a network partition; a suitable policy to not immediately disconnect 5479 neighbors when no CRL is available can address this issue. Also, an 5480 ACP Registrar or Certification Authority might not be available 5481 during a partition. This may delay renewal of certificates that are 5482 to expire in the future, and it may prevent the enrollment of new 5483 nodes during the partition. 5485 Highly resilient ACP designs can be built by using ACP Registrars 5486 with embedded sub-CA, as outlined in Section 9.2.4. As long as a 5487 partition is left with one or more of such ACP Registrars, it can 5488 continue to enroll new candidate ACP nodes as long as the ACP 5489 Registrar's sub-CA certificate does not expire. Because the ACP 5490 addressing relies on unique Registrar-IDs, a later re-merge of 5491 partitions will also not cause problems with ACP addresses assigned 5492 during partitioning. 5494 After a network partition, a re-merge will just establish the 5495 previous status, certificates can be renewed, the CRL is available, 5496 and new nodes can be enrolled everywhere. Since all nodes use the 5497 same TA, a re-merge will be smooth. 5499 Merging two networks with different TA requires the ACP nodes to 5500 trust the union of TA. As long as the routing-subdomain hashes are 5501 different, the addressing will not overlap, which only happens in the 5502 unlikely event of a 40-bit hash collision in SHA256 (see 5503 Section 6.10). Note that the complete mechanisms to merge networks 5504 is out of scope of this specification. 5506 It is also highly desirable for implementation of the ACP to be able 5507 to run it over interfaces that are administratively down. If this is 5508 not feasible, then it might instead be possible to request explicit 5509 operator override upon administrative actions that would 5510 administratively bring down an interface across which the ACP is 5511 running. Especially if bringing down the ACP is known to disconnect 5512 the operator from the node. For example any such down administrative 5513 action could perform a dependency check to see if the transport 5514 connection across which this action is performed is affected by the 5515 down action (with default RPL routing used, packet forwarding will be 5516 symmetric, so this is actually possible to check). 5518 10.2. Self-Protection Properties 5520 10.2.1. From the outside 5522 As explained in Section 6, the ACP is based on secure channels built 5523 between nodes that have mutually authenticated each other with their 5524 domain certificates. The channels themselves are protected using 5525 standard encryption technologies such as DTLS or IPsec which provide 5526 additional authentication during channel establishment, data 5527 integrity and data confidentiality protection of data inside the ACP 5528 and in addition, provide replay protection. 5530 Attacker will not be able to join the ACP unless they have a valid 5531 ACP certificate. On-path attackers without a valid ACP certificate 5532 can not inject packets into the ACP due to ACP secure channels. They 5533 can also not decrypt ACP traffic except if they can crack the 5534 encryption. They can attempt behavioral traffic analysis on the 5535 encrypted ACP traffic. 5537 The degree to which compromised ACP nodes can impact the ACP depends 5538 on the implementation of the ACP nodes and their impairment. When an 5539 attacker has only gained administrative privileges to configure ACP 5540 nodes remotely, the attacker can disrupt the ACP only through one of 5541 the few configuration options to disable it, see Section 9.3, or by 5542 configuring of non-autonomic ACP options if those are supported on 5543 the impaired ACP nodes, see Section 8. Injecting or ectracting 5544 traffic into/from an impaired ACP node is only possible when an 5545 impaired ACP node supports ACP connect (see Section 8.1) and the 5546 attacker can control traffic into/from one of the ACP nodes 5547 interfaces, such as by having physical access to the ACP node. 5549 The ACP also serves as protection (through authentication and 5550 encryption) for protocols relevant to OAM that may not have secured 5551 protocol stack options or where implementation or deployment of those 5552 options fail on some vendor/product/customer limitations. This 5553 includes protocols such as SNMP ([RFC3411]), NTP ([RFC5905]), PTP 5554 ([IEEE-1588-2008]), DNS ([RFC3596]), DHCPv6 ([RFC3315]), syslog 5555 ([RFC3164]), Radius ([RFC2865]), Diameter ([RFC6733]), TACACS 5556 ([RFC1492]), IPFIX ([RFC7011]), Netflow ([RFC3954]) - just to name a 5557 few. Not all of these protocol references are necessarily the latest 5558 version of protocols but versions that are still widely deployed. 5560 Protection via the ACP secure hop-by-hop channels for these protocols 5561 is meant to be only a stopgap though: The ultimate goal is for these 5562 and other protocols to use end-to-end encryption utilizing the domain 5563 certificate and rely on the ACP secure channels primarily for zero- 5564 touch reliable connectivity, but not primarily for security. 5566 The remaining attack vector would be to attack the underlying ACP 5567 protocols themselves, either via directed attacks or by denial-of- 5568 service attacks. However, as the ACP is built using link-local IPv6 5569 addresses, remote attacks from the Data-Plane are impossible as long 5570 as the Data-Plane has no facilities to remotely sent IPv6 link-local 5571 packets. The only exception are ACP connected interfaces which 5572 require higher physical protection. The ULA addresses are only 5573 reachable inside the ACP context, therefore, unreachable from the 5574 Data-Plane. Also, the ACP protocols should be implemented to be 5575 attack resistant and not consume unnecessary resources even while 5576 under attack. 5578 10.2.2. From the inside 5580 The security model of the ACP is based on trusting all members of the 5581 group of nodes that receive an ACP certificate for the same domain. 5582 Attacks from the inside by a compromised group member are therefore 5583 the biggest challenge. 5585 Group members must be protected against attackers so that there is no 5586 easy way to compromise them, or use them as a proxy for attacking 5587 other devices across the ACP. For example, management plane 5588 functions (transport ports) should only be reachable from the ACP but 5589 not the Data-Plane. Especially for those management plane functions 5590 that have no good protection by themselves because they do not have 5591 secure end-to-end transport and to whom ACP not only provides 5592 automatic reliable connectivity but also protection against attacks. 5593 Protection across all potential attack vectors is typically easier to 5594 do in devices whose software is designed from the ground up with ACP 5595 in mind than with legacy software based systems where the ACP is 5596 added on as another feature. 5598 As explained above, traffic across the ACP should still be end-to-end 5599 encrypted whenever possible. This includes traffic such as GRASP, 5600 EST and BRSKI inside the ACP. This minimizes man in the middle 5601 attacks by compromised ACP group members. Such attackers cannot 5602 eavesdrop or modify communications, they can just filter them (which 5603 is unavoidable by any means). 5605 See Appendix A.10.8 for further considerations how to avoid and deal 5606 with compromised nodes. 5608 10.3. The Administrator View 5610 An ACP is self-forming, self-managing and self-protecting, therefore 5611 has minimal dependencies on the administrator of the network. 5612 Specifically, since it is (intended to be) independent of 5613 configuration, there is only limited scope for configuration errors 5614 on the ACP itself. The administrator may have the option to enable 5615 or disable the entire approach, but detailed configuration is not 5616 possible. This means that the ACP must not be reflected in the 5617 running configuration of nodes, except a possible on/off switch (and 5618 even that is undesirable). 5620 While configuration (except for Section 8 and Section 9.2) is not 5621 possible, an administrator must have full visibility of the ACP and 5622 all its parameters, to be able to do trouble-shooting. Therefore, an 5623 ACP must support all show and debug options, as for any other network 5624 function. Specifically, a network management system or controller 5625 must be able to discover the ACP, and monitor its health. This 5626 visibility of ACP operations must clearly be separated from 5627 visibility of Data-Plane so automated systems will never have to deal 5628 with ACP aspects unless they explicitly desire to do so. 5630 Since an ACP is self-protecting, a node not supporting the ACP, or 5631 without a valid domain certificate cannot connect to it. This means 5632 that by default a traditional controller or network management system 5633 cannot connect to an ACP. See Section 8.1.1 for more details on how 5634 to connect an NMS host into the ACP. 5636 11. Security Considerations 5638 A set of ACP nodes with ACP certificates for the same ACP domain and 5639 with ACP functionaliy enabled is automatically "self-building": The 5640 ACP is automatically established between neighboring ACP nodes. It 5641 is also "self-protecting": The ACP secure channels are authenticated 5642 and encrypted. No configuration is required for this. 5644 The self-protecting property does not include workarounds for non- 5645 autonomic components as explained in Section 8. See Section 10.2 for 5646 details of how the ACP protects itself against attacks from the 5647 outside and to a more limited degree from the inside as well. 5649 However, the security of the ACP depends on a number of other 5650 factors: 5652 o The usage of domain certificates depends on a valid supporting PKI 5653 infrastructure. If the chain of trust of this PKI infrastructure 5654 is compromised, the security of the ACP is also compromised. This 5655 is typically under the control of the network administrator. 5657 o Every ACP registrar is criticial infrastructure that needs to be 5658 hardened against attacks, similar to a CA. A malicious registrar 5659 can enroll enemy plegdes to an ACP network or break ACP routing by 5660 duplicate ACP address assignment to pledges via their ACP 5661 certificates. 5663 o Security can be compromised by implementation errors (bugs), as in 5664 all products. 5666 There is no prevention of source-address spoofing inside the ACP. 5667 This implies that if an attacker gains access to the ACP, it can 5668 spoof all addresses inside the ACP and fake messages from any other 5669 node. New protocol/services run across the ACP should therefore use 5670 end-to-end authentication inside the ACP. This is already done by 5671 GRASP as specified in this document. 5673 The ACP is designed to enable automation of current network 5674 management and future autonomic peer-to-peer/distributed network 5675 automation. Any ACP member can send ACP IPv6 packet to other ACP 5676 members and announce via ACP GRASP services to all ACP members 5677 without depenency against centralized components. 5679 The ACP relies on peer-to-peer authentication and authorization using 5680 ACP certificates. This security model is necessary to enable the 5681 autonomic ad-hoc any-to-any connectivity between ACP nodes. It 5682 provides infrastructure protection through hop by hop authentication 5683 and encryption - without relying on third parties. For any services 5684 where this complete autonomic peer-to-peer group security model is 5685 appropriate, the ACP certificate can also be used unchanged. For 5686 example for any type of Data-Plane routing protocol security. 5688 This ACP security model is designed primarily to protect against 5689 attack from the outside, but not against attacks from the inside. To 5690 protect against spoofing attacks from compromised on-path ACP nodes, 5691 end-to-end encryption inside the ACP is used by new ACP signaling: 5692 GRASP across the ACP using TLS. The same is expected from any non- 5693 legacy services/protocols using the ACP. Because no group-keys are 5694 used, there is no risk for impacted nodes to access end-to-end 5695 encrypted traffic from other ACP nodes. 5697 Attacks from impacted ACP nodes against the ACP are more difficult 5698 than against the Data-Plane because of the autoconfiguration of the 5699 ACP and the absence of configuration options that could be abused 5700 that allow to change/break ACP behavior. This is excluding 5701 configuration for workaround in support of non-autonomic components. 5703 Mitigation against compromised ACP members is possible through 5704 standard automated certificate management mechanisms including 5705 revocation and non-renewal of short-lived certificates. In this 5706 version of the specification, there are no further optimization of 5707 these mechanisms defined for the ACP (but see Appendix A.10.8). 5709 Higher layer service built using ACP certificates should not solely 5710 rely on undifferentiated group security when another model is more 5711 appropriate/more secure. For example central network configuration 5712 relies on a security model where only few especially trusted nodes 5713 are allowed to configure the Data-Plane of network nodes (CLIL, 5714 Netconf). This can be done through ACP certificates by 5715 differentiating them and introduce roles. See Appendix A.10.5. 5717 Operators and provisioning software developers need to be aware of 5718 how the provisioning/configuration of network devices impacts the 5719 ability of the operator / provisioning software to remotely access 5720 the network nodes. By using the ACP, most of the issues of 5721 configuration/provisioning caused loss of connectivity for remote 5722 provisioning/configuration will be eliminated, see Section 6. Only 5723 few exceptions such as explicit physical interface down configuration 5724 will be left Section 9.3.2. 5726 Many details of ACP are designed with security in mind and discussed 5727 elsewhere in the document: 5729 IPv6 addresses used by nodes in the ACP are covered as part of the 5730 node's domain certificate as described in Section 6.1.2. This allows 5731 even verification of ownership of a peer's IPv6 address when using a 5732 connection authenticated with the domain certificate. 5734 The ACP acts as a security (and transport) substrate for GRASP inside 5735 the ACP such that GRASP is not only protected by attacks from the 5736 outside, but also by attacks from compromised inside attackers - by 5737 relying not only on hop-by-hop security of ACP secure channels, but 5738 adding end-to-end security for those GRASP messages. See 5739 Section 6.8.2. 5741 ACP provides for secure, resilient zero-touch discovery of EST 5742 servers for certificate renewal. See Section 6.1.5. 5744 ACP provides extensible, auto-configuring hop-by-hop protection of 5745 the ACP infrastructure via the negotiation of hop-by-hop secure 5746 channel protocols. See Section 6.5. 5748 The ACP is designed to minimize attacks from the outside by 5749 minimizing its dependency against any non-ACP (Data-Plane) 5750 operations/configuration on a node. See also Section 6.12.2. 5752 In combination with BRSKI, ACP enables a resilient, fully zero-touch 5753 network solution for short-lived certificates that can be renewed or 5754 re-enrolled even after unintentional expiry (e.g., because of 5755 interrupted connectivity). See Appendix A.2. 5757 Because ACP secure channels can be long lived, but certificates used 5758 may be short lived, secure channels, for example built via IPsec need 5759 to be terminated when peer certificates expire. See Section 6.7.5. 5761 The ACP is designed to minimize attacks from the outside by 5762 minimizing its dependency against any non-ACP (Data-Plane) 5763 operations/configuration on a node. See also Section 6.12.2. 5765 Section 7.2 describes how to implement a routed ACP topology 5766 operating on what effectively is a large bridge-domain when using L3/ 5767 L2 routers that operate at L2 in the Data-Plane. In this case, the 5768 ACP is subject to much higher likelyhood of attacks by other nodes 5769 "stealing" L2 addresses than in the actual routed case. Especially 5770 when the bridged network includes non-trusted devices such as hosts. 5771 This is a generic issue in L2 LANs. L2/L3 devices often already have 5772 some form of "port security" to prohibit this. They rely on NDP or 5773 DHCP learning of which port/MAC-address and IPv6 address belong 5774 together and block MAC/IPv6 source addresses from wrong ports. This 5775 type of function needs to be enabled to prohibit DoS attacks and 5776 specifically to protect the ACP. Likewise the GRASP DULL instance 5777 needs to ensure that the IPv6 address in the locator-option matches 5778 the source IPv6 address of the DULL GRASP packet. 5780 12. IANA Considerations 5782 This document defines the "Autonomic Control Plane". 5784 For the ANIMA-ACP-2020 ASN.1 module, IANA is asked to register value 5785 IANA1 for "id-mod-anima-acpnodename-2020" in the "SMI Security for 5786 PKIX Module Identifier" (1.3.6.1.5.5.7.0) registry. 5788 For the otherName / AcpNodeName, IANA is asked to register a value 5789 for IANA2 for id-on-AcpNodeName in the "SMI Security for PKIX Other 5790 Name Forms" (1.3.6.1.5.5.7.8) registry. 5792 The IANA is requested to register the value "AN_ACP" (without quotes) 5793 to the GRASP Objectives Names Table in the GRASP Parameter Registry. 5794 The specification for this value is this document, Section 6.3. 5796 The IANA is requested to register the value "SRV.est" (without 5797 quotes) to the GRASP Objectives Names Table in the GRASP Parameter 5798 Registry. The specification for this value is this document, 5799 Section 6.1.5. 5801 Explanation: This document chooses the initially strange looking 5802 format "SRV." because these objective names would be in 5803 line with potential future simplification of the GRASP objective 5804 registry. Today, every name in the GRASP objective registry needs to 5805 be explicitly allocated with IANA. In the future, this type of 5806 objective names could considered to be automatically registered in 5807 that registry for the same service for which is 5808 registered according to [RFC6335]. This explanation is solely 5809 informational and has no impact on the requested registration. 5811 The IANA is requested to create an ACP Parameter Registry with 5812 currently one registry table - the "ACP Address Type" table. 5814 "ACP Address Type" Table. The value in this table are numeric values 5815 0...3 paired with a name (string). Future values MUST be assigned 5816 using the Standards Action policy defined by [RFC8126]. The 5817 following initial values are assigned by this document: 5819 0: ACP Zone Addressing Sub-Scheme (ACP RFC Figure 11) / ACP Manual 5820 Addressing Sub-Scheme (ACP RFC Section 6.10.4) 5821 1: ACP Vlong Addressing Sub-Scheme (ACP RFC Section 6.10.5) 5823 13. Acknowledgements 5825 This work originated from an Autonomic Networking project at Cisco 5826 Systems, which started in early 2010. Many people contributed to 5827 this project and the idea of the Autonomic Control Plane, amongst 5828 which (in alphabetical order): Ignas Bagdonas, Parag Bhide, Balaji 5829 BL, Alex Clemm, Yves Hertoghs, Bruno Klauser, Max Pritikin, Michael 5830 Richardson, Ravi Kumar Vadapalli. 5832 Special thanks to Brian Carpenter, Elwyn Davies, Joel Halpern and 5833 Sheng Jiang for their thorough reviews and to Pascal Thubert and 5834 Michael Richardson to provide the details for the recommendations of 5835 the use of RPL in the ACP. 5837 Many thanks Ben Kaduk and Eric Rescorla for their thorough SEC AD 5838 reviews and to Valery Smyslov, Tero Kivinen, Paul Wouters and Yoav 5839 Nir for review of IPsec and IKEv2 parameters and helping to 5840 understand those and other security protocol details better. 5842 Further input, review or suggestions were received from: Rene Struik, 5843 Brian Carpenter, Benoit Claise, William Atwood and Yongkang Zhang. 5845 14. Change log [RFC Editor: Please remove] 5847 14.1. Summary of changes since entering IESG review 5849 This text replaces the prior changelog with a summary to provide 5850 guidance for further IESG review. 5852 Please see revision -21 for the individual changelogs of prior 5853 versions . 5855 14.1.1. Reviews (while in IESG review status) / status 5857 This document entered IESG review with version -13. It has since 5858 seen the following reviews: 5860 IESG: Original owner/Yes: Terry Manderson (INT). 5862 IESG: No Objection: Deborah Brungard (RTG), Alissa Cooper (GEN), 5863 Warren Kumari (OPS), Mirja Kuehlewind (TSV), Alexey Melnikov (ART), 5864 Adam Roach (ART). 5866 IESG: No Objection, not counted anymore as they have left IESG: Ben 5867 Campbell (ART), Spencer Dawkins (TSV). 5869 IESG: Open DISCUSS hopefully resolved by this version: Eric Rescorla 5870 (SEC, left IESG), Benjamin Kaduk (SEC). 5872 Other: Michael Richardson (WG), Brian Carpenter (WG), Pascal Thubert 5873 (WG), Frank Xialiang (WG), Elwyn Davies (GEN), Joel Halpern (RTGdir), 5874 Yongkang Zhang (WG), William Atwood (WG). 5876 14.1.2. BRSKI / ACP registrar related enhancements 5878 Only after ACP entered IESG review did it become clear that the in- 5879 progress BRSKI document would not provide all the explanations needed 5880 for ACP registrars as expected earlier by ACP authors. Instead, 5881 BRSKI will only specify a subset of required ACP behavior related to 5882 certificate handling and registrar. There, it became clear that the 5883 ACP draft should specify generic ACP registrar behavior independent 5884 of BRSKI so ACP could be implemented with or without BRSKI and any 5885 manual/proprietary or future standardized BRSKI alternatives (for 5886 example via NetConf) would understand the requirements for ACP 5887 registrars and its certificate handling. 5889 This lead to additional text about ACP registrars in the ACP 5890 document: 5892 1. Defined relationship ACP / ANI (ANI = ACP + BRSKI). 5894 6.1.4 (new) Overview of TA required for ACP. 5896 6.1.5.5 Added explanations/requirements for Re-enrolment. 5898 6.10.7 Normative requirements for ACP registrars (BRSKI or not). 5900 10.2 Operational expectations against ACP registrars (BRSKI or not). 5902 14.1.3. Normative enhancements since start of IESG review 5904 In addition to above ACP registrar / BRSKI related enhancements there 5905 is a range of minor normative (also explanatory) enhancements since 5906 the start of IESG review: 5908 6.1.1 Hex digits in ACP domain information field now upper-case (no 5909 specific reason except that both options are equally good, but 5910 capitalized ones are used in rfc5234). 5912 6.1.5.3 Added explanations about CRLs. 5914 6.1.5.6 Added explanations of behavior under failing certificates. 5916 6.1.2 Allow ACP adddress '0' in ACP domain information field: 5917 presence of address indicates permission to build ACP secure channel 5918 to node, 0 indicates that the address of the node is assigned by 5919 (future) other means than certificate. Non-autonomic nodes have no 5920 address at all (that was in -13), and can only connect via ACP 5921 connect interfaces to ACP. 5923 6.1.3 Distinction of real ACP nodes (with address) and those with 5924 domain certificate without address added as a new rule to ACP domain 5925 membership check. 5927 6.6 Added throttling of secure-channel setup attempts. 5929 6.11.1.14 Removed requirement to handle unknown destination ACP 5930 traffic in low-end nodes that would never be RPL roots. 5932 6.12.5 Added recommendation to use IPv6 DAD. 5934 6.1.1, 6.7.1.1, 6.7.2, 6.7.3, 6.8.2 Various refined additional 5935 certificate, secure channel protocol (IPsec/IKEv2 and DTLS) and ACP 5936 GRASP TLS protocol parameter requirements to ensure interoperating 5937 implementations (from SEC-AD review). 5939 14.1.4. Explanatory enhancements since start of IESG review 5941 Beyond the functional enhancements from the previous two sections, 5942 the mayority of changes since -13 are additional explanations from 5943 review feedback, textual nits and restructuring - with no functional 5944 requirement additions/changes. 5946 1.1 Added "applicability and scope" section with summarized 5947 explanations. 5949 2.Added in-band vs. out-of-band management definitions. 5951 6.1.2 (was 6.1.1) expanded explanations of reasoning for elements of 5952 the ACP domain information field. 5954 6.1.3 refined explanations of ACP domain membership check and 5955 justifications for it. 5957 6.5 Elaborated step-by-step secure channel setup. 5959 6.10 Additional explanations for addressing modes, additional table 5960 of addressing formats (thanks MichaelR). 5962 6.10.5 introduced 'F' bit position as a better visual representation 5963 in the Vlong address space. 5965 6.11.1.1 extensive overhaul to improve readability of use of RPL 5966 (from IESG feedback of non-routing/RPL experts). 5968 6.12.2 Added caution about unconfiguring Data-Plane IPv6 addresses 5969 and impact to ACP (limitation of current ACP design, and pointint to 5970 more details in 10.2). 5972 10.4 New explanations / summary of configurations for ACP (aka: all 5973 config is undesirable and only required for integrating with non- 5974 autonomic components, primarily ACP-connect and Registrars). 5976 11. Textually enhanced / better structured security considerations 5977 section after IESG security review. 5979 A. (new) Moved all explanations and discussions about futures from 5980 section 10 into this new appendix. This text should not be removed 5981 because it captures a lot of repeated asked questions in WG and 5982 during reviews and from users, and also captures ideas for some 5983 likely important followup work. But none of this is relevant to 5984 implementing (section 6) and operating (section 10) the ACP. 5986 14.2. draft-ietf-anima-autonomic-control-plane-28 5988 IESG review Roman Danyliw: 5990 6. Requested additional text elaborating misconfiguration plus 5991 attack vectors. 5993 6.1.3.1 Added paragraph about unsecured NTP as basis for time in the 5994 absence of other options. 5996 6.7.2 reworded text about additional secure channel protocol 5997 reqiurements. 5999 6.7.3.1.2. Added requirement for ACP nodes supporting IKEv2 to 6000 support RFC8247 (not sure how that got dropped from prior versions. 6002 Replaced minimum crypto requirements definition via specific AES 6003 options with more generic "symmetric key/hash strength" requirements. 6005 6.10.7.3. Added example how to derive addressing scheme from IDevID 6006 (PID). Added explanation how to deal with non-persistant registrar 6007 address database (hint: it sucks or is wasteful, what did you 6008 expect). 6010 8.1.1. Added explanation for 'Physical controlled/secured'. 6012 8.1.5. Removed 'Physical controlled/secured' text, refer back to 6013 8.1.1. 6015 8.2.1. Fixed ABNF 'or' syntax line. 6017 9.3.2. Added explanation of remote management problem with interface 6018 "down" type commands. 6020 10.2.1. Added explanations for attacks from impaired ACP nodes. 6022 11. Rewrote intro paragraph. Removed text referring to enrollment/ 6023 registrars as they are out of scope of ACP (dependencies only). 6025 11. Added note about need for new protocols inside ACP to use end- 6026 to-end authentication. 6028 11. Rewrote paragraph about operator mistakes so as to be 6029 actionably. Operators must not make mistakes - but ACP minimizes the 6030 mistakes they can make. 6032 ACP domain certificate -> ACP certificate. 6034 Various other cosmetic edits (thanks!) and typo fixes (sorry for not 6035 running full spell check for every version. Will definitely do 6036 before RFC editor). 6038 Other: 6040 6.12.5.2.1./6.12.5.2.2. Added text explaining link breakage wrt. 6041 RTL (came about re-analyzing behavior after question about hop 6042 count). 6044 Removed now unnecessary references for earlier rrc822Name otherName 6045 choice. 6047 14.3. draft-ietf-anima-autonomic-control-plane-27 6049 Too many revisions with too many fixes. Lets do a one-word change 6050 revision for a change now if it helps to accelerate the review 6051 process. 6053 Added "subjectAltName /" to make it unambiguous that AcpNodeName is 6054 indeed a SAN (from Russ). 6056 14.4. draft-ietf-anima-autonomic-control-plane-26 6058 Russ Housley review of -25. 6060 1.1 Explicit reference for TLS 1.2 RFC. 6062 2. Changed term of "ACP Domain Information" to AcpNodeName (ASN.1) / 6063 acp-node-name (ABNF), also through rest of document. 6065 2. Improved CA behavior definition. changed IDevID/LDevID to IDevID/ 6066 LDevID certificate to be more unambiguous. 6068 2. Changed definition of root CA to just refer to how its used in 6069 RFC7030 CA root key update, because thats the only thing relevant to 6070 ACP. 6072 6.1.1 Moved ECDH requirement to end of text as it was not related to 6073 the subject of the initial paragraps. Likewise reference to 6074 CABFORUM. 6076 6.1.1 Reduced cert key requirements to only be MUST for certs with 6077 2048 RSA public key and P-256 curves. Reduced longer keys to SHOULD. 6079 6.1.2 Changed text for conversion from rfc822Name to otherName / 6080 AcpNode, removed all the explanations of benefits coming with 6081 rfc822Name *sob* *sob* *sob*. 6083 6.1.2.1 New ASN.1 definition for otherName / AcpNodeName. 6085 6.1.3 Fixed up text. re the handling of missing connectivity for 6086 CRLDP / OCSP. 6088 6.1.4 Fixed up text re. inability to use public CA to situation with 6089 otherName / AcpNodeName (no more ACME rfc822Name validation for us 6090 *sob* *sob* *sob*). 6092 12. Added ASN.1 registration requests to IANA section. 6094 Appenices. Minor changes for rfc822Name to otherName change. 6096 Various minor verbal fixes/enhancements. 6098 14.5. draft-ietf-anima-autonomic-control-plane-25 6100 Crypto parameter discuss from Valery Smyslov and Paul Wouters and 6101 resulting changes. 6103 6.7.2 Moved Michael Richardson suggested diagnostic of signaling TA 6104 from IPsec section to this general requirements section and added 6105 explanation how this may be inappropriate if TA payload is considered 6106 secret by TA owner. 6108 6.7.3.1 Added traffic selectors for native IPsec. Improved text 6109 explanation. 6111 6.7.3.1.2 removed misleading text about signaling TA when using 6112 intermediate certs. 6114 6.7.3.1.2 Removed requirement for 'PKCS #7 wrapped X.509 certificate' 6115 requirement on request of Valery Smyslov as it is not defined in 6116 RFC7296 and there are enough options mandated in RFC7296. Replaced 6117 with just informative text to educate readers who are not IPsec 6118 experts what the mandatory option in RFC7296 is that allows to signal 6119 certificates. 6121 6.7.3.1.2 Added SHOULD requirement how to deal with CERTREQ so that 6122 6.7.2 requirement for TA diagnostics will work in IKEv2 (ignoring 6123 CERTREQ is permitted by IKEv2). Added explanation how this will 6124 result in TA cert diagnostics. 6126 6.7.3.1.2 Added requirement for IKEv2 to operate on link-local 6127 addresses for ACP so at to assume ACT cert as the only possible 6128 authenticator - to avoid potentialy failing section from multiple 6129 available certs on a router. 6131 6.7.3.1.2 fixed PKIX- style OID to ASN.1 object AlgorithmIdentifier 6132 (Paul). 6134 6.7.3.2 Added IPsec traffic selectors for IPsec with GRE. 6136 6.7.5 Added notion that IPsec/GRE MAY be preferred over IPsec/native. 6137 Luckily IPsec/native uses tunneling, whereas IPsec/GRE uses transport 6138 mode, and there is a long discuss whether it is permitted to even 6139 build IPsec connectings that only support transports instead of 6140 always being able to fall back to tunnel mode. Added explanatory 6141 paragraph why ACP nodes may prefer GRE over native (wonder how that 6142 was missing..). 6144 9.1.1 Added section to explain need for secure channel peer 6145 diagnostics via signaling of TA. Four examples given. 6147 Paul Wouters mentioned that ipkcs7 had to be used in some interop 6148 cases with windows CA, but that is an issue of ACP Registrar having 6149 to convert into PKCS#7 to talk to a windows CA, and this spec is not 6150 concerned with that, except to know that it is feasible, so not 6151 mentioned in text anywhere, just tracking discussion here in 6152 changelog. 6154 Michael Richardson: 6156 3.1.3 Added point in support of rfc822address that CA may not support 6157 to sign certificates with new attributes (such as new otherName). 6159 Michael Richardson/Brian Carpenter fix: 6161 6.1.5.1/6.3 Fixed GRASP examples. 6163 Joe Halpern review: 6165 1. Enhanded introduction text for in-band and of out-of-band, 6166 explaining how ACP is an in-band network aiming to achieve all 6167 possible benefits of an out-of-band network. 6169 1. Comprehensive explanation for term Data-Plane as it is only 6170 logically following pre-established terminology on a fully autonomic 6171 node, when used for existing nodes augmented with ACP, Data-Plane has 6172 more functionality than usually associated with the term. 6174 2. Removed explanatory text for Data-Plane, referring to section 1. 6176 2. Reduced explanation in definition of in-band (management/ 6177 signaling), out-of-band-signaling, now pointing to section 1. 6179 5. Rewrote a lot of the steps (overview) as this text was not 6180 reviewed for long time. Added references to normative section for 6181 each step to hopefully avoid feedback of not explaining terms used 6182 (really not possible to give good summary without using forward 6183 references). 6185 2. Separate out-of-band-management definition from virtual out-of- 6186 band-management definition (later one for ACP). 6188 2. Added definitions for RPI and RPL. 6190 6.1.1. added note about end-to-end authentication to distinguish 6191 channel security from overall ACP security model. 6193 6.5 Fixed bugs in channel selection signaling step description (Alice 6194 vs. Bob). 6196 6.7.1 Removed redundant channel selection explanation. 6198 6.10.3 remove locator/identifier terminology from zone addressing 6199 scheme description (unnecessary), removed explanations (now in 9.4), 6200 simplified text, clarified requirement for Node-ID to be unique, 6201 recommend to use primarily zone 0. 6203 6.10.3.1 Removed. Included a lot of insufficient suggestions for 6204 future stanards extensions, most of it was wrong or would need to be 6205 revisited by WG anyhow. Idea now (just here for comment): Announce 6206 via GRASP Zone-ID (e.g.: from per-zone edge-node/registrar) into a 6207 zone of the ACP so all nodes supporting the scheme can automatically 6208 self-allocate the Zone-ID. 6210 6.11.1.1 (RPL overview), eliminated redundant text. 6212 6.11.1.1.1 New subsection to better structure overview. 6214 6.11.1.1.2 New subsection to better group overview, replaced TTL 6215 explanation (just the symptom) with hopefully better reconvergence 6216 text (intent of the profile) for the ACP RPL profile. 6218 6.11.1.1.6 Added text to explain simple choice for rank_factor. 6220 6.11.1.13 moved explanation for RPI up into 6.11.1.1. 6222 6.12.5.1 rewrote section for ACP Loopback Interface. 6224 9.4 New informative/informational section for partial or incremental 6225 adoption of ACP to help understand why there is the Zone interface 6226 sub-scheme, and how to use it. 6228 Unrelated fixes: 6230 Ask to RFC editor to add most important abbreviations to RFC editor 6231 abbreviation list. 6233 6.10.2 changed names in ACP addressing scheme table to be less 6234 suggestive of use. 6236 Russ Hously review: 6238 2. Fixed definition of "Enrollment", "Trust Anchor", "CA", and "root 6239 CA". Changed "Certificate Authority" to "Certification Authority" 6240 throughout the document (correct term according to X.509). 6242 6.1 Fixed explanation of mutual ACP trust. 6244 6.1.1 s/X509/X509v3/. 6246 6.1.2 created bulleted lists for explanations and justifications for 6247 choices of ACP certificate encoding. No semantic changes, just to 6248 make it easier to refer to the points in discussions (rfcdiff seems 6249 to have a bug showing text differences due to formatting changes). 6251 6.1.3 Moved content of rule #1 into previous rule #2 because 6252 certification chain validation does imply validation of lifetime. 6253 numbers of all rules reduced by 1, changed hopefully all references 6254 to the rule numbers in the document. 6256 Rule #3, Hopefully fixed linguistic problem self-contradiction of 6257 MUST by lower casing MUST in the explanation part and rewriting the 6258 condition when this is not applicable. 6260 6.1.4 Replaced redundant term "Trust Point" (TP) with Trust Anchor 6261 (TA"). Replaced throughout document Trust Anchor with abbreviation 6262 TA. 6264 Enhanced several sentences/rewrote paragraphs to make explanations 6265 clearer. 6267 6.6 Added explanation how ACP nodes must throttle their attempts for 6268 connection making purely on the result of their own connection 6269 attempts, not based on those connections where they are responder. 6271 14.6. draft-ietf-anima-autonomic-control-plane-24 6273 Leftover from -23 review by Eric Vyncke: 6275 Swapping sections 9 and 10, section 9 was meant to be at end of 6276 document and summarize. Its not meant to be misinterpreted as 6277 introducing any new information. This did happen because section 10 6278 was added after section 9. 6280 14.7. draft-ietf-anima-autonomic-control-plane-23 6282 Note: big rfcdiff of TOC is an rfcdiff bug, changes really minimal. 6284 Review of IPsec security with Mcr and ipsec mailing list. 6286 6.7.1 - new section: Moved general considerations for secure channel 6287 protocols here, refined them. 6289 6.7.2 - new section: Moved common requirements for secure channel 6290 protocols here, refined them. 6292 6.7.3.1.1. - improved requirements text related to RFC8221, better 6293 explamations re. HW acceleration issues. 6295 6.7.3.1.2. - improved requirements text related to RFC8247, (some 6296 requirements still discussed to be redundant, will be finalized in 6297 next weeks. 6299 Eric Vyncke review of -21: 6301 Only noting most important changes, long list of smaller text/ 6302 readability enhancements. 6304 2. - New explanation of "normative" , "informational" section title 6305 tags. alphabetic reordering of terms, refined definitions for CA, 6306 CRL. root CA. 6308 6.1.1. - explanation when IDevID parameters may be copied into 6309 LDevID. 6311 6.1.2. - Fixed hex digits in ACP domain information to lower case. 6313 6.1.3.1. - New section on Realtime clock and Time Validation. 6315 6.3 - Added explanation that DTLS means >= version 1.2 (not only 6316 1.2). 6318 6.7 - New text in this main section explaing relationship of ACP 6319 secure channels and ACP virtual interfaces - with forward references 6320 to virtual interface section. 6322 6.8.2 - reordered text and picture, no text change. 6324 6.10.7.2 - describe first how Registrar-ID can be allocted for all 6325 type of registrars, then refined text for how to potentially use MAC 6326 addresses on physical registrars. 6328 6.11.1.1 - Added text how this profile does not use Data-Plane 6329 artefacts (RPI) because hadware forwarding. This was previously 6330 hidden only later in the text. 6332 6.11.1.13. - Rewrote RPL Data-Plane artefact text. Provide decoder 6333 ring for abbreviations and all relevant RFCs. 6335 6.12.5.2. - Added more explicit text that secure channels are mapped 6336 into virtual interfaces, moved different type of interfaces used by 6337 ACP into seperate subsections to be able to refer to them. 6339 7.2 - Rewrote/refined text for ACP on L2, prior text was confusing 6340 and did not well explain why ACP for L2/L3 switches can be 6341 implemented without any L2 (HW) changes. Also missing explanation of 6342 only running GRASP untagged when VLANs are used. 6344 8.1.1 - Added requirement for ACP Edge nodes to allow configurable 6345 filtering of IPv6 RPI headers. 6347 11. - (security section). Moved explanation of address stealing from 6348 7.2 to here. 6350 14.8. draft-ietf-anima-autonomic-control-plane-22 6352 Ben Kaduk review of -21: 6354 RFC822 encoding of ACP domain information: 6356 6.1.2 rewrote text for explaining / justifying use of rfc822name as 6357 identifier for node CP in certificate (was discussed in thread, but 6358 badly written in prior versions). 6360 6.1.2 Changed EBNF syntax to use "+" after rfcSELF because that is 6361 the known primary name to extensions separator in many email systems 6362 ("." was wrong in prior versions). 6364 6.1.2 Rewrote/improved explanations for use of rfc822name field to 6365 explain better why it is PKIX compliant and the right thing to do. 6367 Crypto parameters for IPsec: 6369 6.1 - Added explanation of why manual keying for ACP is not feasible 6370 for ACP. Surprisingly, that text did not exist. Referred to by 6371 IPsec text (6.7.1), but here is the right place to describe the 6372 reasoning. 6374 6.1.2 - Small textual refinement referring to requirements to 6375 authenticate peers (for the special cases of empty or '0' ACP address 6376 in ACP domain information field. 6378 6.3 - To better justify Bens proposed change of secure channel 6379 protocol being IPsec vs. GRASP objective being IKEv2, better 6380 explained how protocol indicated in GRASP objective-value is name of 6381 protocol used to negotiate secure channel, use example of IKEv2 to 6382 negotiate IPsec. 6384 6.7.1 - refinemenet similar to 6.3. 6386 - moved new paragraph from Bens pull request up from 6.7.1.1 to 6.7.1 6387 as it equally applies to GRE encapped IPsec (looks nicer one level 6388 up). 6390 - created subsections 6.7.1.1 (IPsec/ESP) / 6.7.1.2 (IKEv2) to 6391 clearer distinguish between these two requirements blocks. 6393 - Refined the text in these two sections to hopefully be a good 6394 answer to Valery's concern of not randomnly mocking with existing 6395 requirements docs (rfc8247 / rfc8221). 6397 6.7.1.1.1 - IPsec/ESP requirements section: 6399 - MUST support rfc8221 mandatory EXCEPT for the superceeding 6400 requirements in this section. Previously, this was not quite clear 6401 from the text. 6403 - Hopefully persuasive explanations about the requirements levels for 6404 ENCR_AES_GCM_16, ENCR_AES_CBC, ENCR_AES_CCM_8 and 6405 ENCR_CHACHA20_POLY1305: Restructured text for why not ENCR_AES_CBC 6406 (was in prior version, just not well structured), added new 6407 expanations for ENCR_AES_CCM_8 and ENCR_CHACHA20_POLY130. 6409 - In simple terms, requirements for ENCR_AES_CBC, ENCR_AES_CCM_8, 6410 ENCR_CHACHACHA are SHOULD when they are implementable with rqual or 6411 faster performancce than ENCR_AES_GCM_16. 6413 - Removed text about "additional rfc8221" reqiurements MAY be used. 6414 Now the logic is that all other requirements apply. Hopefully we 6415 have written enough so that we prohibited downgrades. 6417 6.7.1.1.2 - RFC8247 requirements: 6419 - Added mandate to support rfc8247, added explanation that there is 6420 no "stripping down" requirement, just additional stronger 6421 requirements to mandate correct use of ACP certificartes during 6422 authentication. 6424 - refined text on identifying ACP by IPv6 address to be clearer: 6425 Identifying in the context of IKEv2 and cases for '0' in ACP domain 6426 information. 6428 - removed last two paragraphs about relationship to rfc8247, as his 6429 is now written in first paragraph of the section. 6431 End of Ben Kaduk review related fixes. 6433 Other: 6435 Forgot to update example of ACP domain information to use capitalized 6436 hex-digits as required by HEXLC used. 6438 Added reference to RFC8316 (AN use-cases) to beginning of section 3 6439 (ACP use cases). 6441 Small Enhanced IPsec parameters description / requirements fixes 6442 (from Michael Richardson). 6444 15. References 6446 15.1. Normative References 6448 [I-D.ietf-anima-bootstrapping-keyinfra] 6449 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 6450 and K. Watsen, "Bootstrapping Remote Secure Key 6451 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 6452 keyinfra-41 (work in progress), April 2020. 6454 [I-D.ietf-anima-grasp] 6455 Bormann, C., Carpenter, B., and B. Liu, "A Generic 6456 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 6457 grasp-15 (work in progress), July 2017. 6459 [IKEV2IANA] 6460 IANA, "Internet Key Exchange Version 2 (IKEv2) 6461 Parameters", . 6464 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 6465 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 6466 . 6468 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 6469 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 6470 DOI 10.17487/RFC3810, June 2004, 6471 . 6473 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 6474 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 6475 November 2005, . 6477 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 6478 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 6479 . 6481 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 6482 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 6483 2006, . 6485 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 6486 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 6487 December 2005, . 6489 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 6490 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 6491 DOI 10.17487/RFC4861, September 2007, 6492 . 6494 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 6495 Address Autoconfiguration", RFC 4862, 6496 DOI 10.17487/RFC4862, September 2007, 6497 . 6499 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 6500 Specifications: ABNF", STD 68, RFC 5234, 6501 DOI 10.17487/RFC5234, January 2008, 6502 . 6504 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 6505 (TLS) Protocol Version 1.2", RFC 5246, 6506 DOI 10.17487/RFC5246, August 2008, 6507 . 6509 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 6510 Housley, R., and W. Polk, "Internet X.509 Public Key 6511 Infrastructure Certificate and Certificate Revocation List 6512 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 6513 . 6515 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 6516 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 6517 January 2012, . 6519 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 6520 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 6521 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 6522 Low-Power and Lossy Networks", RFC 6550, 6523 DOI 10.17487/RFC6550, March 2012, 6524 . 6526 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 6527 and D. Barthel, "Routing Metrics Used for Path Calculation 6528 in Low-Power and Lossy Networks", RFC 6551, 6529 DOI 10.17487/RFC6551, March 2012, 6530 . 6532 [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing 6533 Protocol for Low-Power and Lossy Networks (RPL)", 6534 RFC 6552, DOI 10.17487/RFC6552, March 2012, 6535 . 6537 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 6538 Power and Lossy Networks (RPL) Option for Carrying RPL 6539 Information in Data-Plane Datagrams", RFC 6553, 6540 DOI 10.17487/RFC6553, March 2012, 6541 . 6543 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 6544 "Enrollment over Secure Transport", RFC 7030, 6545 DOI 10.17487/RFC7030, October 2013, 6546 . 6548 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 6549 Kivinen, "Internet Key Exchange Protocol Version 2 6550 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 6551 2014, . 6553 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 6554 "Recommendations for Secure Use of Transport Layer 6555 Security (TLS) and Datagram Transport Layer Security 6556 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 6557 2015, . 6559 [RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support 6560 for Generic Routing Encapsulation (GRE)", RFC 7676, 6561 DOI 10.17487/RFC7676, October 2015, 6562 . 6564 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 6565 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 6566 May 2017, . 6568 [RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T. 6569 Kivinen, "Cryptographic Algorithm Implementation 6570 Requirements and Usage Guidance for Encapsulating Security 6571 Payload (ESP) and Authentication Header (AH)", RFC 8221, 6572 DOI 10.17487/RFC8221, October 2017, 6573 . 6575 [RFC8247] Nir, Y., Kivinen, T., Wouters, P., and D. Migault, 6576 "Algorithm Implementation Requirements and Usage Guidance 6577 for the Internet Key Exchange Protocol Version 2 (IKEv2)", 6578 RFC 8247, DOI 10.17487/RFC8247, September 2017, 6579 . 6581 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 6582 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 6583 . 6585 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 6586 Definition Language (CDDL): A Notational Convention to 6587 Express Concise Binary Object Representation (CBOR) and 6588 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 6589 June 2019, . 6591 15.2. Informative References 6593 [AR8021] Group, W. -. H. L. L. P. W., "IEEE Standard for Local and 6594 metropolitan area networks - Secure Device Identity", 6595 December 2009, . 6598 [CABFORUM] 6599 CA/Browser Forum, "Certificate Contents for Baseline SSL", 6600 Nov 2019, . 6603 [I-D.eckert-anima-noc-autoconfig] 6604 Eckert, T., "Autoconfiguration of NOC services in ACP 6605 networks via GRASP", draft-eckert-anima-noc-autoconfig-00 6606 (work in progress), July 2018. 6608 [I-D.ietf-acme-star] 6609 Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T. 6610 Fossati, "Support for Short-Term, Automatically-Renewed 6611 (STAR) Certificates in Automated Certificate Management 6612 Environment (ACME)", draft-ietf-acme-star-11 (work in 6613 progress), October 2019. 6615 [I-D.ietf-anima-prefix-management] 6616 Jiang, S., Du, Z., Carpenter, B., and Q. Sun, "Autonomic 6617 IPv6 Edge Prefix Management in Large-scale Networks", 6618 draft-ietf-anima-prefix-management-07 (work in progress), 6619 December 2017. 6621 [I-D.ietf-anima-reference-model] 6622 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 6623 and J. Nobre, "A Reference Model for Autonomic 6624 Networking", draft-ietf-anima-reference-model-10 (work in 6625 progress), November 2018. 6627 [I-D.ietf-roll-applicability-template] 6628 Richardson, M., "ROLL Applicability Statement Template", 6629 draft-ietf-roll-applicability-template-09 (work in 6630 progress), May 2016. 6632 [I-D.ietf-tls-dtls13] 6633 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 6634 Datagram Transport Layer Security (DTLS) Protocol Version 6635 1.3", draft-ietf-tls-dtls13-38 (work in progress), May 6636 2020. 6638 [IEEE-1588-2008] 6639 IEEE, "IEEE Standard for a Precision Clock Synchronization 6640 Protocol for Networked Measurement and Control Systems", 6641 December 2008, . 6644 [IEEE-802.1X] 6645 Group, W. -. H. L. L. P. W., "IEEE Standard for Local and 6646 Metropolitan Area Networks: Port-Based Network Access 6647 Control", February 2010, 6648 . 6651 [LLDP] Group, W. -. H. L. L. P. W., "IEEE Standard for Local and 6652 Metropolitan Area Networks: Station and Media Access 6653 Control Connectivity Discovery", June 2016, 6654 . 6657 [MACSEC] Group, W. -. H. L. L. P. W., "IEEE Standard for Local and 6658 Metropolitan Area Networks: Media Access Control (MAC) 6659 Security", June 2006, 6660 . 6663 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 6664 RFC 1112, DOI 10.17487/RFC1112, August 1989, 6665 . 6667 [RFC1492] Finseth, C., "An Access Control Protocol, Sometimes Called 6668 TACACS", RFC 1492, DOI 10.17487/RFC1492, July 1993, 6669 . 6671 [RFC1654] Rekhter, Y., Ed. and T. Li, Ed., "A Border Gateway 6672 Protocol 4 (BGP-4)", RFC 1654, DOI 10.17487/RFC1654, July 6673 1994, . 6675 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 6676 and E. Lear, "Address Allocation for Private Internets", 6677 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 6678 . 6680 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 6681 Requirement Levels", BCP 14, RFC 2119, 6682 DOI 10.17487/RFC2119, March 1997, 6683 . 6685 [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax 6686 Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998, 6687 . 6689 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 6690 (IKE)", RFC 2409, DOI 10.17487/RFC2409, November 1998, 6691 . 6693 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 6694 "Remote Authentication Dial In User Service (RADIUS)", 6695 RFC 2865, DOI 10.17487/RFC2865, June 2000, 6696 . 6698 [RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, 6699 DOI 10.17487/RFC3164, August 2001, 6700 . 6702 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 6703 C., and M. Carney, "Dynamic Host Configuration Protocol 6704 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 6705 2003, . 6707 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 6708 Architecture for Describing Simple Network Management 6709 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 6710 DOI 10.17487/RFC3411, December 2002, 6711 . 6713 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 6714 "DNS Extensions to Support IP Version 6", STD 88, 6715 RFC 3596, DOI 10.17487/RFC3596, October 2003, 6716 . 6718 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 6719 Protocol (XMPP): Core", RFC 3920, DOI 10.17487/RFC3920, 6720 October 2004, . 6722 [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export 6723 Version 9", RFC 3954, DOI 10.17487/RFC3954, October 2004, 6724 . 6726 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 6727 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 6728 DOI 10.17487/RFC4007, March 2005, 6729 . 6731 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 6732 "Internet X.509 Public Key Infrastructure Certificate 6733 Management Protocol (CMP)", RFC 4210, 6734 DOI 10.17487/RFC4210, September 2005, 6735 . 6737 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 6738 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 6739 2006, . 6741 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 6742 for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, 6743 . 6745 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 6746 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 6747 for Transport Layer Security (TLS)", RFC 4492, 6748 DOI 10.17487/RFC4492, May 2006, 6749 . 6751 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 6752 "Considerations for Internet Group Management Protocol 6753 (IGMP) and Multicast Listener Discovery (MLD) Snooping 6754 Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, 6755 . 6757 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 6758 Group Management Protocol Version 3 (IGMPv3) and Multicast 6759 Listener Discovery Protocol Version 2 (MLDv2) for Source- 6760 Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, 6761 August 2006, . 6763 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 6764 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 6765 . 6767 [RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol 6768 Independent Multicast (PIM)", RFC 4610, 6769 DOI 10.17487/RFC4610, August 2006, 6770 . 6772 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 6773 Extensions for Stateless Address Autoconfiguration in 6774 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 6775 . 6777 [RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure 6778 Subject Alternative Name for Expression of Service Name", 6779 RFC 4985, DOI 10.17487/RFC4985, August 2007, 6780 . 6782 [RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet 6783 Group Management Protocol Version 3 (IGMPv3) and Multicast 6784 Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, 6785 DOI 10.17487/RFC5790, February 2010, 6786 . 6788 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 6789 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 6790 . 6792 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 6793 "Network Time Protocol Version 4: Protocol and Algorithms 6794 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 6795 . 6797 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 6798 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 6799 DOI 10.17487/RFC5912, June 2010, 6800 . 6802 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 6803 and A. Bierman, Ed., "Network Configuration Protocol 6804 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 6805 . 6807 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 6808 Cheshire, "Internet Assigned Numbers Authority (IANA) 6809 Procedures for the Management of the Service Name and 6810 Transport Protocol Port Number Registry", BCP 165, 6811 RFC 6335, DOI 10.17487/RFC6335, August 2011, 6812 . 6814 [RFC6402] Schaad, J., "Certificate Management over CMS (CMC) 6815 Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011, 6816 . 6818 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 6819 of Interpretation", RFC 6407, DOI 10.17487/RFC6407, 6820 October 2011, . 6822 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 6823 Routing Header for Source Routes with the Routing Protocol 6824 for Low-Power and Lossy Networks (RPL)", RFC 6554, 6825 DOI 10.17487/RFC6554, March 2012, 6826 . 6828 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 6829 "Default Address Selection for Internet Protocol Version 6 6830 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 6831 . 6833 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 6834 Ed., "Diameter Base Protocol", RFC 6733, 6835 DOI 10.17487/RFC6733, October 2012, 6836 . 6838 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 6839 DOI 10.17487/RFC6762, February 2013, 6840 . 6842 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 6843 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 6844 . 6846 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 6847 "TCP Extensions for Multipath Operation with Multiple 6848 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 6849 . 6851 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 6852 Locator/ID Separation Protocol (LISP)", RFC 6830, 6853 DOI 10.17487/RFC6830, January 2013, 6854 . 6856 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 6857 "Specification of the IP Flow Information Export (IPFIX) 6858 Protocol for the Exchange of Flow Information", STD 77, 6859 RFC 7011, DOI 10.17487/RFC7011, September 2013, 6860 . 6862 [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local 6863 Addressing inside an IPv6 Network", RFC 7404, 6864 DOI 10.17487/RFC7404, November 2014, 6865 . 6867 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 6868 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 6869 Defined Networking (SDN): Layers and Architecture 6870 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 6871 2015, . 6873 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 6874 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 6875 Networking: Definitions and Design Goals", RFC 7575, 6876 DOI 10.17487/RFC7575, June 2015, 6877 . 6879 [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap 6880 Analysis for Autonomic Networking", RFC 7576, 6881 DOI 10.17487/RFC7576, June 2015, 6882 . 6884 [RFC7585] Winter, S. and M. McCauley, "Dynamic Peer Discovery for 6885 RADIUS/TLS and RADIUS/DTLS Based on the Network Access 6886 Identifier (NAI)", RFC 7585, DOI 10.17487/RFC7585, October 6887 2015, . 6889 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 6890 Considerations for IPv6 Address Generation Mechanisms", 6891 RFC 7721, DOI 10.17487/RFC7721, March 2016, 6892 . 6894 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 6895 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 6896 Multicast - Sparse Mode (PIM-SM): Protocol Specification 6897 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 6898 2016, . 6900 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 6901 RFC 7950, DOI 10.17487/RFC7950, August 2016, 6902 . 6904 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 6905 Hosts in a Multi-Prefix Network", RFC 8028, 6906 DOI 10.17487/RFC8028, November 2016, 6907 . 6909 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 6910 Writing an IANA Considerations Section in RFCs", BCP 26, 6911 RFC 8126, DOI 10.17487/RFC8126, June 2017, 6912 . 6914 [RFC8316] Nobre, J., Granville, L., Clemm, A., and A. Gonzalez 6915 Prieto, "Autonomic Networking Use Case for Distributed 6916 Detection of Service Level Agreement (SLA) Violations", 6917 RFC 8316, DOI 10.17487/RFC8316, February 2018, 6918 . 6920 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 6921 "A Voucher Artifact for Bootstrapping Protocols", 6922 RFC 8366, DOI 10.17487/RFC8366, May 2018, 6923 . 6925 [RFC8368] Eckert, T., Ed. and M. Behringer, "Using an Autonomic 6926 Control Plane for Stable Connectivity of Network 6927 Operations, Administration, and Maintenance (OAM)", 6928 RFC 8368, DOI 10.17487/RFC8368, May 2018, 6929 . 6931 [RFC8398] Melnikov, A., Ed. and W. Chuang, Ed., "Internationalized 6932 Email Addresses in X.509 Certificates", RFC 8398, 6933 DOI 10.17487/RFC8398, May 2018, 6934 . 6936 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 6937 Decraene, B., Litkowski, S., and R. Shakir, "Segment 6938 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 6939 July 2018, . 6941 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 6942 Touch Provisioning (SZTP)", RFC 8572, 6943 DOI 10.17487/RFC8572, April 2019, 6944 . 6946 [X.509] International Telecommunication Union, "Information 6947 technology - Open Systems Interconnection - The Directory: 6948 Public-key and attribute certificate frameworks", ITU-T 6949 Recommendation X.509, ISO/IEC 9594-8, October 2016, 6950 . 6952 15.3. URIs 6954 [1] https://en.wikipedia.org/wiki/Operational_Technology 6956 [2] https://en.wikipedia.org/wiki/Single-root_input/ 6957 output_virtualization 6959 Appendix A. Background and Futures (Informative) 6961 The following sections discuss additional background information 6962 about aspects of the normative parts of this document or associated 6963 mechanisms such as BRSKI (such as why specific choices were made by 6964 the ACP) and they provide discussion about possible future variations 6965 of the ACP. 6967 A.1. ACP Address Space Schemes 6969 This document defines the Zone, Vlong and Manual sub address schemes 6970 primarily to support address prefix assignment via distributed, 6971 potentially uncoordinated ACP registrars as defined in 6972 Section 6.10.7. This costs 48/46-bit identifier so that these ACP 6973 registrar can assign non-conflicting address prefixes. This design 6974 does not leave enough bits to simultaneously support a large number 6975 of nodes (Node-ID) plus a large prefix of local addresses for every 6976 node plus a large enough set of bits to identify a routing Zone. In 6977 result, Zone, Vlong 8/16 attempt to support all features, but in via 6978 separate prefixes. 6980 In networks that always expect to rely on a centralized PMS as 6981 described above (Section 9.2.5), the 48/46-bits for the Registrar-ID 6982 could be saved. Such variations of the ACP addressing mechanisms 6983 could be introduced through future work in different ways. If a new 6984 otherName was introduced, incompatible ACP variations could be 6985 created where every design aspect of the ACP could be changed. 6986 Including all addressing choices. If instead a new addressing sub- 6987 type would be defined, it could be a backward compatible extension of 6988 this ACP specification. Information such as the size of a zone- 6989 prefix and the length of the prefix assigned to the ACP node itself 6990 could be encoded via the extension field of the acp-node-name. 6992 Note that an explicitly defined "Manual" addressing sub-scheme is 6993 always beneficial to provide an easy way for ACP nodes to prohibit 6994 incorrect manual configuration of any non-"Manual" ACP address spaces 6995 and therefore ensure that "Manual" operations will never impact 6996 correct routing for any non-"Manual" ACP addresses assigned via ACP 6997 certificates. 6999 A.2. BRSKI Bootstrap (ANI) 7001 BRSKI describes how nodes with an IDevID certificate can securely and 7002 zero-touch enroll with an LDevID certificate to support the ACP. 7003 BRSKI also leverages the ACP to enable zero-touch bootstrap of new 7004 nodes across networks without any configuration requirements across 7005 the transit nodes (e.g., no DHCP/DNS forwarding/server setup). This 7006 includes otherwise not configured networks as described in 7007 Section 3.2. Therefore BRSKI in conjunction with ACP provides for a 7008 secure and zero-touch management solution for complete networks. 7009 Nodes supporting such an infrastructure (BRSKI and ACP) are called 7010 ANI nodes (Autonomic Networking Infrastructure), see 7011 [I-D.ietf-anima-reference-model]. Nodes that do not support an 7012 IDevID certiificate but only an (insecure) vendor specific Unique 7013 Device Identifier (UDI) or nodes whose manufacturer does not support 7014 a MASA could use some future security reduced version of BRSKI. 7016 When BRSKI is used to provision a domain certificate (which is called 7017 enrollment), the BRSKI registrar (acting as an enhanced EST server) 7018 must include the otherName / AcpNode encoded ACP address and domain 7019 name to the enrolling node (called pledge) via its response to the 7020 pledges EST CSR Attribute request that is mandatory in BRSKI. 7022 The Certification Authority in an ACP network must not change the 7023 otherName / AcpNode in the certificate. The ACP nodes can therefore 7024 find their ACP address and domain using this field in the domain 7025 certificate, both for themselves, as well as for other nodes. 7027 The use of BRSKI in conjunction with the ACP can also help to further 7028 simplify maintenance and renewal of domain certificates. Instead of 7029 relying on CRL, the lifetime of certificates can be made extremely 7030 small, for example in the order of hours. When a node fails to 7031 connect to the ACP within its certificate lifetime, it cannot connect 7032 to the ACP to renew its certificate across it (using just EST), but 7033 it can still renew its certificate as an "enrolled/expired pledge" 7034 via the BRSKI bootstrap proxy. This requires only that the BRSKI 7035 registrar honors expired domain certificates and that the pledge 7036 attempts to perform TLS authentication for BRSKI bootstrap using its 7037 expired domain certificate before falling back to attempting to use 7038 its IDevID certificate for BRSKI. This mechanism could also render 7039 CRLs unnecessary because the BRSKI registrar in conjunction with the 7040 CA would not renew revoked certificates - only a "Do-not-renew" list 7041 would be necessary on BRSKI registrars/CA. 7043 In the absence of BRSKI or less secure variants thereof, provisioning 7044 of certificates may involve one or more touches or non-standardized 7045 automation. Node vendors usually support provisioning of 7046 certificates into nodes via PKCS#7 (see [RFC2315]) and may support 7047 this provisioning through vendor specific models via Netconf 7048 ([RFC6241]). If such nodes also support Netconf Zero-Touch 7049 ([RFC8572]) then this can be combined to zero-touch provisioning of 7050 domain certificates into nodes. Unless there are equivalent 7051 integration of Netconf connections across the ACP as there is in 7052 BRSKI, this combination would not support zero-touch bootstrap across 7053 a not configured network though. 7055 A.3. ACP Neighbor discovery protocol selection 7057 This section discusses why GRASP DULL was chosen as the discovery 7058 protocol for L2 adjacent candidate ACP neighbors. The contenders 7059 considered where GRASP, mDNS or LLDP. 7061 A.3.1. LLDP 7063 LLDP and Cisco's earlier Cisco Discovery Protocol (CDP) are example 7064 of L2 discovery protocols that terminate their messages on L2 ports. 7065 If those protocols would be chosen for ACP neighbor discovery, ACP 7066 neighbor discovery would therefore also terminate on L2 ports. This 7067 would prevent ACP construction over non-ACP capable but LLDP or CDP 7068 enabled L2 switches. LLDP has extensions using different MAC 7069 addresses and this could have been an option for ACP discovery as 7070 well, but the additional required IEEE standardization and definition 7071 of a profile for such a modified instance of LLDP seemed to be more 7072 work than the benefit of "reusing the existing protocol" LLDP for 7073 this very simple purpose. 7075 A.3.2. mDNS and L2 support 7077 Multicast DNNS (mDNS) [RFC6762] with DNS Service Discovery (DNS-SD) 7078 Resource Records (RRs) as defined in [RFC6763] is a key contender as 7079 an ACP discovery protocol. because it relies on link-local IP 7080 multicast, it does operates at the subnet level, and is also found in 7081 L2 switches. The authors of this document are not aware of mDNS 7082 implementation that terminate their mDNS messages on L2 ports instead 7083 of the subnet level. If mDNS was used as the ACP discovery mechanism 7084 on an ACP capable (L3)/L2 switch as outlined in Section 7, then this 7085 would be necessary to implement. It is likely that termination of 7086 mDNS messages could only be applied to all mDNS messages from such a 7087 port, which would then make it necessary to software forward any non- 7088 ACP related mDNS messages to maintain prior non-ACP mDNS 7089 functionality. Adding support for ACP into such L2 switches with 7090 mDNS could therefore create regression problems for prior mDNS 7091 functionality on those nodes. With low performance of software 7092 forwarding in many L2 switches, this could also make the ACP risky to 7093 support on such L2 switches. 7095 A.3.3. Why DULL GRASP 7097 LLDP was not considered because of the above mentioned issues. mDNS 7098 was not selected because of the above L2 mDNS considerations and 7099 because of the following additional points: 7101 If mDNS was not already existing in a node, it would be more work to 7102 implement than DULL GRASP, and if an existing implementation of mDNS 7103 was used, it would likely be more code space than a separate 7104 implementation of DULL GRASP or a shared implementation of DULL GRASP 7105 and GRASP in the ACP. 7107 A.4. Choice of routing protocol (RPL) 7109 This section motivates why RPL - "IPv6 Routing Protocol for Low-Power 7110 and Lossy Networks ([RFC6550] was chosen as the default (and in this 7111 specification only) routing protocol for the ACP. The choice and 7112 above explained profile was derived from a pre-standard 7113 implementation of ACP that was successfully deployed in operational 7114 networks. 7116 Requirements for routing in the ACP are: 7118 o Self-management: The ACP must build automatically, without human 7119 intervention. Therefore routing protocol must also work 7120 completely automatically. RPL is a simple, self-managing 7121 protocol, which does not require zones or areas; it is also self- 7122 configuring, since configuration is carried as part of the 7123 protocol (see Section 6.7.6 of [RFC6550]). 7125 o Scale: The ACP builds over an entire domain, which could be a 7126 large enterprise or service provider network. The routing 7127 protocol must therefore support domains of 100,000 nodes or more, 7128 ideally without the need for zoning or separation into areas. RPL 7129 has this scale property. This is based on extensive use of 7130 default routing. 7132 o Low resource consumption: The ACP supports traditional network 7133 infrastructure, thus runs in addition to traditional protocols. 7134 The ACP, and specifically the routing protocol must have low 7135 resource consumption both in terms of memory and CPU requirements. 7136 Specifically, at edge nodes, where memory and CPU are scarce, 7137 consumption should be minimal. RPL builds a DODAG, where the main 7138 resource consumption is at the root of the DODAG. The closer to 7139 the edge of the network, the less state needs to be maintained. 7140 This adapts nicely to the typical network design. Also, all 7141 changes below a common parent node are kept below that parent 7142 node. 7144 o Support for unstructured address space: In the Autonomic 7145 Networking Infrastructure, node addresses are identifiers, and may 7146 not be assigned in a topological way. Also, nodes may move 7147 topologically, without changing their address. Therefore, the 7148 routing protocol must support completely unstructured address 7149 space. RPL is specifically made for mobile ad-hoc networks, with 7150 no assumptions on topologically aligned addressing. 7152 o Modularity: To keep the initial implementation small, yet allow 7153 later for more complex methods, it is highly desirable that the 7154 routing protocol has a simple base functionality, but can import 7155 new functional modules if needed. RPL has this property with the 7156 concept of "objective function", which is a plugin to modify 7157 routing behavior. 7159 o Extensibility: Since the Autonomic Networking Infrastructure is a 7160 new concept, it is likely that changes in the way of operation 7161 will happen over time. RPL allows for new objective functions to 7162 be introduced later, which allow changes to the way the routing 7163 protocol creates the DAGs. 7165 o Multi-topology support: It may become necessary in the future to 7166 support more than one DODAG for different purposes, using 7167 different objective functions. RPL allow for the creation of 7168 several parallel DODAGs, should this be required. This could be 7169 used to create different topologies to reach different roots. 7171 o No need for path optimization: RPL does not necessarily compute 7172 the optimal path between any two nodes. However, the ACP does not 7173 require this today, since it carries mainly non-delay-sensitive 7174 feedback loops. It is possible that different optimization 7175 schemes become necessary in the future, but RPL can be expanded 7176 (see point "Extensibility" above). 7178 A.5. ACP Information Distribution and multicast 7180 IP multicast is not used by the ACP because the ANI (Autonomic 7181 Networking Infrastructure) itself does not require IP multicast but 7182 only service announcement/discovery. Using IP multicast for that 7183 would have made it necessary to develop a zero-touch auto configuring 7184 solution for ASM (Any Source Multicast - the original form of IP 7185 multicast defined in [RFC1112]), which would be quite complex and 7186 difficult to justify. One aspect of complexity where no attempt at a 7187 solution has been described in IETF documents is the automatic- 7188 selection of routers that should be PIM Sparse Mode (PIM-SM) 7189 Rendezvous Points (RPs) (see [RFC7761]). The other aspects of 7190 complexity are the implementation of MLD ([RFC4604]), PIM-SM and 7191 Anycast-RP (see [RFC4610]). If those implementations already exist 7192 in a product, then they would be very likely tied to accelerated 7193 forwarding which consumes hardware resources, and that in return is 7194 difficult to justify as a cost of performing only service discovery. 7196 Some future ASA may need high performance in-network data 7197 replication. That is the case when the use of IP multicast is 7198 justified. Such an ASA can then use service discovery from ACP 7199 GRASP, and then they do not need ASM but only SSM (Source Specific 7200 Multicast, see [RFC4607]) for the IP multicast replication. SSM 7201 itself can simply be enabled in the Data-Plane (or even in an update 7202 to the ACP) without any other configuration than just enabling it on 7203 all nodes and only requires a simpler version of MLD (see [RFC5790]). 7205 LSP (Link State Protocol) based IGP routing protocols typically have 7206 a mechanism to flood information, and such a mechanism could be used 7207 to flood GRASP objectives by defining them to be information of that 7208 IGP. This would be a possible optimization in future variations of 7209 the ACP that do use an LSP routing protocol. Note though that such a 7210 mechanism would not work easily for GRASP M_DISCOVERY messages which 7211 are intelligently (constrained) flooded not across the whole ACP, but 7212 only up to a node where a responder is found. We do expect that many 7213 future services in ASA will have only few consuming ASA, and for 7214 those cases, M_DISCOVERY is the more efficient method than flooding 7215 across the whole domain. 7217 Because the ACP uses RPL, one desirable future extension is to use 7218 RPLs existing notion of DODAG, which are loop-free distribution 7219 trees, to make GRASP flooding more efficient both for M_FLOOD and 7220 M_DISCOVERY. See Section 6.12.5 how this will be specifically 7221 beneficial when using NBMA interfaces. This is not currently 7222 specified in this document because it is not quite clear yet what 7223 exactly the implications are to make GRASP flooding depend on RPL 7224 DODAG convergence and how difficult it would be to let GRASP flooding 7225 access the DODAG information. 7227 A.6. Extending ACP channel negotiation (via GRASP) 7229 [RFC Editor: This section to be removed before RFC. 7231 [This section kept for informational purposes up until the last draft 7232 version as that would be the version that readers interested in the 7233 changelog would also go to to revisit it.] 7235 The mechanism described in the normative part of this document to 7236 support multiple different ACP secure channel protocols without a 7237 single network wide MTI protocol is important to allow extending 7238 secure ACP channel protocols beyond what is specified in this 7239 document, but it will run into problem if it would be used for 7240 multiple protocols: 7242 The need to potentially have multiple of these security associations 7243 even temporarily run in parallel to determine which of them works 7244 best does not support the most lightweight implementation options. 7246 The simple policy of letting one side (Alice) decide what is best may 7247 not lead to the mutual best result. 7249 The two limitations can easier be solved if the solution was more 7250 modular and as few as possible initial secure channel negotiation 7251 protocols would be used, and these protocols would then take on the 7252 responsibility to support more flexible objectives to negotiate the 7253 mutually preferred ACP security channel protocol. 7255 IKEv2 is the IETF standard protocol to negotiate network security 7256 associations. It is meant to be extensible, but it is unclear 7257 whether it would be feasible to extend IKEv2 to support possible 7258 future requirements for ACP secure channel negotiation: 7260 Consider the simple case where the use of native IPsec vs. IPsec via 7261 GRE is to be negotiated and the objective is the maximum throughput. 7262 Both sides would indicate some agreed upon performance metric and the 7263 preferred encapsulation is the one with the higher performance of the 7264 slower side. IKEv2 does not support negotiation with such 7265 objectives. 7267 Consider DTLS and some form of MacSec are to be added as negotiation 7268 options - and the performance objective should work across all IPsec, 7269 DTLS and MacSec options. In the case of MacSEC, the negotiation 7270 would also need to determine a key for the peering. It is unclear if 7271 it would be even appropriate to consider extending the scope of 7272 negotiation in IKEv2 to those cases. Even if feasible to define, it 7273 is unclear if implementations of IKEv2 would be eager to adopt those 7274 type of extension given the long cycles of security testing that 7275 necessarily goes along with core security protocols such as IKEv2 7276 implementations. 7278 A more modular alternative to extending IKEv2 could be to layer a 7279 modular negotiation mechanism on top of the multitude of existing or 7280 possible future secure channel protocols. For this, GRASP over TLS 7281 could be considered as a first ACP secure channel negotiation 7282 protocol. The following are initial considerations for such an 7283 approach. A full specification is subject to a separate document: 7285 To explicitly allow negotiation of the ACP channel protocol, GRASP 7286 over a TLS connection using the GRASP_LISTEN_PORT and the node's and 7287 peer's link-local IPv6 address is used. When Alice and Bob support 7288 GRASP negotiation, they do prefer it over any other non-explicitly 7289 negotiated security association protocol and should wait trying any 7290 non-negotiated ACP channel protocol until after it is clear that 7291 GRASP/TLS will not work to the peer. 7293 When Alice and Bob successfully establish the GRASP/TSL session, they 7294 will negotiate the channel mechanism to use using objectives such as 7295 performance and perceived quality of the security. After agreeing on 7296 a channel mechanism, Alice and Bob start the selected Channel 7297 protocol. Once the secure channel protocol is successfully running, 7298 the GRASP/TLS connection can be kept alive or timed out as long as 7299 the selected channel protocol has a secure association between Alice 7300 and Bob. When it terminates, it needs to be re-negotiated via GRASP/ 7301 TLS. 7303 Notes: 7305 o Negotiation of a channel type may require IANA assignments of code 7306 points. 7308 o TLS is subject to reset attacks, which IKEv2 is not. Normally, 7309 ACP connections (as specified in this document) will be over link- 7310 local addresses so the attack surface for this one issue in TCP 7311 should be reduced (note that this may not be true when ACP is 7312 tunneled as described in Section 8.2.2. 7314 o GRASP packets received inside a TLS connection established for 7315 GRASP/TLS ACP negotiation are assigned to a separate GRASP domain 7316 unique to that TLS connection. 7318 A.7. CAs, domains and routing subdomains 7320 There is a wide range of setting up different ACP solution by 7321 appropriately using CAs and the domain and rsub elements in the acp- 7322 node-name in the domain certificate. We summarize these options here 7323 as they have been explained in different parts of the document in 7324 before and discuss possible and desirable extensions: 7326 An ACP domain is the set of all ACP nodes that can authenticate each 7327 other as belonging to the same ACP network using the ACP domain 7328 membership check (Section 6.1.3). GRASP inside the ACP is run across 7329 all transitively connected ACP nodes in a domain. 7331 The rsub element in the acp-node-name permits the use of addresses 7332 from different ULA prefixes. One use case is to create multiple 7333 physical networks that initially may be separated with one ACP domain 7334 but different routing subdomains, so that all nodes can mutual trust 7335 their ACP certificates (not depending on rsub) and so that they could 7336 connect later together into a contiguous ACP network. 7338 One instance of such a use case is an ACP for regions interconnected 7339 via a non-ACP enabled core, for example due to the absence of product 7340 support for ACP on the core nodes. ACP connect configurations as 7341 defined in this document can be used to extend and interconnect those 7342 ACP islands to the NOC and merge them into a single ACP when later 7343 that product support gap is closed. 7345 Note that RPL scales very well. It is not necessary to use multiple 7346 routing subdomains to scale ACP domains in a way it would be possible 7347 if other routing protocols where used. They exist only as options 7348 for the above mentioned reasons. 7350 If different ACP domains are to be created that should not allow to 7351 connect to each other by default, these ACP domains simply need to 7352 have different domain elements in the acp-node-name. These domain 7353 elements can be arbitrary, including subdomains of one another: 7354 Domains "example.com" and "research.example.com" are separate domains 7355 if both are domain elements in the acp-node-name of certificates. 7357 It is not necessary to have a separate CA for different ACP domains: 7358 an operator can use a single CA to sign certificates for multiple ACP 7359 domains that are not allowed to connect to each other because the 7360 checks for ACP adjacencies includes comparison of the domain part. 7362 If multiple independent networks choose the same domain name but had 7363 their own CA, these would not form a single ACP domain because of CA 7364 mismatch. Therefore there is no problem in choosing domain names 7365 that are potentially also used by others. Nevertheless it is highly 7366 recommended to use domain names that one can have high probability to 7367 be unique. It is recommended to use domain names that start with a 7368 DNS domain names owned by the assigning organization and unique 7369 within it. For example "acp.example.com" if you own "example.com". 7371 A.8. Intent for the ACP 7373 Intent is the architecture component of autonomic networks according 7374 to [I-D.ietf-anima-reference-model] that allows operators to issue 7375 policies to the network. Its applicability for use is quite flexible 7376 and freeform, with potential applications including policies flooded 7377 across ACP GRASP and interpreted on every ACP node. 7379 One concern for future definitions of Intent solutions is the problem 7380 of circular dependencies when expressing Intent policies about the 7381 ACP itself. 7383 For example, Intent could indicate the desire to build an ACP across 7384 all domains that have a common parent domain (without relying on the 7385 rsub/routing-subdomain solution defined in this document). For 7386 example ACP nodes with domain "example.com", "access.example.com", 7387 "core.example.com" and "city.core.example.com" should all establish 7388 one single ACP. 7390 If each domain has its own source of Intent, then the Intent would 7391 simply have to allow adding the peer domains TA and domain names to 7392 the parameters for the ACP domain membership check (Section 6.1.3) so 7393 that nodes from those other domains are accepted as ACP peers. 7395 If this Intent was to be originated only from one domain, it could 7396 likely not be made to work because the other domains will not build 7397 any ACP connection amongst each other, whether they use the same or 7398 different CA due to the ACP domain membership check. 7400 If the domains use the same CA one could change the ACP setup to 7401 permit for the ACP to be established between two ACP nodes with 7402 different acp-domain-names, but only for the purpose of disseminating 7403 limited information, such as Intent, but not to set up full ACP 7404 connectivity, specifically not RPL routing and passing of arbitrary 7405 GRASP information. Unless the Intent policies permit this to happen 7406 across domain boundaries. 7408 This type of approach where the ACP first allows Intent to operate 7409 and only then sets up the rest of ACP connectivity based on Intent 7410 policy could also be used to enable Intent policies that would limit 7411 functionality across the ACP inside a domain, as long as no policy 7412 would disturb the distribution of Intent. For example to limit 7413 reachability across the ACP to certain type of nodes or locations of 7414 nodes. 7416 A.9. Adopting ACP concepts for other environments 7418 The ACP as specified in this document is very explicit about the 7419 choice of options to allow interoperable implementations. The 7420 choices made may not be the best for all environments, but the 7421 concepts used by the ACP can be used to build derived solutions: 7423 The ACP specifies the use of ULA and deriving its prefix from the 7424 domain name so that no address allocation is required to deploy the 7425 ACP. The ACP will equally work not using ULA but any other /48 IPv6 7426 prefix. This prefix could simply be a configuration of the ACP 7427 registrars (for example when using BRSKI) to enroll the domain 7428 certificates - instead of the ACP registrar deriving the /48 ULA 7429 prefix from the AN domain name. 7431 Some solutions may already have an auto-addressing scheme, for 7432 example derived from existing unique device identifiers (e.g., MAC 7433 addresses). In those cases it may not be desirable to assign 7434 addresses to devices via the ACP address information field in the way 7435 described in this document. The certificate may simply serve to 7436 identify the ACP domain, and the address field could be empty/unused. 7437 The only fix required in the remaining way the ACP operate is to 7438 define another element in the domain certificate for the two peers to 7439 decide who is Alice and who is Bob during secure channel building. 7441 Note though that future work may leverage the acp address to 7442 authenticate "ownership" of the address by the device. If the 7443 address used by a device is derived from some pre-existing permanent 7444 local ID (such as MAC address), then it would be useful to store that 7445 address in the certificate using the format of the access address 7446 information field or in a similar way. 7448 The ACP is defined as a separate VRF because it intends to support 7449 well managed networks with a wide variety of configurations. 7450 Therefore, reliable, configuration-indestructible connectivity cannot 7451 be achieved from the Data-Plane itself. In solutions where all 7452 transit connectivity impacting functions are fully automated 7453 (including security), indestructible and resilient, it would be 7454 possible to eliminate the need for the ACP to be a separate VRF. 7455 Consider the most simple example system in which there is no separate 7456 Data-Plane, but the ACP is the Data-Plane. Add BRSKI, and it becomes 7457 a fully autonomic network - except that it does not support automatic 7458 addressing for user equipment. This gap can then be closed for 7459 example by adding a solution derived from 7460 [I-D.ietf-anima-prefix-management]. 7462 TCP/TLS as the protocols to provide reliability and security to GRASP 7463 in the ACP may not be the preferred choice in constrained networks. 7464 For example, CoAP/DTLS (Constrained Application Protocol) may be 7465 preferred where they are already used, allowing to reduce the 7466 additional code space footprint for the ACP on those devices. Hop- 7467 by-hop reliability for ACP GRASP messages could be made to support 7468 protocols like DTLS by adding the same type of negotiation as defined 7469 in this document for ACP secure channel protocol negotiation. End- 7470 to-end GRASP connections can be made to select their transport 7471 protocol in future extensions of the ACP meant to better support 7472 constrained devices by indicating the supported transport protocols 7473 (e.g.: TLS/DTLS) via GRASP parameters of the GRASP objective through 7474 which the transport endpoint is discovered. 7476 The routing protocol RPL used for the ACP does explicitly not 7477 optimize for shortest paths and fastest convergence. Variations of 7478 the ACP may want to use a different routing protocol or introduce 7479 more advanced RPL profiles. 7481 Variations such as what routing protocol to use, or whether to 7482 instantiate an ACP in a VRF or (as suggested above) as the actual 7483 Data-Plane, can be automatically chosen in implementations built to 7484 support multiple options by deriving them from future parameters in 7485 the certificate. Parameters in certificates should be limited to 7486 those that would not need to be changed more often than certificates 7487 would need to be updated anyhow; Or by ensuring that these parameters 7488 can be provisioned before the variation of an ACP is activated in a 7489 node. Using BRSKI, this could be done for example as additional 7490 follow-up signaling directly after the certificate enrollment, still 7491 leveraging the BRSKI TLS connection and therefore not introducing any 7492 additional connectivity requirements. 7494 Last but not least, secure channel protocols including their 7495 encapsulations are easily added to ACP solutions. ACP hop-by-hop 7496 network layer secure channels could also be replaced by end-to-end 7497 security plus other means for infrastructure protection. Any future 7498 network OAM should always use end-to-end security anyhow and can 7499 leverage the domain certificates and is therefore not dependent on 7500 security to be provided for by ACP secure channels. 7502 A.10. Further (future) options 7504 A.10.1. Auto-aggregation of routes 7506 Routing in the ACP according to this specification only leverages the 7507 standard RPL mechanism of route optimization, e.g. keeping only 7508 routes that are not towards the RPL root. This is known to scale to 7509 networks with 20,000 or more nodes. There is no auto-aggregation of 7510 routes for /48 ULA prefixes (when using rsub in the acp-node-name) 7511 and/or Zone-ID based prefixes. 7513 Automatic assignment of Zone-ID and auto-aggregation of routes could 7514 be achieved for example by configuring zone-boundaries, announcing 7515 via GRASP into the zones the zone parameters (zone-ID and /48 ULA 7516 prefix) and auto-aggegating routes on the zone-boundaries. Nodes 7517 would assign their Zone-ID and potentially even /48 prefix based on 7518 the GRASP announcements. 7520 A.10.2. More options for avoiding IPv6 Data-Plane dependency 7522 As described in Section 6.12.2, the ACP depends on the Data-Plane to 7523 establish IPv6 link-local addressing on interfaces. Using a separate 7524 MAC address for the ACP allows to fully isolate the ACP from the 7525 Data-Plane in a way that is compatible with this specification. It 7526 is also an ideal option when using Single-root input/output 7527 virtualization (SR-IOV - see https://en.wikipedia.org/wiki/Single- 7528 root_input/output_virtualization [2]) in an implementation to isolate 7529 the ACP because different SR-IOV interfaces use different MAC 7530 addresses. 7532 When additional MAC address(es) are not available, separation of the 7533 ACP could be done at different demux points. The same subnet 7534 interface could have a separate IPv6 interface for the ACP and Data- 7535 Plane and therefore separate link-local addresses for both, where the 7536 ACP interface is non-configurable on the Data-Plane. This too would 7537 be compatible with this specification and not impact 7538 interoperability. 7540 An option that would require additional specification is to use a 7541 different Ethertype from 0x86DD (IPv6) to encapsulate IPv6 packets 7542 for the ACP. This would be a similar approach as used for IP 7543 authentication packets in [IEEE-802.1X] which use the Extensible 7544 Authentication Protocol over Local Area Network (EAPoL) ethertype 7545 (0x88A2). 7547 Note that in the case of ANI nodes, all the above considerations 7548 equally apply to the encapsulation of BRSKI packets including GRASP 7549 used for BRSKI. 7551 A.10.3. ACP APIs and operational models (YANG) 7553 Future work should define YANG ([RFC7950]) data model and/or node 7554 internal APIs to monitor and manage the ACP. 7556 Support for the ACP Adjacency Table (Section 6.2) and ACP GRASP need 7557 to be included into such model/API. 7559 A.10.4. RPL enhancements 7561 ..... USA ...... ..... Europe ...... 7563 NOC1 NOC2 7564 | | 7565 | metric 100 | 7566 ACP1 --------------------------- ACP2 . 7567 | | . WAN 7568 | metric 10 metric 20 | . Core 7569 | | . 7570 ACP3 --------------------------- ACP4 . 7571 | metric 100 | 7572 | | . 7573 | | . Sites 7574 ACP10 ACP11 . 7576 Figure 18: Dual NOC 7578 The profile for RPL specified in this document builds only one 7579 spanning-tree path set to a root, typically a registrar in one NOC. 7580 In the presence of multiple NOCs, routing toward the non-root NOCs 7581 may be suboptimal. Figure 18 shows an extreme example. Assuming 7582 that node ACP1 becomes the RPL root, traffic between ACP11 and NOC2 7583 will pass through ACP4-ACP3-ACP1-ACP2 instead of ACP4-ACP2 because 7584 the RPL calculated DODAG/routes are shortest paths towards the RPL 7585 root. 7587 To overcome these limitations, extensions/modifications to the RPL 7588 profile can provide optimality for multiple NOCs. This requires 7589 utilizing Data-Plane artifact including IPinIP encap/decap on ACP 7590 routers and processing of IPv6 RPI headers. Alternatively, (Src,Dst) 7591 routing table entries could be used. 7593 Flooding of ACP GRASP messages can be further constrained and 7594 therefore optimized by flooding only via links that are part of the 7595 RPL DODAG. 7597 A.10.5. Role assignments 7599 ACP connect is an explicit mechanism to "leak" ACP traffic explicitly 7600 (for example in a NOC). It is therefore also a possible security gap 7601 when it is easy to enable ACP connect on arbitrary compromised ACP 7602 nodes. 7604 One simple solution is to define an extension in the ACP certificates 7605 ACP information field indicating the permission for ACP connect to be 7606 configured on that ACP node. This could similarly be done to decide 7607 whether a node is permitted to be a registrar or not. 7609 Tying the permitted "roles" of an ACP node to the ACP certificate 7610 provides fairly strong protection against misconfiguration, but is 7611 still subject to code modifications. 7613 Another interesting role to assign to certificates is that of a NOC 7614 node. This would allow to limit certain type of connections such as 7615 OAM TLS connections to only NOC initiator or responders. 7617 A.10.6. Autonomic L3 transit 7619 In this specification, the ACP can only establish autonomic 7620 connectivity across L2 hops and only explicitly configured options to 7621 tunnel across L3. Future work should specify mechanisms to 7622 automatically tunnel ACP across L3 networks. A hub&spoke option 7623 would allow to tunnel across the Internet to a cloud or central 7624 instance of the ACP, a peer-to-peer tunneling mechanism could tunnel 7625 ACP islands across an L3VPN infrastructure. 7627 A.10.7. Diagnostics 7629 Section 9.1 describes diagnostics options that can be done without 7630 changing the external, interoperability affecting characteristics of 7631 ACP implementations. 7633 Even better diagnostics of ACP operations is possible with additional 7634 signaling extensions, such as: 7636 1. Consider if LLDP should be a recommended functionality for ANI 7637 devices to improve diagnostics, and if so, which information 7638 elements it should signal (noting that such information is 7639 conveyed in an insecure manner). Includes potentially new 7640 information elements. 7642 2. In alternative to LLDP, A DULL GRASP diagnostics objective could 7643 be defined to carry these information elements. 7645 3. The IDevID certificate of BRSKI pledges should be included in the 7646 selected insecure diagnostics option. This may be undesirable 7647 when exposure of device information is seen as too much of a 7648 security issue (ability to deduce possible attack vectors from 7649 device model for example). 7651 4. A richer set of diagnostics information should be made available 7652 via the secured ACP channels, using either single-hop GRASP or 7653 network wide "topology discovery" mechanisms. 7655 A.10.8. Avoiding and dealing with compromised ACP nodes 7657 Compromised ACP nodes pose the biggest risk to the operations of the 7658 network. The most common type of compromise is leakage of 7659 credentials to manage/configure the device and the application of 7660 malicious configuration including the change of access credentials, 7661 but not the change of software. Most of todays networking equipment 7662 should have secure boot/software infrastructure anyhow, so attacks 7663 that introduce malicious software should be a lot harder. 7665 The most important aspect of security design against these type of 7666 attacks is to eliminate password based configuration access methods 7667 and instead rely on certificate based credentials handed out only to 7668 nodes where it is clear that the private keys can not leak. This 7669 limits unexpected propagation of credentials. 7671 If password based credentials to configure devices still need to be 7672 supported, they must not be locally configurable, but only be 7673 remotely provisioned or verified (through protocols like Radius or 7674 Diameter), and there must be no local configuration permitting to 7675 change these authentication mechanisms, but ideally they should be 7676 autoconfiguring across the ACP. See 7677 [I-D.eckert-anima-noc-autoconfig]. 7679 Without physical access to the compromised device, attackers with 7680 access to configuration should not be able to break the ACP 7681 connectivity, even when they can break or otherwise manipulate 7682 (spoof) the Data-Plane connectivity through configuration. To 7683 achieve this, it is necessary to avoid providing configuration 7684 options for the ACP, such as enabling/disabling it on interfaces. 7685 For example there could be an ACP configuration that locks down the 7686 current ACP config unless factory reseet is done. 7688 With such means, the valid administration has the best chances to 7689 maintain access to ACP nodes, discover malicious configuration though 7690 ongoing configuration tracking from central locations for example, 7691 and to react accordingly. 7693 The primary reaction is withdrawal/change of credentials, terminate 7694 malicious existing management sessions and fixing the configuration. 7695 Ensuring that management sessions using invalidated credentials are 7696 terminated automatically without recourse will likely require new 7697 work. 7699 Only when these steps are not feasible would it be necessary to 7700 revoke or expire the ACP certificate credentials and consider the 7701 node kicked off the network - until the situation can be further 7702 rectified, likely requiring direct physical access to the node. 7704 Without extensions, compromised ACP nodes can only be removed from 7705 the ACP at the speed of CRL/OCSP information refresh or expiry (and 7706 non-removal) of short lived certificates. Future extensions to the 7707 ACP could for example use GRASP flooding distribution of triggered 7708 updates of CRL/OCSP or explicit removal indication of the compromised 7709 nodes domain certificate. 7711 Authors' Addresses 7713 Toerless Eckert (editor) 7714 Futurewei Technologies Inc. USA 7715 2330 Central Expy 7716 Santa Clara 95050 7717 USA 7719 Email: tte+ietf@cs.fau.de 7720 Michael H. Behringer (editor) 7722 Email: michael.h.behringer@gmail.com 7724 Steinthor Bjarnason 7725 Arbor Networks 7726 2727 South State Street, Suite 200 7727 Ann Arbor MI 48104 7728 United States 7730 Email: sbjarnason@arbor.net