idnits 2.17.1 draft-ietf-anima-autonomic-control-plane-26.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 20 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 1198 has weird spacing: '...address of f...' == Line 2678 has weird spacing: '...k-local unic...' == Line 2679 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 1, 2020) is 1389 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 483, but not defined -- Looks like a reference, but probably isn't: '1' on line 6807 -- Looks like a reference, but probably isn't: '2' on line 7380 -- Looks like a reference, but probably isn't: '3' on line 2095 -- Looks like a reference, but probably isn't: '5' on line 2101 -- Looks like a reference, but probably isn't: '9' on line 2112 -- Looks like a reference, but probably isn't: '13' on line 2130 == Missing Reference: 'ACP VRF' is mentioned on line 4048, but not defined == Missing Reference: 'Data-Plane' is mentioned on line 4050, but not defined == Missing Reference: 'Select' is mentioned on line 4210, but not defined == Missing Reference: 'Plane' is mentioned on line 4212, but not defined == Unused Reference: 'RFC1034' is defined on line 6299, but no explicit reference was found in the text == Unused Reference: 'RFC5321' is defined on line 6350, but no explicit reference was found in the text == Unused Reference: 'RFC5322' is defined on line 6354, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-applicability-template' is defined on line 6470, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-useofrplinfo' is defined on line 6475, but no explicit reference was found in the text == Unused Reference: 'RFC2821' is defined on line 6542, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IKEV2IANA' ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-41 == Outdated reference: A later version (-44) exists of draft-ietf-roll-useofrplinfo-39 == 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 2821 (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 3164 (Obsoleted by RFC 5424) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 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 (~~), 21 warnings (==), 18 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 2, 2021 6 S. Bjarnason 7 Arbor Networks 8 July 1, 2020 10 An Autonomic Control Plane (ACP) 11 draft-ietf-anima-autonomic-control-plane-26 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 2, 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) . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . 22 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) . . . . . . . . . . . . . . . . . 32 78 6.1.5. Certificate and Trust Anchor Maintenance . . . . . . 33 79 6.1.5.1. GRASP objective for EST server . . . . . . . . . 34 80 6.1.5.2. Renewal . . . . . . . . . . . . . . . . . . . . . 35 81 6.1.5.3. Certificate Revocation Lists (CRLs) . . . . . . . 36 82 6.1.5.4. Lifetimes . . . . . . . . . . . . . . . . . . . . 36 83 6.1.5.5. Re-enrollment . . . . . . . . . . . . . . . . . . 37 84 6.1.5.6. Failing Certificates . . . . . . . . . . . . . . 38 85 6.2. ACP Adjacency Table . . . . . . . . . . . . . . . . . . . 39 86 6.3. Neighbor Discovery with DULL GRASP . . . . . . . . . . . 39 87 6.4. Candidate ACP Neighbor Selection . . . . . . . . . . . . 43 88 6.5. Channel Selection . . . . . . . . . . . . . . . . . . . . 43 89 6.6. Candidate ACP Neighbor verification . . . . . . . . . . . 47 90 6.7. Security Association (Secure Channel) protocols . . . . . 47 91 6.7.1. General considerations . . . . . . . . . . . . . . . 48 92 6.7.2. Common requirements . . . . . . . . . . . . . . . . . 48 93 6.7.3. ACP via IPsec . . . . . . . . . . . . . . . . . . . . 50 94 6.7.3.1. Native IPsec . . . . . . . . . . . . . . . . . . 50 95 6.7.3.1.1. RFC8221 (IPsec/ESP) . . . . . . . . . . . . . 50 96 6.7.3.1.2. RFC8247 (IKEv2) . . . . . . . . . . . . . . . 52 98 6.7.3.2. IPsec with GRE encapsulation . . . . . . . . . . 53 99 6.7.4. ACP via DTLS . . . . . . . . . . . . . . . . . . . . 54 100 6.7.5. ACP Secure Channel Profiles . . . . . . . . . . . . . 55 101 6.8. GRASP in the ACP . . . . . . . . . . . . . . . . . . . . 56 102 6.8.1. GRASP as a core service of the ACP . . . . . . . . . 56 103 6.8.2. ACP as the Security and Transport substrate for GRASP 57 104 6.8.2.1. Discussion . . . . . . . . . . . . . . . . . . . 60 105 6.9. Context Separation . . . . . . . . . . . . . . . . . . . 61 106 6.10. Addressing inside the ACP . . . . . . . . . . . . . . . . 61 107 6.10.1. Fundamental Concepts of Autonomic Addressing . . . . 61 108 6.10.2. The ACP Addressing Base Scheme . . . . . . . . . . . 63 109 6.10.3. ACP Zone Addressing Sub-Scheme (ACP-Zone) . . . . . 64 110 6.10.4. ACP Manual Addressing Sub-Scheme (ACP-Manual) . . . 66 111 6.10.5. ACP Vlong Addressing Sub-Scheme (ACP-VLong-8/ACP- 112 VLong-16 . . . . . . . . . . . . . . . . . . . . . . 67 113 6.10.6. Other ACP Addressing Sub-Schemes . . . . . . . . . . 68 114 6.10.7. ACP Registrars . . . . . . . . . . . . . . . . . . . 69 115 6.10.7.1. Use of BRSKI or other Mechanism/Protocols . . . 69 116 6.10.7.2. Unique Address/Prefix allocation . . . . . . . . 70 117 6.10.7.3. Addressing Sub-Scheme Policies . . . . . . . . . 71 118 6.10.7.4. Address/Prefix Persistence . . . . . . . . . . . 72 119 6.10.7.5. Further Details . . . . . . . . . . . . . . . . 72 120 6.11. Routing in the ACP . . . . . . . . . . . . . . . . . . . 72 121 6.11.1. ACP RPL Profile . . . . . . . . . . . . . . . . . . 73 122 6.11.1.1. Overview . . . . . . . . . . . . . . . . . . . . 73 123 6.11.1.1.1. Single Instance . . . . . . . . . . . . . . 73 124 6.11.1.1.2. Reconvergence . . . . . . . . . . . . . . . 74 125 6.11.1.2. RPL Instances . . . . . . . . . . . . . . . . . 74 126 6.11.1.3. Storing vs. Non-Storing Mode . . . . . . . . . . 74 127 6.11.1.4. DAO Policy . . . . . . . . . . . . . . . . . . . 75 128 6.11.1.5. Path Metric . . . . . . . . . . . . . . . . . . 75 129 6.11.1.6. Objective Function . . . . . . . . . . . . . . . 75 130 6.11.1.7. DODAG Repair . . . . . . . . . . . . . . . . . . 75 131 6.11.1.8. Multicast . . . . . . . . . . . . . . . . . . . 76 132 6.11.1.9. Security . . . . . . . . . . . . . . . . . . . . 76 133 6.11.1.10. P2P communications . . . . . . . . . . . . . . . 76 134 6.11.1.11. IPv6 address configuration . . . . . . . . . . . 76 135 6.11.1.12. Administrative parameters . . . . . . . . . . . 76 136 6.11.1.13. RPL Packet Information . . . . . . . . . . . . . 76 137 6.11.1.14. Unknown Destinations . . . . . . . . . . . . . . 77 138 6.12. General ACP Considerations . . . . . . . . . . . . . . . 77 139 6.12.1. Performance . . . . . . . . . . . . . . . . . . . . 77 140 6.12.2. Addressing of Secure Channels . . . . . . . . . . . 78 141 6.12.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . 78 142 6.12.4. Multiple links between nodes . . . . . . . . . . . . 79 143 6.12.5. ACP interfaces . . . . . . . . . . . . . . . . . . . 79 144 6.12.5.1. ACP loopback interfaces . . . . . . . . . . . . 79 145 6.12.5.2. ACP virtual interfaces . . . . . . . . . . . . . 81 146 6.12.5.2.1. ACP point-to-point virtual interfaces . . . 81 147 6.12.5.2.2. ACP multi-access virtual interfaces . . . . 82 148 7. ACP support on L2 switches/ports (Normative) . . . . . . . . 84 149 7.1. Why (Benefits of ACP on L2 switches) . . . . . . . . . . 84 150 7.2. How (per L2 port DULL GRASP) . . . . . . . . . . . . . . 85 151 8. Support for Non-ACP Components (Normative) . . . . . . . . . 87 152 8.1. ACP Connect . . . . . . . . . . . . . . . . . . . . . . . 87 153 8.1.1. Non-ACP Controller / NMS system . . . . . . . . . . . 87 154 8.1.2. Software Components . . . . . . . . . . . . . . . . . 89 155 8.1.3. Auto Configuration . . . . . . . . . . . . . . . . . 90 156 8.1.4. Combined ACP/Data-Plane Interface (VRF Select) . . . 91 157 8.1.5. Use of GRASP . . . . . . . . . . . . . . . . . . . . 93 158 8.2. Connecting ACP islands over Non-ACP L3 networks (Remote 159 ACP neighbors) . . . . . . . . . . . . . . . . . . . . . 93 160 8.2.1. Configured Remote ACP neighbor . . . . . . . . . . . 94 161 8.2.2. Tunneled Remote ACP Neighbor . . . . . . . . . . . . 95 162 8.2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 95 163 9. ACP Operations (Informative) . . . . . . . . . . . . . . . . 95 164 9.1. ACP (and BRSKI) Diagnostics . . . . . . . . . . . . . . . 96 165 9.1.1. Secure Channel Peer diagnostics . . . . . . . . . . . 100 166 9.2. ACP Registrars . . . . . . . . . . . . . . . . . . . . . 101 167 9.2.1. Registrar interactions . . . . . . . . . . . . . . . 102 168 9.2.2. Registrar Parameter . . . . . . . . . . . . . . . . . 103 169 9.2.3. Certificate renewal and limitations . . . . . . . . . 103 170 9.2.4. ACP Registrars with sub-CA . . . . . . . . . . . . . 104 171 9.2.5. Centralized Policy Control . . . . . . . . . . . . . 105 172 9.3. Enabling and disabling ACP/ANI . . . . . . . . . . . . . 105 173 9.3.1. Filtering for non-ACP/ANI packets . . . . . . . . . . 106 174 9.3.2. Admin Down State . . . . . . . . . . . . . . . . . . 106 175 9.3.2.1. Security . . . . . . . . . . . . . . . . . . . . 107 176 9.3.2.2. Fast state propagation and Diagnostics . . . . . 107 177 9.3.2.3. Low Level Link Diagnostics . . . . . . . . . . . 108 178 9.3.2.4. Power Consumption Issues . . . . . . . . . . . . 109 179 9.3.3. Interface level ACP/ANI enable . . . . . . . . . . . 109 180 9.3.4. Which interfaces to auto-enable? . . . . . . . . . . 109 181 9.3.5. Node Level ACP/ANI enable . . . . . . . . . . . . . . 111 182 9.3.5.1. Brownfield nodes . . . . . . . . . . . . . . . . 111 183 9.3.5.2. Greenfield nodes . . . . . . . . . . . . . . . . 112 184 9.3.6. Undoing ANI/ACP enable . . . . . . . . . . . . . . . 112 185 9.3.7. Summary . . . . . . . . . . . . . . . . . . . . . . . 113 186 9.4. Partial or Incremental adoption . . . . . . . . . . . . . 113 187 9.5. Configuration and the ACP (summary) . . . . . . . . . . . 114 188 10. Summary: Benefits (Informative) . . . . . . . . . . . . . . . 115 189 10.1. Self-Healing Properties . . . . . . . . . . . . . . . . 116 190 10.2. Self-Protection Properties . . . . . . . . . . . . . . . 117 191 10.2.1. From the outside . . . . . . . . . . . . . . . . . . 117 192 10.2.2. From the inside . . . . . . . . . . . . . . . . . . 118 193 10.3. The Administrator View . . . . . . . . . . . . . . . . . 119 195 11. Security Considerations . . . . . . . . . . . . . . . . . . . 119 196 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 122 197 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 123 198 14. Change log [RFC Editor: Please remove] . . . . . . . . . . . 124 199 14.1. Summary of changes since entering IESG review . . . . . 124 200 14.1.1. Reviews (while in IESG review status) / status . . . 124 201 14.1.2. BRSKI / ACP registrar related enhancements . . . . . 124 202 14.1.3. Normative enhancements since start of IESG review . 125 203 14.1.4. Explanatory enhancements since start of IESG review 126 204 14.2. draft-ietf-anima-autonomic-control-plane-26 . . . . . . 127 205 14.3. draft-ietf-anima-autonomic-control-plane-25 . . . . . . 127 206 14.4. draft-ietf-anima-autonomic-control-plane-24 . . . . . . 131 207 14.5. draft-ietf-anima-autonomic-control-plane-23 . . . . . . 131 208 14.6. draft-ietf-anima-autonomic-control-plane-22 . . . . . . 133 209 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 135 210 15.1. Normative References . . . . . . . . . . . . . . . . . . 135 211 15.2. Informative References . . . . . . . . . . . . . . . . . 138 212 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 146 213 Appendix A. Background and Futures (Informative) . . . . . . . . 146 214 A.1. ACP Address Space Schemes . . . . . . . . . . . . . . . . 146 215 A.2. BRSKI Bootstrap (ANI) . . . . . . . . . . . . . . . . . . 147 216 A.3. ACP Neighbor discovery protocol selection . . . . . . . . 148 217 A.3.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 148 218 A.3.2. mDNS and L2 support . . . . . . . . . . . . . . . . . 148 219 A.3.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 149 220 A.4. Choice of routing protocol (RPL) . . . . . . . . . . . . 149 221 A.5. ACP Information Distribution and multicast . . . . . . . 151 222 A.6. Extending ACP channel negotiation (via GRASP) . . . . . . 152 223 A.7. CAs, domains and routing subdomains . . . . . . . . . . . 153 224 A.8. Intent for the ACP . . . . . . . . . . . . . . . . . . . 155 225 A.9. Adopting ACP concepts for other environments . . . . . . 156 226 A.10. Further (future) options . . . . . . . . . . . . . . . . 157 227 A.10.1. Auto-aggregation of routes . . . . . . . . . . . . . 157 228 A.10.2. More options for avoiding IPv6 Data-Plane dependency 158 229 A.10.3. ACP APIs and operational models (YANG) . . . . . . . 158 230 A.10.4. RPL enhancements . . . . . . . . . . . . . . . . . . 159 231 A.10.5. Role assignments . . . . . . . . . . . . . . . . . . 159 232 A.10.6. Autonomic L3 transit . . . . . . . . . . . . . . . . 160 233 A.10.7. Diagnostics . . . . . . . . . . . . . . . . . . . . 160 234 A.10.8. Avoiding and dealing with compromised ACP nodes . . 161 235 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 162 237 1. Introduction (Informative) 239 Autonomic Networking is a concept of self-management: Autonomic 240 functions self-configure, and negotiate parameters and settings 241 across the network. [RFC7575] defines the fundamental ideas and 242 design goals of Autonomic Networking. A gap analysis of Autonomic 243 Networking is given in [RFC7576]. The reference architecture for 244 Autonomic Networking in the IETF is specified in the document 245 [I-D.ietf-anima-reference-model]. 247 Autonomic functions need an autonomically built communications 248 infrastructure. This infrastructure needs to be secure, resilient 249 and re-usable by all autonomic functions. Section 5 of [RFC7575] 250 introduces that infrastructure and calls it the Autonomic Control 251 Plane (ACP). More descriptively it would be the "Autonomic 252 communications infrastructure for OAM and Control". For naming 253 consistency with that prior document, this document continues to use 254 the name ACP though. 256 Today, the OAM and control plane of IP networks is what is typically 257 called in-band management/signaling: Its management and control 258 protocol traffic depends on the routing and forwarding tables, 259 security, policy, QoS and potentially other configuration that first 260 has to be established through the very same management and control 261 protocols. Misconfigurations including unexpected side effects or 262 mutual dependences can disrupt OAM and control operations and 263 especially disrupt remote management access to the affected node 264 itself and potentially a much larger number of nodes for whom the 265 affected node is on the network parth. Traditionally, physically 266 separate, so-called out-of-band (management) networks have been used 267 to avoid these problems or at least to allow recovery from such 268 problems. Worst case, personnel are sent on site to access devices 269 through out-of-band management ports (also called craft ports, serial 270 console, management ethernet port). However, both options are 271 expensive. 273 In increasingly automated networks either centralized management 274 systems or distributed autonomic service agents in the network 275 require a control plane which is independent of the configuration of 276 the network they manage, to avoid impacting their own operations 277 through the configuration actions they take. 279 This document describes a modular design for a self-forming, self- 280 managing and self-protecting ACP, which is a virtual out-of-band 281 network designed to be as independent as possible of configuration, 282 addressing and routing and similar self-dependency problems in 283 current IP networks, but which is still operating in-band on the same 284 physical network that it is controlling and managing. The ACP design 285 is therefore intended to combine as good as possible the resilience 286 of out-of-band management networks with the low-cost of traditional 287 IP in-band network management. The details how this is achieved are 288 described in Section 6. 290 In a fully autonomic network node without legacy control or 291 management functions/protocols, the Data-Plane would be for example 292 just a forwarding plane for "Data" IPv6 packets, aka: packets that 293 are not forwarded by the ACP itself such as control or management 294 plane packets. In such networks/nodes, there would be no non- 295 autonomous control or non-autonomous management plane. 297 Routing protocols for example would be built inside the ACP as so- 298 called autonomous functions via autonomous service agents, leveraging 299 the ACPs functions instead of implementing them seperately for each 300 protocol: discovery, automaticically established authenticated and 301 encrypted local and distant peer connectivity for control and 302 managemenet traffic and common control/management protocol session 303 and presentation functions. 305 When ACP functionality is added to nodes that have non-autonomous 306 management plane and/or control plane functions (henceforth called 307 non-autonomous nodes), the ACP instead is best abstracted as a 308 special Virtual Routing and Forwarding (VRF) instance (or virtual 309 router) and the complete pre-existing non-autonomous management and/ 310 or control plane is considered to be part of the Data-Plane to avoid 311 introduction of more complex, new terminology only for this case. 313 Like the forwarding plane for "Data" packets, the non-autonomous 314 control and management plane functions can then be managed/used via 315 the ACP. This terminology is consistent with pre-existing documents 316 such as [RFC8368]. 318 In both instances (autonomous and non-autonomous nodes), the ACP is 319 built such that it is operating in the absene of the Data-Plane, and 320 in the case of existing non-autonomous (management, control) 321 components in the Data-Plane also in the presence of any 322 (mis-)configuration thereof. 324 The Autonomic Control Plane serves several purposes at the same time: 326 1. Autonomic functions communicate over the ACP. The ACP therefore 327 directly supports Autonomic Networking functions, as described in 328 [I-D.ietf-anima-reference-model]. For example, Generic Autonomic 329 Signaling Protocol (GRASP - [I-D.ietf-anima-grasp]) runs securely 330 inside the ACP and depends on the ACP as its "security and 331 transport substrate". 333 2. A controller or network management system can use it to securely 334 bootstrap network devices in remote locations, even if the (Data- 335 Plane) network in between is not yet configured; no Data-Plane 336 dependent bootstrap configuration is required. An example of 337 such a secure bootstrap process is described in 338 [I-D.ietf-anima-bootstrapping-keyinfra]. 340 3. An operator can use it to access remote devices using protocols 341 such as Secure SHell (SSH) or Network Configuration Protocol 342 (NETCONF) running across the ACP, even if the network is 343 misconfigured or not configured. 345 This document describes these purposes as use cases for the ACP in 346 Section 3, it defines the requirements in Section 4. Section 5 gives 347 an overview how the ACP is constructed. 349 The normative part of this document starts with Section 6, where the 350 ACP is specified. Section 7 defines normative how to support ACP on 351 L2 switches. Section 8 explains normative how non-ACP nodes and 352 networks can be integrated. 354 The remaining sections are non-normative: Section 10 reviews benefits 355 of the ACP (after all the details have been defined), Section 9 356 provides operational recommendations, Appendix A provides additional 357 explanations and describes additional details or future standard or 358 propriety extensions that were considered not to be appropriate for 359 standardization in this document but were considered important to 360 document. There are no dependencies against Appendix A to build a 361 complete working and interoperable ACP according to this document. 363 The ACP provides secure IPv6 connectivity, therefore it can be used 364 not only as the secure connectivity for self-management as required 365 for the ACP in [RFC7575], but it can also be used as the secure 366 connectivity for traditional (centralized) management. The ACP can 367 be implemented and operated without any other components of autonomic 368 networks, except for the GRASP protocol. ACP relies on per-link DULL 369 GRASP (see Section 6.3) to autodiscover ACP neighbors, and includes 370 the ACP GRASP instance to provide service discovery for clients of 371 the ACP (see Section 6.8) including for its own maintenance of ACP 372 certificates. 374 The document "Using Autonomic Control Plane for Stable Connectivity 375 of Network OAM" [RFC8368] describes how the ACP alone can be used to 376 provide secure and stable connectivity for autonomic and non- 377 autonomic OAM applications, specifically for the case of current non- 378 autonomic networks/nodes. That document also explains how existing 379 management solutions can leverage the ACP in parallel with 380 traditional management models, when to use the ACP and how to 381 integrate with potentially IPv4 only OAM backends. 383 Combining ACP with Bootstrapping Remote Secure Key Infrastructures 384 (BRSKI), see [I-D.ietf-anima-bootstrapping-keyinfra]) results in the 385 "Autonomic Network Infrastructure" (ANI) as defined in 386 [I-D.ietf-anima-reference-model], which provides autonomic 387 connectivity (from ACP) with secure zero-touch (automated) bootstrap 388 from BRSKI. The ANI itself does not constitute an Autonomic Network, 389 but it allows the building of more or less autonomic networks on top 390 of it - using either centralized, Software Defined Networking- 391 (SDN-)style (see [RFC7426]) automation or distributed automation via 392 Autonomic Service Agents (ASA) / Autonomic Functions (AF) - or a 393 mixture of both. See [I-D.ietf-anima-reference-model] for more 394 information. 396 1.1. Applicability and Scope 398 Please see the following Terminology section (Section 2) for 399 explanations of terms used in this section. 401 The design of the ACP as defined in this document is considered to be 402 applicable to all types of "professionally managed" networks: Service 403 Provider, Local Area Network (LAN), Metro(politan networks), Wide 404 Area Network (WAN), Enterprise Information Technology (IT) and 405 ->"Operational Technology" () (OT) networks. The ACP can operate 406 equally on layer 3 equipment and on layer 2 equipment such as bridges 407 (see Section 7). The hop-by-hop authentication, integrity-protection 408 and confidentiality mechanism used by the ACP is defined to be 409 negotiable, therefore it can be extended to environments with 410 different protocol preferences. The minimum implementation 411 requirements in this document attempt to achieve maximum 412 interoperability by requiring support for multiple options depending 413 on the type of device: IPsec, see [RFC4301], and datagram Transport 414 Layer Security (DTLS) version 1.2, see [RFC6347]). 416 The implementation footprint of the ACP consists of Public Key 417 Infrastructure (PKI) code for the ACP certificate, the GRASP 418 protocol, UDP, TCP and TLS 1.2 ([RFC5246], for security and 419 reliability of GRASP), the ACP secure channel protocol used (such as 420 IPsec or DTLS), and an instance of IPv6 packet forwarding and routing 421 via the Routing Protocol for Low-power and Lossy Networks (RPL), see 422 [RFC6550], that is separate from routing and forwarding for the Data- 423 Plane (user traffic). 425 The ACP uses only IPv6 to avoid complexity of dual-stack ACP 426 operations (IPv6/IPv4). Nevertheless, it can without any changes be 427 integrated into even otherwise IPv4-only network devices. The Data- 428 Plane itself would not need to change, it could continue to be IPv4 429 only. For such IPv4 only devices, the IPv6 protocol itself would be 430 additional implementation footprint only used for the ACP. 432 The protocol choices of the ACP are primarily based on wide use and 433 support in networks and devices, well understood security properties 434 and required scalability. The ACP design is an attempt to produce 435 the lowest risk combination of existing technologies and protocols to 436 build a widely applicable operational network management solution: 438 RPL was chosen because it requires a smaller routing table footprint 439 in large networks compared to other routing protocols with an 440 autonomically configured single area. The deployment experience of 441 large scale Internet of Things (IoT) networks serves as the basis for 442 wide deployment experience with RPL. The profile chosen for RPL in 443 the ACP does not leverage any RPL specific forwarding plane features 444 (IPv6 extension headers), making its implementation a pure control 445 plane software requirement. 447 GRASP is the only completely novel protocol used in the ACP, and this 448 choice was necessary because there is no existing suitable protocol 449 to provide the necessary functions to the ACP, so GRASP was developed 450 to fill that gap. 452 The ACP design can be applicable to (cpu, memory) constrained devices 453 and (bitrate, reliability) constrained networks, but this document 454 does not attempt to define the most constrained type of devices or 455 networks to which the ACP is applicable. RPL and DTLS for ACP secure 456 channels are two protocol choices already making ACP more applicable 457 to constrained environments. Support for constrained devices in this 458 specification is opportunistic, but not complete, because the 459 reliable transport for GRASP (see Section 6.8.2) only specifies TCP/ 460 TLS). See Appendix A.9 for discussions about how future standards or 461 proprietary extensions/variations of the ACP could better meet 462 different expectations from those on which the current design is 463 based including supporting constrained devices better. 465 2. Acronyms and Terminology (Informative) 467 [RFC Editor: Please add ACP, BRSKI, GRASP, MASA to https://www.rfc- 468 editor.org/materials/abbrev.expansion.txt.] 470 [RFC Editor: WG/IETF/IESG review of the terms below asked for 471 references between these terms when they refer to each other. The 472 only option I could find for RFC/XML to point to a hanging text 473 acronym definition that also displays the actual term is the 474 format="title" version, which leads to references such as '->"ACP 475 domain certificate" ()'. I found no reasonable way to eliminate the 476 trailing '()' generated by this type of cross references. Can you 477 please take care of removing these artefacts during editing (after 478 conversion to nroff ?). I also created a ticket to ask for an 479 xml2rfc enhancement to avoid this in the future: 480 https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/347.] 482 [RFC Editor: Question: Is it possible to change the first occurrences 483 of [RFCxxxx] references to "rfcxxx title" [RFCxxxx]? the XML2RFC 484 format does not seem to offer such a format, but I did not want to 485 duplicate 50 first references - one reference for title mentioning 486 and one for RFC number.] 488 This document serves both as a normative specification for how ACP 489 nodes have to behave as well as describing requirements, benefits, 490 architecture and operational aspects to explain the context. 491 Normative sections are labelled "(Normative)" and use 492 [RFC2119]/[RFC8174] keywords. Other sections are labelled 493 "(Informative)" and do not use those normative keywords. 495 In the rest of the document we will refer to systems using the ACP as 496 "nodes". Typically such a node is a physical (network equipment) 497 device, but it can equally be some virtualized system. Therefore, we 498 do not refer to them as devices unless the context specifically calls 499 for a physical system. 501 This document introduces or uses the following terms (sorted 502 alphabetically). Terms introduced are explained on first use, so 503 this list is for reference only. 505 ACP: "Autonomic Control Plane". The Autonomic Function as defined 506 in this document. It provides secure zero-touch (automated) 507 transitive (network wide) IPv6 connectivity for all nodes in the 508 same ACP domain as well as a GRASP instance running across this 509 ACP IPv6 connectivity. The ACP is primarily meant to be used as a 510 component of the ANI to enable Autonomic Networks but it can 511 equally be used in simple ANI networks (with no other Autonomic 512 Functions) or completely by itself. 514 ACP address: An IPv6 address assigned to the ACP node. It is stored 515 in the acp-node-name of the ->"ACP domain certificate" (). 517 ACP address range/set: The ACP address may imply a range or set of 518 addresses that the node can assign for different purposes. This 519 address range/set is derived by the node from the format of the 520 ACP address called the "addressing sub-scheme". 522 ACP connect interface: An interface on an ACP node providing access 523 to the ACP for non ACP capable nodes without using an ACP secure 524 channel. See Section 8.1.1. 526 ACP domain: The ACP domain is the set of nodes with ->"ACP domain 527 certificates" that allow them to authenticate each other as 528 members of the ACP domain. See also Section 6.1.3. 530 ACP (ANI/AN) Domain Certificate: A [RFC5280] certificate (LDevID) 531 carrying the acp-node-name which is used by the ACP to learn its 532 address in the ACP and to derive and cryptographically assert its 533 membership in the ACP domain. 535 ACP acp-node-name field: An information field in the ACP Domain 536 Certificate in which the ACP relevant information is encoded: the 537 ACP domain name, the ACP IPv6 address of the node and optional 538 additional role attributes about the node. 540 ACP Loopback interface: The Loopback interface in the ACP Virtual 541 Routing and Forwarding (VRF) that has the ACP address assigned to 542 it. See Section 6.12.5.1. 544 ACP network: The ACP network constitutes all the nodes that have 545 access to the ACP. It is the set of active and transitively 546 connected nodes of an ACP domain plus all nodes that get access to 547 the ACP of that domain via ACP edge nodes. 549 ACP (ULA) prefix(es): The /48 IPv6 address prefixes used across the 550 ACP. In the normal/simple case, the ACP has one ULA prefix, see 551 Section 6.10. The ACP routing table may include multiple ULA 552 prefixes if the "rsub" option is used to create addresses from 553 more than one ULA prefix. See Section 6.1.2. The ACP may also 554 include non-ULA prefixes if those are configured on ACP connect 555 interfaces. See Section 8.1.1. 557 ACP secure channel: A channel authenticated via ->"ACP domain 558 certificates" () providing integrity protection and 559 confidentiality through encryption. These are established between 560 (normally) adjacent ACP nodes to carry traffic of the ACP VRF 561 securely and isolated from Data-Plane traffic in-band over the 562 same link/path as the Data-Plane. 564 ACP secure channel protocol: The protocol used to build an ACP 565 secure channel, e.g., Internet Key Exchange Protocol version 2 566 (IKEv2) with IPsec or Datagram Transport Layer Security (DTLS). 568 ACP virtual interface: An interface in the ACP VRF mapped to one or 569 more ACP secure channels. See Section 6.12.5. 571 AN "Autonomic Network": A network according to 572 [I-D.ietf-anima-reference-model]. Its main components are ANI, 573 Autonomic Functions and Intent. 575 (AN) Domain Name: An FQDN (Fully Qualified Domain Name) in the acp- 576 node-name of the Domain Certificate. See Section 6.1.2. 578 ANI (nodes/network): "Autonomic Network Infrastructure". The ANI is 579 the infrastructure to enable Autonomic Networks. It includes ACP, 580 BRSKI and GRASP. Every Autonomic Network includes the ANI, but 581 not every ANI network needs to include autonomic functions beyond 582 the ANI (nor Intent). An ANI network without further autonomic 583 functions can for example support secure zero-touch (automated) 584 bootstrap and stable connectivity for SDN networks - see 585 [RFC8368]. 587 ANIMA: "Autonomic Networking Integrated Model and Approach". ACP, 588 BRSKI and GRASP are specifications of the IETF ANIMA working 589 group. 591 ASA: "Autonomic Service Agent". Autonomic software modules running 592 on an ANI device. The components making up the ANI (BRSKI, ACP, 593 GRASP) are also described as ASAs. 595 Autonomic Function: A function/service in an Autonomic Network (AN) 596 composed of one or more ASA across one or more ANI nodes. 598 BRSKI: "Bootstrapping Remote Secure Key Infrastructures" 599 ([I-D.ietf-anima-bootstrapping-keyinfra]. A protocol extending 600 EST to enable secure zero-touch bootstrap in conjunction with ACP. 601 ANI nodes use ACP, BRSKI and GRASP. 603 CA: "Certification Authority". An entity that issues digital 604 certificates. A CA uses its private key to sign the certificates 605 it issues, relying parties use the public key in the CA 606 certificate to validate the signature. This signing certificate 607 can be considered to be an identifier of the CA, so the term CA is 608 also loosely used to refer to the certificate used by the CA for 609 signing. 611 CRL: "Certificate Revocation List". A list of revoked certificates. 612 Required to revoke certificates before their lifetime expires. 614 Data-Plane: The counterpoint to the ACP VRF in an ACP node: 615 forwarding of user traffic and in non-autonomous nodes/networks 616 also any non-autonomous control and/or management plane functions. 617 In a fully Autonomic Network node, the Data-Plane is managed 618 autonomically via Autonomic Functions and Intent. See Section 1 619 for more detailed explanations. 621 device: A physical system, or physical node. 623 Enrollment: The process through which a node authenticates itself to 624 a network with an initial identity, which is often called IDevID 625 certificate, and acquires from the network a network specific 626 identity, which is often called LDevID certificate, and 627 certificates of one or more Trust Anchor(s). In the ACP, the 628 LDevID certificate is called the ACP Domain Certificate. 630 EST: "Enrollment over Secure Transport" ([RFC7030]). IETF standard- 631 track protocol for enrollment of a node with an LDevID 632 certificate. BRSKI is based on EST. 634 GRASP: "Generic Autonomic Signaling Protocol". An extensible 635 signaling protocol required by the ACP for ACP neighbor discovery. 637 The ACP also provides the "security and transport substrate" for 638 the "ACP instance of GRASP". This instance of GRASP runs across 639 the ACP secure channels to support BRSKI and other NOC/OAM or 640 Autonomic Functions. See [I-D.ietf-anima-grasp]. 642 IDevID: An "Initial Device IDentity" X.509 certificate installed by 643 the vendor on new equipment. Contains information that 644 establishes the identity of the node in the context of its vendor/ 645 manufacturer such as device model/type and serial number. See 646 [AR8021]. The IDevID certificate cannot be used as a node 647 identifier for the ACP because they are not provisioned by the 648 owner of the network, so they can not directly indicate an ACP 649 domain they belong to. 651 in-band (management/signaling): In-band management traffic and/or 652 control plane signaling uses the same network resources such as 653 routers/switches and network links that it manages/controls. In- 654 band is the standard management and signaling mechanism in IP 655 networks. Compared to ->"out-of-band" () it requires no 656 additional physical resources, but introduces potentially circular 657 dependencies for its correct operations. See ->"introduction" 658 (Introduction (Informative)). 660 Intent: Policy language of an autonomic network according to 661 [I-D.ietf-anima-reference-model]. 663 Loopback interface: See ->"ACP Loopback interface" (). 665 LDevID: A "Local Device IDentity" is an X.509 certificate installed 666 during "enrollment". The Domain Certificate used by the ACP is an 667 LDevID certificate. See [AR8021]. 669 Management: Used in this document as another word for ->"OAM" (). 671 MASA (service): "Manufacturer Authorized Signing Authority". A 672 vendor/manufacturer or delegated cloud service on the Internet 673 used as part of the BRSKI protocol. 675 MIC: "Manufacturer Installed Certificate". This is another word to 676 describe an IDevID in referenced materials. This term is not used 677 in this document. 679 native interface: Interfaces existing on a node without 680 configuration of the already running node. On physical nodes 681 these are usually physical interfaces. On virtual nodes their 682 equivalent. 684 NOC: Network Operations Center. 686 node: A system supporting the ACP according to this document. Can 687 be virtual or physical. Physical nodes are called devices. 689 Node-ID: The identifier of an ACP node inside that ACP. It is the 690 last 64 (see Section 6.10.3) or 78-bits (see Section 6.10.5) of 691 the ACP address. 693 OAM: Operations, Administration and Management. Includes Network 694 Monitoring. 696 Operational Technology (OT): "https://en.wikipedia.org/wiki/ 697 Operational_Technology" [1]: "The hardware and software dedicated 698 to detecting or causing changes in physical processes through 699 direct monitoring and/or control of physical devices such as 700 valves, pumps, etc.". OT networks are today in most cases well 701 separated from Information Technology (IT) networks. 703 out-of-band (management) network: An out-of-band network is a 704 secondary network used to manage a primary network. The equipment 705 of the primary network is connected to the out-of-band network via 706 dedicated management ports on the primary network equipment. 707 Serial (console) management ports were historically most common, 708 higher end network equipment now also has ethernet ports dedicated 709 only for management. An out-of-band network provides management 710 access to the primary network independent of the configuration 711 state of the primary network. See ->"introduction" 712 (Introduction (Informative)) 714 (virtual) out-of-band network: The ACP can be called a virtual out- 715 of-band network for management and control because it attempts to 716 provide the benefits of a (physical) ->"out-of-band netork" () 717 even though it is physcially carried ->"in-band" (). See 718 ->"introduction" (Introduction (Informative)). 720 root CA: "root Certification Authority". A ->"CA" () for which the 721 root CA Key update procedures of [RFC7030], Section 4.4 can be 722 applied. 724 RPL: "IPv6 Routing Protocol for Low-Power and Lossy Networks". The 725 routing protocol used in the ACP. See [RFC6550]. 727 (ACP/ANI/BRSKI) Registrar: An ACP registrar is an entity (software 728 and/or person) that is orchestrating the enrollment of ACP nodes 729 with the ACP domain certificate. ANI nodes use BRSKI, so ANI 730 registrars are also called BRSKI registrars. For non-ANI ACP 731 nodes, the registrar mechanisms are undefined by this document. 732 See Section 6.10.7. Renewal and other maintenance (such as 733 revocation) of ACP domain certificates may be performed by other 734 entities than registrars. EST must be supported for ACP domain 735 certificate renewal (see Section 6.1.5). BRSKI is an extension of 736 EST, so ANI/BRSKI registrars can easily support ACP domain 737 certificate renewal in addition to initial enrollment. 739 RPI: "RPL Packet Information". Network extension headers for use 740 with the ->"RPL" () routing protocols. Not used with RPL in the 741 ACP. See Section 6.11.1.13. 743 RPL: "Routing Protocol for Low-Power and Lossy Networks". The 744 routing protocol used in the ACP. See Section 6.11. 746 sUDI: "secured Unique Device Identifier". This is another word to 747 describe an IDevID in referenced material. This term is not used 748 in this document. 750 TA: "Trust Anchor". A Trust Anchor is an entity that is trusted for 751 the purpose of certificate validation. Trust Anchor Information 752 such as self-signed certificate(s) of the Trust Anchor is 753 configured into the ACP node as part of Enrollment. See 754 [RFC5280], Section 6.1.1. 756 UDI: "Unique Device Identifier". In the context of this document 757 unsecured identity information of a node typically consisting of 758 at least device model/type and serial number, often in a vendor 759 specific format. See sUDI and LDevID. 761 ULA: (Global ID prefix) A "Unique Local Address" (ULA) is an IPv6 762 address in the block fc00::/7, defined in [RFC4193]. It is the 763 approximate IPv6 counterpart of the IPv4 private address 764 ([RFC1918]). The ULA Global ID prefix are the first 48-bits of a 765 ULA address. In this document it is abbreviated as "ULA prefix". 767 (ACP) VRF: The ACP is modeled in this document as a "Virtual Routing 768 and Forwarding" instance (VRF). This means that it is based on a 769 "virtual router" consisting of a separate IPv6 forwarding table to 770 which the ACP virtual interfaces are attached and an associated 771 IPv6 routing table separate from the Data-Plane. Unlike the VRFs 772 on MPLS/VPN-PE ([RFC4364]) or LISP XTR ([RFC6830]), the ACP VRF 773 does not have any special "core facing" functionality or routing/ 774 mapping protocols shared across multiple VRFs. In vendor products 775 a VRF such as the ACP-VRF may also be referred to as a so called 776 VRF-lite. 778 (ACP) Zone: An ACP zone is a set of ACP nodes using the same zone 779 field value in their ACP address according to Section 6.10.3. 780 Zones are a mechanism to support structured addressing of ACP 781 addresses within the same /48-bit ULA prefix. 783 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 784 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 785 "OPTIONAL" in this document are to be interpreted as described in BCP 786 14 [RFC2119],[RFC8174] when, and only when, they appear in all 787 capitals, as shown here. 789 3. Use Cases for an Autonomic Control Plane (Informative) 791 This section summarizes the use cases that are intended to be 792 supported by an ACP. To understand how these are derived from and 793 relate to the larger set of use cases for autonomic networks, please 794 refer to [RFC8316]. 796 3.1. An Infrastructure for Autonomic Functions 798 Autonomic Functions need a stable infrastructure to run on, and all 799 autonomic functions should use the same infrastructure to minimize 800 the complexity of the network. In this way, there is only need for a 801 single discovery mechanism, a single security mechanism, and single 802 instances of other processes that distributed functions require. 804 3.2. Secure Bootstrap over a not configured Network 806 Today, bootstrapping a new node typically requires all nodes between 807 a controlling node such as an SDN controller ("Software Defined 808 Networking", see [RFC7426]) and the new node to be completely and 809 correctly addressed, configured and secured. Bootstrapping and 810 configuration of a network happens in rings around the controller - 811 configuring each ring of devices before the next one can be 812 bootstrapped. Without console access (for example through an out-of- 813 band network) it is not possible today to make devices securely 814 reachable before having configured the entire network leading up to 815 them. 817 With the ACP, secure bootstrap of new devices and whole new networks 818 can happen without requiring any configuration of unconfigured 819 devices along the path: As long as all devices along the path support 820 ACP and a zero-touch bootstrap mechanism such as BRSKI, the ACP 821 across a whole network of unconfigured devices can be brought up 822 without operator/provisioning intervention. The ACP also provides 823 additional security for any bootstrap mechanism, because it can 824 provide encrypted discovery (via ACP GRASP) of registrars or other 825 bootstrap servers by bootstrap proxies connecting to nodes that are 826 to be bootstrapped and the ACP encryption hides the identities of the 827 communicating entities (pledge and registrar), making it more 828 difficult to learn which network node might be attackable. The ACP 829 domain certificate can also be used to end-to-end encrypt the 830 bootstrap communication between such proxies and server. Note that 831 bootstrapping here includes not only the first step that can be 832 provided by BRSKI (secure keys), but also later stages where 833 configuration is bootstrapped. 835 3.3. Data-Plane Independent Permanent Reachability 837 Today, most critical control plane protocols and OAM protocols are 838 using the Data-Plane of the network. This leads to often undesirable 839 dependencies between control and OAM plane on one side and the Data- 840 Plane on the other: Only if the forwarding and control plane of the 841 Data-Plane are configured correctly, will the Data-Plane and the OAM/ 842 control plane work as expected. 844 Data-Plane connectivity can be affected by errors and faults, for 845 example misconfigurations that make AAA (Authentication, 846 Authorization and Accounting) servers unreachable or can lock an 847 administrator out of a device; routing or addressing issues can make 848 a device unreachable; shutting down interfaces over which a current 849 management session is running can lock an admin irreversibly out of 850 the device. Traditionally only out-of-band access can help recover 851 from such issues (such as serial console or ethernet management 852 port). 854 Data-Plane dependencies also affect applications in a Network 855 Operations Center (NOC) such as SDN controller applications: Certain 856 network changes are today hard to implement, because the change 857 itself may affect reachability of the devices. Examples are address 858 or mask changes, routing changes, or security policies. Today such 859 changes require precise hop-by-hop planning. 861 Note that specific control plane functions for the Data-Plane often 862 want to depend on forwarding of their packets via the Data-Plane: 863 Aliveness and routing protocol signaling packets across the Data- 864 Plane to verify reachability across the Data-Plane, using IPv4 865 signaling packets for IPv4 routing vs. IPv6 signaling packets for 866 IPv6 routing. 868 Assuming appropriate implementation (see Section 6.12.2 for more 869 details), the ACP provides reachability that is independent of the 870 Data-Plane. This allows the control plane and OAM plane to operate 871 more robustly: 873 o For management plane protocols, the ACP provides the functionality 874 of a Virtual out-of-band (VooB) channel, by providing connectivity 875 to all nodes regardless of their Data-Plane configuration, routing 876 and forwarding tables. 878 o For control plane protocols, the ACP allows their operation even 879 when the Data-Plane is temporarily faulty, or during transitional 880 events, such as routing changes, which may affect the control 881 plane at least temporarily. This is specifically important for 882 autonomic service agents, which could affect Data-Plane 883 connectivity. 885 The document "Using Autonomic Control Plane for Stable Connectivity 886 of Network OAM" [RFC8368] explains this use case for the ACP in 887 significantly more detail and explains how the ACP can be used in 888 practical network operations. 890 4. Requirements (Informative) 892 The following requirements were identified for the design of the ACP 893 based on the above use-cases (Section 3). These requirements are 894 informative. The ACP as specified in the normative parts of this 895 document is meeting or exceeding these use-case requirements: 897 ACP1: The ACP should provide robust connectivity: As far as 898 possible, it should be independent of configured addressing, 899 configuration and routing. Requirements 2 and 3 build on this 900 requirement, but also have value on their own. 902 ACP2: The ACP must have a separate address space from the Data- 903 Plane. Reason: traceability, debug-ability, separation from 904 Data-Plane, infrastructure security (filtering based on known 905 address space). 907 ACP3: The ACP must use autonomically managed address space. Reason: 908 easy bootstrap and setup ("autonomic"); robustness (admin 909 cannot break network easily). This document uses Unique Local 910 Addresses (ULA) for this purpose, see [RFC4193]. 912 ACP4: The ACP must be generic, that is it must be usable by all the 913 functions and protocols of the ANI. Clients of the ACP must 914 not be tied to a particular application or transport protocol. 916 ACP5: The ACP must provide security: Messages coming through the ACP 917 must be authenticated to be from a trusted node, and should 918 (very strong should) be encrypted. 920 Explanation for ACP4: In a fully autonomic network (AN), newly 921 written ASA could potentially all communicate exclusively via GRASP 922 with each other, and if that was assumed to be the only requirement 923 against the ACP, it would not need to provide IPv6 layer connectivity 924 between nodes, but only GRASP connectivity. Nevertheless, because 925 ACP also intends to support non-AN networks, it is crucial to support 926 IPv6 layer connectivity across the ACP to support any transport and 927 application layer protocols. 929 The ACP operates hop-by-hop, because this interaction can be built on 930 IPv6 link local addressing, which is autonomic, and has no dependency 931 on configuration (requirement 1). It may be necessary to have ACP 932 connectivity across non-ACP nodes, for example to link ACP nodes over 933 the general Internet. This is possible, but introduces a dependency 934 against stable/resilient routing over the non-ACP hops (see 935 Section 8.2). 937 5. Overview (Informative) 939 When a node has an ACP domain certificate (see Section 6.1.1) and is 940 enabled to bring up the ACP (see Section 9.3.5), it will create its 941 ACP without any configuration as follows. For details, see Section 6 942 and further sections: 944 1. The node creates a VRF instance, or a similar virtual context for 945 the ACP. 947 2. The node assigns its ULA IPv6 address (prefix) (see Section 6.10 948 which is learned from the acp-node-name (see (see Section 6.1.2) 949 of its ACP domain certificate (see Section 6.1.1) to an ACP 950 loopback interface (see Section 6.10) and connects this interface 951 into the ACP VRF. 953 3. The node establishes a list of candidate peer adjacencies and 954 candidate channel types to try for the adjacency. This is 955 automatic for all candidate link-local adjacencies, see 956 Section 6.3 across all native interfaces (see Section 9.3.4). If 957 a candidate peer is discovered via multiple interfaces, this will 958 result in one adjacency per interface. If the ACP node has 959 multiple interfaces connecting to the same subnet across which it 960 is also operating as an L2 switch in the Data-Plane, it employs 961 methods for ACP with L2 switching, see Section 7. 963 4. For each entry in the candidate adjacency list, the node 964 negotiates a secure tunnel using the candidate channel types. 965 See Section 6.5. 967 5. The node authenticates the peer node during secure channel setup 968 and authorizes it to become part of the ACP according to 969 Section 6.1.3. 971 6. Each successfully established secure channel is mapped into an 972 ACP virtual interface, which is placed into the ACP VRF. See 973 Section 6.12.5.2. 975 7. Each node runs a lightweight routing protocol, see Section 6.11, 976 to announce reachability of the ACP loopack address (or prefix) 977 across the ACP. 979 8. This completes the creation of the ACP with hop-by-hop secure 980 tunnels, auto-addressing and auto-routing. The node is now an 981 ACP node with a running ACP. 983 Note: 985 o None of the above operations (except the following explicit 986 configured ones) are reflected in the configuration of the node. 988 o Non-ACP NMS ("Network Management Systems") or SDN controllers have 989 to be explicitly configured for connection into the ACP. 991 o Additional candidate peer adjacencies for ACP connections across 992 non-ACP Layer-3 clouds requires explicit configuration. See 993 Section 8.2. 995 The following figure illustrates the ACP. 997 ACP node 1 ACP node 2 998 ................... ................... 999 secure . . secure . . secure 1000 channel: +-----------+ : channel : +-----------+ : channel 1001 ..--------| ACP VRF |---------------------| ACP VRF |---------.. 1002 : / \ / \ <--routing--> / \ / \ : 1003 : \ / \ / \ / \ / : 1004 ..--------| Loopback |---------------------| Loopback |---------.. 1005 : | interface | : : | interface | : 1006 : +-----------+ : : +-----------+ : 1007 : : : : 1008 : Data-Plane :...............: Data-Plane : 1009 : : link : : 1010 :.................: :.................: 1012 Figure 1: ACP VRF and secure channels 1014 The resulting overlay network is normally based exclusively on hop- 1015 by-hop tunnels. This is because addressing used on links is IPv6 1016 link local addressing, which does not require any prior set-up. In 1017 this way the ACP can be built even if there is no configuration on 1018 the node, or if the Data-Plane has issues such as addressing or 1019 routing problems. 1021 6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 1023 This section describes the components and steps to set up an ACP and 1024 highlights the key properties which make it "indestructible" against 1025 many inadvertent changes to the Data-Plane, for example caused by 1026 misconfigurations. 1028 An ACP node can be a router, switch, controller, NMS host, or any 1029 other IP capable node. Initially, it MUST have its ACP domain 1030 certificate, as well as an (empty) ACP Adjacency Table (described in 1031 Section 6.2). It then can start to discover ACP neighbors and build 1032 the ACP. This is described step by step in the following sections: 1034 6.1. ACP Domain, Certificate and Network 1036 The ACP relies on group security. An ACP domain is a group of nodes 1037 that trust each other to participate in ACP operations such as 1038 creating ACP secure channels in an autonomous peer-to-peer fashion 1039 between ACP domain members via protocols such as IPsec. To 1040 authenticate and authorize another ACP member node with access to the 1041 ACP Domain, each ACP member requires keying material: An ACP node 1042 MUST have a Local Device IDentity (LDevID) certificate, henceforth 1043 called the ACP Domain Certificate and information about one or more 1044 Trust Anchor (TA) as required for the ACP domain membership check 1045 (Section 6.1.3). 1047 Manual keying via shared secrets is not usable for an ACP domain 1048 because it would require a single shared secret across all current 1049 and future ACP domain members to meet the expectation of autonomous, 1050 peer-to-peer establishment of ACP secure channels between any ACP 1051 domain members. Such a single shared secret would be an inacceptable 1052 security weakness. Asymmetric keying material (public keys) without 1053 certificates does not provide the mechanisms to authenticate ACP 1054 domain membership in an autonomous, peer-to-peer fashion for current 1055 and future ACP domain members. 1057 The LDevID certificate is called the ACP domain certificate, the TA 1058 is the Certification Authority (CA) root certificate of the ACP 1059 domain. 1061 The ACP does not mandate specific mechanisms by which this keying 1062 material is provisioned into the ACP node. It only requires the 1063 certificate to comply with Section 6.1.1, specifically to have the 1064 acp-node-name as specified in Section 6.1.2 in its domain certificate 1065 as well as those of candidate ACP peers. See Appendix A.2 for more 1066 information about enrollment or provisioning options. 1068 This document uses the term ACP in many places where the Autonomic 1069 Networking reference documents [RFC7575] and 1070 [I-D.ietf-anima-reference-model] use the word autonomic. This is 1071 done because those reference documents consider (only) fully 1072 autonomic networks and nodes, but support of ACP does not require 1073 support for other components of autonomic networks except for relying 1074 on GRASP and providing security and transport for GRASP. Therefore 1075 the word autonomic might be misleading to operators interested in 1076 only the ACP. 1078 [RFC7575] defines the term "Autonomic Domain" as a collection of 1079 autonomic nodes. ACP nodes do not need to be fully autonomic, but 1080 when they are, then the ACP domain is an autonomic domain. Likewise, 1081 [I-D.ietf-anima-reference-model] defines the term "Domain 1082 Certificate" as the certificate used in an autonomic domain. The ACP 1083 domain certificate is that domain certificate when ACP nodes are 1084 (fully) autonomic nodes. Finally, this document uses the term ACP 1085 network to refer to the network created by active ACP nodes in an ACP 1086 domain. The ACP network itself can extend beyond ACP nodes through 1087 the mechanisms described in Section 8.1. 1089 6.1.1. ACP Certificates 1091 ACP domain certificates MUST be [RFC5280] compliant X.509v3 1092 certificates. 1094 ACP nodes MUST support handling ACP certificates, TA certificates and 1095 certificate chain certificates (henceforth just called certificates 1096 in this section) with RSA public keys and certificates with Elliptic 1097 Curve (ECC) public keys. 1099 ACP nodes MUST NOT support certificates with RSA public keys of less 1100 than 2048 bit modulus or curves with group order of less than 256 1101 bit. They MUST support certificates with RSA public keys with 2048 1102 bit modulus and MAY support longer RSA keys. They MUST support 1103 certificates with ECC public keys using NIST P-256 curves and SHOULD 1104 support P-384 and P-521 curves. 1106 ACP nodes MUST support SHA-256 and SHOULD support SHA-384, SHA-512 1107 signatures for certificates with RSA key and the same RSA signatures 1108 plus ECDSA signatures for certificates with ECC key. 1110 The ACP certificate SHOULD use an RSA key and an RSA signature when 1111 the ACP certificate is intended to be used not only for ACP 1112 authentication but also for other purposes. The ACP certificate MAY 1113 use an ECC key and an ECDSA signature if the ACP certificate is only 1114 used for ACP and ANI authentication and authorization. 1116 Any secure channel protocols used for the ACP as specified in this 1117 document or extensions of this document MUST therefore support 1118 authentication (e.g.:signing) starting with these type of 1119 certificates. See [RFC4492] for more information. 1121 The reason for these choices are as follows: As of 2020, RSA is still 1122 more widely used than ECC, therefore the MUST for RSA. ECC offers 1123 equivalent security at (logarithmically) shorter key lengths (see 1124 [RFC4492]). This can be beneficial especially in the presence of 1125 constrained bandwidth or constrained nodes in an ACP/ANI network. 1126 Some ACP functions such as GRASP peer-2-peer across the ACP require 1127 end-to-end/any-to-any authentication/authorization, therefore ECC can 1128 only reliably be used in the ACP when it MUST be supported on all ACP 1129 nodes. RSA signatures are mandatory to be supported also for ECC 1130 certificates because CAs themselves may not support ECC yet. 1132 The ACP domain certificate SHOULD be used for any authentication 1133 between nodes with ACP domain certificates (ACP nodes and NOC nodes) 1134 where the required authorization condition is ACP domain membership, 1135 such as ACP node to NOC/OAM end-to-end security and ASA to ASA end- 1136 to-end security. Section 6.1.3 defines this "ACP domain membership 1137 check". The uses of this check that are standardized in this 1138 document are for the establishment of hop-by-hop ACP secure channels 1139 (Section 6.6) and for ACP GRASP (Section 6.8.2) end-to-end via TLS 1140 1.2 ([RFC5246]). 1142 The ACP domain membership check requires a minimum amount of elements 1143 in a certificate as described in Section 6.1.3. The identity of a 1144 node in the ACP is carried via the acp-node-name as defined in 1145 Section 6.1.2. 1147 In support of ECDH key establishment, ACP certificates with ECC keys 1148 MUST indicate to be Elliptic Curve Diffie-Hellman capable (ECDH) if 1149 X.509 v3 keyUsage and extendedKeyUsage are included in the 1150 certificate. 1152 Any other field of the ACP domain certificate is to be populated as 1153 required by [RFC5280] or desired by the operator of the ACP domain 1154 ACP registrars/CA and required by other purposes that the ACP domain 1155 certificate is intended to be used for. 1157 For further certificate details, ACP certificates may follow the 1158 recommendations from [CABFORUM]. 1160 For diagnostic and other operational purposes, it is beneficial to 1161 copy the device identifying fields of the node's IDevID certificate 1162 into the ACP domain certificate, such as the "serialNumber" (see 1163 [I-D.ietf-anima-bootstrapping-keyinfra] section 2.3.1). This can be 1164 done for example if it would be acceptable for the devices 1165 "serialNumber" to be signalled via the Link Layer Discovery Protocol 1166 (LLDP, [LLDP]) because like LLDP signalled information, the ACP 1167 certificate information can be retrieved bei neighboring nodes 1168 without further authentication and be used either for beneficial 1169 diagnostics or for malicious attacks. Retrieval of the ACP 1170 certificate is possible via a (failing) attempt to set up an ACP 1171 secure channel, and the "serialNumber" contains usually device type 1172 information that may help to faster determine working exploits/ 1173 attacks against the device. 1175 Note that there is no intention to constrain authorization within the 1176 ACP or autonomic networks using the ACP to just the ACP domain 1177 membership check as defined in this document. It can be extended or 1178 modified with future requirements. Such future authorizations can 1179 use and require additional elements in certificates or policies or 1180 even additional certificates. For an example, see Appendix A.10.5. 1182 6.1.2. ACP Certificate AcpNodeName 1184 acp-node-name = local-part "@" acp-domain-name 1185 local-part = [ acp-address ] [ "+" rsub extensions ] 1186 HEXLC = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" 1187 ; DIGIT as of RFC5234 section B.1 1188 acp-address = 32HEXLC | "0" 1189 rsub = [ ] ; as of RFC1034, section 3.5 1190 acp-domain-name = ; ; as of RFC 1034, section 3.5 1191 extensions = *( "+" extension ) 1192 extension = ; future standard definition. 1193 ; Must fit RFC5322 simple dot-atom format. 1195 routing-subdomain = [ rsub "." ] acp-domain-name 1197 Example: 1198 given an ACP address of fd89:b714:f3db:0:200:0:6400:0000 1199 and an ACP domain-name of acp.example.com 1200 and an rsub extenstion of area51.research 1202 then this results in: 1203 acp-node-name = fd89b714F3db00000200000064000000 1204 +area51.research@acp.example.com 1205 acp-domain-name = acp.example.com 1206 routing-subdomain = area51.research.acp.example.com 1208 Figure 2: ACP Node Name ABNF 1210 acp-node-name in above Figure 2 is the ABNF ([RFC5234]) definition of 1211 the ACP Node Name. An ACP domain certificate MUST carry this 1212 information. It MUST be encoded as an otherName / AcpNodeName as 1213 described in Section 6.1.2.1. 1215 Nodes complying with this specification MUST be able to receive their 1216 ACP address through the domain certificate, in which case their own 1217 ACP domain certificate MUST have the 32HEXDIG "acp-address" field. 1218 Nodes complying with this specification MUST also be able to 1219 authenticate nodes as ACP domain members or ACP secure channel peers 1220 when they have a 0-value acp-address field and as ACP domain members 1221 (but not as ACP secure channel peers) when they have an empty acp- 1222 address field. See Section 6.1.3. 1224 acp-domain-name is used to indicate the ACP Domain across which ACP 1225 nodes authenticate and authorize each other, for example to build ACP 1226 secure channels to each other, see Section 6.1.3. acp-domain-name 1227 SHOULD be the FQDN of an Internet domain owned by the network 1228 administration of the ACP and ideally reserved to only be used for 1229 the ACP. In this specification it serves to be a name for the ACP 1230 that ideally is globally unique. When acp-domain-name is a globally 1231 unique name, collision of ACP addresses across different ACP domains 1232 can only happen due to ULA hash collisions (see Section 6.10.2). 1233 Using different acp-domain-names, operators can distinguish multiple 1234 ACP even when using the same TA. 1236 To keep the encoding simple, there is no consideration for 1237 internationalized acp-domain-names. The acp-node-name is not 1238 intended for end user consumption, and there is no protection against 1239 someone not owning a domain name to simpy choose it. Instead, it 1240 serves as a hash seed for the ULA and for diagnostics to the 1241 operator. Therefore, any operator owning only an internationalized 1242 domain name should be able to pick an equivalently unique 7-bit ASCII 1243 acp-domain-name string representing the internationalized domain 1244 name. 1246 "routing-subdomain" is a string that can be constructed from the acp- 1247 node-name, and it is used in the hash-creation of the ULA (see 1248 below). The presence of the "rsub" component allows a single ACP 1249 domain to employ multiple /48 ULA prefixes. See Appendix A.7 for 1250 example use-cases. 1252 The optional "extensions" field is used for future standardized 1253 extensions to this specification. It MUST be ignored if present and 1254 not understood. 1256 The following points explain and justify the encoding choices 1257 described: 1259 1. Formatting notes: 1261 1.1 "rsub" needs to be in the "local-part": If the format just 1262 had routing-subdomain as the domain part of the acp-node- 1263 name, rsub and acp-domain-name could not be separated from 1264 each other to determine in the ACP domain membership check 1265 which part is the acp-domain-name and which is solely for 1266 creating a different ULA prefix. 1268 1.2 If "acp-address" is empty, and "rsub" is empty too, the 1269 "local-part" will have the format ":++extension(s)". The 1270 two plus characters are necessary so the node can 1271 unambiguously parse that both "acp-address" and "rsub" are 1272 empty. 1274 2. The encoding of the ACP domain name and ACP address as described 1275 in this section is used for the following reasons: 1277 2.1 The acp-node-name is the identifier of a node's ACP. It 1278 includes the necessary components to identify a nodes ACP 1279 both from within the ACP as well as from the outside of the 1280 ACP. 1282 2.2 For manual and/or automated diagnostics and backend 1283 management of devices and ACPs, it is necessary to have an 1284 easily human readible and software parsed standard, single 1285 string representation of the information in the acp-node- 1286 name. For example, inventory or other backend systems can 1287 always identify an entity by one unique string field but not 1288 by a combination of multiple fields, which would be 1289 necessary if there was no single string representation. 1291 2.3 If the encoding was not that of such a string, it would be 1292 necessary to define a second standard encoding to provide 1293 this format (standard string encoding) for operator 1294 consumption. 1296 2.4 Adresses of the form <@domain> have become the 1297 preferred format for identifiers of entities in many 1298 systems, including the majority of user identification in 1299 web or mobile applications such as multi-domain single-sign- 1300 on systems. 1302 3. Compatibilities: 1304 3.1 It should be possible to use the ACP domain certificate as 1305 an LDevID certificate on the system for other uses beside 1306 the ACP. Therefore, the information element required for 1307 the ACP should be encoded so that it minimizes the 1308 possibility of creating incompatibilities with such other 1309 uses. The subjectName is for example often used as an 1310 entity identifier in non-ACP uses of a the ACP Domain 1311 certificate. 1313 3.2 The element should not require additional ASN.1 en/decoding, 1314 because libraries to access certificate information 1315 especially for embedded devices may not support extended 1316 ASN.1 decoding beyond predefined, manadatory fields. 1317 subjectAltName / otherName is already used with a single 1318 string parameter for several otherNames (see [RFC3920], 1319 [RFC7585], [RFC4985], [RFC8398]). 1321 3.3 The element required for the ACP should minimize the risk of 1322 being misinterpreted by other uses of the LDevID 1323 certificate. It also must not be misinterpreted to actually 1324 be an email address, hence the use of the otherName / 1325 rfc822Name option in the certificate would be inapproprite. 1327 See section 4.2.1.6 of [RFC5280] for details on the subjectAltName 1328 field. 1330 6.1.2.1. AcpNodeName ASN.1 Module 1332 The following ASN.1 module normatively specifies the AcpNodeName 1333 structure. This specification uses the ASN.1 definitions from 1334 [RFC5912] with the 2002 ASN.1 notation used in that document. 1335 [RFC5912] updates normative documents using older ASN.1 notation. 1337 ANIMA-ACP-2020 1338 { iso(1) identified-organization(3) dod(6) 1339 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 1340 id-mod-anima-acpnodename-2020(IANA1) } 1342 DEFINITIONS IMPLICIT TAGS ::= 1343 BEGIN 1345 IMPORTS 1346 OTHER-NAME 1347 FROM PKIX1Implicit-2009 1348 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 1349 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59) } 1351 id-pkix 1352 FROM PKIX1Explicit-2009 1353 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 1354 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51) } ; 1356 id-on OBJECT IDENTIFIER ::= { id-pkix 8 } 1358 AcpNodeNameOtherNames OTHER-NAME ::= { on-AcpNodeName, ... } 1360 on-AcpNodeName OTHER-NAME ::= { 1361 AcpNodeName IDENTIFIED BY id-on-AcpNodeName 1362 } 1364 id-on-AcpNodeName OBJECT IDENTIFIER ::= { id-on IANA2 } 1366 AcpNodeName ::= IA5String (SIZE (1..MAX)) 1367 -- AcpNodeName as specified in this document carries the 1368 -- acp-node-name as specified in the ABNF in Section 6.1.2 1370 END 1372 6.1.3. ACP domain membership check 1374 The following points constitute the ACP domain membership check of a 1375 candidate peer via its certificate: 1377 1: The peer has proved ownership of the private key associated with 1378 the certificate's public key. This check is performed by the 1379 security association protocol used, for example [RFC7296], section 1380 2.15. 1382 2: The peer's certificate passes certificate path validation as 1383 defined in [RFC5280], section 6 against one of the TA associated 1384 with the ACP node's ACP domain certificate (see Section 6.1.4 1385 below). This includes verification of the validity (lifetime) of 1386 the certificates in the path. 1388 3: If the node certificate indicates a Certificate Revocation List 1389 (CRL) Distribution Point (CRLDP) ([RFC5280], section 4.2.1.13) or 1390 Online Certificate Status Protocol (OCSP) responder ([RFC5280], 1391 section 4.2.2.1), then the peer's certificate MUST be valid 1392 according to those mechanisms when they are available: An OCSP 1393 check for the peer's certificate across the ACP must succeed or 1394 the peer certificate must not be listed in the CRL retrieved from 1395 the CRLDP. These mechanisms are not available when the node has 1396 no ACP or non-ACP connectivity to retrieve a current CRL or access 1397 an OCSP responder and the security association protocol itself has 1398 also no way to communicate CRL or OCSP check. 1400 Retries to learn revocation via OCSP/CRL SHOULD be made using 1401 the same backoff as described in Section 6.6. If and when the ACP 1402 node then learns that an ACP peer's certificate is invalid for 1403 which rule 3 had to be skipped during ACP secure channel 1404 establishment, then the ACP secure channel to that peer MUST be 1405 closed even if this peer is the only connectivity to access CRL/ 1406 OCSP. This applies (of course) to all ACP secure channels to this 1407 peer if there are multiple. The ACP secure channel connection 1408 MUST be retried periodically to support the case that the neighbor 1409 acquires a new, valid certificate. 1411 4: The peer's certificate has a syntactically valid acp-node-name 1412 field and the acp-domain-name in that peer's acp-node-name is the 1413 same as in this ACP node's certificate (lowercase normalized). 1415 When checking a candidate peer's certificate for the purpose of 1416 establishing an ACP secure channel, one additional check is 1417 performed: 1419 5: The candidate peer certificate's acp-node-name has a non-empty 1420 acp-address field (either 32HEXDIG or 0, according to Figure 2). 1422 Technically, ACP secure channels can only be built with nodes that 1423 have an acp-address. Rule 5 ensures that this is taken into account 1424 during ACP domain membership check. 1426 Nodes with an empty acp-address field can only use their ACP domain 1427 certificate for non-ACP-secure channel authentication purposes. This 1428 includes for example NMS type nodes permitted to communicate into the 1429 ACP via ACP connect (Section 8.1) 1431 The special value 0 in an ACP certificates acp-address field is used 1432 for nodes that can and should determine their ACP address through 1433 other mechanisms than learning it through the acp-address field in 1434 their ACP domain certificate. These ACP nodes are permitted to 1435 establish ACP secure channels. Mechanisms for those nodes to 1436 determine their ACP address are outside the scope of this 1437 specification, but this option is defined here so that any ACP nodes 1438 can build ACP secure channels to them according to Rule 5. 1440 In summary: 1442 Steps 1...4 constitute standard certificate validity verification 1443 and private key authentication as defined by [RFC5280] and 1444 security association protocols (such as Internet Key Exchange 1445 Protocol version 2 IKEv2 [RFC7296] when leveraging certificates. 1447 Steps 1...4 do not include verification of any pre-existing form 1448 of non-public-key-only based identity elements of a certificate 1449 such as a web servers domain name prefix often encoded in 1450 certificate common name. Steps 5 and 6 are the equivalent steps. 1452 Step 4 Constitutes standard CRL/OCSP checks refined for the case 1453 of missing connectivity and limited functionality security 1454 association protocols. 1456 Step 5 Checks for the presence of an ACP identity for the peer. 1458 Steps 1...5 authorize to build any secure connection between 1459 members of the same ACP domain except for ACP secure channels. 1461 Step 6 is the additional verification of the presence of an ACP 1462 address. 1464 Steps 1...6 authorize to build an ACP secure channel. 1466 For brevity, the remainder of this document refers to this process 1467 only as authentication instead of as authentication and 1468 authorization. 1470 6.1.3.1. Realtime clock and Time Validation 1472 An ACP node with a realtime clock in which it has confidence, MUST 1473 check the time stamps when performing ACP domain membership check 1474 such as as the certificate validity period in step 1. and the 1475 respective times in step 4 for revocation information (e.g.: 1476 signingTimes in CMS signatures). 1478 An ACP node without such a realtime clock MAY ignore those time stamp 1479 validation steps if it does not know the current time. Such an ACP 1480 node SHOULD obtain the current time in a secured fashion, such as via 1481 a Network Time Protocol signalled through the ACP. It then ignores 1482 time stamp validation only until the current time is known. In the 1483 absence of implementing a secured mechanism, such an ACP node MAY use 1484 a current time learned in an insecured fashion in the ACP domain 1485 membership check. 1487 Beside ACP domain membership check, the ACP itself has no dependency 1488 against knowledge of the current time, but protocols and services 1489 using the ACP will likley have the need to know the current time. 1490 For example event logging. 1492 6.1.4. Trust Anchors (TA) 1494 ACP nodes need TA information according to [RFC5280], section 6.1.1 1495 (d), typically in the form of one or more certificate of the TA to 1496 perform certificate path validation as required by Section 6.1.3, 1497 rule 2. TA information MUST be provisioned to an ACP node (together 1498 with its ACP domain certificate) by an ACP Registrar during initial 1499 enrolment of a candidate ACP node. ACP nodes MUST also support 1500 renewal of TA information via Enrollment over Secure Transport (EST, 1501 see [RFC7030]), as described below in Section 6.1.5. 1503 The required information about a TA can consist of not only a single, 1504 but multiple certificates as required for dealing with CA certificate 1505 renewals as explained in Section 4.4 of CMP ([RFC4210]). 1507 A certificate path is a chain of certificates starting at the ACP 1508 certificate (leaf/end-entity) followed by zero or more intermediate 1509 CA certificates and ending with the TA information, which are 1510 typically one or two the self-signed certificates of the TA. The CA 1511 that signs the ACP certificate is called the assigning CA. If there 1512 are no intermediate CA, then the assigning CA is the TA. Certificate 1513 path validation authenticates that the ACP certificate is permitted 1514 by a TA associated with the ACP, directly or indirectly via one or 1515 more intermediate CA. 1517 Note that different ACP nodes may have different intermediate CA in 1518 their certificate path and even different TA. The set of TA for an 1519 ACP domain must be consistent across all ACP members so that any ACP 1520 node can authenticate any other ACP node. The protocols through 1521 which ACP domain membership check rules 1-3 are performed need to 1522 support the exchange not only of the ACP nodes certificates, but also 1523 exchange of the intermedia TA. 1525 ACP nodes MUST support for the ACP domain membership check the 1526 certificate path validation with 0 or 1 intermediate CA. They SHOULD 1527 support 2 intermediate CA and two TA (to permit migration to from one 1528 TA to another TA). 1530 Certificates for an ACP MUST only be given to nodes that are allowed 1531 to be members of that ACP. When the signing CA relies on an ACP 1532 Registrar, the CA MUST only sign certificates with acp-node-name 1533 through trusted ACP Registrars. In this setup, any existing CA, 1534 unaware of the formatting of acp-node-name, can be used. 1536 These requirements can be achieved by using TA private to the owner 1537 of the ACP domain or potentially through appropriate contractual 1538 agreements between the involved parties (Registrar and CA). These 1539 requirements typically exclude public CA, because they in general do 1540 not support the notion of trusted registrars vouching for the 1541 correctness of the fields of a requested certificate or would by 1542 themselves not be capable to validate the correctness of otherName / 1543 AcpNodeName. 1545 A single owner can operate multiple independent ACP domains from the 1546 same set of TA. Registrars must then know which ACP a node needs to 1547 be enrolled into. 1549 6.1.5. Certificate and Trust Anchor Maintenance 1551 ACP nodes MUST support renewal of their Certificate and TA 1552 information via EST ("Enrollment over Secure Transport", see 1553 [RFC7030]) and MAY support other mechanisms. An ACP network MUST 1554 have at least one ACP node supporting EST server functionality across 1555 the ACP so that EST renewal is useable. 1557 ACP nodes SHOULD be able to remember the IPv6 locator parameters of 1558 the O_IPv6_LOCATOR in GRASP of the EST server from which they last 1559 renewed their ACP domain certificate. They SHOULD provide the 1560 ability for these EST server parameters to also be set by the ACP 1561 Registrar (see Section 6.10.7) that initially enrolled the ACP device 1562 with its ACP domain certificate. When BRSKI (see 1563 [I-D.ietf-anima-bootstrapping-keyinfra]) is used, the IPv6 locator of 1564 the BRSKI registrar from the BRSKI TLS connection SHOULD be 1565 remembered and used for the next renewal via EST if that registrar 1566 also announces itself as an EST server via GRASP (see next section) 1567 on its ACP address. 1569 The EST server MUST present a certificate that is passing ACP domain 1570 membership check in its TLS connection setup (Section 6.1.3, rules 1571 1..4, not rule 5 as this is not for an ACP secure channel setup). 1572 The EST server certificate MUST also contain the id-kp-cmcRA 1573 [RFC6402] extended key usage extension and the EST client MUST check 1574 its presence. 1576 The additional check against the id-kp-cmcRA extended key usage 1577 extension field ensures that clients do not fall prey to an illicit 1578 EST server. While such illicit EST servers should not be able to 1579 support certificate signing requests (as they are not able to elicit 1580 a signing response from a valid CA), such an illicit EST server would 1581 be able to provide faked CA certificates to EST clients that need to 1582 renew their CA certificates when they expire. 1584 Note that EST servers supporting multiple ACP domains will need to 1585 have for each of these ACP domains a separate certificate and respond 1586 on a different transport address (IPv6 address and/or TCP port), but 1587 this is easily automated on the EST server as long as the CA does not 1588 restrict registrars to request certificates with the id-kp-cmcRA 1589 extended usage extension for themselves. 1591 6.1.5.1. GRASP objective for EST server 1593 ACP nodes that are EST servers MUST announce their service via GRASP 1594 in the ACP through M_FLOOD messages. See [I-D.ietf-anima-grasp], 1595 section 2.8.11 for the definition of this message type: 1597 Example: 1599 [M_FLOOD, 12340815, h'fd89b714f3db0000200000064000001', 210000, 1600 [["SRV.est", 4, 255 ], 1601 [O_IPv6_LOCATOR, 1602 h'fd89b714f3db0000200000064000001', IPPROTO_TCP, 443]] 1603 ] 1605 Figure 3: GRASP SRV.est example 1607 The formal definition of the objective in Concise data definition 1608 language (CDDL) (see [RFC8610]) is as follows: 1610 flood-message = [M_FLOOD, session-id, initiator, ttl, 1611 +[objective, (locator-option / [])]] 1612 ; see example above and explanation 1613 ; below for initiator and ttl 1615 objective = ["SRV.est", objective-flags, loop-count, 1616 objective-value] 1618 objective-flags = sync-only ; as in GRASP spec 1619 sync-only = 4 ; M_FLOOD only requires synchronization 1620 loop-count = 255 ; recommended as there is no mechanism 1621 ; to discover network diameter. 1622 objective-value = any ; reserved for future extensions 1624 Figure 4: GRASP SRV.est definition 1626 The objective name "SRV.est" indicates that the objective is an 1627 [RFC7030] compliant EST server because "est" is an [RFC6335] 1628 registered service name for [RFC7030]. Objective-value MUST be 1629 ignored if present. Backward compatible extensions to [RFC7030] MAY 1630 be indicated through objective-value. Non [RFC7030] compatible 1631 certificate renewal options MUST use a different objective-name. 1632 Non-recognized objective-values (or parts thereof if it is a 1633 structure partially understood) MUST be ignored. 1635 The M_FLOOD message MUST be sent periodically. The default SHOULD be 1636 60 seconds, the value SHOULD be operator configurable but SHOULD be 1637 not smaller than 60 seconds. The frequency of sending MUST be such 1638 that the aggregate amount of periodic M_FLOODs from all flooding 1639 sources cause only negligible traffic across the ACP. The time-to- 1640 live (ttl) parameter SHOULD be 3.5 times the period so that up to 1641 three consecutive messages can be dropped before considering an 1642 announcement expired. In the example above, the ttl is 210000 msec, 1643 3.5 times 60 seconds. When a service announcer using these 1644 parameters unexpectedly dies immediately after sending the M_FLOOD, 1645 receivers would consider it expired 210 seconds later. When a 1646 receiver tries to connect to this dead service before this timeout, 1647 it will experience a failing connection and use that as an indication 1648 that the service instance is dead and select another instance of the 1649 same service instead (from another GRASP announcement). 1651 6.1.5.2. Renewal 1653 When performing renewal, the node SHOULD attempt to connect to the 1654 remembered EST server. If that fails, it SHOULD attempt to connect 1655 to an EST server learned via GRASP. The server with which 1656 certificate renewal succeeds SHOULD be remembered for the next 1657 renewal. 1659 Remembering the last renewal server and preferring it provides 1660 stickiness which can help diagnostics. It also provides some 1661 protection against off-path compromised ACP members announcing bogus 1662 information into GRASP. 1664 Renewal of certificates SHOULD start after less than 50% of the 1665 domain certificate lifetime so that network operations has ample time 1666 to investigate and resolve any problems that causes a node to not 1667 renew its domain certificate in time - and to allow prolonged periods 1668 of running parts of a network disconnected from any CA. 1670 6.1.5.3. Certificate Revocation Lists (CRLs) 1672 The ACP node SHOULD support revocation through CRL(s) via HTTP from 1673 one or more CRL Distribution Points (CRLDP). The CRLDP(s) MUST be 1674 indicated in the Domain Certificate when used. If the CRLDP URL uses 1675 an IPv6 address (ULA address when using the addressing rules 1676 specified in this document), the ACP node will connect to the CRLDP 1677 via the ACP. If the CRLDP uses a domain name, the ACP node will 1678 connect to the CRLDP via the Data-Plane. 1680 It is common to use domain names for CRLDP(s), but there is no 1681 requirement for the ACP to support DNS. Any DNS lookup in the Data- 1682 Plane is not only a possible security issue, but it would also not 1683 indicate whether the resolved address is meant to be reachable across 1684 the ACP. Therefore, the use of an IPv6 address versus the use of a 1685 DNS name doubles as an indicator whether or not to reach the CRLDP 1686 via the ACP. 1688 A CRLDP can be reachable across the ACP either by running it on a 1689 node with ACP or by connecting its node via an ACP connect interface 1690 (see Section 8.1). The CRLDP SHOULD use an ACP domain certificate 1691 for its HTTPs connections. The connecting ACP node SHOULD verify 1692 that the CRLDP certificate used during the HTTPs connection has the 1693 same ACP address as indicated in the CRLDP URL of the node's ACP 1694 domain certificate if the CRLDP URL uses an IPv6 address. 1696 6.1.5.4. Lifetimes 1698 Certificate lifetime may be set to shorter lifetimes than customary 1699 (1 year) because certificate renewal is fully automated via ACP and 1700 EST. The primary limiting factor for shorter certificate lifetimes 1701 is load on the EST server(s) and CA. It is therefore recommended 1702 that ACP domain certificates are managed via a CA chain where the 1703 assigning CA has enough performance to manage short lived 1704 certificates. See also Section 9.2.4 for discussion about an example 1705 setup achieving this. See also [I-D.ietf-acme-star]. 1707 When certificate lifetimes are sufficiently short, such as few hours, 1708 certificate revocation may not be necessary, allowing to simplify the 1709 overall certificate maintenance infrastructure. 1711 See Appendix A.2 for further optimizations of certificate maintenance 1712 when BRSKI can be used ("Bootstrapping Remote Secure Key 1713 Infrastructures", see [I-D.ietf-anima-bootstrapping-keyinfra]). 1715 6.1.5.5. Re-enrollment 1717 An ACP node may determine that its ACP domain certificate has 1718 expired, for example because the ACP node was powered down or 1719 disconnected longer than its certificate lifetime. In this case, the 1720 ACP node SHOULD convert to a role of a re-enrolling candidate ACP 1721 node. 1723 In this role, the node does maintain the TA and certificate chain 1724 associated with its ACP domain certificate exclusively for the 1725 purpose of re-enrollment, and attempts (or waits) to get re-enrolled 1726 with a new ACP certificate. The details depend on the mechanisms/ 1727 protocols used by the ACP Registrars. 1729 Please refer to Section 6.10.7 and 1730 [I-D.ietf-anima-bootstrapping-keyinfra] for explanations about ACP 1731 Registrars and vouchers as used in the following text. When ACP is 1732 intended to be used without BRSKI, the details about BRSKI and 1733 vouchers in the following text can be skipped. 1735 When BRSKI is used (i.e.: on ACP nodes that are ANI nodes), the re- 1736 enrolling candidate ACP node would attempt to enroll like a candidate 1737 ACP node (BRSKI pledge), but instead of using the ACP nodes IDevID 1738 certificate, it SHOULD first attempt to use its ACP domain 1739 certificate in the BRSKI TLS authentication. The BRSKI registrar MAY 1740 honor this certificate beyond its expiration date purely for the 1741 purpose of re-enrollment. Using the ACP node's domain certificate 1742 allows the BRSKI registrar to learn that node's acp-node-name, so 1743 that the BRSKI registrar can re-assign the same ACP address 1744 information to the ACP node in the new ACP domain certificate. 1746 If the BRSKI registrar denies the use of the old ACP domain 1747 certificate, the re-enrolling candidate ACP node MUST re-attempt re- 1748 enrollment using its IDevID certificate as defined in BRSKI during 1749 the TLS connection setup. 1751 Both when the BRSKI connection is attempted with the old ACP domain 1752 certificate or the IDevID certificate, the re-enrolling candidate ACP 1753 node SHOULD authenticate the BRSKI registrar during TLS connection 1754 setup based on its existing TA certificate chain information 1755 associated with its old ACP certificate. The re-enrolling candidate 1756 ACP node SHOULD only fall back to requesting a voucher from the BRSKI 1757 registrar when this authentication fails during TLS connection setup. 1759 When other mechanisms than BRSKI are used for ACP domain certificate 1760 enrollment, the principles of the re-enrolling candidate ACP node are 1761 the same. The re-enrolling candidate ACP node attempts to 1762 authenticate any ACP Registrar peers during re-enrollment protocol/ 1763 mechanisms via its existing certificate chain/TA information and 1764 provides its existing ACP domain certificate and other identification 1765 (such as the IDevID certificate) as necessary to the registrar. 1767 Maintaining existing TA information is especially important when 1768 enrollment mechanisms are used that unlike BRSKI do not leverage a 1769 voucher mechanism to authenticate the ACP registrar and where 1770 therefore the injection of certificate failures could otherwise make 1771 the ACP node easily attackable remotely. 1773 When using BRSKI or other protocol/mechanisms supporting vouchers, 1774 maintaining existing TA information allows for re-enrollment of 1775 expired ACP certificates to be more lightweight, especially in 1776 environments where repeated acquisition of vouchers during the 1777 lifetime of ACP nodes may be operationally expensive or otherwise 1778 undesirable. 1780 6.1.5.6. Failing Certificates 1782 An ACP domain certificate is called failing in this document, if/when 1783 the ACP node to which the certificate was issued can determine that 1784 it was revoked (or explicitly not renewed), or in the absence of such 1785 explicit local diagnostics, when the ACP node fails to connect to 1786 other ACP nodes in the same ACP domain using its ACP certificate. 1787 For connection failures to determine the ACP domain certificate as 1788 the culprit, the peer should pass the domain membership check 1789 (Section 6.1.3) and other reasons for the connection failure can be 1790 excluded because of the connection error diagnostics. 1792 This type of failure can happen during setup/refresh of a secure ACP 1793 channel connections or any other use of the ACP domain certificate, 1794 such as for the TLS connection to an EST server for the renewal of 1795 the ACP domain certificate. 1797 Example reasons for failing certificates that the ACP node can only 1798 discover through connection failure are that the domain certificate 1799 or any of its signing certificates could have been revoked or may 1800 have expired, but the ACP node cannot self-diagnose this condition 1801 directly. Revocation information or clock synchronization may only 1802 be available across the ACP, but the ACP node cannot build ACP secure 1803 channels because ACP peers reject the ACP node's domain certificate. 1805 ACP nodes SHOULD support the option to determines whether its ACP 1806 certificate is failing, and when it does, put itself into the role of 1807 a re-enrolling candidate ACP node as explained above 1808 (Section 6.1.5.5). 1810 6.2. ACP Adjacency Table 1812 To know to which nodes to establish an ACP channel, every ACP node 1813 maintains an adjacency table. The adjacency table contains 1814 information about adjacent ACP nodes, at a minimum: Node-ID 1815 (identifier of the node inside the ACP, see Section 6.10.3 and 1816 Section 6.10.5), interface on which neighbor was discovered (by GRASP 1817 as explained below), link-local IPv6 address of neighbor on that 1818 interface, certificate (including acp-node-name). An ACP node MUST 1819 maintain this adjacency table. This table is used to determine to 1820 which neighbor an ACP connection is established. 1822 Where the next ACP node is not directly adjacent (i.e., not on a link 1823 connected to this node), the information in the adjacency table can 1824 be supplemented by configuration. For example, the Node-ID and IP 1825 address could be configured. See Section 8.2. 1827 The adjacency table MAY contain information about the validity and 1828 trust of the adjacent ACP node's certificate. However, subsequent 1829 steps MUST always start with the ACP domain membership check against 1830 the peer (see Section 6.1.3). 1832 The adjacency table contains information about adjacent ACP nodes in 1833 general, independently of their domain and trust status. The next 1834 step determines to which of those ACP nodes an ACP connection should 1835 be established. 1837 6.3. Neighbor Discovery with DULL GRASP 1839 [RFC Editor: GRASP draft is in RFC editor queue, waiting for 1840 dependencies, including ACP. Please ensure that references to I- 1841 D.ietf-anima-grasp that include section number references (throughout 1842 this document) will be updated in case any last-minute changes in 1843 GRASP would make those section references change. 1845 Discovery Unsolicited Link-Local (DULL) GRASP is a limited subset of 1846 GRASP intended to operate across an insecure link-local scope. See 1847 section 2.5.2 of [I-D.ietf-anima-grasp] for its formal definition. 1848 The ACP uses one instance of DULL GRASP for every L2 interface of the 1849 ACP node to discover link level adjacent candidate ACP neighbors. 1850 Unless modified by policy as noted earlier (Section 5 bullet point 1851 2.), native interfaces (e.g., physical interfaces on physical nodes) 1852 SHOULD be initialized automatically to a state in which ACP discovery 1853 can be performed and any native interfaces with ACP neighbors can 1854 then be brought into the ACP even if the interface is otherwise not 1855 configured. Reception of packets on such otherwise not configured 1856 interfaces MUST be limited so that at first only IPv6 StateLess 1857 Address Auto Configuration (SLAAC - [RFC4862]) and DULL GRASP work 1858 and then only the following ACP secure channel setup packets - but 1859 not any other unnecessary traffic (e.g., no other link-local IPv6 1860 transport stack responders for example). 1862 Note that the use of the IPv6 link-local multicast address 1863 (ALL_GRASP_NEIGHBORS) implies the need to use Multicast Listener 1864 Discovery Version 2 (MLDv2, see [RFC3810]) to announce the desire to 1865 receive packets for that address. Otherwise DULL GRASP could fail to 1866 operate correctly in the presence of MLD snooping, non-ACP enabled L2 1867 switches ([RFC4541]) - because those would stop forwarding DULL GRASP 1868 packets. Switches not supporting MLD snooping simply need to operate 1869 as pure L2 bridges for IPv6 multicast packets for DULL GRASP to work. 1871 ACP discovery SHOULD NOT be enabled by default on non-native 1872 interfaces. In particular, ACP discovery MUST NOT run inside the ACP 1873 across ACP virtual interfaces. See Section 9.3 for further, non- 1874 normative suggestions on how to enable/disable ACP at node and 1875 interface level. See Section 8.2.2 for more details about tunnels 1876 (typical non-native interfaces). See Section 7 for how ACP should be 1877 extended on devices operating (also) as L2 bridges. 1879 Note: If an ACP node also implements BRSKI to enroll its ACP domain 1880 certificate (see Appendix A.2 for a summary), then the above 1881 considerations also apply to GRASP discovery for BRSKI. Each DULL 1882 instance of GRASP set up for ACP is then also used for the discovery 1883 of a bootstrap proxy via BRSKI when the node does not have a domain 1884 certificate. Discovery of ACP neighbors happens only when the node 1885 does have the certificate. The node therefore never needs to 1886 discover both a bootstrap proxy and ACP neighbor at the same time. 1888 An ACP node announces itself to potential ACP peers by use of the 1889 "AN_ACP" objective. This is a synchronization objective intended to 1890 be flooded on a single link using the GRASP Flood Synchronization 1891 (M_FLOOD) message. In accordance with the design of the Flood 1892 message, a locator consisting of a specific link-local IP address, IP 1893 protocol number and port number will be distributed with the flooded 1894 objective. An example of the message is informally: 1896 [M_FLOOD, 12340815, h'fe80000000000000c0011001feef0000', 210000, 1897 [["AN_ACP", 4, 1, "IKEv2" ], 1898 [O_IPv6_LOCATOR, 1899 h'fe80000000000000c0011001feef0000', IPPROTO_UDP, 15000]] 1900 [["AN_ACP", 4, 1, "DTLS" ], 1901 [O_IPv6_LOCATOR, 1902 h'fe80000000000000c0011001feef0000', IPPROTO_UDP, 17000]] 1903 ] 1905 Figure 5: GRASP AN_ACP example 1907 The formal CDDL definition is: 1909 flood-message = [M_FLOOD, session-id, initiator, ttl, 1910 +[objective, (locator-option / [])]] 1912 objective = ["AN_ACP", objective-flags, loop-count, 1913 objective-value] 1915 objective-flags = sync-only ; as in the GRASP specification 1916 sync-only = 4 ; M_FLOOD only requires synchronization 1917 loop-count = 1 ; limit to link-local operation 1918 objective-value = method 1919 method = "IKEv2" / "DTLS" ; or future standard methods 1921 Figure 6: GRASP AN_ACP definition 1923 The objective-flags field is set to indicate synchronization. 1925 The loop-count is fixed at 1 since this is a link-local operation. 1927 In the above example the RECOMMENDED period of sending of the 1928 objective is 60 seconds. The indicated ttl of 210000 msec means that 1929 the objective would be cached by ACP nodes even when two out of three 1930 messages are dropped in transit. 1932 The session-id is a random number used for loop prevention 1933 (distinguishing a message from a prior instance of the same message). 1934 In DULL this field is irrelevant but has to be set according to the 1935 GRASP specification. 1937 The originator MUST be the IPv6 link local address of the originating 1938 ACP node on the sending interface. 1940 The 'objective-value' parameter is a string indicating the protocol 1941 available at the specified or implied locator. It is a protocol 1942 supported by the node to negotiate a secure channel. IKEv2 as shown 1943 above is the protocol used to negotiate an IPsec secure channel. 1945 The locator-option is optional and only required when the secure 1946 channel protocol is not offered at a well-defined port number, or if 1947 there is no well-defined port number. 1949 IKEv2 is the actual protocol used to negotiate an Internet Protocol 1950 security architecture (IPsec) connection. GRASP therefore indicates 1951 "IKEv2" and not "IPsec". If "IPsec" was used, this too could mean 1952 use of the obsolete older version IKE (v1) ([RFC2409]). IKEv2 has am 1953 IANA assigned port number 500, but in the above example, the 1954 candidate ACP neighbor is offering ACP secure channel negotiation via 1955 IKEv2 on port 15000 (purely to show through the example that GRASP 1956 allows to indicate the port number and it does not have to be the 1957 IANA assigned one). 1959 "DTLS" indicates DTLS 1.2. This can also be a newer version of the 1960 protocol as long as it can negotiate down to version 1.2 in the 1961 presence of a peer only speaking DTLS 1.2. There is no default UDP 1962 port for DTLS, it is always locally assigned by the node. For 1963 details, see Section 6.7.4. 1965 If a locator is included, it MUST be an O_IPv6_LOCATOR, and the IPv6 1966 address MUST be the same as the initiator address (these are DULL 1967 requirements to minimize third party DoS attacks). 1969 The secure channel methods defined in this document use the 1970 objective-values of "IKEv2" and "DTLS". There is no distinction 1971 between IKEv2 native and GRE-IKEv2 because this is purely negotiated 1972 via IKEv2. 1974 A node that supports more than one secure channel protocol method 1975 needs to flood multiple versions of the "AN_ACP" objective so that 1976 each method can be accompanied by its own locator-option. This can 1977 use a single GRASP M_FLOOD message as shown in Figure 5. 1979 Note that a node serving both as an ACP node and BRSKI Join Proxy may 1980 choose to distribute the "AN_ACP" objective and the respective BRSKI 1981 in the same M_FLOOD message, since GRASP allows multiple objectives 1982 in one message. This may be impractical though if ACP and BRSKI 1983 operations are implemented via separate software modules / ASAs. 1985 The result of the discovery is the IPv6 link-local address of the 1986 neighbor as well as its supported secure channel protocols (and non- 1987 standard port they are running on). It is stored in the ACP 1988 Adjacency Table (see Section 6.2), which then drives the further 1989 building of the ACP to that neighbor. 1991 Note that the DULL GRASP objective described does intentionally not 1992 include ACP nodes ACP domain certificate even though this would be 1993 useful for diagnostics and to simplify the security exchange in ACP 1994 secure channel security association protocols (see Section 6.7). The 1995 reason is that DULL GRASP messages are periodically multicasted 1996 across IPv6 subnets and full certificates could easily lead to 1997 fragmented IPv6 DULL GRASP multicast packets due to the size of a 1998 certificate. This would be highly undesirable. 2000 6.4. Candidate ACP Neighbor Selection 2002 An ACP node determines to which other ACP nodes in the adjacency 2003 table it should attempt to build an ACP connection. This is based on 2004 the information in the ACP Adjacency table. 2006 The ACP is established exclusively between nodes in the same domain. 2007 This includes all routing subdomains. Appendix A.7 explains how ACP 2008 connections across multiple routing subdomains are special. 2010 The result of the candidate ACP neighbor selection process is a list 2011 of adjacent or configured autonomic neighbors to which an ACP channel 2012 should be established. The next step begins that channel 2013 establishment. 2015 6.5. Channel Selection 2017 To avoid attacks, initial discovery of candidate ACP peers cannot 2018 include any non-protected negotiation. To avoid re-inventing and 2019 validating security association mechanisms, the next step after 2020 discovering the address of a candidate neighbor can only be to try 2021 first to establish a security association with that neighbor using a 2022 well-known security association method. 2024 From the use-cases it seems clear that not all type of ACP nodes can 2025 or need to connect directly to each other or are able to support or 2026 prefer all possible mechanisms. For example, code space limited IoT 2027 devices may only support DTLS because that code exists already on 2028 them for end-to-end security, but low-end in-ceiling L2 switches may 2029 only want to support Media Access Control Security (MacSec, see 2030 802.1AE ([MACSEC]) because that is also supported in their chips. 2031 Only a flexible gateway device may need to support both of these 2032 mechanisms and potentially more. Note that MacSec is not required by 2033 any profiles of the ACP in this specification but just mentioned as a 2034 likely next interesting secure channel protocol. Note also that the 2035 security model allows and requires for any-to-any authentication and 2036 authorization between all ACP nodes because there is also end-to-end 2037 and not only hop-by-hop authentication for secure channels. 2039 To support extensible secure channel protocol selection without a 2040 single common mandatory to implement (MTI) protocol, ACP nodes MUST 2041 try all the ACP secure channel protocols it supports and that are 2042 feasible because the candidate ACP neighbor also announced them via 2043 its AN_ACP GRASP parameters (these are called the "feasible" ACP 2044 secure channel protocols). 2046 To ensure that the selection of the secure channel protocols always 2047 succeeds in a predictable fashion without blocking, the following 2048 rules apply: 2050 o An ACP node may choose to attempt to initiate the different 2051 feasible ACP secure channel protocols it supports according to its 2052 local policies sequentially or in parallel, but it MUST support 2053 acting as a responder to all of them in parallel. 2055 o Once the first secure channel protocol succeeds, the two peers 2056 know each other's certificates because they are used by all secure 2057 channel protocols for mutual authentication. The node with the 2058 lower Node-ID in the ACP address of its ACP domain certificate 2059 becomes Bob, the one with the higher Node-ID in the certificate 2060 Alice. A peer with an empty ACP address field in its ACP domain 2061 certificate becomes Bob (this specification does not define such 2062 peers, only the interoperability with them). 2064 o Bob becomes passive, he does not attempt to further initiate ACP 2065 secure channel protocols with Alice and does not consider it to be 2066 an error when Alice closes secure channels. Alice becomes the 2067 active party, continues to attempt setting up secure channel 2068 protocols with Bob until she arrives at the best one from her view 2069 that also works with Bob. 2071 For example, originally Bob could have been the initiator of one ACP 2072 secure channel protocol that Bob prefers and the security association 2073 succeeded. The roles of Bob and Alice are then assigned and the 2074 connection setup is completed. The protocol could for example be 2075 IPsec via IKEv2 ("IP security", see [RFC4301] and "Internet Key 2076 Exchange protocol version 2", see [RFC7296]. It is now up to Alice 2077 to decide how to proceed. Even if the IPsec connection from Bob 2078 succeeded, Alice might prefer another secure protocol over IPsec 2079 (e.g., FOOBAR), and try to set that up with Bob. If that preference 2080 of Alice succeeds, she would close the IPsec connection. If no 2081 better protocol attempt succeeds, she would keep the IPsec 2082 connection. 2084 The following sequence of steps show this example in more detail. 2085 Each step is tagged with [{:}]. The connection is 2086 included to easier distinguish which of the two competing connections 2087 the step belong to, one initiated by Node 1, one initiated by Node 2. 2089 [1] Node 1 sends GRASP AN_ACP message to announce itself 2091 [2] Node 2 sends GRASP AN_ACP message to announce itself 2093 [3] Node 2 receives [1] from Node 1 2095 [4:C1] Because of [3], Node 2 starts as initiator on its 2096 preferred secure channel protocol towards Node 1. 2097 Connection C1. 2099 [5] Node 1 receives [2] from Node 2 2101 [6:C2] Because of [5], Node 1 starts as initiator on its 2102 preferred secure channel protocol towards Node 2. 2103 Connection C2. 2105 [7:C1] Node1 and Node2 have authenticated each others 2106 certificate on connection C1 as valid ACP peers. 2108 [8:C1] Node 1 certificate has lower ACP Node-ID than Node2, 2109 therefore Node 1 considers itself Bob and Node 2 Alice 2110 on connection C1. Connection setup C1 is completed. 2112 [9] Node 1 (Bob)) refrains from attempting any further secure 2113 channel connections to Node 2 (Alice) as learned from [2] 2114 because it knows from [8:C1] that it is Bob relative 2115 to Node 1. 2117 [10:C2] Node1 and Node2 have authenticated each others 2118 certificate on connection C2 (like [7:C1]). 2120 [11:C2] Node 1 certificate has lower ACP Node-ID than Node2, 2121 therefore Node 1 considers itself Bob and Node 2 Alice 2122 on connection C2, but they also identify that C2 is to the 2123 same mutual peer as their C1, so this has no further impact: 2124 the roles Alice and Bob where already assigned between these 2125 two peers by [8:C1]. 2127 [12:C2] Node 2 (Alice) closes C1. Node 1 (Bob) is fine with this, 2128 because of his role as Bob (since [8:C1]). 2130 [13] Node 2 (Alice) and Node 1 (Bob) start data transfer across 2131 C2, which makes it become a secure channel for the ACP. 2133 Figure 7: Secure Channel sequence of steps 2135 All this negotiation is in the context of an "L2 interface". Alice 2136 and Bob will build ACP connections to each other on every "L2 2137 interface" that they both connect to. An autonomic node MUST NOT 2138 assume that neighbors with the same L2 or link-local IPv6 addresses 2139 on different L2 interfaces are the same node. This can only be 2140 determined after examining the certificate after a successful 2141 security association attempt. 2143 6.6. Candidate ACP Neighbor verification 2145 Independent of the security association protocol chosen, candidate 2146 ACP neighbors need to be authenticated based on their domain 2147 certificate. This implies that any secure channel protocol MUST 2148 support certificate based authentication that can support the ACP 2149 domain membership check as defined in Section 6.1.3. If it fails, 2150 the connection attempt is aborted and an error logged. Attempts to 2151 reconnect MUST be throttled. The RECOMMENDED default is exponential 2152 base 2 backoff with a minimum delay of 10 seconds and a maximum delay 2153 of 640 seconds. 2155 Failure to authenticate an ACP neighbor when acting in the role of a 2156 responder of the security authentication protocol MUST NOT impact the 2157 attempts of the ACP node to attempt establishing a connection as an 2158 initiator. Only failed connection attempts as an initiator must 2159 cause throttling. This rule is meant to increase resilience of 2160 secure channel creation. Section 6.5 shows how simultaneous mutual 2161 secure channel setup collisions are resolved. 2163 6.7. Security Association (Secure Channel) protocols 2165 This section describes how ACP nodes establish secured data 2166 connections to automatically discovered or configured peers in the 2167 ACP. Section 6.3 above described how IPv6 subnet adjacent peers are 2168 discovered automatically. Section 8.2 describes how non IPv6 subnet 2169 adjacent peers can be configured. 2171 Section 6.12.5.2 describes how secure channels are mapped to virtual 2172 IPv6 subnet interfaces in the ACP. The simple case is to map every 2173 ACP secure channel into a separate ACP point-to-point virtual 2174 interface Section 6.12.5.2.1. When a single subnet has multiple ACP 2175 peers this results in multiple ACP point-to-point virtual interfaces 2176 across that underlying multi-party IPv6 subnet. This can be 2177 optimized with ACP multi-access virtual interfaces Section 6.12.5.2.2 2178 but the benefits of that optimization may not justify the complexity 2179 of that option. 2181 6.7.1. General considerations 2183 Due to Channel Selection (Section 6.5), ACP can support an evolving 2184 set of security association protocols and does not require support 2185 for a single network wide MTI. ACP nodes only need to implement 2186 those protocols required to interoperate with their candidate peers, 2187 not with potentially any node in the ACP domain. See Section 6.7.5 2188 for an example of this. 2190 The degree of security required on every hop of an ACP network needs 2191 to be consistent across the network so that there is no designated 2192 "weakest link" because it is that "weakest link" that would otherwise 2193 become the designated point of attack. When the secure channel 2194 protection on one link is compromised, it can be used to send/receive 2195 packets across the whole ACP network. Therefore, even though the 2196 security association protocols can be different, their minimum degree 2197 of security should be comparable. 2199 Secure channel protocols do not need to always support arbitrary L3 2200 connectivity between peers, but can leverage the fact that the 2201 standard use case for ACP secure channels is an L2 adjacency. Hence, 2202 L2 dependent mechanisms could be adopted for use as secure channel 2203 association protocols: 2205 L2 mechanisms such as strong encrypted radio technologies or [MACSEC] 2206 may offer equivalent encryption and the ACP security association 2207 protocol may only be required to authenticate ACP domain membership 2208 of a peer and/or derive a key for the L2 mechanism. Mechanisms to 2209 auto-discover and associate ACP peers leveraging such underlying L2 2210 security are possible and desirable to avoid duplication of 2211 encryption, but none are specified in this document. 2213 Strong physical security of a link may stand in where cryptographic 2214 security is infeasible. As there is no secure mechanism to 2215 automatically discover strong physical security solely between two 2216 peers, it can only be used with explicit configuration and that 2217 configuration too could become an attack vector. This document 2218 therefore only specifies with ACP connect (Figure 15) one explicitly 2219 configured mechanism without any secure channel association protocol 2220 - for the case where both the link and the nodes attached to it have 2221 strong physical security. 2223 6.7.2. Common requirements 2225 The authentication of peers in any security association protocol MUST 2226 use the ACP domain certificate according to Section 6.1.3. Because 2227 auto-discovery of candidate ACP neighbors via GRASP (see Section 6.3) 2228 as specified in this document does not communicate the neighbors ACP 2229 domain certificate, and ACP nodes may not (yet) have any other 2230 network connectivity to retrieve certificates, any security 2231 association protocol MUST use a mechanism to communicate the 2232 certificate directly instead of relying on a referential mechanism 2233 such as communicating only a hash and/or URL for the certificate. 2235 A security association protocol MUST use Forward Secrecy (whether 2236 inherently or as part of a profile of the security association 2237 protocol). 2239 Because the ACP payload of legacy protocol payloads inside the ACP 2240 and hop-by-hop ACP flooded GRASP information is unencrypted, the ACP 2241 secure channel protocol requires confidentiality. Symmetric 2242 encryption for the transmission of secure channel data MUST use 2243 encryption schemes considered to be security wise equal to or better 2244 than AES256. There MUST NOT be support for NULL encryption. 2246 Security association protocols typically only signal the End Entity 2247 certificate (e.g.: the ACP domain certificate) and any possible 2248 intermediate CA certificates for successfull mutual authentication. 2249 The TA has to be mutually known and trusted and therefore its 2250 certificate does not need to be signalled for successful mutual 2251 authentication. Nevertheless, for use with ACP secure channel setup, 2252 there SHOULD be the option to include the TA certificate in the 2253 signaling to aid troubleshooting, see Section 9.1.1. 2255 Signalling of TA certificates may not be appropriate when the 2256 deployment is relying on a security model where the TA certificate 2257 content is considered confidential and only its hash is appropriate 2258 for signalling. ACP nodes SHOULD have a mechanism to select whether 2259 the TA certificate is signalled or not. Assuming that both options 2260 are possible with a specific secure channel protocol. 2262 An ACP secure channel MUST immediately be terminated when the 2263 lifetime of any certificate in the chain used to authenticate the 2264 neighbor expires or becomes revoked. This may not be standard 2265 behavior in secure channel protocols because the certificate 2266 authentication may only influences the setup of the secure channel in 2267 these protocols, but may not be re-validated during the lifetime of 2268 the secure connection in the absence of this requirement. 2270 When introducing the profile for a security association protocol in 2271 support of the ACP, protocol options SHOULD be eliminated that do not 2272 provide benefits for devices that should be able to support the ACP. 2273 For example, definitions for security protocols often include old/ 2274 inferior security options required only to interoperate with existing 2275 devices that will not be a able to update to the currently preferred 2276 security options. Such old/inferior security options do not need to 2277 be supported when a security association protocol is first specified 2278 for the ACP, strengthening the "weakest link" and simplifying ACP 2279 implementation overhead. 2281 6.7.3. ACP via IPsec 2283 An ACP node announces its ability to support IPsec, negotiated via 2284 IKEv2, as the ACP secure channel protocol using the "IKEv2" 2285 objective-value in the "AN_ACP" GRASP objective. 2287 The ACP usage of IPsec and IKEv2 mandates a profile with a narrow set 2288 of options of the current standards-track usage guidance for IPsec 2289 [RFC8221] and IKEv2 [RFC8247]. These option result in stringent 2290 security properties and can exclude deprecated/legacy algorithms 2291 because there is no need for interoperability with legacy equipment 2292 for ACP secure channels. Any such backward compatibility would lead 2293 only to increased attack surface and implementation complexity, for 2294 no benefit. 2296 6.7.3.1. Native IPsec 2298 An ACP node that is supporting native IPsec MUST use IPsec in tunnel 2299 mode, negotiated via IKEv2, and with IPv6 payload (e.g., ESP Next 2300 Header of 41). It MUST use local and peer link-local IPv6 addresses 2301 for encapsulation. Manual keying MUST NOT be used, see Section 6.1. 2302 Traffic Selectors are: 2304 TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 2306 TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 2308 IPsec tunnel mode is required because the ACP will route/forward 2309 packets received from any other ACP node across the ACP secure 2310 channels, and not only its own generated ACP packets. With IPsec 2311 transport mode (and no additional encapsulation header in the ESP 2312 payload), it would only be possible to send packets originated by the 2313 ACP node itself because the IPv6 addresses of the ESP must be the 2314 same as that of the outer IPv6 header. 2316 6.7.3.1.1. RFC8221 (IPsec/ESP) 2318 ACP IPsec implementations MUST comply with [RFC8221] (and its 2319 updates). The requirements from above and this section amend and 2320 superceed its requirements. 2322 AH MUST NOT be used (because it does not provide confidentiality). 2324 For the required ESP encryption algorithms in section 5 of [RFC8221] 2325 the following guidance applies: 2327 o ENCR_NULL AH MUST NOT be used (because it does not provide 2328 confidentiality). 2330 o ENCR_AES_GCM_16 is the only MTI ESP encryption algorithm for ACP 2331 via IPsec/ESP (it is already listed as MUST in [RFC8221]). 2333 o ENCR_AES_CBC and ENCR_AES_CCM_8 MAY be supported. If either 2334 provides higher performance than ENCR_AES_GCM_16 it SHOULD be 2335 supported. 2337 o ENCR_CHACHA20_POLY1305 SHOULD be supported at equal or higher 2338 performance than ENCR_AES_GCM_16. If that performance is not 2339 feasible, it MAY be supported. 2341 IKEv2 indicates an order for the offered algorithms. The algorithms 2342 SHOULD be ordered by performance. The first algorithm supported by 2343 both sides is generally choosen. 2345 Explanations: 2347 o There is no requirement to interoperate with legacy equipment in 2348 ACP secure channels, so a single MTI encryption algorithm for 2349 IPsec in ACP secure channels is sufficient for interoperability 2350 and allows for the most lightweight implementations. 2352 o ENCR_AES_GCM_16 is an authenticated encryption with associated 2353 data (AEAD) cipher mode, so no additional ESP authentication 2354 algorithm is needed, simplifying the MTI requirements of IPsec for 2355 the ACP. 2357 o There is no MTI requirement against support of ENCR_AES_CBC 2358 because ENCR_AES_GCM_16 is assumed to be feasible with less cost/ 2359 higher performance in modern devices hardware accelerated 2360 implementations compared to ENCR-AES_CBC. 2362 o ENCR_CHACHA20_POLY1305 is mandatory in [RFC8221] because of its 2363 target use as a fallback algorithm in case weaknesses in AES are 2364 uncoverered. Unfortunately, there is currently no way to 2365 automatically propagate across an ACP a policy to disallow use of 2366 AES based algorithms, so this target benefit of 2367 ENCR_CHACHA20_POLY1305 can not fully be adopted yet for the ACP. 2368 Therefore this algorithm is only recommended. Changing from AES 2369 to this algorithm at potentially big drop in performance could 2370 also render the ACP inoperable. Therefore the performance 2371 requirement against this algorithm so that it could become an 2372 effective security backup to AES for the ACP once a policy to 2373 switch over to it or prefer it is available in an ACP framework. 2375 [RFC8221] allows for 128-bit or 256-bit AES keys. This document 2376 mandates that only 256-bit AES keys MUST be supported. 2378 When [RFC8221] is updated, ACP implementations will need to consider 2379 legacy interoperability, and the IPsec WG has generally done a very 2380 good job of taking that into account in its recommendations. 2382 6.7.3.1.2. RFC8247 (IKEv2) 2384 [RFC8247] provides a baseline recommendation for mandatory to 2385 implement ciphers, integrity checks, pseudo-random-functions and 2386 Diffie-Hellman mechanisms. Those recommendations, and the 2387 recommendations of subsequent documents apply well to the ACP. 2388 Because IKEv2 for ACP secure channels is sufficient to be implemented 2389 in control plane software, rather than in ASIC hardware, and ACP 2390 nodes supporting IKEv2 are not assumed to be code-space constrained, 2391 and because existing IKEv2 implementations are expected to support 2392 [RFC8247] recommendations, this documents makes no attempt to 2393 simplify its recommendations for use with the ACP. 2395 This document does establish a policy statement as permitted by 2396 [RFC8247] for the specific case of ACP traffic. 2398 See [IKEV2IANA] for IANA IKEv2 parameter names used in this text. 2400 To signal the ACP domain certificate chain (including TA) as required 2401 by Section 6.7.2, "X.509 Certificate - Signature" payload in IKEv2 2402 can be used. It is mandatory according to [RFC7296] section 3.6. 2404 ACP nodes SHOULD set up IKEv2 to only use the ACP certificate and TA 2405 when acting as an IKEv2 responder on the IPv6 link local address and 2406 port number indicated in the AN_ACP DULL GRASP announcements (see 2407 Section 6.3). 2409 When CERTREQ is received from a peer, and does not indicate any of 2410 this ACP nodes TA certificates, the ACP node SHOULD ignore the 2411 CERTREQ and continue sending its certificate chain including its TA 2412 as subject to the requirements and explanations in Section 6.7.2. 2413 This will not result in successfull mutual authentication but assists 2414 diagnostics. 2416 Note that with IKEv2, failing authentication will only result in the 2417 responder receiving the certificate chain from the initiator, but not 2418 vice versa. Because ACP secure channel setup is symmetric (see 2419 Section 6.6), every non-malicious ACP neighbor will attempt to 2420 connect as an initiator though, allowing to obtain the diagnostic 2421 information about the neighbors certificate. 2423 In IKEv2, ACP nodes are identified by their ACP address. The 2424 ID_IPv6_ADDR IKEv2 identification payload MUST be used and MUST 2425 convey the ACP address. If the peer's ACP domain certificate 2426 includes an ACP address in the acp-node-name (not "0" or empty), the 2427 address in the IKEv2 identification payload MUST match it. See 2428 Section 6.1.3 for more information about "0" or empty ACP address 2429 fields in the acp-node-name. 2431 IKEv2 authentication MUST use authentication method 14 ("Digital 2432 Signature") for ACP certificates; this authentication method can be 2433 used with both RSA and ECDSA certificates, indicated by an ASN.1 2434 object AlgorithmIdentifier. 2436 The Digital Signature hash SHA2-512 MUST be supported (in addition to 2437 SHA2-256). 2439 The IKEv2 Diffie-Hellman key exchange group 19 (256-bit random ECP), 2440 listed as a SHOULD, is to be configured, along with the 2048-bit MODP 2441 (group 14). ECC provides a similar security level to finite-field 2442 (MODP) key exchange with a shorter key length, so is generally 2443 preferred absent other considerations. 2445 6.7.3.2. IPsec with GRE encapsulation 2447 In network devices it is often more common to implement high 2448 performance virtual interfaces on top of GRE encapsulation than on 2449 top of a "native" IPsec association (without any other encapsulation 2450 than those defined by IPsec). On those devices it may be beneficial 2451 to run the ACP secure channel on top of GRE protected by the IPsec 2452 association. 2454 The requirements for ESP/IPsec/IKEv2 with GRE are the same as for 2455 native IPsec (see Section 6.7.3.1) except that IPsec transport mode 2456 and next protocol GRE (47) are to be negotiated. Tunnel mode is not 2457 required because of GRE. Traffic Selectors are: 2459 TSi = (47, 0-65535, Initiator-IPv6-LL-addr ... Initiator-ACP-LL-addr) 2461 TSr = (47, 0-65535, Responder-IPv6-LL-addr ... Responder-IPv6-LL- 2462 addr) 2464 If IKEv2 initiator and responder support IPsec over GRE, it has to be 2465 preferred over native IPsec. The ACP IPv6 traffic has to be carried 2466 across GRE according to [RFC7676]. 2468 6.7.4. ACP via DTLS 2470 We define the use of ACP via DTLS in the assumption that it is likely 2471 the first transport encryption supported in some classes of 2472 constrained devices because DTLS is already used in those devices but 2473 IPsec is not, and code-space may be limited. 2475 An ACP node announces its ability to support DTLS v1.2 compliant with 2476 the requirements defined in this document as an ACP secure channel 2477 protocol in GRASP through the "DTLS" objective-value in the "AN_ACP" 2478 objective. 2480 To run ACP via UDP and DTLS v1.2 [RFC6347], a locally assigned UDP 2481 port is used that is announced as a parameter in the GRASP AN_ACP 2482 objective to candidate neighbors. This port can also be any newer 2483 version of DTLS as long as that version can negotiate a DTLS v1.2 2484 connection in the presence of an DTLS v1.2 only peer. 2486 All ACP nodes supporting DTLS as a secure channel protocol MUST 2487 adhere to the DTLS implementation recommendations and security 2488 considerations of BCP 195 [RFC7525] except with respect to the DTLS 2489 version. ACP nodes supporting DTLS MUST support DTLS 1.2. They MUST 2490 NOT support older versions of DTLS. Implementation MUST comply with 2491 BCP 195, [RFC7525]. 2493 Unlike for IPsec, no attempts are made to simplify the requirements 2494 of the BCP 195 recommendations because the expectation is that DTLS 2495 would be using software-only implementations where the ability to 2496 reuse of widely adopted implementations is more important than 2497 minizing the complexity of a hardware accelerated implementation 2498 which is known to be important for IPsec. 2500 DTLS v1.3 ([I-D.ietf-tls-dtls13]) is "backward compatible" with DTLS 2501 v1.2 (see section 1. of DTLS v1.3): A DTLS implementation supporting 2502 both DTLS v1.2 and DTLS v1.3 does comply with the above requirements 2503 of negoting to DTLS v1.2 in the presence of a DTLS v1.2 only peer, 2504 but using DTLS v1.3 when booth peers support it. 2506 Version v1.2 is the MTI version of DTLS in this specification because 2508 o There is more experience with DTLS v1.2 across the spectrum of 2509 target ACP nodes. 2511 o Firmware of lower end, embedded ACP nodes may not support a newer 2512 version for a long time. 2514 o There are significant changes of DTLS v1.3, such as a different 2515 record layer requiring time to gain implementation and deployment 2516 experience especially on lower end, code space limited devices. 2518 o The existing BCP [RFC7525] for DTLS v1.2 may equally take longer 2519 time to be updated with experience from a newer DTLS version. 2521 o There are no significant use-case relevant benefits of DTLS v1.3 2522 over DTLS v1.2 in the context of the ACP options for DTLS. For 2523 example, signaling performance improvements for session setup in 2524 DTLS v1.3 is not important for the ACP given the long-lived nature 2525 of ACP secure channel connections and the fact that DTLS 2526 connections are mostly link-local (short RTT). 2528 Nevertheless, newer versions of DTLS, such as DTLS v1.3 have more 2529 strict security requirements and use of the latest standard protocol 2530 version is for IETF security standards in general recommended. 2531 Therefore, ACP implementations are advised to support all the newer 2532 versions of DTLS that can still negotiate down to DTLS v1.2. 2534 [RFC-editor: if by the time of AUTH48, DTLS 1.3 would have evolved to 2535 be an RFC, then not only would the references to the DTLS v1.3 draft 2536 be changed to the RFC number, but that RFC is then going to be put 2537 into the normative list of references and the above paragraph is 2538 going to be amended to say: Implementations SHOULD support 2539 [DTLSv1.3-RFC]. This is not done right now, because there is no 2540 benefit in potentially waiting in RFC-editor queue for that RFC given 2541 how the text alreayd lays out a non-nrmative desire to support 2542 DTLSv1.3.] 2544 There is no additional session setup or other security association 2545 besides this simple DTLS setup. As soon as the DTLS session is 2546 functional, the ACP peers will exchange ACP IPv6 packets as the 2547 payload of the DTLS transport connection. Any DTLS defined security 2548 association mechanisms such as re-keying are used as they would be 2549 for any transport application relying solely on DTLS. 2551 6.7.5. ACP Secure Channel Profiles 2553 As explained in the beginning of Section 6.5, there is no single 2554 secure channel mechanism mandated for all ACP nodes. Instead, this 2555 section defines two ACP profiles (baseline and constrained) for ACP 2556 nodes that do introduce such requirements. 2558 A baseline ACP node MUST support IPsec natively and MAY support IPsec 2559 via GRE. If GRE is supported, it MAY be preferred over native IPec. 2560 A constrained ACP node that cannot support IPsec MUST support DTLS. 2561 An ACP node connecting an area of constrained ACP nodes with an area 2562 of baseline ACP nodes needs to support IPsec and DTLS and supports 2563 therefore the baseline and constrained profile. 2565 Explanation: Not all type of ACP nodes can or need to connect 2566 directly to each other or are able to support or prefer all possible 2567 secure channel mechanisms. For example, code space limited IoT 2568 devices may only support DTLS because that code exists already on 2569 them for end-to-end security, but high-end core routers may not want 2570 to support DTLS because they can perform IPsec in accelerated 2571 hardware but would need to support DTLS in an underpowered CPU 2572 forwarding path shared with critical control plane operations. This 2573 is not a deployment issue for a single ACP across these type of nodes 2574 as long as there are also appropriate gateway ACP nodes that support 2575 sufficiently many secure channel mechanisms to allow interconnecting 2576 areas of ACP nodes with a more constrained set of secure channel 2577 protocols. On the edge between IoT areas and high-end core networks, 2578 general-purpose routers that act as those gateways and that can 2579 support a variety of secure channel protocols is the norm already. 2581 IPsec natively with tunnel mode provides the shortest encapsulation 2582 overhead. GRE may be preferred by legacy implementations because the 2583 virtual interfaces required by ACP design in conjunction with secure 2584 channels have in the past more often been implemented for GRE than 2585 purely for native IPsec. 2587 ACP nodes need to specify in documentation the set of secure ACP 2588 mechanisms they support and should declare which profile they support 2589 according to above requirements. 2591 6.8. GRASP in the ACP 2593 6.8.1. GRASP as a core service of the ACP 2595 The ACP MUST run an instance of GRASP inside of it. It is a key part 2596 of the ACP services. The function in GRASP that makes it fundamental 2597 as a service of the ACP is the ability to provide ACP wide service 2598 discovery (using objectives in GRASP). 2600 ACP provides IP unicast routing via the RPL routing protocol (see 2601 Section 6.11). 2603 The ACP does not use IP multicast routing nor does it provide generic 2604 IP multicast services (the handling of GRASP link-local multicast 2605 messages is explained in Section 6.8.2). Instead, the ACP provides 2606 service discovery via the objective discovery/announcement and 2607 negotiation mechanisms of the ACP GRASP instance (services are a form 2608 of objectives). These mechanisms use hop-by-hop reliable flooding of 2609 GRASP messages for both service discovery (GRASP M_DISCOVERY 2610 messages) and service announcement (GRASP M_FLOOD messages). 2612 See Appendix A.5 for discussion about this design choice of the ACP. 2614 6.8.2. ACP as the Security and Transport substrate for GRASP 2616 In the terminology of GRASP ([I-D.ietf-anima-grasp]), the ACP is the 2617 security and transport substrate for the GRASP instance run inside 2618 the ACP ("ACP GRASP"). 2620 This means that the ACP is responsible for ensuring that this 2621 instance of GRASP is only sending messages across the ACP GRASP 2622 virtual interfaces. Whenever the ACP adds or deletes such an 2623 interface because of new ACP secure channels or loss thereof, the ACP 2624 needs to indicate this to the ACP instance of GRASP. The ACP exists 2625 also in the absence of any active ACP neighbors. It is created when 2626 the node has a domain certificate, and continues to exist even if all 2627 of its neighbors cease operation. 2629 In this case ASAs using GRASP running on the same node would still 2630 need to be able to discover each other's objectives. When the ACP 2631 does not exist, ASAs leveraging the ACP instance of GRASP via APIs 2632 MUST still be able to operate, and MUST be able to understand that 2633 there is no ACP and that therefore the ACP instance of GRASP cannot 2634 operate. 2636 The following explanation how ACP acts as the security and transport 2637 substrate for GRASP is visualized in Figure 8 below. 2639 GRASP unicast messages inside the ACP always use the ACP address. 2640 Link-local addresses from the ACP VRF MUST NOT be used inside 2641 objectives. GRASP unicast messages inside the ACP are transported 2642 via TLS which MUST comply with [RFC7525] execept that only TLS 1.2 2643 ([RFC5246]) is REQUIRED and TLS 1.3 ([RFC8446] is RECOMMENDED. There 2644 is no need for older version backward compatibility in the new use- 2645 case of ACP. Mutual authentication MUST use the ACP domain 2646 membership check defined in (Section 6.1.3). 2648 GRASP link-local multicast messages are targeted for a specific ACP 2649 virtual interface (as defined Section 6.12.5) but are sent by the ACP 2650 into an ACP GRASP virtual interface that is constructed from the TCP 2651 connection(s) to the IPv6 link-local neighbor address(es) on the 2652 underlying ACP virtual interface. If the ACP GRASP virtual interface 2653 has two or more neighbors, the GRASP link-local multicast messages 2654 are replicated to all neighbor TCP connections. 2656 TLS for GRASP MUST offer TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and 2657 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 and MUST NOT offer options 2658 with less than 256bit AES or less than SHA384. TLS for GRASP MUST 2659 also include the "Supported Elliptic Curves" extension, it MUST 2660 support support the NIST P-256 (secp256r1) and P-384 (secp384r1(24)) 2661 curves [RFC4492]. In addition, GRASP TLS clients SHOULD send an 2662 ec_point_formats extension with a single element, "uncompressed". 2663 For further interoperability recommendations, GRASP TLS 2664 implementations SHOULD follow [RFC7525]. 2666 TCP and TLS connections for GRASP in the ACP use the IANA assigned 2667 TCP port for GRASP (7107). Effectively the transport stack is 2668 expected to be TLS for connections from/to the ACP address (e.g., 2669 global scope address(es)) and TCP for connections from/to link-local 2670 addresses on the ACP virtual interfaces. The latter ones are only 2671 used for flooding of GRASP messages. 2673 ..............................ACP.............................. 2674 . . 2675 . /-GRASP-flooding-\ ACP GRASP instance . 2676 . / \ A 2677 . GRASP GRASP GRASP C 2678 . link-local unicast link-local P 2679 . multicast messages multicast . 2680 . messages | messages . 2681 . | | | . 2682 ............................................................... 2683 . v v v ACP security and transport . 2684 . | | | substrate for GRASP . 2685 . | | | . 2686 . | ACP GRASP | - ACP GRASP A 2687 . | Loopback | Loopback interface C 2688 . | interface | - ACP-cert auth P 2689 . | TLS | . 2690 . ACP GRASP | ACP GRASP - ACP GRASP virtual . 2691 . subnet1 | subnet2 virtual interfaces . 2692 . TCP | TCP . 2693 . | | | . 2694 ............................................................... 2695 . | | | ^^^ Users of ACP (GRASP/ASA) . 2696 . | | | ACP interfaces/addressing . 2697 . | | | . 2698 . | | | A 2699 . | ACP-Loopback Interf.| <- ACP Loopback interface C 2700 . | ACP-address | - address (global ULA) P 2701 . subnet1 | subnet2 <- ACP virtual interfaces . 2702 . link-local | link-local - link-local addresses . 2703 ............................................................... 2704 . | | | ACP VRF . 2705 . | RPL-routing | virtual routing and forwarding . 2706 . | /IP-Forwarding\ | A 2707 . | / \ | C 2708 . ACP IPv6 packets ACP IPv6 packets P 2709 . |/ \| . 2710 . IPsec/DTLS IPsec/DTLS - ACP-cert auth . 2711 ............................................................... 2712 | | Data-Plane 2713 | | 2714 | | - ACP secure channel 2715 link-local link-local - encapsulation addresses 2716 subnet1 subnet2 - Data-Plane interfaces 2717 | | 2718 ACP-Nbr1 ACP-Nbr2 2720 Figure 8: ACP as security and transport substrate for GRASP 2722 6.8.2.1. Discussion 2724 TCP encapsulation for GRASP M_DISCOVERY and M_FLOOD link local 2725 messages is used because these messages are flooded across 2726 potentially many hops to all ACP nodes and a single link with even 2727 temporary packet loss issues (e.g., WiFi/Powerline link) can reduce 2728 the probability for loss free transmission so much that applications 2729 would want to increase the frequency with which they send these 2730 messages. Such shorter periodic retransmission of datagrams would 2731 result in more traffic and processing overhead in the ACP than the 2732 hop-by-hop reliable retransmission mechanism by TCP and duplicate 2733 elimination by GRASP. 2735 TLS is mandated for GRASP non-link-local unicast because the ACP 2736 secure channel mandatory authentication and encryption protects only 2737 against attacks from the outside but not against attacks from the 2738 inside: Compromised ACP members that have (not yet) been detected and 2739 removed (e.g., via domain certificate revocation / expiry). 2741 If GRASP peer connections were to use just TCP, compromised ACP 2742 members could simply eavesdrop passively on GRASP peer connections 2743 for whom they are on-path ("Man In The Middle" - MITM) or intercept 2744 and modify them. With TLS, it is not possible to completely 2745 eliminate problems with compromised ACP members, but attacks are a 2746 lot more complex: 2748 Eavesdropping/spoofing by a compromised ACP node is still possible 2749 because in the model of the ACP and GRASP, the provider and consumer 2750 of an objective have initially no unique information (such as an 2751 identity) about the other side which would allow them to distinguish 2752 a benevolent from a compromised peer. The compromised ACP node would 2753 simply announce the objective as well, potentially filter the 2754 original objective in GRASP when it is a MITM and act as an 2755 application level proxy. This of course requires that the 2756 compromised ACP node understand the semantics of the GRASP 2757 negotiation to an extent that allows it to proxy it without being 2758 detected, but in an ACP environment this is quite likely public 2759 knowledge or even standardized. 2761 The GRASP TLS connections are run the same as any other ACP traffic 2762 through the ACP secure channels. This leads to double 2763 authentication/encryption, which has the following benefits: 2765 o Secure channel methods such as IPsec may provide protection 2766 against additional attacks, for example reset-attacks. 2768 o The secure channel method may leverage hardware acceleration and 2769 there may be little or no gain in eliminating it. 2771 o There is no different security model for ACP GRASP from other ACP 2772 traffic. Instead, there is just another layer of protection 2773 against certain attacks from the inside which is important due to 2774 the role of GRASP in the ACP. 2776 6.9. Context Separation 2778 The ACP is in a separate context from the normal Data-Plane of the 2779 node. This context includes the ACP channels' IPv6 forwarding and 2780 routing as well as any required higher layer ACP functions. 2782 In classical network system, a dedicated VRF is one logical 2783 implementation option for the ACP. If possible by the systems 2784 software architecture, separation options that minimize shared 2785 components are preferred, such as a logical container or virtual 2786 machine instance. The context for the ACP needs to be established 2787 automatically during bootstrap of a node. As much as possible it 2788 should be protected from being modified unintentionally by ("Data- 2789 Plane") configuration. 2791 Context separation improves security, because the ACP is not 2792 reachable from the Data-Plane routing or forwarding table(s). Also, 2793 configuration errors from the Data-Plane setup do not affect the ACP. 2795 6.10. Addressing inside the ACP 2797 The channels explained above typically only establish communication 2798 between two adjacent nodes. In order for communication to happen 2799 across multiple hops, the autonomic control plane requires ACP 2800 network wide valid addresses and routing. Each ACP node creates a 2801 Loopback interface with an ACP network wide unique address (prefix) 2802 inside the ACP context (as explained in in Section 6.9). This 2803 address may be used also in other virtual contexts. 2805 With the algorithm introduced here, all ACP nodes in the same routing 2806 subdomain have the same /48 ULA prefix. Conversely, ULA global IDs 2807 from different domains are unlikely to clash, such that two ACP 2808 networks can be merged, as long as the policy allows that merge. See 2809 also Section 10.1 for a discussion on merging domains. 2811 Links inside the ACP only use link-local IPv6 addressing, such that 2812 each node's ACP only requires one routable address prefix. 2814 6.10.1. Fundamental Concepts of Autonomic Addressing 2816 o Usage: Autonomic addresses are exclusively used for self- 2817 management functions inside a trusted domain. They are not used 2818 for user traffic. Communications with entities outside the 2819 trusted domain use another address space, for example normally 2820 managed routable address space (called "Data-Plane" in this 2821 document). 2823 o Separation: Autonomic address space is used separately from user 2824 address space and other address realms. This supports the 2825 robustness requirement. 2827 o Loopback-only: Only ACP Loopback interfaces (and potentially those 2828 configured for "ACP connect", see Section 8.1) carry routable 2829 address(es); all other interfaces (called ACP virtual interfaces) 2830 only use IPv6 link local addresses. The usage of IPv6 link local 2831 addressing is discussed in [RFC7404]. 2833 o Use-ULA: For Loopback interfaces of ACP nodes, we use ULA with L=1 2834 (as defined in section 3.1 of [RFC4193]). Note that the random 2835 hash for ACP Loopback addresses uses the definition in 2836 Section 6.10.2 and not the one of [RFC4193] section 3.2.2. 2838 o No external connectivity: They do not provide access to the 2839 Internet. If a node requires further reaching connectivity, it 2840 should use another, traditionally managed address scheme in 2841 parallel. 2843 o Addresses in the ACP are permanent, and do not support temporary 2844 addresses as defined in [RFC4941]. 2846 o Addresses in the ACP are not considered sensitive on privacy 2847 grounds because ACP nodes are not expected to be end-user host. 2848 All ACP nodes are in one (potentially federated) administrative 2849 domain. They are assumed to be to be candidate hosts of ACP 2850 traffic amongst each other or transit thereof. There are no 2851 transit nodes less privileged to know about the identity of other 2852 hosts in the ACP. Therefore, ACP addresses do not need to be 2853 pseudo-random as discussed in [RFC7721]. Because they are not 2854 propagated to untrusted (non ACP) nodes and stay within a domain 2855 (of trust), we also consider them not to be subject to scanning 2856 attacks. 2858 The ACP is based exclusively on IPv6 addressing, for a variety of 2859 reasons: 2861 o Simplicity, reliability and scale: If other network layer 2862 protocols were supported, each would have to have its own set of 2863 security associations, routing table and process, etc. 2865 o Autonomic functions do not require IPv4: Autonomic functions and 2866 autonomic service agents are new concepts. They can be 2867 exclusively built on IPv6 from day one. There is no need for 2868 backward compatibility. 2870 o OAM protocols do not require IPv4: The ACP may carry OAM 2871 protocols. All relevant protocols (SNMP, TFTP, SSH, SCP, Radius, 2872 Diameter, ...) are available in IPv6. See also [RFC8368] for how 2873 ACP could be made to interoperate with IPv4 only OAM. 2875 Further explanation about the addressing and routing related reasons 2876 for the choice of the autonomous ACP addressing can be found in 2877 Section 6.12.5.1. 2879 6.10.2. The ACP Addressing Base Scheme 2881 The Base ULA addressing scheme for ACP nodes has the following 2882 format: 2884 8 40 2 78 2885 +--+-------------------------+------+------------------------------+ 2886 |fd| hash(routing-subdomain) | Type | (sub-scheme) | 2887 +--+-------------------------+------+------------------------------+ 2889 Figure 9: ACP Addressing Base Scheme 2891 The first 48-bits follow the ULA scheme, as defined in [RFC4193], to 2892 which a type field is added: 2894 o "fd" identifies a locally defined ULA address. 2896 o The 40-bits ULA "global ID" (term from [RFC4193]) for ACP 2897 addresses carried in the acp-node-name in the ACP domain 2898 certificates are the first 40-bits of the SHA256 hash of the 2899 routing subdomain from the same acp-node-name. In the example of 2900 Section 6.1.2, the routing subdomain is 2901 "area51.research.acp.example.com" and the 40-bits ULA "global ID" 2902 89b714f3db. 2904 o When creating a new routing-subdomain for an existing autonomic 2905 network, it MUST be ensured, that rsub is selected so the 2906 resulting hash of the routing-subdomain does not collide with the 2907 hash of any pre-existing routing-subdomains of the autonomic 2908 network. This ensures that ACP addresses created by registrars 2909 for different routing subdomains do not collide with each others. 2911 o To allow for extensibility, the fact that the ULA "global ID" is a 2912 hash of the routing subdomain SHOULD NOT be assumed by any ACP 2913 node during normal operations. The hash function is only executed 2914 during the creation of the certificate. If BRSKI is used then the 2915 BRSKI registrar will create the acp-node-name in response to the 2916 EST Certificate Signing Request (CSR) Attribute Request message by 2917 the pledge. 2919 o Establishing connectivity between different ACP (different acp- 2920 domain-name) is outside the scope of this specification. If it is 2921 being done through future extensions, then the rsub of all 2922 routing-subdomains across those autonomic networks need to be 2923 selected so the resulting routing-subdomain hashes do not collide. 2924 For example a large cooperation with its own private TA may want 2925 to create different autonomic networks that initially should not 2926 be able to connect but where the option to do so should be kept 2927 open. When taking this future possibility into account, it is 2928 easy to always select rsub so that no collisions happen. 2930 o Type: This field allows different address sub-schemes. This 2931 addresses the "upgradability" requirement. Assignment of types 2932 for this field will be maintained by IANA. 2934 The sub-scheme may imply a range or set of addresses assigned to the 2935 node, this is called the ACP address range/set and explained in each 2936 sub-scheme. 2938 Please refer to Section 6.10.7 and Appendix A.1 for further 2939 explanations why the following Sub-Addressing schemes are used and 2940 why multiple are necessary. 2942 The following summarizes the addressing Sub-Schemes: 2944 +------+-----+-----------------+-------+------------+ 2945 | Type | Z | name | F-bit | V-bit size | 2946 +------+-----+-----------------+-------+------------+ 2947 | 0x00 | 0 | ACP-Zone | N/A | 1 bit | 2948 +------+-----+-----------------+-------+------------+ 2949 | 0x00 | 1 | ACP-Manual | N/A | 1 bit | 2950 +------+-----+-----------------+-------+------------+ 2951 | 0x01 | N/A | ACP-VLong-8 | 0 | 8 bits | 2952 +------+-----+-----------------+-------+------------+ 2953 | 0x01 | N/A | ACP-VLong-16 | 1 | 16 bits | 2954 +------+-----+-----------------+-------+------------+ 2956 Figure 10: Addressing schemes 2958 6.10.3. ACP Zone Addressing Sub-Scheme (ACP-Zone) 2960 This sub-scheme is used when the Type field of the base scheme is 2961 0x00 and the Z bit is 0x0. 2963 64 64 2964 +-----------------+---+---------++-----------------------------+---+ 2965 | (base scheme) | Z | Zone-ID || Node-ID | 2966 | | | || Registrar-ID | Node-Number| V | 2967 +-----------------+---+---------++--------------+--------------+---+ 2968 50 1 13 48 15 1 2970 Figure 11: ACP Zone Addressing Sub-Scheme 2972 The fields are defined as follows: 2974 o Type: MUST be 0x0. 2976 o Z: MUST be 0x0. 2978 o Zone-ID: A value for a network zone. 2980 o Node-ID: A unique value for each node. 2982 The 64-bit Node-ID must be unique across the ACP domain for each 2983 node. It is derived and composed as follows: 2985 o Registrar-ID (48-bit): A number unique inside the domain that 2986 identifies the ACP registrar which assigned the Node-ID to the 2987 node. One or more domain-wide unique identifiers of the ACP 2988 registrar can be used for this purpose. See Section 6.10.7.2. 2990 o Node-Number: Number to make the Node-ID unique. This can be 2991 sequentially assigned by the ACP Registrar owning the Registrar- 2992 ID. 2994 o V (1-bit): Virtualization bit: 0: Indicates the ACP itself ("ACP 2995 node base system); 1: Indicates the optional "host" context on the 2996 ACP node (see below). 2998 In the ACP Zone Addressing Sub-Scheme, the ACP address in the 2999 certificate has V field as all zero bits. 3001 The ACP address set of the node includes addresses with any Zone-ID 3002 value and any V value. No two nodes in the same ACP can have the 3003 same Node-ID, but differerent Zone-IDs. 3005 The Virtual bit in this sub-scheme allows the easy addition of the 3006 ACP as a component to existing systems without causing problems in 3007 the port number space between the services in the ACP and the 3008 existing system. V:0 is the ACP router (autonomic node base system), 3009 V:1 is the host with pre-existing transport endpoints on it that 3010 could collide with the transport endpoints used by the ACP router. 3011 The ACP host could for example have a p2p virtual interface with the 3012 V:0 address as its router into the ACP. Depending on the software 3013 design of ASAs, which is outside the scope of this specification, 3014 they may use the V:0 or V:1 address. 3016 The location of the V bit(s) at the end of the address allows the 3017 announcement of a single prefix for each ACP node. For example, in a 3018 network with 20,000 ACP nodes, this avoid 20,000 additional routes in 3019 the routing table. 3021 It is RECOMMENDED that only Zone-ID 0 is used unless it is meant to 3022 be used in conjunction with operational practices for partial/ 3023 incremental adoption of the ACP as described in Section 9.4. 3025 Note: Zones and Zone-ID as defined here are not related to [RFC4007] 3026 zones or zone_id. ACP zone addresses are not scoped (reachable only 3027 from within an RFC4007 zone) but reachable across the whole ACP. An 3028 RFC4007 zone_id is a zone index that has only local significance on a 3029 node, whereas an ACP Zone-ID is an identifier for an ACP zone that is 3030 unique across that ACP. 3032 6.10.4. ACP Manual Addressing Sub-Scheme (ACP-Manual) 3034 This sub-scheme is used when the Type field of the base scheme is 3035 0x00 and the Z bit is 0x1. 3037 64 64 3038 +---------------------+---+----------++-----------------------------+ 3039 | (base scheme) | Z | Subnet-ID|| Interface Identifier | 3040 +---------------------+---+----------++-----------------------------+ 3041 50 1 13 3043 Figure 12: ACP Manual Addressing Sub-Scheme 3045 The fields are defined as follows: 3047 o Type: MUST be 0x0. 3049 o Z: MUST be 0x1. 3051 o Subnet-ID: Configured subnet identifier. 3053 o Interface Identifier. 3055 This sub-scheme is meant for "manual" allocation to subnets where the 3056 other addressing schemes cannot be used. The primary use case is for 3057 assignment to ACP connect subnets (see Section 8.1.1). 3059 "Manual" means that allocations of the Subnet-ID need to be done 3060 today with pre-existing, non-autonomic mechanisms. Every subnet that 3061 uses this addressing sub-scheme needs to use a unique Subnet-ID 3062 (unless some anycast setup is done). 3064 The Z bit field was added to distinguish Zone addressing and manual 3065 addressing sub-schemes without requiring one more bit in the base 3066 scheme and therefore allowing for the Vlong scheme (described below) 3067 to have one more bit available. 3069 Manual addressing sub-scheme addresses SHOULD NOT be used in ACP 3070 domain certificates. Any node capable to build ACP secure channels 3071 and permitted by Registrar policy to participate in building ACP 3072 secure channels SHOULD receive an ACP address (prefix) from one of 3073 the other ACP addressing sub-schemes. Nodes not capable (or 3074 permitted) to participate in ACP secure channels can connect to the 3075 ACP via ACP connect interfaces of ACP edge nodes (see Section 8.1), 3076 without setting up an ACP secure channel. Their ACP domain 3077 certificate MUST include an empty acp-address to indicate that their 3078 ACP domain certificate is only usable for non- ACP secure channel 3079 authentication, such as end-to-end transport connections across the 3080 ACP or Data-Plane. 3082 Address management of ACP connect subnets is done using traditional 3083 assignment methods and existing IPv6 protocols. See Section 8.1.3 3084 for details. 3086 6.10.5. ACP Vlong Addressing Sub-Scheme (ACP-VLong-8/ACP-VLong-16 3088 This sub-scheme is used when the Type field of the base scheme is 3089 0x01. 3091 50 78 3092 +---------------------++-----------------------------+----------+ 3093 | (base scheme) || Node-ID | 3094 | || Registrar-ID |F| Node-Number| V | 3095 +---------------------++--------------+--------------+----------+ 3096 50 46 1 23/15 8/16 3098 Figure 13: ACP Vlong Addressing Sub-Scheme 3100 This addressing scheme foregoes the Zone-ID field to allow for 3101 larger, flatter routed networks (e.g., as in IoT) with 8421376 Node- 3102 Numbers (2^23+2^15). It also allows for up to 2^16 (i.e. 65536) 3103 different virtualized addresses within a node, which could be used to 3104 address individual software components in an ACP node. 3106 The fields are the same as in the Zone-ID sub-scheme with the 3107 following refinements: 3109 o F: format bit. This bit determines the format of the subsequent 3110 bits. 3112 o V: Virtualization bit: this is a field that is either 8 or 16 3113 bits. For F=0, it is 8 bits, for F=1 it is 16 bits. The V bits 3114 are assigned by the ACP node. In the ACP certificate's ACP 3115 address Section 6.1.2, the V-bits are always set to 0. 3117 o Registrar-ID: To maximize Node-Number and V, the Registrar-ID is 3118 reduced to 46-bits. One or more domain-wide unique identifiers of 3119 the ACP registrar can be used for this purpose. See 3120 Section 6.10.7.2. 3122 o The Node-Number is unique to each ACP node. There are two formats 3123 for the Node-Number. When F=0, the node-number is 23 bits, for 3124 F=1 it is 15 bits. Each format of node-number is considered to be 3125 in a unique number space. 3127 The F=0 bit format addresses are intended to be used for "general 3128 purpose" ACP nodes that would potentially have a limited number (< 3129 256) of clients (ASA/Autonomic Functions or legacy services) of the 3130 ACP that require separate V(irtual) addresses. 3132 The F=1 bit Node-Numbers are intended for ACP nodes that are ACP edge 3133 nodes (see Section 8.1.1) or that have a large number of clients 3134 requiring separate V(irtual) addresses. For example large SDN 3135 controllers with container modular software architecture (see 3136 Section 8.1.2). 3138 In the Vlong addressing sub-scheme, the ACP address in the 3139 certificate has all V field bits as zero. The ACP address set for 3140 the node includes any V value. 3142 6.10.6. Other ACP Addressing Sub-Schemes 3144 Before further addressing sub-schemes are defined, experience with 3145 the schemes defined here should be collected. The schemes defined in 3146 this document have been devised to allow hopefully sufficiently 3147 flexible setup of ACPs for a variety of situation. These reasons 3148 also lead to the fairly liberal use of address space: The Zone 3149 Addressing Sub-Scheme is intended to enable optimized routing in 3150 large networks by reserving bits for Zone-ID's. The Vlong addressing 3151 sub-scheme enables the allocation of 8/16-bit of addresses inside 3152 individual ACP nodes. Both address spaces allow distributed, 3153 uncoordinated allocation of node addresses by reserving bits for the 3154 registrar-ID field in the address. 3156 IANA is asked need to assign a new "type" for each new addressing 3157 sub-scheme. With the current allocations, only 2 more schemes are 3158 possible, so the last addressing scheme MUST provide further 3159 extensions (e.g., by reserving bits from it for further extensions). 3161 6.10.7. ACP Registrars 3163 ACP registrars are responsible to enroll candidate ACP nodes with ACP 3164 domain certificates and associated trust point(s). They are also 3165 responsible that an acp-node-name field is included in the ACP domain 3166 certificate carrying the ACP domain name and the ACP nodes ACP 3167 address prefix. This address prefix is intended to persist unchanged 3168 through the lifetime of the ACP node. 3170 Because of the ACP addressing sub-schemes, an ACP domain can have 3171 multiple distributed ACP registrars that do not need to coordinate 3172 for address assignment. ACP registrars can also be sub-CAs, in which 3173 case they can also assign ACP domain certificates without 3174 dependencies against a (shared) TA (except during renewals of their 3175 own certificates). 3177 ACP registrars are PKI registration authorities (RA) enhanced with 3178 the handling of the ACP domain certificate specific fields. They 3179 request certificates for ACP nodes from a Certification Authority 3180 through any appropriate mechanism (out of scope in this document, but 3181 required to be BRSKI for ANI registrars). Only nodes that are 3182 trusted to be compliant with the requirements against registrar 3183 described in this section can be given the necessary credentials to 3184 perform this RA function, such as credentials for the BRSKI 3185 connection to the CA for ANI registrars. 3187 6.10.7.1. Use of BRSKI or other Mechanism/Protocols 3189 Any protocols or mechanisms may be used as ACP registrars, as long as 3190 the resulting ACP certificate and TA certificate(s) allow to perform 3191 the ACP domain membership described in Section 6.1.3 with other ACP 3192 domain members, and meet the ACP addressing requirements for its acp- 3193 node-name as described further below in this section. 3195 An ACP registrar could be a person deciding whether to enroll a 3196 candidate ACP node and then orchestrating the enrollment of the ACP 3197 certificate and associated TA, using command line or web based 3198 commands on the candidate ACP node and TA to generate and sign the 3199 ACP domain certificate and configure certificate and TA onto the 3200 node. 3202 The only currently defined protocol for ACP registrars is BRSKI 3203 ([I-D.ietf-anima-bootstrapping-keyinfra]). When BRSKI is used, the 3204 ACP nodes are called ANI nodes, and the ACP registrars are called 3205 BRSKI or ANI registrars. The BRSKI specification does not define the 3206 handling of the acp-node-name field because the rules do not depend 3207 on BRSKI but apply equally to any protocols/mechanisms an ACP 3208 registrar may use. 3210 6.10.7.2. Unique Address/Prefix allocation 3212 ACP registrars MUST NOT allocate ACP address prefixes to ACP nodes 3213 via the acp-node-name that would collide with the ACP address 3214 prefixes of other ACP nodes in the same ACP domain. This includes 3215 both prefixes allocated by the same ACP registrar to different ACP 3216 nodes as well as prefixes allocated by other ACP registrars for the 3217 same ACP domain. 3219 To support such unique address allocation, an ACP registrar MUST have 3220 one or more 46-bit identifiers unique across the ACP domain which is 3221 called the Registrar-ID. Allocation of Registrar-ID(s) to an ACP 3222 registrar can happen through OAM mechanisms in conjunction with some 3223 database / allocation orchestration. 3225 ACP registrars running on physical devices with known globally unique 3226 EUI-48 MAC address(es) can use the lower 46 bits of those address(es) 3227 as unique Registrar-IDs without requiring any external signaling/ 3228 configuration (the upper two bits, V and U are not uniquely assigned 3229 but functional). This approach is attractive for distributed, non- 3230 centrally administered, lightweight ACP registrar implementations. 3231 There is no mechanism to deduce from a MAC address itself whether it 3232 is actually uniquely assigned. Implementations need to consult 3233 additional offline information before making this assumption. For 3234 example by knowing that a particular physical product/MIC-chip is 3235 guaranteed to use globally unique assigned EUI-48 MAC address(es). 3237 When the candidate ACP device (called Pledge in BRSKI) is to be 3238 enrolled into an ACP domain, the ACP registrar needs to allocate a 3239 unique ACP address to the node and ensure that the ACP certificate 3240 gets a acp-node-name field (Section 6.1.2) with the appropriate 3241 information - ACP domain-name, ACP-address, and so on. If the ACP 3242 registrar uses BRSKI, it signals the ACP acp-node-name field to the 3243 Pledge via the EST /csrattrs command (see 3244 [I-D.ietf-anima-bootstrapping-keyinfra], section 5.9.2 - "EST CSR 3245 Attributes"). 3247 [RFC Editor: please update reference to section 5.9.2 accordingly 3248 with latest BRSKI draft at time of publishing, or RFC] 3250 6.10.7.3. Addressing Sub-Scheme Policies 3252 The ACP registrar selects for the candidate ACP node a unique address 3253 prefix from an appropriate ACP addressing sub-scheme, either a zone 3254 addressing sub-scheme prefix (see Section 6.10.3), or a Vlong 3255 addressing sub-scheme prefix (see Section 6.10.5). The assigned ACP 3256 address prefix encoded in the acp-node-name field of the ACP domain 3257 certificate indicates to the ACP node its ACP address information. 3258 The sub-addressing scheme indicates the prefix length: /127 for zone 3259 address sub-scheme, /120 or /112 for Vlong address sub-scheme. The 3260 first address of the prefix is the ACP address. All other addresses 3261 in the prefix are for other uses by the ACP node as described in the 3262 zone and Vlong addressing sub scheme sections. The ACP address 3263 prefix itself is then signaled by the ACP node into the ACP routing 3264 protocol (see Section 6.11) to establish IPv6 reachability across the 3265 ACP. 3267 The choice of addressing sub-scheme and prefix-length in the Vlong 3268 address sub-scheme is subject to ACP registrar policy. It could be 3269 an ACP domain wide policy, or a per ACP node or per ACP node type 3270 policy. For example, in BRSKI, the ACP registrar is aware of the 3271 IDevID certificate of the candidate ACP node, which contains a 3272 "serialNnumber" that is typically indicating the node's vendor and 3273 device type and can be used to drive a policy selecting an 3274 appropriate addressing sub-scheme for the (class of) node(s). 3276 ACP registrars SHOULD default to allocate ACP zone sub-address scheme 3277 addresses with Zone-ID 0. 3279 ACP registrars that are aware of can use the IDevID certificate of a 3280 candidate ACP device SHOULD be able to choose the zone vs. Vlong sub- 3281 address scheme for ACP nodes based on the "serialNumber" of the 3282 IDevID certificate, for example by the PID (Product Identifier) part 3283 which identifies the product type, or the complete "serialNumber". 3285 In a simple allocation scheme, an ACP registrar remembers 3286 persistently across reboots its currently used Registrar-ID and for 3287 each addressing scheme (Zone with Zone-ID 0, Vlong with /112, Vlong 3288 with /120), the next Node-Number available for allocation and 3289 increases it during successful enrollment to an ACP node. In this 3290 simple allocation scheme, the ACP registrar would not recycle ACP 3291 address prefixes from no longer used ACP nodes. 3293 6.10.7.4. Address/Prefix Persistence 3295 When an ACP domain certificate is renewed or rekeyed via EST or other 3296 mechanisms, the ACP address/prefix in the acp-node-name field MUST be 3297 maintained unless security issues or violations of the unique address 3298 assignment requirements exist or are suspected by the ACP registrar. 3300 ACP address information SHOULD be maintained even when the renewing/ 3301 rekeying ACP registrar is not the same as the one that enrolled the 3302 prior ACP certificate. See Section 9.2.4 for an example. 3304 ACP address information SHOULD also be maintained even after an ACP 3305 certificate did expire or failed. See Section 6.1.5.5 and 3306 Section 6.1.5.6. 3308 6.10.7.5. Further Details 3310 Section 9.2 discusses further informative details of ACP registrars: 3311 What interactions registrars need, what parameters they require, 3312 certificate renewal and limitations, use of sub-CAs on registrars and 3313 centralized policy control. 3315 6.11. Routing in the ACP 3317 Once ULA address are set up all autonomic entities should run a 3318 routing protocol within the autonomic control plane context. This 3319 routing protocol distributes the ULA created in the previous section 3320 for reachability. The use of the autonomic control plane specific 3321 context eliminates the probable clash with Data-Plane routing tables 3322 and also secures the ACP from interference from the configuration 3323 mismatch or incorrect routing updates. 3325 The establishment of the routing plane and its parameters are 3326 automatic and strictly within the confines of the autonomic control 3327 plane. Therefore, no explicit configuration is required. 3329 All routing updates are automatically secured in transit as the 3330 channels of the ACP are encrypted, and this routing runs only inside 3331 the ACP. 3333 The routing protocol inside the ACP is RPL ([RFC6550]). See 3334 Appendix A.4 for more details on the choice of RPL. 3336 RPL adjacencies are set up across all ACP channels in the same domain 3337 including all its routing subdomains. See Appendix A.7 for more 3338 details. 3340 6.11.1. ACP RPL Profile 3342 The following is a description of the RPL profile that ACP nodes need 3343 to support by default. The format of this section is derived from 3344 draft-ietf-roll-applicability-template. 3346 6.11.1.1. Overview 3348 RPL Packet Information (RPI) defined in [RFC6550], section 11.2 3349 defines the data packet artefacts required or beneficial in 3350 forwarding of packets routed by RPL. This profile does not use RPI 3351 for better compatibility with accelerated hardware forwarding planes 3352 which most often does not support the Hop-by-Hop headers used for 3353 RPI, but also to avoid the overhead of the RPI header on the wire and 3354 cost of adding/removing them. 3356 6.11.1.1.1. Single Instance 3358 To avoid the need for RPI, the ACP RPL profile uses a simple 3359 destination prefix based routing/forwarding table. To achieve this, 3360 the profiles uses only one RPL instanceID. This single instanceID 3361 can contain only one Destination Oriented Directed Acyclic Graph 3362 (DODAG), and the routing/forwarding table can therefore only 3363 calculate a single class of service ("best effort towards the primary 3364 NOC/root") and cannot create optimized routing paths to accomplish 3365 latency or energy goals between any two nodes. 3367 This choice is a compromise. Consider a network that has multiple 3368 NOCs in different locations. Only one NOC will become the DODAG 3369 root. Traffic to and from other NOCs has to be sent through the 3370 DODAG (shortest path tree) rooted in the primary NOC. Depending on 3371 topology, this can be an annoyance from a latency point of view or 3372 from minimizing network path resources, but this is deemed to be 3373 acceptable given how ACP traffic is "only" network management/control 3374 traffic. See Appendix A.10.4 for more details. 3376 Using a single instanceID/DODAG does not introduce a single point of 3377 failure, as the DODAG will reconfigure itself when it detects Data- 3378 Plane forwarding failures including choosing a different root when 3379 the primary one fails. 3381 The benefit of this profile, especially compared to other IGPs is 3382 that it does not calculate routes for node reachable through the same 3383 interface as the DODAG root. This RPL profile can therefore scale to 3384 much larger number of ACP nodes in the same amount of compute and 3385 memory than other routing protocols. Especially on nodes that are 3386 leafs of the topology or those close to those leafs. 3388 6.11.1.1.2. Reconvergence 3390 In RPL profiles where RPL Packet Information (RPI, see 3391 Section 6.11.1.13) is present, it is also used to trigger 3392 reconvergence when misrouted, for example looping, packets are 3393 recognized because of their RPI data. This helps to minimize RPL 3394 signaling traffic especially in networks without stable topology and 3395 slow links. 3397 The ACP RPL profile instead relies on quick reconverging the DODAG by 3398 recognizing link state change (down/up) and triggering reconvergence 3399 signaling as described in Section 6.11.1.7. Since links in the ACP 3400 are assumed to be mostly reliable (or have link layer protection 3401 against loss) and because there is no stretch according to 3402 Section 6.11.1.7, loops caused by loss of RPL routing protocol 3403 signaling packets should be exceedingly rare. 3405 In addition, there are a variety of mechanisms possible in RPL to 3406 further avoid temporary loops RECOMMENDED to be used for the ACPL RPL 3407 profile: DODAG Information Objects (DIOs) SHOULD be sent 2...3 times 3408 to inform children when losing the last parent. The technique in 3409 [RFC6550] section 8.2.2.6. (Detaching) SHOULD be favored over that 3410 in section 8.2.2.5., (Poisoning) because it allows local 3411 connectivity. Nodes SHOULD select more than one parent, at least 3 3412 if possible, and send Destination Advertisement Objects (DAO)s to all 3413 of them in parallel. 3415 Additionally, failed ACP tunnels can be quickly discovered trough the 3416 secure channel protocol mechanisms such as IKEv2 Dead Peer Detection. 3417 This can function as a replacement for a Low-power and Lossy 3418 Networks' (LLN's) Expected Transmission Count (ETX) feature that is 3419 not used in this profile. A failure of an ACP tunnel should 3420 imediately signal the RPL control plane to pick a different parent. 3422 6.11.1.2. RPL Instances 3424 Single RPL instance. Default RPLInstanceID = 0. 3426 6.11.1.3. Storing vs. Non-Storing Mode 3428 RPL Mode of Operations (MOP): MUST support mode 2 - "Storing Mode of 3429 Operations with no multicast support". Implementations MAY support 3430 mode 3 ("... with multicast support" as that is a superset of mode 3431 2). Note: Root indicates mode in DIO flow. 3433 6.11.1.4. DAO Policy 3435 Proactive, aggressive DAO state maintenance: 3437 o Use K-flag in unsolicited DAO indicating change from previous 3438 information (to require DAO-ACK). 3440 o Retry such DAO DAO-RETRIES(3) times with DAO- ACK_TIME_OUT(256ms) 3441 in between. 3443 6.11.1.5. Path Metric 3445 Hopcount. 3447 6.11.1.6. Objective Function 3449 Objective Function (OF): Use OF0 [RFC6552]. No use of metric 3450 containers. 3452 rank_factor: Derived from link speed: <= 100Mbps: 3453 LOW_SPEED_FACTOR(5), else HIGH_SPEED_FACTOR(1) 3455 This is a simple rank differentiation between typical "low speed" or 3456 "IoT" links that commonly max out at 100 Mbps and typical 3457 infrastructure links with speeds of 1 Gbps or higher. Given how the 3458 path selection for the ACP focusses only on reachability but not on 3459 path cost optimization, no attempts at finer grained path 3460 optimization are made. 3462 6.11.1.7. DODAG Repair 3464 Global Repair: we assume stable links and ranks (metrics), so no need 3465 to periodically rebuild DODAG. DODAG version only incremented under 3466 catastrophic events (e.g., administrative action). 3468 Local Repair: As soon as link breakage is detected, send No-Path DAO 3469 for all the targets that were reachable only via this link. As soon 3470 as link repair is detected, validate if this link provides you a 3471 better parent. If so, compute your new rank, and send new DIO that 3472 advertises your new rank. Then send a DAO with a new path sequence 3473 about yourself. 3475 stretch_rank: none provided ("not stretched"). 3477 Data Path Validation: Not used. 3479 Trickle: Not used. 3481 6.11.1.8. Multicast 3483 Not used yet but possible because of the selected mode of operations. 3485 6.11.1.9. Security 3487 [RFC6550] security not used, substituted by ACP security. 3489 Because the ACP links already include provisions for confidentiality 3490 and integrity protection, their usage at the RPL layer would be 3491 redundant, and so RPL security is not used. 3493 6.11.1.10. P2P communications 3495 Not used. 3497 6.11.1.11. IPv6 address configuration 3499 Every ACP node (RPL node) announces an IPv6 prefix covering the 3500 address(es) used in the ACP node. The prefix length depends on the 3501 chosen addressing sub-scheme of the ACP address provisioned into the 3502 certificate of the ACP node, e.g., /127 for Zone Addressing Sub- 3503 Scheme or /112 or /120 for Vlong addressing sub-scheme. See 3504 Section 6.10 for more details. 3506 Every ACP node MUST install a black hole (aka null) route for 3507 whatever ACP address space that it advertises (i.e.: the /96 or 3508 /127). This is avoid routing loops for addresses that an ACP node 3509 has not (yet) used. 3511 6.11.1.12. Administrative parameters 3513 Administrative Preference ([RFC6550], 3.2.6 - to become root): 3514 Indicated in DODAGPreference field of DIO message. 3516 o Explicit configured "root": 0b100 3518 o ACP registrar (Default): 0b011 3520 o ACP-connect (non-registrar): 0b010 3522 o Default: 0b001. 3524 6.11.1.13. RPL Packet Information 3526 RPI is not required in the ACP RPL profile for the following reasons. 3528 One RPI option is the RPL Source Routing Header (SRH) [RFC6554] which 3529 is not necessary because the ACP RPL profile uses storing mode where 3530 each hop has the necessary next-hop forwarding information. 3532 The simpler RPL Option header [RFC6553] is also not necessary in this 3533 profile, because it uses a single RPL instance and data path 3534 validation is also not used. 3536 6.11.1.14. Unknown Destinations 3538 Because RPL minimizes the size of the routing and forwarding table, 3539 prefixes reachable through the same interface as the RPL root are not 3540 known on every ACP node. Therefore traffic to unknown destination 3541 addresses can only be discovered at the RPL root. The RPL root 3542 SHOULD have attach safe mechanisms to operationally discover and log 3543 such packets. 3545 As this requirement raises additional Data-Plane, it does not apply 3546 to nodes where the administrative parameter to become root 3547 (Section 6.11.1.12) can always only be 0b001, e.g.: the node does not 3548 support explicit configuration to be root, or to be ACP registrar or 3549 to have ACP-connect functionality. If an ACP network is degraded to 3550 the point where there are no nodes that could be configured roots, 3551 ACP registrars or ACP-connect nodes, traffic to unknown destinations 3552 could not be diagnosed, but in the absence of any intelligent nodes 3553 supporting other than 0b001 administrative preference, there is 3554 likely also no diagnostic function possible. 3556 6.12. General ACP Considerations 3558 Since channels are by default established between adjacent neighbors, 3559 the resulting overlay network does hop-by-hop encryption. Each node 3560 decrypts incoming traffic from the ACP, and encrypts outgoing traffic 3561 to its neighbors in the ACP. Routing is discussed in Section 6.11. 3563 6.12.1. Performance 3565 There are no performance requirements against ACP implementations 3566 defined in this document because the performance requirements depend 3567 on the intended use case. It is expected that full autonomic node 3568 with a wide range of ASA can require high forwarding plane 3569 performance in the ACP, for example for telemetry. Implementations 3570 of ACP to solely support traditional/SDN style use cases can benefit 3571 from ACP at lower performance, especially if the ACP is used only for 3572 critical operations, e.g., when the Data-Plane is not available. The 3573 design of the ACP as specified in this document is intended to 3574 support a wide range of performance options: It is intended to allow 3575 software-only implementations at potentially low performance, but can 3576 also support high performance options. See [RFC8368] for more 3577 details. 3579 6.12.2. Addressing of Secure Channels 3581 In order to be independent of the Data-Plane routing and addressing, 3582 the GRASP discovered ACP secure channels use IPv6 link local 3583 addresses between adjacent neighbors. Note: Section 8.2 specifies 3584 extensions in which secure channels are configured tunnels operating 3585 over the Data-Plane, so those secure channels cannot be independent 3586 of the Data-Plane. 3588 To avoid that Data-Plane configuration can impact the operations of 3589 the IPv6 (link-local) interface/address used for ACP channels, 3590 appropriate implementation considerations are required. If the IPv6 3591 interface/link-local address is shared with the Data-Plane it needs 3592 to be impossible to unconfigure/disable it through configuration. 3593 Instead of sharing the IPv6 interface/link-local address, a separate 3594 (virtual) interface with a separate IPv6 link-local address can be 3595 used. For example, the ACP interface could be run over a separate 3596 MAC address of an underlying L2 (Ethernet) interface. For more 3597 details and options, see Appendix A.10.2. 3599 Note that other (non-ideal) implementation choices may introduce 3600 additional undesired dependencies against the Data-Plane. For 3601 example shared code and configuration of the secure channel protocols 3602 (IPsec / DTLS). 3604 6.12.3. MTU 3606 The MTU for ACP secure channels MUST be derived locally from the 3607 underlying link MTU minus the secure channel encapsulation overhead. 3609 ACP secure Channel protocols do not need to perform MTU discovery 3610 because they are built across L2 adjacencies - the MTU on both sides 3611 connecting to the L2 connection are assumed to be consistent. 3612 Extensions to ACP where the ACP is for example tunneled need to 3613 consider how to guarantee MTU consistency. This is an issue of 3614 tunnels, not an issue of running the ACP across a tunnel. Transport 3615 stacks running across ACP can perform normal PMTUD (Path MTU 3616 Discovery). Because the ACP is meant to be prioritize reliability 3617 over performance, they MAY opt to only expect IPv6 minimum MTU (1280) 3618 to avoid running into PMTUD implementation bugs or underlying link 3619 MTU mismatch problems. 3621 6.12.4. Multiple links between nodes 3623 If two nodes are connected via several links, the ACP SHOULD be 3624 established across every link, but it is possible to establish the 3625 ACP only on a sub-set of links. Having an ACP channel on every link 3626 has a number of advantages, for example it allows for a faster 3627 failover in case of link failure, and it reflects the physical 3628 topology more closely. Using a subset of links (for example, a 3629 single link), reduces resource consumption on the node, because state 3630 needs to be kept per ACP channel. The negotiation scheme explained 3631 in Section 6.5 allows Alice (the node with the higher ACP address) to 3632 drop all but the desired ACP channels to Bob - and Bob will not re- 3633 try to build these secure channels from his side unless Alice shows 3634 up with a previously unknown GRASP announcement (e.g., on a different 3635 link or with a different address announced in GRASP). 3637 6.12.5. ACP interfaces 3639 The ACP VRF has conceptually two type of interfaces: The "ACP 3640 Loopback interface(s)" to which the ACP ULA address(es) are assigned 3641 and the "ACP virtual interfaces" that are mapped to the ACP secure 3642 channels. 3644 6.12.5.1. ACP loopback interfaces 3646 For autonomous operations of the ACP, as described in Section 6 and 3647 Section 7, the ACP node uses the first address from the N bit ACP 3648 prefix (N = 128 - number of Vbits of the ACP address) assigned to the 3649 node. This address is assigned with an adddress prefix of N or 3650 larger to a loopback interface. 3652 Other addresses from the prefix can be used by the ACP of the node as 3653 desired. The autonomous operations of the ACP does not require 3654 additional global scope IPv6 addresses, they are instead intended for 3655 ASA or non-autonomous functions. Non fully autonomic components of 3656 the ACP such as ACP connect interfaces (see Figure 15 may also 3657 introduce additional global scope IPv6 addresses on other type of 3658 interfaces into the ACP. 3660 [RFC Editor: please remove this paragraph: Note to reviewers: Please 3661 do not complain again about an obsolete RFC number in the following 3662 paragraph. The text should make it clear that the reference was 3663 choosen to indicate a particular point in time, but not to recommend/ 3664 use a particularily obsolete protocol spec.] 3666 The use of loopback interfaces for global scope addresses is common 3667 operational configuration practice on routers, for example in IBGP 3668 connections since BGP4 (see [RFC1654]) or earlier. The ACP adopts 3669 and automates this operational practice. 3671 A loopback interface for use with the ACP as described above is an 3672 interface behaving according to [RFC6724] Section 4., paragraph 2: 3673 Packets sent by the host of the node from the loopback interface 3674 behave as if they are looped back by the interface so that they look 3675 as if they originated from the loopback interface, are then received 3676 by the node and forwarded by it towards the destination. 3678 The word loopback only indicates this behavior, but not the actual 3679 name of the interface type choosen in an actual implementation. A 3680 loopback interface for use with the ACP can be a virtual/software 3681 construct without any associated hardware, or it can be a hardware 3682 interface operating in loopback mode. 3684 A loopback interface used for the ACP MUST NOT have connectivity to 3685 other nodes. 3687 The following reviews the reasons for the choice of loopback 3688 addresses for ACP addresses is based on the IPv6 address architecture 3689 and common challenges: 3691 1. IPv6 addresses are assigned to interfaces, not nodes. IPv6 3692 continues the IPv4 model that a subnet prefix is associated with 3693 one link, see [RFC4291], Section 2.1. 3695 2. IPv6 implementations do commonly not allow to assign the same 3696 IPv6 global scope address in the same VRF to more than one 3697 interface. 3699 3. Global scope addresses assigned to interfaces that are connecting 3700 to other nodes (external interfaces) may not be stable addresses 3701 for communications because any such interface could fail due to 3702 reasons external to the node. This could render the addresses 3703 assigned to that interface unusable. 3705 4. If failure of the subnet does not result in bringing down the 3706 interface and making the addresses unusable, it could result in 3707 unreachability of the address because the shortest path to the 3708 node might go through one of the other nodes on the same subnet 3709 which could equally consider the subnet to be operational even 3710 though it is not. 3712 5. Many OAM service implementations on routers can not deal with 3713 more than one peer address, often because they do already expect 3714 that a single loopback address can be used, especially to provide 3715 a stable address under failure of external interfaces or links. 3717 6. Even when an application supports multiple addresses to a peer, 3718 it can only use one adddress for a connection at a time with the 3719 most widely deployed transport protocols TCP and UDP. While 3720 [RFC6824] solves this problem, it is not widely adopted for 3721 router OAM services implementations. 3723 7. To completely autonomously assign global scope addresses to 3724 subnets connecting to other nodes, it would be necessary for 3725 every node to have an amount of prefix address space in the order 3726 of the maximum number of subnets that the node could connect to 3727 and then the node would have to negotiate with adjacent nodes 3728 across those subnet whose address space to use for each subnet. 3730 8. Using global scope addresses for subnets between nodes is 3731 unnecessary if those subnets only connect routers, such as ACP 3732 secure channels because they can communicate to remote nodes via 3733 their global scope loopback addresses. Using global scope 3734 addresses for those extern subnets is therefore wasteful for the 3735 address space and also unnecessarily increasing the size of 3736 routing and forwarding tables, which especially for the ACP is 3737 highly undesirable because it should attempt to minimize the per- 3738 node overhead of the ACP VRF. 3740 9. For all these reasons, the ACP addressing schemes do not consider 3741 ACP addresses for subnets connecting ACP nodes. 3743 Note that [RFC8402] introduces the term Node-SID to refer to IGP 3744 prefix segments that identify a specific rouer, for example on a 3745 loopback interface. An ACP loopback address prefix may similarily be 3746 called an ACP Node Identifier. 3748 6.12.5.2. ACP virtual interfaces 3750 Any ACP secure channel to another ACP node is mapped to ACP virtual 3751 interfaces in one of the following ways. This is independent of the 3752 chosen secure channel protocol (IPsec, DTLS or other future protocol 3753 - standards or non-standards). 3755 Note that all the considerations described here are assuming point- 3756 to-point secure channel associations. Mapping multi-party secure 3757 channel associations such as [RFC6407] is out of scope (but would be 3758 easy to add). 3760 6.12.5.2.1. ACP point-to-point virtual interfaces 3762 In this option, each ACP secure channel is mapped into a separate 3763 point-to-point ACP virtual interface. If a physical subnet has more 3764 than two ACP capable nodes (in the same domain), this implementation 3765 approach will lead to a full mesh of ACP virtual interfaces between 3766 them. 3768 6.12.5.2.2. ACP multi-access virtual interfaces 3770 In a more advanced implementation approach, the ACP will construct a 3771 single multi-access ACP virtual interface for all ACP secure channels 3772 to ACP capable nodes reachable across the same underlying (physical) 3773 subnet. IPv6 link-local multicast packets sent into an ACP multi- 3774 access virtual interface are replicated to every ACP secure channel 3775 mapped into the ACP multicast-access virtual interface. IPv6 unicast 3776 packets sent into an ACP multi-access virtual interface are sent to 3777 the ACP secure channel that belongs to the ACP neighbor that is the 3778 next-hop in the ACP forwarding table entry used to reach the packets 3779 destination address. 3781 There is no requirement for all ACP nodes on the same multi-access 3782 subnet to use the same type of ACP virtual interface. This is purely 3783 a node local decision. 3785 ACP nodes MUST perform standard IPv6 operations across ACP virtual 3786 interfaces including SLAAC (Stateless Address Auto-Configuration) - 3787 [RFC4862]) to assign their IPv6 link local address on the ACP virtual 3788 interface and ND (Neighbor Discovery - [RFC4861]) to discover which 3789 IPv6 link-local neighbor address belongs to which ACP secure channel 3790 mapped to the ACP virtual interface. This is independent of whether 3791 the ACP virtual interface is point-to-point or multi-access. 3793 "Optimistic Duplicate Address Detection (DAD)" according to [RFC4429] 3794 is RECOMMENDED because the likelihood for duplicates between ACP 3795 nodes is highly improbable as long as the address can be formed from 3796 a globally unique local assigned identifier (e.g., EUI-48/EUI-64, see 3797 below). 3799 ACP nodes MAY reduce the amount of link-local IPv6 multicast packets 3800 from ND by learning the IPv6 link-local neighbor address to ACP 3801 secure channel mapping from other messages such as the source address 3802 of IPv6 link-local multicast RPL messages - and therefore forego the 3803 need to send Neighbor Solicitation messages. 3805 The ACP virtual interface IPv6 link local address can be derived from 3806 any appropriate local mechanism such as node local EUI-48 or EUI-64 3807 ("EUI" stands for "Extended Unique Identifier"). It MUST NOT depend 3808 on something that is attackable from the Data-Plane such as the IPv6 3809 link-local address of the underlying physical interface, which can be 3810 attacked by SLAAC, or parameters of the secure channel encapsulation 3811 header that may not be protected by the secure channel mechanism. 3813 The link-layer address of an ACP virtual interface is the address 3814 used for the underlying interface across which the secure tunnels are 3815 built, typically Ethernet addresses. Because unicast IPv6 packets 3816 sent to an ACP virtual interface are not sent to a link-layer 3817 destination address but rather an ACP secure channel, the link-layer 3818 address fields SHOULD be ignored on reception and instead the ACP 3819 secure channel from which the message was received should be 3820 remembered. 3822 Multi-access ACP virtual interfaces are preferable implementations 3823 when the underlying interface is a (broadcast) multi-access subnet 3824 because they do reflect the presence of the underlying multi-access 3825 subnet into the virtual interfaces of the ACP. This makes it for 3826 example simpler to build services with topology awareness inside the 3827 ACP VRF in the same way as they could have been built running 3828 natively on the multi-access interfaces. 3830 Consider also the impact of point-to-point vs. multi-access virtual 3831 interface on the efficiency of flooding via link local multicasted 3832 messages: 3834 Assume a LAN with three ACP neighbors, Alice, Bob and Carol. Alice's 3835 ACP GRASP wants to send a link-local GRASP multicast message to Bob 3836 and Carol. If Alice's ACP emulates the LAN as one point-to-point 3837 virtual interface to Bob and one to Carol, The sending applications 3838 itself will send two copies, if Alice's ACP emulates a LAN, GRASP 3839 will send one packet and the ACP will replicate it. The result is 3840 the same. The difference happens when Bob and Carol receive their 3841 packet. If they use ACP point-to-point virtual interfaces, their 3842 GRASP instance would forward the packet from Alice to each other as 3843 part of the GRASP flooding procedure. These packets are unnecessary 3844 and would be discarded by GRASP on receipt as duplicates (by use of 3845 the GRASP Session ID). If Bob and Carol's ACP would emulate a multi- 3846 access virtual interface, then this would not happen, because GRASPs 3847 flooding procedure does not replicate back packets to the interface 3848 that they were received from. 3850 Note that link-local GRASP multicast messages are not sent directly 3851 as IPv6 link-local multicast UDP messages into ACP virtual 3852 interfaces, but instead into ACP GRASP virtual interfaces, that are 3853 layered on top of ACP virtual interfaces to add TCP reliability to 3854 link-local multicast GRASP messages. Nevertheless, these ACP GRASP 3855 virtual interfaces perform the same replication of message and, 3856 therefore, result in the same impact on flooding. See Section 6.8.2 3857 for more details. 3859 RPL does support operations and correct routing table construction 3860 across non-broadcast multi-access (NBMA) subnets. This is common 3861 when using many radio technologies. When such NBMA subnets are used, 3862 they MUST NOT be represented as ACP multi-access virtual interfaces 3863 because the replication of IPv6 link-local multicast messages will 3864 not reach all NBMA subnet neighbors. In result, GRASP message 3865 flooding would fail. Instead, each ACP secure channel across such an 3866 interface MUST be represented as a ACP point-to-point virtual 3867 interface. See also Appendix A.10.4. 3869 Care needs to be taken when creating multi-access ACP virtual 3870 interfaces across ACP secure channels between ACP nodes in different 3871 domains or routing subdomains. If for example future inter-domain 3872 ACP policies are defined as "peer-to-peer" policies, it is easier to 3873 create ACP point-to-point virtual interfaces for these inter-domain 3874 secure channels. 3876 7. ACP support on L2 switches/ports (Normative) 3878 7.1. Why (Benefits of ACP on L2 switches) 3880 ANrtr1 ------ ANswitch1 --- ANswitch2 ------- ANrtr2 3881 .../ \ \ ... 3882 ANrtrM ------ \ ------- ANrtrN 3883 ANswitchM ... 3885 Figure 14: Topology with L2 ACP switches 3887 Consider a large L2 LAN with ANrtr1...ANrtrN connected via some 3888 topology of L2 switches. Examples include large enterprise campus 3889 networks with an L2 core, IoT networks or broadband aggregation 3890 networks which often have even a multi-level L2 switched topology. 3892 If the discovery protocol used for the ACP is operating at the subnet 3893 level, every ACP router will see all other ACP routers on the LAN as 3894 neighbors and a full mesh of ACP channels will be built. If some or 3895 all of the AN switches are autonomic with the same discovery 3896 protocol, then the full mesh would include those switches as well. 3898 A full mesh of ACP connections can create fundamental scale 3899 challenges. The number of security associations of the secure 3900 channel protocols will likely not scale arbitrarily, especially when 3901 they leverage platform accelerated encryption/decryption. Likewise, 3902 any other ACP operations (such as routing) needs to scale to the 3903 number of direct ACP neighbors. An ACP router with just 4 physical 3904 interfaces might be deployed into a LAN with hundreds of neighbors 3905 connected via switches. Introducing such a new unpredictable scaling 3906 factor requirement makes it harder to support the ACP on arbitrary 3907 platforms and in arbitrary deployments. 3909 Predictable scaling requirements for ACP neighbors can most easily be 3910 achieved if in topologies such as these, ACP capable L2 switches can 3911 ensure that discovery messages terminate on them so that neighboring 3912 ACP routers and switches will only find the physically connected ACP 3913 L2 switches as their candidate ACP neighbors. With such a discovery 3914 mechanism in place, the ACP and its security associations will only 3915 need to scale to the number of physical interfaces instead of a 3916 potentially much larger number of "LAN-connected" neighbors. And the 3917 ACP topology will follow directly the physical topology, something 3918 which can then also be leveraged in management operations or by ASAs. 3920 In the example above, consider ANswitch1 and ANswitchM are ACP 3921 capable, and ANswitch2 is not ACP capable. The desired ACP topology 3922 is that ANrtr1 and ANrtrM only have an ACP connection to ANswitch1, 3923 and that ANswitch1, ANrtr2, ANrtrN have a full mesh of ACP connection 3924 amongst each other. ANswitch1 also has an ACP connection with 3925 ANswitchM and ANswitchM has ACP connections to anything else behind 3926 it. 3928 7.2. How (per L2 port DULL GRASP) 3930 To support ACP on L2 switches or L2 switched ports of an L3 device, 3931 it is necessary to make those L2 ports look like L3 interfaces for 3932 the ACP implementation. This primarily involves the creation of a 3933 separate DULL GRASP instance/domain on every such L2 port. Because 3934 GRASP has a dedicated link-local IPv6 multicast address 3935 (ALL_GRASP_NEIGHBORS), it is sufficient that all packets for this 3936 address are being extracted at the port level and passed to that DULL 3937 GRASP instance. Likewise the IPv6 link-local multicast packets sent 3938 by that DULL GRASP instance need to be sent only towards the L2 port 3939 for this DULL GRASP instance (instead of being flooded across all 3940 ports of the VLAN to which the port belongs). 3942 When Ports/Interfaces across which the ACP is expected to operate in 3943 an ACP-aware L2-switch or L2/L3-switch/router are L2-bridged, packets 3944 for the ALL_GRASP_NEIGHBORS multicast address MUST never be forward 3945 between these ports. If MLD snooping is used, it MUST be prohibited 3946 from bridging packets for the ALL_GRASP_NEIGHBORS IPv6 multicast 3947 address. 3949 On hybrid L2/L3 switches, multiple L2 ports are assigned to a single 3950 L3 VLAN interface. With the aforementioned changes for DULL GRASP, 3951 ACP can simply operate on the L3 VLAN interfaces, so no further 3952 (hardware) forwarding changes are required to make ACP operate on L2 3953 ports. This is possible because the ACP secure channel protocols 3954 only use link-local IPv6 unicast packets, and these packets will be 3955 sent to the correct L2 port towards the peer by the VLAN logic of the 3956 device. 3958 This is sufficient when p2p ACP virtual interfaces are established to 3959 every ACP peer. When it is desired to create multi-access ACP 3960 virtual interfaces (see Section 6.12.5.2.2), it is REQIURED not to 3961 coalesce all the ACP secure channels on the same L3 VLAN interface, 3962 but only all those on the same L2 port. 3964 If VLAN tagging is used, then all the above described logic only 3965 applies to untagged GRASP packets. For the purpose of ACP neighbor 3966 discovery via GRASP, no VLAN tagged packets SHOULD be sent or 3967 received. In a hybrid L2/L3 switch, each VLAN would therefore only 3968 create ACP adjacencies across those ports where the VLAN is carried 3969 untagged. 3971 In result, the simple logic is that ACP secure channels would operate 3972 over the same L3 interfaces that present a single flat bridged 3973 network across all routers, but because DULL GRASP is separated on a 3974 per-port basis, no full mesh of ACP secure channels is created, but 3975 only per-port ACP secure channels to per-port L2-adjacent ACP node 3976 neighbors. 3978 For example, in the above picture, ANswitch1 would run separate DULL 3979 GRASP instances on its ports to ANrtr1, ANswitch2 and ANswitchI, even 3980 though all those three ports may be in the data plane in the same 3981 (V)LAN and perform L2 switching between these ports, ANswitch1 would 3982 perform ACP L3 routing between them. 3984 The description in the previous paragraph was specifically meant to 3985 illustrate that on hybrid L3/L2 devices that are common in 3986 enterprise, IoT and broadband aggregation, there is only the GRASP 3987 packet extraction (by Ethernet address) and GRASP link-local 3988 multicast per L2-port packet injection that has to consider L2 ports 3989 at the hardware forwarding level. The remaining operations are 3990 purely ACP control plane and setup of secure channels across the L3 3991 interface. This hopefully makes support for per-L2 port ACP on those 3992 hybrid devices easy. 3994 In devices without such a mix of L2 port/interfaces and L3 interfaces 3995 (to terminate any transport layer connections), implementation 3996 details will differ. Logically most simply every L2 port is 3997 considered and used as a separate L3 subnet for all ACP operations. 3998 The fact that the ACP only requires IPv6 link-local unicast and 3999 multicast should make support for it on any type of L2 devices as 4000 simple as possible. 4002 A generic issue with ACP in L2 switched networks is the interaction 4003 with the Spanning Tree Protocol. Without further L2 enhancements, 4004 the ACP would run only across the active STP topology and the ACP 4005 would be interrupted and re-converge with STP changes. Ideally, ACP 4006 peering SHOULD be built also across ports that are blocked in STP so 4007 that the ACP does not depend on STP and can continue to run 4008 unaffected across STP topology changes, where re-convergence can be 4009 quite slow. The above described simple implementation options are 4010 not sufficient to achieve this. 4012 8. Support for Non-ACP Components (Normative) 4014 8.1. ACP Connect 4016 8.1.1. Non-ACP Controller / NMS system 4018 The Autonomic Control Plane can be used by management systems, such 4019 as controllers or network management system (NMS) hosts (henceforth 4020 called simply "NMS hosts"), to connect to devices (or other type of 4021 nodes) through it. For this, an NMS host needs to have access to the 4022 ACP. The ACP is a self-protecting overlay network, which allows by 4023 default access only to trusted, autonomic systems. Therefore, a 4024 traditional, non-ACP NMS system does not have access to the ACP by 4025 default, such as any other external node. 4027 If the NMS host is not autonomic, i.e., it does not support autonomic 4028 negotiation of the ACP, then it can be brought into the ACP by 4029 explicit configuration. To support connections to adjacent non-ACP 4030 nodes, an ACP node SHOULD support "ACP connect" (sometimes also 4031 called "autonomic connect"): 4033 "ACP connect" is an interface level configured workaround for 4034 connection of trusted non-ACP nodes to the ACP. The ACP node on 4035 which ACP connect is configured is called an "ACP edge node". With 4036 ACP connect, the ACP is accessible from those non-ACP nodes (such as 4037 NOC systems) on such an interface without those non-ACP nodes having 4038 to support any ACP discovery or ACP channel setup. This is also 4039 called "native" access to the ACP because to those NOC systems the 4040 interface looks like a normal network interface (without any 4041 encryption/novel-signaling). 4043 Data-Plane "native" (no ACP) 4044 . 4045 +--------+ +----------------+ . +-------------+ 4046 | ACP | |ACP Edge Node | . | | 4047 | Node | | | v | | 4048 | |-------|...[ACP VRF]....+-----------------| |+ 4049 | | ^ |. | | NOC Device || 4050 | | . | .[Data-Plane]..+-----------------| "NMS hosts" || 4051 | | . | [ ] | . ^ | || 4052 +--------+ . +----------------+ . . +-------------+| 4053 . . . +-------------+ 4054 . . . 4055 Data-Plane "native" . ACP "native" (unencrypted) 4056 + ACP auto-negotiated . "ACP connect subnet" 4057 and encrypted . 4058 ACP connect interface 4059 e.g., "VRF ACP native" (config) 4061 Figure 15: ACP connect 4063 ACP connect has security consequences: All systems and processes 4064 connected via ACP connect have access to all ACP nodes on the entire 4065 ACP, without further authentication. Thus, the ACP connect interface 4066 and NOC systems connected to it needs to be physically controlled/ 4067 secured. For this reason the mechanisms described here do explicitly 4068 not include options to allow for a non-ACP router to be connected 4069 across an ACP connect interface and addresses behind such a router 4070 routed inside the ACP. 4072 An ACP connect interface provides exclusively access to only the ACP. 4073 This is likely insufficient for many NMS hosts. Instead, they would 4074 require a second "Data-Plane" interface outside the ACP for 4075 connections between the NMS host and administrators, or Internet 4076 based services, or for direct access to the Data-Plane. The document 4077 "Using Autonomic Control Plane for Stable Connectivity of Network 4078 OAM" [RFC8368] explains in more detail how the ACP can be integrated 4079 in a mixed NOC environment. 4081 An ACP connect interface SHOULD use an IPv6 address/prefix from the 4082 ACP Manual Addressing Sub-Scheme (Section 6.10.4), letting the 4083 operator configure for example only the Subnet-ID and having the node 4084 automatically assign the remaining part of the prefix/address. It 4085 SHOULD NOT use a prefix that is also routed outside the ACP so that 4086 the addresses clearly indicate whether it is used inside the ACP or 4087 not. 4089 The prefix of ACP connect subnets MUST be distributed by the ACP edge 4090 node into the ACP routing protocol RPL. The NMS hosts MUST connect 4091 to prefixes in the ACP routing table via its ACP connect interface. 4092 In the simple case where the ACP uses only one ULA prefix and all ACP 4093 connect subnets have prefixes covered by that ULA prefix, NMS hosts 4094 can rely on [RFC6724] to determine longest match prefix routes 4095 towards its different interfaces, ACP and Data-Plane. With RFC6724, 4096 The NMS host will select the ACP connect interface for all addresses 4097 in the ACP because any ACP destination address is longest matched by 4098 the address on the ACP connect interface. If the NMS hosts ACP 4099 connect interface uses another prefix or if the ACP uses multiple ULA 4100 prefixes, then the NMS hosts require (static) routes towards the ACP 4101 interface for these prefixes. 4103 When an ACP Edge node receives a packet from an ACP connect 4104 interface, the ACP Edge node MUST only forward the packet into the 4105 ACP if the packet has an IPv6 source address from that interface. 4106 This is sometimes called "RPF filtering". This MAY be changed 4107 through administrative measures. 4109 To limit the security impact of ACP connect, nodes supporting it 4110 SHOULD implement a security mechanism to allow configuration/use of 4111 ACP connect interfaces only on nodes explicitly targeted to be 4112 deployed with it (those in physically secure locations such as a 4113 NOC). For example, the registrar could disable the ability to enable 4114 ACP connect on devices during enrollment and that property could only 4115 be changed through re-enrollment. See also Appendix A.10.5. 4117 ACP Edge nodes SHOULD have a configurable option to filter packets 4118 with RPI headers (xsee Section 6.11.1.13 across an ACP connect 4119 interface. These headers are outside the scope of the RPL profile in 4120 this specification but may be used in future extensions of this 4121 specification. 4123 8.1.2. Software Components 4125 The previous section assumed that ACP Edge node and NOC devices are 4126 separate physical devices and the ACP connect interface is a physical 4127 network connection. This section discusses the implication when 4128 these components are instead software components running on a single 4129 physical device. 4131 The ACP connect mechanism can not only be used to connect physically 4132 external systems (NMS hosts) to the ACP but also other applications, 4133 containers or virtual machines. In fact, one possible way to 4134 eliminate the security issue of the external ACP connect interface is 4135 to collocate an ACP edge node and an NMS host by making one a virtual 4136 machine or container inside the other; and therefore converting the 4137 unprotected external ACP subnet into an internal virtual subnet in a 4138 single device. This would ultimately result in a fully ACP enabled 4139 NMS host with minimum impact to the NMS hosts software architecture. 4140 This approach is not limited to NMS hosts but could equally be 4141 applied to devices consisting of one or more VNF (virtual network 4142 functions): An internal virtual subnet connecting out-of-band 4143 management interfaces of the VNFs to an ACP edge router VNF. 4145 The core requirement is that the software components need to have a 4146 network stack that permits access to the ACP and optionally also the 4147 Data-Plane. Like in the physical setup for NMS hosts this can be 4148 realized via two internal virtual subnets. One that is connecting to 4149 the ACP (which could be a container or virtual machine by itself), 4150 and one (or more) connecting into the Data-Plane. 4152 This "internal" use of ACP connect approach should not considered to 4153 be a "workaround" because in this case it is possible to build a 4154 correct security model: It is not necessary to rely on unprovable 4155 external physical security mechanisms as in the case of external NMS 4156 hosts. Instead, the orchestration of the ACP, the virtual subnets 4157 and the software components can be done by trusted software that 4158 could be considered to be part of the ANI (or even an extended ACP). 4159 This software component is responsible for ensuring that only trusted 4160 software components will get access to that virtual subnet and that 4161 only even more trusted software components will get access to both 4162 the ACP virtual subnet and the Data-Plane (because those ACP users 4163 could leak traffic between ACP and Data-Plane). This trust could be 4164 established for example through cryptographic means such as signed 4165 software packages. 4167 8.1.3. Auto Configuration 4169 ACP edge nodes, NMS hosts and software components that as described 4170 in the previous section are meant to be composed via virtual 4171 interfaces SHOULD support on the ACP connect subnet StateLess Address 4172 Autoconfiguration (SLAAC - [RFC4862]) and route auto configuration 4173 according to [RFC4191]. 4175 The ACP edge node acts as the router on the ACP connect subnet, 4176 providing the (auto-)configured prefix for the ACP connect subnet to 4177 NMS hosts and/or software components. The ACP edge node uses route 4178 prefix option of RFC4191 to announce the default route (::/) with a 4179 lifetime of 0 and aggregated prefixes for routes in the ACP routing 4180 table with normal lifetimes. This will ensure that the ACP edge node 4181 does not become a default router, but that the NMS hosts and software 4182 components will route the prefixes used in the ACP to the ACP edge 4183 node. 4185 Aggregated prefix means that the ACP edge node needs to only announce 4186 the /48 ULA prefixes used in the ACP but none of the actual /64 4187 (Manual Addressing Sub-Scheme), /127 (ACP Zone Addressing Sub- 4188 Scheme), /112 or /120 (Vlong Addressing Sub-Scheme) routes of actual 4189 ACP nodes. If ACP interfaces are configured with non ULA prefixes, 4190 then those prefixes cannot be aggregated without further configured 4191 policy on the ACP edge node. This explains the above recommendation 4192 to use ACP ULA prefix covered prefixes for ACP connect interfaces: 4193 They allow for a shorter list of prefixes to be signaled via RFC4191 4194 to NMS hosts and software components. 4196 The ACP edge nodes that have a Vlong ACP address MAY allocate a 4197 subset of their /112 or /120 address prefix to ACP connect 4198 interface(s) to eliminate the need to non-autonomically configure/ 4199 provision the address prefixes for such ACP connect interfaces. 4201 8.1.4. Combined ACP/Data-Plane Interface (VRF Select) 4203 Combined ACP and Data-Plane interface 4204 . 4205 +--------+ +--------------------+ . +--------------+ 4206 | ACP | |ACP Edge No | . | NMS Host(s) | 4207 | Node | | | . | / Software | 4208 | | | [ACP ]. | . | |+ 4209 | | | .[VRF ] .[VRF ] | v | "ACP address"|| 4210 | +-------+. .[Select].+--------+ "Date Plane || 4211 | | ^ | .[Data ]. | | Address(es)"|| 4212 | | . | [Plane] | | || 4213 | | . | [ ] | +--------------+| 4214 +--------+ . +--------------------+ +--------------+ 4215 . 4216 Data-Plane "native" and + ACP auto-negotiated/encrypted 4218 Figure 16: VRF select 4220 Using two physical and/or virtual subnets (and therefore interfaces) 4221 into NMS Hosts (as per Section 8.1.1) or Software (as per 4222 Section 8.1.2) may be seen as additional complexity, for example with 4223 legacy NMS Hosts that support only one IP interface. 4225 To provide a single subnet into both ACP and Data-Plane, the ACP Edge 4226 node needs to de-multiplex packets from NMS hosts into ACP VRF and 4227 Data-Plane. This is sometimes called "VRF select". If the ACP VRF 4228 has no overlapping IPv6 addresses with the Data-Plane (it should have 4229 no overlapping addresses), then this function can use the IPv6 4230 Destination address. The problem is Source Address Selection on the 4231 NMS Host(s) according to RFC6724. 4233 Consider the simple case: The ACP uses only one ULA prefix, the ACP 4234 IPv6 prefix for the Combined ACP and Data-Plane interface is covered 4235 by that ULA prefix. The ACP edge node announces both the ACP IPv6 4236 prefix and one (or more) prefixes for the Data-Plane. Without 4237 further policy configurations on the NMS Host(s), it may select its 4238 ACP address as a source address for Data-Plane ULA destinations 4239 because of Rule 8 of RFC6724. The ACP edge node can pass on the 4240 packet to the Data-Plane, but the ACP source address should not be 4241 used for Data-Plane traffic, and return traffic may fail. 4243 If the ACP carries multiple ULA prefixes or non-ULA ACP connect 4244 prefixes, then the correct source address selection becomes even more 4245 problematic. 4247 With separate ACP connect and Data-Plane subnets and RFC4191 prefix 4248 announcements that are to be routed across the ACP connect interface, 4249 RFC6724 source address selection Rule 5 (use address of outgoing 4250 interface) will be used, so that above problems do not occur, even in 4251 more complex cases of multiple ULA and non-ULA prefixes in the ACP 4252 routing table. 4254 To achieve the same behavior with a Combined ACP and Data-Plane 4255 interface, the ACP Edge Node needs to behave as two separate routers 4256 on the interface: One link-local IPv6 address/router for its ACP 4257 reachability, and one link-local IPv6 address/router for its Data- 4258 Plane reachability. The Router Advertisements for both are as 4259 described above (Section 8.1.3): For the ACP, the ACP prefix is 4260 announced together with RFC4191 option for the prefixes routed across 4261 the ACP and lifetime=0 to disqualify this next-hop as a default 4262 router. For the Data-Plane, the Data-Plane prefix(es) are announced 4263 together with whatever dafault router parameters are used for the 4264 Data-Plane. 4266 In result, RFC6724 source address selection Rule 5.5 may result in 4267 the same correct source address selection behavior of NMS hosts 4268 without further configuration on it as the separate ACP connect and 4269 Data-Plane interfaces. As described in the text for Rule 5.5, this 4270 is only a MAY, because IPv6 hosts are not required to track next-hop 4271 information. If an NMS Host does not do this, then separate ACP 4272 connect and Data-Plane interfaces are the preferable method of 4273 attachment. Hosts implementing [RFC8028] should (instead of may) 4274 implement [RFC6724] Rule 5.5, so it is preferred for hosts to support 4275 [RFC8028]. 4277 ACP edge nodes MAY support the Combined ACP and Data-Plane interface. 4279 8.1.5. Use of GRASP 4281 GRASP can and should be possible to use across ACP connect 4282 interfaces, especially in the architectural correct solution when it 4283 is used as a mechanism to connect Software (e.g., ASA or legacy NMS 4284 applications) to the ACP. 4286 Given how the ACP is the security and transport substrate for GRASP, 4287 the requirements for devices connected via ACP connect is that those 4288 are equivalently (if not better) secured against attacks and run only 4289 software that is equally (if not better) protected, known (or 4290 trusted) not to be malicious and accordingly designed to isolate 4291 access to the ACP against external equipment. 4293 The difference in security is that cryptographic security of the ACP 4294 secure channel is replaced by required physical security of the 4295 network connection between an ACP edge node and the NMS or other host 4296 reachable via the ACP connect interface. Node integrity too is 4297 expected to be easier because the ACP connect node, the ACP connect 4298 link and the nodes connecting to it must be in a contiguous secure 4299 environment, hence assuming there can be no physical attack against 4300 the devices. 4302 When using "Combined ACP and Data-Plane Interfaces", care hasa to be 4303 taken that only GRASP messages intended for the ACP GRASP domain 4304 received from Software or NMS Hosts are forwarded by ACP edge nodes. 4305 Currently there is no definition for a GRASP security and transport 4306 substrate beside the ACP, so there is no definition how such 4307 Software/NMS Host could participate in two separate GRASP Domains 4308 across the same subnet (ACP and Data-Plane domains). At current it 4309 is assumed that all GRASP packets on a Combined ACP and Data-Plane 4310 interface belong to the GRASP ACP Domain. They SHOULD all use the 4311 ACP IPv6 addresses of the Software/NMS Hosts. The link-local IPv6 4312 addresses of Software/NMS Hosts (used for GRASP M_DISCOVERY and 4313 M_FLOOD messages) are also assumed to belong to the ACP address 4314 space. 4316 8.2. Connecting ACP islands over Non-ACP L3 networks (Remote ACP 4317 neighbors) 4319 Not all nodes in a network may support the ACP. If non-ACP Layer-2 4320 devices are between ACP nodes, the ACP will work across it since it 4321 is IP based. However, the autonomic discovery of ACP neighbors via 4322 DULL GRASP is only intended to work across L2 connections, so it is 4323 not sufficient to autonomically create ACP connections across non-ACP 4324 Layer-3 devices. 4326 8.2.1. Configured Remote ACP neighbor 4328 On the ACP node, remote ACP neighbors are configured explicitly. The 4329 parameters of such a "connection" are described in the following 4330 ABNF. 4332 connection = [ method , local-addr, remote-addr, ?pmtu ] 4333 method = [ "IKEv2" , ?port ] 4334 method //= [ "DTLS", port ] 4335 local-addr = [ address , ?vrf ] 4336 remote-addr = [ address ] 4337 address = ("any" | ipv4-address | ipv6-address ) 4338 vrf = tstr ; Name of a VRF on this node with local-address 4340 Figure 17: Parameters for remote ACP neighbors 4342 Explicit configuration of a remote-peer according to this ABNF 4343 provides all the information to build a secure channel without 4344 requiring a tunnel to that peer and running DULL GRASP inside of it. 4346 The configuration includes the parameters otherwise signaled via DULL 4347 GRASP: local address, remote (peer) locator and method. The 4348 differences over DULL GRASP local neighbor discovery and secure 4349 channel creation are as follows: 4351 o The local and remote address can be IPv4 or IPv6 and are typically 4352 global scope addresses. 4354 o The VRF across which the connection is built (and in which local- 4355 addr exists) can to be specified. If vrf is not specified, it is 4356 the default VRF on the node. In DULL GRASP the VRF is implied by 4357 the interface across which DULL GRASP operates. 4359 o If local address is "any", the local address used when initiating 4360 a secure channel connection is decided by source address selection 4361 ([RFC6724] for IPv6). As a responder, the connection listens on 4362 all addresses of the node in the selected VRF. 4364 o Configuration of port is only required for methods where no 4365 defaults exist (e.g., "DTLS"). 4367 o If remote address is "any", the connection is only a responder. 4368 It is a "hub" that can be used by multiple remote peers to connect 4369 simultaneously - without having to know or configure their 4370 addresses. Example: Hub site for remote "spoke" sites reachable 4371 over the Internet. 4373 o Pmtu should be configurable to overcome issues/limitations of Path 4374 MTU Discovery (PMTUD). 4376 o IKEv2/IPsec to remote peers should support the optional NAT 4377 Traversal (NAT-T) procedures. 4379 8.2.2. Tunneled Remote ACP Neighbor 4381 An IPinIP, GRE or other form of pre-existing tunnel is configured 4382 between two remote ACP peers and the virtual interfaces representing 4383 the tunnel are configured for "ACP enable". This will enable IPv6 4384 link local addresses and DULL on this tunnel. In result, the tunnel 4385 is used for normal "L2 adjacent" candidate ACP neighbor discovery 4386 with DULL and secure channel setup procedures described in this 4387 document. 4389 Tunneled Remote ACP Neighbor requires two encapsulations: the 4390 configured tunnel and the secure channel inside of that tunnel. This 4391 makes it in general less desirable than Configured Remote ACP 4392 Neighbor. Benefits of tunnels are that it may be easier to implement 4393 because there is no change to the ACP functionality - just running it 4394 over a virtual (tunnel) interface instead of only native interfaces. 4395 The tunnel itself may also provide PMTUD while the secure channel 4396 method may not. Or the tunnel mechanism is permitted/possible 4397 through some firewall while the secure channel method may not. 4399 8.2.3. Summary 4401 Configured/Tunneled Remote ACP neighbors are less "indestructible" 4402 than L2 adjacent ACP neighbors based on link local addressing, since 4403 they depend on more correct Data-Plane operations, such as routing 4404 and global addressing. 4406 Nevertheless, these options may be crucial to incrementally deploy 4407 the ACP, especially if it is meant to connect islands across the 4408 Internet. Implementations SHOULD support at least Tunneled Remote 4409 ACP Neighbors via GRE tunnels - which is likely the most common 4410 router-to-router tunneling protocol in use today. 4412 9. ACP Operations (Informative) 4414 The following sections document important operational aspects of the 4415 ACP. They are not normative because they do not impact the 4416 interoperability between components of the ACP, but they include 4417 recommendations/requirements for the internal operational model 4418 beneficial or necessary to achieve the desired use-case benefits of 4419 the ACP (see Section 3). 4421 o Section 9.1 describes recommended operator diagnostics 4422 capabilities of ACP nodes. The have been derived from diagnostic 4423 of a commercially available ACP implementation. 4425 o Section 9.2 describes high level how an ACP registrar needs to 4426 work, what its configuration parameters are and specific issues 4427 impacting the choices of deployment design due to renewal and 4428 revocation issues. It describes a model where ACP Registrars have 4429 their own sub-CA to provide the most distributed deployment option 4430 for ACP Registrars, and it describes considerations for 4431 centralized policy control of ACP Registrar operations. 4433 o Section 9.3 describes suggested ACP node behavior and operational 4434 interfaces (configuration options) to manage the ACP in so-called 4435 greenfield devices (previously unconfigured) and brownfield 4436 devices (preconfigured). 4438 The recommendations and suggestions of this chapter were derived from 4439 operational experience gained with a commercially available pre- 4440 standard ACP implementation. 4442 9.1. ACP (and BRSKI) Diagnostics 4444 Even though ACP and ANI in general are taking out many manual 4445 configuration mistakes through their automation, it is important to 4446 provide good diagnostics for them. 4448 The basic diagnostics is support of (yang) data models representing 4449 the complete (auto-)configuration and operational state of all 4450 components: BRSKI, GRASP, ACP and the infrastructure used by them: 4451 TLS/DTLS, IPsec, certificates, TA, time, VRF and so on. While 4452 necessary, this is not sufficient: 4454 Simply representing the state of components does not allow operators 4455 to quickly take action - unless they do understand how to interpret 4456 the data, and that can mean a requirement for deep understanding of 4457 all components and how they interact in the ACP/ANI. 4459 Diagnostic supports should help to quickly answer the questions 4460 operators are expected to ask, such as "is the ACP working 4461 correctly?", or "why is there no ACP connection to a known 4462 neighboring node?" 4464 In current network management approaches, the logic to answer these 4465 questions is most often built as centralized diagnostics software 4466 that leverages the above mentioned data models. While this approach 4467 is feasible for components utilizing the ANI, it is not sufficient to 4468 diagnose the ANI itself: 4470 o Developing the logic to identify common issues requires 4471 operational experience with the components of the ANI. Letting 4472 each management system define its own analysis is inefficient. 4474 o When the ANI is not operating correctly, it may not be possible to 4475 run diagnostics from remote because of missing connectivity. The 4476 ANI should therefore have diagnostic capabilities available 4477 locally on the nodes themselves. 4479 o Certain operations are difficult or impossible to monitor in real- 4480 time, such as initial bootstrap issues in a network location where 4481 no capabilities exist to attach local diagnostics. Therefore it 4482 is important to also define means of capturing (logging) 4483 diagnostics locally for later retrieval. Ideally, these captures 4484 are also non-volatile so that they can survive extended power-off 4485 conditions - for example when a device that fails to be brought up 4486 zero-touch is being sent back for diagnostics at a more 4487 appropriate location. 4489 The most simple form of diagnostics answering questions such as the 4490 above is to represent the relevant information sequentially in 4491 dependency order, so that the first non-expected/non-operational item 4492 is the most likely root cause. Or just log/highlight that item. For 4493 example: 4495 Q: Is ACP operational to accept neighbor connections: 4497 o Check if any potentially necessary configuration to make ACP/ANI 4498 operational are correct (see Section 9.3 for a discussion of such 4499 commands). 4501 o Does the system time look reasonable, or could it be the default 4502 system time after clock chip battery failure (certificate checks 4503 depend on reasonable notion of time). 4505 o Does the node have keying material - domain certificate, TA 4506 certificates, .... 4508 o If no keying material and ANI is supported/enabled, check the 4509 state of BRSKI (not detailed in this example). 4511 o Check the validity of the domain certificate: 4513 * Does the certificate validate against the TA? 4515 * Has it been revoked? 4516 * Was the last scheduled attempt to retrieve a CRL successful 4517 (e.g., do we know that our CRL information is up to date). 4519 * Is the certificate valid: validity start time in the past, 4520 expiration time in the future? 4522 * Does the certificate have a correctly formatted acp-node-name 4523 field? 4525 o Was the ACP VRF successfully created? 4527 o Is ACP enabled on one or more interfaces that are up and running? 4529 If all this looks good, the ACP should be running locally "fine" - 4530 but we did not check any ACP neighbor relationships. 4532 Question: why does the node not create a working ACP connection to a 4533 neighbor on an interface? 4535 o Is the interface physically up? Does it have an IPv6 link-local 4536 address? 4538 o Is it enabled for ACP? 4540 o Do we successfully send DULL GRASP messages to the interface (link 4541 layer errors)? 4543 o Do we receive DULL GRASP messages on the interface? If not, some 4544 intervening L2 equipment performing bad MLD snooping could have 4545 caused problems. Provide e.g., diagnostics of the MLD querier 4546 IPv6 and MAC address. 4548 o Do we see the ACP objective in any DULL GRASP message from that 4549 interface? Diagnose the supported secure channel methods. 4551 o Do we know the MAC address of the neighbor with the ACP objective? 4552 If not, diagnose SLAAC/ND state. 4554 o When did we last attempt to build an ACP secure channel to the 4555 neighbor? 4557 o If it failed, why: 4559 * Did the neighbor close the connection on us or did we close the 4560 connection on it because the domain certificate membership 4561 failed? 4563 * If the neighbor closed the connection on us, provide any error 4564 diagnostics from the secure channel protocol. 4566 * If we failed the attempt, display our local reason: 4568 + There was no common secure channel protocol supported by the 4569 two neighbors (this could not happen on nodes supporting 4570 this specification because it mandates common support for 4571 IPsec). 4573 + The ACP domain certificate membership check (Section 6.1.3) 4574 fails: 4576 - The neighbor's certificate is not signed directly or 4577 indirectly by one of the nodes TA. Provide diagnostics 4578 which TA it has (can identify whom the device belongs 4579 to). 4581 - The neighbor's certificate does not have the same domain 4582 (or no domain at all). Diagnose domain-name and 4583 potentially other cert info. 4585 - The neighbor's certificate has been revoked or could not 4586 be authenticated by OCSP. 4588 - The neighbor's certificate has expired - or is not yet 4589 valid. 4591 * Any other connection issues in e.g., IKEv2 / IPsec, DTLS?. 4593 Question: Is the ACP operating correctly across its secure channels? 4595 o Are there one or more active ACP neighbors with secure channels? 4597 o Is the RPL routing protocol for the ACP running? 4599 o Is there a default route to the root in the ACP routing table? 4601 o Is there for each direct ACP neighbor not reachable over the ACP 4602 virtual interface to the root a route in the ACP routing table? 4604 o Is ACP GRASP running? 4606 o Is at least one SRV.est objective cached (to support certificate 4607 renewal)? 4609 o Is there at least one BRSKI registrar objective cached (in case 4610 BRSKI is supported) 4612 o Is BRSKI proxy operating normally on all interfaces where ACP is 4613 operating? 4615 o ... 4617 These lists are not necessarily complete, but illustrate the 4618 principle and show that there are variety of issues ranging from 4619 normal operational causes (a neighbor in another ACP domain) over 4620 problems in the credentials management (certificate lifetimes), 4621 explicit security actions (revocation) or unexpected connectivity 4622 issues (intervening L2 equipment). 4624 The items so far are illustrating how the ANI operations can be 4625 diagnosed with passive observation of the operational state of its 4626 components including historic/cached/counted events. This is not 4627 necessary sufficient to provide good enough diagnostics overall: 4629 The components of ACP and BRSKI are designed with security in mind 4630 but they do not attempt to provide diagnostics for building the 4631 network itself. Consider two examples: 4633 1. BRSKI does not allow for a neighboring device to identify the 4634 pledges IDevID certificate. Only the selected BRSKI registrar 4635 can do this, but it may be difficult to disseminate information 4636 about undesired pledges from those BRSKI registrars to locations/ 4637 nodes where information about those pledges is desired. 4639 2. LLDP disseminates information about nodes to their immediate 4640 neighbors, such as node model/type/software and interface name/ 4641 number of the connection. This information is often helpful or 4642 even necessary in network diagnostics. It can equally considered 4643 to be too insecure to make this information available unprotected 4644 to all possible neighbors. 4646 An "interested adjacent party" can always determine the IDevID 4647 certificate of a BRSKI pledge by behaving like a BRSKI proxy/ 4648 registrar. Therefore the IDevID certificate of a BRSKI pledge is not 4649 meant to be protected - it just has to be queried and is not signaled 4650 unsolicited (as it would be in LLDP) so that other observers on the 4651 same subnet can determine who is an "interested adjacent party". 4653 9.1.1. Secure Channel Peer diagnostics 4655 When using mutual certificate authentication, the TA certificate is 4656 not required to be signalled explicitly because its hash is 4657 sufficient for certificate chain validation. In the case of ACP 4658 secure channel setup this leads to limited diagnostics when 4659 authentication fails because of TA mismatch. For this reason, 4660 Section 6.7.2 recommends to also include the TA certificate in the 4661 secure channel signalling. This should be possible to do without 4662 protocol modifications in the security association protocols used by 4663 the ACP. For example, while [RFC7296] does not mention this, it also 4664 does not prohibit it. 4666 One common deployment use case where the diagnostic through the 4667 signalled TA of a candidate peer is very helpfull are multi-tenant 4668 environments such as office buildings, where different tenants run 4669 their own networks and ACPs. Each tenant is given supposedly 4670 disjoint L2 connectivity through the building infrastructure. In 4671 these environments there are various common errors through which a 4672 device may receive L2 connectivity into the wrong tenants network. 4674 While the ACP itself is not impact by this, the Data-Plane to be 4675 built later may be impacted. Therefore it is important to be able to 4676 diagnose such undesirable connectivity from the ACP so that any 4677 autonomic or non-autonomic mechanisms to configure the Data-Plane can 4678 accordingly treat such interfaces. The information in the TA of the 4679 peer can then ease troubleshooting of such issues. 4681 Another example case is the intended or accidental re-activation of 4682 equipment whose TA certificate has long expired, such as redundant 4683 gear taken from storage after years. Potentially without following 4684 the correct process set up for such cases. 4686 A third example case is when in a mergers&aquisition case ACP nodes 4687 have not been correctly provisioned with the mutual TA of previously 4688 disjoint ACP. This is assuming that the ACP domain names where 4689 already aligned so that the ACP domain membership check is only 4690 failing on the TA. 4692 A fourth example case is when multiple registrars where set up for 4693 the same ACP but without correctly setting up the same TA. For 4694 example when registrars support to also be CA themselves but are 4695 misconfigured to become TA instead of intermediate CA. 4697 9.2. ACP Registrars 4699 As described in Section 6.10.7, the ACP addressing mechanism is 4700 designed to enable lightweight, distributed and uncoordinated ACP 4701 registrars that are providing ACP address prefixes to candidate ACP 4702 nodes by enrolling them with an ACP domain certificate into an ACP 4703 domain via any appropriate mechanism/protocol, automated or not. 4705 This section discusses informatively more details and options for ACP 4706 registrars. 4708 9.2.1. Registrar interactions 4710 This section summarizes and discusses the interactions with other 4711 entities required by an ACP registrar. 4713 In a simple instance of an ACP network, no central NOC component 4714 beside a TA is required. Typically, this is a root CA. One or more 4715 uncoordinated acting ACP registrar can be set up, performing the 4716 following interactions: 4718 To orchestrate enrolling a candidate ACP node autonomically, the ACP 4719 registrar can rely on the ACP and use Proxies to reach the candidate 4720 ACP node, therefore allowing minimum pre-existing (auto-)configured 4721 network services on the candidate ACP node. BRSKI defines the BRSKI 4722 proxy, a design that can be adopted for various protocols that 4723 Pledges/candidate ACP nodes could want to use, for example BRSKI over 4724 CoAP (Constrained Application Protocol), or proxying of Netconf. 4726 To reach a TA that has no ACP connectivity, the ACP registrar would 4727 use the Data-Plane. ACP and Data-Plane in an ACP registrar could 4728 (and by default should be) completely isolated from each other at the 4729 network level. Only applications such as the ACP registrar would 4730 need the ability for their transport stacks to access both. 4732 In non-autonomic enrollment options, the Data-Plane between a ACP 4733 registrar and the candidate ACP node needs to be configured first. 4734 This includes the ACP registrar and the candidate ACP node. Then any 4735 appropriate set of protocols can be used between ACP registrar and 4736 candidate ACP node to discover the other side, and then connect and 4737 enroll (configure) the candidate ACP node with an ACP domain 4738 certificate. Netconf ZeroTouch ([RFC8572]) is an example protocol 4739 that could be used for this. BRSKI using optional discovery 4740 mechanisms is equally a possibility for candidate ACP nodes 4741 attempting to be enrolled across non-ACP networks, such as the 4742 Internet. 4744 When candidate ACP nodes have secure bootstrap, such as BRSKI 4745 Pledges, they will not trust to be configured/enrolled across the 4746 network, unless being presented with a voucher (see [RFC8366]) 4747 authorizing the network to take possession of the node. An ACP 4748 registrar will then need a method to retrieve such a voucher, either 4749 offline, or online from a MASA (Manufacturer Authorized Signing 4750 Authority). BRSKI and Netconf ZeroTouch are two protocols that 4751 include capabilities to present the voucher to the candidate ACP 4752 node. 4754 An ACP registrar could operate EST for ACP certificate renewal and/or 4755 act as a CRL Distribution point. A node performing these services 4756 does not need to support performing (initial) enrollment, but it does 4757 require the same above described connectivity as an ACP registrar: 4758 via the ACP to ACP nodes and via the Data-Plane to the TA and other 4759 sources of CRL information. 4761 9.2.2. Registrar Parameter 4763 The interactions of an ACP registrar outlined Section 6.10.7 and 4764 Section 9.2.1 above depend on the following parameters: 4766 A URL to the TA and credentials so that the ACP registrar can let 4767 the TA sign candidate ACP node certificates. 4769 The ACP domain-name. 4771 The Registrar-ID to use. This could default to a MAC address of 4772 the ACP registrar. 4774 For recovery, the next-useable Node-IDs for zone (Zone-ID=0) sub- 4775 addressing scheme, for Vlong /112 and for Vlong /120 sub- 4776 addressing scheme. These IDs would only need to be provisioned 4777 after recovering from a crash. Some other mechanism would be 4778 required to remember these IDs in a backup location or to recover 4779 them from the set of currently known ACP nodes. 4781 Policies if candidate ACP nodes should receive a domain 4782 certificate or not, for example based on the devices IDevID 4783 certificate as in BRSKI. The ACP registrar may have a whitelist 4784 or blacklist of devices "serialNumbers" from their IDevID 4785 certificate. 4787 Policies what type of address prefix to assign to a candidate ACP 4788 devices, based on likely the same information. 4790 For BRSKI or other mechanisms using vouchers: Parameters to 4791 determine how to retrieve vouchers for specific type of secure 4792 bootstrap candidate ACP nodes (such as MASA URLs), unless this 4793 information is automatically learned such as from the IDevID 4794 certificate of candidate ACP nodes (as defined in BRSKI). 4796 9.2.3. Certificate renewal and limitations 4798 When an ACP node renews/rekeys its certificate, it may end up doing 4799 so via a different registrar (e.g., EST server) than the one it 4800 originally received its ACP domain certificate from, for example 4801 because that original ACP registrar is gone. The ACP registrar 4802 through which the renewal/rekeying is performed would by default 4803 trust the acp-node-name from the ACP nodes current ACP domain 4804 certificate and maintain this information so that the ACP node 4805 maintains its ACP address prefix. In EST renewal/rekeying, the ACP 4806 nodes current ACP domain certificate is signaled during the TLS 4807 handshake. 4809 This simple scenario has two limitations: 4811 1. The ACP registrars cannot directly assign certificates to nodes 4812 and therefore needs an "online" connection to the TA. 4814 2. Recovery from a compromised ACP registrar is difficult. When an 4815 ACP registrar is compromised, it can insert for example a 4816 conflicting acp-node-name and create thereby an attack against 4817 other ACP nodes through the ACP routing protocol. 4819 Even when such a malicious ACP registrar is detected, resolving the 4820 problem may be difficult because it would require identifying all the 4821 wrong ACP domain certificates assigned via the ACP registrar after it 4822 was compromised. And without additional centralized tracking of 4823 assigned certificates there is no way to do this. 4825 9.2.4. ACP Registrars with sub-CA 4827 In situations, where either of the above two limitations are an 4828 issue, ACP registrars could also be sub-CAs. This removes the need 4829 for connectivity to a TA whenever an ACP node is enrolled, and 4830 reduces the need for connectivity of such an ACP registrar to a TA to 4831 only those times when it needs to renew its own certificate. The ACP 4832 registrar would also now use its own (sub-CA) certificate to enroll 4833 and sign the ACP nodes certificates, and therefore it is only 4834 necessary to revoke a compromised ACP registrars sub-CA certificate. 4835 Alternatively one can let it expire and not renew it, when the 4836 certificate of the sub-CA is appropriately short-lived. 4838 As the ACP domain membership check verifies a peer ACP node's ACP 4839 domain certificate trust chain, it will also verify the signing 4840 certificate which is the compromised/revoked sub-CA certificate. 4841 Therefore ACP domain membership for an ACP node enrolled from a 4842 compromised and discovered ACP registrar will fail. 4844 ACP nodes enrolled by a compromised ACP registrar would automatically 4845 fail to establish ACP channels and ACP domain certificate renewal via 4846 EST and therefore revert to their role as a candidate ACP members and 4847 attempt to get a new ACP domain certificate from an ACP registrar - 4848 for example, via BRSKI. In result, ACP registrars that have an 4849 associated sub-CA makes isolating and resolving issues with 4850 compromised registrars easier. 4852 Note that ACP registrars with sub-CA functionality also can control 4853 the lifetime of ACP domain certificates easier and therefore also be 4854 used as a tool to introduce short lived certificates and not rely on 4855 CRL, whereas the certificates for the sub-CAs themselves could be 4856 longer lived and subject to CRL. 4858 9.2.5. Centralized Policy Control 4860 When using multiple, uncoordinated ACP registrars, several advanced 4861 operations are potentially more complex than with a single, resilient 4862 policy control backend, for example including but not limited to: 4864 Which candidate ACP node is permitted or not permitted into an ACP 4865 domain. This may not be a decision to be taken upfront, so that a 4866 per-"serialNumber" policy can be loaded into every ACP registrar. 4867 Instead, it may better be decided in real-time including 4868 potentially a human decision in a NOC. 4870 Tracking of all enrolled ACP nodes and their certificate 4871 information. For example in support of revoking individual ACP 4872 nodes certificates. 4874 More flexible policies what type of address prefix or even what 4875 specific address prefix to assign to a candidate ACP node. 4877 These and other operations could be introduced more easily by 4878 introducing a centralized Policy Management System (PMS) and 4879 modifying ACP registrar behavior so that it queries the PMS for any 4880 policy decision occurring during the candidate ACP node enrollment 4881 process and/or the ACP node certificate renewal process. For 4882 example, which ACP address prefix to assign. Likewise the ACP 4883 registrar would report any relevant state change information to the 4884 PMS as well, for example when a certificate was successfully enrolled 4885 onto a candidate ACP node. 4887 9.3. Enabling and disabling ACP/ANI 4889 Both ACP and BRSKI require interfaces to be operational enough to 4890 support sending/receiving their packets. In node types where 4891 interfaces are by default (e.g., without operator configuration) 4892 enabled, such as most L2 switches, this would be less of a change in 4893 behavior than in most L3 devices (e.g.: routers), where interfaces 4894 are by default disabled. In almost all network devices it is common 4895 though for configuration to change interfaces to a physically 4896 disabled state and that would break the ACP. 4898 In this section, we discuss a suggested operational model to enable/ 4899 disable interfaces and nodes for ACP/ANI in a way that minimizes the 4900 risk of operator action to break the ACP in this way, and that also 4901 minimizes operator surprise when ACP/ANI becomes supported in node 4902 software. 4904 9.3.1. Filtering for non-ACP/ANI packets 4906 Whenever this document refers to enabling an interface for ACP (or 4907 BRSKI), it only requires to permit the interface to send/receive 4908 packets necessary to operate ACP (or BRSKI) - but not any other Data- 4909 Plane packets. Unless the Data-Plane is explicitly configured/ 4910 enabled, all packets not required for ACP/BRSKI should be filtered on 4911 input and output: 4913 Both BRSKI and ACP require link-local only IPv6 operations on 4914 interfaces and DULL GRASP. IPv6 link-local operations means the 4915 minimum signaling to auto-assign an IPv6 link-local address and talk 4916 to neighbors via their link-local address: SLAAC (Stateless Address 4917 Auto-Configuration - [RFC4862]) and ND (Neighbor Discovery - 4918 [RFC4861]). When the device is a BRSKI pledge, it may also require 4919 TCP/TLS connections to BRSKI proxies on the interface. When the 4920 device has keying material, and the ACP is running, it requires DULL 4921 GRASP packets and packets necessary for the secure-channel mechanism 4922 it supports, e.g., IKEv2 and IPsec ESP packets or DTLS packets to the 4923 IPv6 link-local address of an ACP neighbor on the interface. It also 4924 requires TCP/TLS packets for its BRSKI proxy functionality, if it 4925 does support BRSKI. 4927 9.3.2. Admin Down State 4929 Interfaces on most network equipment have at least two states: "up" 4930 and "down". These may have product specific names. "down" for 4931 example could be called "shutdown" and "up" could be called "no 4932 shutdown". The "down" state disables all interface operations down 4933 to the physical level. The "up" state enables the interface enough 4934 for all possible L2/L3 services to operate on top of it and it may 4935 also auto-enable some subset of them. More commonly, the operations 4936 of various L2/L3 services is controlled via additional node-wide or 4937 interface level options, but they all become only active when the 4938 interface is not "down". Therefore an easy way to ensure that all 4939 L2/L3 operations on an interface are inactive is to put the interface 4940 into "down" state. The fact that this also physically shuts down the 4941 interface is in many cases just a side effect, but it may be 4942 important in other cases (see below, Section 9.3.2.2). 4944 To provide ACP/ANI resilience against operators configuring 4945 interfaces to "down" state, this document recommends to separate the 4946 "down" state of interfaces into an "admin down" state where the 4947 physical layer is kept running and ACP/ANI can use the interface and 4948 a "physical down" state. Any existing "down" configurations would 4949 map to "admin down". In "admin down", any existing L2/L3 services of 4950 the Data-Plane should see no difference to "physical down" state. To 4951 ensure that no Data-Plane packets could be sent/received, packet 4952 filtering could be established automatically as described above in 4953 Section 9.3.1. 4955 As necessary (see discussion below) new configuration options could 4956 be introduced to issue "physical down". The options should be 4957 provided with additional checks to minimize the risk of issuing them 4958 in a way that breaks the ACP without automatic restoration. For 4959 example they could be denied to be issued from a control connection 4960 (netconf/ssh) that goes across the interface itself ("do not 4961 disconnect yourself"). Or they could be performed only temporary and 4962 only be made permanent with additional later reconfirmation. 4964 In the following sub-sections important aspects to the introduction 4965 of "admin down" state are discussed. 4967 9.3.2.1. Security 4969 Interfaces are physically brought down (or left in default down 4970 state) as a form of security. "Admin down" state as described above 4971 provides also a high level of security because it only permits ACP/ 4972 ANI operations which are both well secured. Ultimately, it is 4973 subject to security review for the deployment whether "admin down" is 4974 a feasible replacement for "physical down". 4976 The need to trust the security of ACP/ANI operations needs to be 4977 weighed against the operational benefits of permitting this: Consider 4978 the typical example of a CPE (customer premises equipment) with no 4979 on-site network expert. User ports are in physical down state unless 4980 explicitly configured not to be. In a misconfiguration situation, 4981 the uplink connection is incorrectly plugged into such as user port. 4982 The device is disconnected from the network and therefore no 4983 diagnostics from the network side is possible anymore. 4984 Alternatively, all ports default to "admin down". The ACP (but not 4985 the Data-Plane) would still automatically form. Diagnostics from the 4986 network side is possible and operator reaction could include to 4987 either make this port the operational uplink port or to instruct re- 4988 cabling. Security wise, only ACP/ANI could be attacked, all other 4989 functions are filtered on interfaces in "admin down" state. 4991 9.3.2.2. Fast state propagation and Diagnostics 4993 "Physical down" state propagates on many interface types (e.g., 4994 Ethernet) to the other side. This can trigger fast L2/L3 protocol 4995 reaction on the other side and "admin down" would not have the same 4996 (fast) result. 4998 Bringing interfaces to "physical down" state is to the best of our 4999 knowledge always a result of operator action, but today, never the 5000 result of autonomic L2/L3 services running on the nodes. Therefore 5001 one option is to change the operator action to not rely on link-state 5002 propagation anymore. This may not be possible when both sides are 5003 under different operator control, but in that case it is unlikely 5004 that the ACP is running across the link and actually putting the 5005 interface into "physical down" state may still be a good option. 5007 Ideally, fast physical state propagation is replaced by fast software 5008 driven state propagation. For example a DULL GRASP "admin-state" 5009 objective could be used to auto configure a Bidirectional Forwarding 5010 Protocol (BFD, [RFC5880]) session between the two sides of the link 5011 that would be used to propagate the "up" vs. admin down state. 5013 Triggering physical down state may also be used as a mean of 5014 diagnosing cabling in the absence of easier methods. It is more 5015 complex than automated neighbor diagnostics because it requires 5016 coordinated remote access to both (likely) sides of a link to 5017 determine whether up/down toggling will cause the same reaction on 5018 the remote side. 5020 See Section 9.1 for a discussion about how LLDP and/or diagnostics 5021 via GRASP could be used to provide neighbor diagnostics, and 5022 therefore hopefully eliminating the need for "physical down" for 5023 neighbor diagnostics - as long as both neighbors support ACP/ANI. 5025 9.3.2.3. Low Level Link Diagnostics 5027 "Physical down" is performed to diagnose low-level interface behavior 5028 when higher layer services (e.g., IPv6) are not working. Especially 5029 Ethernet links are subject to a wide variety of possible wrong 5030 configuration/cablings if they do not support automatic selection of 5031 variable parameters such as speed (10/100/1000 Mbps), crossover 5032 (Auto-MDIX) and connector (fiber, copper - when interfaces have 5033 multiple but can only enable one at a time). The need for low level 5034 link diagnostic can therefore be minimized by using fully auto 5035 configuring links. 5037 In addition to "Physical down", low level diagnostics of Ethernet or 5038 other interfaces also involve the creation of other states on 5039 interfaces, such as physical Loopback (internal and/or external) or 5040 bringing down all packet transmissions for reflection/cable-length 5041 measurements. Any of these options would disrupt ACP as well. 5043 In cases where such low-level diagnostics of an operational link is 5044 desired but where the link could be a single point of failure for the 5045 ACP, ASA on both nodes of the link could perform a negotiated 5046 diagnostics that automatically terminates in a predetermined manner 5047 without dependence on external input ensuring the link will become 5048 operational again. 5050 9.3.2.4. Power Consumption Issues 5052 Power consumption of "physical down" interfaces, may be significantly 5053 lower than those in "admin down" state, for example on long-range 5054 fiber interfaces. Bringing up interfaces, for example to probe 5055 reachability, may also consume additional power. This can make these 5056 type of interfaces inappropriate to operate purely for the ACP when 5057 they are not currently needed for the Data-Plane. 5059 9.3.3. Interface level ACP/ANI enable 5061 The interface level configuration option "ACP enable" enables ACP 5062 operations on an interface, starting with ACP neighbor discovery via 5063 DULL GRAP. The interface level configuration option "ANI enable" on 5064 nodes supporting BRSKI and ACP starts with BRSKI pledge operations 5065 when there is no domain certificate on the node. On ACP/BRSKI nodes, 5066 "ACP enable" may not need to be supported, but only "ANI enable". 5067 Unless overridden by global configuration options (see later), "ACP/ 5068 ANI enable" will result in "down" state on an interface to behave as 5069 "admin down". 5071 9.3.4. Which interfaces to auto-enable? 5073 (Section 6.3) requires that "ACP enable" is automatically set on 5074 native interfaces, but not on non-native interfaces (reminder: a 5075 native interface is one that exists without operator configuration 5076 action such as physical interfaces in physical devices). 5078 Ideally, ACP enable is set automatically on all interfaces that 5079 provide access to additional connectivity that allows to reach more 5080 nodes of the ACP domain. The best set of interfaces necessary to 5081 achieve this is not possible to determine automatically. Native 5082 interfaces are the best automatic approximation. 5084 Consider an ACP domain of ACP nodes transitively connected via native 5085 interfaces. A Data-Plane tunnel between two of these nodes that are 5086 non-adjacent is created and "ACP enable" is set for that tunnel. ACP 5087 RPL sees this tunnel as just as a single hop. Routes in the ACP 5088 would use this hop as an attractive path element to connect regions 5089 adjacent to the tunnel nodes. In result, the actual hop-by-hop paths 5090 used by traffic in the ACP can become worse. In addition, correct 5091 forwarding in the ACP now depends on correct Data-Plane forwarding 5092 config including QoS, filtering and other security on the Data-Plane 5093 path across which this tunnel runs. This is the main issue why "ACP/ 5094 ANI enable" should not be set automatically on non-native interfaces. 5096 If the tunnel would connect two previously disjoint ACP regions, then 5097 it likely would be useful for the ACP. A Data-Plane tunnel could 5098 also run across nodes without ACP and provide additional connectivity 5099 for an already connected ACP network. The benefit of this additional 5100 ACP redundancy has to be weighed against the problems of relying on 5101 the Data-Plane. If a tunnel connects two separate ACP regions: how 5102 many tunnels should be created to connect these ACP regions reliably 5103 enough? Between which nodes? These are all standard tunneled 5104 network design questions not specific to the ACP, and there are no 5105 generic fully automated answers. 5107 Instead of automatically setting "ACP enable" on these type of 5108 interfaces, the decision needs to be based on the use purpose of the 5109 non-native interface and "ACP enable" needs to be set in conjunction 5110 with the mechanism through which the non-native interface is created/ 5111 configured. 5113 In addition to explicit setting of "ACP/ANI enable", non-native 5114 interfaces also need to support configuration of the ACP RPL cost of 5115 the link - to avoid the problems of attracting too much traffic to 5116 the link as described above. 5118 Even native interfaces may not be able to automatically perform BRSKI 5119 or ACP because they may require additional operator input to become 5120 operational. Example include DSL interfaces requiring PPPoE 5121 credentials or mobile interfaces requiring credentials from a SIM 5122 card. Whatever mechanism is used to provide the necessary config to 5123 the device to enable the interface can also be expanded to decide on 5124 whether or not to set "ACP/ANI enable". 5126 The goal of automatically setting "ACP/ANI enable" on interfaces 5127 (native or not) is to eliminate unnecessary "touches" to the node to 5128 make its operation as much as possible "zero-touch" with respect to 5129 ACP/ANI. If there are "unavoidable touches" such a creating/ 5130 configuring a non-native interface or provisioning credentials for a 5131 native interface, then "ACP/ANI enable" should be added as an option 5132 to that "touch". If a wrong "touch" is easily fixed (not creating 5133 another high-cost touch), then the default should be not to enable 5134 ANI/ACP, and if it is potentially expensive or slow to fix (e.g., 5135 parameters on SIM card shipped to remote location), then the default 5136 should be to enable ACP/ANI. 5138 9.3.5. Node Level ACP/ANI enable 5140 A node level command "ACP/ANI enable [up-if-only]" enables ACP or ANI 5141 on the node (ANI = ACP + BRSKI). Without this command set, any 5142 interface level "ACP/ANI enable" is ignored. Once set, ACP/ANI will 5143 operate an interface where "ACP/ANI enable" is set. Setting of 5144 interface level "ACP/ANI enable" is either automatic (default) or 5145 explicit through operator action as described in the previous 5146 section. 5148 If the option "up-if-only" is selected, the behavior of "down" 5149 interfaces is unchanged, and ACP/ANI will only operate on interfaces 5150 where "ACP/ANI enable" is set and that are "up". When it is not set, 5151 then "down" state of interfaces with "ACP/ANI enable" is modified to 5152 behave as "admin down". 5154 9.3.5.1. Brownfield nodes 5156 A "brownfield" node is one that already has a configured Data-Plane. 5158 Executing global "ACP/ANI enable [up-if-only]" on each node is the 5159 only command necessary to create an ACP across a network of 5160 brownfield nodes once all the nodes have a domain certificate. When 5161 BRSKI is used ("ANI enable"), provisioning of the certificates only 5162 requires set-up of a single BRSKI registrar node which could also 5163 implement a CA for the network. This is the most simple way to 5164 introduce ACP/ANI into existing (== brownfield) networks. 5166 The need to explicitly enable ACP/ANI is especially important in 5167 brownfield nodes because otherwise software updates may introduce 5168 support for ACP/ANI: Automatic enablement of ACP/ANI in networks 5169 where the operator does not only not want ACP/ANI but where the 5170 operator likely never even heard of it could be quite irritating to 5171 the operator. Especially when "down" behavior is changed to "admin 5172 down". 5174 Automatically setting "ANI enable" on brownfield nodes where the 5175 operator is unaware of BRSKI and MASA operations could also be an 5176 unlikely but then critical security issue. If an attacker could 5177 impersonate the operator and register as the operator at the MASA or 5178 otherwise get hold of vouchers and can get enough physical access to 5179 the network so pledges would register to an attacking registrar, then 5180 the attacker could gain access to the network through the ACP that 5181 the attacker then has access to. 5183 In networks where the operator explicitly wants to enable the ANI 5184 this could not happen, because the operator would create a BRSKI 5185 registrar that would discover attack attempts, and the operator would 5186 be setting up his registrar with the MASA. Nodes requiring 5187 "ownership vouchers" would not be subject to that attack. See 5188 [I-D.ietf-anima-bootstrapping-keyinfra] for more details. Note that 5189 a global "ACP enable" alone is not subject to these type of attacks, 5190 because it always depends on some other mechanism first to provision 5191 domain certificates into the device. 5193 9.3.5.2. Greenfield nodes 5195 A "greenfield" node is one that did not have any prior configuration. 5197 For greenfield nodes, only "ANI enable" is relevant. If another 5198 mechanism than BRSKI is used to (zero-touch) bootstrap a node, then 5199 it is up to that mechanism to provision domain certificates and to 5200 set global "ACP enable" as desired. 5202 Nodes supporting full ANI functionality set "ANI enable" 5203 automatically when they decide that they are greenfield, e.g., that 5204 they are powering on from factory condition. They will then put all 5205 native interfaces into "admin down" state and start to perform BRSKI 5206 pledge functionality - and once a domain certificate is enrolled they 5207 automatically enable ACP. 5209 Attempts for BRSKI pledge operations in greenfield state should 5210 terminate automatically when another method of configuring the node 5211 is used. Methods that indicate some form of physical possession of 5212 the device such as configuration via the serial console port could 5213 lead to immediate termination of BRSKI, while other parallel auto 5214 configuration methods subject to remote attacks might lead to BRSKI 5215 termination only after they were successful. Details of this may 5216 vary widely over different type of nodes. When BRSKI pledge 5217 operation terminates, this will automatically unset "ANI enable" and 5218 should terminate any temporarily needed state on the device to 5219 perform BRSKI - DULL GRASP, BRSKI pledge and any IPv6 configuration 5220 on interfaces. 5222 9.3.6. Undoing ANI/ACP enable 5224 Disabling ANI/ACP by undoing "ACP/ANI enable" is a risk for the 5225 reliable operations of the ACP if it can be executed by mistake or 5226 unauthorized. This behavior could be influenced through some 5227 additional (future) property in the certificate (e.g., in the acp- 5228 node-name extension field): In an ANI deployment intended for 5229 convenience, disabling it could be allowed without further 5230 constraints. In an ANI deployment considered to be critical more 5231 checks would be required. One very controlled option would be to not 5232 permit these commands unless the domain certificate has been revoked 5233 or is denied renewal. Configuring this option would be a parameter 5234 on the BRSKI registrar(s). As long as the node did not receive a 5235 domain certificate, undoing "ANI/ACP enable" should not have any 5236 additional constraints. 5238 9.3.7. Summary 5240 Node-wide "ACP/ANI enable [up-if-only]" commands enable the operation 5241 of ACP/ANI. This is only auto-enabled on ANI greenfield devices, 5242 otherwise it must be configured explicitly. 5244 If the option "up-if-only" is not selected, interfaces enabled for 5245 ACP/ANI interpret "down" state as "admin down" and not "physical 5246 down". In "admin-down" all non-ACP/ANI packets are filtered, but the 5247 physical layer is kept running to permit ACP/ANI to operate. 5249 (New) commands that result in physical interruption ("physical down", 5250 "loopback") of ACP/ANI enabled interfaces should be built to protect 5251 continuance or reestablishment of ACP as much as possible. 5253 Interface level "ACP/ANI enable" control per-interface operations. 5254 It is enabled by default on native interfaces and has to be 5255 configured explicitly on other interfaces. 5257 Disabling "ACP/ANI enable" global and per-interface should have 5258 additional checks to minimize undesired breakage of ACP. The degree 5259 of control could be a domain wide parameter in the domain 5260 certificates. 5262 9.4. Partial or Incremental adoption 5264 The ACP Zone Addressing Sub-Scheme (see Section 6.10.3) allows 5265 incremental adoption of the ACP in a network where ACP can be 5266 deployed on edge areas, but not across the core that is connecting 5267 those edges. 5269 In such a setup, each edge network, such as a branch or campus of an 5270 enterprise network has a disjoined ACP to which one or more unique 5271 Zone-IDs are assigned: ACP nodes registered for a specific ACP zone 5272 have to receive ACP Zone Addressing Sub-scheme addresses, for example 5273 by virtue of configuring for each such zone one or more ACP 5274 Registrars with that Zone-ID. All the Registrars for these ACP Zones 5275 need to get ACP certificates from CAs relying on a common set of TA 5276 and of course the same ACP domain name. 5278 These ACP zones can first be brought up as separate networks without 5279 any connection between them and/or they can be connected across a 5280 non-ACP enabled core network through various non-autonomic 5281 operational practices. For example, each separate ACP Zone can have 5282 an edge node that is a layer 3 VPN PE (MPLS or IPv6 layer 3 VPN), 5283 where a complete non-autonomic ACP-Core VPN is created by using the 5284 ACP VRFs and exchanging the routes from those ACP VRFs across the 5285 VPNs non-autonomic routing protocol(s). 5287 While such a setup is possible with any ACP addressing sub-scheme, 5288 the ACP-Zone Addressing sub-scheme makes it easy to configure and 5289 scalable for any VPN routing protocols because every ACP zone would 5290 only need to indicate one or more /64 ACP Zone Addressing prefix 5291 routes into the ACP-Core VPN as opposed to routes for every 5292 individual ACP node as required in the other ACP addressing schemes. 5294 Note that the non-autonomous ACP-Core VPN would require additional 5295 extensions to propagate GRASP messages when GRASP discovery is 5296 desired across the zones. For example, one could set up on each Zone 5297 edge router remote ACP tunnel to an appplication level implemented 5298 GRASP hub running in the networks NOC that is generating GRASP 5299 announcements for NOC services into the ACP Zones or propagating them 5300 between ACP Zones. 5302 Such partial deployment may prove to be sufficient or could evolve to 5303 become more autonomous through future standardized or non- 5304 standardized enhancements, for example by allowing GRASP messages to 5305 be propagated across the layer 3 VPN, leveraging for example L3VPN 5306 Multicast support. 5308 Finally, these partial deployments can be merged into a single 5309 contiguous complete autonomous ACP (given appropriate ACP support 5310 across the core) without changes in the crypto material, because the 5311 nodes ACP certificates are fromm a single ACP. 5313 9.5. Configuration and the ACP (summary) 5315 There is no desirable configuration for the ACP. Instead, all 5316 parameters that need to be configured in support of the ACP are 5317 limitations of the solution, but they are only needed in cases where 5318 not all components are made autonomic. Whereever this is necessary, 5319 it relies on pre-existing mechanisms for configuration such as CLI or 5320 YANG ([RFC7950]) data models. 5322 The most important examples of such configuration include: 5324 o When ACP nodes do not support an autonomic way to receive an ACP 5325 domain certificate, for example BRSKI, then such certificate needs 5326 to be configured via some pre-existing mechanisms outside the 5327 scope of this specification. Today, router have typically a 5328 variety of mechanisms to do this. 5330 o Certificate maintenance requires PKI functions. Discovery of 5331 these functions across the ACP is automated (see Section 6.1.5), 5332 but their configuration is not. 5334 o When non-ACP capable nodes such as pre-existing NMS need to be 5335 physically connected to the ACP, the ACP node to which they attach 5336 needs to be configured with ACP-connect according to Section 8.1. 5337 It is also possible to use that single physical connection to 5338 connect both to ACP and the Data-Plane of the network as explained 5339 in Section 8.1.4. 5341 o When devices are not autonomically bootstrapped, explicit 5342 configuration to enable the ACP needs to be applied. See 5343 Section 9.3. 5345 o When the ACP needs to be extended across interfacess other than 5346 L2, the ACP as defined in this document can not autodiscover 5347 candidate neighbors automatically. Remote neighbors need to be 5348 configured, see Section 8.2. 5350 Once the ACP is operating, any further configuration for the Data- 5351 Plane can be configured more reliably across the ACP itself because 5352 the ACP provides addressing and connectivity (routing) independent of 5353 the Data-Plane itself. For this, the configuration methods simply 5354 need to also allow to operate across the ACP VRF - netconf, ssh or 5355 any other method. 5357 The ACP also provides additional security through its hop-by-hop 5358 encryption for any such configuration operations: Some legacy 5359 configuration methods (SNMP, TFTP, HTTP) may not use end-to-end 5360 encryption, and most of the end-to-end secured configuration methods 5361 still allow for easy passive observation along the path about 5362 configuration taking place (transport flows, port numbers, IP 5363 addresses). 5365 The ACP can and should equally be used as the transport to configure 5366 any of the aforemention non-automic components of the ACP, but in 5367 that case, the same caution needs to be exercised as with Data-Plane 5368 configuration without ACP: Misconfiguration may cause the configuring 5369 entity to be disconnected from the node it configures - for example 5370 when incorrectly unconfiguring a remote ACP neighbor through which 5371 the configured ACP node is reached. 5373 10. Summary: Benefits (Informative) 5374 10.1. Self-Healing Properties 5376 The ACP is self-healing: 5378 o New neighbors will automatically join the ACP after successful 5379 validation and will become reachable using their unique ULA 5380 address across the ACP. 5382 o When any changes happen in the topology, the routing protocol used 5383 in the ACP will automatically adapt to the changes and will 5384 continue to provide reachability to all nodes. 5386 o The ACP tracks the validity of peer certificates and tears down 5387 ACP secure channels when a peer certificate has expired. When 5388 short-lived certificates with lifetimes in the order of OCSP/CRL 5389 refresh times are used, then this allows for removal of invalid 5390 peers (whose certificate was not renewed) at similar speeds as 5391 when using OCSP/CRL. The same benefit can be achieved when using 5392 CRL/OCSP, periodically refreshing the revocation information and 5393 also tearing down ACP secure channels when the peer's (long-lived) 5394 certificate is revoked. There is no requirement against ACP 5395 implementations to require this enhancement though to keep the 5396 mandatory implementations simpler. 5398 The ACP can also sustain network partitions and mergers. Practically 5399 all ACP operations are link local, where a network partition has no 5400 impact. Nodes authenticate each other using the domain certificates 5401 to establish the ACP locally. Addressing inside the ACP remains 5402 unchanged, and the routing protocol inside both parts of the ACP will 5403 lead to two working (although partitioned) ACPs. 5405 There are few central dependencies: A CRL may not be available during 5406 a network partition; a suitable policy to not immediately disconnect 5407 neighbors when no CRL is available can address this issue. Also, an 5408 ACP Registrar or Certification Authority might not be available 5409 during a partition. This may delay renewal of certificates that are 5410 to expire in the future, and it may prevent the enrollment of new 5411 nodes during the partition. 5413 Highly resilient ACP designs can be built by using ACP Registrars 5414 with embedded sub-CA, as outlined in Section 9.2.4. As long as a 5415 partition is left with one or more of such ACP Registrars, it can 5416 continue to enroll new candidate ACP nodes as long as the ACP 5417 Registrar's sub-CA certificate does not expire. Because the ACP 5418 addressing relies on unique Registrar-IDs, a later re-merge of 5419 partitions will also not cause problems with ACP addresses assigned 5420 during partitioning. 5422 After a network partition, a re-merge will just establish the 5423 previous status, certificates can be renewed, the CRL is available, 5424 and new nodes can be enrolled everywhere. Since all nodes use the 5425 same TA, a re-merge will be smooth. 5427 Merging two networks with different TA requires the ACP nodes to 5428 trust the union of TA. As long as the routing-subdomain hashes are 5429 different, the addressing will not overlap, which only happens in the 5430 unlikely event of a 40-bit hash collision in SHA256 (see 5431 Section 6.10). Note that the complete mechanisms to merge networks 5432 is out of scope of this specification. 5434 It is also highly desirable for implementation of the ACP to be able 5435 to run it over interfaces that are administratively down. If this is 5436 not feasible, then it might instead be possible to request explicit 5437 operator override upon administrative actions that would 5438 administratively bring down an interface across which the ACP is 5439 running. Especially if bringing down the ACP is known to disconnect 5440 the operator from the node. For example any such down administrative 5441 action could perform a dependency check to see if the transport 5442 connection across which this action is performed is affected by the 5443 down action (with default RPL routing used, packet forwarding will be 5444 symmetric, so this is actually possible to check). 5446 10.2. Self-Protection Properties 5448 10.2.1. From the outside 5450 As explained in Section 6, the ACP is based on secure channels built 5451 between nodes that have mutually authenticated each other with their 5452 domain certificates. The channels themselves are protected using 5453 standard encryption technologies such as DTLS or IPsec which provide 5454 additional authentication during channel establishment, data 5455 integrity and data confidentiality protection of data inside the ACP 5456 and in addition, provide replay protection. 5458 An attacker will not be able to join the ACP unless having a valid 5459 domain certificate, also packet injection and sniffing traffic will 5460 not be possible due to the security provided by the encryption 5461 protocol. 5463 The ACP also serves as protection (through authentication and 5464 encryption) for protocols relevant to OAM that may not have secured 5465 protocol stack options or where implementation or deployment of those 5466 options fail on some vendor/product/customer limitations. This 5467 includes protocols such as SNMP ([RFC3411]), NTP ([RFC5905]), PTP 5468 ([IEEE-1588-2008]), DNS ([RFC3596]), DHCPv6 ([RFC3315]), syslog 5469 ([RFC3164]), Radius ([RFC2865]), Diameter ([RFC6733]), TACACS 5470 ([RFC1492]), IPFIX ([RFC7011]), Netflow ([RFC3954]) - just to name a 5471 few. Not all of these protocol references are necessarily the latest 5472 version of protocols but versions that are still widely deployed. 5474 Protection via the ACP secure hop-by-hop channels for these protocols 5475 is meant to be only a stopgap though: The ultimate goal is for these 5476 and other protocols to use end-to-end encryption utilizing the domain 5477 certificate and rely on the ACP secure channels primarily for zero- 5478 touch reliable connectivity, but not primarily for security. 5480 The remaining attack vector would be to attack the underlying ACP 5481 protocols themselves, either via directed attacks or by denial-of- 5482 service attacks. However, as the ACP is built using link-local IPv6 5483 addresses, remote attacks from the Data-Plane are impossible as long 5484 as the Data-Plane has no facilities to remotely sent IPv6 link-local 5485 packets. The only exception are ACP connected interfaces which 5486 require higher physical protection. The ULA addresses are only 5487 reachable inside the ACP context, therefore, unreachable from the 5488 Data-Plane. Also, the ACP protocols should be implemented to be 5489 attack resistant and not consume unnecessary resources even while 5490 under attack. 5492 10.2.2. From the inside 5494 The security model of the ACP is based on trusting all members of the 5495 group of nodes that receive an ACP domain certificate for the same 5496 domain. Attacks from the inside by a compromised group member are 5497 therefore the biggest challenge. 5499 Group members must be protected against attackers so that there is no 5500 easy way to compromise them, or use them as a proxy for attacking 5501 other devices across the ACP. For example, management plane 5502 functions (transport ports) should only be reachable from the ACP but 5503 not the Data-Plane. Especially for those management plane functions 5504 that have no good protection by themselves because they do not have 5505 secure end-to-end transport and to whom ACP not only provides 5506 automatic reliable connectivity but also protection against attacks. 5507 Protection across all potential attack vectors is typically easier to 5508 do in devices whose software is designed from the ground up with 5509 security in mind than with legacy software based systems where the 5510 ACP is added on as another feature. 5512 As explained above, traffic across the ACP SHOULD still be end-to-end 5513 encrypted whenever possible. This includes traffic such as GRASP, 5514 EST and BRSKI inside the ACP. This minimizes man in the middle 5515 attacks by compromised ACP group members. Such attackers cannot 5516 eavesdrop or modify communications, they can just filter them (which 5517 is unavoidable by any means). 5519 See Appendix A.10.8 for further considerations how to avoid and deal 5520 with compromised nodes. 5522 10.3. The Administrator View 5524 An ACP is self-forming, self-managing and self-protecting, therefore 5525 has minimal dependencies on the administrator of the network. 5526 Specifically, since it is (intended to be) independent of 5527 configuration, there is only limited scope for configuration errors 5528 on the ACP itself. The administrator may have the option to enable 5529 or disable the entire approach, but detailed configuration is not 5530 possible. This means that the ACP must not be reflected in the 5531 running configuration of nodes, except a possible on/off switch (and 5532 even that is undesirable). 5534 While configuration (except for Section 8 and Section 9.2) is not 5535 possible, an administrator must have full visibility of the ACP and 5536 all its parameters, to be able to do trouble-shooting. Therefore, an 5537 ACP must support all show and debug options, as for any other network 5538 function. Specifically, a network management system or controller 5539 must be able to discover the ACP, and monitor its health. This 5540 visibility of ACP operations must clearly be separated from 5541 visibility of Data-Plane so automated systems will never have to deal 5542 with ACP aspects unless they explicitly desire to do so. 5544 Since an ACP is self-protecting, a node not supporting the ACP, or 5545 without a valid domain certificate cannot connect to it. This means 5546 that by default a traditional controller or network management system 5547 cannot connect to an ACP. See Section 8.1.1 for more details on how 5548 to connect an NMS host into the ACP. 5550 11. Security Considerations 5552 After seeding an ACP by configuring at least one ACP registrar with 5553 routing-subdomain and a CA, an ACP is self-protecting and there is no 5554 need to apply configuration to make it secure (typically the ACP 5555 Registrar doubles as EST server for certificate renewal). Its 5556 security therefore does not depend on configuration. This does not 5557 include workarounds for non-autonomic components as explained in 5558 Section 8. See Section 10.2 for details of how the ACP protects 5559 itself against attacks from the outside and to a more limited degree 5560 from the inside as well. 5562 However, the security of the ACP depends on a number of other 5563 factors: 5565 o The usage of domain certificates depends on a valid supporting PKI 5566 infrastructure. If the chain of trust of this PKI infrastructure 5567 is compromised, the security of the ACP is also compromised. This 5568 is typically under the control of the network administrator. 5570 o Every ACP registrar is criticial infrastructure that needs to be 5571 hardened against attacks, similar to a CA. A malicious registrar 5572 can enroll enemy plegdes to an ACP network or break ACP routing by 5573 duplicate ACP address assignment to pledges via their ACP domain 5574 certificates. 5576 o Security can be compromised by implementation errors (bugs), as in 5577 all products. 5579 There is no prevention of source-address spoofing inside the ACP. 5580 This implies that if an attacker gains access to the ACP, it can 5581 spoof all addresses inside the ACP and fake messages from any other 5582 node. 5584 The ACP is designed to enable automation of current network 5585 management and future autonomic peer-to-peer/distributed network 5586 automation. Any ACP member can send ACP IPv6 packet to other ACP 5587 members and announce via ACP GRASP services to all ACP members 5588 without depenency against centralized components. 5590 The ACP relies on peer-to-peer authentication and authorization using 5591 ACP certificates. This security model is necessary to enable the 5592 autonomic ad-hoc any-to-any connectivity between ACP nodes. It 5593 provides infrastructure protection through hop by hop authentication 5594 and encryption - without relying on third parties. For any services 5595 where this complete autonomic peer-to-peer group security model is 5596 appropriate, the ACP domain certificate can also be used unchanged. 5597 For example for any type of Data-Plane routing protocol security. 5599 This ACP security model is designed primarily to protect against 5600 attack from the outside, but not against attacks from the inside. To 5601 protect against spoofing attacks from compromised on-path ACP nodes, 5602 end-to-end encryption inside the ACP is used by new ACP signaling: 5603 GRASP across the ACP using TLS. The same is expected from any non- 5604 legacy services/protocols using the ACP. Because no group-keys are 5605 used, there is no risk for impacted nodes to access end-to-end 5606 encrypted traffic from other ACP nodes. 5608 Attacks from impacted ACP nodes against the ACP are more difficult 5609 than against the Data-Plane because of the autoconfiguration of the 5610 ACP and the absence of configuration options that could be abused 5611 that allow to change/break ACP behavior. This is excluding 5612 configuration for workaround in support of non-autonomic components. 5614 Mitigation against compromised ACP members is possible through 5615 standard automated certificate management mechanisms including 5616 revocation and non-renewal of short-lived certificates. In this 5617 version of the specification, there are no further optimization of 5618 these mechanisms defined for the ACP (but see Appendix A.10.8). 5620 Higher layer service built using ACP domain certificates should not 5621 solely rely on undifferentiated group security when another model is 5622 more appropriate/more secure. For example central network 5623 configuration relies on a security model where only few especially 5624 trusted nodes are allowed to configure the Data-Plane of network 5625 nodes (CLIL, Netconf). This can be done through ACP domain 5626 certificates by differentiating them and introduce roles. See 5627 Appendix A.10.5. 5629 Fundamentally, security depends on avoiding operator and network 5630 operations automation mistakes, implementation and architecture. 5631 Autonomic approaches such as the ACP largely eliminate operator 5632 mistakes and make it easier to recover from network operations 5633 mistakes. Implementation and architectural mistakes are still 5634 possible, as in all networking technologies. 5636 Many details of ACP are designed with security in mind and discussed 5637 elsewhere in the document: 5639 IPv6 addresses used by nodes in the ACP are covered as part of the 5640 node's domain certificate as described in Section 6.1.2. This allows 5641 even verification of ownership of a peer's IPv6 address when using a 5642 connection authenticated with the domain certificate. 5644 The ACP acts as a security (and transport) substrate for GRASP inside 5645 the ACP such that GRASP is not only protected by attacks from the 5646 outside, but also by attacks from compromised inside attackers - by 5647 relying not only on hop-by-hop security of ACP secure channels, but 5648 adding end-to-end security for those GRASP messages. See 5649 Section 6.8.2. 5651 ACP provides for secure, resilient zero-touch discovery of EST 5652 servers for certificate renewal. See Section 6.1.5. 5654 ACP provides extensible, auto-configuring hop-by-hop protection of 5655 the ACP infrastructure via the negotiation of hop-by-hop secure 5656 channel protocols. See Section 6.5. 5658 The ACP is designed to minimize attacks from the outside by 5659 minimizing its dependency against any non-ACP (Data-Plane) 5660 operations/configuration on a node. See also Section 6.12.2. 5662 In combination with BRSKI, ACP enables a resilient, fully zero-touch 5663 network solution for short-lived certificates that can be renewed or 5664 re-enrolled even after unintentional expiry (e.g., because of 5665 interrupted connectivity). See Appendix A.2. 5667 Because ACP secure channels can be long lived, but certificates used 5668 may be short lived, secure channels, for example built via IPsec need 5669 to be terminated when peer certificates expire. See Section 6.7.5. 5671 The ACP is designed to minimize attacks from the outside by 5672 minimizing its dependency against any non-ACP (Data-Plane) 5673 operations/configuration on a node. See also Section 6.12.2. 5675 Section 7.2 describes how to implement a routed ACP topology 5676 operating on what effectively is a large bridge-domain when using L3/ 5677 L2 routers that operate at L2 in the Data-Plane. In this case, the 5678 ACP is subject to much higher likelyhood of attacks by other nodes 5679 "stealing" L2 addresses than in the actual routed case. Especially 5680 when the bridged network includes non-trusted devices such as hosts. 5681 This is a generic issue in L2 LANs. L2/L3 devices often already have 5682 some form of "port security" to prohibit this. They rely on NDP or 5683 DHCP learning of which port/MAC-address and IPv6 address belong 5684 together and block MAC/IPv6 source addresses from wrong ports. This 5685 type of function needs to be enabled to prohibit DoS attacks and 5686 specifically to protect the ACP. Likewise the GRASP DULL instance 5687 needs to ensure that the IPv6 address in the locator-option matches 5688 the source IPv6 address of the DULL GRASP packet. 5690 12. IANA Considerations 5692 This document defines the "Autonomic Control Plane". 5694 For the ANIMA-ACP-2020 ASN.1 module, IANA is asked to register value 5695 IANA1 for "id-mod-anima-acpnodename-2020" in the "SMI Security for 5696 PKIX Module Identifier" (1.3.6.1.5.5.7.0) registry. 5698 For the otherName / AcpNodeName, IANA is asked to register a value 5699 for IANA2 for id-on-AcpNodeName in the "SMI Security for PKIX Other 5700 Name Forms" (1.3.6.1.5.5.7.8) registry. 5702 The IANA is requested to register the value "AN_ACP" (without quotes) 5703 to the GRASP Objectives Names Table in the GRASP Parameter Registry. 5704 The specification for this value is this document, Section 6.3. 5706 The IANA is requested to register the value "SRV.est" (without 5707 quotes) to the GRASP Objectives Names Table in the GRASP Parameter 5708 Registry. The specification for this value is this document, 5709 Section 6.1.5. 5711 Explanation: This document chooses the initially strange looking 5712 format "SRV." because these objective names would be in 5713 line with potential future simplification of the GRASP objective 5714 registry. Today, every name in the GRASP objective registry needs to 5715 be explicitly allocated with IANA. In the future, this type of 5716 objective names could considered to be automatically registered in 5717 that registry for the same service for which is 5718 registered according to [RFC6335]. This explanation is solely 5719 informational and has no impact on the requested registration. 5721 The IANA is requested to create an ACP Parameter Registry with 5722 currently one registry table - the "ACP Address Type" table. 5724 "ACP Address Type" Table. The value in this table are numeric values 5725 0...3 paired with a name (string). Future values MUST be assigned 5726 using the Standards Action policy defined by [RFC8126]. The 5727 following initial values are assigned by this document: 5729 0: ACP Zone Addressing Sub-Scheme (ACP RFC Figure 11) / ACP Manual 5730 Addressing Sub-Scheme (ACP RFC Section 6.10.4) 5731 1: ACP Vlong Addressing Sub-Scheme (ACP RFC Section 6.10.5) 5733 13. Acknowledgements 5735 This work originated from an Autonomic Networking project at Cisco 5736 Systems, which started in early 2010. Many people contributed to 5737 this project and the idea of the Autonomic Control Plane, amongst 5738 which (in alphabetical order): Ignas Bagdonas, Parag Bhide, Balaji 5739 BL, Alex Clemm, Yves Hertoghs, Bruno Klauser, Max Pritikin, Michael 5740 Richardson, Ravi Kumar Vadapalli. 5742 Special thanks to Brian Carpenter, Elwyn Davies, Joel Halpern and 5743 Sheng Jiang for their thorough reviews and to Pascal Thubert and 5744 Michael Richardson to provide the details for the recommendations of 5745 the use of RPL in the ACP. 5747 Many thanks Ben Kaduk and Eric Rescorla for their thorough SEC AD 5748 reviews and to Valery Smyslov, Tero Kivinen, Paul Wouters and Yoav 5749 Nir for review of IPsec and IKEv2 parameters and helping to 5750 understand those and other security protocol details better. 5752 Further input, review or suggestions were received from: Rene Struik, 5753 Brian Carpenter, Benoit Claise, William Atwood and Yongkang Zhang. 5755 14. Change log [RFC Editor: Please remove] 5757 14.1. Summary of changes since entering IESG review 5759 This text replaces the prior changelog with a summary to provide 5760 guidance for further IESG review. 5762 Please see revision -21 for the individual changelogs of prior 5763 versions . 5765 14.1.1. Reviews (while in IESG review status) / status 5767 This document entered IESG review with version -13. It has since 5768 seen the following reviews: 5770 IESG: Original owner/Yes: Terry Manderson (INT). 5772 IESG: No Objection: Deborah Brungard (RTG), Alissa Cooper (GEN), 5773 Warren Kumari (OPS), Mirja Kuehlewind (TSV), Alexey Melnikov (ART), 5774 Adam Roach (ART). 5776 IESG: No Objection, not counted anymore as they have left IESG: Ben 5777 Campbell (ART), Spencer Dawkins (TSV). 5779 IESG: Open DISCUSS hopefully resolved by this version: Eric Rescorla 5780 (SEC, left IESG), Benjamin Kaduk (SEC). 5782 Other: Michael Richardson (WG), Brian Carpenter (WG), Pascal Thubert 5783 (WG), Frank Xialiang (WG), Elwyn Davies (GEN), Joel Halpern (RTGdir), 5784 Yongkang Zhang (WG), William Atwood (WG). 5786 14.1.2. BRSKI / ACP registrar related enhancements 5788 Only after ACP entered IESG review did it become clear that the in- 5789 progress BRSKI document would not provide all the explanations needed 5790 for ACP registrars as expected earlier by ACP authors. Instead, 5791 BRSKI will only specify a subset of required ACP behavior related to 5792 certificate handling and registrar. There, it became clear that the 5793 ACP draft should specify generic ACP registrar behavior independent 5794 of BRSKI so ACP could be implemented with or without BRSKI and any 5795 manual/proprietary or future standardized BRSKI alternatives (for 5796 example via NetConf) would understand the requirements for ACP 5797 registrars and its certificate handling. 5799 This lead to additional text about ACP registrars in the ACP 5800 document: 5802 1. Defined relationship ACP / ANI (ANI = ACP + BRSKI). 5804 6.1.4 (new) Overview of TA required for ACP. 5806 6.1.5.5 Added explanations/requirements for Re-enrolment. 5808 6.10.7 Normative requirements for ACP registrars (BRSKI or not). 5810 10.2 Operational expectations against ACP registrars (BRSKI or not). 5812 14.1.3. Normative enhancements since start of IESG review 5814 In addition to above ACP registrar / BRSKI related enhancements there 5815 is a range of minor normative (also explanatory) enhancements since 5816 the start of IESG review: 5818 6.1.1 Hex digits in ACP domain information field now upper-case (no 5819 specific reason except that both options are equally good, but 5820 capitalized ones are used in rfc5234). 5822 6.1.5.3 Added explanations about CRLs. 5824 6.1.5.6 Added explanations of behavior under failing certificates. 5826 6.1.2 Allow ACP adddress '0' in ACP domain information field: 5827 presence of address indicates permission to build ACP secure channel 5828 to node, 0 indicates that the address of the node is assigned by 5829 (future) other means than certificate. Non-autonomic nodes have no 5830 address at all (that was in -13), and can only connect via ACP 5831 connect interfaces to ACP. 5833 6.1.3 Distinction of real ACP nodes (with address) and those with 5834 domain certificate without address added as a new rule to ACP domain 5835 membership check. 5837 6.6 Added throttling of secure-channel setup attempts. 5839 6.11.1.14 Removed requirement to handle unknown destination ACP 5840 traffic in low-end nodes that would never be RPL roots. 5842 6.12.5 Added recommendation to use IPv6 DAD. 5844 6.1.1, 6.7.1.1, 6.7.2, 6.7.3, 6.8.2 Various refined additional 5845 certificate, secure channel protocol (IPsec/IKEv2 and DTLS) and ACP 5846 GRASP TLS protocol parameter requirements to ensure interoperating 5847 implementations (from SEC-AD review). 5849 14.1.4. Explanatory enhancements since start of IESG review 5851 Beyond the functional enhancements from the previous two sections, 5852 the mayority of changes since -13 are additional explanations from 5853 review feedback, textual nits and restructuring - with no functional 5854 requirement additions/changes. 5856 1.1 Added "applicability and scope" section with summarized 5857 explanations. 5859 2.Added in-band vs. out-of-band management definitions. 5861 6.1.2 (was 6.1.1) expanded explanations of reasoning for elements of 5862 the ACP domain information field. 5864 6.1.3 refined explanations of ACP domain membership check and 5865 justifications for it. 5867 6.5 Elaborated step-by-step secure channel setup. 5869 6.10 Additional explanations for addressing modes, additional table 5870 of addressing formats (thanks MichaelR). 5872 6.10.5 introduced 'F' bit position as a better visual representation 5873 in the Vlong address space. 5875 6.11.1.1 extensive overhaul to improve readability of use of RPL 5876 (from IESG feedback of non-routing/RPL experts). 5878 6.12.2 Added caution about unconfiguring Data-Plane IPv6 addresses 5879 and impact to ACP (limitation of current ACP design, and pointint to 5880 more details in 10.2). 5882 10.4 New explanations / summary of configurations for ACP (aka: all 5883 config is undesirable and only required for integrating with non- 5884 autonomic components, primarily ACP-connect and Registrars). 5886 11. Textually enhanced / better structured security considerations 5887 section after IESG security review. 5889 A. (new) Moved all explanations and discussions about futures from 5890 section 10 into this new appendix. This text should not be removed 5891 because it captures a lot of repeated asked questions in WG and 5892 during reviews and from users, and also captures ideas for some 5893 likely important followup work. But none of this is relevant to 5894 implementing (section 6) and operating (section 10) the ACP. 5896 14.2. draft-ietf-anima-autonomic-control-plane-26 5898 Russ Housley review of -25. 5900 1.1 Explicit reference for TLS 1.2 RFC. 5902 2. Changed term of "ACP Domain Information" to AcpNodeName (ASN.1) / 5903 acp-node-name (ABNF), also through rest of document. 5905 2. Improved CA behavior definition. changed IDevID/LDevID to IDevID/ 5906 LDevID certificate to be more unambiguous. 5908 2. Changed definition of root CA to just refer to how its used in 5909 RFC7030 CA root key update, because thats the only thing relevant to 5910 ACP. 5912 6.1.1 Moved ECDH requirement to end of text as it was not related to 5913 the subject of the initial paragraps. Likewise reference to 5914 CABFORUM. 5916 6.1.1 Reduced cert key requirements to only be MUST for certs with 5917 2048 RSA public key and P-256 curves. Reduced longer keys to SHOULD. 5919 6.1.2 Changed text for conversion from rfc822Name to otherName / 5920 AcpNode, removed all the explanations of benefits coming with 5921 rfc822Name *sob* *sob* *sob*. 5923 6.1.2.1 New ASN.1 definition for otherName / AcpNodeName. 5925 6.1.3 Fixed up text. re the handling of missing connectivity for 5926 CRLDP / OCSP. 5928 6.1.4 Fixed up text re. inability to use public CA to situation with 5929 otherName / AcpNodeName (no more ACME rfc822Name validation for us 5930 *sob* *sob* *sob*). 5932 12. Added ASN.1 registration requests to IANA section. 5934 Appenices. Minor changes for rfc822Name to otherName change. 5936 Various minor verbal fixes/enhancements. 5938 14.3. draft-ietf-anima-autonomic-control-plane-25 5940 Crypto parameter discuss from Valery Smyslov and Paul Wouters and 5941 resulting changes. 5943 6.7.2 Moved Michael Richardson suggested diagnostic of signaling TA 5944 from IPsec section to this general requirements section and added 5945 explanation how this may be inappropriate if TA payload is considered 5946 secret by TA owner. 5948 6.7.3.1 Added traffic selectors for native IPsec. Improved text 5949 explanation. 5951 6.7.3.1.2 removed misleading text about signaling TA when using 5952 intermediate certs. 5954 6.7.3.1.2 Removed requirement for 'PKCS #7 wrapped X.509 certificate' 5955 requirement on request of Valery Smyslov as it is not defined in 5956 RFC7296 and there are enough options mandated in RFC7296. Replaced 5957 with just informative text to educate readers who are not IPsec 5958 experts what the mandatory option in RFC7296 is that allows to signal 5959 certificates. 5961 6.7.3.1.2 Added SHOULD requirement how to deal with CERTREQ so that 5962 6.7.2 requirement for TA diagnostics will work in IKEv2 (ignoring 5963 CERTREQ is permitted by IKEv2). Added explanation how this will 5964 result in TA cert diagnostics. 5966 6.7.3.1.2 Added requirement for IKEv2 to operate on link-local 5967 addresses for ACP so at to assume ACT cert as the only possible 5968 authenticator - to avoid potentialy failing section from multiple 5969 available certs on a router. 5971 6.7.3.1.2 fixed PKIX- style OID to ASN.1 object AlgorithmIdentifier 5972 (Paul). 5974 6.7.3.2 Added IPsec traffic selectors for IPsec with GRE. 5976 6.7.5 Added notion that IPsec/GRE MAY be preferred over IPsec/native. 5977 Luckily IPsec/native uses tunneling, whereas IPsec/GRE uses transport 5978 mode, and there is a long discuss whether it is permitted to even 5979 build IPsec connectings that only support transports instead of 5980 always being able to fall back to tunnel mode. Added explanatory 5981 paragraph why ACP nodes may prefer GRE over native (wonder how that 5982 was missing..). 5984 9.1.1 Added section to explain need for secure channel peer 5985 diagnostics via signaling of TA. Four examples given. 5987 Paul Wouters mentioned that ipkcs7 had to be used in some interop 5988 cases with windows CA, but that is an issue of ACP Registrar having 5989 to convert into PKCS#7 to talk to a windows CA, and this spec is not 5990 concerned with that, except to know that it is feasible, so not 5991 mentioned in text anywhere, just tracking discussion here in 5992 changelog. 5994 Michael Richardson: 5996 3.1.3 Added point in support of rfc822address that CA may not support 5997 to sign certificates with new attributes (such as new otherName). 5999 Michael Richardson/Brian Carpenter fix: 6001 6.1.5.1/6.3 Fixed GRASP examples. 6003 Joe Halpern review: 6005 1. Enhanded introduction text for in-band and of out-of-band, 6006 explaining how ACP is an in-band network aiming to achieve all 6007 possible benefits of an out-of-band network. 6009 1. Comprehensive explanation for term Data-Plane as it is only 6010 logically following pre-established terminology on a fully autonomic 6011 node, when used for existing nodes augmented with ACP, Data-Plane has 6012 more functionality than usually associated with the term. 6014 2. Removed explanatory text for Data-Plane, referring to section 1. 6016 2. Reduced explanation in definition of in-band (management/ 6017 signaling), out-of-band-signaling, now pointing to section 1. 6019 5. Rewrote a lot of the steps (overview) as this text was not 6020 reviewed for long time. Added references to normative section for 6021 each step to hopefully avoid feedback of not explaining terms used 6022 (really not possible to give good summary without using forward 6023 references). 6025 2. Separate out-of-band-management definition from virtual out-of- 6026 band-management definition (later one for ACP). 6028 2. Added definitions for RPI and RPL. 6030 6.1.1. added note about end-to-end authentication to distinguish 6031 channel security from overall ACP security model. 6033 6.5 Fixed bugs in channel selection signaling step description (Alice 6034 vs. Bob). 6036 6.7.1 Removed redundant channel selection explanation. 6038 6.10.3 remove locator/identifier terminology from zone addressing 6039 scheme description (unnecessary), removed explanations (now in 9.4), 6040 simplified text, clarified requirement for Node-ID to be unique, 6041 recommend to use primarily zone 0. 6043 6.10.3.1 Removed. Included a lot of insufficient suggestions for 6044 future stanards extensions, most of it was wrong or would need to be 6045 revisited by WG anyhow. Idea now (just here for comment): Announce 6046 via GRASP Zone-ID (e.g.: from per-zone edge-node/registrar) into a 6047 zone of the ACP so all nodes supporting the scheme can automatically 6048 self-allocate the Zone-ID. 6050 6.11.1.1 (RPL overview), eliminated redundant text. 6052 6.11.1.1.1 New subsection to better structure overview. 6054 6.11.1.1.2 New subsection to better group overview, replaced TTL 6055 explanation (just the symptom) with hopefully better reconvergence 6056 text (intent of the profile) for the ACP RPL profile. 6058 6.11.1.1.6 Added text to explain simple choice for rank_factor. 6060 6.11.1.13 moved explanation for RPI up into 6.11.1.1. 6062 6.12.5.1 rewrote section for ACP Loopback Interface. 6064 9.4 New informative/informational section for partial or incremental 6065 adoption of ACP to help understand why there is the Zone interface 6066 sub-scheme, and how to use it. 6068 Unrelated fixes: 6070 Ask to RFC editor to add most important abbreviations to RFC editor 6071 abbreviation list. 6073 6.10.2 changed names in ACP addressing scheme table to be less 6074 suggestive of use. 6076 Russ Hously review: 6078 2. Fixed definition of "Enrollment", "Trust Anchor", "CA", and "root 6079 CA". Changed "Certificate Authority" to "Certification Authority" 6080 throughout the document (correct term according to X.509). 6082 6.1 Fixed explanation of mutual ACP trust. 6084 6.1.1 s/X509/X509v3/. 6086 6.1.2 created bulleted lists for explanations and justifications for 6087 choices of ACP domain certificate encoding. No semantic changes, 6088 just to make it easier to refer to the points in discussions (rfcdiff 6089 seems to have a bug showing text differences due to formatting 6090 changes). 6092 6.1.3 Moved content of rule #1 into previous rule #2 because 6093 certification chain validation does imply validation of lifetime. 6094 numbers of all rules reduced by 1, changed hopefully all references 6095 to the rule numbers in the document. 6097 Rule #3, Hopefully fixed linguistic problem self-contradiction of 6098 MUST by lower casing MUST in the explanation part and rewriting the 6099 condition when this is not applicable. 6101 6.1.4 Replaced redundant term "Trust Point" (TP) with Trust Anchor 6102 (TA"). Replaced throughout document Trust Anchor with abbreviation 6103 TA. 6105 Enhanced several sentences/rewrote paragraphs to make explanations 6106 clearer. 6108 6.6 Added explanation how ACP nodes must throttle their attempts for 6109 connection making purely on the result of their own connection 6110 attempts, not based on those connections where they are responder. 6112 14.4. draft-ietf-anima-autonomic-control-plane-24 6114 Leftover from -23 review by Eric Vyncke: 6116 Swapping sections 9 and 10, section 9 was meant to be at end of 6117 document and summarize. Its not meant to be misinterpreted as 6118 introducing any new information. This did happen because section 10 6119 was added after section 9. 6121 14.5. draft-ietf-anima-autonomic-control-plane-23 6123 Note: big rfcdiff of TOC is an rfcdiff bug, changes really minimal. 6125 Review of IPsec security with Mcr and ipsec mailing list. 6127 6.7.1 - new section: Moved general considerations for secure channel 6128 protocols here, refined them. 6130 6.7.2 - new section: Moved common requirements for secure channel 6131 protocols here, refined them. 6133 6.7.3.1.1. - improved requirements text related to RFC8221, better 6134 explamations re. HW acceleration issues. 6136 6.7.3.1.2. - improved requirements text related to RFC8247, (some 6137 requirements still discussed to be redundant, will be finalized in 6138 next weeks. 6140 Eric Vyncke review of -21: 6142 Only noting most important changes, long list of smaller text/ 6143 readability enhancements. 6145 2. - New explanation of "normative" , "informational" section title 6146 tags. alphabetic reordering of terms, refined definitions for CA, 6147 CRL. root CA. 6149 6.1.1. - explanation when IDevID parameters may be copied into 6150 LDevID. 6152 6.1.2. - Fixed hex digits in ACP domain information to lower case. 6154 6.1.3.1. - New section on Realtime clock and Time Validation. 6156 6.3 - Added explanation that DTLS means >= version 1.2 (not only 6157 1.2). 6159 6.7 - New text in this main section explaing relationship of ACP 6160 secure channels and ACP virtual interfaces - with forward references 6161 to virtual interface section. 6163 6.8.2 - reordered text and picture, no text change. 6165 6.10.7.2 - describe first how Registrar-ID can be allocted for all 6166 type of registrars, then refined text for how to potentially use MAC 6167 addresses on physical registrars. 6169 6.11.1.1 - Added text how this profile does not use Data-Plane 6170 artefacts (RPI) because hadware forwarding. This was previously 6171 hidden only later in the text. 6173 6.11.1.13. - Rewrote RPL Data-Plane artefact text. Provide decoder 6174 ring for abbreviations and all relevant RFCs. 6176 6.12.5.2. - Added more explicit text that secure channels are mapped 6177 into virtual interfaces, moved different type of interfaces used by 6178 ACP into seperate subsections to be able to refer to them. 6180 7.2 - Rewrote/refined text for ACP on L2, prior text was confusing 6181 and did not well explain why ACP for L2/L3 switches can be 6182 implemented without any L2 (HW) changes. Also missing explanation of 6183 only running GRASP untagged when VLANs are used. 6185 8.1.1 - Added requirement for ACP Edge nodes to allow configurable 6186 filtering of IPv6 RPI headers. 6188 11. - (security section). Moved explanation of address stealing from 6189 7.2 to here. 6191 14.6. draft-ietf-anima-autonomic-control-plane-22 6193 Ben Kaduk review of -21: 6195 RFC822 encoding of ACP domain information: 6197 6.1.2 rewrote text for explaining / justifying use of rfc822name as 6198 identifier for node CP in certificate (was discussed in thread, but 6199 badly written in prior versions). 6201 6.1.2 Changed EBNF syntax to use "+" after rfcSELF because that is 6202 the known primary name to extensions separator in many email systems 6203 ("." was wrong in prior versions). 6205 6.1.2 Rewrote/improved explanations for use of rfc822name field to 6206 explain better why it is PKIX compliant and the right thing to do. 6208 Crypto parameters for IPsec: 6210 6.1 - Added explanation of why manual keying for ACP is not feasible 6211 for ACP. Surprisingly, that text did not exist. Referred to by 6212 IPsec text (6.7.1), but here is the right place to describe the 6213 reasoning. 6215 6.1.2 - Small textual refinement referring to requirements to 6216 authenticate peers (for the special cases of empty or '0' ACP address 6217 in ACP domain information field. 6219 6.3 - To better justify Bens proposed change of secure channel 6220 protocol being IPsec vs. GRASP objective being IKEv2, better 6221 explained how protocol indicated in GRASP objective-value is name of 6222 protocol used to negotiate secure channel, use example of IKEv2 to 6223 negotiate IPsec. 6225 6.7.1 - refinemenet similar to 6.3. 6227 - moved new paragraph from Bens pull request up from 6.7.1.1 to 6.7.1 6228 as it equally applies to GRE encapped IPsec (looks nicer one level 6229 up). 6231 - created subsections 6.7.1.1 (IPsec/ESP) / 6.7.1.2 (IKEv2) to 6232 clearer distinguish between these two requirements blocks. 6234 - Refined the text in these two sections to hopefully be a good 6235 answer to Valery's concern of not randomnly mocking with existing 6236 requirements docs (rfc8247 / rfc8221). 6238 6.7.1.1.1 - IPsec/ESP requirements section: 6240 - MUST support rfc8221 mandatory EXCEPT for the superceeding 6241 requirements in this section. Previously, this was not quite clear 6242 from the text. 6244 - Hopefully persuasive explanations about the requirements levels for 6245 ENCR_AES_GCM_16, ENCR_AES_CBC, ENCR_AES_CCM_8 and 6246 ENCR_CHACHA20_POLY1305: Restructured text for why not ENCR_AES_CBC 6247 (was in prior version, just not well structured), added new 6248 expanations for ENCR_AES_CCM_8 and ENCR_CHACHA20_POLY130. 6250 - In simple terms, requirements for ENCR_AES_CBC, ENCR_AES_CCM_8, 6251 ENCR_CHACHACHA are SHOULD when they are implementable with rqual or 6252 faster performancce than ENCR_AES_GCM_16. 6254 - Removed text about "additional rfc8221" reqiurements MAY be used. 6255 Now the logic is that all other requirements apply. Hopefully we 6256 have written enough so that we prohibited downgrades. 6258 6.7.1.1.2 - RFC8247 requirements: 6260 - Added mandate to support rfc8247, added explanation that there is 6261 no "stripping down" requirement, just additional stronger 6262 requirements to mandate correct use of ACP certificartes during 6263 authentication. 6265 - refined text on identifying ACP by IPv6 address to be clearer: 6266 Identifying in the context of IKEv2 and cases for '0' in ACP domain 6267 information. 6269 - removed last two paragraphs about relationship to rfc8247, as his 6270 is now written in first paragraph of the section. 6272 End of Ben Kaduk review related fixes. 6274 Other: 6276 Forgot to update example of ACP domain information to use capitalized 6277 hex-digits as required by HEXDIGIT used. 6279 Added reference to RFC8316 (AN use-cases) to beginning of section 3 6280 (ACP use cases). 6282 Small Enhanced IPsec parameters description / requirements fixes 6283 (from Michael Richardson). 6285 15. References 6287 15.1. Normative References 6289 [I-D.ietf-anima-grasp] 6290 Bormann, C., Carpenter, B., and B. Liu, "A Generic 6291 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 6292 grasp-15 (work in progress), July 2017. 6294 [IKEV2IANA] 6295 IANA, "Internet Key Exchange Version 2 (IKEv2) 6296 Parameters", . 6299 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 6300 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 6301 . 6303 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 6304 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 6305 DOI 10.17487/RFC3810, June 2004, 6306 . 6308 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 6309 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 6310 November 2005, . 6312 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 6313 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 6314 . 6316 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 6317 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 6318 2006, . 6320 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 6321 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 6322 December 2005, . 6324 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 6325 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 6326 DOI 10.17487/RFC4861, September 2007, 6327 . 6329 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 6330 Address Autoconfiguration", RFC 4862, 6331 DOI 10.17487/RFC4862, September 2007, 6332 . 6334 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 6335 Specifications: ABNF", STD 68, RFC 5234, 6336 DOI 10.17487/RFC5234, January 2008, 6337 . 6339 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 6340 (TLS) Protocol Version 1.2", RFC 5246, 6341 DOI 10.17487/RFC5246, August 2008, 6342 . 6344 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 6345 Housley, R., and W. Polk, "Internet X.509 Public Key 6346 Infrastructure Certificate and Certificate Revocation List 6347 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 6348 . 6350 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 6351 DOI 10.17487/RFC5321, October 2008, 6352 . 6354 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 6355 DOI 10.17487/RFC5322, October 2008, 6356 . 6358 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 6359 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 6360 January 2012, . 6362 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 6363 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 6364 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 6365 Low-Power and Lossy Networks", RFC 6550, 6366 DOI 10.17487/RFC6550, March 2012, 6367 . 6369 [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing 6370 Protocol for Low-Power and Lossy Networks (RPL)", 6371 RFC 6552, DOI 10.17487/RFC6552, March 2012, 6372 . 6374 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 6375 Power and Lossy Networks (RPL) Option for Carrying RPL 6376 Information in Data-Plane Datagrams", RFC 6553, 6377 DOI 10.17487/RFC6553, March 2012, 6378 . 6380 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 6381 "Enrollment over Secure Transport", RFC 7030, 6382 DOI 10.17487/RFC7030, October 2013, 6383 . 6385 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 6386 Kivinen, "Internet Key Exchange Protocol Version 2 6387 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 6388 2014, . 6390 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 6391 "Recommendations for Secure Use of Transport Layer 6392 Security (TLS) and Datagram Transport Layer Security 6393 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 6394 2015, . 6396 [RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support 6397 for Generic Routing Encapsulation (GRE)", RFC 7676, 6398 DOI 10.17487/RFC7676, October 2015, 6399 . 6401 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 6402 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 6403 May 2017, . 6405 [RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T. 6406 Kivinen, "Cryptographic Algorithm Implementation 6407 Requirements and Usage Guidance for Encapsulating Security 6408 Payload (ESP) and Authentication Header (AH)", RFC 8221, 6409 DOI 10.17487/RFC8221, October 2017, 6410 . 6412 [RFC8247] Nir, Y., Kivinen, T., Wouters, P., and D. Migault, 6413 "Algorithm Implementation Requirements and Usage Guidance 6414 for the Internet Key Exchange Protocol Version 2 (IKEv2)", 6415 RFC 8247, DOI 10.17487/RFC8247, September 2017, 6416 . 6418 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 6419 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 6420 . 6422 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 6423 Definition Language (CDDL): A Notational Convention to 6424 Express Concise Binary Object Representation (CBOR) and 6425 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 6426 June 2019, . 6428 15.2. Informative References 6430 [AR8021] Group, W. -. H. L. L. P. W., "IEEE Standard for Local and 6431 metropolitan area networks - Secure Device Identity", 6432 December 2009, . 6435 [CABFORUM] 6436 CA/Browser Forum, "Certificate Contents for Baseline SSL", 6437 Nov 2019, . 6440 [I-D.eckert-anima-noc-autoconfig] 6441 Eckert, T., "Autoconfiguration of NOC services in ACP 6442 networks via GRASP", draft-eckert-anima-noc-autoconfig-00 6443 (work in progress), July 2018. 6445 [I-D.ietf-acme-star] 6446 Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T. 6447 Fossati, "Support for Short-Term, Automatically-Renewed 6448 (STAR) Certificates in Automated Certificate Management 6449 Environment (ACME)", draft-ietf-acme-star-11 (work in 6450 progress), October 2019. 6452 [I-D.ietf-anima-bootstrapping-keyinfra] 6453 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 6454 and K. Watsen, "Bootstrapping Remote Secure Key 6455 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 6456 keyinfra-41 (work in progress), April 2020. 6458 [I-D.ietf-anima-prefix-management] 6459 Jiang, S., Du, Z., Carpenter, B., and Q. Sun, "Autonomic 6460 IPv6 Edge Prefix Management in Large-scale Networks", 6461 draft-ietf-anima-prefix-management-07 (work in progress), 6462 December 2017. 6464 [I-D.ietf-anima-reference-model] 6465 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 6466 and J. Nobre, "A Reference Model for Autonomic 6467 Networking", draft-ietf-anima-reference-model-10 (work in 6468 progress), November 2018. 6470 [I-D.ietf-roll-applicability-template] 6471 Richardson, M., "ROLL Applicability Statement Template", 6472 draft-ietf-roll-applicability-template-09 (work in 6473 progress), May 2016. 6475 [I-D.ietf-roll-useofrplinfo] 6476 Robles, I., Richardson, M., and P. Thubert, "Using RPI 6477 Option Type, Routing Header for Source Routes and IPv6-in- 6478 IPv6 encapsulation in the RPL Data Plane", draft-ietf- 6479 roll-useofrplinfo-39 (work in progress), June 2020. 6481 [I-D.ietf-tls-dtls13] 6482 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 6483 Datagram Transport Layer Security (DTLS) Protocol Version 6484 1.3", draft-ietf-tls-dtls13-38 (work in progress), May 6485 2020. 6487 [IEEE-1588-2008] 6488 IEEE, "IEEE Standard for a Precision Clock Synchronization 6489 Protocol for Networked Measurement and Control Systems", 6490 December 2008, . 6493 [IEEE-802.1X] 6494 Group, W. -. H. L. L. P. W., "IEEE Standard for Local and 6495 Metropolitan Area Networks: Port-Based Network Access 6496 Control", February 2010, 6497 . 6500 [LLDP] Group, W. -. H. L. L. P. W., "IEEE Standard for Local and 6501 Metropolitan Area Networks: Station and Media Access 6502 Control Connectivity Discovery", June 2016, 6503 . 6506 [MACSEC] Group, W. -. H. L. L. P. W., "IEEE Standard for Local and 6507 Metropolitan Area Networks: Media Access Control (MAC) 6508 Security", June 2006, 6509 . 6512 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 6513 RFC 1112, DOI 10.17487/RFC1112, August 1989, 6514 . 6516 [RFC1492] Finseth, C., "An Access Control Protocol, Sometimes Called 6517 TACACS", RFC 1492, DOI 10.17487/RFC1492, July 1993, 6518 . 6520 [RFC1654] Rekhter, Y., Ed. and T. Li, Ed., "A Border Gateway 6521 Protocol 4 (BGP-4)", RFC 1654, DOI 10.17487/RFC1654, July 6522 1994, . 6524 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 6525 and E. Lear, "Address Allocation for Private Internets", 6526 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 6527 . 6529 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 6530 Requirement Levels", BCP 14, RFC 2119, 6531 DOI 10.17487/RFC2119, March 1997, 6532 . 6534 [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax 6535 Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998, 6536 . 6538 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 6539 (IKE)", RFC 2409, DOI 10.17487/RFC2409, November 1998, 6540 . 6542 [RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", 6543 RFC 2821, DOI 10.17487/RFC2821, April 2001, 6544 . 6546 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 6547 "Remote Authentication Dial In User Service (RADIUS)", 6548 RFC 2865, DOI 10.17487/RFC2865, June 2000, 6549 . 6551 [RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, 6552 DOI 10.17487/RFC3164, August 2001, 6553 . 6555 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 6556 C., and M. Carney, "Dynamic Host Configuration Protocol 6557 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 6558 2003, . 6560 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 6561 Architecture for Describing Simple Network Management 6562 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 6563 DOI 10.17487/RFC3411, December 2002, 6564 . 6566 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 6567 "DNS Extensions to Support IP Version 6", STD 88, 6568 RFC 3596, DOI 10.17487/RFC3596, October 2003, 6569 . 6571 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 6572 Protocol (XMPP): Core", RFC 3920, DOI 10.17487/RFC3920, 6573 October 2004, . 6575 [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export 6576 Version 9", RFC 3954, DOI 10.17487/RFC3954, October 2004, 6577 . 6579 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 6580 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 6581 DOI 10.17487/RFC4007, March 2005, 6582 . 6584 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 6585 "Internet X.509 Public Key Infrastructure Certificate 6586 Management Protocol (CMP)", RFC 4210, 6587 DOI 10.17487/RFC4210, September 2005, 6588 . 6590 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 6591 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 6592 2006, . 6594 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 6595 for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, 6596 . 6598 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 6599 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 6600 for Transport Layer Security (TLS)", RFC 4492, 6601 DOI 10.17487/RFC4492, May 2006, 6602 . 6604 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 6605 "Considerations for Internet Group Management Protocol 6606 (IGMP) and Multicast Listener Discovery (MLD) Snooping 6607 Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, 6608 . 6610 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 6611 Group Management Protocol Version 3 (IGMPv3) and Multicast 6612 Listener Discovery Protocol Version 2 (MLDv2) for Source- 6613 Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, 6614 August 2006, . 6616 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 6617 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 6618 . 6620 [RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol 6621 Independent Multicast (PIM)", RFC 4610, 6622 DOI 10.17487/RFC4610, August 2006, 6623 . 6625 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 6626 Extensions for Stateless Address Autoconfiguration in 6627 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 6628 . 6630 [RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure 6631 Subject Alternative Name for Expression of Service Name", 6632 RFC 4985, DOI 10.17487/RFC4985, August 2007, 6633 . 6635 [RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet 6636 Group Management Protocol Version 3 (IGMPv3) and Multicast 6637 Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, 6638 DOI 10.17487/RFC5790, February 2010, 6639 . 6641 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 6642 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 6643 . 6645 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 6646 "Network Time Protocol Version 4: Protocol and Algorithms 6647 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 6648 . 6650 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 6651 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 6652 DOI 10.17487/RFC5912, June 2010, 6653 . 6655 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 6656 and A. Bierman, Ed., "Network Configuration Protocol 6657 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 6658 . 6660 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 6661 Cheshire, "Internet Assigned Numbers Authority (IANA) 6662 Procedures for the Management of the Service Name and 6663 Transport Protocol Port Number Registry", BCP 165, 6664 RFC 6335, DOI 10.17487/RFC6335, August 2011, 6665 . 6667 [RFC6402] Schaad, J., "Certificate Management over CMS (CMC) 6668 Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011, 6669 . 6671 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 6672 of Interpretation", RFC 6407, DOI 10.17487/RFC6407, 6673 October 2011, . 6675 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 6676 Routing Header for Source Routes with the Routing Protocol 6677 for Low-Power and Lossy Networks (RPL)", RFC 6554, 6678 DOI 10.17487/RFC6554, March 2012, 6679 . 6681 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 6682 "Default Address Selection for Internet Protocol Version 6 6683 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 6684 . 6686 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 6687 Ed., "Diameter Base Protocol", RFC 6733, 6688 DOI 10.17487/RFC6733, October 2012, 6689 . 6691 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 6692 DOI 10.17487/RFC6762, February 2013, 6693 . 6695 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 6696 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 6697 . 6699 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 6700 "TCP Extensions for Multipath Operation with Multiple 6701 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 6702 . 6704 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 6705 Locator/ID Separation Protocol (LISP)", RFC 6830, 6706 DOI 10.17487/RFC6830, January 2013, 6707 . 6709 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 6710 "Specification of the IP Flow Information Export (IPFIX) 6711 Protocol for the Exchange of Flow Information", STD 77, 6712 RFC 7011, DOI 10.17487/RFC7011, September 2013, 6713 . 6715 [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local 6716 Addressing inside an IPv6 Network", RFC 7404, 6717 DOI 10.17487/RFC7404, November 2014, 6718 . 6720 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 6721 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 6722 Defined Networking (SDN): Layers and Architecture 6723 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 6724 2015, . 6726 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 6727 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 6728 Networking: Definitions and Design Goals", RFC 7575, 6729 DOI 10.17487/RFC7575, June 2015, 6730 . 6732 [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap 6733 Analysis for Autonomic Networking", RFC 7576, 6734 DOI 10.17487/RFC7576, June 2015, 6735 . 6737 [RFC7585] Winter, S. and M. McCauley, "Dynamic Peer Discovery for 6738 RADIUS/TLS and RADIUS/DTLS Based on the Network Access 6739 Identifier (NAI)", RFC 7585, DOI 10.17487/RFC7585, October 6740 2015, . 6742 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 6743 Considerations for IPv6 Address Generation Mechanisms", 6744 RFC 7721, DOI 10.17487/RFC7721, March 2016, 6745 . 6747 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 6748 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 6749 Multicast - Sparse Mode (PIM-SM): Protocol Specification 6750 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 6751 2016, . 6753 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 6754 RFC 7950, DOI 10.17487/RFC7950, August 2016, 6755 . 6757 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 6758 Hosts in a Multi-Prefix Network", RFC 8028, 6759 DOI 10.17487/RFC8028, November 2016, 6760 . 6762 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 6763 Writing an IANA Considerations Section in RFCs", BCP 26, 6764 RFC 8126, DOI 10.17487/RFC8126, June 2017, 6765 . 6767 [RFC8316] Nobre, J., Granville, L., Clemm, A., and A. Gonzalez 6768 Prieto, "Autonomic Networking Use Case for Distributed 6769 Detection of Service Level Agreement (SLA) Violations", 6770 RFC 8316, DOI 10.17487/RFC8316, February 2018, 6771 . 6773 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 6774 "A Voucher Artifact for Bootstrapping Protocols", 6775 RFC 8366, DOI 10.17487/RFC8366, May 2018, 6776 . 6778 [RFC8368] Eckert, T., Ed. and M. Behringer, "Using an Autonomic 6779 Control Plane for Stable Connectivity of Network 6780 Operations, Administration, and Maintenance (OAM)", 6781 RFC 8368, DOI 10.17487/RFC8368, May 2018, 6782 . 6784 [RFC8398] Melnikov, A., Ed. and W. Chuang, Ed., "Internationalized 6785 Email Addresses in X.509 Certificates", RFC 8398, 6786 DOI 10.17487/RFC8398, May 2018, 6787 . 6789 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 6790 Decraene, B., Litkowski, S., and R. Shakir, "Segment 6791 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 6792 July 2018, . 6794 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 6795 Touch Provisioning (SZTP)", RFC 8572, 6796 DOI 10.17487/RFC8572, April 2019, 6797 . 6799 [X.509] International Telecommunication Union, "Information 6800 technology - Open Systems Interconnection - The Directory: 6801 Public-key and attribute certificate frameworks", ITU-T 6802 Recommendation X.509, ISO/IEC 9594-8, October 2016, 6803 . 6805 15.3. URIs 6807 [1] https://en.wikipedia.org/wiki/Operational_Technology 6809 [2] https://en.wikipedia.org/wiki/Single-root_input/ 6810 output_virtualization 6812 Appendix A. Background and Futures (Informative) 6814 The following sections discuss additional background information 6815 about aspects of the normative parts of this document or associated 6816 mechanisms such as BRSKI (such as why specific choices were made by 6817 the ACP) and they provide discussion about possible future variations 6818 of the ACP. 6820 A.1. ACP Address Space Schemes 6822 This document defines the Zone, Vlong and Manual sub address schemes 6823 primarily to support address prefix assignment via distributed, 6824 potentially uncoordinated ACP registrars as defined in 6825 Section 6.10.7. This costs 48/46-bit identifier so that these ACP 6826 registrar can assign non-conflicting address prefixes. This design 6827 does not leave enough bits to simultaneously support a large number 6828 of nodes (Node-ID) plus a large prefix of local addresses for every 6829 node plus a large enough set of bits to identify a routing Zone. In 6830 result, Zone, Vlong 8/16 attempt to support all features, but in via 6831 separate prefixes. 6833 In networks that always expect to rely on a centralized PMS as 6834 described above (Section 9.2.5), the 48/46-bits for the Registrar-ID 6835 could be saved. Such variations of the ACP addressing mechanisms 6836 could be introduced through future work in different ways. If a new 6837 otherName was introduced, incompatible ACP variations could be 6838 created where every design aspect of the ACP could be changed. 6839 Including all addressing choices. If instead a new addressing sub- 6840 type would be defined, it could be a backward compatible extension of 6841 this ACP specification. Information such as the size of a zone- 6842 prefix and the length of the prefix assigned to the ACP node itself 6843 could be encoded via the extension field of the acp-node-name. 6845 Note that an explicitly defined "Manual" addressing sub-scheme is 6846 always beneficial to provide an easy way for ACP nodes to prohibit 6847 incorrect manual configuration of any non-"Manual" ACP address spaces 6848 and therefore ensure that "Manual" operations will never impact 6849 correct routing for any non-"Manual" ACP addresses assigned via ACP 6850 domain certificates. 6852 A.2. BRSKI Bootstrap (ANI) 6854 BRSKI describes how nodes with an IDevID certificate can securely and 6855 zero-touch enroll with an LDevID certificate to support the ACP. 6856 BRSKI also leverages the ACP to enable zero-touch bootstrap of new 6857 nodes across networks without any configuration requirements across 6858 the transit nodes (e.g., no DHCP/DNS forwarding/server setup). This 6859 includes otherwise not configured networks as described in 6860 Section 3.2. Therefore BRSKI in conjunction with ACP provides for a 6861 secure and zero-touch management solution for complete networks. 6862 Nodes supporting such an infrastructure (BRSKI and ACP) are called 6863 ANI nodes (Autonomic Networking Infrastructure), see 6864 [I-D.ietf-anima-reference-model]. Nodes that do not support an 6865 IDevID certiificate but only an (insecure) vendor specific Unique 6866 Device Identifier (UDI) or nodes whose manufacturer does not support 6867 a MASA could use some future security reduced version of BRSKI. 6869 When BRSKI is used to provision a domain certificate (which is called 6870 enrollment), the BRSKI registrar (acting as an enhanced EST server) 6871 must include the otherName / AcpNode encoded ACP address and domain 6872 name to the enrolling node (called pledge) via its response to the 6873 pledges EST CSR Attribute request that is mandatory in BRSKI. 6875 The Certification Authority in an ACP network must not change the 6876 otherName / AcpNode in the certificate. The ACP nodes can therefore 6877 find their ACP address and domain using this field in the domain 6878 certificate, both for themselves, as well as for other nodes. 6880 The use of BRSKI in conjunction with the ACP can also help to further 6881 simplify maintenance and renewal of domain certificates. Instead of 6882 relying on CRL, the lifetime of certificates can be made extremely 6883 small, for example in the order of hours. When a node fails to 6884 connect to the ACP within its certificate lifetime, it cannot connect 6885 to the ACP to renew its certificate across it (using just EST), but 6886 it can still renew its certificate as an "enrolled/expired pledge" 6887 via the BRSKI bootstrap proxy. This requires only that the BRSKI 6888 registrar honors expired domain certificates and that the pledge 6889 attempts to perform TLS authentication for BRSKI bootstrap using its 6890 expired domain certificate before falling back to attempting to use 6891 its IDevID certificate for BRSKI. This mechanism could also render 6892 CRLs unnecessary because the BRSKI registrar in conjunction with the 6893 CA would not renew revoked certificates - only a "Do-not-renew" list 6894 would be necessary on BRSKI registrars/CA. 6896 In the absence of BRSKI or less secure variants thereof, provisioning 6897 of certificates may involve one or more touches or non-standardized 6898 automation. Node vendors usually support provisioning of 6899 certificates into nodes via PKCS#7 (see [RFC2315]) and may support 6900 this provisioning through vendor specific models via Netconf 6901 ([RFC6241]). If such nodes also support Netconf Zero-Touch 6902 ([RFC8572]) then this can be combined to zero-touch provisioning of 6903 domain certificates into nodes. Unless there are equivalent 6904 integration of Netconf connections across the ACP as there is in 6905 BRSKI, this combination would not support zero-touch bootstrap across 6906 a not configured network though. 6908 A.3. ACP Neighbor discovery protocol selection 6910 This section discusses why GRASP DULL was chosen as the discovery 6911 protocol for L2 adjacent candidate ACP neighbors. The contenders 6912 considered where GRASP, mDNS or LLDP. 6914 A.3.1. LLDP 6916 LLDP and Cisco's earlier Cisco Discovery Protocol (CDP) are example 6917 of L2 discovery protocols that terminate their messages on L2 ports. 6918 If those protocols would be chosen for ACP neighbor discovery, ACP 6919 neighbor discovery would therefore also terminate on L2 ports. This 6920 would prevent ACP construction over non-ACP capable but LLDP or CDP 6921 enabled L2 switches. LLDP has extensions using different MAC 6922 addresses and this could have been an option for ACP discovery as 6923 well, but the additional required IEEE standardization and definition 6924 of a profile for such a modified instance of LLDP seemed to be more 6925 work than the benefit of "reusing the existing protocol" LLDP for 6926 this very simple purpose. 6928 A.3.2. mDNS and L2 support 6930 Multicast DNNS (mDNS) [RFC6762] with DNS Service Discovery (DNS-SD) 6931 Resource Records (RRs) as defined in [RFC6763] is a key contender as 6932 an ACP discovery protocol. because it relies on link-local IP 6933 multicast, it does operates at the subnet level, and is also found in 6934 L2 switches. The authors of this document are not aware of mDNS 6935 implementation that terminate their mDNS messages on L2 ports instead 6936 of the subnet level. If mDNS was used as the ACP discovery mechanism 6937 on an ACP capable (L3)/L2 switch as outlined in Section 7, then this 6938 would be necessary to implement. It is likely that termination of 6939 mDNS messages could only be applied to all mDNS messages from such a 6940 port, which would then make it necessary to software forward any non- 6941 ACP related mDNS messages to maintain prior non-ACP mDNS 6942 functionality. Adding support for ACP into such L2 switches with 6943 mDNS could therefore create regression problems for prior mDNS 6944 functionality on those nodes. With low performance of software 6945 forwarding in many L2 switches, this could also make the ACP risky to 6946 support on such L2 switches. 6948 A.3.3. Why DULL GRASP 6950 LLDP was not considered because of the above mentioned issues. mDNS 6951 was not selected because of the above L2 mDNS considerations and 6952 because of the following additional points: 6954 If mDNS was not already existing in a node, it would be more work to 6955 implement than DULL GRASP, and if an existing implementation of mDNS 6956 was used, it would likely be more code space than a separate 6957 implementation of DULL GRASP or a shared implementation of DULL GRASP 6958 and GRASP in the ACP. 6960 A.4. Choice of routing protocol (RPL) 6962 This section motivates why RPL - "IPv6 Routing Protocol for Low-Power 6963 and Lossy Networks ([RFC6550] was chosen as the default (and in this 6964 specification only) routing protocol for the ACP. The choice and 6965 above explained profile was derived from a pre-standard 6966 implementation of ACP that was successfully deployed in operational 6967 networks. 6969 Requirements for routing in the ACP are: 6971 o Self-management: The ACP must build automatically, without human 6972 intervention. Therefore routing protocol must also work 6973 completely automatically. RPL is a simple, self-managing 6974 protocol, which does not require zones or areas; it is also self- 6975 configuring, since configuration is carried as part of the 6976 protocol (see Section 6.7.6 of [RFC6550]). 6978 o Scale: The ACP builds over an entire domain, which could be a 6979 large enterprise or service provider network. The routing 6980 protocol must therefore support domains of 100,000 nodes or more, 6981 ideally without the need for zoning or separation into areas. RPL 6982 has this scale property. This is based on extensive use of 6983 default routing. 6985 o Low resource consumption: The ACP supports traditional network 6986 infrastructure, thus runs in addition to traditional protocols. 6987 The ACP, and specifically the routing protocol must have low 6988 resource consumption both in terms of memory and CPU requirements. 6989 Specifically, at edge nodes, where memory and CPU are scarce, 6990 consumption should be minimal. RPL builds a DODAG, where the main 6991 resource consumption is at the root of the DODAG. The closer to 6992 the edge of the network, the less state needs to be maintained. 6993 This adapts nicely to the typical network design. Also, all 6994 changes below a common parent node are kept below that parent 6995 node. 6997 o Support for unstructured address space: In the Autonomic 6998 Networking Infrastructure, node addresses are identifiers, and may 6999 not be assigned in a topological way. Also, nodes may move 7000 topologically, without changing their address. Therefore, the 7001 routing protocol must support completely unstructured address 7002 space. RPL is specifically made for mobile ad-hoc networks, with 7003 no assumptions on topologically aligned addressing. 7005 o Modularity: To keep the initial implementation small, yet allow 7006 later for more complex methods, it is highly desirable that the 7007 routing protocol has a simple base functionality, but can import 7008 new functional modules if needed. RPL has this property with the 7009 concept of "objective function", which is a plugin to modify 7010 routing behavior. 7012 o Extensibility: Since the Autonomic Networking Infrastructure is a 7013 new concept, it is likely that changes in the way of operation 7014 will happen over time. RPL allows for new objective functions to 7015 be introduced later, which allow changes to the way the routing 7016 protocol creates the DAGs. 7018 o Multi-topology support: It may become necessary in the future to 7019 support more than one DODAG for different purposes, using 7020 different objective functions. RPL allow for the creation of 7021 several parallel DODAGs, should this be required. This could be 7022 used to create different topologies to reach different roots. 7024 o No need for path optimization: RPL does not necessarily compute 7025 the optimal path between any two nodes. However, the ACP does not 7026 require this today, since it carries mainly non-delay-sensitive 7027 feedback loops. It is possible that different optimization 7028 schemes become necessary in the future, but RPL can be expanded 7029 (see point "Extensibility" above). 7031 A.5. ACP Information Distribution and multicast 7033 IP multicast is not used by the ACP because the ANI (Autonomic 7034 Networking Infrastructure) itself does not require IP multicast but 7035 only service announcement/discovery. Using IP multicast for that 7036 would have made it necessary to develop a zero-touch auto configuring 7037 solution for ASM (Any Source Multicast - the original form of IP 7038 multicast defined in [RFC1112]), which would be quite complex and 7039 difficult to justify. One aspect of complexity where no attempt at a 7040 solution has been described in IETF documents is the automatic- 7041 selection of routers that should be PIM Sparse Mode (PIM-SM) 7042 Rendezvous Points (RPs) (see [RFC7761]). The other aspects of 7043 complexity are the implementation of MLD ([RFC4604]), PIM-SM and 7044 Anycast-RP (see [RFC4610]). If those implementations already exist 7045 in a product, then they would be very likely tied to accelerated 7046 forwarding which consumes hardware resources, and that in return is 7047 difficult to justify as a cost of performing only service discovery. 7049 Some future ASA may need high performance in-network data 7050 replication. That is the case when the use of IP multicast is 7051 justified. Such an ASA can then use service discovery from ACP 7052 GRASP, and then they do not need ASM but only SSM (Source Specific 7053 Multicast, see [RFC4607]) for the IP multicast replication. SSM 7054 itself can simply be enabled in the Data-Plane (or even in an update 7055 to the ACP) without any other configuration than just enabling it on 7056 all nodes and only requires a simpler version of MLD (see [RFC5790]). 7058 LSP (Link State Protocol) based IGP routing protocols typically have 7059 a mechanism to flood information, and such a mechanism could be used 7060 to flood GRASP objectives by defining them to be information of that 7061 IGP. This would be a possible optimization in future variations of 7062 the ACP that do use an LSP routing protocol. Note though that such a 7063 mechanism would not work easily for GRASP M_DISCOVERY messages which 7064 are intelligently (constrained) flooded not across the whole ACP, but 7065 only up to a node where a responder is found. We do expect that many 7066 future services in ASA will have only few consuming ASA, and for 7067 those cases, M_DISCOVERY is the more efficient method than flooding 7068 across the whole domain. 7070 Because the ACP uses RPL, one desirable future extension is to use 7071 RPLs existing notion of DODAG, which are loop-free distribution 7072 trees, to make GRASP flooding more efficient both for M_FLOOD and 7073 M_DISCOVERY. See Section 6.12.5 how this will be specifically 7074 beneficial when using NBMA interfaces. This is not currently 7075 specified in this document because it is not quite clear yet what 7076 exactly the implications are to make GRASP flooding depend on RPL 7077 DODAG convergence and how difficult it would be to let GRASP flooding 7078 access the DODAG information. 7080 A.6. Extending ACP channel negotiation (via GRASP) 7082 [RFC Editor: This section to be removed before RFC. 7084 [This section kept for informational purposes up until the last draft 7085 version as that would be the version that readers interested in the 7086 changelog would also go to to revisit it.] 7088 The mechanism described in the normative part of this document to 7089 support multiple different ACP secure channel protocols without a 7090 single network wide MTI protocol is important to allow extending 7091 secure ACP channel protocols beyond what is specified in this 7092 document, but it will run into problem if it would be used for 7093 multiple protocols: 7095 The need to potentially have multiple of these security associations 7096 even temporarily run in parallel to determine which of them works 7097 best does not support the most lightweight implementation options. 7099 The simple policy of letting one side (Alice) decide what is best may 7100 not lead to the mutual best result. 7102 The two limitations can easier be solved if the solution was more 7103 modular and as few as possible initial secure channel negotiation 7104 protocols would be used, and these protocols would then take on the 7105 responsibility to support more flexible objectives to negotiate the 7106 mutually preferred ACP security channel protocol. 7108 IKEv2 is the IETF standard protocol to negotiate network security 7109 associations. It is meant to be extensible, but it is unclear 7110 whether it would be feasible to extend IKEv2 to support possible 7111 future requirements for ACP secure channel negotiation: 7113 Consider the simple case where the use of native IPsec vs. IPsec via 7114 GRE is to be negotiated and the objective is the maximum throughput. 7115 Both sides would indicate some agreed upon performance metric and the 7116 preferred encapsulation is the one with the higher performance of the 7117 slower side. IKEv2 does not support negotiation with such 7118 objectives. 7120 Consider DTLS and some form of MacSec are to be added as negotiation 7121 options - and the performance objective should work across all IPsec, 7122 DTLS and MacSec options. In the case of MacSEC, the negotiation 7123 would also need to determine a key for the peering. It is unclear if 7124 it would be even appropriate to consider extending the scope of 7125 negotiation in IKEv2 to those cases. Even if feasible to define, it 7126 is unclear if implementations of IKEv2 would be eager to adopt those 7127 type of extension given the long cycles of security testing that 7128 necessarily goes along with core security protocols such as IKEv2 7129 implementations. 7131 A more modular alternative to extending IKEv2 could be to layer a 7132 modular negotiation mechanism on top of the multitude of existing or 7133 possible future secure channel protocols. For this, GRASP over TLS 7134 could be considered as a first ACP secure channel negotiation 7135 protocol. The following are initial considerations for such an 7136 approach. A full specification is subject to a separate document: 7138 To explicitly allow negotiation of the ACP channel protocol, GRASP 7139 over a TLS connection using the GRASP_LISTEN_PORT and the node's and 7140 peer's link-local IPv6 address is used. When Alice and Bob support 7141 GRASP negotiation, they do prefer it over any other non-explicitly 7142 negotiated security association protocol and should wait trying any 7143 non-negotiated ACP channel protocol until after it is clear that 7144 GRASP/TLS will not work to the peer. 7146 When Alice and Bob successfully establish the GRASP/TSL session, they 7147 will negotiate the channel mechanism to use using objectives such as 7148 performance and perceived quality of the security. After agreeing on 7149 a channel mechanism, Alice and Bob start the selected Channel 7150 protocol. Once the secure channel protocol is successfully running, 7151 the GRASP/TLS connection can be kept alive or timed out as long as 7152 the selected channel protocol has a secure association between Alice 7153 and Bob. When it terminates, it needs to be re-negotiated via GRASP/ 7154 TLS. 7156 Notes: 7158 o Negotiation of a channel type may require IANA assignments of code 7159 points. 7161 o TLS is subject to reset attacks, which IKEv2 is not. Normally, 7162 ACP connections (as specified in this document) will be over link- 7163 local addresses so the attack surface for this one issue in TCP 7164 should be reduced (note that this may not be true when ACP is 7165 tunneled as described in Section 8.2.2. 7167 o GRASP packets received inside a TLS connection established for 7168 GRASP/TLS ACP negotiation are assigned to a separate GRASP domain 7169 unique to that TLS connection. 7171 A.7. CAs, domains and routing subdomains 7173 There is a wide range of setting up different ACP solution by 7174 appropriately using CAs and the domain and rsub elements in the acp- 7175 node-name in the domain certificate. We summarize these options here 7176 as they have been explained in different parts of the document in 7177 before and discuss possible and desirable extensions: 7179 An ACP domain is the set of all ACP nodes that can authenticate each 7180 other as belonging to the same ACP network using the ACP domain 7181 membership check (Section 6.1.3). GRASP inside the ACP is run across 7182 all transitively connected ACP nodes in a domain. 7184 The rsub element in the acp-node-name permits the use of addresses 7185 from different ULA prefixes. One use case is to create multiple 7186 physical networks that initially may be separated with one ACP domain 7187 but different routing subdomains, so that all nodes can mutual trust 7188 their ACP domain certificates (not depending on rsub) and so that 7189 they could connect later together into a contiguous ACP network. 7191 One instance of such a use case is an ACP for regions interconnected 7192 via a non-ACP enabled core, for example due to the absence of product 7193 support for ACP on the core nodes. ACP connect configurations as 7194 defined in this document can be used to extend and interconnect those 7195 ACP islands to the NOC and merge them into a single ACP when later 7196 that product support gap is closed. 7198 Note that RPL scales very well. It is not necessary to use multiple 7199 routing subdomains to scale ACP domains in a way it would be possible 7200 if other routing protocols where used. They exist only as options 7201 for the above mentioned reasons. 7203 If different ACP domains are to be created that should not allow to 7204 connect to each other by default, these ACP domains simply need to 7205 have different domain elements in the acp-node-name. These domain 7206 elements can be arbitrary, including subdomains of one another: 7207 Domains "example.com" and "research.example.com" are separate domains 7208 if both are domain elements in the acp-node-name of certificates. 7210 It is not necessary to have a separate CA for different ACP domains: 7211 an operator can use a single CA to sign certificates for multiple ACP 7212 domains that are not allowed to connect to each other because the 7213 checks for ACP adjacencies includes comparison of the domain part. 7215 If multiple independent networks choose the same domain name but had 7216 their own CA, these would not form a single ACP domain because of CA 7217 mismatch. Therefore there is no problem in choosing domain names 7218 that are potentially also used by others. Nevertheless it is highly 7219 recommended to use domain names that one can have high probability to 7220 be unique. It is recommended to use domain names that start with a 7221 DNS domain names owned by the assigning organization and unique 7222 within it. For example "acp.example.com" if you own "example.com". 7224 A.8. Intent for the ACP 7226 Intent is the architecture component of autonomic networks according 7227 to [I-D.ietf-anima-reference-model] that allows operators to issue 7228 policies to the network. Its applicability for use is quite flexible 7229 and freeform, with potential applications including policies flooded 7230 across ACP GRASP and interpreted on every ACP node. 7232 One concern for future definitions of Intent solutions is the problem 7233 of circular dependencies when expressing Intent policies about the 7234 ACP itself. 7236 For example, Intent could indicate the desire to build an ACP across 7237 all domains that have a common parent domain (without relying on the 7238 rsub/routing-subdomain solution defined in this document). For 7239 example ACP nodes with domain "example.com", "access.example.com", 7240 "core.example.com" and "city.core.example.com" should all establish 7241 one single ACP. 7243 If each domain has its own source of Intent, then the Intent would 7244 simply have to allow adding the peer domains TA and domain names to 7245 the parameters for the ACP domain membership check (Section 6.1.3) so 7246 that nodes from those other domains are accepted as ACP peers. 7248 If this Intent was to be originated only from one domain, it could 7249 likely not be made to work because the other domains will not build 7250 any ACP connection amongst each other, whether they use the same or 7251 different CA due to the ACP domain membership check. 7253 If the domains use the same CA one could change the ACP setup to 7254 permit for the ACP to be established between two ACP nodes with 7255 different acp-domain-names, but only for the purpose of disseminating 7256 limited information, such as Intent, but not to set up full ACP 7257 connectivity, specifically not RPL routing and passing of arbitrary 7258 GRASP information. Unless the Intent policies permit this to happen 7259 across domain boundaries. 7261 This type of approach where the ACP first allows Intent to operate 7262 and only then sets up the rest of ACP connectivity based on Intent 7263 policy could also be used to enable Intent policies that would limit 7264 functionality across the ACP inside a domain, as long as no policy 7265 would disturb the distribution of Intent. For example to limit 7266 reachability across the ACP to certain type of nodes or locations of 7267 nodes. 7269 A.9. Adopting ACP concepts for other environments 7271 The ACP as specified in this document is very explicit about the 7272 choice of options to allow interoperable implementations. The 7273 choices made may not be the best for all environments, but the 7274 concepts used by the ACP can be used to build derived solutions: 7276 The ACP specifies the use of ULA and deriving its prefix from the 7277 domain name so that no address allocation is required to deploy the 7278 ACP. The ACP will equally work not using ULA but any other /48 IPv6 7279 prefix. This prefix could simply be a configuration of the ACP 7280 registrars (for example when using BRSKI) to enroll the domain 7281 certificates - instead of the ACP registrar deriving the /48 ULA 7282 prefix from the AN domain name. 7284 Some solutions may already have an auto-addressing scheme, for 7285 example derived from existing unique device identifiers (e.g., MAC 7286 addresses). In those cases it may not be desirable to assign 7287 addresses to devices via the ACP address information field in the way 7288 described in this document. The certificate may simply serve to 7289 identify the ACP domain, and the address field could be empty/unused. 7290 The only fix required in the remaining way the ACP operate is to 7291 define another element in the domain certificate for the two peers to 7292 decide who is Alice and who is Bob during secure channel building. 7293 Note though that future work may leverage the acp address to 7294 authenticate "ownership" of the address by the device. If the 7295 address used by a device is derived from some pre-existing permanent 7296 local ID (such as MAC address), then it would be useful to store that 7297 address in the certificate using the format of the access address 7298 information field or in a similar way. 7300 The ACP is defined as a separate VRF because it intends to support 7301 well managed networks with a wide variety of configurations. 7302 Therefore, reliable, configuration-indestructible connectivity cannot 7303 be achieved from the Data-Plane itself. In solutions where all 7304 transit connectivity impacting functions are fully automated 7305 (including security), indestructible and resilient, it would be 7306 possible to eliminate the need for the ACP to be a separate VRF. 7307 Consider the most simple example system in which there is no separate 7308 Data-Plane, but the ACP is the Data-Plane. Add BRSKI, and it becomes 7309 a fully autonomic network - except that it does not support automatic 7310 addressing for user equipment. This gap can then be closed for 7311 example by adding a solution derived from 7312 [I-D.ietf-anima-prefix-management]. 7314 TCP/TLS as the protocols to provide reliability and security to GRASP 7315 in the ACP may not be the preferred choice in constrained networks. 7316 For example, CoAP/DTLS (Constrained Application Protocol) may be 7317 preferred where they are already used, allowing to reduce the 7318 additional code space footprint for the ACP on those devices. Hop- 7319 by-hop reliability for ACP GRASP messages could be made to support 7320 protocols like DTLS by adding the same type of negotiation as defined 7321 in this document for ACP secure channel protocol negotiation. End- 7322 to-end GRASP connections can be made to select their transport 7323 protocol in future extensions of the ACP meant to better support 7324 constrained devices by indicating the supported transport protocols 7325 (e.g.: TLS/DTLS) via GRASP parameters of the GRASP objective through 7326 which the transport endpoint is discovered. 7328 The routing protocol RPL used for the ACP does explicitly not 7329 optimize for shortest paths and fastest convergence. Variations of 7330 the ACP may want to use a different routing protocol or introduce 7331 more advanced RPL profiles. 7333 Variations such as what routing protocol to use, or whether to 7334 instantiate an ACP in a VRF or (as suggested above) as the actual 7335 Data-Plane, can be automatically chosen in implementations built to 7336 support multiple options by deriving them from future parameters in 7337 the certificate. Parameters in certificates should be limited to 7338 those that would not need to be changed more often than certificates 7339 would need to be updated anyhow; Or by ensuring that these parameters 7340 can be provisioned before the variation of an ACP is activated in a 7341 node. Using BRSKI, this could be done for example as additional 7342 follow-up signaling directly after the certificate enrollment, still 7343 leveraging the BRSKI TLS connection and therefore not introducing any 7344 additional connectivity requirements. 7346 Last but not least, secure channel protocols including their 7347 encapsulations are easily added to ACP solutions. ACP hop-by-hop 7348 network layer secure channels could also be replaced by end-to-end 7349 security plus other means for infrastructure protection. Any future 7350 network OAM should always use end-to-end security anyhow and can 7351 leverage the domain certificates and is therefore not dependent on 7352 security to be provided for by ACP secure channels. 7354 A.10. Further (future) options 7356 A.10.1. Auto-aggregation of routes 7358 Routing in the ACP according to this specification only leverages the 7359 standard RPL mechanism of route optimization, e.g. keeping only 7360 routes that are not towards the RPL root. This is known to scale to 7361 networks with 20,000 or more nodes. There is no auto-aggregation of 7362 routes for /48 ULA prefixes (when using rsub in the acp-node-name) 7363 and/or Zone-ID based prefixes. 7365 Automatic assignment of Zone-ID and auto-aggregation of routes could 7366 be achieved for example by configuring zone-boundaries, announcing 7367 via GRASP into the zones the zone parameters (zone-ID and /48 ULA 7368 prefix) and auto-aggegating routes on the zone-boundaries. Nodes 7369 would assign their Zone-ID and potentially even /48 prefix based on 7370 the GRASP announcements. 7372 A.10.2. More options for avoiding IPv6 Data-Plane dependency 7374 As described in Section 6.12.2, the ACP depends on the Data-Plane to 7375 establish IPv6 link-local addressing on interfaces. Using a separate 7376 MAC address for the ACP allows to fully isolate the ACP from the 7377 Data-Plane in a way that is compatible with this specification. It 7378 is also an ideal option when using Single-root input/output 7379 virtualization (SR-IOV - see https://en.wikipedia.org/wiki/Single- 7380 root_input/output_virtualization [2]) in an implementation to isolate 7381 the ACP because different SR-IOV interfaces use different MAC 7382 addresses. 7384 When additional MAC address(es) are not available, separation of the 7385 ACP could be done at different demux points. The same subnet 7386 interface could have a separate IPv6 interface for the ACP and Data- 7387 Plane and therefore separate link-local addresses for both, where the 7388 ACP interface is non-configurable on the Data-Plane. This too would 7389 be compatible with this specification and not impact 7390 interoperability. 7392 An option that would require additional specification is to use a 7393 different Ethertype from 0x86DD (IPv6) to encapsulate IPv6 packets 7394 for the ACP. This would be a similar approach as used for IP 7395 authentication packets in [IEEE-802.1X] which use the Extensible 7396 Authentication Protocol over Local Area Network (EAPoL) ethertype 7397 (0x88A2). 7399 Note that in the case of ANI nodes, all the above considerations 7400 equally apply to the encapsulation of BRSKI packets including GRASP 7401 used for BRSKI. 7403 A.10.3. ACP APIs and operational models (YANG) 7405 Future work should define YANG ([RFC7950]) data model and/or node 7406 internal APIs to monitor and manage the ACP. 7408 Support for the ACP Adjacency Table (Section 6.2) and ACP GRASP need 7409 to be included into such model/API. 7411 A.10.4. RPL enhancements 7413 ..... USA ...... ..... Europe ...... 7415 NOC1 NOC2 7416 | | 7417 | metric 100 | 7418 ACP1 --------------------------- ACP2 . 7419 | | . WAN 7420 | metric 10 metric 20 | . Core 7421 | | . 7422 ACP3 --------------------------- ACP4 . 7423 | metric 100 | 7424 | | . 7425 | | . Sites 7426 ACP10 ACP11 . 7428 Figure 18: Dual NOC 7430 The profile for RPL specified in this document builds only one 7431 spanning-tree path set to a root, typically a registrar in one NOC. 7432 In the presence of multiple NOCs, routing toward the non-root NOCs 7433 may be suboptimal. Figure 18 shows an extreme example. Assuming 7434 that node ACP1 becomes the RPL root, traffic between ACP11 and NOC2 7435 will pass through ACP4-ACP3-ACP1-ACP2 instead of ACP4-ACP2 because 7436 the RPL calculated DODAG/routes are shortest paths towards the RPL 7437 root. 7439 To overcome these limitations, extensions/modifications to the RPL 7440 profile can provide optimality for multiple NOCs. This requires 7441 utilizing Data-Plane artifact including IPinIP encap/decap on ACP 7442 routers and processing of IPv6 RPI headers. Alternatively, (Src,Dst) 7443 routing table entries could be used. 7445 Flooding of ACP GRASP messages can be further constrained and 7446 therefore optimized by flooding only via links that are part of the 7447 RPL DODAG. 7449 A.10.5. Role assignments 7451 ACP connect is an explicit mechanism to "leak" ACP traffic explicitly 7452 (for example in a NOC). It is therefore also a possible security gap 7453 when it is easy to enable ACP connect on arbitrary compromised ACP 7454 nodes. 7456 One simple solution is to define an extension in the ACP certificates 7457 ACP information field indicating the permission for ACP connect to be 7458 configured on that ACP node. This could similarly be done to decide 7459 whether a node is permitted to be a registrar or not. 7461 Tying the permitted "roles" of an ACP node to the ACP domain 7462 certificate provides fairly strong protection against 7463 misconfiguration, but is still subject to code modifications. 7465 Another interesting role to assign to certificates is that of a NOC 7466 node. This would allow to limit certain type of connections such as 7467 OAM TLS connections to only NOC initiator or responders. 7469 A.10.6. Autonomic L3 transit 7471 In this specification, the ACP can only establish autonomic 7472 connectivity across L2 hops and only explicitly configured options to 7473 tunnel across L3. Future work should specify mechanisms to 7474 automatically tunnel ACP across L3 networks. A hub&spoke option 7475 would allow to tunnel across the Internet to a cloud or central 7476 instance of the ACP, a peer-to-peer tunneling mechanism could tunnel 7477 ACP islands across an L3VPN infrastructure. 7479 A.10.7. Diagnostics 7481 Section 9.1 describes diagnostics options that can be done without 7482 changing the external, interoperability affecting characteristics of 7483 ACP implementations. 7485 Even better diagnostics of ACP operations is possible with additional 7486 signaling extensions, such as: 7488 1. Consider if LLDP should be a recommended functionality for ANI 7489 devices to improve diagnostics, and if so, which information 7490 elements it should signal (noting that such information is 7491 conveyed in an insecure manner). Includes potentially new 7492 information elements. 7494 2. In alternative to LLDP, A DULL GRASP diagnostics objective could 7495 be defined to carry these information elements. 7497 3. The IDevID certificate of BRSKI pledges should be included in the 7498 selected insecure diagnostics option. This may be undesirable 7499 when exposure of device information is seen as too much of a 7500 security issue (ability to deduce possible attack vectors from 7501 device model for example). 7503 4. A richer set of diagnostics information should be made available 7504 via the secured ACP channels, using either single-hop GRASP or 7505 network wide "topology discovery" mechanisms. 7507 A.10.8. Avoiding and dealing with compromised ACP nodes 7509 Compromised ACP nodes pose the biggest risk to the operations of the 7510 network. The most common type of compromise is leakage of 7511 credentials to manage/configure the device and the application of 7512 malicious configuration including the change of access credentials, 7513 but not the change of software. Most of todays networking equipment 7514 should have secure boot/software infrastructure anyhow, so attacks 7515 that introduce malicious software should be a lot harder. 7517 The most important aspect of security design against these type of 7518 attacks is to eliminate password based configuration access methods 7519 and instead rely on certificate based credentials handed out only to 7520 nodes where it is clear that the private keys can not leak. This 7521 limits unexpected propagation of credentials. 7523 If password based credentials to configure devices still need to be 7524 supported, they must not be locally configurable, but only be 7525 remotely provisioned or verified (through protocols like Radius or 7526 Diameter), and there must be no local configuration permitting to 7527 change these authentication mechanisms, but ideally they should be 7528 autoconfiguring across the ACP. See 7529 [I-D.eckert-anima-noc-autoconfig]. 7531 Without physical access to the compromised device, attackers with 7532 access to configuration should not be able to break the ACP 7533 connectivity, even when they can break or otherwise manipulate 7534 (spoof) the Data-Plane connectivity through configuration. To 7535 achieve this, it is necessary to avoid providing configuration 7536 options for the ACP, such as enabling/disabling it on interfaces. 7537 For example there could be an ACP configuration that locks down the 7538 current ACP config unless factory reseet is done. 7540 With such means, the valid administration has the best chances to 7541 maintain access to ACP nodes, discover malicious configuration though 7542 ongoing configuration tracking from central locations for example, 7543 and to react accordingly. 7545 The primary reaction is withdrawal/change of credentials, terminate 7546 malicious existing management sessions and fixing the configuration. 7547 Ensuring that management sessions using invalidated credentials are 7548 terminated automatically without recourse will likely require new 7549 work. 7551 Only when these steps are not feasible would it be necessary to 7552 revoke or expire the ACP domain certificate credentials and consider 7553 the node kicked off the network - until the situation can be further 7554 rectified, likely requiring direct physical access to the node. 7556 Without extensions, compromised ACP nodes can only be removed from 7557 the ACP at the speed of CRL/OCSP information refresh or expiry (and 7558 non-removal) of short lived certificates. Future extensions to the 7559 ACP could for example use GRASP flooding distribution of triggered 7560 updates of CRL/OCSP or explicit removal indication of the compromised 7561 nodes domain certificate. 7563 Authors' Addresses 7565 Toerless Eckert (editor) 7566 Futurewei Technologies Inc. USA 7567 2330 Central Expy 7568 Santa Clara 95050 7569 USA 7571 Email: tte+ietf@cs.fau.de 7573 Michael H. Behringer (editor) 7575 Email: michael.h.behringer@gmail.com 7577 Steinthor Bjarnason 7578 Arbor Networks 7579 2727 South State Street, Suite 200 7580 Ann Arbor MI 48104 7581 United States 7583 Email: sbjarnason@arbor.net