idnits 2.17.1 draft-ietf-anima-autonomic-control-plane-27.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 1199 has weird spacing: '...address of f...' == Line 2679 has weird spacing: '...k-local unic...' == Line 2680 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 2, 2020) is 1394 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 484, but not defined -- Looks like a reference, but probably isn't: '1' on line 6817 -- Looks like a reference, but probably isn't: '2' on line 7390 -- Looks like a reference, but probably isn't: '3' on line 2096 -- Looks like a reference, but probably isn't: '5' on line 2102 -- Looks like a reference, but probably isn't: '9' on line 2113 -- Looks like a reference, but probably isn't: '13' on line 2131 == Missing Reference: 'ACP VRF' is mentioned on line 4049, but not defined == Missing Reference: 'Data-Plane' is mentioned on line 4051, but not defined == Missing Reference: 'Select' is mentioned on line 4211, but not defined == Missing Reference: 'Plane' is mentioned on line 4213, but not defined == Unused Reference: 'RFC1034' is defined on line 6309, but no explicit reference was found in the text == Unused Reference: 'RFC5321' is defined on line 6360, but no explicit reference was found in the text == Unused Reference: 'RFC5322' is defined on line 6364, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-applicability-template' is defined on line 6480, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-useofrplinfo' is defined on line 6485, but no explicit reference was found in the text == Unused Reference: 'RFC2821' is defined on line 6552, 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 3, 2021 6 S. Bjarnason 7 Arbor Networks 8 July 2, 2020 10 An Autonomic Control Plane (ACP) 11 draft-ietf-anima-autonomic-control-plane-27 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 3, 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-27 . . . . . . 127 205 14.3. draft-ietf-anima-autonomic-control-plane-26 . . . . . . 127 206 14.4. draft-ietf-anima-autonomic-control-plane-25 . . . . . . 128 207 14.5. draft-ietf-anima-autonomic-control-plane-24 . . . . . . 131 208 14.6. draft-ietf-anima-autonomic-control-plane-23 . . . . . . 131 209 14.7. draft-ietf-anima-autonomic-control-plane-22 . . . . . . 133 210 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 135 211 15.1. Normative References . . . . . . . . . . . . . . . . . . 135 212 15.2. Informative References . . . . . . . . . . . . . . . . . 138 213 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 146 214 Appendix A. Background and Futures (Informative) . . . . . . . . 146 215 A.1. ACP Address Space Schemes . . . . . . . . . . . . . . . . 146 216 A.2. BRSKI Bootstrap (ANI) . . . . . . . . . . . . . . . . . . 147 217 A.3. ACP Neighbor discovery protocol selection . . . . . . . . 148 218 A.3.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 148 219 A.3.2. mDNS and L2 support . . . . . . . . . . . . . . . . . 148 220 A.3.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 149 221 A.4. Choice of routing protocol (RPL) . . . . . . . . . . . . 149 222 A.5. ACP Information Distribution and multicast . . . . . . . 151 223 A.6. Extending ACP channel negotiation (via GRASP) . . . . . . 152 224 A.7. CAs, domains and routing subdomains . . . . . . . . . . . 153 225 A.8. Intent for the ACP . . . . . . . . . . . . . . . . . . . 155 226 A.9. Adopting ACP concepts for other environments . . . . . . 156 227 A.10. Further (future) options . . . . . . . . . . . . . . . . 157 228 A.10.1. Auto-aggregation of routes . . . . . . . . . . . . . 157 229 A.10.2. More options for avoiding IPv6 Data-Plane dependency 158 230 A.10.3. ACP APIs and operational models (YANG) . . . . . . . 158 231 A.10.4. RPL enhancements . . . . . . . . . . . . . . . . . . 159 232 A.10.5. Role assignments . . . . . . . . . . . . . . . . . . 159 233 A.10.6. Autonomic L3 transit . . . . . . . . . . . . . . . . 160 234 A.10.7. Diagnostics . . . . . . . . . . . . . . . . . . . . 160 235 A.10.8. Avoiding and dealing with compromised ACP nodes . . 161 236 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 162 238 1. Introduction (Informative) 240 Autonomic Networking is a concept of self-management: Autonomic 241 functions self-configure, and negotiate parameters and settings 242 across the network. [RFC7575] defines the fundamental ideas and 243 design goals of Autonomic Networking. A gap analysis of Autonomic 244 Networking is given in [RFC7576]. The reference architecture for 245 Autonomic Networking in the IETF is specified in the document 246 [I-D.ietf-anima-reference-model]. 248 Autonomic functions need an autonomically built communications 249 infrastructure. This infrastructure needs to be secure, resilient 250 and re-usable by all autonomic functions. Section 5 of [RFC7575] 251 introduces that infrastructure and calls it the Autonomic Control 252 Plane (ACP). More descriptively it would be the "Autonomic 253 communications infrastructure for OAM and Control". For naming 254 consistency with that prior document, this document continues to use 255 the name ACP though. 257 Today, the OAM and control plane of IP networks is what is typically 258 called in-band management/signaling: Its management and control 259 protocol traffic depends on the routing and forwarding tables, 260 security, policy, QoS and potentially other configuration that first 261 has to be established through the very same management and control 262 protocols. Misconfigurations including unexpected side effects or 263 mutual dependences can disrupt OAM and control operations and 264 especially disrupt remote management access to the affected node 265 itself and potentially a much larger number of nodes for whom the 266 affected node is on the network parth. Traditionally, physically 267 separate, so-called out-of-band (management) networks have been used 268 to avoid these problems or at least to allow recovery from such 269 problems. Worst case, personnel are sent on site to access devices 270 through out-of-band management ports (also called craft ports, serial 271 console, management ethernet port). However, both options are 272 expensive. 274 In increasingly automated networks either centralized management 275 systems or distributed autonomic service agents in the network 276 require a control plane which is independent of the configuration of 277 the network they manage, to avoid impacting their own operations 278 through the configuration actions they take. 280 This document describes a modular design for a self-forming, self- 281 managing and self-protecting ACP, which is a virtual out-of-band 282 network designed to be as independent as possible of configuration, 283 addressing and routing and similar self-dependency problems in 284 current IP networks, but which is still operating in-band on the same 285 physical network that it is controlling and managing. The ACP design 286 is therefore intended to combine as good as possible the resilience 287 of out-of-band management networks with the low-cost of traditional 288 IP in-band network management. The details how this is achieved are 289 described in Section 6. 291 In a fully autonomic network node without legacy control or 292 management functions/protocols, the Data-Plane would be for example 293 just a forwarding plane for "Data" IPv6 packets, aka: packets that 294 are not forwarded by the ACP itself such as control or management 295 plane packets. In such networks/nodes, there would be no non- 296 autonomous control or non-autonomous management plane. 298 Routing protocols for example would be built inside the ACP as so- 299 called autonomous functions via autonomous service agents, leveraging 300 the ACPs functions instead of implementing them seperately for each 301 protocol: discovery, automaticically established authenticated and 302 encrypted local and distant peer connectivity for control and 303 managemenet traffic and common control/management protocol session 304 and presentation functions. 306 When ACP functionality is added to nodes that have non-autonomous 307 management plane and/or control plane functions (henceforth called 308 non-autonomous nodes), the ACP instead is best abstracted as a 309 special Virtual Routing and Forwarding (VRF) instance (or virtual 310 router) and the complete pre-existing non-autonomous management and/ 311 or control plane is considered to be part of the Data-Plane to avoid 312 introduction of more complex, new terminology only for this case. 314 Like the forwarding plane for "Data" packets, the non-autonomous 315 control and management plane functions can then be managed/used via 316 the ACP. This terminology is consistent with pre-existing documents 317 such as [RFC8368]. 319 In both instances (autonomous and non-autonomous nodes), the ACP is 320 built such that it is operating in the absene of the Data-Plane, and 321 in the case of existing non-autonomous (management, control) 322 components in the Data-Plane also in the presence of any 323 (mis-)configuration thereof. 325 The Autonomic Control Plane serves several purposes at the same time: 327 1. Autonomic functions communicate over the ACP. The ACP therefore 328 directly supports Autonomic Networking functions, as described in 329 [I-D.ietf-anima-reference-model]. For example, Generic Autonomic 330 Signaling Protocol (GRASP - [I-D.ietf-anima-grasp]) runs securely 331 inside the ACP and depends on the ACP as its "security and 332 transport substrate". 334 2. A controller or network management system can use it to securely 335 bootstrap network devices in remote locations, even if the (Data- 336 Plane) network in between is not yet configured; no Data-Plane 337 dependent bootstrap configuration is required. An example of 338 such a secure bootstrap process is described in 339 [I-D.ietf-anima-bootstrapping-keyinfra]. 341 3. An operator can use it to access remote devices using protocols 342 such as Secure SHell (SSH) or Network Configuration Protocol 343 (NETCONF) running across the ACP, even if the network is 344 misconfigured or not configured. 346 This document describes these purposes as use cases for the ACP in 347 Section 3, it defines the requirements in Section 4. Section 5 gives 348 an overview how the ACP is constructed. 350 The normative part of this document starts with Section 6, where the 351 ACP is specified. Section 7 defines normative how to support ACP on 352 L2 switches. Section 8 explains normative how non-ACP nodes and 353 networks can be integrated. 355 The remaining sections are non-normative: Section 10 reviews benefits 356 of the ACP (after all the details have been defined), Section 9 357 provides operational recommendations, Appendix A provides additional 358 explanations and describes additional details or future standard or 359 propriety extensions that were considered not to be appropriate for 360 standardization in this document but were considered important to 361 document. There are no dependencies against Appendix A to build a 362 complete working and interoperable ACP according to this document. 364 The ACP provides secure IPv6 connectivity, therefore it can be used 365 not only as the secure connectivity for self-management as required 366 for the ACP in [RFC7575], but it can also be used as the secure 367 connectivity for traditional (centralized) management. The ACP can 368 be implemented and operated without any other components of autonomic 369 networks, except for the GRASP protocol. ACP relies on per-link DULL 370 GRASP (see Section 6.3) to autodiscover ACP neighbors, and includes 371 the ACP GRASP instance to provide service discovery for clients of 372 the ACP (see Section 6.8) including for its own maintenance of ACP 373 certificates. 375 The document "Using Autonomic Control Plane for Stable Connectivity 376 of Network OAM" [RFC8368] describes how the ACP alone can be used to 377 provide secure and stable connectivity for autonomic and non- 378 autonomic OAM applications, specifically for the case of current non- 379 autonomic networks/nodes. That document also explains how existing 380 management solutions can leverage the ACP in parallel with 381 traditional management models, when to use the ACP and how to 382 integrate with potentially IPv4 only OAM backends. 384 Combining ACP with Bootstrapping Remote Secure Key Infrastructures 385 (BRSKI), see [I-D.ietf-anima-bootstrapping-keyinfra]) results in the 386 "Autonomic Network Infrastructure" (ANI) as defined in 387 [I-D.ietf-anima-reference-model], which provides autonomic 388 connectivity (from ACP) with secure zero-touch (automated) bootstrap 389 from BRSKI. The ANI itself does not constitute an Autonomic Network, 390 but it allows the building of more or less autonomic networks on top 391 of it - using either centralized, Software Defined Networking- 392 (SDN-)style (see [RFC7426]) automation or distributed automation via 393 Autonomic Service Agents (ASA) / Autonomic Functions (AF) - or a 394 mixture of both. See [I-D.ietf-anima-reference-model] for more 395 information. 397 1.1. Applicability and Scope 399 Please see the following Terminology section (Section 2) for 400 explanations of terms used in this section. 402 The design of the ACP as defined in this document is considered to be 403 applicable to all types of "professionally managed" networks: Service 404 Provider, Local Area Network (LAN), Metro(politan networks), Wide 405 Area Network (WAN), Enterprise Information Technology (IT) and 406 ->"Operational Technology" () (OT) networks. The ACP can operate 407 equally on layer 3 equipment and on layer 2 equipment such as bridges 408 (see Section 7). The hop-by-hop authentication, integrity-protection 409 and confidentiality mechanism used by the ACP is defined to be 410 negotiable, therefore it can be extended to environments with 411 different protocol preferences. The minimum implementation 412 requirements in this document attempt to achieve maximum 413 interoperability by requiring support for multiple options depending 414 on the type of device: IPsec, see [RFC4301], and datagram Transport 415 Layer Security (DTLS) version 1.2, see [RFC6347]). 417 The implementation footprint of the ACP consists of Public Key 418 Infrastructure (PKI) code for the ACP certificate, the GRASP 419 protocol, UDP, TCP and TLS 1.2 ([RFC5246], for security and 420 reliability of GRASP), the ACP secure channel protocol used (such as 421 IPsec or DTLS), and an instance of IPv6 packet forwarding and routing 422 via the Routing Protocol for Low-power and Lossy Networks (RPL), see 423 [RFC6550], that is separate from routing and forwarding for the Data- 424 Plane (user traffic). 426 The ACP uses only IPv6 to avoid complexity of dual-stack ACP 427 operations (IPv6/IPv4). Nevertheless, it can without any changes be 428 integrated into even otherwise IPv4-only network devices. The Data- 429 Plane itself would not need to change, it could continue to be IPv4 430 only. For such IPv4 only devices, the IPv6 protocol itself would be 431 additional implementation footprint only used for the ACP. 433 The protocol choices of the ACP are primarily based on wide use and 434 support in networks and devices, well understood security properties 435 and required scalability. The ACP design is an attempt to produce 436 the lowest risk combination of existing technologies and protocols to 437 build a widely applicable operational network management solution: 439 RPL was chosen because it requires a smaller routing table footprint 440 in large networks compared to other routing protocols with an 441 autonomically configured single area. The deployment experience of 442 large scale Internet of Things (IoT) networks serves as the basis for 443 wide deployment experience with RPL. The profile chosen for RPL in 444 the ACP does not leverage any RPL specific forwarding plane features 445 (IPv6 extension headers), making its implementation a pure control 446 plane software requirement. 448 GRASP is the only completely novel protocol used in the ACP, and this 449 choice was necessary because there is no existing suitable protocol 450 to provide the necessary functions to the ACP, so GRASP was developed 451 to fill that gap. 453 The ACP design can be applicable to (cpu, memory) constrained devices 454 and (bitrate, reliability) constrained networks, but this document 455 does not attempt to define the most constrained type of devices or 456 networks to which the ACP is applicable. RPL and DTLS for ACP secure 457 channels are two protocol choices already making ACP more applicable 458 to constrained environments. Support for constrained devices in this 459 specification is opportunistic, but not complete, because the 460 reliable transport for GRASP (see Section 6.8.2) only specifies TCP/ 461 TLS). See Appendix A.9 for discussions about how future standards or 462 proprietary extensions/variations of the ACP could better meet 463 different expectations from those on which the current design is 464 based including supporting constrained devices better. 466 2. Acronyms and Terminology (Informative) 468 [RFC Editor: Please add ACP, BRSKI, GRASP, MASA to https://www.rfc- 469 editor.org/materials/abbrev.expansion.txt.] 471 [RFC Editor: WG/IETF/IESG review of the terms below asked for 472 references between these terms when they refer to each other. The 473 only option I could find for RFC/XML to point to a hanging text 474 acronym definition that also displays the actual term is the 475 format="title" version, which leads to references such as '->"ACP 476 domain certificate" ()'. I found no reasonable way to eliminate the 477 trailing '()' generated by this type of cross references. Can you 478 please take care of removing these artefacts during editing (after 479 conversion to nroff ?). I also created a ticket to ask for an 480 xml2rfc enhancement to avoid this in the future: 481 https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/347.] 483 [RFC Editor: Question: Is it possible to change the first occurrences 484 of [RFCxxxx] references to "rfcxxx title" [RFCxxxx]? the XML2RFC 485 format does not seem to offer such a format, but I did not want to 486 duplicate 50 first references - one reference for title mentioning 487 and one for RFC number.] 489 This document serves both as a normative specification for how ACP 490 nodes have to behave as well as describing requirements, benefits, 491 architecture and operational aspects to explain the context. 492 Normative sections are labelled "(Normative)" and use 493 [RFC2119]/[RFC8174] keywords. Other sections are labelled 494 "(Informative)" and do not use those normative keywords. 496 In the rest of the document we will refer to systems using the ACP as 497 "nodes". Typically such a node is a physical (network equipment) 498 device, but it can equally be some virtualized system. Therefore, we 499 do not refer to them as devices unless the context specifically calls 500 for a physical system. 502 This document introduces or uses the following terms (sorted 503 alphabetically). Terms introduced are explained on first use, so 504 this list is for reference only. 506 ACP: "Autonomic Control Plane". The Autonomic Function as defined 507 in this document. It provides secure zero-touch (automated) 508 transitive (network wide) IPv6 connectivity for all nodes in the 509 same ACP domain as well as a GRASP instance running across this 510 ACP IPv6 connectivity. The ACP is primarily meant to be used as a 511 component of the ANI to enable Autonomic Networks but it can 512 equally be used in simple ANI networks (with no other Autonomic 513 Functions) or completely by itself. 515 ACP address: An IPv6 address assigned to the ACP node. It is stored 516 in the acp-node-name of the ->"ACP domain certificate" (). 518 ACP address range/set: The ACP address may imply a range or set of 519 addresses that the node can assign for different purposes. This 520 address range/set is derived by the node from the format of the 521 ACP address called the "addressing sub-scheme". 523 ACP connect interface: An interface on an ACP node providing access 524 to the ACP for non ACP capable nodes without using an ACP secure 525 channel. See Section 8.1.1. 527 ACP domain: The ACP domain is the set of nodes with ->"ACP domain 528 certificates" that allow them to authenticate each other as 529 members of the ACP domain. See also Section 6.1.3. 531 ACP (ANI/AN) Domain Certificate: A [RFC5280] certificate (LDevID) 532 carrying the acp-node-name which is used by the ACP to learn its 533 address in the ACP and to derive and cryptographically assert its 534 membership in the ACP domain. 536 ACP acp-node-name field: An information field in the ACP Domain 537 Certificate in which the ACP relevant information is encoded: the 538 ACP domain name, the ACP IPv6 address of the node and optional 539 additional role attributes about the node. 541 ACP Loopback interface: The Loopback interface in the ACP Virtual 542 Routing and Forwarding (VRF) that has the ACP address assigned to 543 it. See Section 6.12.5.1. 545 ACP network: The ACP network constitutes all the nodes that have 546 access to the ACP. It is the set of active and transitively 547 connected nodes of an ACP domain plus all nodes that get access to 548 the ACP of that domain via ACP edge nodes. 550 ACP (ULA) prefix(es): The /48 IPv6 address prefixes used across the 551 ACP. In the normal/simple case, the ACP has one ULA prefix, see 552 Section 6.10. The ACP routing table may include multiple ULA 553 prefixes if the "rsub" option is used to create addresses from 554 more than one ULA prefix. See Section 6.1.2. The ACP may also 555 include non-ULA prefixes if those are configured on ACP connect 556 interfaces. See Section 8.1.1. 558 ACP secure channel: A channel authenticated via ->"ACP domain 559 certificates" () providing integrity protection and 560 confidentiality through encryption. These are established between 561 (normally) adjacent ACP nodes to carry traffic of the ACP VRF 562 securely and isolated from Data-Plane traffic in-band over the 563 same link/path as the Data-Plane. 565 ACP secure channel protocol: The protocol used to build an ACP 566 secure channel, e.g., Internet Key Exchange Protocol version 2 567 (IKEv2) with IPsec or Datagram Transport Layer Security (DTLS). 569 ACP virtual interface: An interface in the ACP VRF mapped to one or 570 more ACP secure channels. See Section 6.12.5. 572 AN "Autonomic Network": A network according to 573 [I-D.ietf-anima-reference-model]. Its main components are ANI, 574 Autonomic Functions and Intent. 576 (AN) Domain Name: An FQDN (Fully Qualified Domain Name) in the acp- 577 node-name of the Domain Certificate. See Section 6.1.2. 579 ANI (nodes/network): "Autonomic Network Infrastructure". The ANI is 580 the infrastructure to enable Autonomic Networks. It includes ACP, 581 BRSKI and GRASP. Every Autonomic Network includes the ANI, but 582 not every ANI network needs to include autonomic functions beyond 583 the ANI (nor Intent). An ANI network without further autonomic 584 functions can for example support secure zero-touch (automated) 585 bootstrap and stable connectivity for SDN networks - see 586 [RFC8368]. 588 ANIMA: "Autonomic Networking Integrated Model and Approach". ACP, 589 BRSKI and GRASP are specifications of the IETF ANIMA working 590 group. 592 ASA: "Autonomic Service Agent". Autonomic software modules running 593 on an ANI device. The components making up the ANI (BRSKI, ACP, 594 GRASP) are also described as ASAs. 596 Autonomic Function: A function/service in an Autonomic Network (AN) 597 composed of one or more ASA across one or more ANI nodes. 599 BRSKI: "Bootstrapping Remote Secure Key Infrastructures" 600 ([I-D.ietf-anima-bootstrapping-keyinfra]. A protocol extending 601 EST to enable secure zero-touch bootstrap in conjunction with ACP. 602 ANI nodes use ACP, BRSKI and GRASP. 604 CA: "Certification Authority". An entity that issues digital 605 certificates. A CA uses its private key to sign the certificates 606 it issues, relying parties use the public key in the CA 607 certificate to validate the signature. This signing certificate 608 can be considered to be an identifier of the CA, so the term CA is 609 also loosely used to refer to the certificate used by the CA for 610 signing. 612 CRL: "Certificate Revocation List". A list of revoked certificates. 613 Required to revoke certificates before their lifetime expires. 615 Data-Plane: The counterpoint to the ACP VRF in an ACP node: 616 forwarding of user traffic and in non-autonomous nodes/networks 617 also any non-autonomous control and/or management plane functions. 618 In a fully Autonomic Network node, the Data-Plane is managed 619 autonomically via Autonomic Functions and Intent. See Section 1 620 for more detailed explanations. 622 device: A physical system, or physical node. 624 Enrollment: The process through which a node authenticates itself to 625 a network with an initial identity, which is often called IDevID 626 certificate, and acquires from the network a network specific 627 identity, which is often called LDevID certificate, and 628 certificates of one or more Trust Anchor(s). In the ACP, the 629 LDevID certificate is called the ACP Domain Certificate. 631 EST: "Enrollment over Secure Transport" ([RFC7030]). IETF standard- 632 track protocol for enrollment of a node with an LDevID 633 certificate. BRSKI is based on EST. 635 GRASP: "Generic Autonomic Signaling Protocol". An extensible 636 signaling protocol required by the ACP for ACP neighbor discovery. 638 The ACP also provides the "security and transport substrate" for 639 the "ACP instance of GRASP". This instance of GRASP runs across 640 the ACP secure channels to support BRSKI and other NOC/OAM or 641 Autonomic Functions. See [I-D.ietf-anima-grasp]. 643 IDevID: An "Initial Device IDentity" X.509 certificate installed by 644 the vendor on new equipment. Contains information that 645 establishes the identity of the node in the context of its vendor/ 646 manufacturer such as device model/type and serial number. See 647 [AR8021]. The IDevID certificate cannot be used as a node 648 identifier for the ACP because they are not provisioned by the 649 owner of the network, so they can not directly indicate an ACP 650 domain they belong to. 652 in-band (management/signaling): In-band management traffic and/or 653 control plane signaling uses the same network resources such as 654 routers/switches and network links that it manages/controls. In- 655 band is the standard management and signaling mechanism in IP 656 networks. Compared to ->"out-of-band" () it requires no 657 additional physical resources, but introduces potentially circular 658 dependencies for its correct operations. See ->"introduction" 659 (Introduction (Informative)). 661 Intent: Policy language of an autonomic network according to 662 [I-D.ietf-anima-reference-model]. 664 Loopback interface: See ->"ACP Loopback interface" (). 666 LDevID: A "Local Device IDentity" is an X.509 certificate installed 667 during "enrollment". The Domain Certificate used by the ACP is an 668 LDevID certificate. See [AR8021]. 670 Management: Used in this document as another word for ->"OAM" (). 672 MASA (service): "Manufacturer Authorized Signing Authority". A 673 vendor/manufacturer or delegated cloud service on the Internet 674 used as part of the BRSKI protocol. 676 MIC: "Manufacturer Installed Certificate". This is another word to 677 describe an IDevID in referenced materials. This term is not used 678 in this document. 680 native interface: Interfaces existing on a node without 681 configuration of the already running node. On physical nodes 682 these are usually physical interfaces. On virtual nodes their 683 equivalent. 685 NOC: Network Operations Center. 687 node: A system supporting the ACP according to this document. Can 688 be virtual or physical. Physical nodes are called devices. 690 Node-ID: The identifier of an ACP node inside that ACP. It is the 691 last 64 (see Section 6.10.3) or 78-bits (see Section 6.10.5) of 692 the ACP address. 694 OAM: Operations, Administration and Management. Includes Network 695 Monitoring. 697 Operational Technology (OT): "https://en.wikipedia.org/wiki/ 698 Operational_Technology" [1]: "The hardware and software dedicated 699 to detecting or causing changes in physical processes through 700 direct monitoring and/or control of physical devices such as 701 valves, pumps, etc.". OT networks are today in most cases well 702 separated from Information Technology (IT) networks. 704 out-of-band (management) network: An out-of-band network is a 705 secondary network used to manage a primary network. The equipment 706 of the primary network is connected to the out-of-band network via 707 dedicated management ports on the primary network equipment. 708 Serial (console) management ports were historically most common, 709 higher end network equipment now also has ethernet ports dedicated 710 only for management. An out-of-band network provides management 711 access to the primary network independent of the configuration 712 state of the primary network. See ->"introduction" 713 (Introduction (Informative)) 715 (virtual) out-of-band network: The ACP can be called a virtual out- 716 of-band network for management and control because it attempts to 717 provide the benefits of a (physical) ->"out-of-band netork" () 718 even though it is physcially carried ->"in-band" (). See 719 ->"introduction" (Introduction (Informative)). 721 root CA: "root Certification Authority". A ->"CA" () for which the 722 root CA Key update procedures of [RFC7030], Section 4.4 can be 723 applied. 725 RPL: "IPv6 Routing Protocol for Low-Power and Lossy Networks". The 726 routing protocol used in the ACP. See [RFC6550]. 728 (ACP/ANI/BRSKI) Registrar: An ACP registrar is an entity (software 729 and/or person) that is orchestrating the enrollment of ACP nodes 730 with the ACP domain certificate. ANI nodes use BRSKI, so ANI 731 registrars are also called BRSKI registrars. For non-ANI ACP 732 nodes, the registrar mechanisms are undefined by this document. 733 See Section 6.10.7. Renewal and other maintenance (such as 734 revocation) of ACP domain certificates may be performed by other 735 entities than registrars. EST must be supported for ACP domain 736 certificate renewal (see Section 6.1.5). BRSKI is an extension of 737 EST, so ANI/BRSKI registrars can easily support ACP domain 738 certificate renewal in addition to initial enrollment. 740 RPI: "RPL Packet Information". Network extension headers for use 741 with the ->"RPL" () routing protocols. Not used with RPL in the 742 ACP. See Section 6.11.1.13. 744 RPL: "Routing Protocol for Low-Power and Lossy Networks". The 745 routing protocol used in the ACP. See Section 6.11. 747 sUDI: "secured Unique Device Identifier". This is another word to 748 describe an IDevID in referenced material. This term is not used 749 in this document. 751 TA: "Trust Anchor". A Trust Anchor is an entity that is trusted for 752 the purpose of certificate validation. Trust Anchor Information 753 such as self-signed certificate(s) of the Trust Anchor is 754 configured into the ACP node as part of Enrollment. See 755 [RFC5280], Section 6.1.1. 757 UDI: "Unique Device Identifier". In the context of this document 758 unsecured identity information of a node typically consisting of 759 at least device model/type and serial number, often in a vendor 760 specific format. See sUDI and LDevID. 762 ULA: (Global ID prefix) A "Unique Local Address" (ULA) is an IPv6 763 address in the block fc00::/7, defined in [RFC4193]. It is the 764 approximate IPv6 counterpart of the IPv4 private address 765 ([RFC1918]). The ULA Global ID prefix are the first 48-bits of a 766 ULA address. In this document it is abbreviated as "ULA prefix". 768 (ACP) VRF: The ACP is modeled in this document as a "Virtual Routing 769 and Forwarding" instance (VRF). This means that it is based on a 770 "virtual router" consisting of a separate IPv6 forwarding table to 771 which the ACP virtual interfaces are attached and an associated 772 IPv6 routing table separate from the Data-Plane. Unlike the VRFs 773 on MPLS/VPN-PE ([RFC4364]) or LISP XTR ([RFC6830]), the ACP VRF 774 does not have any special "core facing" functionality or routing/ 775 mapping protocols shared across multiple VRFs. In vendor products 776 a VRF such as the ACP-VRF may also be referred to as a so called 777 VRF-lite. 779 (ACP) Zone: An ACP zone is a set of ACP nodes using the same zone 780 field value in their ACP address according to Section 6.10.3. 781 Zones are a mechanism to support structured addressing of ACP 782 addresses within the same /48-bit ULA prefix. 784 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 785 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 786 "OPTIONAL" in this document are to be interpreted as described in BCP 787 14 [RFC2119],[RFC8174] when, and only when, they appear in all 788 capitals, as shown here. 790 3. Use Cases for an Autonomic Control Plane (Informative) 792 This section summarizes the use cases that are intended to be 793 supported by an ACP. To understand how these are derived from and 794 relate to the larger set of use cases for autonomic networks, please 795 refer to [RFC8316]. 797 3.1. An Infrastructure for Autonomic Functions 799 Autonomic Functions need a stable infrastructure to run on, and all 800 autonomic functions should use the same infrastructure to minimize 801 the complexity of the network. In this way, there is only need for a 802 single discovery mechanism, a single security mechanism, and single 803 instances of other processes that distributed functions require. 805 3.2. Secure Bootstrap over a not configured Network 807 Today, bootstrapping a new node typically requires all nodes between 808 a controlling node such as an SDN controller ("Software Defined 809 Networking", see [RFC7426]) and the new node to be completely and 810 correctly addressed, configured and secured. Bootstrapping and 811 configuration of a network happens in rings around the controller - 812 configuring each ring of devices before the next one can be 813 bootstrapped. Without console access (for example through an out-of- 814 band network) it is not possible today to make devices securely 815 reachable before having configured the entire network leading up to 816 them. 818 With the ACP, secure bootstrap of new devices and whole new networks 819 can happen without requiring any configuration of unconfigured 820 devices along the path: As long as all devices along the path support 821 ACP and a zero-touch bootstrap mechanism such as BRSKI, the ACP 822 across a whole network of unconfigured devices can be brought up 823 without operator/provisioning intervention. The ACP also provides 824 additional security for any bootstrap mechanism, because it can 825 provide encrypted discovery (via ACP GRASP) of registrars or other 826 bootstrap servers by bootstrap proxies connecting to nodes that are 827 to be bootstrapped and the ACP encryption hides the identities of the 828 communicating entities (pledge and registrar), making it more 829 difficult to learn which network node might be attackable. The ACP 830 domain certificate can also be used to end-to-end encrypt the 831 bootstrap communication between such proxies and server. Note that 832 bootstrapping here includes not only the first step that can be 833 provided by BRSKI (secure keys), but also later stages where 834 configuration is bootstrapped. 836 3.3. Data-Plane Independent Permanent Reachability 838 Today, most critical control plane protocols and OAM protocols are 839 using the Data-Plane of the network. This leads to often undesirable 840 dependencies between control and OAM plane on one side and the Data- 841 Plane on the other: Only if the forwarding and control plane of the 842 Data-Plane are configured correctly, will the Data-Plane and the OAM/ 843 control plane work as expected. 845 Data-Plane connectivity can be affected by errors and faults, for 846 example misconfigurations that make AAA (Authentication, 847 Authorization and Accounting) servers unreachable or can lock an 848 administrator out of a device; routing or addressing issues can make 849 a device unreachable; shutting down interfaces over which a current 850 management session is running can lock an admin irreversibly out of 851 the device. Traditionally only out-of-band access can help recover 852 from such issues (such as serial console or ethernet management 853 port). 855 Data-Plane dependencies also affect applications in a Network 856 Operations Center (NOC) such as SDN controller applications: Certain 857 network changes are today hard to implement, because the change 858 itself may affect reachability of the devices. Examples are address 859 or mask changes, routing changes, or security policies. Today such 860 changes require precise hop-by-hop planning. 862 Note that specific control plane functions for the Data-Plane often 863 want to depend on forwarding of their packets via the Data-Plane: 864 Aliveness and routing protocol signaling packets across the Data- 865 Plane to verify reachability across the Data-Plane, using IPv4 866 signaling packets for IPv4 routing vs. IPv6 signaling packets for 867 IPv6 routing. 869 Assuming appropriate implementation (see Section 6.12.2 for more 870 details), the ACP provides reachability that is independent of the 871 Data-Plane. This allows the control plane and OAM plane to operate 872 more robustly: 874 o For management plane protocols, the ACP provides the functionality 875 of a Virtual out-of-band (VooB) channel, by providing connectivity 876 to all nodes regardless of their Data-Plane configuration, routing 877 and forwarding tables. 879 o For control plane protocols, the ACP allows their operation even 880 when the Data-Plane is temporarily faulty, or during transitional 881 events, such as routing changes, which may affect the control 882 plane at least temporarily. This is specifically important for 883 autonomic service agents, which could affect Data-Plane 884 connectivity. 886 The document "Using Autonomic Control Plane for Stable Connectivity 887 of Network OAM" [RFC8368] explains this use case for the ACP in 888 significantly more detail and explains how the ACP can be used in 889 practical network operations. 891 4. Requirements (Informative) 893 The following requirements were identified for the design of the ACP 894 based on the above use-cases (Section 3). These requirements are 895 informative. The ACP as specified in the normative parts of this 896 document is meeting or exceeding these use-case requirements: 898 ACP1: The ACP should provide robust connectivity: As far as 899 possible, it should be independent of configured addressing, 900 configuration and routing. Requirements 2 and 3 build on this 901 requirement, but also have value on their own. 903 ACP2: The ACP must have a separate address space from the Data- 904 Plane. Reason: traceability, debug-ability, separation from 905 Data-Plane, infrastructure security (filtering based on known 906 address space). 908 ACP3: The ACP must use autonomically managed address space. Reason: 909 easy bootstrap and setup ("autonomic"); robustness (admin 910 cannot break network easily). This document uses Unique Local 911 Addresses (ULA) for this purpose, see [RFC4193]. 913 ACP4: The ACP must be generic, that is it must be usable by all the 914 functions and protocols of the ANI. Clients of the ACP must 915 not be tied to a particular application or transport protocol. 917 ACP5: The ACP must provide security: Messages coming through the ACP 918 must be authenticated to be from a trusted node, and should 919 (very strong should) be encrypted. 921 Explanation for ACP4: In a fully autonomic network (AN), newly 922 written ASA could potentially all communicate exclusively via GRASP 923 with each other, and if that was assumed to be the only requirement 924 against the ACP, it would not need to provide IPv6 layer connectivity 925 between nodes, but only GRASP connectivity. Nevertheless, because 926 ACP also intends to support non-AN networks, it is crucial to support 927 IPv6 layer connectivity across the ACP to support any transport and 928 application layer protocols. 930 The ACP operates hop-by-hop, because this interaction can be built on 931 IPv6 link local addressing, which is autonomic, and has no dependency 932 on configuration (requirement 1). It may be necessary to have ACP 933 connectivity across non-ACP nodes, for example to link ACP nodes over 934 the general Internet. This is possible, but introduces a dependency 935 against stable/resilient routing over the non-ACP hops (see 936 Section 8.2). 938 5. Overview (Informative) 940 When a node has an ACP domain certificate (see Section 6.1.1) and is 941 enabled to bring up the ACP (see Section 9.3.5), it will create its 942 ACP without any configuration as follows. For details, see Section 6 943 and further sections: 945 1. The node creates a VRF instance, or a similar virtual context for 946 the ACP. 948 2. The node assigns its ULA IPv6 address (prefix) (see Section 6.10 949 which is learned from the acp-node-name (see (see Section 6.1.2) 950 of its ACP domain certificate (see Section 6.1.1) to an ACP 951 loopback interface (see Section 6.10) and connects this interface 952 into the ACP VRF. 954 3. The node establishes a list of candidate peer adjacencies and 955 candidate channel types to try for the adjacency. This is 956 automatic for all candidate link-local adjacencies, see 957 Section 6.3 across all native interfaces (see Section 9.3.4). If 958 a candidate peer is discovered via multiple interfaces, this will 959 result in one adjacency per interface. If the ACP node has 960 multiple interfaces connecting to the same subnet across which it 961 is also operating as an L2 switch in the Data-Plane, it employs 962 methods for ACP with L2 switching, see Section 7. 964 4. For each entry in the candidate adjacency list, the node 965 negotiates a secure tunnel using the candidate channel types. 966 See Section 6.5. 968 5. The node authenticates the peer node during secure channel setup 969 and authorizes it to become part of the ACP according to 970 Section 6.1.3. 972 6. Each successfully established secure channel is mapped into an 973 ACP virtual interface, which is placed into the ACP VRF. See 974 Section 6.12.5.2. 976 7. Each node runs a lightweight routing protocol, see Section 6.11, 977 to announce reachability of the ACP loopack address (or prefix) 978 across the ACP. 980 8. This completes the creation of the ACP with hop-by-hop secure 981 tunnels, auto-addressing and auto-routing. The node is now an 982 ACP node with a running ACP. 984 Note: 986 o None of the above operations (except the following explicit 987 configured ones) are reflected in the configuration of the node. 989 o Non-ACP NMS ("Network Management Systems") or SDN controllers have 990 to be explicitly configured for connection into the ACP. 992 o Additional candidate peer adjacencies for ACP connections across 993 non-ACP Layer-3 clouds requires explicit configuration. See 994 Section 8.2. 996 The following figure illustrates the ACP. 998 ACP node 1 ACP node 2 999 ................... ................... 1000 secure . . secure . . secure 1001 channel: +-----------+ : channel : +-----------+ : channel 1002 ..--------| ACP VRF |---------------------| ACP VRF |---------.. 1003 : / \ / \ <--routing--> / \ / \ : 1004 : \ / \ / \ / \ / : 1005 ..--------| Loopback |---------------------| Loopback |---------.. 1006 : | interface | : : | interface | : 1007 : +-----------+ : : +-----------+ : 1008 : : : : 1009 : Data-Plane :...............: Data-Plane : 1010 : : link : : 1011 :.................: :.................: 1013 Figure 1: ACP VRF and secure channels 1015 The resulting overlay network is normally based exclusively on hop- 1016 by-hop tunnels. This is because addressing used on links is IPv6 1017 link local addressing, which does not require any prior set-up. In 1018 this way the ACP can be built even if there is no configuration on 1019 the node, or if the Data-Plane has issues such as addressing or 1020 routing problems. 1022 6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 1024 This section describes the components and steps to set up an ACP and 1025 highlights the key properties which make it "indestructible" against 1026 many inadvertent changes to the Data-Plane, for example caused by 1027 misconfigurations. 1029 An ACP node can be a router, switch, controller, NMS host, or any 1030 other IP capable node. Initially, it MUST have its ACP domain 1031 certificate, as well as an (empty) ACP Adjacency Table (described in 1032 Section 6.2). It then can start to discover ACP neighbors and build 1033 the ACP. This is described step by step in the following sections: 1035 6.1. ACP Domain, Certificate and Network 1037 The ACP relies on group security. An ACP domain is a group of nodes 1038 that trust each other to participate in ACP operations such as 1039 creating ACP secure channels in an autonomous peer-to-peer fashion 1040 between ACP domain members via protocols such as IPsec. To 1041 authenticate and authorize another ACP member node with access to the 1042 ACP Domain, each ACP member requires keying material: An ACP node 1043 MUST have a Local Device IDentity (LDevID) certificate, henceforth 1044 called the ACP Domain Certificate and information about one or more 1045 Trust Anchor (TA) as required for the ACP domain membership check 1046 (Section 6.1.3). 1048 Manual keying via shared secrets is not usable for an ACP domain 1049 because it would require a single shared secret across all current 1050 and future ACP domain members to meet the expectation of autonomous, 1051 peer-to-peer establishment of ACP secure channels between any ACP 1052 domain members. Such a single shared secret would be an inacceptable 1053 security weakness. Asymmetric keying material (public keys) without 1054 certificates does not provide the mechanisms to authenticate ACP 1055 domain membership in an autonomous, peer-to-peer fashion for current 1056 and future ACP domain members. 1058 The LDevID certificate is called the ACP domain certificate, the TA 1059 is the Certification Authority (CA) root certificate of the ACP 1060 domain. 1062 The ACP does not mandate specific mechanisms by which this keying 1063 material is provisioned into the ACP node. It only requires the 1064 certificate to comply with Section 6.1.1, specifically to have the 1065 acp-node-name as specified in Section 6.1.2 in its domain certificate 1066 as well as those of candidate ACP peers. See Appendix A.2 for more 1067 information about enrollment or provisioning options. 1069 This document uses the term ACP in many places where the Autonomic 1070 Networking reference documents [RFC7575] and 1071 [I-D.ietf-anima-reference-model] use the word autonomic. This is 1072 done because those reference documents consider (only) fully 1073 autonomic networks and nodes, but support of ACP does not require 1074 support for other components of autonomic networks except for relying 1075 on GRASP and providing security and transport for GRASP. Therefore 1076 the word autonomic might be misleading to operators interested in 1077 only the ACP. 1079 [RFC7575] defines the term "Autonomic Domain" as a collection of 1080 autonomic nodes. ACP nodes do not need to be fully autonomic, but 1081 when they are, then the ACP domain is an autonomic domain. Likewise, 1082 [I-D.ietf-anima-reference-model] defines the term "Domain 1083 Certificate" as the certificate used in an autonomic domain. The ACP 1084 domain certificate is that domain certificate when ACP nodes are 1085 (fully) autonomic nodes. Finally, this document uses the term ACP 1086 network to refer to the network created by active ACP nodes in an ACP 1087 domain. The ACP network itself can extend beyond ACP nodes through 1088 the mechanisms described in Section 8.1. 1090 6.1.1. ACP Certificates 1092 ACP domain certificates MUST be [RFC5280] compliant X.509v3 1093 certificates. 1095 ACP nodes MUST support handling ACP certificates, TA certificates and 1096 certificate chain certificates (henceforth just called certificates 1097 in this section) with RSA public keys and certificates with Elliptic 1098 Curve (ECC) public keys. 1100 ACP nodes MUST NOT support certificates with RSA public keys of less 1101 than 2048 bit modulus or curves with group order of less than 256 1102 bit. They MUST support certificates with RSA public keys with 2048 1103 bit modulus and MAY support longer RSA keys. They MUST support 1104 certificates with ECC public keys using NIST P-256 curves and SHOULD 1105 support P-384 and P-521 curves. 1107 ACP nodes MUST support SHA-256 and SHOULD support SHA-384, SHA-512 1108 signatures for certificates with RSA key and the same RSA signatures 1109 plus ECDSA signatures for certificates with ECC key. 1111 The ACP certificate SHOULD use an RSA key and an RSA signature when 1112 the ACP certificate is intended to be used not only for ACP 1113 authentication but also for other purposes. The ACP certificate MAY 1114 use an ECC key and an ECDSA signature if the ACP certificate is only 1115 used for ACP and ANI authentication and authorization. 1117 Any secure channel protocols used for the ACP as specified in this 1118 document or extensions of this document MUST therefore support 1119 authentication (e.g.:signing) starting with these type of 1120 certificates. See [RFC4492] for more information. 1122 The reason for these choices are as follows: As of 2020, RSA is still 1123 more widely used than ECC, therefore the MUST for RSA. ECC offers 1124 equivalent security at (logarithmically) shorter key lengths (see 1125 [RFC4492]). This can be beneficial especially in the presence of 1126 constrained bandwidth or constrained nodes in an ACP/ANI network. 1127 Some ACP functions such as GRASP peer-2-peer across the ACP require 1128 end-to-end/any-to-any authentication/authorization, therefore ECC can 1129 only reliably be used in the ACP when it MUST be supported on all ACP 1130 nodes. RSA signatures are mandatory to be supported also for ECC 1131 certificates because CAs themselves may not support ECC yet. 1133 The ACP domain certificate SHOULD be used for any authentication 1134 between nodes with ACP domain certificates (ACP nodes and NOC nodes) 1135 where the required authorization condition is ACP domain membership, 1136 such as ACP node to NOC/OAM end-to-end security and ASA to ASA end- 1137 to-end security. Section 6.1.3 defines this "ACP domain membership 1138 check". The uses of this check that are standardized in this 1139 document are for the establishment of hop-by-hop ACP secure channels 1140 (Section 6.6) and for ACP GRASP (Section 6.8.2) end-to-end via TLS 1141 1.2 ([RFC5246]). 1143 The ACP domain membership check requires a minimum amount of elements 1144 in a certificate as described in Section 6.1.3. The identity of a 1145 node in the ACP is carried via the acp-node-name as defined in 1146 Section 6.1.2. 1148 In support of ECDH key establishment, ACP certificates with ECC keys 1149 MUST indicate to be Elliptic Curve Diffie-Hellman capable (ECDH) if 1150 X.509 v3 keyUsage and extendedKeyUsage are included in the 1151 certificate. 1153 Any other field of the ACP domain certificate is to be populated as 1154 required by [RFC5280] or desired by the operator of the ACP domain 1155 ACP registrars/CA and required by other purposes that the ACP domain 1156 certificate is intended to be used for. 1158 For further certificate details, ACP certificates may follow the 1159 recommendations from [CABFORUM]. 1161 For diagnostic and other operational purposes, it is beneficial to 1162 copy the device identifying fields of the node's IDevID certificate 1163 into the ACP domain certificate, such as the "serialNumber" (see 1164 [I-D.ietf-anima-bootstrapping-keyinfra] section 2.3.1). This can be 1165 done for example if it would be acceptable for the devices 1166 "serialNumber" to be signalled via the Link Layer Discovery Protocol 1167 (LLDP, [LLDP]) because like LLDP signalled information, the ACP 1168 certificate information can be retrieved bei neighboring nodes 1169 without further authentication and be used either for beneficial 1170 diagnostics or for malicious attacks. Retrieval of the ACP 1171 certificate is possible via a (failing) attempt to set up an ACP 1172 secure channel, and the "serialNumber" contains usually device type 1173 information that may help to faster determine working exploits/ 1174 attacks against the device. 1176 Note that there is no intention to constrain authorization within the 1177 ACP or autonomic networks using the ACP to just the ACP domain 1178 membership check as defined in this document. It can be extended or 1179 modified with future requirements. Such future authorizations can 1180 use and require additional elements in certificates or policies or 1181 even additional certificates. For an example, see Appendix A.10.5. 1183 6.1.2. ACP Certificate AcpNodeName 1185 acp-node-name = local-part "@" acp-domain-name 1186 local-part = [ acp-address ] [ "+" rsub extensions ] 1187 HEXLC = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" 1188 ; DIGIT as of RFC5234 section B.1 1189 acp-address = 32HEXLC | "0" 1190 rsub = [ ] ; as of RFC1034, section 3.5 1191 acp-domain-name = ; ; as of RFC 1034, section 3.5 1192 extensions = *( "+" extension ) 1193 extension = ; future standard definition. 1194 ; Must fit RFC5322 simple dot-atom format. 1196 routing-subdomain = [ rsub "." ] acp-domain-name 1198 Example: 1199 given an ACP address of fd89:b714:f3db:0:200:0:6400:0000 1200 and an ACP domain-name of acp.example.com 1201 and an rsub extenstion of area51.research 1203 then this results in: 1204 acp-node-name = fd89b714F3db00000200000064000000 1205 +area51.research@acp.example.com 1206 acp-domain-name = acp.example.com 1207 routing-subdomain = area51.research.acp.example.com 1209 Figure 2: ACP Node Name ABNF 1211 acp-node-name in above Figure 2 is the ABNF ([RFC5234]) definition of 1212 the ACP Node Name. An ACP domain certificate MUST carry this 1213 information. It MUST be encoded as a subjectAltName / otherName / 1214 AcpNodeName as described in Section 6.1.2.1. 1216 Nodes complying with this specification MUST be able to receive their 1217 ACP address through the domain certificate, in which case their own 1218 ACP domain certificate MUST have the 32HEXDIG "acp-address" field. 1219 Nodes complying with this specification MUST also be able to 1220 authenticate nodes as ACP domain members or ACP secure channel peers 1221 when they have a 0-value acp-address field and as ACP domain members 1222 (but not as ACP secure channel peers) when they have an empty acp- 1223 address field. See Section 6.1.3. 1225 acp-domain-name is used to indicate the ACP Domain across which ACP 1226 nodes authenticate and authorize each other, for example to build ACP 1227 secure channels to each other, see Section 6.1.3. acp-domain-name 1228 SHOULD be the FQDN of an Internet domain owned by the network 1229 administration of the ACP and ideally reserved to only be used for 1230 the ACP. In this specification it serves to be a name for the ACP 1231 that ideally is globally unique. When acp-domain-name is a globally 1232 unique name, collision of ACP addresses across different ACP domains 1233 can only happen due to ULA hash collisions (see Section 6.10.2). 1234 Using different acp-domain-names, operators can distinguish multiple 1235 ACP even when using the same TA. 1237 To keep the encoding simple, there is no consideration for 1238 internationalized acp-domain-names. The acp-node-name is not 1239 intended for end user consumption, and there is no protection against 1240 someone not owning a domain name to simpy choose it. Instead, it 1241 serves as a hash seed for the ULA and for diagnostics to the 1242 operator. Therefore, any operator owning only an internationalized 1243 domain name should be able to pick an equivalently unique 7-bit ASCII 1244 acp-domain-name string representing the internationalized domain 1245 name. 1247 "routing-subdomain" is a string that can be constructed from the acp- 1248 node-name, and it is used in the hash-creation of the ULA (see 1249 below). The presence of the "rsub" component allows a single ACP 1250 domain to employ multiple /48 ULA prefixes. See Appendix A.7 for 1251 example use-cases. 1253 The optional "extensions" field is used for future standardized 1254 extensions to this specification. It MUST be ignored if present and 1255 not understood. 1257 The following points explain and justify the encoding choices 1258 described: 1260 1. Formatting notes: 1262 1.1 "rsub" needs to be in the "local-part": If the format just 1263 had routing-subdomain as the domain part of the acp-node- 1264 name, rsub and acp-domain-name could not be separated from 1265 each other to determine in the ACP domain membership check 1266 which part is the acp-domain-name and which is solely for 1267 creating a different ULA prefix. 1269 1.2 If "acp-address" is empty, and "rsub" is empty too, the 1270 "local-part" will have the format ":++extension(s)". The 1271 two plus characters are necessary so the node can 1272 unambiguously parse that both "acp-address" and "rsub" are 1273 empty. 1275 2. The encoding of the ACP domain name and ACP address as described 1276 in this section is used for the following reasons: 1278 2.1 The acp-node-name is the identifier of a node's ACP. It 1279 includes the necessary components to identify a nodes ACP 1280 both from within the ACP as well as from the outside of the 1281 ACP. 1283 2.2 For manual and/or automated diagnostics and backend 1284 management of devices and ACPs, it is necessary to have an 1285 easily human readible and software parsed standard, single 1286 string representation of the information in the acp-node- 1287 name. For example, inventory or other backend systems can 1288 always identify an entity by one unique string field but not 1289 by a combination of multiple fields, which would be 1290 necessary if there was no single string representation. 1292 2.3 If the encoding was not that of such a string, it would be 1293 necessary to define a second standard encoding to provide 1294 this format (standard string encoding) for operator 1295 consumption. 1297 2.4 Adresses of the form <@domain> have become the 1298 preferred format for identifiers of entities in many 1299 systems, including the majority of user identification in 1300 web or mobile applications such as multi-domain single-sign- 1301 on systems. 1303 3. Compatibilities: 1305 3.1 It should be possible to use the ACP domain certificate as 1306 an LDevID certificate on the system for other uses beside 1307 the ACP. Therefore, the information element required for 1308 the ACP should be encoded so that it minimizes the 1309 possibility of creating incompatibilities with such other 1310 uses. The subjectName is for example often used as an 1311 entity identifier in non-ACP uses of a the ACP Domain 1312 certificate. 1314 3.2 The element should not require additional ASN.1 en/decoding, 1315 because libraries to access certificate information 1316 especially for embedded devices may not support extended 1317 ASN.1 decoding beyond predefined, manadatory fields. 1318 subjectAltName / otherName is already used with a single 1319 string parameter for several otherNames (see [RFC3920], 1320 [RFC7585], [RFC4985], [RFC8398]). 1322 3.3 The element required for the ACP should minimize the risk of 1323 being misinterpreted by other uses of the LDevID 1324 certificate. It also must not be misinterpreted to actually 1325 be an email address, hence the use of the otherName / 1326 rfc822Name option in the certificate would be inapproprite. 1328 See section 4.2.1.6 of [RFC5280] for details on the subjectAltName 1329 field. 1331 6.1.2.1. AcpNodeName ASN.1 Module 1333 The following ASN.1 module normatively specifies the AcpNodeName 1334 structure. This specification uses the ASN.1 definitions from 1335 [RFC5912] with the 2002 ASN.1 notation used in that document. 1336 [RFC5912] updates normative documents using older ASN.1 notation. 1338 ANIMA-ACP-2020 1339 { iso(1) identified-organization(3) dod(6) 1340 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 1341 id-mod-anima-acpnodename-2020(IANA1) } 1343 DEFINITIONS IMPLICIT TAGS ::= 1344 BEGIN 1346 IMPORTS 1347 OTHER-NAME 1348 FROM PKIX1Implicit-2009 1349 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 1350 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59) } 1352 id-pkix 1353 FROM PKIX1Explicit-2009 1354 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 1355 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51) } ; 1357 id-on OBJECT IDENTIFIER ::= { id-pkix 8 } 1359 AcpNodeNameOtherNames OTHER-NAME ::= { on-AcpNodeName, ... } 1361 on-AcpNodeName OTHER-NAME ::= { 1362 AcpNodeName IDENTIFIED BY id-on-AcpNodeName 1363 } 1365 id-on-AcpNodeName OBJECT IDENTIFIER ::= { id-on IANA2 } 1367 AcpNodeName ::= IA5String (SIZE (1..MAX)) 1368 -- AcpNodeName as specified in this document carries the 1369 -- acp-node-name as specified in the ABNF in Section 6.1.2 1371 END 1373 6.1.3. ACP domain membership check 1375 The following points constitute the ACP domain membership check of a 1376 candidate peer via its certificate: 1378 1: The peer has proved ownership of the private key associated with 1379 the certificate's public key. This check is performed by the 1380 security association protocol used, for example [RFC7296], section 1381 2.15. 1383 2: The peer's certificate passes certificate path validation as 1384 defined in [RFC5280], section 6 against one of the TA associated 1385 with the ACP node's ACP domain certificate (see Section 6.1.4 1386 below). This includes verification of the validity (lifetime) of 1387 the certificates in the path. 1389 3: If the node certificate indicates a Certificate Revocation List 1390 (CRL) Distribution Point (CRLDP) ([RFC5280], section 4.2.1.13) or 1391 Online Certificate Status Protocol (OCSP) responder ([RFC5280], 1392 section 4.2.2.1), then the peer's certificate MUST be valid 1393 according to those mechanisms when they are available: An OCSP 1394 check for the peer's certificate across the ACP must succeed or 1395 the peer certificate must not be listed in the CRL retrieved from 1396 the CRLDP. These mechanisms are not available when the node has 1397 no ACP or non-ACP connectivity to retrieve a current CRL or access 1398 an OCSP responder and the security association protocol itself has 1399 also no way to communicate CRL or OCSP check. 1401 Retries to learn revocation via OCSP/CRL SHOULD be made using 1402 the same backoff as described in Section 6.6. If and when the ACP 1403 node then learns that an ACP peer's certificate is invalid for 1404 which rule 3 had to be skipped during ACP secure channel 1405 establishment, then the ACP secure channel to that peer MUST be 1406 closed even if this peer is the only connectivity to access CRL/ 1407 OCSP. This applies (of course) to all ACP secure channels to this 1408 peer if there are multiple. The ACP secure channel connection 1409 MUST be retried periodically to support the case that the neighbor 1410 acquires a new, valid certificate. 1412 4: The peer's certificate has a syntactically valid acp-node-name 1413 field and the acp-domain-name in that peer's acp-node-name is the 1414 same as in this ACP node's certificate (lowercase normalized). 1416 When checking a candidate peer's certificate for the purpose of 1417 establishing an ACP secure channel, one additional check is 1418 performed: 1420 5: The candidate peer certificate's acp-node-name has a non-empty 1421 acp-address field (either 32HEXDIG or 0, according to Figure 2). 1423 Technically, ACP secure channels can only be built with nodes that 1424 have an acp-address. Rule 5 ensures that this is taken into account 1425 during ACP domain membership check. 1427 Nodes with an empty acp-address field can only use their ACP domain 1428 certificate for non-ACP-secure channel authentication purposes. This 1429 includes for example NMS type nodes permitted to communicate into the 1430 ACP via ACP connect (Section 8.1) 1432 The special value 0 in an ACP certificates acp-address field is used 1433 for nodes that can and should determine their ACP address through 1434 other mechanisms than learning it through the acp-address field in 1435 their ACP domain certificate. These ACP nodes are permitted to 1436 establish ACP secure channels. Mechanisms for those nodes to 1437 determine their ACP address are outside the scope of this 1438 specification, but this option is defined here so that any ACP nodes 1439 can build ACP secure channels to them according to Rule 5. 1441 In summary: 1443 Steps 1...4 constitute standard certificate validity verification 1444 and private key authentication as defined by [RFC5280] and 1445 security association protocols (such as Internet Key Exchange 1446 Protocol version 2 IKEv2 [RFC7296] when leveraging certificates. 1448 Steps 1...4 do not include verification of any pre-existing form 1449 of non-public-key-only based identity elements of a certificate 1450 such as a web servers domain name prefix often encoded in 1451 certificate common name. Steps 5 and 6 are the equivalent steps. 1453 Step 4 Constitutes standard CRL/OCSP checks refined for the case 1454 of missing connectivity and limited functionality security 1455 association protocols. 1457 Step 5 Checks for the presence of an ACP identity for the peer. 1459 Steps 1...5 authorize to build any secure connection between 1460 members of the same ACP domain except for ACP secure channels. 1462 Step 6 is the additional verification of the presence of an ACP 1463 address. 1465 Steps 1...6 authorize to build an ACP secure channel. 1467 For brevity, the remainder of this document refers to this process 1468 only as authentication instead of as authentication and 1469 authorization. 1471 6.1.3.1. Realtime clock and Time Validation 1473 An ACP node with a realtime clock in which it has confidence, MUST 1474 check the time stamps when performing ACP domain membership check 1475 such as as the certificate validity period in step 1. and the 1476 respective times in step 4 for revocation information (e.g.: 1477 signingTimes in CMS signatures). 1479 An ACP node without such a realtime clock MAY ignore those time stamp 1480 validation steps if it does not know the current time. Such an ACP 1481 node SHOULD obtain the current time in a secured fashion, such as via 1482 a Network Time Protocol signalled through the ACP. It then ignores 1483 time stamp validation only until the current time is known. In the 1484 absence of implementing a secured mechanism, such an ACP node MAY use 1485 a current time learned in an insecured fashion in the ACP domain 1486 membership check. 1488 Beside ACP domain membership check, the ACP itself has no dependency 1489 against knowledge of the current time, but protocols and services 1490 using the ACP will likley have the need to know the current time. 1491 For example event logging. 1493 6.1.4. Trust Anchors (TA) 1495 ACP nodes need TA information according to [RFC5280], section 6.1.1 1496 (d), typically in the form of one or more certificate of the TA to 1497 perform certificate path validation as required by Section 6.1.3, 1498 rule 2. TA information MUST be provisioned to an ACP node (together 1499 with its ACP domain certificate) by an ACP Registrar during initial 1500 enrolment of a candidate ACP node. ACP nodes MUST also support 1501 renewal of TA information via Enrollment over Secure Transport (EST, 1502 see [RFC7030]), as described below in Section 6.1.5. 1504 The required information about a TA can consist of not only a single, 1505 but multiple certificates as required for dealing with CA certificate 1506 renewals as explained in Section 4.4 of CMP ([RFC4210]). 1508 A certificate path is a chain of certificates starting at the ACP 1509 certificate (leaf/end-entity) followed by zero or more intermediate 1510 CA certificates and ending with the TA information, which are 1511 typically one or two the self-signed certificates of the TA. The CA 1512 that signs the ACP certificate is called the assigning CA. If there 1513 are no intermediate CA, then the assigning CA is the TA. Certificate 1514 path validation authenticates that the ACP certificate is permitted 1515 by a TA associated with the ACP, directly or indirectly via one or 1516 more intermediate CA. 1518 Note that different ACP nodes may have different intermediate CA in 1519 their certificate path and even different TA. The set of TA for an 1520 ACP domain must be consistent across all ACP members so that any ACP 1521 node can authenticate any other ACP node. The protocols through 1522 which ACP domain membership check rules 1-3 are performed need to 1523 support the exchange not only of the ACP nodes certificates, but also 1524 exchange of the intermedia TA. 1526 ACP nodes MUST support for the ACP domain membership check the 1527 certificate path validation with 0 or 1 intermediate CA. They SHOULD 1528 support 2 intermediate CA and two TA (to permit migration to from one 1529 TA to another TA). 1531 Certificates for an ACP MUST only be given to nodes that are allowed 1532 to be members of that ACP. When the signing CA relies on an ACP 1533 Registrar, the CA MUST only sign certificates with acp-node-name 1534 through trusted ACP Registrars. In this setup, any existing CA, 1535 unaware of the formatting of acp-node-name, can be used. 1537 These requirements can be achieved by using TA private to the owner 1538 of the ACP domain or potentially through appropriate contractual 1539 agreements between the involved parties (Registrar and CA). These 1540 requirements typically exclude public CA, because they in general do 1541 not support the notion of trusted registrars vouching for the 1542 correctness of the fields of a requested certificate or would by 1543 themselves not be capable to validate the correctness of otherName / 1544 AcpNodeName. 1546 A single owner can operate multiple independent ACP domains from the 1547 same set of TA. Registrars must then know which ACP a node needs to 1548 be enrolled into. 1550 6.1.5. Certificate and Trust Anchor Maintenance 1552 ACP nodes MUST support renewal of their Certificate and TA 1553 information via EST ("Enrollment over Secure Transport", see 1554 [RFC7030]) and MAY support other mechanisms. An ACP network MUST 1555 have at least one ACP node supporting EST server functionality across 1556 the ACP so that EST renewal is useable. 1558 ACP nodes SHOULD be able to remember the IPv6 locator parameters of 1559 the O_IPv6_LOCATOR in GRASP of the EST server from which they last 1560 renewed their ACP domain certificate. They SHOULD provide the 1561 ability for these EST server parameters to also be set by the ACP 1562 Registrar (see Section 6.10.7) that initially enrolled the ACP device 1563 with its ACP domain certificate. When BRSKI (see 1564 [I-D.ietf-anima-bootstrapping-keyinfra]) is used, the IPv6 locator of 1565 the BRSKI registrar from the BRSKI TLS connection SHOULD be 1566 remembered and used for the next renewal via EST if that registrar 1567 also announces itself as an EST server via GRASP (see next section) 1568 on its ACP address. 1570 The EST server MUST present a certificate that is passing ACP domain 1571 membership check in its TLS connection setup (Section 6.1.3, rules 1572 1..4, not rule 5 as this is not for an ACP secure channel setup). 1573 The EST server certificate MUST also contain the id-kp-cmcRA 1574 [RFC6402] extended key usage extension and the EST client MUST check 1575 its presence. 1577 The additional check against the id-kp-cmcRA extended key usage 1578 extension field ensures that clients do not fall prey to an illicit 1579 EST server. While such illicit EST servers should not be able to 1580 support certificate signing requests (as they are not able to elicit 1581 a signing response from a valid CA), such an illicit EST server would 1582 be able to provide faked CA certificates to EST clients that need to 1583 renew their CA certificates when they expire. 1585 Note that EST servers supporting multiple ACP domains will need to 1586 have for each of these ACP domains a separate certificate and respond 1587 on a different transport address (IPv6 address and/or TCP port), but 1588 this is easily automated on the EST server as long as the CA does not 1589 restrict registrars to request certificates with the id-kp-cmcRA 1590 extended usage extension for themselves. 1592 6.1.5.1. GRASP objective for EST server 1594 ACP nodes that are EST servers MUST announce their service via GRASP 1595 in the ACP through M_FLOOD messages. See [I-D.ietf-anima-grasp], 1596 section 2.8.11 for the definition of this message type: 1598 Example: 1600 [M_FLOOD, 12340815, h'fd89b714f3db0000200000064000001', 210000, 1601 [["SRV.est", 4, 255 ], 1602 [O_IPv6_LOCATOR, 1603 h'fd89b714f3db0000200000064000001', IPPROTO_TCP, 443]] 1604 ] 1606 Figure 3: GRASP SRV.est example 1608 The formal definition of the objective in Concise data definition 1609 language (CDDL) (see [RFC8610]) is as follows: 1611 flood-message = [M_FLOOD, session-id, initiator, ttl, 1612 +[objective, (locator-option / [])]] 1613 ; see example above and explanation 1614 ; below for initiator and ttl 1616 objective = ["SRV.est", objective-flags, loop-count, 1617 objective-value] 1619 objective-flags = sync-only ; as in GRASP spec 1620 sync-only = 4 ; M_FLOOD only requires synchronization 1621 loop-count = 255 ; recommended as there is no mechanism 1622 ; to discover network diameter. 1623 objective-value = any ; reserved for future extensions 1625 Figure 4: GRASP SRV.est definition 1627 The objective name "SRV.est" indicates that the objective is an 1628 [RFC7030] compliant EST server because "est" is an [RFC6335] 1629 registered service name for [RFC7030]. Objective-value MUST be 1630 ignored if present. Backward compatible extensions to [RFC7030] MAY 1631 be indicated through objective-value. Non [RFC7030] compatible 1632 certificate renewal options MUST use a different objective-name. 1633 Non-recognized objective-values (or parts thereof if it is a 1634 structure partially understood) MUST be ignored. 1636 The M_FLOOD message MUST be sent periodically. The default SHOULD be 1637 60 seconds, the value SHOULD be operator configurable but SHOULD be 1638 not smaller than 60 seconds. The frequency of sending MUST be such 1639 that the aggregate amount of periodic M_FLOODs from all flooding 1640 sources cause only negligible traffic across the ACP. The time-to- 1641 live (ttl) parameter SHOULD be 3.5 times the period so that up to 1642 three consecutive messages can be dropped before considering an 1643 announcement expired. In the example above, the ttl is 210000 msec, 1644 3.5 times 60 seconds. When a service announcer using these 1645 parameters unexpectedly dies immediately after sending the M_FLOOD, 1646 receivers would consider it expired 210 seconds later. When a 1647 receiver tries to connect to this dead service before this timeout, 1648 it will experience a failing connection and use that as an indication 1649 that the service instance is dead and select another instance of the 1650 same service instead (from another GRASP announcement). 1652 6.1.5.2. Renewal 1654 When performing renewal, the node SHOULD attempt to connect to the 1655 remembered EST server. If that fails, it SHOULD attempt to connect 1656 to an EST server learned via GRASP. The server with which 1657 certificate renewal succeeds SHOULD be remembered for the next 1658 renewal. 1660 Remembering the last renewal server and preferring it provides 1661 stickiness which can help diagnostics. It also provides some 1662 protection against off-path compromised ACP members announcing bogus 1663 information into GRASP. 1665 Renewal of certificates SHOULD start after less than 50% of the 1666 domain certificate lifetime so that network operations has ample time 1667 to investigate and resolve any problems that causes a node to not 1668 renew its domain certificate in time - and to allow prolonged periods 1669 of running parts of a network disconnected from any CA. 1671 6.1.5.3. Certificate Revocation Lists (CRLs) 1673 The ACP node SHOULD support revocation through CRL(s) via HTTP from 1674 one or more CRL Distribution Points (CRLDP). The CRLDP(s) MUST be 1675 indicated in the Domain Certificate when used. If the CRLDP URL uses 1676 an IPv6 address (ULA address when using the addressing rules 1677 specified in this document), the ACP node will connect to the CRLDP 1678 via the ACP. If the CRLDP uses a domain name, the ACP node will 1679 connect to the CRLDP via the Data-Plane. 1681 It is common to use domain names for CRLDP(s), but there is no 1682 requirement for the ACP to support DNS. Any DNS lookup in the Data- 1683 Plane is not only a possible security issue, but it would also not 1684 indicate whether the resolved address is meant to be reachable across 1685 the ACP. Therefore, the use of an IPv6 address versus the use of a 1686 DNS name doubles as an indicator whether or not to reach the CRLDP 1687 via the ACP. 1689 A CRLDP can be reachable across the ACP either by running it on a 1690 node with ACP or by connecting its node via an ACP connect interface 1691 (see Section 8.1). The CRLDP SHOULD use an ACP domain certificate 1692 for its HTTPs connections. The connecting ACP node SHOULD verify 1693 that the CRLDP certificate used during the HTTPs connection has the 1694 same ACP address as indicated in the CRLDP URL of the node's ACP 1695 domain certificate if the CRLDP URL uses an IPv6 address. 1697 6.1.5.4. Lifetimes 1699 Certificate lifetime may be set to shorter lifetimes than customary 1700 (1 year) because certificate renewal is fully automated via ACP and 1701 EST. The primary limiting factor for shorter certificate lifetimes 1702 is load on the EST server(s) and CA. It is therefore recommended 1703 that ACP domain certificates are managed via a CA chain where the 1704 assigning CA has enough performance to manage short lived 1705 certificates. See also Section 9.2.4 for discussion about an example 1706 setup achieving this. See also [I-D.ietf-acme-star]. 1708 When certificate lifetimes are sufficiently short, such as few hours, 1709 certificate revocation may not be necessary, allowing to simplify the 1710 overall certificate maintenance infrastructure. 1712 See Appendix A.2 for further optimizations of certificate maintenance 1713 when BRSKI can be used ("Bootstrapping Remote Secure Key 1714 Infrastructures", see [I-D.ietf-anima-bootstrapping-keyinfra]). 1716 6.1.5.5. Re-enrollment 1718 An ACP node may determine that its ACP domain certificate has 1719 expired, for example because the ACP node was powered down or 1720 disconnected longer than its certificate lifetime. In this case, the 1721 ACP node SHOULD convert to a role of a re-enrolling candidate ACP 1722 node. 1724 In this role, the node does maintain the TA and certificate chain 1725 associated with its ACP domain certificate exclusively for the 1726 purpose of re-enrollment, and attempts (or waits) to get re-enrolled 1727 with a new ACP certificate. The details depend on the mechanisms/ 1728 protocols used by the ACP Registrars. 1730 Please refer to Section 6.10.7 and 1731 [I-D.ietf-anima-bootstrapping-keyinfra] for explanations about ACP 1732 Registrars and vouchers as used in the following text. When ACP is 1733 intended to be used without BRSKI, the details about BRSKI and 1734 vouchers in the following text can be skipped. 1736 When BRSKI is used (i.e.: on ACP nodes that are ANI nodes), the re- 1737 enrolling candidate ACP node would attempt to enroll like a candidate 1738 ACP node (BRSKI pledge), but instead of using the ACP nodes IDevID 1739 certificate, it SHOULD first attempt to use its ACP domain 1740 certificate in the BRSKI TLS authentication. The BRSKI registrar MAY 1741 honor this certificate beyond its expiration date purely for the 1742 purpose of re-enrollment. Using the ACP node's domain certificate 1743 allows the BRSKI registrar to learn that node's acp-node-name, so 1744 that the BRSKI registrar can re-assign the same ACP address 1745 information to the ACP node in the new ACP domain certificate. 1747 If the BRSKI registrar denies the use of the old ACP domain 1748 certificate, the re-enrolling candidate ACP node MUST re-attempt re- 1749 enrollment using its IDevID certificate as defined in BRSKI during 1750 the TLS connection setup. 1752 Both when the BRSKI connection is attempted with the old ACP domain 1753 certificate or the IDevID certificate, the re-enrolling candidate ACP 1754 node SHOULD authenticate the BRSKI registrar during TLS connection 1755 setup based on its existing TA certificate chain information 1756 associated with its old ACP certificate. The re-enrolling candidate 1757 ACP node SHOULD only fall back to requesting a voucher from the BRSKI 1758 registrar when this authentication fails during TLS connection setup. 1760 When other mechanisms than BRSKI are used for ACP domain certificate 1761 enrollment, the principles of the re-enrolling candidate ACP node are 1762 the same. The re-enrolling candidate ACP node attempts to 1763 authenticate any ACP Registrar peers during re-enrollment protocol/ 1764 mechanisms via its existing certificate chain/TA information and 1765 provides its existing ACP domain certificate and other identification 1766 (such as the IDevID certificate) as necessary to the registrar. 1768 Maintaining existing TA information is especially important when 1769 enrollment mechanisms are used that unlike BRSKI do not leverage a 1770 voucher mechanism to authenticate the ACP registrar and where 1771 therefore the injection of certificate failures could otherwise make 1772 the ACP node easily attackable remotely. 1774 When using BRSKI or other protocol/mechanisms supporting vouchers, 1775 maintaining existing TA information allows for re-enrollment of 1776 expired ACP certificates to be more lightweight, especially in 1777 environments where repeated acquisition of vouchers during the 1778 lifetime of ACP nodes may be operationally expensive or otherwise 1779 undesirable. 1781 6.1.5.6. Failing Certificates 1783 An ACP domain certificate is called failing in this document, if/when 1784 the ACP node to which the certificate was issued can determine that 1785 it was revoked (or explicitly not renewed), or in the absence of such 1786 explicit local diagnostics, when the ACP node fails to connect to 1787 other ACP nodes in the same ACP domain using its ACP certificate. 1788 For connection failures to determine the ACP domain certificate as 1789 the culprit, the peer should pass the domain membership check 1790 (Section 6.1.3) and other reasons for the connection failure can be 1791 excluded because of the connection error diagnostics. 1793 This type of failure can happen during setup/refresh of a secure ACP 1794 channel connections or any other use of the ACP domain certificate, 1795 such as for the TLS connection to an EST server for the renewal of 1796 the ACP domain certificate. 1798 Example reasons for failing certificates that the ACP node can only 1799 discover through connection failure are that the domain certificate 1800 or any of its signing certificates could have been revoked or may 1801 have expired, but the ACP node cannot self-diagnose this condition 1802 directly. Revocation information or clock synchronization may only 1803 be available across the ACP, but the ACP node cannot build ACP secure 1804 channels because ACP peers reject the ACP node's domain certificate. 1806 ACP nodes SHOULD support the option to determines whether its ACP 1807 certificate is failing, and when it does, put itself into the role of 1808 a re-enrolling candidate ACP node as explained above 1809 (Section 6.1.5.5). 1811 6.2. ACP Adjacency Table 1813 To know to which nodes to establish an ACP channel, every ACP node 1814 maintains an adjacency table. The adjacency table contains 1815 information about adjacent ACP nodes, at a minimum: Node-ID 1816 (identifier of the node inside the ACP, see Section 6.10.3 and 1817 Section 6.10.5), interface on which neighbor was discovered (by GRASP 1818 as explained below), link-local IPv6 address of neighbor on that 1819 interface, certificate (including acp-node-name). An ACP node MUST 1820 maintain this adjacency table. This table is used to determine to 1821 which neighbor an ACP connection is established. 1823 Where the next ACP node is not directly adjacent (i.e., not on a link 1824 connected to this node), the information in the adjacency table can 1825 be supplemented by configuration. For example, the Node-ID and IP 1826 address could be configured. See Section 8.2. 1828 The adjacency table MAY contain information about the validity and 1829 trust of the adjacent ACP node's certificate. However, subsequent 1830 steps MUST always start with the ACP domain membership check against 1831 the peer (see Section 6.1.3). 1833 The adjacency table contains information about adjacent ACP nodes in 1834 general, independently of their domain and trust status. The next 1835 step determines to which of those ACP nodes an ACP connection should 1836 be established. 1838 6.3. Neighbor Discovery with DULL GRASP 1840 [RFC Editor: GRASP draft is in RFC editor queue, waiting for 1841 dependencies, including ACP. Please ensure that references to I- 1842 D.ietf-anima-grasp that include section number references (throughout 1843 this document) will be updated in case any last-minute changes in 1844 GRASP would make those section references change. 1846 Discovery Unsolicited Link-Local (DULL) GRASP is a limited subset of 1847 GRASP intended to operate across an insecure link-local scope. See 1848 section 2.5.2 of [I-D.ietf-anima-grasp] for its formal definition. 1849 The ACP uses one instance of DULL GRASP for every L2 interface of the 1850 ACP node to discover link level adjacent candidate ACP neighbors. 1851 Unless modified by policy as noted earlier (Section 5 bullet point 1852 2.), native interfaces (e.g., physical interfaces on physical nodes) 1853 SHOULD be initialized automatically to a state in which ACP discovery 1854 can be performed and any native interfaces with ACP neighbors can 1855 then be brought into the ACP even if the interface is otherwise not 1856 configured. Reception of packets on such otherwise not configured 1857 interfaces MUST be limited so that at first only IPv6 StateLess 1858 Address Auto Configuration (SLAAC - [RFC4862]) and DULL GRASP work 1859 and then only the following ACP secure channel setup packets - but 1860 not any other unnecessary traffic (e.g., no other link-local IPv6 1861 transport stack responders for example). 1863 Note that the use of the IPv6 link-local multicast address 1864 (ALL_GRASP_NEIGHBORS) implies the need to use Multicast Listener 1865 Discovery Version 2 (MLDv2, see [RFC3810]) to announce the desire to 1866 receive packets for that address. Otherwise DULL GRASP could fail to 1867 operate correctly in the presence of MLD snooping, non-ACP enabled L2 1868 switches ([RFC4541]) - because those would stop forwarding DULL GRASP 1869 packets. Switches not supporting MLD snooping simply need to operate 1870 as pure L2 bridges for IPv6 multicast packets for DULL GRASP to work. 1872 ACP discovery SHOULD NOT be enabled by default on non-native 1873 interfaces. In particular, ACP discovery MUST NOT run inside the ACP 1874 across ACP virtual interfaces. See Section 9.3 for further, non- 1875 normative suggestions on how to enable/disable ACP at node and 1876 interface level. See Section 8.2.2 for more details about tunnels 1877 (typical non-native interfaces). See Section 7 for how ACP should be 1878 extended on devices operating (also) as L2 bridges. 1880 Note: If an ACP node also implements BRSKI to enroll its ACP domain 1881 certificate (see Appendix A.2 for a summary), then the above 1882 considerations also apply to GRASP discovery for BRSKI. Each DULL 1883 instance of GRASP set up for ACP is then also used for the discovery 1884 of a bootstrap proxy via BRSKI when the node does not have a domain 1885 certificate. Discovery of ACP neighbors happens only when the node 1886 does have the certificate. The node therefore never needs to 1887 discover both a bootstrap proxy and ACP neighbor at the same time. 1889 An ACP node announces itself to potential ACP peers by use of the 1890 "AN_ACP" objective. This is a synchronization objective intended to 1891 be flooded on a single link using the GRASP Flood Synchronization 1892 (M_FLOOD) message. In accordance with the design of the Flood 1893 message, a locator consisting of a specific link-local IP address, IP 1894 protocol number and port number will be distributed with the flooded 1895 objective. An example of the message is informally: 1897 [M_FLOOD, 12340815, h'fe80000000000000c0011001feef0000', 210000, 1898 [["AN_ACP", 4, 1, "IKEv2" ], 1899 [O_IPv6_LOCATOR, 1900 h'fe80000000000000c0011001feef0000', IPPROTO_UDP, 15000]] 1901 [["AN_ACP", 4, 1, "DTLS" ], 1902 [O_IPv6_LOCATOR, 1903 h'fe80000000000000c0011001feef0000', IPPROTO_UDP, 17000]] 1904 ] 1906 Figure 5: GRASP AN_ACP example 1908 The formal CDDL definition is: 1910 flood-message = [M_FLOOD, session-id, initiator, ttl, 1911 +[objective, (locator-option / [])]] 1913 objective = ["AN_ACP", objective-flags, loop-count, 1914 objective-value] 1916 objective-flags = sync-only ; as in the GRASP specification 1917 sync-only = 4 ; M_FLOOD only requires synchronization 1918 loop-count = 1 ; limit to link-local operation 1919 objective-value = method 1920 method = "IKEv2" / "DTLS" ; or future standard methods 1922 Figure 6: GRASP AN_ACP definition 1924 The objective-flags field is set to indicate synchronization. 1926 The loop-count is fixed at 1 since this is a link-local operation. 1928 In the above example the RECOMMENDED period of sending of the 1929 objective is 60 seconds. The indicated ttl of 210000 msec means that 1930 the objective would be cached by ACP nodes even when two out of three 1931 messages are dropped in transit. 1933 The session-id is a random number used for loop prevention 1934 (distinguishing a message from a prior instance of the same message). 1935 In DULL this field is irrelevant but has to be set according to the 1936 GRASP specification. 1938 The originator MUST be the IPv6 link local address of the originating 1939 ACP node on the sending interface. 1941 The 'objective-value' parameter is a string indicating the protocol 1942 available at the specified or implied locator. It is a protocol 1943 supported by the node to negotiate a secure channel. IKEv2 as shown 1944 above is the protocol used to negotiate an IPsec secure channel. 1946 The locator-option is optional and only required when the secure 1947 channel protocol is not offered at a well-defined port number, or if 1948 there is no well-defined port number. 1950 IKEv2 is the actual protocol used to negotiate an Internet Protocol 1951 security architecture (IPsec) connection. GRASP therefore indicates 1952 "IKEv2" and not "IPsec". If "IPsec" was used, this too could mean 1953 use of the obsolete older version IKE (v1) ([RFC2409]). IKEv2 has am 1954 IANA assigned port number 500, but in the above example, the 1955 candidate ACP neighbor is offering ACP secure channel negotiation via 1956 IKEv2 on port 15000 (purely to show through the example that GRASP 1957 allows to indicate the port number and it does not have to be the 1958 IANA assigned one). 1960 "DTLS" indicates DTLS 1.2. This can also be a newer version of the 1961 protocol as long as it can negotiate down to version 1.2 in the 1962 presence of a peer only speaking DTLS 1.2. There is no default UDP 1963 port for DTLS, it is always locally assigned by the node. For 1964 details, see Section 6.7.4. 1966 If a locator is included, it MUST be an O_IPv6_LOCATOR, and the IPv6 1967 address MUST be the same as the initiator address (these are DULL 1968 requirements to minimize third party DoS attacks). 1970 The secure channel methods defined in this document use the 1971 objective-values of "IKEv2" and "DTLS". There is no distinction 1972 between IKEv2 native and GRE-IKEv2 because this is purely negotiated 1973 via IKEv2. 1975 A node that supports more than one secure channel protocol method 1976 needs to flood multiple versions of the "AN_ACP" objective so that 1977 each method can be accompanied by its own locator-option. This can 1978 use a single GRASP M_FLOOD message as shown in Figure 5. 1980 Note that a node serving both as an ACP node and BRSKI Join Proxy may 1981 choose to distribute the "AN_ACP" objective and the respective BRSKI 1982 in the same M_FLOOD message, since GRASP allows multiple objectives 1983 in one message. This may be impractical though if ACP and BRSKI 1984 operations are implemented via separate software modules / ASAs. 1986 The result of the discovery is the IPv6 link-local address of the 1987 neighbor as well as its supported secure channel protocols (and non- 1988 standard port they are running on). It is stored in the ACP 1989 Adjacency Table (see Section 6.2), which then drives the further 1990 building of the ACP to that neighbor. 1992 Note that the DULL GRASP objective described does intentionally not 1993 include ACP nodes ACP domain certificate even though this would be 1994 useful for diagnostics and to simplify the security exchange in ACP 1995 secure channel security association protocols (see Section 6.7). The 1996 reason is that DULL GRASP messages are periodically multicasted 1997 across IPv6 subnets and full certificates could easily lead to 1998 fragmented IPv6 DULL GRASP multicast packets due to the size of a 1999 certificate. This would be highly undesirable. 2001 6.4. Candidate ACP Neighbor Selection 2003 An ACP node determines to which other ACP nodes in the adjacency 2004 table it should attempt to build an ACP connection. This is based on 2005 the information in the ACP Adjacency table. 2007 The ACP is established exclusively between nodes in the same domain. 2008 This includes all routing subdomains. Appendix A.7 explains how ACP 2009 connections across multiple routing subdomains are special. 2011 The result of the candidate ACP neighbor selection process is a list 2012 of adjacent or configured autonomic neighbors to which an ACP channel 2013 should be established. The next step begins that channel 2014 establishment. 2016 6.5. Channel Selection 2018 To avoid attacks, initial discovery of candidate ACP peers cannot 2019 include any non-protected negotiation. To avoid re-inventing and 2020 validating security association mechanisms, the next step after 2021 discovering the address of a candidate neighbor can only be to try 2022 first to establish a security association with that neighbor using a 2023 well-known security association method. 2025 From the use-cases it seems clear that not all type of ACP nodes can 2026 or need to connect directly to each other or are able to support or 2027 prefer all possible mechanisms. For example, code space limited IoT 2028 devices may only support DTLS because that code exists already on 2029 them for end-to-end security, but low-end in-ceiling L2 switches may 2030 only want to support Media Access Control Security (MacSec, see 2031 802.1AE ([MACSEC]) because that is also supported in their chips. 2032 Only a flexible gateway device may need to support both of these 2033 mechanisms and potentially more. Note that MacSec is not required by 2034 any profiles of the ACP in this specification but just mentioned as a 2035 likely next interesting secure channel protocol. Note also that the 2036 security model allows and requires for any-to-any authentication and 2037 authorization between all ACP nodes because there is also end-to-end 2038 and not only hop-by-hop authentication for secure channels. 2040 To support extensible secure channel protocol selection without a 2041 single common mandatory to implement (MTI) protocol, ACP nodes MUST 2042 try all the ACP secure channel protocols it supports and that are 2043 feasible because the candidate ACP neighbor also announced them via 2044 its AN_ACP GRASP parameters (these are called the "feasible" ACP 2045 secure channel protocols). 2047 To ensure that the selection of the secure channel protocols always 2048 succeeds in a predictable fashion without blocking, the following 2049 rules apply: 2051 o An ACP node may choose to attempt to initiate the different 2052 feasible ACP secure channel protocols it supports according to its 2053 local policies sequentially or in parallel, but it MUST support 2054 acting as a responder to all of them in parallel. 2056 o Once the first secure channel protocol succeeds, the two peers 2057 know each other's certificates because they are used by all secure 2058 channel protocols for mutual authentication. The node with the 2059 lower Node-ID in the ACP address of its ACP domain certificate 2060 becomes Bob, the one with the higher Node-ID in the certificate 2061 Alice. A peer with an empty ACP address field in its ACP domain 2062 certificate becomes Bob (this specification does not define such 2063 peers, only the interoperability with them). 2065 o Bob becomes passive, he does not attempt to further initiate ACP 2066 secure channel protocols with Alice and does not consider it to be 2067 an error when Alice closes secure channels. Alice becomes the 2068 active party, continues to attempt setting up secure channel 2069 protocols with Bob until she arrives at the best one from her view 2070 that also works with Bob. 2072 For example, originally Bob could have been the initiator of one ACP 2073 secure channel protocol that Bob prefers and the security association 2074 succeeded. The roles of Bob and Alice are then assigned and the 2075 connection setup is completed. The protocol could for example be 2076 IPsec via IKEv2 ("IP security", see [RFC4301] and "Internet Key 2077 Exchange protocol version 2", see [RFC7296]. It is now up to Alice 2078 to decide how to proceed. Even if the IPsec connection from Bob 2079 succeeded, Alice might prefer another secure protocol over IPsec 2080 (e.g., FOOBAR), and try to set that up with Bob. If that preference 2081 of Alice succeeds, she would close the IPsec connection. If no 2082 better protocol attempt succeeds, she would keep the IPsec 2083 connection. 2085 The following sequence of steps show this example in more detail. 2086 Each step is tagged with [{:}]. The connection is 2087 included to easier distinguish which of the two competing connections 2088 the step belong to, one initiated by Node 1, one initiated by Node 2. 2090 [1] Node 1 sends GRASP AN_ACP message to announce itself 2092 [2] Node 2 sends GRASP AN_ACP message to announce itself 2094 [3] Node 2 receives [1] from Node 1 2096 [4:C1] Because of [3], Node 2 starts as initiator on its 2097 preferred secure channel protocol towards Node 1. 2098 Connection C1. 2100 [5] Node 1 receives [2] from Node 2 2102 [6:C2] Because of [5], Node 1 starts as initiator on its 2103 preferred secure channel protocol towards Node 2. 2104 Connection C2. 2106 [7:C1] Node1 and Node2 have authenticated each others 2107 certificate on connection C1 as valid ACP peers. 2109 [8:C1] Node 1 certificate has lower ACP Node-ID than Node2, 2110 therefore Node 1 considers itself Bob and Node 2 Alice 2111 on connection C1. Connection setup C1 is completed. 2113 [9] Node 1 (Bob)) refrains from attempting any further secure 2114 channel connections to Node 2 (Alice) as learned from [2] 2115 because it knows from [8:C1] that it is Bob relative 2116 to Node 1. 2118 [10:C2] Node1 and Node2 have authenticated each others 2119 certificate on connection C2 (like [7:C1]). 2121 [11:C2] Node 1 certificate has lower ACP Node-ID than Node2, 2122 therefore Node 1 considers itself Bob and Node 2 Alice 2123 on connection C2, but they also identify that C2 is to the 2124 same mutual peer as their C1, so this has no further impact: 2125 the roles Alice and Bob where already assigned between these 2126 two peers by [8:C1]. 2128 [12:C2] Node 2 (Alice) closes C1. Node 1 (Bob) is fine with this, 2129 because of his role as Bob (since [8:C1]). 2131 [13] Node 2 (Alice) and Node 1 (Bob) start data transfer across 2132 C2, which makes it become a secure channel for the ACP. 2134 Figure 7: Secure Channel sequence of steps 2136 All this negotiation is in the context of an "L2 interface". Alice 2137 and Bob will build ACP connections to each other on every "L2 2138 interface" that they both connect to. An autonomic node MUST NOT 2139 assume that neighbors with the same L2 or link-local IPv6 addresses 2140 on different L2 interfaces are the same node. This can only be 2141 determined after examining the certificate after a successful 2142 security association attempt. 2144 6.6. Candidate ACP Neighbor verification 2146 Independent of the security association protocol chosen, candidate 2147 ACP neighbors need to be authenticated based on their domain 2148 certificate. This implies that any secure channel protocol MUST 2149 support certificate based authentication that can support the ACP 2150 domain membership check as defined in Section 6.1.3. If it fails, 2151 the connection attempt is aborted and an error logged. Attempts to 2152 reconnect MUST be throttled. The RECOMMENDED default is exponential 2153 base 2 backoff with a minimum delay of 10 seconds and a maximum delay 2154 of 640 seconds. 2156 Failure to authenticate an ACP neighbor when acting in the role of a 2157 responder of the security authentication protocol MUST NOT impact the 2158 attempts of the ACP node to attempt establishing a connection as an 2159 initiator. Only failed connection attempts as an initiator must 2160 cause throttling. This rule is meant to increase resilience of 2161 secure channel creation. Section 6.5 shows how simultaneous mutual 2162 secure channel setup collisions are resolved. 2164 6.7. Security Association (Secure Channel) protocols 2166 This section describes how ACP nodes establish secured data 2167 connections to automatically discovered or configured peers in the 2168 ACP. Section 6.3 above described how IPv6 subnet adjacent peers are 2169 discovered automatically. Section 8.2 describes how non IPv6 subnet 2170 adjacent peers can be configured. 2172 Section 6.12.5.2 describes how secure channels are mapped to virtual 2173 IPv6 subnet interfaces in the ACP. The simple case is to map every 2174 ACP secure channel into a separate ACP point-to-point virtual 2175 interface Section 6.12.5.2.1. When a single subnet has multiple ACP 2176 peers this results in multiple ACP point-to-point virtual interfaces 2177 across that underlying multi-party IPv6 subnet. This can be 2178 optimized with ACP multi-access virtual interfaces Section 6.12.5.2.2 2179 but the benefits of that optimization may not justify the complexity 2180 of that option. 2182 6.7.1. General considerations 2184 Due to Channel Selection (Section 6.5), ACP can support an evolving 2185 set of security association protocols and does not require support 2186 for a single network wide MTI. ACP nodes only need to implement 2187 those protocols required to interoperate with their candidate peers, 2188 not with potentially any node in the ACP domain. See Section 6.7.5 2189 for an example of this. 2191 The degree of security required on every hop of an ACP network needs 2192 to be consistent across the network so that there is no designated 2193 "weakest link" because it is that "weakest link" that would otherwise 2194 become the designated point of attack. When the secure channel 2195 protection on one link is compromised, it can be used to send/receive 2196 packets across the whole ACP network. Therefore, even though the 2197 security association protocols can be different, their minimum degree 2198 of security should be comparable. 2200 Secure channel protocols do not need to always support arbitrary L3 2201 connectivity between peers, but can leverage the fact that the 2202 standard use case for ACP secure channels is an L2 adjacency. Hence, 2203 L2 dependent mechanisms could be adopted for use as secure channel 2204 association protocols: 2206 L2 mechanisms such as strong encrypted radio technologies or [MACSEC] 2207 may offer equivalent encryption and the ACP security association 2208 protocol may only be required to authenticate ACP domain membership 2209 of a peer and/or derive a key for the L2 mechanism. Mechanisms to 2210 auto-discover and associate ACP peers leveraging such underlying L2 2211 security are possible and desirable to avoid duplication of 2212 encryption, but none are specified in this document. 2214 Strong physical security of a link may stand in where cryptographic 2215 security is infeasible. As there is no secure mechanism to 2216 automatically discover strong physical security solely between two 2217 peers, it can only be used with explicit configuration and that 2218 configuration too could become an attack vector. This document 2219 therefore only specifies with ACP connect (Figure 15) one explicitly 2220 configured mechanism without any secure channel association protocol 2221 - for the case where both the link and the nodes attached to it have 2222 strong physical security. 2224 6.7.2. Common requirements 2226 The authentication of peers in any security association protocol MUST 2227 use the ACP domain certificate according to Section 6.1.3. Because 2228 auto-discovery of candidate ACP neighbors via GRASP (see Section 6.3) 2229 as specified in this document does not communicate the neighbors ACP 2230 domain certificate, and ACP nodes may not (yet) have any other 2231 network connectivity to retrieve certificates, any security 2232 association protocol MUST use a mechanism to communicate the 2233 certificate directly instead of relying on a referential mechanism 2234 such as communicating only a hash and/or URL for the certificate. 2236 A security association protocol MUST use Forward Secrecy (whether 2237 inherently or as part of a profile of the security association 2238 protocol). 2240 Because the ACP payload of legacy protocol payloads inside the ACP 2241 and hop-by-hop ACP flooded GRASP information is unencrypted, the ACP 2242 secure channel protocol requires confidentiality. Symmetric 2243 encryption for the transmission of secure channel data MUST use 2244 encryption schemes considered to be security wise equal to or better 2245 than AES256. There MUST NOT be support for NULL encryption. 2247 Security association protocols typically only signal the End Entity 2248 certificate (e.g.: the ACP domain certificate) and any possible 2249 intermediate CA certificates for successfull mutual authentication. 2250 The TA has to be mutually known and trusted and therefore its 2251 certificate does not need to be signalled for successful mutual 2252 authentication. Nevertheless, for use with ACP secure channel setup, 2253 there SHOULD be the option to include the TA certificate in the 2254 signaling to aid troubleshooting, see Section 9.1.1. 2256 Signalling of TA certificates may not be appropriate when the 2257 deployment is relying on a security model where the TA certificate 2258 content is considered confidential and only its hash is appropriate 2259 for signalling. ACP nodes SHOULD have a mechanism to select whether 2260 the TA certificate is signalled or not. Assuming that both options 2261 are possible with a specific secure channel protocol. 2263 An ACP secure channel MUST immediately be terminated when the 2264 lifetime of any certificate in the chain used to authenticate the 2265 neighbor expires or becomes revoked. This may not be standard 2266 behavior in secure channel protocols because the certificate 2267 authentication may only influences the setup of the secure channel in 2268 these protocols, but may not be re-validated during the lifetime of 2269 the secure connection in the absence of this requirement. 2271 When introducing the profile for a security association protocol in 2272 support of the ACP, protocol options SHOULD be eliminated that do not 2273 provide benefits for devices that should be able to support the ACP. 2274 For example, definitions for security protocols often include old/ 2275 inferior security options required only to interoperate with existing 2276 devices that will not be a able to update to the currently preferred 2277 security options. Such old/inferior security options do not need to 2278 be supported when a security association protocol is first specified 2279 for the ACP, strengthening the "weakest link" and simplifying ACP 2280 implementation overhead. 2282 6.7.3. ACP via IPsec 2284 An ACP node announces its ability to support IPsec, negotiated via 2285 IKEv2, as the ACP secure channel protocol using the "IKEv2" 2286 objective-value in the "AN_ACP" GRASP objective. 2288 The ACP usage of IPsec and IKEv2 mandates a profile with a narrow set 2289 of options of the current standards-track usage guidance for IPsec 2290 [RFC8221] and IKEv2 [RFC8247]. These option result in stringent 2291 security properties and can exclude deprecated/legacy algorithms 2292 because there is no need for interoperability with legacy equipment 2293 for ACP secure channels. Any such backward compatibility would lead 2294 only to increased attack surface and implementation complexity, for 2295 no benefit. 2297 6.7.3.1. Native IPsec 2299 An ACP node that is supporting native IPsec MUST use IPsec in tunnel 2300 mode, negotiated via IKEv2, and with IPv6 payload (e.g., ESP Next 2301 Header of 41). It MUST use local and peer link-local IPv6 addresses 2302 for encapsulation. Manual keying MUST NOT be used, see Section 6.1. 2303 Traffic Selectors are: 2305 TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 2307 TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 2309 IPsec tunnel mode is required because the ACP will route/forward 2310 packets received from any other ACP node across the ACP secure 2311 channels, and not only its own generated ACP packets. With IPsec 2312 transport mode (and no additional encapsulation header in the ESP 2313 payload), it would only be possible to send packets originated by the 2314 ACP node itself because the IPv6 addresses of the ESP must be the 2315 same as that of the outer IPv6 header. 2317 6.7.3.1.1. RFC8221 (IPsec/ESP) 2319 ACP IPsec implementations MUST comply with [RFC8221] (and its 2320 updates). The requirements from above and this section amend and 2321 superceed its requirements. 2323 AH MUST NOT be used (because it does not provide confidentiality). 2325 For the required ESP encryption algorithms in section 5 of [RFC8221] 2326 the following guidance applies: 2328 o ENCR_NULL AH MUST NOT be used (because it does not provide 2329 confidentiality). 2331 o ENCR_AES_GCM_16 is the only MTI ESP encryption algorithm for ACP 2332 via IPsec/ESP (it is already listed as MUST in [RFC8221]). 2334 o ENCR_AES_CBC and ENCR_AES_CCM_8 MAY be supported. If either 2335 provides higher performance than ENCR_AES_GCM_16 it SHOULD be 2336 supported. 2338 o ENCR_CHACHA20_POLY1305 SHOULD be supported at equal or higher 2339 performance than ENCR_AES_GCM_16. If that performance is not 2340 feasible, it MAY be supported. 2342 IKEv2 indicates an order for the offered algorithms. The algorithms 2343 SHOULD be ordered by performance. The first algorithm supported by 2344 both sides is generally choosen. 2346 Explanations: 2348 o There is no requirement to interoperate with legacy equipment in 2349 ACP secure channels, so a single MTI encryption algorithm for 2350 IPsec in ACP secure channels is sufficient for interoperability 2351 and allows for the most lightweight implementations. 2353 o ENCR_AES_GCM_16 is an authenticated encryption with associated 2354 data (AEAD) cipher mode, so no additional ESP authentication 2355 algorithm is needed, simplifying the MTI requirements of IPsec for 2356 the ACP. 2358 o There is no MTI requirement against support of ENCR_AES_CBC 2359 because ENCR_AES_GCM_16 is assumed to be feasible with less cost/ 2360 higher performance in modern devices hardware accelerated 2361 implementations compared to ENCR-AES_CBC. 2363 o ENCR_CHACHA20_POLY1305 is mandatory in [RFC8221] because of its 2364 target use as a fallback algorithm in case weaknesses in AES are 2365 uncoverered. Unfortunately, there is currently no way to 2366 automatically propagate across an ACP a policy to disallow use of 2367 AES based algorithms, so this target benefit of 2368 ENCR_CHACHA20_POLY1305 can not fully be adopted yet for the ACP. 2369 Therefore this algorithm is only recommended. Changing from AES 2370 to this algorithm at potentially big drop in performance could 2371 also render the ACP inoperable. Therefore the performance 2372 requirement against this algorithm so that it could become an 2373 effective security backup to AES for the ACP once a policy to 2374 switch over to it or prefer it is available in an ACP framework. 2376 [RFC8221] allows for 128-bit or 256-bit AES keys. This document 2377 mandates that only 256-bit AES keys MUST be supported. 2379 When [RFC8221] is updated, ACP implementations will need to consider 2380 legacy interoperability, and the IPsec WG has generally done a very 2381 good job of taking that into account in its recommendations. 2383 6.7.3.1.2. RFC8247 (IKEv2) 2385 [RFC8247] provides a baseline recommendation for mandatory to 2386 implement ciphers, integrity checks, pseudo-random-functions and 2387 Diffie-Hellman mechanisms. Those recommendations, and the 2388 recommendations of subsequent documents apply well to the ACP. 2389 Because IKEv2 for ACP secure channels is sufficient to be implemented 2390 in control plane software, rather than in ASIC hardware, and ACP 2391 nodes supporting IKEv2 are not assumed to be code-space constrained, 2392 and because existing IKEv2 implementations are expected to support 2393 [RFC8247] recommendations, this documents makes no attempt to 2394 simplify its recommendations for use with the ACP. 2396 This document does establish a policy statement as permitted by 2397 [RFC8247] for the specific case of ACP traffic. 2399 See [IKEV2IANA] for IANA IKEv2 parameter names used in this text. 2401 To signal the ACP domain certificate chain (including TA) as required 2402 by Section 6.7.2, "X.509 Certificate - Signature" payload in IKEv2 2403 can be used. It is mandatory according to [RFC7296] section 3.6. 2405 ACP nodes SHOULD set up IKEv2 to only use the ACP certificate and TA 2406 when acting as an IKEv2 responder on the IPv6 link local address and 2407 port number indicated in the AN_ACP DULL GRASP announcements (see 2408 Section 6.3). 2410 When CERTREQ is received from a peer, and does not indicate any of 2411 this ACP nodes TA certificates, the ACP node SHOULD ignore the 2412 CERTREQ and continue sending its certificate chain including its TA 2413 as subject to the requirements and explanations in Section 6.7.2. 2414 This will not result in successfull mutual authentication but assists 2415 diagnostics. 2417 Note that with IKEv2, failing authentication will only result in the 2418 responder receiving the certificate chain from the initiator, but not 2419 vice versa. Because ACP secure channel setup is symmetric (see 2420 Section 6.6), every non-malicious ACP neighbor will attempt to 2421 connect as an initiator though, allowing to obtain the diagnostic 2422 information about the neighbors certificate. 2424 In IKEv2, ACP nodes are identified by their ACP address. The 2425 ID_IPv6_ADDR IKEv2 identification payload MUST be used and MUST 2426 convey the ACP address. If the peer's ACP domain certificate 2427 includes an ACP address in the acp-node-name (not "0" or empty), the 2428 address in the IKEv2 identification payload MUST match it. See 2429 Section 6.1.3 for more information about "0" or empty ACP address 2430 fields in the acp-node-name. 2432 IKEv2 authentication MUST use authentication method 14 ("Digital 2433 Signature") for ACP certificates; this authentication method can be 2434 used with both RSA and ECDSA certificates, indicated by an ASN.1 2435 object AlgorithmIdentifier. 2437 The Digital Signature hash SHA2-512 MUST be supported (in addition to 2438 SHA2-256). 2440 The IKEv2 Diffie-Hellman key exchange group 19 (256-bit random ECP), 2441 listed as a SHOULD, is to be configured, along with the 2048-bit MODP 2442 (group 14). ECC provides a similar security level to finite-field 2443 (MODP) key exchange with a shorter key length, so is generally 2444 preferred absent other considerations. 2446 6.7.3.2. IPsec with GRE encapsulation 2448 In network devices it is often more common to implement high 2449 performance virtual interfaces on top of GRE encapsulation than on 2450 top of a "native" IPsec association (without any other encapsulation 2451 than those defined by IPsec). On those devices it may be beneficial 2452 to run the ACP secure channel on top of GRE protected by the IPsec 2453 association. 2455 The requirements for ESP/IPsec/IKEv2 with GRE are the same as for 2456 native IPsec (see Section 6.7.3.1) except that IPsec transport mode 2457 and next protocol GRE (47) are to be negotiated. Tunnel mode is not 2458 required because of GRE. Traffic Selectors are: 2460 TSi = (47, 0-65535, Initiator-IPv6-LL-addr ... Initiator-ACP-LL-addr) 2462 TSr = (47, 0-65535, Responder-IPv6-LL-addr ... Responder-IPv6-LL- 2463 addr) 2465 If IKEv2 initiator and responder support IPsec over GRE, it has to be 2466 preferred over native IPsec. The ACP IPv6 traffic has to be carried 2467 across GRE according to [RFC7676]. 2469 6.7.4. ACP via DTLS 2471 We define the use of ACP via DTLS in the assumption that it is likely 2472 the first transport encryption supported in some classes of 2473 constrained devices because DTLS is already used in those devices but 2474 IPsec is not, and code-space may be limited. 2476 An ACP node announces its ability to support DTLS v1.2 compliant with 2477 the requirements defined in this document as an ACP secure channel 2478 protocol in GRASP through the "DTLS" objective-value in the "AN_ACP" 2479 objective. 2481 To run ACP via UDP and DTLS v1.2 [RFC6347], a locally assigned UDP 2482 port is used that is announced as a parameter in the GRASP AN_ACP 2483 objective to candidate neighbors. This port can also be any newer 2484 version of DTLS as long as that version can negotiate a DTLS v1.2 2485 connection in the presence of an DTLS v1.2 only peer. 2487 All ACP nodes supporting DTLS as a secure channel protocol MUST 2488 adhere to the DTLS implementation recommendations and security 2489 considerations of BCP 195 [RFC7525] except with respect to the DTLS 2490 version. ACP nodes supporting DTLS MUST support DTLS 1.2. They MUST 2491 NOT support older versions of DTLS. Implementation MUST comply with 2492 BCP 195, [RFC7525]. 2494 Unlike for IPsec, no attempts are made to simplify the requirements 2495 of the BCP 195 recommendations because the expectation is that DTLS 2496 would be using software-only implementations where the ability to 2497 reuse of widely adopted implementations is more important than 2498 minizing the complexity of a hardware accelerated implementation 2499 which is known to be important for IPsec. 2501 DTLS v1.3 ([I-D.ietf-tls-dtls13]) is "backward compatible" with DTLS 2502 v1.2 (see section 1. of DTLS v1.3): A DTLS implementation supporting 2503 both DTLS v1.2 and DTLS v1.3 does comply with the above requirements 2504 of negoting to DTLS v1.2 in the presence of a DTLS v1.2 only peer, 2505 but using DTLS v1.3 when booth peers support it. 2507 Version v1.2 is the MTI version of DTLS in this specification because 2509 o There is more experience with DTLS v1.2 across the spectrum of 2510 target ACP nodes. 2512 o Firmware of lower end, embedded ACP nodes may not support a newer 2513 version for a long time. 2515 o There are significant changes of DTLS v1.3, such as a different 2516 record layer requiring time to gain implementation and deployment 2517 experience especially on lower end, code space limited devices. 2519 o The existing BCP [RFC7525] for DTLS v1.2 may equally take longer 2520 time to be updated with experience from a newer DTLS version. 2522 o There are no significant use-case relevant benefits of DTLS v1.3 2523 over DTLS v1.2 in the context of the ACP options for DTLS. For 2524 example, signaling performance improvements for session setup in 2525 DTLS v1.3 is not important for the ACP given the long-lived nature 2526 of ACP secure channel connections and the fact that DTLS 2527 connections are mostly link-local (short RTT). 2529 Nevertheless, newer versions of DTLS, such as DTLS v1.3 have more 2530 strict security requirements and use of the latest standard protocol 2531 version is for IETF security standards in general recommended. 2532 Therefore, ACP implementations are advised to support all the newer 2533 versions of DTLS that can still negotiate down to DTLS v1.2. 2535 [RFC-editor: if by the time of AUTH48, DTLS 1.3 would have evolved to 2536 be an RFC, then not only would the references to the DTLS v1.3 draft 2537 be changed to the RFC number, but that RFC is then going to be put 2538 into the normative list of references and the above paragraph is 2539 going to be amended to say: Implementations SHOULD support 2540 [DTLSv1.3-RFC]. This is not done right now, because there is no 2541 benefit in potentially waiting in RFC-editor queue for that RFC given 2542 how the text alreayd lays out a non-nrmative desire to support 2543 DTLSv1.3.] 2545 There is no additional session setup or other security association 2546 besides this simple DTLS setup. As soon as the DTLS session is 2547 functional, the ACP peers will exchange ACP IPv6 packets as the 2548 payload of the DTLS transport connection. Any DTLS defined security 2549 association mechanisms such as re-keying are used as they would be 2550 for any transport application relying solely on DTLS. 2552 6.7.5. ACP Secure Channel Profiles 2554 As explained in the beginning of Section 6.5, there is no single 2555 secure channel mechanism mandated for all ACP nodes. Instead, this 2556 section defines two ACP profiles (baseline and constrained) for ACP 2557 nodes that do introduce such requirements. 2559 A baseline ACP node MUST support IPsec natively and MAY support IPsec 2560 via GRE. If GRE is supported, it MAY be preferred over native IPec. 2561 A constrained ACP node that cannot support IPsec MUST support DTLS. 2562 An ACP node connecting an area of constrained ACP nodes with an area 2563 of baseline ACP nodes needs to support IPsec and DTLS and supports 2564 therefore the baseline and constrained profile. 2566 Explanation: Not all type of ACP nodes can or need to connect 2567 directly to each other or are able to support or prefer all possible 2568 secure channel mechanisms. For example, code space limited IoT 2569 devices may only support DTLS because that code exists already on 2570 them for end-to-end security, but high-end core routers may not want 2571 to support DTLS because they can perform IPsec in accelerated 2572 hardware but would need to support DTLS in an underpowered CPU 2573 forwarding path shared with critical control plane operations. This 2574 is not a deployment issue for a single ACP across these type of nodes 2575 as long as there are also appropriate gateway ACP nodes that support 2576 sufficiently many secure channel mechanisms to allow interconnecting 2577 areas of ACP nodes with a more constrained set of secure channel 2578 protocols. On the edge between IoT areas and high-end core networks, 2579 general-purpose routers that act as those gateways and that can 2580 support a variety of secure channel protocols is the norm already. 2582 IPsec natively with tunnel mode provides the shortest encapsulation 2583 overhead. GRE may be preferred by legacy implementations because the 2584 virtual interfaces required by ACP design in conjunction with secure 2585 channels have in the past more often been implemented for GRE than 2586 purely for native IPsec. 2588 ACP nodes need to specify in documentation the set of secure ACP 2589 mechanisms they support and should declare which profile they support 2590 according to above requirements. 2592 6.8. GRASP in the ACP 2594 6.8.1. GRASP as a core service of the ACP 2596 The ACP MUST run an instance of GRASP inside of it. It is a key part 2597 of the ACP services. The function in GRASP that makes it fundamental 2598 as a service of the ACP is the ability to provide ACP wide service 2599 discovery (using objectives in GRASP). 2601 ACP provides IP unicast routing via the RPL routing protocol (see 2602 Section 6.11). 2604 The ACP does not use IP multicast routing nor does it provide generic 2605 IP multicast services (the handling of GRASP link-local multicast 2606 messages is explained in Section 6.8.2). Instead, the ACP provides 2607 service discovery via the objective discovery/announcement and 2608 negotiation mechanisms of the ACP GRASP instance (services are a form 2609 of objectives). These mechanisms use hop-by-hop reliable flooding of 2610 GRASP messages for both service discovery (GRASP M_DISCOVERY 2611 messages) and service announcement (GRASP M_FLOOD messages). 2613 See Appendix A.5 for discussion about this design choice of the ACP. 2615 6.8.2. ACP as the Security and Transport substrate for GRASP 2617 In the terminology of GRASP ([I-D.ietf-anima-grasp]), the ACP is the 2618 security and transport substrate for the GRASP instance run inside 2619 the ACP ("ACP GRASP"). 2621 This means that the ACP is responsible for ensuring that this 2622 instance of GRASP is only sending messages across the ACP GRASP 2623 virtual interfaces. Whenever the ACP adds or deletes such an 2624 interface because of new ACP secure channels or loss thereof, the ACP 2625 needs to indicate this to the ACP instance of GRASP. The ACP exists 2626 also in the absence of any active ACP neighbors. It is created when 2627 the node has a domain certificate, and continues to exist even if all 2628 of its neighbors cease operation. 2630 In this case ASAs using GRASP running on the same node would still 2631 need to be able to discover each other's objectives. When the ACP 2632 does not exist, ASAs leveraging the ACP instance of GRASP via APIs 2633 MUST still be able to operate, and MUST be able to understand that 2634 there is no ACP and that therefore the ACP instance of GRASP cannot 2635 operate. 2637 The following explanation how ACP acts as the security and transport 2638 substrate for GRASP is visualized in Figure 8 below. 2640 GRASP unicast messages inside the ACP always use the ACP address. 2641 Link-local addresses from the ACP VRF MUST NOT be used inside 2642 objectives. GRASP unicast messages inside the ACP are transported 2643 via TLS which MUST comply with [RFC7525] execept that only TLS 1.2 2644 ([RFC5246]) is REQUIRED and TLS 1.3 ([RFC8446] is RECOMMENDED. There 2645 is no need for older version backward compatibility in the new use- 2646 case of ACP. Mutual authentication MUST use the ACP domain 2647 membership check defined in (Section 6.1.3). 2649 GRASP link-local multicast messages are targeted for a specific ACP 2650 virtual interface (as defined Section 6.12.5) but are sent by the ACP 2651 into an ACP GRASP virtual interface that is constructed from the TCP 2652 connection(s) to the IPv6 link-local neighbor address(es) on the 2653 underlying ACP virtual interface. If the ACP GRASP virtual interface 2654 has two or more neighbors, the GRASP link-local multicast messages 2655 are replicated to all neighbor TCP connections. 2657 TLS for GRASP MUST offer TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and 2658 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 and MUST NOT offer options 2659 with less than 256bit AES or less than SHA384. TLS for GRASP MUST 2660 also include the "Supported Elliptic Curves" extension, it MUST 2661 support support the NIST P-256 (secp256r1) and P-384 (secp384r1(24)) 2662 curves [RFC4492]. In addition, GRASP TLS clients SHOULD send an 2663 ec_point_formats extension with a single element, "uncompressed". 2664 For further interoperability recommendations, GRASP TLS 2665 implementations SHOULD follow [RFC7525]. 2667 TCP and TLS connections for GRASP in the ACP use the IANA assigned 2668 TCP port for GRASP (7107). Effectively the transport stack is 2669 expected to be TLS for connections from/to the ACP address (e.g., 2670 global scope address(es)) and TCP for connections from/to link-local 2671 addresses on the ACP virtual interfaces. The latter ones are only 2672 used for flooding of GRASP messages. 2674 ..............................ACP.............................. 2675 . . 2676 . /-GRASP-flooding-\ ACP GRASP instance . 2677 . / \ A 2678 . GRASP GRASP GRASP C 2679 . link-local unicast link-local P 2680 . multicast messages multicast . 2681 . messages | messages . 2682 . | | | . 2683 ............................................................... 2684 . v v v ACP security and transport . 2685 . | | | substrate for GRASP . 2686 . | | | . 2687 . | ACP GRASP | - ACP GRASP A 2688 . | Loopback | Loopback interface C 2689 . | interface | - ACP-cert auth P 2690 . | TLS | . 2691 . ACP GRASP | ACP GRASP - ACP GRASP virtual . 2692 . subnet1 | subnet2 virtual interfaces . 2693 . TCP | TCP . 2694 . | | | . 2695 ............................................................... 2696 . | | | ^^^ Users of ACP (GRASP/ASA) . 2697 . | | | ACP interfaces/addressing . 2698 . | | | . 2699 . | | | A 2700 . | ACP-Loopback Interf.| <- ACP Loopback interface C 2701 . | ACP-address | - address (global ULA) P 2702 . subnet1 | subnet2 <- ACP virtual interfaces . 2703 . link-local | link-local - link-local addresses . 2704 ............................................................... 2705 . | | | ACP VRF . 2706 . | RPL-routing | virtual routing and forwarding . 2707 . | /IP-Forwarding\ | A 2708 . | / \ | C 2709 . ACP IPv6 packets ACP IPv6 packets P 2710 . |/ \| . 2711 . IPsec/DTLS IPsec/DTLS - ACP-cert auth . 2712 ............................................................... 2713 | | Data-Plane 2714 | | 2715 | | - ACP secure channel 2716 link-local link-local - encapsulation addresses 2717 subnet1 subnet2 - Data-Plane interfaces 2718 | | 2719 ACP-Nbr1 ACP-Nbr2 2721 Figure 8: ACP as security and transport substrate for GRASP 2723 6.8.2.1. Discussion 2725 TCP encapsulation for GRASP M_DISCOVERY and M_FLOOD link local 2726 messages is used because these messages are flooded across 2727 potentially many hops to all ACP nodes and a single link with even 2728 temporary packet loss issues (e.g., WiFi/Powerline link) can reduce 2729 the probability for loss free transmission so much that applications 2730 would want to increase the frequency with which they send these 2731 messages. Such shorter periodic retransmission of datagrams would 2732 result in more traffic and processing overhead in the ACP than the 2733 hop-by-hop reliable retransmission mechanism by TCP and duplicate 2734 elimination by GRASP. 2736 TLS is mandated for GRASP non-link-local unicast because the ACP 2737 secure channel mandatory authentication and encryption protects only 2738 against attacks from the outside but not against attacks from the 2739 inside: Compromised ACP members that have (not yet) been detected and 2740 removed (e.g., via domain certificate revocation / expiry). 2742 If GRASP peer connections were to use just TCP, compromised ACP 2743 members could simply eavesdrop passively on GRASP peer connections 2744 for whom they are on-path ("Man In The Middle" - MITM) or intercept 2745 and modify them. With TLS, it is not possible to completely 2746 eliminate problems with compromised ACP members, but attacks are a 2747 lot more complex: 2749 Eavesdropping/spoofing by a compromised ACP node is still possible 2750 because in the model of the ACP and GRASP, the provider and consumer 2751 of an objective have initially no unique information (such as an 2752 identity) about the other side which would allow them to distinguish 2753 a benevolent from a compromised peer. The compromised ACP node would 2754 simply announce the objective as well, potentially filter the 2755 original objective in GRASP when it is a MITM and act as an 2756 application level proxy. This of course requires that the 2757 compromised ACP node understand the semantics of the GRASP 2758 negotiation to an extent that allows it to proxy it without being 2759 detected, but in an ACP environment this is quite likely public 2760 knowledge or even standardized. 2762 The GRASP TLS connections are run the same as any other ACP traffic 2763 through the ACP secure channels. This leads to double 2764 authentication/encryption, which has the following benefits: 2766 o Secure channel methods such as IPsec may provide protection 2767 against additional attacks, for example reset-attacks. 2769 o The secure channel method may leverage hardware acceleration and 2770 there may be little or no gain in eliminating it. 2772 o There is no different security model for ACP GRASP from other ACP 2773 traffic. Instead, there is just another layer of protection 2774 against certain attacks from the inside which is important due to 2775 the role of GRASP in the ACP. 2777 6.9. Context Separation 2779 The ACP is in a separate context from the normal Data-Plane of the 2780 node. This context includes the ACP channels' IPv6 forwarding and 2781 routing as well as any required higher layer ACP functions. 2783 In classical network system, a dedicated VRF is one logical 2784 implementation option for the ACP. If possible by the systems 2785 software architecture, separation options that minimize shared 2786 components are preferred, such as a logical container or virtual 2787 machine instance. The context for the ACP needs to be established 2788 automatically during bootstrap of a node. As much as possible it 2789 should be protected from being modified unintentionally by ("Data- 2790 Plane") configuration. 2792 Context separation improves security, because the ACP is not 2793 reachable from the Data-Plane routing or forwarding table(s). Also, 2794 configuration errors from the Data-Plane setup do not affect the ACP. 2796 6.10. Addressing inside the ACP 2798 The channels explained above typically only establish communication 2799 between two adjacent nodes. In order for communication to happen 2800 across multiple hops, the autonomic control plane requires ACP 2801 network wide valid addresses and routing. Each ACP node creates a 2802 Loopback interface with an ACP network wide unique address (prefix) 2803 inside the ACP context (as explained in in Section 6.9). This 2804 address may be used also in other virtual contexts. 2806 With the algorithm introduced here, all ACP nodes in the same routing 2807 subdomain have the same /48 ULA prefix. Conversely, ULA global IDs 2808 from different domains are unlikely to clash, such that two ACP 2809 networks can be merged, as long as the policy allows that merge. See 2810 also Section 10.1 for a discussion on merging domains. 2812 Links inside the ACP only use link-local IPv6 addressing, such that 2813 each node's ACP only requires one routable address prefix. 2815 6.10.1. Fundamental Concepts of Autonomic Addressing 2817 o Usage: Autonomic addresses are exclusively used for self- 2818 management functions inside a trusted domain. They are not used 2819 for user traffic. Communications with entities outside the 2820 trusted domain use another address space, for example normally 2821 managed routable address space (called "Data-Plane" in this 2822 document). 2824 o Separation: Autonomic address space is used separately from user 2825 address space and other address realms. This supports the 2826 robustness requirement. 2828 o Loopback-only: Only ACP Loopback interfaces (and potentially those 2829 configured for "ACP connect", see Section 8.1) carry routable 2830 address(es); all other interfaces (called ACP virtual interfaces) 2831 only use IPv6 link local addresses. The usage of IPv6 link local 2832 addressing is discussed in [RFC7404]. 2834 o Use-ULA: For Loopback interfaces of ACP nodes, we use ULA with L=1 2835 (as defined in section 3.1 of [RFC4193]). Note that the random 2836 hash for ACP Loopback addresses uses the definition in 2837 Section 6.10.2 and not the one of [RFC4193] section 3.2.2. 2839 o No external connectivity: They do not provide access to the 2840 Internet. If a node requires further reaching connectivity, it 2841 should use another, traditionally managed address scheme in 2842 parallel. 2844 o Addresses in the ACP are permanent, and do not support temporary 2845 addresses as defined in [RFC4941]. 2847 o Addresses in the ACP are not considered sensitive on privacy 2848 grounds because ACP nodes are not expected to be end-user host. 2849 All ACP nodes are in one (potentially federated) administrative 2850 domain. They are assumed to be to be candidate hosts of ACP 2851 traffic amongst each other or transit thereof. There are no 2852 transit nodes less privileged to know about the identity of other 2853 hosts in the ACP. Therefore, ACP addresses do not need to be 2854 pseudo-random as discussed in [RFC7721]. Because they are not 2855 propagated to untrusted (non ACP) nodes and stay within a domain 2856 (of trust), we also consider them not to be subject to scanning 2857 attacks. 2859 The ACP is based exclusively on IPv6 addressing, for a variety of 2860 reasons: 2862 o Simplicity, reliability and scale: If other network layer 2863 protocols were supported, each would have to have its own set of 2864 security associations, routing table and process, etc. 2866 o Autonomic functions do not require IPv4: Autonomic functions and 2867 autonomic service agents are new concepts. They can be 2868 exclusively built on IPv6 from day one. There is no need for 2869 backward compatibility. 2871 o OAM protocols do not require IPv4: The ACP may carry OAM 2872 protocols. All relevant protocols (SNMP, TFTP, SSH, SCP, Radius, 2873 Diameter, ...) are available in IPv6. See also [RFC8368] for how 2874 ACP could be made to interoperate with IPv4 only OAM. 2876 Further explanation about the addressing and routing related reasons 2877 for the choice of the autonomous ACP addressing can be found in 2878 Section 6.12.5.1. 2880 6.10.2. The ACP Addressing Base Scheme 2882 The Base ULA addressing scheme for ACP nodes has the following 2883 format: 2885 8 40 2 78 2886 +--+-------------------------+------+------------------------------+ 2887 |fd| hash(routing-subdomain) | Type | (sub-scheme) | 2888 +--+-------------------------+------+------------------------------+ 2890 Figure 9: ACP Addressing Base Scheme 2892 The first 48-bits follow the ULA scheme, as defined in [RFC4193], to 2893 which a type field is added: 2895 o "fd" identifies a locally defined ULA address. 2897 o The 40-bits ULA "global ID" (term from [RFC4193]) for ACP 2898 addresses carried in the acp-node-name in the ACP domain 2899 certificates are the first 40-bits of the SHA256 hash of the 2900 routing subdomain from the same acp-node-name. In the example of 2901 Section 6.1.2, the routing subdomain is 2902 "area51.research.acp.example.com" and the 40-bits ULA "global ID" 2903 89b714f3db. 2905 o When creating a new routing-subdomain for an existing autonomic 2906 network, it MUST be ensured, that rsub is selected so the 2907 resulting hash of the routing-subdomain does not collide with the 2908 hash of any pre-existing routing-subdomains of the autonomic 2909 network. This ensures that ACP addresses created by registrars 2910 for different routing subdomains do not collide with each others. 2912 o To allow for extensibility, the fact that the ULA "global ID" is a 2913 hash of the routing subdomain SHOULD NOT be assumed by any ACP 2914 node during normal operations. The hash function is only executed 2915 during the creation of the certificate. If BRSKI is used then the 2916 BRSKI registrar will create the acp-node-name in response to the 2917 EST Certificate Signing Request (CSR) Attribute Request message by 2918 the pledge. 2920 o Establishing connectivity between different ACP (different acp- 2921 domain-name) is outside the scope of this specification. If it is 2922 being done through future extensions, then the rsub of all 2923 routing-subdomains across those autonomic networks need to be 2924 selected so the resulting routing-subdomain hashes do not collide. 2925 For example a large cooperation with its own private TA may want 2926 to create different autonomic networks that initially should not 2927 be able to connect but where the option to do so should be kept 2928 open. When taking this future possibility into account, it is 2929 easy to always select rsub so that no collisions happen. 2931 o Type: This field allows different address sub-schemes. This 2932 addresses the "upgradability" requirement. Assignment of types 2933 for this field will be maintained by IANA. 2935 The sub-scheme may imply a range or set of addresses assigned to the 2936 node, this is called the ACP address range/set and explained in each 2937 sub-scheme. 2939 Please refer to Section 6.10.7 and Appendix A.1 for further 2940 explanations why the following Sub-Addressing schemes are used and 2941 why multiple are necessary. 2943 The following summarizes the addressing Sub-Schemes: 2945 +------+-----+-----------------+-------+------------+ 2946 | Type | Z | name | F-bit | V-bit size | 2947 +------+-----+-----------------+-------+------------+ 2948 | 0x00 | 0 | ACP-Zone | N/A | 1 bit | 2949 +------+-----+-----------------+-------+------------+ 2950 | 0x00 | 1 | ACP-Manual | N/A | 1 bit | 2951 +------+-----+-----------------+-------+------------+ 2952 | 0x01 | N/A | ACP-VLong-8 | 0 | 8 bits | 2953 +------+-----+-----------------+-------+------------+ 2954 | 0x01 | N/A | ACP-VLong-16 | 1 | 16 bits | 2955 +------+-----+-----------------+-------+------------+ 2957 Figure 10: Addressing schemes 2959 6.10.3. ACP Zone Addressing Sub-Scheme (ACP-Zone) 2961 This sub-scheme is used when the Type field of the base scheme is 2962 0x00 and the Z bit is 0x0. 2964 64 64 2965 +-----------------+---+---------++-----------------------------+---+ 2966 | (base scheme) | Z | Zone-ID || Node-ID | 2967 | | | || Registrar-ID | Node-Number| V | 2968 +-----------------+---+---------++--------------+--------------+---+ 2969 50 1 13 48 15 1 2971 Figure 11: ACP Zone Addressing Sub-Scheme 2973 The fields are defined as follows: 2975 o Type: MUST be 0x0. 2977 o Z: MUST be 0x0. 2979 o Zone-ID: A value for a network zone. 2981 o Node-ID: A unique value for each node. 2983 The 64-bit Node-ID must be unique across the ACP domain for each 2984 node. It is derived and composed as follows: 2986 o Registrar-ID (48-bit): A number unique inside the domain that 2987 identifies the ACP registrar which assigned the Node-ID to the 2988 node. One or more domain-wide unique identifiers of the ACP 2989 registrar can be used for this purpose. See Section 6.10.7.2. 2991 o Node-Number: Number to make the Node-ID unique. This can be 2992 sequentially assigned by the ACP Registrar owning the Registrar- 2993 ID. 2995 o V (1-bit): Virtualization bit: 0: Indicates the ACP itself ("ACP 2996 node base system); 1: Indicates the optional "host" context on the 2997 ACP node (see below). 2999 In the ACP Zone Addressing Sub-Scheme, the ACP address in the 3000 certificate has V field as all zero bits. 3002 The ACP address set of the node includes addresses with any Zone-ID 3003 value and any V value. No two nodes in the same ACP can have the 3004 same Node-ID, but differerent Zone-IDs. 3006 The Virtual bit in this sub-scheme allows the easy addition of the 3007 ACP as a component to existing systems without causing problems in 3008 the port number space between the services in the ACP and the 3009 existing system. V:0 is the ACP router (autonomic node base system), 3010 V:1 is the host with pre-existing transport endpoints on it that 3011 could collide with the transport endpoints used by the ACP router. 3012 The ACP host could for example have a p2p virtual interface with the 3013 V:0 address as its router into the ACP. Depending on the software 3014 design of ASAs, which is outside the scope of this specification, 3015 they may use the V:0 or V:1 address. 3017 The location of the V bit(s) at the end of the address allows the 3018 announcement of a single prefix for each ACP node. For example, in a 3019 network with 20,000 ACP nodes, this avoid 20,000 additional routes in 3020 the routing table. 3022 It is RECOMMENDED that only Zone-ID 0 is used unless it is meant to 3023 be used in conjunction with operational practices for partial/ 3024 incremental adoption of the ACP as described in Section 9.4. 3026 Note: Zones and Zone-ID as defined here are not related to [RFC4007] 3027 zones or zone_id. ACP zone addresses are not scoped (reachable only 3028 from within an RFC4007 zone) but reachable across the whole ACP. An 3029 RFC4007 zone_id is a zone index that has only local significance on a 3030 node, whereas an ACP Zone-ID is an identifier for an ACP zone that is 3031 unique across that ACP. 3033 6.10.4. ACP Manual Addressing Sub-Scheme (ACP-Manual) 3035 This sub-scheme is used when the Type field of the base scheme is 3036 0x00 and the Z bit is 0x1. 3038 64 64 3039 +---------------------+---+----------++-----------------------------+ 3040 | (base scheme) | Z | Subnet-ID|| Interface Identifier | 3041 +---------------------+---+----------++-----------------------------+ 3042 50 1 13 3044 Figure 12: ACP Manual Addressing Sub-Scheme 3046 The fields are defined as follows: 3048 o Type: MUST be 0x0. 3050 o Z: MUST be 0x1. 3052 o Subnet-ID: Configured subnet identifier. 3054 o Interface Identifier. 3056 This sub-scheme is meant for "manual" allocation to subnets where the 3057 other addressing schemes cannot be used. The primary use case is for 3058 assignment to ACP connect subnets (see Section 8.1.1). 3060 "Manual" means that allocations of the Subnet-ID need to be done 3061 today with pre-existing, non-autonomic mechanisms. Every subnet that 3062 uses this addressing sub-scheme needs to use a unique Subnet-ID 3063 (unless some anycast setup is done). 3065 The Z bit field was added to distinguish Zone addressing and manual 3066 addressing sub-schemes without requiring one more bit in the base 3067 scheme and therefore allowing for the Vlong scheme (described below) 3068 to have one more bit available. 3070 Manual addressing sub-scheme addresses SHOULD NOT be used in ACP 3071 domain certificates. Any node capable to build ACP secure channels 3072 and permitted by Registrar policy to participate in building ACP 3073 secure channels SHOULD receive an ACP address (prefix) from one of 3074 the other ACP addressing sub-schemes. Nodes not capable (or 3075 permitted) to participate in ACP secure channels can connect to the 3076 ACP via ACP connect interfaces of ACP edge nodes (see Section 8.1), 3077 without setting up an ACP secure channel. Their ACP domain 3078 certificate MUST include an empty acp-address to indicate that their 3079 ACP domain certificate is only usable for non- ACP secure channel 3080 authentication, such as end-to-end transport connections across the 3081 ACP or Data-Plane. 3083 Address management of ACP connect subnets is done using traditional 3084 assignment methods and existing IPv6 protocols. See Section 8.1.3 3085 for details. 3087 6.10.5. ACP Vlong Addressing Sub-Scheme (ACP-VLong-8/ACP-VLong-16 3089 This sub-scheme is used when the Type field of the base scheme is 3090 0x01. 3092 50 78 3093 +---------------------++-----------------------------+----------+ 3094 | (base scheme) || Node-ID | 3095 | || Registrar-ID |F| Node-Number| V | 3096 +---------------------++--------------+--------------+----------+ 3097 50 46 1 23/15 8/16 3099 Figure 13: ACP Vlong Addressing Sub-Scheme 3101 This addressing scheme foregoes the Zone-ID field to allow for 3102 larger, flatter routed networks (e.g., as in IoT) with 8421376 Node- 3103 Numbers (2^23+2^15). It also allows for up to 2^16 (i.e. 65536) 3104 different virtualized addresses within a node, which could be used to 3105 address individual software components in an ACP node. 3107 The fields are the same as in the Zone-ID sub-scheme with the 3108 following refinements: 3110 o F: format bit. This bit determines the format of the subsequent 3111 bits. 3113 o V: Virtualization bit: this is a field that is either 8 or 16 3114 bits. For F=0, it is 8 bits, for F=1 it is 16 bits. The V bits 3115 are assigned by the ACP node. In the ACP certificate's ACP 3116 address Section 6.1.2, the V-bits are always set to 0. 3118 o Registrar-ID: To maximize Node-Number and V, the Registrar-ID is 3119 reduced to 46-bits. One or more domain-wide unique identifiers of 3120 the ACP registrar can be used for this purpose. See 3121 Section 6.10.7.2. 3123 o The Node-Number is unique to each ACP node. There are two formats 3124 for the Node-Number. When F=0, the node-number is 23 bits, for 3125 F=1 it is 15 bits. Each format of node-number is considered to be 3126 in a unique number space. 3128 The F=0 bit format addresses are intended to be used for "general 3129 purpose" ACP nodes that would potentially have a limited number (< 3130 256) of clients (ASA/Autonomic Functions or legacy services) of the 3131 ACP that require separate V(irtual) addresses. 3133 The F=1 bit Node-Numbers are intended for ACP nodes that are ACP edge 3134 nodes (see Section 8.1.1) or that have a large number of clients 3135 requiring separate V(irtual) addresses. For example large SDN 3136 controllers with container modular software architecture (see 3137 Section 8.1.2). 3139 In the Vlong addressing sub-scheme, the ACP address in the 3140 certificate has all V field bits as zero. The ACP address set for 3141 the node includes any V value. 3143 6.10.6. Other ACP Addressing Sub-Schemes 3145 Before further addressing sub-schemes are defined, experience with 3146 the schemes defined here should be collected. The schemes defined in 3147 this document have been devised to allow hopefully sufficiently 3148 flexible setup of ACPs for a variety of situation. These reasons 3149 also lead to the fairly liberal use of address space: The Zone 3150 Addressing Sub-Scheme is intended to enable optimized routing in 3151 large networks by reserving bits for Zone-ID's. The Vlong addressing 3152 sub-scheme enables the allocation of 8/16-bit of addresses inside 3153 individual ACP nodes. Both address spaces allow distributed, 3154 uncoordinated allocation of node addresses by reserving bits for the 3155 registrar-ID field in the address. 3157 IANA is asked need to assign a new "type" for each new addressing 3158 sub-scheme. With the current allocations, only 2 more schemes are 3159 possible, so the last addressing scheme MUST provide further 3160 extensions (e.g., by reserving bits from it for further extensions). 3162 6.10.7. ACP Registrars 3164 ACP registrars are responsible to enroll candidate ACP nodes with ACP 3165 domain certificates and associated trust point(s). They are also 3166 responsible that an acp-node-name field is included in the ACP domain 3167 certificate carrying the ACP domain name and the ACP nodes ACP 3168 address prefix. This address prefix is intended to persist unchanged 3169 through the lifetime of the ACP node. 3171 Because of the ACP addressing sub-schemes, an ACP domain can have 3172 multiple distributed ACP registrars that do not need to coordinate 3173 for address assignment. ACP registrars can also be sub-CAs, in which 3174 case they can also assign ACP domain certificates without 3175 dependencies against a (shared) TA (except during renewals of their 3176 own certificates). 3178 ACP registrars are PKI registration authorities (RA) enhanced with 3179 the handling of the ACP domain certificate specific fields. They 3180 request certificates for ACP nodes from a Certification Authority 3181 through any appropriate mechanism (out of scope in this document, but 3182 required to be BRSKI for ANI registrars). Only nodes that are 3183 trusted to be compliant with the requirements against registrar 3184 described in this section can be given the necessary credentials to 3185 perform this RA function, such as credentials for the BRSKI 3186 connection to the CA for ANI registrars. 3188 6.10.7.1. Use of BRSKI or other Mechanism/Protocols 3190 Any protocols or mechanisms may be used as ACP registrars, as long as 3191 the resulting ACP certificate and TA certificate(s) allow to perform 3192 the ACP domain membership described in Section 6.1.3 with other ACP 3193 domain members, and meet the ACP addressing requirements for its acp- 3194 node-name as described further below in this section. 3196 An ACP registrar could be a person deciding whether to enroll a 3197 candidate ACP node and then orchestrating the enrollment of the ACP 3198 certificate and associated TA, using command line or web based 3199 commands on the candidate ACP node and TA to generate and sign the 3200 ACP domain certificate and configure certificate and TA onto the 3201 node. 3203 The only currently defined protocol for ACP registrars is BRSKI 3204 ([I-D.ietf-anima-bootstrapping-keyinfra]). When BRSKI is used, the 3205 ACP nodes are called ANI nodes, and the ACP registrars are called 3206 BRSKI or ANI registrars. The BRSKI specification does not define the 3207 handling of the acp-node-name field because the rules do not depend 3208 on BRSKI but apply equally to any protocols/mechanisms an ACP 3209 registrar may use. 3211 6.10.7.2. Unique Address/Prefix allocation 3213 ACP registrars MUST NOT allocate ACP address prefixes to ACP nodes 3214 via the acp-node-name that would collide with the ACP address 3215 prefixes of other ACP nodes in the same ACP domain. This includes 3216 both prefixes allocated by the same ACP registrar to different ACP 3217 nodes as well as prefixes allocated by other ACP registrars for the 3218 same ACP domain. 3220 To support such unique address allocation, an ACP registrar MUST have 3221 one or more 46-bit identifiers unique across the ACP domain which is 3222 called the Registrar-ID. Allocation of Registrar-ID(s) to an ACP 3223 registrar can happen through OAM mechanisms in conjunction with some 3224 database / allocation orchestration. 3226 ACP registrars running on physical devices with known globally unique 3227 EUI-48 MAC address(es) can use the lower 46 bits of those address(es) 3228 as unique Registrar-IDs without requiring any external signaling/ 3229 configuration (the upper two bits, V and U are not uniquely assigned 3230 but functional). This approach is attractive for distributed, non- 3231 centrally administered, lightweight ACP registrar implementations. 3232 There is no mechanism to deduce from a MAC address itself whether it 3233 is actually uniquely assigned. Implementations need to consult 3234 additional offline information before making this assumption. For 3235 example by knowing that a particular physical product/MIC-chip is 3236 guaranteed to use globally unique assigned EUI-48 MAC address(es). 3238 When the candidate ACP device (called Pledge in BRSKI) is to be 3239 enrolled into an ACP domain, the ACP registrar needs to allocate a 3240 unique ACP address to the node and ensure that the ACP certificate 3241 gets a acp-node-name field (Section 6.1.2) with the appropriate 3242 information - ACP domain-name, ACP-address, and so on. If the ACP 3243 registrar uses BRSKI, it signals the ACP acp-node-name field to the 3244 Pledge via the EST /csrattrs command (see 3245 [I-D.ietf-anima-bootstrapping-keyinfra], section 5.9.2 - "EST CSR 3246 Attributes"). 3248 [RFC Editor: please update reference to section 5.9.2 accordingly 3249 with latest BRSKI draft at time of publishing, or RFC] 3251 6.10.7.3. Addressing Sub-Scheme Policies 3253 The ACP registrar selects for the candidate ACP node a unique address 3254 prefix from an appropriate ACP addressing sub-scheme, either a zone 3255 addressing sub-scheme prefix (see Section 6.10.3), or a Vlong 3256 addressing sub-scheme prefix (see Section 6.10.5). The assigned ACP 3257 address prefix encoded in the acp-node-name field of the ACP domain 3258 certificate indicates to the ACP node its ACP address information. 3259 The sub-addressing scheme indicates the prefix length: /127 for zone 3260 address sub-scheme, /120 or /112 for Vlong address sub-scheme. The 3261 first address of the prefix is the ACP address. All other addresses 3262 in the prefix are for other uses by the ACP node as described in the 3263 zone and Vlong addressing sub scheme sections. The ACP address 3264 prefix itself is then signaled by the ACP node into the ACP routing 3265 protocol (see Section 6.11) to establish IPv6 reachability across the 3266 ACP. 3268 The choice of addressing sub-scheme and prefix-length in the Vlong 3269 address sub-scheme is subject to ACP registrar policy. It could be 3270 an ACP domain wide policy, or a per ACP node or per ACP node type 3271 policy. For example, in BRSKI, the ACP registrar is aware of the 3272 IDevID certificate of the candidate ACP node, which contains a 3273 "serialNnumber" that is typically indicating the node's vendor and 3274 device type and can be used to drive a policy selecting an 3275 appropriate addressing sub-scheme for the (class of) node(s). 3277 ACP registrars SHOULD default to allocate ACP zone sub-address scheme 3278 addresses with Zone-ID 0. 3280 ACP registrars that are aware of can use the IDevID certificate of a 3281 candidate ACP device SHOULD be able to choose the zone vs. Vlong sub- 3282 address scheme for ACP nodes based on the "serialNumber" of the 3283 IDevID certificate, for example by the PID (Product Identifier) part 3284 which identifies the product type, or the complete "serialNumber". 3286 In a simple allocation scheme, an ACP registrar remembers 3287 persistently across reboots its currently used Registrar-ID and for 3288 each addressing scheme (Zone with Zone-ID 0, Vlong with /112, Vlong 3289 with /120), the next Node-Number available for allocation and 3290 increases it during successful enrollment to an ACP node. In this 3291 simple allocation scheme, the ACP registrar would not recycle ACP 3292 address prefixes from no longer used ACP nodes. 3294 6.10.7.4. Address/Prefix Persistence 3296 When an ACP domain certificate is renewed or rekeyed via EST or other 3297 mechanisms, the ACP address/prefix in the acp-node-name field MUST be 3298 maintained unless security issues or violations of the unique address 3299 assignment requirements exist or are suspected by the ACP registrar. 3301 ACP address information SHOULD be maintained even when the renewing/ 3302 rekeying ACP registrar is not the same as the one that enrolled the 3303 prior ACP certificate. See Section 9.2.4 for an example. 3305 ACP address information SHOULD also be maintained even after an ACP 3306 certificate did expire or failed. See Section 6.1.5.5 and 3307 Section 6.1.5.6. 3309 6.10.7.5. Further Details 3311 Section 9.2 discusses further informative details of ACP registrars: 3312 What interactions registrars need, what parameters they require, 3313 certificate renewal and limitations, use of sub-CAs on registrars and 3314 centralized policy control. 3316 6.11. Routing in the ACP 3318 Once ULA address are set up all autonomic entities should run a 3319 routing protocol within the autonomic control plane context. This 3320 routing protocol distributes the ULA created in the previous section 3321 for reachability. The use of the autonomic control plane specific 3322 context eliminates the probable clash with Data-Plane routing tables 3323 and also secures the ACP from interference from the configuration 3324 mismatch or incorrect routing updates. 3326 The establishment of the routing plane and its parameters are 3327 automatic and strictly within the confines of the autonomic control 3328 plane. Therefore, no explicit configuration is required. 3330 All routing updates are automatically secured in transit as the 3331 channels of the ACP are encrypted, and this routing runs only inside 3332 the ACP. 3334 The routing protocol inside the ACP is RPL ([RFC6550]). See 3335 Appendix A.4 for more details on the choice of RPL. 3337 RPL adjacencies are set up across all ACP channels in the same domain 3338 including all its routing subdomains. See Appendix A.7 for more 3339 details. 3341 6.11.1. ACP RPL Profile 3343 The following is a description of the RPL profile that ACP nodes need 3344 to support by default. The format of this section is derived from 3345 draft-ietf-roll-applicability-template. 3347 6.11.1.1. Overview 3349 RPL Packet Information (RPI) defined in [RFC6550], section 11.2 3350 defines the data packet artefacts required or beneficial in 3351 forwarding of packets routed by RPL. This profile does not use RPI 3352 for better compatibility with accelerated hardware forwarding planes 3353 which most often does not support the Hop-by-Hop headers used for 3354 RPI, but also to avoid the overhead of the RPI header on the wire and 3355 cost of adding/removing them. 3357 6.11.1.1.1. Single Instance 3359 To avoid the need for RPI, the ACP RPL profile uses a simple 3360 destination prefix based routing/forwarding table. To achieve this, 3361 the profiles uses only one RPL instanceID. This single instanceID 3362 can contain only one Destination Oriented Directed Acyclic Graph 3363 (DODAG), and the routing/forwarding table can therefore only 3364 calculate a single class of service ("best effort towards the primary 3365 NOC/root") and cannot create optimized routing paths to accomplish 3366 latency or energy goals between any two nodes. 3368 This choice is a compromise. Consider a network that has multiple 3369 NOCs in different locations. Only one NOC will become the DODAG 3370 root. Traffic to and from other NOCs has to be sent through the 3371 DODAG (shortest path tree) rooted in the primary NOC. Depending on 3372 topology, this can be an annoyance from a latency point of view or 3373 from minimizing network path resources, but this is deemed to be 3374 acceptable given how ACP traffic is "only" network management/control 3375 traffic. See Appendix A.10.4 for more details. 3377 Using a single instanceID/DODAG does not introduce a single point of 3378 failure, as the DODAG will reconfigure itself when it detects Data- 3379 Plane forwarding failures including choosing a different root when 3380 the primary one fails. 3382 The benefit of this profile, especially compared to other IGPs is 3383 that it does not calculate routes for node reachable through the same 3384 interface as the DODAG root. This RPL profile can therefore scale to 3385 much larger number of ACP nodes in the same amount of compute and 3386 memory than other routing protocols. Especially on nodes that are 3387 leafs of the topology or those close to those leafs. 3389 6.11.1.1.2. Reconvergence 3391 In RPL profiles where RPL Packet Information (RPI, see 3392 Section 6.11.1.13) is present, it is also used to trigger 3393 reconvergence when misrouted, for example looping, packets are 3394 recognized because of their RPI data. This helps to minimize RPL 3395 signaling traffic especially in networks without stable topology and 3396 slow links. 3398 The ACP RPL profile instead relies on quick reconverging the DODAG by 3399 recognizing link state change (down/up) and triggering reconvergence 3400 signaling as described in Section 6.11.1.7. Since links in the ACP 3401 are assumed to be mostly reliable (or have link layer protection 3402 against loss) and because there is no stretch according to 3403 Section 6.11.1.7, loops caused by loss of RPL routing protocol 3404 signaling packets should be exceedingly rare. 3406 In addition, there are a variety of mechanisms possible in RPL to 3407 further avoid temporary loops RECOMMENDED to be used for the ACPL RPL 3408 profile: DODAG Information Objects (DIOs) SHOULD be sent 2...3 times 3409 to inform children when losing the last parent. The technique in 3410 [RFC6550] section 8.2.2.6. (Detaching) SHOULD be favored over that 3411 in section 8.2.2.5., (Poisoning) because it allows local 3412 connectivity. Nodes SHOULD select more than one parent, at least 3 3413 if possible, and send Destination Advertisement Objects (DAO)s to all 3414 of them in parallel. 3416 Additionally, failed ACP tunnels can be quickly discovered trough the 3417 secure channel protocol mechanisms such as IKEv2 Dead Peer Detection. 3418 This can function as a replacement for a Low-power and Lossy 3419 Networks' (LLN's) Expected Transmission Count (ETX) feature that is 3420 not used in this profile. A failure of an ACP tunnel should 3421 imediately signal the RPL control plane to pick a different parent. 3423 6.11.1.2. RPL Instances 3425 Single RPL instance. Default RPLInstanceID = 0. 3427 6.11.1.3. Storing vs. Non-Storing Mode 3429 RPL Mode of Operations (MOP): MUST support mode 2 - "Storing Mode of 3430 Operations with no multicast support". Implementations MAY support 3431 mode 3 ("... with multicast support" as that is a superset of mode 3432 2). Note: Root indicates mode in DIO flow. 3434 6.11.1.4. DAO Policy 3436 Proactive, aggressive DAO state maintenance: 3438 o Use K-flag in unsolicited DAO indicating change from previous 3439 information (to require DAO-ACK). 3441 o Retry such DAO DAO-RETRIES(3) times with DAO- ACK_TIME_OUT(256ms) 3442 in between. 3444 6.11.1.5. Path Metric 3446 Hopcount. 3448 6.11.1.6. Objective Function 3450 Objective Function (OF): Use OF0 [RFC6552]. No use of metric 3451 containers. 3453 rank_factor: Derived from link speed: <= 100Mbps: 3454 LOW_SPEED_FACTOR(5), else HIGH_SPEED_FACTOR(1) 3456 This is a simple rank differentiation between typical "low speed" or 3457 "IoT" links that commonly max out at 100 Mbps and typical 3458 infrastructure links with speeds of 1 Gbps or higher. Given how the 3459 path selection for the ACP focusses only on reachability but not on 3460 path cost optimization, no attempts at finer grained path 3461 optimization are made. 3463 6.11.1.7. DODAG Repair 3465 Global Repair: we assume stable links and ranks (metrics), so no need 3466 to periodically rebuild DODAG. DODAG version only incremented under 3467 catastrophic events (e.g., administrative action). 3469 Local Repair: As soon as link breakage is detected, send No-Path DAO 3470 for all the targets that were reachable only via this link. As soon 3471 as link repair is detected, validate if this link provides you a 3472 better parent. If so, compute your new rank, and send new DIO that 3473 advertises your new rank. Then send a DAO with a new path sequence 3474 about yourself. 3476 stretch_rank: none provided ("not stretched"). 3478 Data Path Validation: Not used. 3480 Trickle: Not used. 3482 6.11.1.8. Multicast 3484 Not used yet but possible because of the selected mode of operations. 3486 6.11.1.9. Security 3488 [RFC6550] security not used, substituted by ACP security. 3490 Because the ACP links already include provisions for confidentiality 3491 and integrity protection, their usage at the RPL layer would be 3492 redundant, and so RPL security is not used. 3494 6.11.1.10. P2P communications 3496 Not used. 3498 6.11.1.11. IPv6 address configuration 3500 Every ACP node (RPL node) announces an IPv6 prefix covering the 3501 address(es) used in the ACP node. The prefix length depends on the 3502 chosen addressing sub-scheme of the ACP address provisioned into the 3503 certificate of the ACP node, e.g., /127 for Zone Addressing Sub- 3504 Scheme or /112 or /120 for Vlong addressing sub-scheme. See 3505 Section 6.10 for more details. 3507 Every ACP node MUST install a black hole (aka null) route for 3508 whatever ACP address space that it advertises (i.e.: the /96 or 3509 /127). This is avoid routing loops for addresses that an ACP node 3510 has not (yet) used. 3512 6.11.1.12. Administrative parameters 3514 Administrative Preference ([RFC6550], 3.2.6 - to become root): 3515 Indicated in DODAGPreference field of DIO message. 3517 o Explicit configured "root": 0b100 3519 o ACP registrar (Default): 0b011 3521 o ACP-connect (non-registrar): 0b010 3523 o Default: 0b001. 3525 6.11.1.13. RPL Packet Information 3527 RPI is not required in the ACP RPL profile for the following reasons. 3529 One RPI option is the RPL Source Routing Header (SRH) [RFC6554] which 3530 is not necessary because the ACP RPL profile uses storing mode where 3531 each hop has the necessary next-hop forwarding information. 3533 The simpler RPL Option header [RFC6553] is also not necessary in this 3534 profile, because it uses a single RPL instance and data path 3535 validation is also not used. 3537 6.11.1.14. Unknown Destinations 3539 Because RPL minimizes the size of the routing and forwarding table, 3540 prefixes reachable through the same interface as the RPL root are not 3541 known on every ACP node. Therefore traffic to unknown destination 3542 addresses can only be discovered at the RPL root. The RPL root 3543 SHOULD have attach safe mechanisms to operationally discover and log 3544 such packets. 3546 As this requirement raises additional Data-Plane, it does not apply 3547 to nodes where the administrative parameter to become root 3548 (Section 6.11.1.12) can always only be 0b001, e.g.: the node does not 3549 support explicit configuration to be root, or to be ACP registrar or 3550 to have ACP-connect functionality. If an ACP network is degraded to 3551 the point where there are no nodes that could be configured roots, 3552 ACP registrars or ACP-connect nodes, traffic to unknown destinations 3553 could not be diagnosed, but in the absence of any intelligent nodes 3554 supporting other than 0b001 administrative preference, there is 3555 likely also no diagnostic function possible. 3557 6.12. General ACP Considerations 3559 Since channels are by default established between adjacent neighbors, 3560 the resulting overlay network does hop-by-hop encryption. Each node 3561 decrypts incoming traffic from the ACP, and encrypts outgoing traffic 3562 to its neighbors in the ACP. Routing is discussed in Section 6.11. 3564 6.12.1. Performance 3566 There are no performance requirements against ACP implementations 3567 defined in this document because the performance requirements depend 3568 on the intended use case. It is expected that full autonomic node 3569 with a wide range of ASA can require high forwarding plane 3570 performance in the ACP, for example for telemetry. Implementations 3571 of ACP to solely support traditional/SDN style use cases can benefit 3572 from ACP at lower performance, especially if the ACP is used only for 3573 critical operations, e.g., when the Data-Plane is not available. The 3574 design of the ACP as specified in this document is intended to 3575 support a wide range of performance options: It is intended to allow 3576 software-only implementations at potentially low performance, but can 3577 also support high performance options. See [RFC8368] for more 3578 details. 3580 6.12.2. Addressing of Secure Channels 3582 In order to be independent of the Data-Plane routing and addressing, 3583 the GRASP discovered ACP secure channels use IPv6 link local 3584 addresses between adjacent neighbors. Note: Section 8.2 specifies 3585 extensions in which secure channels are configured tunnels operating 3586 over the Data-Plane, so those secure channels cannot be independent 3587 of the Data-Plane. 3589 To avoid that Data-Plane configuration can impact the operations of 3590 the IPv6 (link-local) interface/address used for ACP channels, 3591 appropriate implementation considerations are required. If the IPv6 3592 interface/link-local address is shared with the Data-Plane it needs 3593 to be impossible to unconfigure/disable it through configuration. 3594 Instead of sharing the IPv6 interface/link-local address, a separate 3595 (virtual) interface with a separate IPv6 link-local address can be 3596 used. For example, the ACP interface could be run over a separate 3597 MAC address of an underlying L2 (Ethernet) interface. For more 3598 details and options, see Appendix A.10.2. 3600 Note that other (non-ideal) implementation choices may introduce 3601 additional undesired dependencies against the Data-Plane. For 3602 example shared code and configuration of the secure channel protocols 3603 (IPsec / DTLS). 3605 6.12.3. MTU 3607 The MTU for ACP secure channels MUST be derived locally from the 3608 underlying link MTU minus the secure channel encapsulation overhead. 3610 ACP secure Channel protocols do not need to perform MTU discovery 3611 because they are built across L2 adjacencies - the MTU on both sides 3612 connecting to the L2 connection are assumed to be consistent. 3613 Extensions to ACP where the ACP is for example tunneled need to 3614 consider how to guarantee MTU consistency. This is an issue of 3615 tunnels, not an issue of running the ACP across a tunnel. Transport 3616 stacks running across ACP can perform normal PMTUD (Path MTU 3617 Discovery). Because the ACP is meant to be prioritize reliability 3618 over performance, they MAY opt to only expect IPv6 minimum MTU (1280) 3619 to avoid running into PMTUD implementation bugs or underlying link 3620 MTU mismatch problems. 3622 6.12.4. Multiple links between nodes 3624 If two nodes are connected via several links, the ACP SHOULD be 3625 established across every link, but it is possible to establish the 3626 ACP only on a sub-set of links. Having an ACP channel on every link 3627 has a number of advantages, for example it allows for a faster 3628 failover in case of link failure, and it reflects the physical 3629 topology more closely. Using a subset of links (for example, a 3630 single link), reduces resource consumption on the node, because state 3631 needs to be kept per ACP channel. The negotiation scheme explained 3632 in Section 6.5 allows Alice (the node with the higher ACP address) to 3633 drop all but the desired ACP channels to Bob - and Bob will not re- 3634 try to build these secure channels from his side unless Alice shows 3635 up with a previously unknown GRASP announcement (e.g., on a different 3636 link or with a different address announced in GRASP). 3638 6.12.5. ACP interfaces 3640 The ACP VRF has conceptually two type of interfaces: The "ACP 3641 Loopback interface(s)" to which the ACP ULA address(es) are assigned 3642 and the "ACP virtual interfaces" that are mapped to the ACP secure 3643 channels. 3645 6.12.5.1. ACP loopback interfaces 3647 For autonomous operations of the ACP, as described in Section 6 and 3648 Section 7, the ACP node uses the first address from the N bit ACP 3649 prefix (N = 128 - number of Vbits of the ACP address) assigned to the 3650 node. This address is assigned with an adddress prefix of N or 3651 larger to a loopback interface. 3653 Other addresses from the prefix can be used by the ACP of the node as 3654 desired. The autonomous operations of the ACP does not require 3655 additional global scope IPv6 addresses, they are instead intended for 3656 ASA or non-autonomous functions. Non fully autonomic components of 3657 the ACP such as ACP connect interfaces (see Figure 15 may also 3658 introduce additional global scope IPv6 addresses on other type of 3659 interfaces into the ACP. 3661 [RFC Editor: please remove this paragraph: Note to reviewers: Please 3662 do not complain again about an obsolete RFC number in the following 3663 paragraph. The text should make it clear that the reference was 3664 choosen to indicate a particular point in time, but not to recommend/ 3665 use a particularily obsolete protocol spec.] 3667 The use of loopback interfaces for global scope addresses is common 3668 operational configuration practice on routers, for example in IBGP 3669 connections since BGP4 (see [RFC1654]) or earlier. The ACP adopts 3670 and automates this operational practice. 3672 A loopback interface for use with the ACP as described above is an 3673 interface behaving according to [RFC6724] Section 4., paragraph 2: 3674 Packets sent by the host of the node from the loopback interface 3675 behave as if they are looped back by the interface so that they look 3676 as if they originated from the loopback interface, are then received 3677 by the node and forwarded by it towards the destination. 3679 The word loopback only indicates this behavior, but not the actual 3680 name of the interface type choosen in an actual implementation. A 3681 loopback interface for use with the ACP can be a virtual/software 3682 construct without any associated hardware, or it can be a hardware 3683 interface operating in loopback mode. 3685 A loopback interface used for the ACP MUST NOT have connectivity to 3686 other nodes. 3688 The following reviews the reasons for the choice of loopback 3689 addresses for ACP addresses is based on the IPv6 address architecture 3690 and common challenges: 3692 1. IPv6 addresses are assigned to interfaces, not nodes. IPv6 3693 continues the IPv4 model that a subnet prefix is associated with 3694 one link, see [RFC4291], Section 2.1. 3696 2. IPv6 implementations do commonly not allow to assign the same 3697 IPv6 global scope address in the same VRF to more than one 3698 interface. 3700 3. Global scope addresses assigned to interfaces that are connecting 3701 to other nodes (external interfaces) may not be stable addresses 3702 for communications because any such interface could fail due to 3703 reasons external to the node. This could render the addresses 3704 assigned to that interface unusable. 3706 4. If failure of the subnet does not result in bringing down the 3707 interface and making the addresses unusable, it could result in 3708 unreachability of the address because the shortest path to the 3709 node might go through one of the other nodes on the same subnet 3710 which could equally consider the subnet to be operational even 3711 though it is not. 3713 5. Many OAM service implementations on routers can not deal with 3714 more than one peer address, often because they do already expect 3715 that a single loopback address can be used, especially to provide 3716 a stable address under failure of external interfaces or links. 3718 6. Even when an application supports multiple addresses to a peer, 3719 it can only use one adddress for a connection at a time with the 3720 most widely deployed transport protocols TCP and UDP. While 3721 [RFC6824] solves this problem, it is not widely adopted for 3722 router OAM services implementations. 3724 7. To completely autonomously assign global scope addresses to 3725 subnets connecting to other nodes, it would be necessary for 3726 every node to have an amount of prefix address space in the order 3727 of the maximum number of subnets that the node could connect to 3728 and then the node would have to negotiate with adjacent nodes 3729 across those subnet whose address space to use for each subnet. 3731 8. Using global scope addresses for subnets between nodes is 3732 unnecessary if those subnets only connect routers, such as ACP 3733 secure channels because they can communicate to remote nodes via 3734 their global scope loopback addresses. Using global scope 3735 addresses for those extern subnets is therefore wasteful for the 3736 address space and also unnecessarily increasing the size of 3737 routing and forwarding tables, which especially for the ACP is 3738 highly undesirable because it should attempt to minimize the per- 3739 node overhead of the ACP VRF. 3741 9. For all these reasons, the ACP addressing schemes do not consider 3742 ACP addresses for subnets connecting ACP nodes. 3744 Note that [RFC8402] introduces the term Node-SID to refer to IGP 3745 prefix segments that identify a specific rouer, for example on a 3746 loopback interface. An ACP loopback address prefix may similarily be 3747 called an ACP Node Identifier. 3749 6.12.5.2. ACP virtual interfaces 3751 Any ACP secure channel to another ACP node is mapped to ACP virtual 3752 interfaces in one of the following ways. This is independent of the 3753 chosen secure channel protocol (IPsec, DTLS or other future protocol 3754 - standards or non-standards). 3756 Note that all the considerations described here are assuming point- 3757 to-point secure channel associations. Mapping multi-party secure 3758 channel associations such as [RFC6407] is out of scope (but would be 3759 easy to add). 3761 6.12.5.2.1. ACP point-to-point virtual interfaces 3763 In this option, each ACP secure channel is mapped into a separate 3764 point-to-point ACP virtual interface. If a physical subnet has more 3765 than two ACP capable nodes (in the same domain), this implementation 3766 approach will lead to a full mesh of ACP virtual interfaces between 3767 them. 3769 6.12.5.2.2. ACP multi-access virtual interfaces 3771 In a more advanced implementation approach, the ACP will construct a 3772 single multi-access ACP virtual interface for all ACP secure channels 3773 to ACP capable nodes reachable across the same underlying (physical) 3774 subnet. IPv6 link-local multicast packets sent into an ACP multi- 3775 access virtual interface are replicated to every ACP secure channel 3776 mapped into the ACP multicast-access virtual interface. IPv6 unicast 3777 packets sent into an ACP multi-access virtual interface are sent to 3778 the ACP secure channel that belongs to the ACP neighbor that is the 3779 next-hop in the ACP forwarding table entry used to reach the packets 3780 destination address. 3782 There is no requirement for all ACP nodes on the same multi-access 3783 subnet to use the same type of ACP virtual interface. This is purely 3784 a node local decision. 3786 ACP nodes MUST perform standard IPv6 operations across ACP virtual 3787 interfaces including SLAAC (Stateless Address Auto-Configuration) - 3788 [RFC4862]) to assign their IPv6 link local address on the ACP virtual 3789 interface and ND (Neighbor Discovery - [RFC4861]) to discover which 3790 IPv6 link-local neighbor address belongs to which ACP secure channel 3791 mapped to the ACP virtual interface. This is independent of whether 3792 the ACP virtual interface is point-to-point or multi-access. 3794 "Optimistic Duplicate Address Detection (DAD)" according to [RFC4429] 3795 is RECOMMENDED because the likelihood for duplicates between ACP 3796 nodes is highly improbable as long as the address can be formed from 3797 a globally unique local assigned identifier (e.g., EUI-48/EUI-64, see 3798 below). 3800 ACP nodes MAY reduce the amount of link-local IPv6 multicast packets 3801 from ND by learning the IPv6 link-local neighbor address to ACP 3802 secure channel mapping from other messages such as the source address 3803 of IPv6 link-local multicast RPL messages - and therefore forego the 3804 need to send Neighbor Solicitation messages. 3806 The ACP virtual interface IPv6 link local address can be derived from 3807 any appropriate local mechanism such as node local EUI-48 or EUI-64 3808 ("EUI" stands for "Extended Unique Identifier"). It MUST NOT depend 3809 on something that is attackable from the Data-Plane such as the IPv6 3810 link-local address of the underlying physical interface, which can be 3811 attacked by SLAAC, or parameters of the secure channel encapsulation 3812 header that may not be protected by the secure channel mechanism. 3814 The link-layer address of an ACP virtual interface is the address 3815 used for the underlying interface across which the secure tunnels are 3816 built, typically Ethernet addresses. Because unicast IPv6 packets 3817 sent to an ACP virtual interface are not sent to a link-layer 3818 destination address but rather an ACP secure channel, the link-layer 3819 address fields SHOULD be ignored on reception and instead the ACP 3820 secure channel from which the message was received should be 3821 remembered. 3823 Multi-access ACP virtual interfaces are preferable implementations 3824 when the underlying interface is a (broadcast) multi-access subnet 3825 because they do reflect the presence of the underlying multi-access 3826 subnet into the virtual interfaces of the ACP. This makes it for 3827 example simpler to build services with topology awareness inside the 3828 ACP VRF in the same way as they could have been built running 3829 natively on the multi-access interfaces. 3831 Consider also the impact of point-to-point vs. multi-access virtual 3832 interface on the efficiency of flooding via link local multicasted 3833 messages: 3835 Assume a LAN with three ACP neighbors, Alice, Bob and Carol. Alice's 3836 ACP GRASP wants to send a link-local GRASP multicast message to Bob 3837 and Carol. If Alice's ACP emulates the LAN as one point-to-point 3838 virtual interface to Bob and one to Carol, The sending applications 3839 itself will send two copies, if Alice's ACP emulates a LAN, GRASP 3840 will send one packet and the ACP will replicate it. The result is 3841 the same. The difference happens when Bob and Carol receive their 3842 packet. If they use ACP point-to-point virtual interfaces, their 3843 GRASP instance would forward the packet from Alice to each other as 3844 part of the GRASP flooding procedure. These packets are unnecessary 3845 and would be discarded by GRASP on receipt as duplicates (by use of 3846 the GRASP Session ID). If Bob and Carol's ACP would emulate a multi- 3847 access virtual interface, then this would not happen, because GRASPs 3848 flooding procedure does not replicate back packets to the interface 3849 that they were received from. 3851 Note that link-local GRASP multicast messages are not sent directly 3852 as IPv6 link-local multicast UDP messages into ACP virtual 3853 interfaces, but instead into ACP GRASP virtual interfaces, that are 3854 layered on top of ACP virtual interfaces to add TCP reliability to 3855 link-local multicast GRASP messages. Nevertheless, these ACP GRASP 3856 virtual interfaces perform the same replication of message and, 3857 therefore, result in the same impact on flooding. See Section 6.8.2 3858 for more details. 3860 RPL does support operations and correct routing table construction 3861 across non-broadcast multi-access (NBMA) subnets. This is common 3862 when using many radio technologies. When such NBMA subnets are used, 3863 they MUST NOT be represented as ACP multi-access virtual interfaces 3864 because the replication of IPv6 link-local multicast messages will 3865 not reach all NBMA subnet neighbors. In result, GRASP message 3866 flooding would fail. Instead, each ACP secure channel across such an 3867 interface MUST be represented as a ACP point-to-point virtual 3868 interface. See also Appendix A.10.4. 3870 Care needs to be taken when creating multi-access ACP virtual 3871 interfaces across ACP secure channels between ACP nodes in different 3872 domains or routing subdomains. If for example future inter-domain 3873 ACP policies are defined as "peer-to-peer" policies, it is easier to 3874 create ACP point-to-point virtual interfaces for these inter-domain 3875 secure channels. 3877 7. ACP support on L2 switches/ports (Normative) 3879 7.1. Why (Benefits of ACP on L2 switches) 3881 ANrtr1 ------ ANswitch1 --- ANswitch2 ------- ANrtr2 3882 .../ \ \ ... 3883 ANrtrM ------ \ ------- ANrtrN 3884 ANswitchM ... 3886 Figure 14: Topology with L2 ACP switches 3888 Consider a large L2 LAN with ANrtr1...ANrtrN connected via some 3889 topology of L2 switches. Examples include large enterprise campus 3890 networks with an L2 core, IoT networks or broadband aggregation 3891 networks which often have even a multi-level L2 switched topology. 3893 If the discovery protocol used for the ACP is operating at the subnet 3894 level, every ACP router will see all other ACP routers on the LAN as 3895 neighbors and a full mesh of ACP channels will be built. If some or 3896 all of the AN switches are autonomic with the same discovery 3897 protocol, then the full mesh would include those switches as well. 3899 A full mesh of ACP connections can create fundamental scale 3900 challenges. The number of security associations of the secure 3901 channel protocols will likely not scale arbitrarily, especially when 3902 they leverage platform accelerated encryption/decryption. Likewise, 3903 any other ACP operations (such as routing) needs to scale to the 3904 number of direct ACP neighbors. An ACP router with just 4 physical 3905 interfaces might be deployed into a LAN with hundreds of neighbors 3906 connected via switches. Introducing such a new unpredictable scaling 3907 factor requirement makes it harder to support the ACP on arbitrary 3908 platforms and in arbitrary deployments. 3910 Predictable scaling requirements for ACP neighbors can most easily be 3911 achieved if in topologies such as these, ACP capable L2 switches can 3912 ensure that discovery messages terminate on them so that neighboring 3913 ACP routers and switches will only find the physically connected ACP 3914 L2 switches as their candidate ACP neighbors. With such a discovery 3915 mechanism in place, the ACP and its security associations will only 3916 need to scale to the number of physical interfaces instead of a 3917 potentially much larger number of "LAN-connected" neighbors. And the 3918 ACP topology will follow directly the physical topology, something 3919 which can then also be leveraged in management operations or by ASAs. 3921 In the example above, consider ANswitch1 and ANswitchM are ACP 3922 capable, and ANswitch2 is not ACP capable. The desired ACP topology 3923 is that ANrtr1 and ANrtrM only have an ACP connection to ANswitch1, 3924 and that ANswitch1, ANrtr2, ANrtrN have a full mesh of ACP connection 3925 amongst each other. ANswitch1 also has an ACP connection with 3926 ANswitchM and ANswitchM has ACP connections to anything else behind 3927 it. 3929 7.2. How (per L2 port DULL GRASP) 3931 To support ACP on L2 switches or L2 switched ports of an L3 device, 3932 it is necessary to make those L2 ports look like L3 interfaces for 3933 the ACP implementation. This primarily involves the creation of a 3934 separate DULL GRASP instance/domain on every such L2 port. Because 3935 GRASP has a dedicated link-local IPv6 multicast address 3936 (ALL_GRASP_NEIGHBORS), it is sufficient that all packets for this 3937 address are being extracted at the port level and passed to that DULL 3938 GRASP instance. Likewise the IPv6 link-local multicast packets sent 3939 by that DULL GRASP instance need to be sent only towards the L2 port 3940 for this DULL GRASP instance (instead of being flooded across all 3941 ports of the VLAN to which the port belongs). 3943 When Ports/Interfaces across which the ACP is expected to operate in 3944 an ACP-aware L2-switch or L2/L3-switch/router are L2-bridged, packets 3945 for the ALL_GRASP_NEIGHBORS multicast address MUST never be forward 3946 between these ports. If MLD snooping is used, it MUST be prohibited 3947 from bridging packets for the ALL_GRASP_NEIGHBORS IPv6 multicast 3948 address. 3950 On hybrid L2/L3 switches, multiple L2 ports are assigned to a single 3951 L3 VLAN interface. With the aforementioned changes for DULL GRASP, 3952 ACP can simply operate on the L3 VLAN interfaces, so no further 3953 (hardware) forwarding changes are required to make ACP operate on L2 3954 ports. This is possible because the ACP secure channel protocols 3955 only use link-local IPv6 unicast packets, and these packets will be 3956 sent to the correct L2 port towards the peer by the VLAN logic of the 3957 device. 3959 This is sufficient when p2p ACP virtual interfaces are established to 3960 every ACP peer. When it is desired to create multi-access ACP 3961 virtual interfaces (see Section 6.12.5.2.2), it is REQIURED not to 3962 coalesce all the ACP secure channels on the same L3 VLAN interface, 3963 but only all those on the same L2 port. 3965 If VLAN tagging is used, then all the above described logic only 3966 applies to untagged GRASP packets. For the purpose of ACP neighbor 3967 discovery via GRASP, no VLAN tagged packets SHOULD be sent or 3968 received. In a hybrid L2/L3 switch, each VLAN would therefore only 3969 create ACP adjacencies across those ports where the VLAN is carried 3970 untagged. 3972 In result, the simple logic is that ACP secure channels would operate 3973 over the same L3 interfaces that present a single flat bridged 3974 network across all routers, but because DULL GRASP is separated on a 3975 per-port basis, no full mesh of ACP secure channels is created, but 3976 only per-port ACP secure channels to per-port L2-adjacent ACP node 3977 neighbors. 3979 For example, in the above picture, ANswitch1 would run separate DULL 3980 GRASP instances on its ports to ANrtr1, ANswitch2 and ANswitchI, even 3981 though all those three ports may be in the data plane in the same 3982 (V)LAN and perform L2 switching between these ports, ANswitch1 would 3983 perform ACP L3 routing between them. 3985 The description in the previous paragraph was specifically meant to 3986 illustrate that on hybrid L3/L2 devices that are common in 3987 enterprise, IoT and broadband aggregation, there is only the GRASP 3988 packet extraction (by Ethernet address) and GRASP link-local 3989 multicast per L2-port packet injection that has to consider L2 ports 3990 at the hardware forwarding level. The remaining operations are 3991 purely ACP control plane and setup of secure channels across the L3 3992 interface. This hopefully makes support for per-L2 port ACP on those 3993 hybrid devices easy. 3995 In devices without such a mix of L2 port/interfaces and L3 interfaces 3996 (to terminate any transport layer connections), implementation 3997 details will differ. Logically most simply every L2 port is 3998 considered and used as a separate L3 subnet for all ACP operations. 3999 The fact that the ACP only requires IPv6 link-local unicast and 4000 multicast should make support for it on any type of L2 devices as 4001 simple as possible. 4003 A generic issue with ACP in L2 switched networks is the interaction 4004 with the Spanning Tree Protocol. Without further L2 enhancements, 4005 the ACP would run only across the active STP topology and the ACP 4006 would be interrupted and re-converge with STP changes. Ideally, ACP 4007 peering SHOULD be built also across ports that are blocked in STP so 4008 that the ACP does not depend on STP and can continue to run 4009 unaffected across STP topology changes, where re-convergence can be 4010 quite slow. The above described simple implementation options are 4011 not sufficient to achieve this. 4013 8. Support for Non-ACP Components (Normative) 4015 8.1. ACP Connect 4017 8.1.1. Non-ACP Controller / NMS system 4019 The Autonomic Control Plane can be used by management systems, such 4020 as controllers or network management system (NMS) hosts (henceforth 4021 called simply "NMS hosts"), to connect to devices (or other type of 4022 nodes) through it. For this, an NMS host needs to have access to the 4023 ACP. The ACP is a self-protecting overlay network, which allows by 4024 default access only to trusted, autonomic systems. Therefore, a 4025 traditional, non-ACP NMS system does not have access to the ACP by 4026 default, such as any other external node. 4028 If the NMS host is not autonomic, i.e., it does not support autonomic 4029 negotiation of the ACP, then it can be brought into the ACP by 4030 explicit configuration. To support connections to adjacent non-ACP 4031 nodes, an ACP node SHOULD support "ACP connect" (sometimes also 4032 called "autonomic connect"): 4034 "ACP connect" is an interface level configured workaround for 4035 connection of trusted non-ACP nodes to the ACP. The ACP node on 4036 which ACP connect is configured is called an "ACP edge node". With 4037 ACP connect, the ACP is accessible from those non-ACP nodes (such as 4038 NOC systems) on such an interface without those non-ACP nodes having 4039 to support any ACP discovery or ACP channel setup. This is also 4040 called "native" access to the ACP because to those NOC systems the 4041 interface looks like a normal network interface (without any 4042 encryption/novel-signaling). 4044 Data-Plane "native" (no ACP) 4045 . 4046 +--------+ +----------------+ . +-------------+ 4047 | ACP | |ACP Edge Node | . | | 4048 | Node | | | v | | 4049 | |-------|...[ACP VRF]....+-----------------| |+ 4050 | | ^ |. | | NOC Device || 4051 | | . | .[Data-Plane]..+-----------------| "NMS hosts" || 4052 | | . | [ ] | . ^ | || 4053 +--------+ . +----------------+ . . +-------------+| 4054 . . . +-------------+ 4055 . . . 4056 Data-Plane "native" . ACP "native" (unencrypted) 4057 + ACP auto-negotiated . "ACP connect subnet" 4058 and encrypted . 4059 ACP connect interface 4060 e.g., "VRF ACP native" (config) 4062 Figure 15: ACP connect 4064 ACP connect has security consequences: All systems and processes 4065 connected via ACP connect have access to all ACP nodes on the entire 4066 ACP, without further authentication. Thus, the ACP connect interface 4067 and NOC systems connected to it needs to be physically controlled/ 4068 secured. For this reason the mechanisms described here do explicitly 4069 not include options to allow for a non-ACP router to be connected 4070 across an ACP connect interface and addresses behind such a router 4071 routed inside the ACP. 4073 An ACP connect interface provides exclusively access to only the ACP. 4074 This is likely insufficient for many NMS hosts. Instead, they would 4075 require a second "Data-Plane" interface outside the ACP for 4076 connections between the NMS host and administrators, or Internet 4077 based services, or for direct access to the Data-Plane. The document 4078 "Using Autonomic Control Plane for Stable Connectivity of Network 4079 OAM" [RFC8368] explains in more detail how the ACP can be integrated 4080 in a mixed NOC environment. 4082 An ACP connect interface SHOULD use an IPv6 address/prefix from the 4083 ACP Manual Addressing Sub-Scheme (Section 6.10.4), letting the 4084 operator configure for example only the Subnet-ID and having the node 4085 automatically assign the remaining part of the prefix/address. It 4086 SHOULD NOT use a prefix that is also routed outside the ACP so that 4087 the addresses clearly indicate whether it is used inside the ACP or 4088 not. 4090 The prefix of ACP connect subnets MUST be distributed by the ACP edge 4091 node into the ACP routing protocol RPL. The NMS hosts MUST connect 4092 to prefixes in the ACP routing table via its ACP connect interface. 4093 In the simple case where the ACP uses only one ULA prefix and all ACP 4094 connect subnets have prefixes covered by that ULA prefix, NMS hosts 4095 can rely on [RFC6724] to determine longest match prefix routes 4096 towards its different interfaces, ACP and Data-Plane. With RFC6724, 4097 The NMS host will select the ACP connect interface for all addresses 4098 in the ACP because any ACP destination address is longest matched by 4099 the address on the ACP connect interface. If the NMS hosts ACP 4100 connect interface uses another prefix or if the ACP uses multiple ULA 4101 prefixes, then the NMS hosts require (static) routes towards the ACP 4102 interface for these prefixes. 4104 When an ACP Edge node receives a packet from an ACP connect 4105 interface, the ACP Edge node MUST only forward the packet into the 4106 ACP if the packet has an IPv6 source address from that interface. 4107 This is sometimes called "RPF filtering". This MAY be changed 4108 through administrative measures. 4110 To limit the security impact of ACP connect, nodes supporting it 4111 SHOULD implement a security mechanism to allow configuration/use of 4112 ACP connect interfaces only on nodes explicitly targeted to be 4113 deployed with it (those in physically secure locations such as a 4114 NOC). For example, the registrar could disable the ability to enable 4115 ACP connect on devices during enrollment and that property could only 4116 be changed through re-enrollment. See also Appendix A.10.5. 4118 ACP Edge nodes SHOULD have a configurable option to filter packets 4119 with RPI headers (xsee Section 6.11.1.13 across an ACP connect 4120 interface. These headers are outside the scope of the RPL profile in 4121 this specification but may be used in future extensions of this 4122 specification. 4124 8.1.2. Software Components 4126 The previous section assumed that ACP Edge node and NOC devices are 4127 separate physical devices and the ACP connect interface is a physical 4128 network connection. This section discusses the implication when 4129 these components are instead software components running on a single 4130 physical device. 4132 The ACP connect mechanism can not only be used to connect physically 4133 external systems (NMS hosts) to the ACP but also other applications, 4134 containers or virtual machines. In fact, one possible way to 4135 eliminate the security issue of the external ACP connect interface is 4136 to collocate an ACP edge node and an NMS host by making one a virtual 4137 machine or container inside the other; and therefore converting the 4138 unprotected external ACP subnet into an internal virtual subnet in a 4139 single device. This would ultimately result in a fully ACP enabled 4140 NMS host with minimum impact to the NMS hosts software architecture. 4141 This approach is not limited to NMS hosts but could equally be 4142 applied to devices consisting of one or more VNF (virtual network 4143 functions): An internal virtual subnet connecting out-of-band 4144 management interfaces of the VNFs to an ACP edge router VNF. 4146 The core requirement is that the software components need to have a 4147 network stack that permits access to the ACP and optionally also the 4148 Data-Plane. Like in the physical setup for NMS hosts this can be 4149 realized via two internal virtual subnets. One that is connecting to 4150 the ACP (which could be a container or virtual machine by itself), 4151 and one (or more) connecting into the Data-Plane. 4153 This "internal" use of ACP connect approach should not considered to 4154 be a "workaround" because in this case it is possible to build a 4155 correct security model: It is not necessary to rely on unprovable 4156 external physical security mechanisms as in the case of external NMS 4157 hosts. Instead, the orchestration of the ACP, the virtual subnets 4158 and the software components can be done by trusted software that 4159 could be considered to be part of the ANI (or even an extended ACP). 4160 This software component is responsible for ensuring that only trusted 4161 software components will get access to that virtual subnet and that 4162 only even more trusted software components will get access to both 4163 the ACP virtual subnet and the Data-Plane (because those ACP users 4164 could leak traffic between ACP and Data-Plane). This trust could be 4165 established for example through cryptographic means such as signed 4166 software packages. 4168 8.1.3. Auto Configuration 4170 ACP edge nodes, NMS hosts and software components that as described 4171 in the previous section are meant to be composed via virtual 4172 interfaces SHOULD support on the ACP connect subnet StateLess Address 4173 Autoconfiguration (SLAAC - [RFC4862]) and route auto configuration 4174 according to [RFC4191]. 4176 The ACP edge node acts as the router on the ACP connect subnet, 4177 providing the (auto-)configured prefix for the ACP connect subnet to 4178 NMS hosts and/or software components. The ACP edge node uses route 4179 prefix option of RFC4191 to announce the default route (::/) with a 4180 lifetime of 0 and aggregated prefixes for routes in the ACP routing 4181 table with normal lifetimes. This will ensure that the ACP edge node 4182 does not become a default router, but that the NMS hosts and software 4183 components will route the prefixes used in the ACP to the ACP edge 4184 node. 4186 Aggregated prefix means that the ACP edge node needs to only announce 4187 the /48 ULA prefixes used in the ACP but none of the actual /64 4188 (Manual Addressing Sub-Scheme), /127 (ACP Zone Addressing Sub- 4189 Scheme), /112 or /120 (Vlong Addressing Sub-Scheme) routes of actual 4190 ACP nodes. If ACP interfaces are configured with non ULA prefixes, 4191 then those prefixes cannot be aggregated without further configured 4192 policy on the ACP edge node. This explains the above recommendation 4193 to use ACP ULA prefix covered prefixes for ACP connect interfaces: 4194 They allow for a shorter list of prefixes to be signaled via RFC4191 4195 to NMS hosts and software components. 4197 The ACP edge nodes that have a Vlong ACP address MAY allocate a 4198 subset of their /112 or /120 address prefix to ACP connect 4199 interface(s) to eliminate the need to non-autonomically configure/ 4200 provision the address prefixes for such ACP connect interfaces. 4202 8.1.4. Combined ACP/Data-Plane Interface (VRF Select) 4204 Combined ACP and Data-Plane interface 4205 . 4206 +--------+ +--------------------+ . +--------------+ 4207 | ACP | |ACP Edge No | . | NMS Host(s) | 4208 | Node | | | . | / Software | 4209 | | | [ACP ]. | . | |+ 4210 | | | .[VRF ] .[VRF ] | v | "ACP address"|| 4211 | +-------+. .[Select].+--------+ "Date Plane || 4212 | | ^ | .[Data ]. | | Address(es)"|| 4213 | | . | [Plane] | | || 4214 | | . | [ ] | +--------------+| 4215 +--------+ . +--------------------+ +--------------+ 4216 . 4217 Data-Plane "native" and + ACP auto-negotiated/encrypted 4219 Figure 16: VRF select 4221 Using two physical and/or virtual subnets (and therefore interfaces) 4222 into NMS Hosts (as per Section 8.1.1) or Software (as per 4223 Section 8.1.2) may be seen as additional complexity, for example with 4224 legacy NMS Hosts that support only one IP interface. 4226 To provide a single subnet into both ACP and Data-Plane, the ACP Edge 4227 node needs to de-multiplex packets from NMS hosts into ACP VRF and 4228 Data-Plane. This is sometimes called "VRF select". If the ACP VRF 4229 has no overlapping IPv6 addresses with the Data-Plane (it should have 4230 no overlapping addresses), then this function can use the IPv6 4231 Destination address. The problem is Source Address Selection on the 4232 NMS Host(s) according to RFC6724. 4234 Consider the simple case: The ACP uses only one ULA prefix, the ACP 4235 IPv6 prefix for the Combined ACP and Data-Plane interface is covered 4236 by that ULA prefix. The ACP edge node announces both the ACP IPv6 4237 prefix and one (or more) prefixes for the Data-Plane. Without 4238 further policy configurations on the NMS Host(s), it may select its 4239 ACP address as a source address for Data-Plane ULA destinations 4240 because of Rule 8 of RFC6724. The ACP edge node can pass on the 4241 packet to the Data-Plane, but the ACP source address should not be 4242 used for Data-Plane traffic, and return traffic may fail. 4244 If the ACP carries multiple ULA prefixes or non-ULA ACP connect 4245 prefixes, then the correct source address selection becomes even more 4246 problematic. 4248 With separate ACP connect and Data-Plane subnets and RFC4191 prefix 4249 announcements that are to be routed across the ACP connect interface, 4250 RFC6724 source address selection Rule 5 (use address of outgoing 4251 interface) will be used, so that above problems do not occur, even in 4252 more complex cases of multiple ULA and non-ULA prefixes in the ACP 4253 routing table. 4255 To achieve the same behavior with a Combined ACP and Data-Plane 4256 interface, the ACP Edge Node needs to behave as two separate routers 4257 on the interface: One link-local IPv6 address/router for its ACP 4258 reachability, and one link-local IPv6 address/router for its Data- 4259 Plane reachability. The Router Advertisements for both are as 4260 described above (Section 8.1.3): For the ACP, the ACP prefix is 4261 announced together with RFC4191 option for the prefixes routed across 4262 the ACP and lifetime=0 to disqualify this next-hop as a default 4263 router. For the Data-Plane, the Data-Plane prefix(es) are announced 4264 together with whatever dafault router parameters are used for the 4265 Data-Plane. 4267 In result, RFC6724 source address selection Rule 5.5 may result in 4268 the same correct source address selection behavior of NMS hosts 4269 without further configuration on it as the separate ACP connect and 4270 Data-Plane interfaces. As described in the text for Rule 5.5, this 4271 is only a MAY, because IPv6 hosts are not required to track next-hop 4272 information. If an NMS Host does not do this, then separate ACP 4273 connect and Data-Plane interfaces are the preferable method of 4274 attachment. Hosts implementing [RFC8028] should (instead of may) 4275 implement [RFC6724] Rule 5.5, so it is preferred for hosts to support 4276 [RFC8028]. 4278 ACP edge nodes MAY support the Combined ACP and Data-Plane interface. 4280 8.1.5. Use of GRASP 4282 GRASP can and should be possible to use across ACP connect 4283 interfaces, especially in the architectural correct solution when it 4284 is used as a mechanism to connect Software (e.g., ASA or legacy NMS 4285 applications) to the ACP. 4287 Given how the ACP is the security and transport substrate for GRASP, 4288 the requirements for devices connected via ACP connect is that those 4289 are equivalently (if not better) secured against attacks and run only 4290 software that is equally (if not better) protected, known (or 4291 trusted) not to be malicious and accordingly designed to isolate 4292 access to the ACP against external equipment. 4294 The difference in security is that cryptographic security of the ACP 4295 secure channel is replaced by required physical security of the 4296 network connection between an ACP edge node and the NMS or other host 4297 reachable via the ACP connect interface. Node integrity too is 4298 expected to be easier because the ACP connect node, the ACP connect 4299 link and the nodes connecting to it must be in a contiguous secure 4300 environment, hence assuming there can be no physical attack against 4301 the devices. 4303 When using "Combined ACP and Data-Plane Interfaces", care hasa to be 4304 taken that only GRASP messages intended for the ACP GRASP domain 4305 received from Software or NMS Hosts are forwarded by ACP edge nodes. 4306 Currently there is no definition for a GRASP security and transport 4307 substrate beside the ACP, so there is no definition how such 4308 Software/NMS Host could participate in two separate GRASP Domains 4309 across the same subnet (ACP and Data-Plane domains). At current it 4310 is assumed that all GRASP packets on a Combined ACP and Data-Plane 4311 interface belong to the GRASP ACP Domain. They SHOULD all use the 4312 ACP IPv6 addresses of the Software/NMS Hosts. The link-local IPv6 4313 addresses of Software/NMS Hosts (used for GRASP M_DISCOVERY and 4314 M_FLOOD messages) are also assumed to belong to the ACP address 4315 space. 4317 8.2. Connecting ACP islands over Non-ACP L3 networks (Remote ACP 4318 neighbors) 4320 Not all nodes in a network may support the ACP. If non-ACP Layer-2 4321 devices are between ACP nodes, the ACP will work across it since it 4322 is IP based. However, the autonomic discovery of ACP neighbors via 4323 DULL GRASP is only intended to work across L2 connections, so it is 4324 not sufficient to autonomically create ACP connections across non-ACP 4325 Layer-3 devices. 4327 8.2.1. Configured Remote ACP neighbor 4329 On the ACP node, remote ACP neighbors are configured explicitly. The 4330 parameters of such a "connection" are described in the following 4331 ABNF. 4333 connection = [ method , local-addr, remote-addr, ?pmtu ] 4334 method = [ "IKEv2" , ?port ] 4335 method //= [ "DTLS", port ] 4336 local-addr = [ address , ?vrf ] 4337 remote-addr = [ address ] 4338 address = ("any" | ipv4-address | ipv6-address ) 4339 vrf = tstr ; Name of a VRF on this node with local-address 4341 Figure 17: Parameters for remote ACP neighbors 4343 Explicit configuration of a remote-peer according to this ABNF 4344 provides all the information to build a secure channel without 4345 requiring a tunnel to that peer and running DULL GRASP inside of it. 4347 The configuration includes the parameters otherwise signaled via DULL 4348 GRASP: local address, remote (peer) locator and method. The 4349 differences over DULL GRASP local neighbor discovery and secure 4350 channel creation are as follows: 4352 o The local and remote address can be IPv4 or IPv6 and are typically 4353 global scope addresses. 4355 o The VRF across which the connection is built (and in which local- 4356 addr exists) can to be specified. If vrf is not specified, it is 4357 the default VRF on the node. In DULL GRASP the VRF is implied by 4358 the interface across which DULL GRASP operates. 4360 o If local address is "any", the local address used when initiating 4361 a secure channel connection is decided by source address selection 4362 ([RFC6724] for IPv6). As a responder, the connection listens on 4363 all addresses of the node in the selected VRF. 4365 o Configuration of port is only required for methods where no 4366 defaults exist (e.g., "DTLS"). 4368 o If remote address is "any", the connection is only a responder. 4369 It is a "hub" that can be used by multiple remote peers to connect 4370 simultaneously - without having to know or configure their 4371 addresses. Example: Hub site for remote "spoke" sites reachable 4372 over the Internet. 4374 o Pmtu should be configurable to overcome issues/limitations of Path 4375 MTU Discovery (PMTUD). 4377 o IKEv2/IPsec to remote peers should support the optional NAT 4378 Traversal (NAT-T) procedures. 4380 8.2.2. Tunneled Remote ACP Neighbor 4382 An IPinIP, GRE or other form of pre-existing tunnel is configured 4383 between two remote ACP peers and the virtual interfaces representing 4384 the tunnel are configured for "ACP enable". This will enable IPv6 4385 link local addresses and DULL on this tunnel. In result, the tunnel 4386 is used for normal "L2 adjacent" candidate ACP neighbor discovery 4387 with DULL and secure channel setup procedures described in this 4388 document. 4390 Tunneled Remote ACP Neighbor requires two encapsulations: the 4391 configured tunnel and the secure channel inside of that tunnel. This 4392 makes it in general less desirable than Configured Remote ACP 4393 Neighbor. Benefits of tunnels are that it may be easier to implement 4394 because there is no change to the ACP functionality - just running it 4395 over a virtual (tunnel) interface instead of only native interfaces. 4396 The tunnel itself may also provide PMTUD while the secure channel 4397 method may not. Or the tunnel mechanism is permitted/possible 4398 through some firewall while the secure channel method may not. 4400 8.2.3. Summary 4402 Configured/Tunneled Remote ACP neighbors are less "indestructible" 4403 than L2 adjacent ACP neighbors based on link local addressing, since 4404 they depend on more correct Data-Plane operations, such as routing 4405 and global addressing. 4407 Nevertheless, these options may be crucial to incrementally deploy 4408 the ACP, especially if it is meant to connect islands across the 4409 Internet. Implementations SHOULD support at least Tunneled Remote 4410 ACP Neighbors via GRE tunnels - which is likely the most common 4411 router-to-router tunneling protocol in use today. 4413 9. ACP Operations (Informative) 4415 The following sections document important operational aspects of the 4416 ACP. They are not normative because they do not impact the 4417 interoperability between components of the ACP, but they include 4418 recommendations/requirements for the internal operational model 4419 beneficial or necessary to achieve the desired use-case benefits of 4420 the ACP (see Section 3). 4422 o Section 9.1 describes recommended operator diagnostics 4423 capabilities of ACP nodes. The have been derived from diagnostic 4424 of a commercially available ACP implementation. 4426 o Section 9.2 describes high level how an ACP registrar needs to 4427 work, what its configuration parameters are and specific issues 4428 impacting the choices of deployment design due to renewal and 4429 revocation issues. It describes a model where ACP Registrars have 4430 their own sub-CA to provide the most distributed deployment option 4431 for ACP Registrars, and it describes considerations for 4432 centralized policy control of ACP Registrar operations. 4434 o Section 9.3 describes suggested ACP node behavior and operational 4435 interfaces (configuration options) to manage the ACP in so-called 4436 greenfield devices (previously unconfigured) and brownfield 4437 devices (preconfigured). 4439 The recommendations and suggestions of this chapter were derived from 4440 operational experience gained with a commercially available pre- 4441 standard ACP implementation. 4443 9.1. ACP (and BRSKI) Diagnostics 4445 Even though ACP and ANI in general are taking out many manual 4446 configuration mistakes through their automation, it is important to 4447 provide good diagnostics for them. 4449 The basic diagnostics is support of (yang) data models representing 4450 the complete (auto-)configuration and operational state of all 4451 components: BRSKI, GRASP, ACP and the infrastructure used by them: 4452 TLS/DTLS, IPsec, certificates, TA, time, VRF and so on. While 4453 necessary, this is not sufficient: 4455 Simply representing the state of components does not allow operators 4456 to quickly take action - unless they do understand how to interpret 4457 the data, and that can mean a requirement for deep understanding of 4458 all components and how they interact in the ACP/ANI. 4460 Diagnostic supports should help to quickly answer the questions 4461 operators are expected to ask, such as "is the ACP working 4462 correctly?", or "why is there no ACP connection to a known 4463 neighboring node?" 4465 In current network management approaches, the logic to answer these 4466 questions is most often built as centralized diagnostics software 4467 that leverages the above mentioned data models. While this approach 4468 is feasible for components utilizing the ANI, it is not sufficient to 4469 diagnose the ANI itself: 4471 o Developing the logic to identify common issues requires 4472 operational experience with the components of the ANI. Letting 4473 each management system define its own analysis is inefficient. 4475 o When the ANI is not operating correctly, it may not be possible to 4476 run diagnostics from remote because of missing connectivity. The 4477 ANI should therefore have diagnostic capabilities available 4478 locally on the nodes themselves. 4480 o Certain operations are difficult or impossible to monitor in real- 4481 time, such as initial bootstrap issues in a network location where 4482 no capabilities exist to attach local diagnostics. Therefore it 4483 is important to also define means of capturing (logging) 4484 diagnostics locally for later retrieval. Ideally, these captures 4485 are also non-volatile so that they can survive extended power-off 4486 conditions - for example when a device that fails to be brought up 4487 zero-touch is being sent back for diagnostics at a more 4488 appropriate location. 4490 The most simple form of diagnostics answering questions such as the 4491 above is to represent the relevant information sequentially in 4492 dependency order, so that the first non-expected/non-operational item 4493 is the most likely root cause. Or just log/highlight that item. For 4494 example: 4496 Q: Is ACP operational to accept neighbor connections: 4498 o Check if any potentially necessary configuration to make ACP/ANI 4499 operational are correct (see Section 9.3 for a discussion of such 4500 commands). 4502 o Does the system time look reasonable, or could it be the default 4503 system time after clock chip battery failure (certificate checks 4504 depend on reasonable notion of time). 4506 o Does the node have keying material - domain certificate, TA 4507 certificates, .... 4509 o If no keying material and ANI is supported/enabled, check the 4510 state of BRSKI (not detailed in this example). 4512 o Check the validity of the domain certificate: 4514 * Does the certificate validate against the TA? 4516 * Has it been revoked? 4517 * Was the last scheduled attempt to retrieve a CRL successful 4518 (e.g., do we know that our CRL information is up to date). 4520 * Is the certificate valid: validity start time in the past, 4521 expiration time in the future? 4523 * Does the certificate have a correctly formatted acp-node-name 4524 field? 4526 o Was the ACP VRF successfully created? 4528 o Is ACP enabled on one or more interfaces that are up and running? 4530 If all this looks good, the ACP should be running locally "fine" - 4531 but we did not check any ACP neighbor relationships. 4533 Question: why does the node not create a working ACP connection to a 4534 neighbor on an interface? 4536 o Is the interface physically up? Does it have an IPv6 link-local 4537 address? 4539 o Is it enabled for ACP? 4541 o Do we successfully send DULL GRASP messages to the interface (link 4542 layer errors)? 4544 o Do we receive DULL GRASP messages on the interface? If not, some 4545 intervening L2 equipment performing bad MLD snooping could have 4546 caused problems. Provide e.g., diagnostics of the MLD querier 4547 IPv6 and MAC address. 4549 o Do we see the ACP objective in any DULL GRASP message from that 4550 interface? Diagnose the supported secure channel methods. 4552 o Do we know the MAC address of the neighbor with the ACP objective? 4553 If not, diagnose SLAAC/ND state. 4555 o When did we last attempt to build an ACP secure channel to the 4556 neighbor? 4558 o If it failed, why: 4560 * Did the neighbor close the connection on us or did we close the 4561 connection on it because the domain certificate membership 4562 failed? 4564 * If the neighbor closed the connection on us, provide any error 4565 diagnostics from the secure channel protocol. 4567 * If we failed the attempt, display our local reason: 4569 + There was no common secure channel protocol supported by the 4570 two neighbors (this could not happen on nodes supporting 4571 this specification because it mandates common support for 4572 IPsec). 4574 + The ACP domain certificate membership check (Section 6.1.3) 4575 fails: 4577 - The neighbor's certificate is not signed directly or 4578 indirectly by one of the nodes TA. Provide diagnostics 4579 which TA it has (can identify whom the device belongs 4580 to). 4582 - The neighbor's certificate does not have the same domain 4583 (or no domain at all). Diagnose domain-name and 4584 potentially other cert info. 4586 - The neighbor's certificate has been revoked or could not 4587 be authenticated by OCSP. 4589 - The neighbor's certificate has expired - or is not yet 4590 valid. 4592 * Any other connection issues in e.g., IKEv2 / IPsec, DTLS?. 4594 Question: Is the ACP operating correctly across its secure channels? 4596 o Are there one or more active ACP neighbors with secure channels? 4598 o Is the RPL routing protocol for the ACP running? 4600 o Is there a default route to the root in the ACP routing table? 4602 o Is there for each direct ACP neighbor not reachable over the ACP 4603 virtual interface to the root a route in the ACP routing table? 4605 o Is ACP GRASP running? 4607 o Is at least one SRV.est objective cached (to support certificate 4608 renewal)? 4610 o Is there at least one BRSKI registrar objective cached (in case 4611 BRSKI is supported) 4613 o Is BRSKI proxy operating normally on all interfaces where ACP is 4614 operating? 4616 o ... 4618 These lists are not necessarily complete, but illustrate the 4619 principle and show that there are variety of issues ranging from 4620 normal operational causes (a neighbor in another ACP domain) over 4621 problems in the credentials management (certificate lifetimes), 4622 explicit security actions (revocation) or unexpected connectivity 4623 issues (intervening L2 equipment). 4625 The items so far are illustrating how the ANI operations can be 4626 diagnosed with passive observation of the operational state of its 4627 components including historic/cached/counted events. This is not 4628 necessary sufficient to provide good enough diagnostics overall: 4630 The components of ACP and BRSKI are designed with security in mind 4631 but they do not attempt to provide diagnostics for building the 4632 network itself. Consider two examples: 4634 1. BRSKI does not allow for a neighboring device to identify the 4635 pledges IDevID certificate. Only the selected BRSKI registrar 4636 can do this, but it may be difficult to disseminate information 4637 about undesired pledges from those BRSKI registrars to locations/ 4638 nodes where information about those pledges is desired. 4640 2. LLDP disseminates information about nodes to their immediate 4641 neighbors, such as node model/type/software and interface name/ 4642 number of the connection. This information is often helpful or 4643 even necessary in network diagnostics. It can equally considered 4644 to be too insecure to make this information available unprotected 4645 to all possible neighbors. 4647 An "interested adjacent party" can always determine the IDevID 4648 certificate of a BRSKI pledge by behaving like a BRSKI proxy/ 4649 registrar. Therefore the IDevID certificate of a BRSKI pledge is not 4650 meant to be protected - it just has to be queried and is not signaled 4651 unsolicited (as it would be in LLDP) so that other observers on the 4652 same subnet can determine who is an "interested adjacent party". 4654 9.1.1. Secure Channel Peer diagnostics 4656 When using mutual certificate authentication, the TA certificate is 4657 not required to be signalled explicitly because its hash is 4658 sufficient for certificate chain validation. In the case of ACP 4659 secure channel setup this leads to limited diagnostics when 4660 authentication fails because of TA mismatch. For this reason, 4661 Section 6.7.2 recommends to also include the TA certificate in the 4662 secure channel signalling. This should be possible to do without 4663 protocol modifications in the security association protocols used by 4664 the ACP. For example, while [RFC7296] does not mention this, it also 4665 does not prohibit it. 4667 One common deployment use case where the diagnostic through the 4668 signalled TA of a candidate peer is very helpfull are multi-tenant 4669 environments such as office buildings, where different tenants run 4670 their own networks and ACPs. Each tenant is given supposedly 4671 disjoint L2 connectivity through the building infrastructure. In 4672 these environments there are various common errors through which a 4673 device may receive L2 connectivity into the wrong tenants network. 4675 While the ACP itself is not impact by this, the Data-Plane to be 4676 built later may be impacted. Therefore it is important to be able to 4677 diagnose such undesirable connectivity from the ACP so that any 4678 autonomic or non-autonomic mechanisms to configure the Data-Plane can 4679 accordingly treat such interfaces. The information in the TA of the 4680 peer can then ease troubleshooting of such issues. 4682 Another example case is the intended or accidental re-activation of 4683 equipment whose TA certificate has long expired, such as redundant 4684 gear taken from storage after years. Potentially without following 4685 the correct process set up for such cases. 4687 A third example case is when in a mergers&aquisition case ACP nodes 4688 have not been correctly provisioned with the mutual TA of previously 4689 disjoint ACP. This is assuming that the ACP domain names where 4690 already aligned so that the ACP domain membership check is only 4691 failing on the TA. 4693 A fourth example case is when multiple registrars where set up for 4694 the same ACP but without correctly setting up the same TA. For 4695 example when registrars support to also be CA themselves but are 4696 misconfigured to become TA instead of intermediate CA. 4698 9.2. ACP Registrars 4700 As described in Section 6.10.7, the ACP addressing mechanism is 4701 designed to enable lightweight, distributed and uncoordinated ACP 4702 registrars that are providing ACP address prefixes to candidate ACP 4703 nodes by enrolling them with an ACP domain certificate into an ACP 4704 domain via any appropriate mechanism/protocol, automated or not. 4706 This section discusses informatively more details and options for ACP 4707 registrars. 4709 9.2.1. Registrar interactions 4711 This section summarizes and discusses the interactions with other 4712 entities required by an ACP registrar. 4714 In a simple instance of an ACP network, no central NOC component 4715 beside a TA is required. Typically, this is a root CA. One or more 4716 uncoordinated acting ACP registrar can be set up, performing the 4717 following interactions: 4719 To orchestrate enrolling a candidate ACP node autonomically, the ACP 4720 registrar can rely on the ACP and use Proxies to reach the candidate 4721 ACP node, therefore allowing minimum pre-existing (auto-)configured 4722 network services on the candidate ACP node. BRSKI defines the BRSKI 4723 proxy, a design that can be adopted for various protocols that 4724 Pledges/candidate ACP nodes could want to use, for example BRSKI over 4725 CoAP (Constrained Application Protocol), or proxying of Netconf. 4727 To reach a TA that has no ACP connectivity, the ACP registrar would 4728 use the Data-Plane. ACP and Data-Plane in an ACP registrar could 4729 (and by default should be) completely isolated from each other at the 4730 network level. Only applications such as the ACP registrar would 4731 need the ability for their transport stacks to access both. 4733 In non-autonomic enrollment options, the Data-Plane between a ACP 4734 registrar and the candidate ACP node needs to be configured first. 4735 This includes the ACP registrar and the candidate ACP node. Then any 4736 appropriate set of protocols can be used between ACP registrar and 4737 candidate ACP node to discover the other side, and then connect and 4738 enroll (configure) the candidate ACP node with an ACP domain 4739 certificate. Netconf ZeroTouch ([RFC8572]) is an example protocol 4740 that could be used for this. BRSKI using optional discovery 4741 mechanisms is equally a possibility for candidate ACP nodes 4742 attempting to be enrolled across non-ACP networks, such as the 4743 Internet. 4745 When candidate ACP nodes have secure bootstrap, such as BRSKI 4746 Pledges, they will not trust to be configured/enrolled across the 4747 network, unless being presented with a voucher (see [RFC8366]) 4748 authorizing the network to take possession of the node. An ACP 4749 registrar will then need a method to retrieve such a voucher, either 4750 offline, or online from a MASA (Manufacturer Authorized Signing 4751 Authority). BRSKI and Netconf ZeroTouch are two protocols that 4752 include capabilities to present the voucher to the candidate ACP 4753 node. 4755 An ACP registrar could operate EST for ACP certificate renewal and/or 4756 act as a CRL Distribution point. A node performing these services 4757 does not need to support performing (initial) enrollment, but it does 4758 require the same above described connectivity as an ACP registrar: 4759 via the ACP to ACP nodes and via the Data-Plane to the TA and other 4760 sources of CRL information. 4762 9.2.2. Registrar Parameter 4764 The interactions of an ACP registrar outlined Section 6.10.7 and 4765 Section 9.2.1 above depend on the following parameters: 4767 A URL to the TA and credentials so that the ACP registrar can let 4768 the TA sign candidate ACP node certificates. 4770 The ACP domain-name. 4772 The Registrar-ID to use. This could default to a MAC address of 4773 the ACP registrar. 4775 For recovery, the next-useable Node-IDs for zone (Zone-ID=0) sub- 4776 addressing scheme, for Vlong /112 and for Vlong /120 sub- 4777 addressing scheme. These IDs would only need to be provisioned 4778 after recovering from a crash. Some other mechanism would be 4779 required to remember these IDs in a backup location or to recover 4780 them from the set of currently known ACP nodes. 4782 Policies if candidate ACP nodes should receive a domain 4783 certificate or not, for example based on the devices IDevID 4784 certificate as in BRSKI. The ACP registrar may have a whitelist 4785 or blacklist of devices "serialNumbers" from their IDevID 4786 certificate. 4788 Policies what type of address prefix to assign to a candidate ACP 4789 devices, based on likely the same information. 4791 For BRSKI or other mechanisms using vouchers: Parameters to 4792 determine how to retrieve vouchers for specific type of secure 4793 bootstrap candidate ACP nodes (such as MASA URLs), unless this 4794 information is automatically learned such as from the IDevID 4795 certificate of candidate ACP nodes (as defined in BRSKI). 4797 9.2.3. Certificate renewal and limitations 4799 When an ACP node renews/rekeys its certificate, it may end up doing 4800 so via a different registrar (e.g., EST server) than the one it 4801 originally received its ACP domain certificate from, for example 4802 because that original ACP registrar is gone. The ACP registrar 4803 through which the renewal/rekeying is performed would by default 4804 trust the acp-node-name from the ACP nodes current ACP domain 4805 certificate and maintain this information so that the ACP node 4806 maintains its ACP address prefix. In EST renewal/rekeying, the ACP 4807 nodes current ACP domain certificate is signaled during the TLS 4808 handshake. 4810 This simple scenario has two limitations: 4812 1. The ACP registrars cannot directly assign certificates to nodes 4813 and therefore needs an "online" connection to the TA. 4815 2. Recovery from a compromised ACP registrar is difficult. When an 4816 ACP registrar is compromised, it can insert for example a 4817 conflicting acp-node-name and create thereby an attack against 4818 other ACP nodes through the ACP routing protocol. 4820 Even when such a malicious ACP registrar is detected, resolving the 4821 problem may be difficult because it would require identifying all the 4822 wrong ACP domain certificates assigned via the ACP registrar after it 4823 was compromised. And without additional centralized tracking of 4824 assigned certificates there is no way to do this. 4826 9.2.4. ACP Registrars with sub-CA 4828 In situations, where either of the above two limitations are an 4829 issue, ACP registrars could also be sub-CAs. This removes the need 4830 for connectivity to a TA whenever an ACP node is enrolled, and 4831 reduces the need for connectivity of such an ACP registrar to a TA to 4832 only those times when it needs to renew its own certificate. The ACP 4833 registrar would also now use its own (sub-CA) certificate to enroll 4834 and sign the ACP nodes certificates, and therefore it is only 4835 necessary to revoke a compromised ACP registrars sub-CA certificate. 4836 Alternatively one can let it expire and not renew it, when the 4837 certificate of the sub-CA is appropriately short-lived. 4839 As the ACP domain membership check verifies a peer ACP node's ACP 4840 domain certificate trust chain, it will also verify the signing 4841 certificate which is the compromised/revoked sub-CA certificate. 4842 Therefore ACP domain membership for an ACP node enrolled from a 4843 compromised and discovered ACP registrar will fail. 4845 ACP nodes enrolled by a compromised ACP registrar would automatically 4846 fail to establish ACP channels and ACP domain certificate renewal via 4847 EST and therefore revert to their role as a candidate ACP members and 4848 attempt to get a new ACP domain certificate from an ACP registrar - 4849 for example, via BRSKI. In result, ACP registrars that have an 4850 associated sub-CA makes isolating and resolving issues with 4851 compromised registrars easier. 4853 Note that ACP registrars with sub-CA functionality also can control 4854 the lifetime of ACP domain certificates easier and therefore also be 4855 used as a tool to introduce short lived certificates and not rely on 4856 CRL, whereas the certificates for the sub-CAs themselves could be 4857 longer lived and subject to CRL. 4859 9.2.5. Centralized Policy Control 4861 When using multiple, uncoordinated ACP registrars, several advanced 4862 operations are potentially more complex than with a single, resilient 4863 policy control backend, for example including but not limited to: 4865 Which candidate ACP node is permitted or not permitted into an ACP 4866 domain. This may not be a decision to be taken upfront, so that a 4867 per-"serialNumber" policy can be loaded into every ACP registrar. 4868 Instead, it may better be decided in real-time including 4869 potentially a human decision in a NOC. 4871 Tracking of all enrolled ACP nodes and their certificate 4872 information. For example in support of revoking individual ACP 4873 nodes certificates. 4875 More flexible policies what type of address prefix or even what 4876 specific address prefix to assign to a candidate ACP node. 4878 These and other operations could be introduced more easily by 4879 introducing a centralized Policy Management System (PMS) and 4880 modifying ACP registrar behavior so that it queries the PMS for any 4881 policy decision occurring during the candidate ACP node enrollment 4882 process and/or the ACP node certificate renewal process. For 4883 example, which ACP address prefix to assign. Likewise the ACP 4884 registrar would report any relevant state change information to the 4885 PMS as well, for example when a certificate was successfully enrolled 4886 onto a candidate ACP node. 4888 9.3. Enabling and disabling ACP/ANI 4890 Both ACP and BRSKI require interfaces to be operational enough to 4891 support sending/receiving their packets. In node types where 4892 interfaces are by default (e.g., without operator configuration) 4893 enabled, such as most L2 switches, this would be less of a change in 4894 behavior than in most L3 devices (e.g.: routers), where interfaces 4895 are by default disabled. In almost all network devices it is common 4896 though for configuration to change interfaces to a physically 4897 disabled state and that would break the ACP. 4899 In this section, we discuss a suggested operational model to enable/ 4900 disable interfaces and nodes for ACP/ANI in a way that minimizes the 4901 risk of operator action to break the ACP in this way, and that also 4902 minimizes operator surprise when ACP/ANI becomes supported in node 4903 software. 4905 9.3.1. Filtering for non-ACP/ANI packets 4907 Whenever this document refers to enabling an interface for ACP (or 4908 BRSKI), it only requires to permit the interface to send/receive 4909 packets necessary to operate ACP (or BRSKI) - but not any other Data- 4910 Plane packets. Unless the Data-Plane is explicitly configured/ 4911 enabled, all packets not required for ACP/BRSKI should be filtered on 4912 input and output: 4914 Both BRSKI and ACP require link-local only IPv6 operations on 4915 interfaces and DULL GRASP. IPv6 link-local operations means the 4916 minimum signaling to auto-assign an IPv6 link-local address and talk 4917 to neighbors via their link-local address: SLAAC (Stateless Address 4918 Auto-Configuration - [RFC4862]) and ND (Neighbor Discovery - 4919 [RFC4861]). When the device is a BRSKI pledge, it may also require 4920 TCP/TLS connections to BRSKI proxies on the interface. When the 4921 device has keying material, and the ACP is running, it requires DULL 4922 GRASP packets and packets necessary for the secure-channel mechanism 4923 it supports, e.g., IKEv2 and IPsec ESP packets or DTLS packets to the 4924 IPv6 link-local address of an ACP neighbor on the interface. It also 4925 requires TCP/TLS packets for its BRSKI proxy functionality, if it 4926 does support BRSKI. 4928 9.3.2. Admin Down State 4930 Interfaces on most network equipment have at least two states: "up" 4931 and "down". These may have product specific names. "down" for 4932 example could be called "shutdown" and "up" could be called "no 4933 shutdown". The "down" state disables all interface operations down 4934 to the physical level. The "up" state enables the interface enough 4935 for all possible L2/L3 services to operate on top of it and it may 4936 also auto-enable some subset of them. More commonly, the operations 4937 of various L2/L3 services is controlled via additional node-wide or 4938 interface level options, but they all become only active when the 4939 interface is not "down". Therefore an easy way to ensure that all 4940 L2/L3 operations on an interface are inactive is to put the interface 4941 into "down" state. The fact that this also physically shuts down the 4942 interface is in many cases just a side effect, but it may be 4943 important in other cases (see below, Section 9.3.2.2). 4945 To provide ACP/ANI resilience against operators configuring 4946 interfaces to "down" state, this document recommends to separate the 4947 "down" state of interfaces into an "admin down" state where the 4948 physical layer is kept running and ACP/ANI can use the interface and 4949 a "physical down" state. Any existing "down" configurations would 4950 map to "admin down". In "admin down", any existing L2/L3 services of 4951 the Data-Plane should see no difference to "physical down" state. To 4952 ensure that no Data-Plane packets could be sent/received, packet 4953 filtering could be established automatically as described above in 4954 Section 9.3.1. 4956 As necessary (see discussion below) new configuration options could 4957 be introduced to issue "physical down". The options should be 4958 provided with additional checks to minimize the risk of issuing them 4959 in a way that breaks the ACP without automatic restoration. For 4960 example they could be denied to be issued from a control connection 4961 (netconf/ssh) that goes across the interface itself ("do not 4962 disconnect yourself"). Or they could be performed only temporary and 4963 only be made permanent with additional later reconfirmation. 4965 In the following sub-sections important aspects to the introduction 4966 of "admin down" state are discussed. 4968 9.3.2.1. Security 4970 Interfaces are physically brought down (or left in default down 4971 state) as a form of security. "Admin down" state as described above 4972 provides also a high level of security because it only permits ACP/ 4973 ANI operations which are both well secured. Ultimately, it is 4974 subject to security review for the deployment whether "admin down" is 4975 a feasible replacement for "physical down". 4977 The need to trust the security of ACP/ANI operations needs to be 4978 weighed against the operational benefits of permitting this: Consider 4979 the typical example of a CPE (customer premises equipment) with no 4980 on-site network expert. User ports are in physical down state unless 4981 explicitly configured not to be. In a misconfiguration situation, 4982 the uplink connection is incorrectly plugged into such as user port. 4983 The device is disconnected from the network and therefore no 4984 diagnostics from the network side is possible anymore. 4985 Alternatively, all ports default to "admin down". The ACP (but not 4986 the Data-Plane) would still automatically form. Diagnostics from the 4987 network side is possible and operator reaction could include to 4988 either make this port the operational uplink port or to instruct re- 4989 cabling. Security wise, only ACP/ANI could be attacked, all other 4990 functions are filtered on interfaces in "admin down" state. 4992 9.3.2.2. Fast state propagation and Diagnostics 4994 "Physical down" state propagates on many interface types (e.g., 4995 Ethernet) to the other side. This can trigger fast L2/L3 protocol 4996 reaction on the other side and "admin down" would not have the same 4997 (fast) result. 4999 Bringing interfaces to "physical down" state is to the best of our 5000 knowledge always a result of operator action, but today, never the 5001 result of autonomic L2/L3 services running on the nodes. Therefore 5002 one option is to change the operator action to not rely on link-state 5003 propagation anymore. This may not be possible when both sides are 5004 under different operator control, but in that case it is unlikely 5005 that the ACP is running across the link and actually putting the 5006 interface into "physical down" state may still be a good option. 5008 Ideally, fast physical state propagation is replaced by fast software 5009 driven state propagation. For example a DULL GRASP "admin-state" 5010 objective could be used to auto configure a Bidirectional Forwarding 5011 Protocol (BFD, [RFC5880]) session between the two sides of the link 5012 that would be used to propagate the "up" vs. admin down state. 5014 Triggering physical down state may also be used as a mean of 5015 diagnosing cabling in the absence of easier methods. It is more 5016 complex than automated neighbor diagnostics because it requires 5017 coordinated remote access to both (likely) sides of a link to 5018 determine whether up/down toggling will cause the same reaction on 5019 the remote side. 5021 See Section 9.1 for a discussion about how LLDP and/or diagnostics 5022 via GRASP could be used to provide neighbor diagnostics, and 5023 therefore hopefully eliminating the need for "physical down" for 5024 neighbor diagnostics - as long as both neighbors support ACP/ANI. 5026 9.3.2.3. Low Level Link Diagnostics 5028 "Physical down" is performed to diagnose low-level interface behavior 5029 when higher layer services (e.g., IPv6) are not working. Especially 5030 Ethernet links are subject to a wide variety of possible wrong 5031 configuration/cablings if they do not support automatic selection of 5032 variable parameters such as speed (10/100/1000 Mbps), crossover 5033 (Auto-MDIX) and connector (fiber, copper - when interfaces have 5034 multiple but can only enable one at a time). The need for low level 5035 link diagnostic can therefore be minimized by using fully auto 5036 configuring links. 5038 In addition to "Physical down", low level diagnostics of Ethernet or 5039 other interfaces also involve the creation of other states on 5040 interfaces, such as physical Loopback (internal and/or external) or 5041 bringing down all packet transmissions for reflection/cable-length 5042 measurements. Any of these options would disrupt ACP as well. 5044 In cases where such low-level diagnostics of an operational link is 5045 desired but where the link could be a single point of failure for the 5046 ACP, ASA on both nodes of the link could perform a negotiated 5047 diagnostics that automatically terminates in a predetermined manner 5048 without dependence on external input ensuring the link will become 5049 operational again. 5051 9.3.2.4. Power Consumption Issues 5053 Power consumption of "physical down" interfaces, may be significantly 5054 lower than those in "admin down" state, for example on long-range 5055 fiber interfaces. Bringing up interfaces, for example to probe 5056 reachability, may also consume additional power. This can make these 5057 type of interfaces inappropriate to operate purely for the ACP when 5058 they are not currently needed for the Data-Plane. 5060 9.3.3. Interface level ACP/ANI enable 5062 The interface level configuration option "ACP enable" enables ACP 5063 operations on an interface, starting with ACP neighbor discovery via 5064 DULL GRAP. The interface level configuration option "ANI enable" on 5065 nodes supporting BRSKI and ACP starts with BRSKI pledge operations 5066 when there is no domain certificate on the node. On ACP/BRSKI nodes, 5067 "ACP enable" may not need to be supported, but only "ANI enable". 5068 Unless overridden by global configuration options (see later), "ACP/ 5069 ANI enable" will result in "down" state on an interface to behave as 5070 "admin down". 5072 9.3.4. Which interfaces to auto-enable? 5074 (Section 6.3) requires that "ACP enable" is automatically set on 5075 native interfaces, but not on non-native interfaces (reminder: a 5076 native interface is one that exists without operator configuration 5077 action such as physical interfaces in physical devices). 5079 Ideally, ACP enable is set automatically on all interfaces that 5080 provide access to additional connectivity that allows to reach more 5081 nodes of the ACP domain. The best set of interfaces necessary to 5082 achieve this is not possible to determine automatically. Native 5083 interfaces are the best automatic approximation. 5085 Consider an ACP domain of ACP nodes transitively connected via native 5086 interfaces. A Data-Plane tunnel between two of these nodes that are 5087 non-adjacent is created and "ACP enable" is set for that tunnel. ACP 5088 RPL sees this tunnel as just as a single hop. Routes in the ACP 5089 would use this hop as an attractive path element to connect regions 5090 adjacent to the tunnel nodes. In result, the actual hop-by-hop paths 5091 used by traffic in the ACP can become worse. In addition, correct 5092 forwarding in the ACP now depends on correct Data-Plane forwarding 5093 config including QoS, filtering and other security on the Data-Plane 5094 path across which this tunnel runs. This is the main issue why "ACP/ 5095 ANI enable" should not be set automatically on non-native interfaces. 5097 If the tunnel would connect two previously disjoint ACP regions, then 5098 it likely would be useful for the ACP. A Data-Plane tunnel could 5099 also run across nodes without ACP and provide additional connectivity 5100 for an already connected ACP network. The benefit of this additional 5101 ACP redundancy has to be weighed against the problems of relying on 5102 the Data-Plane. If a tunnel connects two separate ACP regions: how 5103 many tunnels should be created to connect these ACP regions reliably 5104 enough? Between which nodes? These are all standard tunneled 5105 network design questions not specific to the ACP, and there are no 5106 generic fully automated answers. 5108 Instead of automatically setting "ACP enable" on these type of 5109 interfaces, the decision needs to be based on the use purpose of the 5110 non-native interface and "ACP enable" needs to be set in conjunction 5111 with the mechanism through which the non-native interface is created/ 5112 configured. 5114 In addition to explicit setting of "ACP/ANI enable", non-native 5115 interfaces also need to support configuration of the ACP RPL cost of 5116 the link - to avoid the problems of attracting too much traffic to 5117 the link as described above. 5119 Even native interfaces may not be able to automatically perform BRSKI 5120 or ACP because they may require additional operator input to become 5121 operational. Example include DSL interfaces requiring PPPoE 5122 credentials or mobile interfaces requiring credentials from a SIM 5123 card. Whatever mechanism is used to provide the necessary config to 5124 the device to enable the interface can also be expanded to decide on 5125 whether or not to set "ACP/ANI enable". 5127 The goal of automatically setting "ACP/ANI enable" on interfaces 5128 (native or not) is to eliminate unnecessary "touches" to the node to 5129 make its operation as much as possible "zero-touch" with respect to 5130 ACP/ANI. If there are "unavoidable touches" such a creating/ 5131 configuring a non-native interface or provisioning credentials for a 5132 native interface, then "ACP/ANI enable" should be added as an option 5133 to that "touch". If a wrong "touch" is easily fixed (not creating 5134 another high-cost touch), then the default should be not to enable 5135 ANI/ACP, and if it is potentially expensive or slow to fix (e.g., 5136 parameters on SIM card shipped to remote location), then the default 5137 should be to enable ACP/ANI. 5139 9.3.5. Node Level ACP/ANI enable 5141 A node level command "ACP/ANI enable [up-if-only]" enables ACP or ANI 5142 on the node (ANI = ACP + BRSKI). Without this command set, any 5143 interface level "ACP/ANI enable" is ignored. Once set, ACP/ANI will 5144 operate an interface where "ACP/ANI enable" is set. Setting of 5145 interface level "ACP/ANI enable" is either automatic (default) or 5146 explicit through operator action as described in the previous 5147 section. 5149 If the option "up-if-only" is selected, the behavior of "down" 5150 interfaces is unchanged, and ACP/ANI will only operate on interfaces 5151 where "ACP/ANI enable" is set and that are "up". When it is not set, 5152 then "down" state of interfaces with "ACP/ANI enable" is modified to 5153 behave as "admin down". 5155 9.3.5.1. Brownfield nodes 5157 A "brownfield" node is one that already has a configured Data-Plane. 5159 Executing global "ACP/ANI enable [up-if-only]" on each node is the 5160 only command necessary to create an ACP across a network of 5161 brownfield nodes once all the nodes have a domain certificate. When 5162 BRSKI is used ("ANI enable"), provisioning of the certificates only 5163 requires set-up of a single BRSKI registrar node which could also 5164 implement a CA for the network. This is the most simple way to 5165 introduce ACP/ANI into existing (== brownfield) networks. 5167 The need to explicitly enable ACP/ANI is especially important in 5168 brownfield nodes because otherwise software updates may introduce 5169 support for ACP/ANI: Automatic enablement of ACP/ANI in networks 5170 where the operator does not only not want ACP/ANI but where the 5171 operator likely never even heard of it could be quite irritating to 5172 the operator. Especially when "down" behavior is changed to "admin 5173 down". 5175 Automatically setting "ANI enable" on brownfield nodes where the 5176 operator is unaware of BRSKI and MASA operations could also be an 5177 unlikely but then critical security issue. If an attacker could 5178 impersonate the operator and register as the operator at the MASA or 5179 otherwise get hold of vouchers and can get enough physical access to 5180 the network so pledges would register to an attacking registrar, then 5181 the attacker could gain access to the network through the ACP that 5182 the attacker then has access to. 5184 In networks where the operator explicitly wants to enable the ANI 5185 this could not happen, because the operator would create a BRSKI 5186 registrar that would discover attack attempts, and the operator would 5187 be setting up his registrar with the MASA. Nodes requiring 5188 "ownership vouchers" would not be subject to that attack. See 5189 [I-D.ietf-anima-bootstrapping-keyinfra] for more details. Note that 5190 a global "ACP enable" alone is not subject to these type of attacks, 5191 because it always depends on some other mechanism first to provision 5192 domain certificates into the device. 5194 9.3.5.2. Greenfield nodes 5196 A "greenfield" node is one that did not have any prior configuration. 5198 For greenfield nodes, only "ANI enable" is relevant. If another 5199 mechanism than BRSKI is used to (zero-touch) bootstrap a node, then 5200 it is up to that mechanism to provision domain certificates and to 5201 set global "ACP enable" as desired. 5203 Nodes supporting full ANI functionality set "ANI enable" 5204 automatically when they decide that they are greenfield, e.g., that 5205 they are powering on from factory condition. They will then put all 5206 native interfaces into "admin down" state and start to perform BRSKI 5207 pledge functionality - and once a domain certificate is enrolled they 5208 automatically enable ACP. 5210 Attempts for BRSKI pledge operations in greenfield state should 5211 terminate automatically when another method of configuring the node 5212 is used. Methods that indicate some form of physical possession of 5213 the device such as configuration via the serial console port could 5214 lead to immediate termination of BRSKI, while other parallel auto 5215 configuration methods subject to remote attacks might lead to BRSKI 5216 termination only after they were successful. Details of this may 5217 vary widely over different type of nodes. When BRSKI pledge 5218 operation terminates, this will automatically unset "ANI enable" and 5219 should terminate any temporarily needed state on the device to 5220 perform BRSKI - DULL GRASP, BRSKI pledge and any IPv6 configuration 5221 on interfaces. 5223 9.3.6. Undoing ANI/ACP enable 5225 Disabling ANI/ACP by undoing "ACP/ANI enable" is a risk for the 5226 reliable operations of the ACP if it can be executed by mistake or 5227 unauthorized. This behavior could be influenced through some 5228 additional (future) property in the certificate (e.g., in the acp- 5229 node-name extension field): In an ANI deployment intended for 5230 convenience, disabling it could be allowed without further 5231 constraints. In an ANI deployment considered to be critical more 5232 checks would be required. One very controlled option would be to not 5233 permit these commands unless the domain certificate has been revoked 5234 or is denied renewal. Configuring this option would be a parameter 5235 on the BRSKI registrar(s). As long as the node did not receive a 5236 domain certificate, undoing "ANI/ACP enable" should not have any 5237 additional constraints. 5239 9.3.7. Summary 5241 Node-wide "ACP/ANI enable [up-if-only]" commands enable the operation 5242 of ACP/ANI. This is only auto-enabled on ANI greenfield devices, 5243 otherwise it must be configured explicitly. 5245 If the option "up-if-only" is not selected, interfaces enabled for 5246 ACP/ANI interpret "down" state as "admin down" and not "physical 5247 down". In "admin-down" all non-ACP/ANI packets are filtered, but the 5248 physical layer is kept running to permit ACP/ANI to operate. 5250 (New) commands that result in physical interruption ("physical down", 5251 "loopback") of ACP/ANI enabled interfaces should be built to protect 5252 continuance or reestablishment of ACP as much as possible. 5254 Interface level "ACP/ANI enable" control per-interface operations. 5255 It is enabled by default on native interfaces and has to be 5256 configured explicitly on other interfaces. 5258 Disabling "ACP/ANI enable" global and per-interface should have 5259 additional checks to minimize undesired breakage of ACP. The degree 5260 of control could be a domain wide parameter in the domain 5261 certificates. 5263 9.4. Partial or Incremental adoption 5265 The ACP Zone Addressing Sub-Scheme (see Section 6.10.3) allows 5266 incremental adoption of the ACP in a network where ACP can be 5267 deployed on edge areas, but not across the core that is connecting 5268 those edges. 5270 In such a setup, each edge network, such as a branch or campus of an 5271 enterprise network has a disjoined ACP to which one or more unique 5272 Zone-IDs are assigned: ACP nodes registered for a specific ACP zone 5273 have to receive ACP Zone Addressing Sub-scheme addresses, for example 5274 by virtue of configuring for each such zone one or more ACP 5275 Registrars with that Zone-ID. All the Registrars for these ACP Zones 5276 need to get ACP certificates from CAs relying on a common set of TA 5277 and of course the same ACP domain name. 5279 These ACP zones can first be brought up as separate networks without 5280 any connection between them and/or they can be connected across a 5281 non-ACP enabled core network through various non-autonomic 5282 operational practices. For example, each separate ACP Zone can have 5283 an edge node that is a layer 3 VPN PE (MPLS or IPv6 layer 3 VPN), 5284 where a complete non-autonomic ACP-Core VPN is created by using the 5285 ACP VRFs and exchanging the routes from those ACP VRFs across the 5286 VPNs non-autonomic routing protocol(s). 5288 While such a setup is possible with any ACP addressing sub-scheme, 5289 the ACP-Zone Addressing sub-scheme makes it easy to configure and 5290 scalable for any VPN routing protocols because every ACP zone would 5291 only need to indicate one or more /64 ACP Zone Addressing prefix 5292 routes into the ACP-Core VPN as opposed to routes for every 5293 individual ACP node as required in the other ACP addressing schemes. 5295 Note that the non-autonomous ACP-Core VPN would require additional 5296 extensions to propagate GRASP messages when GRASP discovery is 5297 desired across the zones. For example, one could set up on each Zone 5298 edge router remote ACP tunnel to an appplication level implemented 5299 GRASP hub running in the networks NOC that is generating GRASP 5300 announcements for NOC services into the ACP Zones or propagating them 5301 between ACP Zones. 5303 Such partial deployment may prove to be sufficient or could evolve to 5304 become more autonomous through future standardized or non- 5305 standardized enhancements, for example by allowing GRASP messages to 5306 be propagated across the layer 3 VPN, leveraging for example L3VPN 5307 Multicast support. 5309 Finally, these partial deployments can be merged into a single 5310 contiguous complete autonomous ACP (given appropriate ACP support 5311 across the core) without changes in the crypto material, because the 5312 nodes ACP certificates are fromm a single ACP. 5314 9.5. Configuration and the ACP (summary) 5316 There is no desirable configuration for the ACP. Instead, all 5317 parameters that need to be configured in support of the ACP are 5318 limitations of the solution, but they are only needed in cases where 5319 not all components are made autonomic. Whereever this is necessary, 5320 it relies on pre-existing mechanisms for configuration such as CLI or 5321 YANG ([RFC7950]) data models. 5323 The most important examples of such configuration include: 5325 o When ACP nodes do not support an autonomic way to receive an ACP 5326 domain certificate, for example BRSKI, then such certificate needs 5327 to be configured via some pre-existing mechanisms outside the 5328 scope of this specification. Today, router have typically a 5329 variety of mechanisms to do this. 5331 o Certificate maintenance requires PKI functions. Discovery of 5332 these functions across the ACP is automated (see Section 6.1.5), 5333 but their configuration is not. 5335 o When non-ACP capable nodes such as pre-existing NMS need to be 5336 physically connected to the ACP, the ACP node to which they attach 5337 needs to be configured with ACP-connect according to Section 8.1. 5338 It is also possible to use that single physical connection to 5339 connect both to ACP and the Data-Plane of the network as explained 5340 in Section 8.1.4. 5342 o When devices are not autonomically bootstrapped, explicit 5343 configuration to enable the ACP needs to be applied. See 5344 Section 9.3. 5346 o When the ACP needs to be extended across interfacess other than 5347 L2, the ACP as defined in this document can not autodiscover 5348 candidate neighbors automatically. Remote neighbors need to be 5349 configured, see Section 8.2. 5351 Once the ACP is operating, any further configuration for the Data- 5352 Plane can be configured more reliably across the ACP itself because 5353 the ACP provides addressing and connectivity (routing) independent of 5354 the Data-Plane itself. For this, the configuration methods simply 5355 need to also allow to operate across the ACP VRF - netconf, ssh or 5356 any other method. 5358 The ACP also provides additional security through its hop-by-hop 5359 encryption for any such configuration operations: Some legacy 5360 configuration methods (SNMP, TFTP, HTTP) may not use end-to-end 5361 encryption, and most of the end-to-end secured configuration methods 5362 still allow for easy passive observation along the path about 5363 configuration taking place (transport flows, port numbers, IP 5364 addresses). 5366 The ACP can and should equally be used as the transport to configure 5367 any of the aforemention non-automic components of the ACP, but in 5368 that case, the same caution needs to be exercised as with Data-Plane 5369 configuration without ACP: Misconfiguration may cause the configuring 5370 entity to be disconnected from the node it configures - for example 5371 when incorrectly unconfiguring a remote ACP neighbor through which 5372 the configured ACP node is reached. 5374 10. Summary: Benefits (Informative) 5375 10.1. Self-Healing Properties 5377 The ACP is self-healing: 5379 o New neighbors will automatically join the ACP after successful 5380 validation and will become reachable using their unique ULA 5381 address across the ACP. 5383 o When any changes happen in the topology, the routing protocol used 5384 in the ACP will automatically adapt to the changes and will 5385 continue to provide reachability to all nodes. 5387 o The ACP tracks the validity of peer certificates and tears down 5388 ACP secure channels when a peer certificate has expired. When 5389 short-lived certificates with lifetimes in the order of OCSP/CRL 5390 refresh times are used, then this allows for removal of invalid 5391 peers (whose certificate was not renewed) at similar speeds as 5392 when using OCSP/CRL. The same benefit can be achieved when using 5393 CRL/OCSP, periodically refreshing the revocation information and 5394 also tearing down ACP secure channels when the peer's (long-lived) 5395 certificate is revoked. There is no requirement against ACP 5396 implementations to require this enhancement though to keep the 5397 mandatory implementations simpler. 5399 The ACP can also sustain network partitions and mergers. Practically 5400 all ACP operations are link local, where a network partition has no 5401 impact. Nodes authenticate each other using the domain certificates 5402 to establish the ACP locally. Addressing inside the ACP remains 5403 unchanged, and the routing protocol inside both parts of the ACP will 5404 lead to two working (although partitioned) ACPs. 5406 There are few central dependencies: A CRL may not be available during 5407 a network partition; a suitable policy to not immediately disconnect 5408 neighbors when no CRL is available can address this issue. Also, an 5409 ACP Registrar or Certification Authority might not be available 5410 during a partition. This may delay renewal of certificates that are 5411 to expire in the future, and it may prevent the enrollment of new 5412 nodes during the partition. 5414 Highly resilient ACP designs can be built by using ACP Registrars 5415 with embedded sub-CA, as outlined in Section 9.2.4. As long as a 5416 partition is left with one or more of such ACP Registrars, it can 5417 continue to enroll new candidate ACP nodes as long as the ACP 5418 Registrar's sub-CA certificate does not expire. Because the ACP 5419 addressing relies on unique Registrar-IDs, a later re-merge of 5420 partitions will also not cause problems with ACP addresses assigned 5421 during partitioning. 5423 After a network partition, a re-merge will just establish the 5424 previous status, certificates can be renewed, the CRL is available, 5425 and new nodes can be enrolled everywhere. Since all nodes use the 5426 same TA, a re-merge will be smooth. 5428 Merging two networks with different TA requires the ACP nodes to 5429 trust the union of TA. As long as the routing-subdomain hashes are 5430 different, the addressing will not overlap, which only happens in the 5431 unlikely event of a 40-bit hash collision in SHA256 (see 5432 Section 6.10). Note that the complete mechanisms to merge networks 5433 is out of scope of this specification. 5435 It is also highly desirable for implementation of the ACP to be able 5436 to run it over interfaces that are administratively down. If this is 5437 not feasible, then it might instead be possible to request explicit 5438 operator override upon administrative actions that would 5439 administratively bring down an interface across which the ACP is 5440 running. Especially if bringing down the ACP is known to disconnect 5441 the operator from the node. For example any such down administrative 5442 action could perform a dependency check to see if the transport 5443 connection across which this action is performed is affected by the 5444 down action (with default RPL routing used, packet forwarding will be 5445 symmetric, so this is actually possible to check). 5447 10.2. Self-Protection Properties 5449 10.2.1. From the outside 5451 As explained in Section 6, the ACP is based on secure channels built 5452 between nodes that have mutually authenticated each other with their 5453 domain certificates. The channels themselves are protected using 5454 standard encryption technologies such as DTLS or IPsec which provide 5455 additional authentication during channel establishment, data 5456 integrity and data confidentiality protection of data inside the ACP 5457 and in addition, provide replay protection. 5459 An attacker will not be able to join the ACP unless having a valid 5460 domain certificate, also packet injection and sniffing traffic will 5461 not be possible due to the security provided by the encryption 5462 protocol. 5464 The ACP also serves as protection (through authentication and 5465 encryption) for protocols relevant to OAM that may not have secured 5466 protocol stack options or where implementation or deployment of those 5467 options fail on some vendor/product/customer limitations. This 5468 includes protocols such as SNMP ([RFC3411]), NTP ([RFC5905]), PTP 5469 ([IEEE-1588-2008]), DNS ([RFC3596]), DHCPv6 ([RFC3315]), syslog 5470 ([RFC3164]), Radius ([RFC2865]), Diameter ([RFC6733]), TACACS 5471 ([RFC1492]), IPFIX ([RFC7011]), Netflow ([RFC3954]) - just to name a 5472 few. Not all of these protocol references are necessarily the latest 5473 version of protocols but versions that are still widely deployed. 5475 Protection via the ACP secure hop-by-hop channels for these protocols 5476 is meant to be only a stopgap though: The ultimate goal is for these 5477 and other protocols to use end-to-end encryption utilizing the domain 5478 certificate and rely on the ACP secure channels primarily for zero- 5479 touch reliable connectivity, but not primarily for security. 5481 The remaining attack vector would be to attack the underlying ACP 5482 protocols themselves, either via directed attacks or by denial-of- 5483 service attacks. However, as the ACP is built using link-local IPv6 5484 addresses, remote attacks from the Data-Plane are impossible as long 5485 as the Data-Plane has no facilities to remotely sent IPv6 link-local 5486 packets. The only exception are ACP connected interfaces which 5487 require higher physical protection. The ULA addresses are only 5488 reachable inside the ACP context, therefore, unreachable from the 5489 Data-Plane. Also, the ACP protocols should be implemented to be 5490 attack resistant and not consume unnecessary resources even while 5491 under attack. 5493 10.2.2. From the inside 5495 The security model of the ACP is based on trusting all members of the 5496 group of nodes that receive an ACP domain certificate for the same 5497 domain. Attacks from the inside by a compromised group member are 5498 therefore the biggest challenge. 5500 Group members must be protected against attackers so that there is no 5501 easy way to compromise them, or use them as a proxy for attacking 5502 other devices across the ACP. For example, management plane 5503 functions (transport ports) should only be reachable from the ACP but 5504 not the Data-Plane. Especially for those management plane functions 5505 that have no good protection by themselves because they do not have 5506 secure end-to-end transport and to whom ACP not only provides 5507 automatic reliable connectivity but also protection against attacks. 5508 Protection across all potential attack vectors is typically easier to 5509 do in devices whose software is designed from the ground up with 5510 security in mind than with legacy software based systems where the 5511 ACP is added on as another feature. 5513 As explained above, traffic across the ACP SHOULD still be end-to-end 5514 encrypted whenever possible. This includes traffic such as GRASP, 5515 EST and BRSKI inside the ACP. This minimizes man in the middle 5516 attacks by compromised ACP group members. Such attackers cannot 5517 eavesdrop or modify communications, they can just filter them (which 5518 is unavoidable by any means). 5520 See Appendix A.10.8 for further considerations how to avoid and deal 5521 with compromised nodes. 5523 10.3. The Administrator View 5525 An ACP is self-forming, self-managing and self-protecting, therefore 5526 has minimal dependencies on the administrator of the network. 5527 Specifically, since it is (intended to be) independent of 5528 configuration, there is only limited scope for configuration errors 5529 on the ACP itself. The administrator may have the option to enable 5530 or disable the entire approach, but detailed configuration is not 5531 possible. This means that the ACP must not be reflected in the 5532 running configuration of nodes, except a possible on/off switch (and 5533 even that is undesirable). 5535 While configuration (except for Section 8 and Section 9.2) is not 5536 possible, an administrator must have full visibility of the ACP and 5537 all its parameters, to be able to do trouble-shooting. Therefore, an 5538 ACP must support all show and debug options, as for any other network 5539 function. Specifically, a network management system or controller 5540 must be able to discover the ACP, and monitor its health. This 5541 visibility of ACP operations must clearly be separated from 5542 visibility of Data-Plane so automated systems will never have to deal 5543 with ACP aspects unless they explicitly desire to do so. 5545 Since an ACP is self-protecting, a node not supporting the ACP, or 5546 without a valid domain certificate cannot connect to it. This means 5547 that by default a traditional controller or network management system 5548 cannot connect to an ACP. See Section 8.1.1 for more details on how 5549 to connect an NMS host into the ACP. 5551 11. Security Considerations 5553 After seeding an ACP by configuring at least one ACP registrar with 5554 routing-subdomain and a CA, an ACP is self-protecting and there is no 5555 need to apply configuration to make it secure (typically the ACP 5556 Registrar doubles as EST server for certificate renewal). Its 5557 security therefore does not depend on configuration. This does not 5558 include workarounds for non-autonomic components as explained in 5559 Section 8. See Section 10.2 for details of how the ACP protects 5560 itself against attacks from the outside and to a more limited degree 5561 from the inside as well. 5563 However, the security of the ACP depends on a number of other 5564 factors: 5566 o The usage of domain certificates depends on a valid supporting PKI 5567 infrastructure. If the chain of trust of this PKI infrastructure 5568 is compromised, the security of the ACP is also compromised. This 5569 is typically under the control of the network administrator. 5571 o Every ACP registrar is criticial infrastructure that needs to be 5572 hardened against attacks, similar to a CA. A malicious registrar 5573 can enroll enemy plegdes to an ACP network or break ACP routing by 5574 duplicate ACP address assignment to pledges via their ACP domain 5575 certificates. 5577 o Security can be compromised by implementation errors (bugs), as in 5578 all products. 5580 There is no prevention of source-address spoofing inside the ACP. 5581 This implies that if an attacker gains access to the ACP, it can 5582 spoof all addresses inside the ACP and fake messages from any other 5583 node. 5585 The ACP is designed to enable automation of current network 5586 management and future autonomic peer-to-peer/distributed network 5587 automation. Any ACP member can send ACP IPv6 packet to other ACP 5588 members and announce via ACP GRASP services to all ACP members 5589 without depenency against centralized components. 5591 The ACP relies on peer-to-peer authentication and authorization using 5592 ACP certificates. This security model is necessary to enable the 5593 autonomic ad-hoc any-to-any connectivity between ACP nodes. It 5594 provides infrastructure protection through hop by hop authentication 5595 and encryption - without relying on third parties. For any services 5596 where this complete autonomic peer-to-peer group security model is 5597 appropriate, the ACP domain certificate can also be used unchanged. 5598 For example for any type of Data-Plane routing protocol security. 5600 This ACP security model is designed primarily to protect against 5601 attack from the outside, but not against attacks from the inside. To 5602 protect against spoofing attacks from compromised on-path ACP nodes, 5603 end-to-end encryption inside the ACP is used by new ACP signaling: 5604 GRASP across the ACP using TLS. The same is expected from any non- 5605 legacy services/protocols using the ACP. Because no group-keys are 5606 used, there is no risk for impacted nodes to access end-to-end 5607 encrypted traffic from other ACP nodes. 5609 Attacks from impacted ACP nodes against the ACP are more difficult 5610 than against the Data-Plane because of the autoconfiguration of the 5611 ACP and the absence of configuration options that could be abused 5612 that allow to change/break ACP behavior. This is excluding 5613 configuration for workaround in support of non-autonomic components. 5615 Mitigation against compromised ACP members is possible through 5616 standard automated certificate management mechanisms including 5617 revocation and non-renewal of short-lived certificates. In this 5618 version of the specification, there are no further optimization of 5619 these mechanisms defined for the ACP (but see Appendix A.10.8). 5621 Higher layer service built using ACP domain certificates should not 5622 solely rely on undifferentiated group security when another model is 5623 more appropriate/more secure. For example central network 5624 configuration relies on a security model where only few especially 5625 trusted nodes are allowed to configure the Data-Plane of network 5626 nodes (CLIL, Netconf). This can be done through ACP domain 5627 certificates by differentiating them and introduce roles. See 5628 Appendix A.10.5. 5630 Fundamentally, security depends on avoiding operator and network 5631 operations automation mistakes, implementation and architecture. 5632 Autonomic approaches such as the ACP largely eliminate operator 5633 mistakes and make it easier to recover from network operations 5634 mistakes. Implementation and architectural mistakes are still 5635 possible, as in all networking technologies. 5637 Many details of ACP are designed with security in mind and discussed 5638 elsewhere in the document: 5640 IPv6 addresses used by nodes in the ACP are covered as part of the 5641 node's domain certificate as described in Section 6.1.2. This allows 5642 even verification of ownership of a peer's IPv6 address when using a 5643 connection authenticated with the domain certificate. 5645 The ACP acts as a security (and transport) substrate for GRASP inside 5646 the ACP such that GRASP is not only protected by attacks from the 5647 outside, but also by attacks from compromised inside attackers - by 5648 relying not only on hop-by-hop security of ACP secure channels, but 5649 adding end-to-end security for those GRASP messages. See 5650 Section 6.8.2. 5652 ACP provides for secure, resilient zero-touch discovery of EST 5653 servers for certificate renewal. See Section 6.1.5. 5655 ACP provides extensible, auto-configuring hop-by-hop protection of 5656 the ACP infrastructure via the negotiation of hop-by-hop secure 5657 channel protocols. See Section 6.5. 5659 The ACP is designed to minimize attacks from the outside by 5660 minimizing its dependency against any non-ACP (Data-Plane) 5661 operations/configuration on a node. See also Section 6.12.2. 5663 In combination with BRSKI, ACP enables a resilient, fully zero-touch 5664 network solution for short-lived certificates that can be renewed or 5665 re-enrolled even after unintentional expiry (e.g., because of 5666 interrupted connectivity). See Appendix A.2. 5668 Because ACP secure channels can be long lived, but certificates used 5669 may be short lived, secure channels, for example built via IPsec need 5670 to be terminated when peer certificates expire. See Section 6.7.5. 5672 The ACP is designed to minimize attacks from the outside by 5673 minimizing its dependency against any non-ACP (Data-Plane) 5674 operations/configuration on a node. See also Section 6.12.2. 5676 Section 7.2 describes how to implement a routed ACP topology 5677 operating on what effectively is a large bridge-domain when using L3/ 5678 L2 routers that operate at L2 in the Data-Plane. In this case, the 5679 ACP is subject to much higher likelyhood of attacks by other nodes 5680 "stealing" L2 addresses than in the actual routed case. Especially 5681 when the bridged network includes non-trusted devices such as hosts. 5682 This is a generic issue in L2 LANs. L2/L3 devices often already have 5683 some form of "port security" to prohibit this. They rely on NDP or 5684 DHCP learning of which port/MAC-address and IPv6 address belong 5685 together and block MAC/IPv6 source addresses from wrong ports. This 5686 type of function needs to be enabled to prohibit DoS attacks and 5687 specifically to protect the ACP. Likewise the GRASP DULL instance 5688 needs to ensure that the IPv6 address in the locator-option matches 5689 the source IPv6 address of the DULL GRASP packet. 5691 12. IANA Considerations 5693 This document defines the "Autonomic Control Plane". 5695 For the ANIMA-ACP-2020 ASN.1 module, IANA is asked to register value 5696 IANA1 for "id-mod-anima-acpnodename-2020" in the "SMI Security for 5697 PKIX Module Identifier" (1.3.6.1.5.5.7.0) registry. 5699 For the otherName / AcpNodeName, IANA is asked to register a value 5700 for IANA2 for id-on-AcpNodeName in the "SMI Security for PKIX Other 5701 Name Forms" (1.3.6.1.5.5.7.8) registry. 5703 The IANA is requested to register the value "AN_ACP" (without quotes) 5704 to the GRASP Objectives Names Table in the GRASP Parameter Registry. 5705 The specification for this value is this document, Section 6.3. 5707 The IANA is requested to register the value "SRV.est" (without 5708 quotes) to the GRASP Objectives Names Table in the GRASP Parameter 5709 Registry. The specification for this value is this document, 5710 Section 6.1.5. 5712 Explanation: This document chooses the initially strange looking 5713 format "SRV." because these objective names would be in 5714 line with potential future simplification of the GRASP objective 5715 registry. Today, every name in the GRASP objective registry needs to 5716 be explicitly allocated with IANA. In the future, this type of 5717 objective names could considered to be automatically registered in 5718 that registry for the same service for which is 5719 registered according to [RFC6335]. This explanation is solely 5720 informational and has no impact on the requested registration. 5722 The IANA is requested to create an ACP Parameter Registry with 5723 currently one registry table - the "ACP Address Type" table. 5725 "ACP Address Type" Table. The value in this table are numeric values 5726 0...3 paired with a name (string). Future values MUST be assigned 5727 using the Standards Action policy defined by [RFC8126]. The 5728 following initial values are assigned by this document: 5730 0: ACP Zone Addressing Sub-Scheme (ACP RFC Figure 11) / ACP Manual 5731 Addressing Sub-Scheme (ACP RFC Section 6.10.4) 5732 1: ACP Vlong Addressing Sub-Scheme (ACP RFC Section 6.10.5) 5734 13. Acknowledgements 5736 This work originated from an Autonomic Networking project at Cisco 5737 Systems, which started in early 2010. Many people contributed to 5738 this project and the idea of the Autonomic Control Plane, amongst 5739 which (in alphabetical order): Ignas Bagdonas, Parag Bhide, Balaji 5740 BL, Alex Clemm, Yves Hertoghs, Bruno Klauser, Max Pritikin, Michael 5741 Richardson, Ravi Kumar Vadapalli. 5743 Special thanks to Brian Carpenter, Elwyn Davies, Joel Halpern and 5744 Sheng Jiang for their thorough reviews and to Pascal Thubert and 5745 Michael Richardson to provide the details for the recommendations of 5746 the use of RPL in the ACP. 5748 Many thanks Ben Kaduk and Eric Rescorla for their thorough SEC AD 5749 reviews and to Valery Smyslov, Tero Kivinen, Paul Wouters and Yoav 5750 Nir for review of IPsec and IKEv2 parameters and helping to 5751 understand those and other security protocol details better. 5753 Further input, review or suggestions were received from: Rene Struik, 5754 Brian Carpenter, Benoit Claise, William Atwood and Yongkang Zhang. 5756 14. Change log [RFC Editor: Please remove] 5758 14.1. Summary of changes since entering IESG review 5760 This text replaces the prior changelog with a summary to provide 5761 guidance for further IESG review. 5763 Please see revision -21 for the individual changelogs of prior 5764 versions . 5766 14.1.1. Reviews (while in IESG review status) / status 5768 This document entered IESG review with version -13. It has since 5769 seen the following reviews: 5771 IESG: Original owner/Yes: Terry Manderson (INT). 5773 IESG: No Objection: Deborah Brungard (RTG), Alissa Cooper (GEN), 5774 Warren Kumari (OPS), Mirja Kuehlewind (TSV), Alexey Melnikov (ART), 5775 Adam Roach (ART). 5777 IESG: No Objection, not counted anymore as they have left IESG: Ben 5778 Campbell (ART), Spencer Dawkins (TSV). 5780 IESG: Open DISCUSS hopefully resolved by this version: Eric Rescorla 5781 (SEC, left IESG), Benjamin Kaduk (SEC). 5783 Other: Michael Richardson (WG), Brian Carpenter (WG), Pascal Thubert 5784 (WG), Frank Xialiang (WG), Elwyn Davies (GEN), Joel Halpern (RTGdir), 5785 Yongkang Zhang (WG), William Atwood (WG). 5787 14.1.2. BRSKI / ACP registrar related enhancements 5789 Only after ACP entered IESG review did it become clear that the in- 5790 progress BRSKI document would not provide all the explanations needed 5791 for ACP registrars as expected earlier by ACP authors. Instead, 5792 BRSKI will only specify a subset of required ACP behavior related to 5793 certificate handling and registrar. There, it became clear that the 5794 ACP draft should specify generic ACP registrar behavior independent 5795 of BRSKI so ACP could be implemented with or without BRSKI and any 5796 manual/proprietary or future standardized BRSKI alternatives (for 5797 example via NetConf) would understand the requirements for ACP 5798 registrars and its certificate handling. 5800 This lead to additional text about ACP registrars in the ACP 5801 document: 5803 1. Defined relationship ACP / ANI (ANI = ACP + BRSKI). 5805 6.1.4 (new) Overview of TA required for ACP. 5807 6.1.5.5 Added explanations/requirements for Re-enrolment. 5809 6.10.7 Normative requirements for ACP registrars (BRSKI or not). 5811 10.2 Operational expectations against ACP registrars (BRSKI or not). 5813 14.1.3. Normative enhancements since start of IESG review 5815 In addition to above ACP registrar / BRSKI related enhancements there 5816 is a range of minor normative (also explanatory) enhancements since 5817 the start of IESG review: 5819 6.1.1 Hex digits in ACP domain information field now upper-case (no 5820 specific reason except that both options are equally good, but 5821 capitalized ones are used in rfc5234). 5823 6.1.5.3 Added explanations about CRLs. 5825 6.1.5.6 Added explanations of behavior under failing certificates. 5827 6.1.2 Allow ACP adddress '0' in ACP domain information field: 5828 presence of address indicates permission to build ACP secure channel 5829 to node, 0 indicates that the address of the node is assigned by 5830 (future) other means than certificate. Non-autonomic nodes have no 5831 address at all (that was in -13), and can only connect via ACP 5832 connect interfaces to ACP. 5834 6.1.3 Distinction of real ACP nodes (with address) and those with 5835 domain certificate without address added as a new rule to ACP domain 5836 membership check. 5838 6.6 Added throttling of secure-channel setup attempts. 5840 6.11.1.14 Removed requirement to handle unknown destination ACP 5841 traffic in low-end nodes that would never be RPL roots. 5843 6.12.5 Added recommendation to use IPv6 DAD. 5845 6.1.1, 6.7.1.1, 6.7.2, 6.7.3, 6.8.2 Various refined additional 5846 certificate, secure channel protocol (IPsec/IKEv2 and DTLS) and ACP 5847 GRASP TLS protocol parameter requirements to ensure interoperating 5848 implementations (from SEC-AD review). 5850 14.1.4. Explanatory enhancements since start of IESG review 5852 Beyond the functional enhancements from the previous two sections, 5853 the mayority of changes since -13 are additional explanations from 5854 review feedback, textual nits and restructuring - with no functional 5855 requirement additions/changes. 5857 1.1 Added "applicability and scope" section with summarized 5858 explanations. 5860 2.Added in-band vs. out-of-band management definitions. 5862 6.1.2 (was 6.1.1) expanded explanations of reasoning for elements of 5863 the ACP domain information field. 5865 6.1.3 refined explanations of ACP domain membership check and 5866 justifications for it. 5868 6.5 Elaborated step-by-step secure channel setup. 5870 6.10 Additional explanations for addressing modes, additional table 5871 of addressing formats (thanks MichaelR). 5873 6.10.5 introduced 'F' bit position as a better visual representation 5874 in the Vlong address space. 5876 6.11.1.1 extensive overhaul to improve readability of use of RPL 5877 (from IESG feedback of non-routing/RPL experts). 5879 6.12.2 Added caution about unconfiguring Data-Plane IPv6 addresses 5880 and impact to ACP (limitation of current ACP design, and pointint to 5881 more details in 10.2). 5883 10.4 New explanations / summary of configurations for ACP (aka: all 5884 config is undesirable and only required for integrating with non- 5885 autonomic components, primarily ACP-connect and Registrars). 5887 11. Textually enhanced / better structured security considerations 5888 section after IESG security review. 5890 A. (new) Moved all explanations and discussions about futures from 5891 section 10 into this new appendix. This text should not be removed 5892 because it captures a lot of repeated asked questions in WG and 5893 during reviews and from users, and also captures ideas for some 5894 likely important followup work. But none of this is relevant to 5895 implementing (section 6) and operating (section 10) the ACP. 5897 14.2. draft-ietf-anima-autonomic-control-plane-27 5899 Too many revisions with too many fixes. Lets do a one-word change 5900 revision for a change now if it helps to accelerate the review 5901 process. 5903 Added "subjectAltName /" to make it unambiguous that AcpNodeName is 5904 indeed a SAN (from Russ). 5906 14.3. draft-ietf-anima-autonomic-control-plane-26 5908 Russ Housley review of -25. 5910 1.1 Explicit reference for TLS 1.2 RFC. 5912 2. Changed term of "ACP Domain Information" to AcpNodeName (ASN.1) / 5913 acp-node-name (ABNF), also through rest of document. 5915 2. Improved CA behavior definition. changed IDevID/LDevID to IDevID/ 5916 LDevID certificate to be more unambiguous. 5918 2. Changed definition of root CA to just refer to how its used in 5919 RFC7030 CA root key update, because thats the only thing relevant to 5920 ACP. 5922 6.1.1 Moved ECDH requirement to end of text as it was not related to 5923 the subject of the initial paragraps. Likewise reference to 5924 CABFORUM. 5926 6.1.1 Reduced cert key requirements to only be MUST for certs with 5927 2048 RSA public key and P-256 curves. Reduced longer keys to SHOULD. 5929 6.1.2 Changed text for conversion from rfc822Name to otherName / 5930 AcpNode, removed all the explanations of benefits coming with 5931 rfc822Name *sob* *sob* *sob*. 5933 6.1.2.1 New ASN.1 definition for otherName / AcpNodeName. 5935 6.1.3 Fixed up text. re the handling of missing connectivity for 5936 CRLDP / OCSP. 5938 6.1.4 Fixed up text re. inability to use public CA to situation with 5939 otherName / AcpNodeName (no more ACME rfc822Name validation for us 5940 *sob* *sob* *sob*). 5942 12. Added ASN.1 registration requests to IANA section. 5944 Appenices. Minor changes for rfc822Name to otherName change. 5946 Various minor verbal fixes/enhancements. 5948 14.4. draft-ietf-anima-autonomic-control-plane-25 5950 Crypto parameter discuss from Valery Smyslov and Paul Wouters and 5951 resulting changes. 5953 6.7.2 Moved Michael Richardson suggested diagnostic of signaling TA 5954 from IPsec section to this general requirements section and added 5955 explanation how this may be inappropriate if TA payload is considered 5956 secret by TA owner. 5958 6.7.3.1 Added traffic selectors for native IPsec. Improved text 5959 explanation. 5961 6.7.3.1.2 removed misleading text about signaling TA when using 5962 intermediate certs. 5964 6.7.3.1.2 Removed requirement for 'PKCS #7 wrapped X.509 certificate' 5965 requirement on request of Valery Smyslov as it is not defined in 5966 RFC7296 and there are enough options mandated in RFC7296. Replaced 5967 with just informative text to educate readers who are not IPsec 5968 experts what the mandatory option in RFC7296 is that allows to signal 5969 certificates. 5971 6.7.3.1.2 Added SHOULD requirement how to deal with CERTREQ so that 5972 6.7.2 requirement for TA diagnostics will work in IKEv2 (ignoring 5973 CERTREQ is permitted by IKEv2). Added explanation how this will 5974 result in TA cert diagnostics. 5976 6.7.3.1.2 Added requirement for IKEv2 to operate on link-local 5977 addresses for ACP so at to assume ACT cert as the only possible 5978 authenticator - to avoid potentialy failing section from multiple 5979 available certs on a router. 5981 6.7.3.1.2 fixed PKIX- style OID to ASN.1 object AlgorithmIdentifier 5982 (Paul). 5984 6.7.3.2 Added IPsec traffic selectors for IPsec with GRE. 5986 6.7.5 Added notion that IPsec/GRE MAY be preferred over IPsec/native. 5987 Luckily IPsec/native uses tunneling, whereas IPsec/GRE uses transport 5988 mode, and there is a long discuss whether it is permitted to even 5989 build IPsec connectings that only support transports instead of 5990 always being able to fall back to tunnel mode. Added explanatory 5991 paragraph why ACP nodes may prefer GRE over native (wonder how that 5992 was missing..). 5994 9.1.1 Added section to explain need for secure channel peer 5995 diagnostics via signaling of TA. Four examples given. 5997 Paul Wouters mentioned that ipkcs7 had to be used in some interop 5998 cases with windows CA, but that is an issue of ACP Registrar having 5999 to convert into PKCS#7 to talk to a windows CA, and this spec is not 6000 concerned with that, except to know that it is feasible, so not 6001 mentioned in text anywhere, just tracking discussion here in 6002 changelog. 6004 Michael Richardson: 6006 3.1.3 Added point in support of rfc822address that CA may not support 6007 to sign certificates with new attributes (such as new otherName). 6009 Michael Richardson/Brian Carpenter fix: 6011 6.1.5.1/6.3 Fixed GRASP examples. 6013 Joe Halpern review: 6015 1. Enhanded introduction text for in-band and of out-of-band, 6016 explaining how ACP is an in-band network aiming to achieve all 6017 possible benefits of an out-of-band network. 6019 1. Comprehensive explanation for term Data-Plane as it is only 6020 logically following pre-established terminology on a fully autonomic 6021 node, when used for existing nodes augmented with ACP, Data-Plane has 6022 more functionality than usually associated with the term. 6024 2. Removed explanatory text for Data-Plane, referring to section 1. 6026 2. Reduced explanation in definition of in-band (management/ 6027 signaling), out-of-band-signaling, now pointing to section 1. 6029 5. Rewrote a lot of the steps (overview) as this text was not 6030 reviewed for long time. Added references to normative section for 6031 each step to hopefully avoid feedback of not explaining terms used 6032 (really not possible to give good summary without using forward 6033 references). 6035 2. Separate out-of-band-management definition from virtual out-of- 6036 band-management definition (later one for ACP). 6038 2. Added definitions for RPI and RPL. 6040 6.1.1. added note about end-to-end authentication to distinguish 6041 channel security from overall ACP security model. 6043 6.5 Fixed bugs in channel selection signaling step description (Alice 6044 vs. Bob). 6046 6.7.1 Removed redundant channel selection explanation. 6048 6.10.3 remove locator/identifier terminology from zone addressing 6049 scheme description (unnecessary), removed explanations (now in 9.4), 6050 simplified text, clarified requirement for Node-ID to be unique, 6051 recommend to use primarily zone 0. 6053 6.10.3.1 Removed. Included a lot of insufficient suggestions for 6054 future stanards extensions, most of it was wrong or would need to be 6055 revisited by WG anyhow. Idea now (just here for comment): Announce 6056 via GRASP Zone-ID (e.g.: from per-zone edge-node/registrar) into a 6057 zone of the ACP so all nodes supporting the scheme can automatically 6058 self-allocate the Zone-ID. 6060 6.11.1.1 (RPL overview), eliminated redundant text. 6062 6.11.1.1.1 New subsection to better structure overview. 6064 6.11.1.1.2 New subsection to better group overview, replaced TTL 6065 explanation (just the symptom) with hopefully better reconvergence 6066 text (intent of the profile) for the ACP RPL profile. 6068 6.11.1.1.6 Added text to explain simple choice for rank_factor. 6070 6.11.1.13 moved explanation for RPI up into 6.11.1.1. 6072 6.12.5.1 rewrote section for ACP Loopback Interface. 6074 9.4 New informative/informational section for partial or incremental 6075 adoption of ACP to help understand why there is the Zone interface 6076 sub-scheme, and how to use it. 6078 Unrelated fixes: 6080 Ask to RFC editor to add most important abbreviations to RFC editor 6081 abbreviation list. 6083 6.10.2 changed names in ACP addressing scheme table to be less 6084 suggestive of use. 6086 Russ Hously review: 6088 2. Fixed definition of "Enrollment", "Trust Anchor", "CA", and "root 6089 CA". Changed "Certificate Authority" to "Certification Authority" 6090 throughout the document (correct term according to X.509). 6092 6.1 Fixed explanation of mutual ACP trust. 6094 6.1.1 s/X509/X509v3/. 6096 6.1.2 created bulleted lists for explanations and justifications for 6097 choices of ACP domain certificate encoding. No semantic changes, 6098 just to make it easier to refer to the points in discussions (rfcdiff 6099 seems to have a bug showing text differences due to formatting 6100 changes). 6102 6.1.3 Moved content of rule #1 into previous rule #2 because 6103 certification chain validation does imply validation of lifetime. 6104 numbers of all rules reduced by 1, changed hopefully all references 6105 to the rule numbers in the document. 6107 Rule #3, Hopefully fixed linguistic problem self-contradiction of 6108 MUST by lower casing MUST in the explanation part and rewriting the 6109 condition when this is not applicable. 6111 6.1.4 Replaced redundant term "Trust Point" (TP) with Trust Anchor 6112 (TA"). Replaced throughout document Trust Anchor with abbreviation 6113 TA. 6115 Enhanced several sentences/rewrote paragraphs to make explanations 6116 clearer. 6118 6.6 Added explanation how ACP nodes must throttle their attempts for 6119 connection making purely on the result of their own connection 6120 attempts, not based on those connections where they are responder. 6122 14.5. draft-ietf-anima-autonomic-control-plane-24 6124 Leftover from -23 review by Eric Vyncke: 6126 Swapping sections 9 and 10, section 9 was meant to be at end of 6127 document and summarize. Its not meant to be misinterpreted as 6128 introducing any new information. This did happen because section 10 6129 was added after section 9. 6131 14.6. draft-ietf-anima-autonomic-control-plane-23 6133 Note: big rfcdiff of TOC is an rfcdiff bug, changes really minimal. 6135 Review of IPsec security with Mcr and ipsec mailing list. 6137 6.7.1 - new section: Moved general considerations for secure channel 6138 protocols here, refined them. 6140 6.7.2 - new section: Moved common requirements for secure channel 6141 protocols here, refined them. 6143 6.7.3.1.1. - improved requirements text related to RFC8221, better 6144 explamations re. HW acceleration issues. 6146 6.7.3.1.2. - improved requirements text related to RFC8247, (some 6147 requirements still discussed to be redundant, will be finalized in 6148 next weeks. 6150 Eric Vyncke review of -21: 6152 Only noting most important changes, long list of smaller text/ 6153 readability enhancements. 6155 2. - New explanation of "normative" , "informational" section title 6156 tags. alphabetic reordering of terms, refined definitions for CA, 6157 CRL. root CA. 6159 6.1.1. - explanation when IDevID parameters may be copied into 6160 LDevID. 6162 6.1.2. - Fixed hex digits in ACP domain information to lower case. 6164 6.1.3.1. - New section on Realtime clock and Time Validation. 6166 6.3 - Added explanation that DTLS means >= version 1.2 (not only 6167 1.2). 6169 6.7 - New text in this main section explaing relationship of ACP 6170 secure channels and ACP virtual interfaces - with forward references 6171 to virtual interface section. 6173 6.8.2 - reordered text and picture, no text change. 6175 6.10.7.2 - describe first how Registrar-ID can be allocted for all 6176 type of registrars, then refined text for how to potentially use MAC 6177 addresses on physical registrars. 6179 6.11.1.1 - Added text how this profile does not use Data-Plane 6180 artefacts (RPI) because hadware forwarding. This was previously 6181 hidden only later in the text. 6183 6.11.1.13. - Rewrote RPL Data-Plane artefact text. Provide decoder 6184 ring for abbreviations and all relevant RFCs. 6186 6.12.5.2. - Added more explicit text that secure channels are mapped 6187 into virtual interfaces, moved different type of interfaces used by 6188 ACP into seperate subsections to be able to refer to them. 6190 7.2 - Rewrote/refined text for ACP on L2, prior text was confusing 6191 and did not well explain why ACP for L2/L3 switches can be 6192 implemented without any L2 (HW) changes. Also missing explanation of 6193 only running GRASP untagged when VLANs are used. 6195 8.1.1 - Added requirement for ACP Edge nodes to allow configurable 6196 filtering of IPv6 RPI headers. 6198 11. - (security section). Moved explanation of address stealing from 6199 7.2 to here. 6201 14.7. draft-ietf-anima-autonomic-control-plane-22 6203 Ben Kaduk review of -21: 6205 RFC822 encoding of ACP domain information: 6207 6.1.2 rewrote text for explaining / justifying use of rfc822name as 6208 identifier for node CP in certificate (was discussed in thread, but 6209 badly written in prior versions). 6211 6.1.2 Changed EBNF syntax to use "+" after rfcSELF because that is 6212 the known primary name to extensions separator in many email systems 6213 ("." was wrong in prior versions). 6215 6.1.2 Rewrote/improved explanations for use of rfc822name field to 6216 explain better why it is PKIX compliant and the right thing to do. 6218 Crypto parameters for IPsec: 6220 6.1 - Added explanation of why manual keying for ACP is not feasible 6221 for ACP. Surprisingly, that text did not exist. Referred to by 6222 IPsec text (6.7.1), but here is the right place to describe the 6223 reasoning. 6225 6.1.2 - Small textual refinement referring to requirements to 6226 authenticate peers (for the special cases of empty or '0' ACP address 6227 in ACP domain information field. 6229 6.3 - To better justify Bens proposed change of secure channel 6230 protocol being IPsec vs. GRASP objective being IKEv2, better 6231 explained how protocol indicated in GRASP objective-value is name of 6232 protocol used to negotiate secure channel, use example of IKEv2 to 6233 negotiate IPsec. 6235 6.7.1 - refinemenet similar to 6.3. 6237 - moved new paragraph from Bens pull request up from 6.7.1.1 to 6.7.1 6238 as it equally applies to GRE encapped IPsec (looks nicer one level 6239 up). 6241 - created subsections 6.7.1.1 (IPsec/ESP) / 6.7.1.2 (IKEv2) to 6242 clearer distinguish between these two requirements blocks. 6244 - Refined the text in these two sections to hopefully be a good 6245 answer to Valery's concern of not randomnly mocking with existing 6246 requirements docs (rfc8247 / rfc8221). 6248 6.7.1.1.1 - IPsec/ESP requirements section: 6250 - MUST support rfc8221 mandatory EXCEPT for the superceeding 6251 requirements in this section. Previously, this was not quite clear 6252 from the text. 6254 - Hopefully persuasive explanations about the requirements levels for 6255 ENCR_AES_GCM_16, ENCR_AES_CBC, ENCR_AES_CCM_8 and 6256 ENCR_CHACHA20_POLY1305: Restructured text for why not ENCR_AES_CBC 6257 (was in prior version, just not well structured), added new 6258 expanations for ENCR_AES_CCM_8 and ENCR_CHACHA20_POLY130. 6260 - In simple terms, requirements for ENCR_AES_CBC, ENCR_AES_CCM_8, 6261 ENCR_CHACHACHA are SHOULD when they are implementable with rqual or 6262 faster performancce than ENCR_AES_GCM_16. 6264 - Removed text about "additional rfc8221" reqiurements MAY be used. 6265 Now the logic is that all other requirements apply. Hopefully we 6266 have written enough so that we prohibited downgrades. 6268 6.7.1.1.2 - RFC8247 requirements: 6270 - Added mandate to support rfc8247, added explanation that there is 6271 no "stripping down" requirement, just additional stronger 6272 requirements to mandate correct use of ACP certificartes during 6273 authentication. 6275 - refined text on identifying ACP by IPv6 address to be clearer: 6276 Identifying in the context of IKEv2 and cases for '0' in ACP domain 6277 information. 6279 - removed last two paragraphs about relationship to rfc8247, as his 6280 is now written in first paragraph of the section. 6282 End of Ben Kaduk review related fixes. 6284 Other: 6286 Forgot to update example of ACP domain information to use capitalized 6287 hex-digits as required by HEXDIGIT used. 6289 Added reference to RFC8316 (AN use-cases) to beginning of section 3 6290 (ACP use cases). 6292 Small Enhanced IPsec parameters description / requirements fixes 6293 (from Michael Richardson). 6295 15. References 6297 15.1. Normative References 6299 [I-D.ietf-anima-grasp] 6300 Bormann, C., Carpenter, B., and B. Liu, "A Generic 6301 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 6302 grasp-15 (work in progress), July 2017. 6304 [IKEV2IANA] 6305 IANA, "Internet Key Exchange Version 2 (IKEv2) 6306 Parameters", . 6309 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 6310 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 6311 . 6313 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 6314 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 6315 DOI 10.17487/RFC3810, June 2004, 6316 . 6318 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 6319 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 6320 November 2005, . 6322 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 6323 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 6324 . 6326 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 6327 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 6328 2006, . 6330 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 6331 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 6332 December 2005, . 6334 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 6335 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 6336 DOI 10.17487/RFC4861, September 2007, 6337 . 6339 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 6340 Address Autoconfiguration", RFC 4862, 6341 DOI 10.17487/RFC4862, September 2007, 6342 . 6344 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 6345 Specifications: ABNF", STD 68, RFC 5234, 6346 DOI 10.17487/RFC5234, January 2008, 6347 . 6349 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 6350 (TLS) Protocol Version 1.2", RFC 5246, 6351 DOI 10.17487/RFC5246, August 2008, 6352 . 6354 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 6355 Housley, R., and W. Polk, "Internet X.509 Public Key 6356 Infrastructure Certificate and Certificate Revocation List 6357 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 6358 . 6360 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 6361 DOI 10.17487/RFC5321, October 2008, 6362 . 6364 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 6365 DOI 10.17487/RFC5322, October 2008, 6366 . 6368 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 6369 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 6370 January 2012, . 6372 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 6373 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 6374 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 6375 Low-Power and Lossy Networks", RFC 6550, 6376 DOI 10.17487/RFC6550, March 2012, 6377 . 6379 [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing 6380 Protocol for Low-Power and Lossy Networks (RPL)", 6381 RFC 6552, DOI 10.17487/RFC6552, March 2012, 6382 . 6384 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 6385 Power and Lossy Networks (RPL) Option for Carrying RPL 6386 Information in Data-Plane Datagrams", RFC 6553, 6387 DOI 10.17487/RFC6553, March 2012, 6388 . 6390 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 6391 "Enrollment over Secure Transport", RFC 7030, 6392 DOI 10.17487/RFC7030, October 2013, 6393 . 6395 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 6396 Kivinen, "Internet Key Exchange Protocol Version 2 6397 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 6398 2014, . 6400 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 6401 "Recommendations for Secure Use of Transport Layer 6402 Security (TLS) and Datagram Transport Layer Security 6403 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 6404 2015, . 6406 [RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support 6407 for Generic Routing Encapsulation (GRE)", RFC 7676, 6408 DOI 10.17487/RFC7676, October 2015, 6409 . 6411 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 6412 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 6413 May 2017, . 6415 [RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T. 6416 Kivinen, "Cryptographic Algorithm Implementation 6417 Requirements and Usage Guidance for Encapsulating Security 6418 Payload (ESP) and Authentication Header (AH)", RFC 8221, 6419 DOI 10.17487/RFC8221, October 2017, 6420 . 6422 [RFC8247] Nir, Y., Kivinen, T., Wouters, P., and D. Migault, 6423 "Algorithm Implementation Requirements and Usage Guidance 6424 for the Internet Key Exchange Protocol Version 2 (IKEv2)", 6425 RFC 8247, DOI 10.17487/RFC8247, September 2017, 6426 . 6428 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 6429 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 6430 . 6432 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 6433 Definition Language (CDDL): A Notational Convention to 6434 Express Concise Binary Object Representation (CBOR) and 6435 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 6436 June 2019, . 6438 15.2. Informative References 6440 [AR8021] Group, W. -. H. L. L. P. W., "IEEE Standard for Local and 6441 metropolitan area networks - Secure Device Identity", 6442 December 2009, . 6445 [CABFORUM] 6446 CA/Browser Forum, "Certificate Contents for Baseline SSL", 6447 Nov 2019, . 6450 [I-D.eckert-anima-noc-autoconfig] 6451 Eckert, T., "Autoconfiguration of NOC services in ACP 6452 networks via GRASP", draft-eckert-anima-noc-autoconfig-00 6453 (work in progress), July 2018. 6455 [I-D.ietf-acme-star] 6456 Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T. 6457 Fossati, "Support for Short-Term, Automatically-Renewed 6458 (STAR) Certificates in Automated Certificate Management 6459 Environment (ACME)", draft-ietf-acme-star-11 (work in 6460 progress), October 2019. 6462 [I-D.ietf-anima-bootstrapping-keyinfra] 6463 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 6464 and K. Watsen, "Bootstrapping Remote Secure Key 6465 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 6466 keyinfra-41 (work in progress), April 2020. 6468 [I-D.ietf-anima-prefix-management] 6469 Jiang, S., Du, Z., Carpenter, B., and Q. Sun, "Autonomic 6470 IPv6 Edge Prefix Management in Large-scale Networks", 6471 draft-ietf-anima-prefix-management-07 (work in progress), 6472 December 2017. 6474 [I-D.ietf-anima-reference-model] 6475 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 6476 and J. Nobre, "A Reference Model for Autonomic 6477 Networking", draft-ietf-anima-reference-model-10 (work in 6478 progress), November 2018. 6480 [I-D.ietf-roll-applicability-template] 6481 Richardson, M., "ROLL Applicability Statement Template", 6482 draft-ietf-roll-applicability-template-09 (work in 6483 progress), May 2016. 6485 [I-D.ietf-roll-useofrplinfo] 6486 Robles, I., Richardson, M., and P. Thubert, "Using RPI 6487 Option Type, Routing Header for Source Routes and IPv6-in- 6488 IPv6 encapsulation in the RPL Data Plane", draft-ietf- 6489 roll-useofrplinfo-39 (work in progress), June 2020. 6491 [I-D.ietf-tls-dtls13] 6492 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 6493 Datagram Transport Layer Security (DTLS) Protocol Version 6494 1.3", draft-ietf-tls-dtls13-38 (work in progress), May 6495 2020. 6497 [IEEE-1588-2008] 6498 IEEE, "IEEE Standard for a Precision Clock Synchronization 6499 Protocol for Networked Measurement and Control Systems", 6500 December 2008, . 6503 [IEEE-802.1X] 6504 Group, W. -. H. L. L. P. W., "IEEE Standard for Local and 6505 Metropolitan Area Networks: Port-Based Network Access 6506 Control", February 2010, 6507 . 6510 [LLDP] Group, W. -. H. L. L. P. W., "IEEE Standard for Local and 6511 Metropolitan Area Networks: Station and Media Access 6512 Control Connectivity Discovery", June 2016, 6513 . 6516 [MACSEC] Group, W. -. H. L. L. P. W., "IEEE Standard for Local and 6517 Metropolitan Area Networks: Media Access Control (MAC) 6518 Security", June 2006, 6519 . 6522 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 6523 RFC 1112, DOI 10.17487/RFC1112, August 1989, 6524 . 6526 [RFC1492] Finseth, C., "An Access Control Protocol, Sometimes Called 6527 TACACS", RFC 1492, DOI 10.17487/RFC1492, July 1993, 6528 . 6530 [RFC1654] Rekhter, Y., Ed. and T. Li, Ed., "A Border Gateway 6531 Protocol 4 (BGP-4)", RFC 1654, DOI 10.17487/RFC1654, July 6532 1994, . 6534 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 6535 and E. Lear, "Address Allocation for Private Internets", 6536 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 6537 . 6539 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 6540 Requirement Levels", BCP 14, RFC 2119, 6541 DOI 10.17487/RFC2119, March 1997, 6542 . 6544 [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax 6545 Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998, 6546 . 6548 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 6549 (IKE)", RFC 2409, DOI 10.17487/RFC2409, November 1998, 6550 . 6552 [RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", 6553 RFC 2821, DOI 10.17487/RFC2821, April 2001, 6554 . 6556 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 6557 "Remote Authentication Dial In User Service (RADIUS)", 6558 RFC 2865, DOI 10.17487/RFC2865, June 2000, 6559 . 6561 [RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, 6562 DOI 10.17487/RFC3164, August 2001, 6563 . 6565 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 6566 C., and M. Carney, "Dynamic Host Configuration Protocol 6567 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 6568 2003, . 6570 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 6571 Architecture for Describing Simple Network Management 6572 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 6573 DOI 10.17487/RFC3411, December 2002, 6574 . 6576 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 6577 "DNS Extensions to Support IP Version 6", STD 88, 6578 RFC 3596, DOI 10.17487/RFC3596, October 2003, 6579 . 6581 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 6582 Protocol (XMPP): Core", RFC 3920, DOI 10.17487/RFC3920, 6583 October 2004, . 6585 [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export 6586 Version 9", RFC 3954, DOI 10.17487/RFC3954, October 2004, 6587 . 6589 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 6590 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 6591 DOI 10.17487/RFC4007, March 2005, 6592 . 6594 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 6595 "Internet X.509 Public Key Infrastructure Certificate 6596 Management Protocol (CMP)", RFC 4210, 6597 DOI 10.17487/RFC4210, September 2005, 6598 . 6600 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 6601 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 6602 2006, . 6604 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 6605 for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, 6606 . 6608 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 6609 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 6610 for Transport Layer Security (TLS)", RFC 4492, 6611 DOI 10.17487/RFC4492, May 2006, 6612 . 6614 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 6615 "Considerations for Internet Group Management Protocol 6616 (IGMP) and Multicast Listener Discovery (MLD) Snooping 6617 Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, 6618 . 6620 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 6621 Group Management Protocol Version 3 (IGMPv3) and Multicast 6622 Listener Discovery Protocol Version 2 (MLDv2) for Source- 6623 Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, 6624 August 2006, . 6626 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 6627 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 6628 . 6630 [RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol 6631 Independent Multicast (PIM)", RFC 4610, 6632 DOI 10.17487/RFC4610, August 2006, 6633 . 6635 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 6636 Extensions for Stateless Address Autoconfiguration in 6637 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 6638 . 6640 [RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure 6641 Subject Alternative Name for Expression of Service Name", 6642 RFC 4985, DOI 10.17487/RFC4985, August 2007, 6643 . 6645 [RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet 6646 Group Management Protocol Version 3 (IGMPv3) and Multicast 6647 Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, 6648 DOI 10.17487/RFC5790, February 2010, 6649 . 6651 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 6652 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 6653 . 6655 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 6656 "Network Time Protocol Version 4: Protocol and Algorithms 6657 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 6658 . 6660 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 6661 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 6662 DOI 10.17487/RFC5912, June 2010, 6663 . 6665 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 6666 and A. Bierman, Ed., "Network Configuration Protocol 6667 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 6668 . 6670 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 6671 Cheshire, "Internet Assigned Numbers Authority (IANA) 6672 Procedures for the Management of the Service Name and 6673 Transport Protocol Port Number Registry", BCP 165, 6674 RFC 6335, DOI 10.17487/RFC6335, August 2011, 6675 . 6677 [RFC6402] Schaad, J., "Certificate Management over CMS (CMC) 6678 Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011, 6679 . 6681 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 6682 of Interpretation", RFC 6407, DOI 10.17487/RFC6407, 6683 October 2011, . 6685 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 6686 Routing Header for Source Routes with the Routing Protocol 6687 for Low-Power and Lossy Networks (RPL)", RFC 6554, 6688 DOI 10.17487/RFC6554, March 2012, 6689 . 6691 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 6692 "Default Address Selection for Internet Protocol Version 6 6693 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 6694 . 6696 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 6697 Ed., "Diameter Base Protocol", RFC 6733, 6698 DOI 10.17487/RFC6733, October 2012, 6699 . 6701 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 6702 DOI 10.17487/RFC6762, February 2013, 6703 . 6705 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 6706 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 6707 . 6709 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 6710 "TCP Extensions for Multipath Operation with Multiple 6711 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 6712 . 6714 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 6715 Locator/ID Separation Protocol (LISP)", RFC 6830, 6716 DOI 10.17487/RFC6830, January 2013, 6717 . 6719 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 6720 "Specification of the IP Flow Information Export (IPFIX) 6721 Protocol for the Exchange of Flow Information", STD 77, 6722 RFC 7011, DOI 10.17487/RFC7011, September 2013, 6723 . 6725 [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local 6726 Addressing inside an IPv6 Network", RFC 7404, 6727 DOI 10.17487/RFC7404, November 2014, 6728 . 6730 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 6731 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 6732 Defined Networking (SDN): Layers and Architecture 6733 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 6734 2015, . 6736 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 6737 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 6738 Networking: Definitions and Design Goals", RFC 7575, 6739 DOI 10.17487/RFC7575, June 2015, 6740 . 6742 [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap 6743 Analysis for Autonomic Networking", RFC 7576, 6744 DOI 10.17487/RFC7576, June 2015, 6745 . 6747 [RFC7585] Winter, S. and M. McCauley, "Dynamic Peer Discovery for 6748 RADIUS/TLS and RADIUS/DTLS Based on the Network Access 6749 Identifier (NAI)", RFC 7585, DOI 10.17487/RFC7585, October 6750 2015, . 6752 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 6753 Considerations for IPv6 Address Generation Mechanisms", 6754 RFC 7721, DOI 10.17487/RFC7721, March 2016, 6755 . 6757 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 6758 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 6759 Multicast - Sparse Mode (PIM-SM): Protocol Specification 6760 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 6761 2016, . 6763 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 6764 RFC 7950, DOI 10.17487/RFC7950, August 2016, 6765 . 6767 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 6768 Hosts in a Multi-Prefix Network", RFC 8028, 6769 DOI 10.17487/RFC8028, November 2016, 6770 . 6772 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 6773 Writing an IANA Considerations Section in RFCs", BCP 26, 6774 RFC 8126, DOI 10.17487/RFC8126, June 2017, 6775 . 6777 [RFC8316] Nobre, J., Granville, L., Clemm, A., and A. Gonzalez 6778 Prieto, "Autonomic Networking Use Case for Distributed 6779 Detection of Service Level Agreement (SLA) Violations", 6780 RFC 8316, DOI 10.17487/RFC8316, February 2018, 6781 . 6783 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 6784 "A Voucher Artifact for Bootstrapping Protocols", 6785 RFC 8366, DOI 10.17487/RFC8366, May 2018, 6786 . 6788 [RFC8368] Eckert, T., Ed. and M. Behringer, "Using an Autonomic 6789 Control Plane for Stable Connectivity of Network 6790 Operations, Administration, and Maintenance (OAM)", 6791 RFC 8368, DOI 10.17487/RFC8368, May 2018, 6792 . 6794 [RFC8398] Melnikov, A., Ed. and W. Chuang, Ed., "Internationalized 6795 Email Addresses in X.509 Certificates", RFC 8398, 6796 DOI 10.17487/RFC8398, May 2018, 6797 . 6799 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 6800 Decraene, B., Litkowski, S., and R. Shakir, "Segment 6801 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 6802 July 2018, . 6804 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 6805 Touch Provisioning (SZTP)", RFC 8572, 6806 DOI 10.17487/RFC8572, April 2019, 6807 . 6809 [X.509] International Telecommunication Union, "Information 6810 technology - Open Systems Interconnection - The Directory: 6811 Public-key and attribute certificate frameworks", ITU-T 6812 Recommendation X.509, ISO/IEC 9594-8, October 2016, 6813 . 6815 15.3. URIs 6817 [1] https://en.wikipedia.org/wiki/Operational_Technology 6819 [2] https://en.wikipedia.org/wiki/Single-root_input/ 6820 output_virtualization 6822 Appendix A. Background and Futures (Informative) 6824 The following sections discuss additional background information 6825 about aspects of the normative parts of this document or associated 6826 mechanisms such as BRSKI (such as why specific choices were made by 6827 the ACP) and they provide discussion about possible future variations 6828 of the ACP. 6830 A.1. ACP Address Space Schemes 6832 This document defines the Zone, Vlong and Manual sub address schemes 6833 primarily to support address prefix assignment via distributed, 6834 potentially uncoordinated ACP registrars as defined in 6835 Section 6.10.7. This costs 48/46-bit identifier so that these ACP 6836 registrar can assign non-conflicting address prefixes. This design 6837 does not leave enough bits to simultaneously support a large number 6838 of nodes (Node-ID) plus a large prefix of local addresses for every 6839 node plus a large enough set of bits to identify a routing Zone. In 6840 result, Zone, Vlong 8/16 attempt to support all features, but in via 6841 separate prefixes. 6843 In networks that always expect to rely on a centralized PMS as 6844 described above (Section 9.2.5), the 48/46-bits for the Registrar-ID 6845 could be saved. Such variations of the ACP addressing mechanisms 6846 could be introduced through future work in different ways. If a new 6847 otherName was introduced, incompatible ACP variations could be 6848 created where every design aspect of the ACP could be changed. 6849 Including all addressing choices. If instead a new addressing sub- 6850 type would be defined, it could be a backward compatible extension of 6851 this ACP specification. Information such as the size of a zone- 6852 prefix and the length of the prefix assigned to the ACP node itself 6853 could be encoded via the extension field of the acp-node-name. 6855 Note that an explicitly defined "Manual" addressing sub-scheme is 6856 always beneficial to provide an easy way for ACP nodes to prohibit 6857 incorrect manual configuration of any non-"Manual" ACP address spaces 6858 and therefore ensure that "Manual" operations will never impact 6859 correct routing for any non-"Manual" ACP addresses assigned via ACP 6860 domain certificates. 6862 A.2. BRSKI Bootstrap (ANI) 6864 BRSKI describes how nodes with an IDevID certificate can securely and 6865 zero-touch enroll with an LDevID certificate to support the ACP. 6866 BRSKI also leverages the ACP to enable zero-touch bootstrap of new 6867 nodes across networks without any configuration requirements across 6868 the transit nodes (e.g., no DHCP/DNS forwarding/server setup). This 6869 includes otherwise not configured networks as described in 6870 Section 3.2. Therefore BRSKI in conjunction with ACP provides for a 6871 secure and zero-touch management solution for complete networks. 6872 Nodes supporting such an infrastructure (BRSKI and ACP) are called 6873 ANI nodes (Autonomic Networking Infrastructure), see 6874 [I-D.ietf-anima-reference-model]. Nodes that do not support an 6875 IDevID certiificate but only an (insecure) vendor specific Unique 6876 Device Identifier (UDI) or nodes whose manufacturer does not support 6877 a MASA could use some future security reduced version of BRSKI. 6879 When BRSKI is used to provision a domain certificate (which is called 6880 enrollment), the BRSKI registrar (acting as an enhanced EST server) 6881 must include the otherName / AcpNode encoded ACP address and domain 6882 name to the enrolling node (called pledge) via its response to the 6883 pledges EST CSR Attribute request that is mandatory in BRSKI. 6885 The Certification Authority in an ACP network must not change the 6886 otherName / AcpNode in the certificate. The ACP nodes can therefore 6887 find their ACP address and domain using this field in the domain 6888 certificate, both for themselves, as well as for other nodes. 6890 The use of BRSKI in conjunction with the ACP can also help to further 6891 simplify maintenance and renewal of domain certificates. Instead of 6892 relying on CRL, the lifetime of certificates can be made extremely 6893 small, for example in the order of hours. When a node fails to 6894 connect to the ACP within its certificate lifetime, it cannot connect 6895 to the ACP to renew its certificate across it (using just EST), but 6896 it can still renew its certificate as an "enrolled/expired pledge" 6897 via the BRSKI bootstrap proxy. This requires only that the BRSKI 6898 registrar honors expired domain certificates and that the pledge 6899 attempts to perform TLS authentication for BRSKI bootstrap using its 6900 expired domain certificate before falling back to attempting to use 6901 its IDevID certificate for BRSKI. This mechanism could also render 6902 CRLs unnecessary because the BRSKI registrar in conjunction with the 6903 CA would not renew revoked certificates - only a "Do-not-renew" list 6904 would be necessary on BRSKI registrars/CA. 6906 In the absence of BRSKI or less secure variants thereof, provisioning 6907 of certificates may involve one or more touches or non-standardized 6908 automation. Node vendors usually support provisioning of 6909 certificates into nodes via PKCS#7 (see [RFC2315]) and may support 6910 this provisioning through vendor specific models via Netconf 6911 ([RFC6241]). If such nodes also support Netconf Zero-Touch 6912 ([RFC8572]) then this can be combined to zero-touch provisioning of 6913 domain certificates into nodes. Unless there are equivalent 6914 integration of Netconf connections across the ACP as there is in 6915 BRSKI, this combination would not support zero-touch bootstrap across 6916 a not configured network though. 6918 A.3. ACP Neighbor discovery protocol selection 6920 This section discusses why GRASP DULL was chosen as the discovery 6921 protocol for L2 adjacent candidate ACP neighbors. The contenders 6922 considered where GRASP, mDNS or LLDP. 6924 A.3.1. LLDP 6926 LLDP and Cisco's earlier Cisco Discovery Protocol (CDP) are example 6927 of L2 discovery protocols that terminate their messages on L2 ports. 6928 If those protocols would be chosen for ACP neighbor discovery, ACP 6929 neighbor discovery would therefore also terminate on L2 ports. This 6930 would prevent ACP construction over non-ACP capable but LLDP or CDP 6931 enabled L2 switches. LLDP has extensions using different MAC 6932 addresses and this could have been an option for ACP discovery as 6933 well, but the additional required IEEE standardization and definition 6934 of a profile for such a modified instance of LLDP seemed to be more 6935 work than the benefit of "reusing the existing protocol" LLDP for 6936 this very simple purpose. 6938 A.3.2. mDNS and L2 support 6940 Multicast DNNS (mDNS) [RFC6762] with DNS Service Discovery (DNS-SD) 6941 Resource Records (RRs) as defined in [RFC6763] is a key contender as 6942 an ACP discovery protocol. because it relies on link-local IP 6943 multicast, it does operates at the subnet level, and is also found in 6944 L2 switches. The authors of this document are not aware of mDNS 6945 implementation that terminate their mDNS messages on L2 ports instead 6946 of the subnet level. If mDNS was used as the ACP discovery mechanism 6947 on an ACP capable (L3)/L2 switch as outlined in Section 7, then this 6948 would be necessary to implement. It is likely that termination of 6949 mDNS messages could only be applied to all mDNS messages from such a 6950 port, which would then make it necessary to software forward any non- 6951 ACP related mDNS messages to maintain prior non-ACP mDNS 6952 functionality. Adding support for ACP into such L2 switches with 6953 mDNS could therefore create regression problems for prior mDNS 6954 functionality on those nodes. With low performance of software 6955 forwarding in many L2 switches, this could also make the ACP risky to 6956 support on such L2 switches. 6958 A.3.3. Why DULL GRASP 6960 LLDP was not considered because of the above mentioned issues. mDNS 6961 was not selected because of the above L2 mDNS considerations and 6962 because of the following additional points: 6964 If mDNS was not already existing in a node, it would be more work to 6965 implement than DULL GRASP, and if an existing implementation of mDNS 6966 was used, it would likely be more code space than a separate 6967 implementation of DULL GRASP or a shared implementation of DULL GRASP 6968 and GRASP in the ACP. 6970 A.4. Choice of routing protocol (RPL) 6972 This section motivates why RPL - "IPv6 Routing Protocol for Low-Power 6973 and Lossy Networks ([RFC6550] was chosen as the default (and in this 6974 specification only) routing protocol for the ACP. The choice and 6975 above explained profile was derived from a pre-standard 6976 implementation of ACP that was successfully deployed in operational 6977 networks. 6979 Requirements for routing in the ACP are: 6981 o Self-management: The ACP must build automatically, without human 6982 intervention. Therefore routing protocol must also work 6983 completely automatically. RPL is a simple, self-managing 6984 protocol, which does not require zones or areas; it is also self- 6985 configuring, since configuration is carried as part of the 6986 protocol (see Section 6.7.6 of [RFC6550]). 6988 o Scale: The ACP builds over an entire domain, which could be a 6989 large enterprise or service provider network. The routing 6990 protocol must therefore support domains of 100,000 nodes or more, 6991 ideally without the need for zoning or separation into areas. RPL 6992 has this scale property. This is based on extensive use of 6993 default routing. 6995 o Low resource consumption: The ACP supports traditional network 6996 infrastructure, thus runs in addition to traditional protocols. 6997 The ACP, and specifically the routing protocol must have low 6998 resource consumption both in terms of memory and CPU requirements. 6999 Specifically, at edge nodes, where memory and CPU are scarce, 7000 consumption should be minimal. RPL builds a DODAG, where the main 7001 resource consumption is at the root of the DODAG. The closer to 7002 the edge of the network, the less state needs to be maintained. 7003 This adapts nicely to the typical network design. Also, all 7004 changes below a common parent node are kept below that parent 7005 node. 7007 o Support for unstructured address space: In the Autonomic 7008 Networking Infrastructure, node addresses are identifiers, and may 7009 not be assigned in a topological way. Also, nodes may move 7010 topologically, without changing their address. Therefore, the 7011 routing protocol must support completely unstructured address 7012 space. RPL is specifically made for mobile ad-hoc networks, with 7013 no assumptions on topologically aligned addressing. 7015 o Modularity: To keep the initial implementation small, yet allow 7016 later for more complex methods, it is highly desirable that the 7017 routing protocol has a simple base functionality, but can import 7018 new functional modules if needed. RPL has this property with the 7019 concept of "objective function", which is a plugin to modify 7020 routing behavior. 7022 o Extensibility: Since the Autonomic Networking Infrastructure is a 7023 new concept, it is likely that changes in the way of operation 7024 will happen over time. RPL allows for new objective functions to 7025 be introduced later, which allow changes to the way the routing 7026 protocol creates the DAGs. 7028 o Multi-topology support: It may become necessary in the future to 7029 support more than one DODAG for different purposes, using 7030 different objective functions. RPL allow for the creation of 7031 several parallel DODAGs, should this be required. This could be 7032 used to create different topologies to reach different roots. 7034 o No need for path optimization: RPL does not necessarily compute 7035 the optimal path between any two nodes. However, the ACP does not 7036 require this today, since it carries mainly non-delay-sensitive 7037 feedback loops. It is possible that different optimization 7038 schemes become necessary in the future, but RPL can be expanded 7039 (see point "Extensibility" above). 7041 A.5. ACP Information Distribution and multicast 7043 IP multicast is not used by the ACP because the ANI (Autonomic 7044 Networking Infrastructure) itself does not require IP multicast but 7045 only service announcement/discovery. Using IP multicast for that 7046 would have made it necessary to develop a zero-touch auto configuring 7047 solution for ASM (Any Source Multicast - the original form of IP 7048 multicast defined in [RFC1112]), which would be quite complex and 7049 difficult to justify. One aspect of complexity where no attempt at a 7050 solution has been described in IETF documents is the automatic- 7051 selection of routers that should be PIM Sparse Mode (PIM-SM) 7052 Rendezvous Points (RPs) (see [RFC7761]). The other aspects of 7053 complexity are the implementation of MLD ([RFC4604]), PIM-SM and 7054 Anycast-RP (see [RFC4610]). If those implementations already exist 7055 in a product, then they would be very likely tied to accelerated 7056 forwarding which consumes hardware resources, and that in return is 7057 difficult to justify as a cost of performing only service discovery. 7059 Some future ASA may need high performance in-network data 7060 replication. That is the case when the use of IP multicast is 7061 justified. Such an ASA can then use service discovery from ACP 7062 GRASP, and then they do not need ASM but only SSM (Source Specific 7063 Multicast, see [RFC4607]) for the IP multicast replication. SSM 7064 itself can simply be enabled in the Data-Plane (or even in an update 7065 to the ACP) without any other configuration than just enabling it on 7066 all nodes and only requires a simpler version of MLD (see [RFC5790]). 7068 LSP (Link State Protocol) based IGP routing protocols typically have 7069 a mechanism to flood information, and such a mechanism could be used 7070 to flood GRASP objectives by defining them to be information of that 7071 IGP. This would be a possible optimization in future variations of 7072 the ACP that do use an LSP routing protocol. Note though that such a 7073 mechanism would not work easily for GRASP M_DISCOVERY messages which 7074 are intelligently (constrained) flooded not across the whole ACP, but 7075 only up to a node where a responder is found. We do expect that many 7076 future services in ASA will have only few consuming ASA, and for 7077 those cases, M_DISCOVERY is the more efficient method than flooding 7078 across the whole domain. 7080 Because the ACP uses RPL, one desirable future extension is to use 7081 RPLs existing notion of DODAG, which are loop-free distribution 7082 trees, to make GRASP flooding more efficient both for M_FLOOD and 7083 M_DISCOVERY. See Section 6.12.5 how this will be specifically 7084 beneficial when using NBMA interfaces. This is not currently 7085 specified in this document because it is not quite clear yet what 7086 exactly the implications are to make GRASP flooding depend on RPL 7087 DODAG convergence and how difficult it would be to let GRASP flooding 7088 access the DODAG information. 7090 A.6. Extending ACP channel negotiation (via GRASP) 7092 [RFC Editor: This section to be removed before RFC. 7094 [This section kept for informational purposes up until the last draft 7095 version as that would be the version that readers interested in the 7096 changelog would also go to to revisit it.] 7098 The mechanism described in the normative part of this document to 7099 support multiple different ACP secure channel protocols without a 7100 single network wide MTI protocol is important to allow extending 7101 secure ACP channel protocols beyond what is specified in this 7102 document, but it will run into problem if it would be used for 7103 multiple protocols: 7105 The need to potentially have multiple of these security associations 7106 even temporarily run in parallel to determine which of them works 7107 best does not support the most lightweight implementation options. 7109 The simple policy of letting one side (Alice) decide what is best may 7110 not lead to the mutual best result. 7112 The two limitations can easier be solved if the solution was more 7113 modular and as few as possible initial secure channel negotiation 7114 protocols would be used, and these protocols would then take on the 7115 responsibility to support more flexible objectives to negotiate the 7116 mutually preferred ACP security channel protocol. 7118 IKEv2 is the IETF standard protocol to negotiate network security 7119 associations. It is meant to be extensible, but it is unclear 7120 whether it would be feasible to extend IKEv2 to support possible 7121 future requirements for ACP secure channel negotiation: 7123 Consider the simple case where the use of native IPsec vs. IPsec via 7124 GRE is to be negotiated and the objective is the maximum throughput. 7125 Both sides would indicate some agreed upon performance metric and the 7126 preferred encapsulation is the one with the higher performance of the 7127 slower side. IKEv2 does not support negotiation with such 7128 objectives. 7130 Consider DTLS and some form of MacSec are to be added as negotiation 7131 options - and the performance objective should work across all IPsec, 7132 DTLS and MacSec options. In the case of MacSEC, the negotiation 7133 would also need to determine a key for the peering. It is unclear if 7134 it would be even appropriate to consider extending the scope of 7135 negotiation in IKEv2 to those cases. Even if feasible to define, it 7136 is unclear if implementations of IKEv2 would be eager to adopt those 7137 type of extension given the long cycles of security testing that 7138 necessarily goes along with core security protocols such as IKEv2 7139 implementations. 7141 A more modular alternative to extending IKEv2 could be to layer a 7142 modular negotiation mechanism on top of the multitude of existing or 7143 possible future secure channel protocols. For this, GRASP over TLS 7144 could be considered as a first ACP secure channel negotiation 7145 protocol. The following are initial considerations for such an 7146 approach. A full specification is subject to a separate document: 7148 To explicitly allow negotiation of the ACP channel protocol, GRASP 7149 over a TLS connection using the GRASP_LISTEN_PORT and the node's and 7150 peer's link-local IPv6 address is used. When Alice and Bob support 7151 GRASP negotiation, they do prefer it over any other non-explicitly 7152 negotiated security association protocol and should wait trying any 7153 non-negotiated ACP channel protocol until after it is clear that 7154 GRASP/TLS will not work to the peer. 7156 When Alice and Bob successfully establish the GRASP/TSL session, they 7157 will negotiate the channel mechanism to use using objectives such as 7158 performance and perceived quality of the security. After agreeing on 7159 a channel mechanism, Alice and Bob start the selected Channel 7160 protocol. Once the secure channel protocol is successfully running, 7161 the GRASP/TLS connection can be kept alive or timed out as long as 7162 the selected channel protocol has a secure association between Alice 7163 and Bob. When it terminates, it needs to be re-negotiated via GRASP/ 7164 TLS. 7166 Notes: 7168 o Negotiation of a channel type may require IANA assignments of code 7169 points. 7171 o TLS is subject to reset attacks, which IKEv2 is not. Normally, 7172 ACP connections (as specified in this document) will be over link- 7173 local addresses so the attack surface for this one issue in TCP 7174 should be reduced (note that this may not be true when ACP is 7175 tunneled as described in Section 8.2.2. 7177 o GRASP packets received inside a TLS connection established for 7178 GRASP/TLS ACP negotiation are assigned to a separate GRASP domain 7179 unique to that TLS connection. 7181 A.7. CAs, domains and routing subdomains 7183 There is a wide range of setting up different ACP solution by 7184 appropriately using CAs and the domain and rsub elements in the acp- 7185 node-name in the domain certificate. We summarize these options here 7186 as they have been explained in different parts of the document in 7187 before and discuss possible and desirable extensions: 7189 An ACP domain is the set of all ACP nodes that can authenticate each 7190 other as belonging to the same ACP network using the ACP domain 7191 membership check (Section 6.1.3). GRASP inside the ACP is run across 7192 all transitively connected ACP nodes in a domain. 7194 The rsub element in the acp-node-name permits the use of addresses 7195 from different ULA prefixes. One use case is to create multiple 7196 physical networks that initially may be separated with one ACP domain 7197 but different routing subdomains, so that all nodes can mutual trust 7198 their ACP domain certificates (not depending on rsub) and so that 7199 they could connect later together into a contiguous ACP network. 7201 One instance of such a use case is an ACP for regions interconnected 7202 via a non-ACP enabled core, for example due to the absence of product 7203 support for ACP on the core nodes. ACP connect configurations as 7204 defined in this document can be used to extend and interconnect those 7205 ACP islands to the NOC and merge them into a single ACP when later 7206 that product support gap is closed. 7208 Note that RPL scales very well. It is not necessary to use multiple 7209 routing subdomains to scale ACP domains in a way it would be possible 7210 if other routing protocols where used. They exist only as options 7211 for the above mentioned reasons. 7213 If different ACP domains are to be created that should not allow to 7214 connect to each other by default, these ACP domains simply need to 7215 have different domain elements in the acp-node-name. These domain 7216 elements can be arbitrary, including subdomains of one another: 7217 Domains "example.com" and "research.example.com" are separate domains 7218 if both are domain elements in the acp-node-name of certificates. 7220 It is not necessary to have a separate CA for different ACP domains: 7221 an operator can use a single CA to sign certificates for multiple ACP 7222 domains that are not allowed to connect to each other because the 7223 checks for ACP adjacencies includes comparison of the domain part. 7225 If multiple independent networks choose the same domain name but had 7226 their own CA, these would not form a single ACP domain because of CA 7227 mismatch. Therefore there is no problem in choosing domain names 7228 that are potentially also used by others. Nevertheless it is highly 7229 recommended to use domain names that one can have high probability to 7230 be unique. It is recommended to use domain names that start with a 7231 DNS domain names owned by the assigning organization and unique 7232 within it. For example "acp.example.com" if you own "example.com". 7234 A.8. Intent for the ACP 7236 Intent is the architecture component of autonomic networks according 7237 to [I-D.ietf-anima-reference-model] that allows operators to issue 7238 policies to the network. Its applicability for use is quite flexible 7239 and freeform, with potential applications including policies flooded 7240 across ACP GRASP and interpreted on every ACP node. 7242 One concern for future definitions of Intent solutions is the problem 7243 of circular dependencies when expressing Intent policies about the 7244 ACP itself. 7246 For example, Intent could indicate the desire to build an ACP across 7247 all domains that have a common parent domain (without relying on the 7248 rsub/routing-subdomain solution defined in this document). For 7249 example ACP nodes with domain "example.com", "access.example.com", 7250 "core.example.com" and "city.core.example.com" should all establish 7251 one single ACP. 7253 If each domain has its own source of Intent, then the Intent would 7254 simply have to allow adding the peer domains TA and domain names to 7255 the parameters for the ACP domain membership check (Section 6.1.3) so 7256 that nodes from those other domains are accepted as ACP peers. 7258 If this Intent was to be originated only from one domain, it could 7259 likely not be made to work because the other domains will not build 7260 any ACP connection amongst each other, whether they use the same or 7261 different CA due to the ACP domain membership check. 7263 If the domains use the same CA one could change the ACP setup to 7264 permit for the ACP to be established between two ACP nodes with 7265 different acp-domain-names, but only for the purpose of disseminating 7266 limited information, such as Intent, but not to set up full ACP 7267 connectivity, specifically not RPL routing and passing of arbitrary 7268 GRASP information. Unless the Intent policies permit this to happen 7269 across domain boundaries. 7271 This type of approach where the ACP first allows Intent to operate 7272 and only then sets up the rest of ACP connectivity based on Intent 7273 policy could also be used to enable Intent policies that would limit 7274 functionality across the ACP inside a domain, as long as no policy 7275 would disturb the distribution of Intent. For example to limit 7276 reachability across the ACP to certain type of nodes or locations of 7277 nodes. 7279 A.9. Adopting ACP concepts for other environments 7281 The ACP as specified in this document is very explicit about the 7282 choice of options to allow interoperable implementations. The 7283 choices made may not be the best for all environments, but the 7284 concepts used by the ACP can be used to build derived solutions: 7286 The ACP specifies the use of ULA and deriving its prefix from the 7287 domain name so that no address allocation is required to deploy the 7288 ACP. The ACP will equally work not using ULA but any other /48 IPv6 7289 prefix. This prefix could simply be a configuration of the ACP 7290 registrars (for example when using BRSKI) to enroll the domain 7291 certificates - instead of the ACP registrar deriving the /48 ULA 7292 prefix from the AN domain name. 7294 Some solutions may already have an auto-addressing scheme, for 7295 example derived from existing unique device identifiers (e.g., MAC 7296 addresses). In those cases it may not be desirable to assign 7297 addresses to devices via the ACP address information field in the way 7298 described in this document. The certificate may simply serve to 7299 identify the ACP domain, and the address field could be empty/unused. 7300 The only fix required in the remaining way the ACP operate is to 7301 define another element in the domain certificate for the two peers to 7302 decide who is Alice and who is Bob during secure channel building. 7303 Note though that future work may leverage the acp address to 7304 authenticate "ownership" of the address by the device. If the 7305 address used by a device is derived from some pre-existing permanent 7306 local ID (such as MAC address), then it would be useful to store that 7307 address in the certificate using the format of the access address 7308 information field or in a similar way. 7310 The ACP is defined as a separate VRF because it intends to support 7311 well managed networks with a wide variety of configurations. 7312 Therefore, reliable, configuration-indestructible connectivity cannot 7313 be achieved from the Data-Plane itself. In solutions where all 7314 transit connectivity impacting functions are fully automated 7315 (including security), indestructible and resilient, it would be 7316 possible to eliminate the need for the ACP to be a separate VRF. 7317 Consider the most simple example system in which there is no separate 7318 Data-Plane, but the ACP is the Data-Plane. Add BRSKI, and it becomes 7319 a fully autonomic network - except that it does not support automatic 7320 addressing for user equipment. This gap can then be closed for 7321 example by adding a solution derived from 7322 [I-D.ietf-anima-prefix-management]. 7324 TCP/TLS as the protocols to provide reliability and security to GRASP 7325 in the ACP may not be the preferred choice in constrained networks. 7326 For example, CoAP/DTLS (Constrained Application Protocol) may be 7327 preferred where they are already used, allowing to reduce the 7328 additional code space footprint for the ACP on those devices. Hop- 7329 by-hop reliability for ACP GRASP messages could be made to support 7330 protocols like DTLS by adding the same type of negotiation as defined 7331 in this document for ACP secure channel protocol negotiation. End- 7332 to-end GRASP connections can be made to select their transport 7333 protocol in future extensions of the ACP meant to better support 7334 constrained devices by indicating the supported transport protocols 7335 (e.g.: TLS/DTLS) via GRASP parameters of the GRASP objective through 7336 which the transport endpoint is discovered. 7338 The routing protocol RPL used for the ACP does explicitly not 7339 optimize for shortest paths and fastest convergence. Variations of 7340 the ACP may want to use a different routing protocol or introduce 7341 more advanced RPL profiles. 7343 Variations such as what routing protocol to use, or whether to 7344 instantiate an ACP in a VRF or (as suggested above) as the actual 7345 Data-Plane, can be automatically chosen in implementations built to 7346 support multiple options by deriving them from future parameters in 7347 the certificate. Parameters in certificates should be limited to 7348 those that would not need to be changed more often than certificates 7349 would need to be updated anyhow; Or by ensuring that these parameters 7350 can be provisioned before the variation of an ACP is activated in a 7351 node. Using BRSKI, this could be done for example as additional 7352 follow-up signaling directly after the certificate enrollment, still 7353 leveraging the BRSKI TLS connection and therefore not introducing any 7354 additional connectivity requirements. 7356 Last but not least, secure channel protocols including their 7357 encapsulations are easily added to ACP solutions. ACP hop-by-hop 7358 network layer secure channels could also be replaced by end-to-end 7359 security plus other means for infrastructure protection. Any future 7360 network OAM should always use end-to-end security anyhow and can 7361 leverage the domain certificates and is therefore not dependent on 7362 security to be provided for by ACP secure channels. 7364 A.10. Further (future) options 7366 A.10.1. Auto-aggregation of routes 7368 Routing in the ACP according to this specification only leverages the 7369 standard RPL mechanism of route optimization, e.g. keeping only 7370 routes that are not towards the RPL root. This is known to scale to 7371 networks with 20,000 or more nodes. There is no auto-aggregation of 7372 routes for /48 ULA prefixes (when using rsub in the acp-node-name) 7373 and/or Zone-ID based prefixes. 7375 Automatic assignment of Zone-ID and auto-aggregation of routes could 7376 be achieved for example by configuring zone-boundaries, announcing 7377 via GRASP into the zones the zone parameters (zone-ID and /48 ULA 7378 prefix) and auto-aggegating routes on the zone-boundaries. Nodes 7379 would assign their Zone-ID and potentially even /48 prefix based on 7380 the GRASP announcements. 7382 A.10.2. More options for avoiding IPv6 Data-Plane dependency 7384 As described in Section 6.12.2, the ACP depends on the Data-Plane to 7385 establish IPv6 link-local addressing on interfaces. Using a separate 7386 MAC address for the ACP allows to fully isolate the ACP from the 7387 Data-Plane in a way that is compatible with this specification. It 7388 is also an ideal option when using Single-root input/output 7389 virtualization (SR-IOV - see https://en.wikipedia.org/wiki/Single- 7390 root_input/output_virtualization [2]) in an implementation to isolate 7391 the ACP because different SR-IOV interfaces use different MAC 7392 addresses. 7394 When additional MAC address(es) are not available, separation of the 7395 ACP could be done at different demux points. The same subnet 7396 interface could have a separate IPv6 interface for the ACP and Data- 7397 Plane and therefore separate link-local addresses for both, where the 7398 ACP interface is non-configurable on the Data-Plane. This too would 7399 be compatible with this specification and not impact 7400 interoperability. 7402 An option that would require additional specification is to use a 7403 different Ethertype from 0x86DD (IPv6) to encapsulate IPv6 packets 7404 for the ACP. This would be a similar approach as used for IP 7405 authentication packets in [IEEE-802.1X] which use the Extensible 7406 Authentication Protocol over Local Area Network (EAPoL) ethertype 7407 (0x88A2). 7409 Note that in the case of ANI nodes, all the above considerations 7410 equally apply to the encapsulation of BRSKI packets including GRASP 7411 used for BRSKI. 7413 A.10.3. ACP APIs and operational models (YANG) 7415 Future work should define YANG ([RFC7950]) data model and/or node 7416 internal APIs to monitor and manage the ACP. 7418 Support for the ACP Adjacency Table (Section 6.2) and ACP GRASP need 7419 to be included into such model/API. 7421 A.10.4. RPL enhancements 7423 ..... USA ...... ..... Europe ...... 7425 NOC1 NOC2 7426 | | 7427 | metric 100 | 7428 ACP1 --------------------------- ACP2 . 7429 | | . WAN 7430 | metric 10 metric 20 | . Core 7431 | | . 7432 ACP3 --------------------------- ACP4 . 7433 | metric 100 | 7434 | | . 7435 | | . Sites 7436 ACP10 ACP11 . 7438 Figure 18: Dual NOC 7440 The profile for RPL specified in this document builds only one 7441 spanning-tree path set to a root, typically a registrar in one NOC. 7442 In the presence of multiple NOCs, routing toward the non-root NOCs 7443 may be suboptimal. Figure 18 shows an extreme example. Assuming 7444 that node ACP1 becomes the RPL root, traffic between ACP11 and NOC2 7445 will pass through ACP4-ACP3-ACP1-ACP2 instead of ACP4-ACP2 because 7446 the RPL calculated DODAG/routes are shortest paths towards the RPL 7447 root. 7449 To overcome these limitations, extensions/modifications to the RPL 7450 profile can provide optimality for multiple NOCs. This requires 7451 utilizing Data-Plane artifact including IPinIP encap/decap on ACP 7452 routers and processing of IPv6 RPI headers. Alternatively, (Src,Dst) 7453 routing table entries could be used. 7455 Flooding of ACP GRASP messages can be further constrained and 7456 therefore optimized by flooding only via links that are part of the 7457 RPL DODAG. 7459 A.10.5. Role assignments 7461 ACP connect is an explicit mechanism to "leak" ACP traffic explicitly 7462 (for example in a NOC). It is therefore also a possible security gap 7463 when it is easy to enable ACP connect on arbitrary compromised ACP 7464 nodes. 7466 One simple solution is to define an extension in the ACP certificates 7467 ACP information field indicating the permission for ACP connect to be 7468 configured on that ACP node. This could similarly be done to decide 7469 whether a node is permitted to be a registrar or not. 7471 Tying the permitted "roles" of an ACP node to the ACP domain 7472 certificate provides fairly strong protection against 7473 misconfiguration, but is still subject to code modifications. 7475 Another interesting role to assign to certificates is that of a NOC 7476 node. This would allow to limit certain type of connections such as 7477 OAM TLS connections to only NOC initiator or responders. 7479 A.10.6. Autonomic L3 transit 7481 In this specification, the ACP can only establish autonomic 7482 connectivity across L2 hops and only explicitly configured options to 7483 tunnel across L3. Future work should specify mechanisms to 7484 automatically tunnel ACP across L3 networks. A hub&spoke option 7485 would allow to tunnel across the Internet to a cloud or central 7486 instance of the ACP, a peer-to-peer tunneling mechanism could tunnel 7487 ACP islands across an L3VPN infrastructure. 7489 A.10.7. Diagnostics 7491 Section 9.1 describes diagnostics options that can be done without 7492 changing the external, interoperability affecting characteristics of 7493 ACP implementations. 7495 Even better diagnostics of ACP operations is possible with additional 7496 signaling extensions, such as: 7498 1. Consider if LLDP should be a recommended functionality for ANI 7499 devices to improve diagnostics, and if so, which information 7500 elements it should signal (noting that such information is 7501 conveyed in an insecure manner). Includes potentially new 7502 information elements. 7504 2. In alternative to LLDP, A DULL GRASP diagnostics objective could 7505 be defined to carry these information elements. 7507 3. The IDevID certificate of BRSKI pledges should be included in the 7508 selected insecure diagnostics option. This may be undesirable 7509 when exposure of device information is seen as too much of a 7510 security issue (ability to deduce possible attack vectors from 7511 device model for example). 7513 4. A richer set of diagnostics information should be made available 7514 via the secured ACP channels, using either single-hop GRASP or 7515 network wide "topology discovery" mechanisms. 7517 A.10.8. Avoiding and dealing with compromised ACP nodes 7519 Compromised ACP nodes pose the biggest risk to the operations of the 7520 network. The most common type of compromise is leakage of 7521 credentials to manage/configure the device and the application of 7522 malicious configuration including the change of access credentials, 7523 but not the change of software. Most of todays networking equipment 7524 should have secure boot/software infrastructure anyhow, so attacks 7525 that introduce malicious software should be a lot harder. 7527 The most important aspect of security design against these type of 7528 attacks is to eliminate password based configuration access methods 7529 and instead rely on certificate based credentials handed out only to 7530 nodes where it is clear that the private keys can not leak. This 7531 limits unexpected propagation of credentials. 7533 If password based credentials to configure devices still need to be 7534 supported, they must not be locally configurable, but only be 7535 remotely provisioned or verified (through protocols like Radius or 7536 Diameter), and there must be no local configuration permitting to 7537 change these authentication mechanisms, but ideally they should be 7538 autoconfiguring across the ACP. See 7539 [I-D.eckert-anima-noc-autoconfig]. 7541 Without physical access to the compromised device, attackers with 7542 access to configuration should not be able to break the ACP 7543 connectivity, even when they can break or otherwise manipulate 7544 (spoof) the Data-Plane connectivity through configuration. To 7545 achieve this, it is necessary to avoid providing configuration 7546 options for the ACP, such as enabling/disabling it on interfaces. 7547 For example there could be an ACP configuration that locks down the 7548 current ACP config unless factory reseet is done. 7550 With such means, the valid administration has the best chances to 7551 maintain access to ACP nodes, discover malicious configuration though 7552 ongoing configuration tracking from central locations for example, 7553 and to react accordingly. 7555 The primary reaction is withdrawal/change of credentials, terminate 7556 malicious existing management sessions and fixing the configuration. 7557 Ensuring that management sessions using invalidated credentials are 7558 terminated automatically without recourse will likely require new 7559 work. 7561 Only when these steps are not feasible would it be necessary to 7562 revoke or expire the ACP domain certificate credentials and consider 7563 the node kicked off the network - until the situation can be further 7564 rectified, likely requiring direct physical access to the node. 7566 Without extensions, compromised ACP nodes can only be removed from 7567 the ACP at the speed of CRL/OCSP information refresh or expiry (and 7568 non-removal) of short lived certificates. Future extensions to the 7569 ACP could for example use GRASP flooding distribution of triggered 7570 updates of CRL/OCSP or explicit removal indication of the compromised 7571 nodes domain certificate. 7573 Authors' Addresses 7575 Toerless Eckert (editor) 7576 Futurewei Technologies Inc. USA 7577 2330 Central Expy 7578 Santa Clara 95050 7579 USA 7581 Email: tte+ietf@cs.fau.de 7583 Michael H. Behringer (editor) 7585 Email: michael.h.behringer@gmail.com 7587 Steinthor Bjarnason 7588 Arbor Networks 7589 2727 South State Street, Suite 200 7590 Ann Arbor MI 48104 7591 United States 7593 Email: sbjarnason@arbor.net