idnits 2.17.1 draft-carpenter-anima-l2acp-scenarios-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (9 April 2020) is 1475 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-24 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. E. Carpenter 3 Internet-Draft Univ. of Auckland 4 Intended status: Informational B. Liu 5 Expires: 11 October 2020 Huawei Technologies 6 9 April 2020 8 Scenarios and Requirements for Layer 2 Autonomic Control Planes 9 draft-carpenter-anima-l2acp-scenarios-02 11 Abstract 13 This document discusses scenarios and requirements for Autonomic 14 Control Planes (ACPs) constructed and secured at Layer 2. These 15 would be alternatives to an ACP constructed and secured at the 16 network layer. A secure ACP is required as the substrate for an 17 autonomic network and for the Generic Autonomic Signaling Protocol 18 (GRASP). 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on 11 October 2020. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Network Scenarios Suitable for a Layer 2 ACP . . . . . . . . 3 55 3. Requirements for a Layer 2 Technology . . . . . . . . . . . . 3 56 4. Multiple Segments . . . . . . . . . . . . . . . . . . . . . . 5 57 5. Implementation Status [RFC Editor: please remove] . . . . . . 5 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 59 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 60 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 61 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 63 9.2. Informative References . . . . . . . . . . . . . . . . . 6 64 Appendix A. Change log [RFC Editor: Please remove] . . . . . . . 7 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 67 1. Introduction 69 As defined in [I-D.ietf-anima-reference-model], the Autonomic Service 70 Agent (ASA) is the atomic entity of an autonomic function, and it is 71 instantiated on autonomic nodes. When ASAs communicate with each 72 other, they should use the Generic Autonomic Signaling Protocol 73 (GRASP) [I-D.ietf-anima-grasp]. It is essential that such 74 communication is strongly secured to avoid malicious interference 75 with the Autonomic Network Infrastructure (ANI). 77 For this reason, GRASP, and any other autonomic management traffic, 78 must run over a secure substrate that is isolated from regular data 79 plane traffic. This substrate is known as the Autonomic Control 80 Plane (ACP). A method for constructing an ACP at the network layer 81 is described in [I-D.ietf-anima-autonomic-control-plane]. The 82 present document discusses scenarios and requirements for 83 constructing an ACP at layer 2. It is not intended to be a normative 84 specification, since implementation details will depend on individual 85 layer 2 technologies. 87 2. Network Scenarios Suitable for a Layer 2 ACP 89 The ANI design is aimed at managed networks, as explained in the 90 reference model [I-D.ietf-anima-reference-model]. For a wide area 91 network (such as a large campus, a multi-site enterprise network, or 92 a carrier network considered as a whole) it is appropriate to 93 construct the ACP using network layer techniques and network layer 94 security, which is the model described in 95 [I-D.ietf-anima-autonomic-control-plane]. However, in at least two 96 cases an ACP covering a smaller geographical area may be appropriate: 98 1. A small enterprise that is completely within one building or 99 several adjacent buildings, which also requires autonomic network 100 management. 102 2. An enterprise that prefers in any case to segment its network 103 into smaller units for management purposes. 105 In either case, we assume that the L2 ACP may extend into the Network 106 Operations Centre (NOC) so that it can be interfaced to traditional 107 tools for Operations, Administration and Maintenance, as described in 108 [RFC8368]. In the terminology of that document, an L2 ACP is an 109 instance of a Generalized ACP. 111 3. Requirements for a Layer 2 Technology 113 These requirements are intended to ensure that a layer 2 ACP can meet 114 the needs of all components of the ANI. 116 1. Since GRASP is specified to run over IPv6, the technology must 117 support transmission of IPv6 packets according to [RFC8200]. 118 Since GRASP can run on a single network segment using link-local 119 addresses, there is not required to be an IPv6 router or DHCPv6 120 server. 122 2. The technology must support multicast. If the switches are not 123 completely transparent to layer 2 multicast, they must support 124 Multicast Listener Discovery Version 2 (MLDv2) for IPv6 125 [RFC3810]. 127 3. The technology should have a minimum MTU of 1500 bytes. Note 128 that since GRASP is specified to run unicast operations over TCP, 129 this is not an absolute requirement and the IPv6 minimum MTU of 130 1280 bytes would be acceptable. GRASP UDP multicast messages 131 could in principle be fragmented but in normal operation this 132 would be unusual. 134 4. The technology must support isolation of a given set of nodes 135 (the "ACP VLAN"). 137 5. The technology must support secure authorization for access to 138 the ACP VLAN. If the VLAN technology in use does not support 139 password protection, a VLAN access control list could be used. 141 6. The technology should support both the normal dataplane VLAN and 142 the ACP VLAN on the same physical sockets. (Possibly the 143 dataplane may be the native VLAN, i.e. frames with no VLAN tag.) 145 7. The technology should support line speed encryption of the ACP 146 VLAN. 148 8. The technology should support wired/wireless bridging if 149 relevant. 151 9. The technology should require minimal manual configuration of ACP 152 nodes. However, it is expected that the nodes will need to be 153 preconfigured before deployment with the VLAN ID, and with a 154 password or encryption key if necessary. A solution which is 155 both secure and self-configuring at Layer 2 is out of scope for 156 this document. 158 A specific security protocol that supports both authentication and 159 encryption of layer 2 packets for Ethernet LANs is MACsec, i.e. the 160 IEEE Standard 802.1AE-2018 [MACsec]. For multicast packets, 161 authentication is on a group basis (i.e., the originator is 162 guaranteed to be a member of the group, rather than a specific 163 interface). MACsec applies across all VLANs, but the ACP VLAN can be 164 isolated from the data plane VLAN independently of MACsec. This 165 solution does not extend to wireless networks. For IEEE 802.11 166 networks, IEEE Standard 802.11-2016 [WiFi] "WPA2" security within a 167 dedicated Basic Service Set (BSS) might be considered adequate. 169 An ACP software module will be needed in each autonomic node, whose 170 job is to provide the GRASP core or other autonomic management 171 protocols with the following information about the L2 ACP: 173 1. A signal that the L2 ACP is available and secure. 175 2. The current global scope IPv6 address that GRASP should use as 176 its primary locator, preferably a ULA, if available. As 177 mentioned, if no such address is available, GRASP will simply 178 operate with link-local addresses. 180 3. A list of [interface_index, link_local_address] pairs for all 181 valid IPv6 interfaces attached to the L2 ACP. The interface 182 index (also known as a zone index [RFC4007]) is an integer for 183 maximum portability between operating systems. 185 4. Multiple Segments 187 The L2 ACP could in principle be extended across multiple segments or 188 even multiple sites by use of secure L2VPN technology. This topic is 189 out of the scope of the present document. 191 5. Implementation Status [RFC Editor: please remove] 193 A simple ACP software module emulating that needed for a secure L2 194 ACP has been implemented, but it does not in fact verify security. 195 It may be found at https://github.com/becarpenter/graspy/blob/master/ 196 acp.py and is briefly documented in 197 https://github.com/becarpenter/graspy/blob/master/graspy.pdf. 199 6. Security Considerations 201 The assumption of this document is that any Layer 2 solution chosen 202 must have adequate security against interlopers and eavesdroppers. 203 It should be noted that (at least in a wired network) this also 204 requires adequate physical security to prevent access by unauthorized 205 persons, including physical intrusion detection. 207 The fact that an IPv6 router is not required in an L2 ACP excludes 208 many Layer 3 vulnerabilities by construction. No outside entity can 209 generate link-local IPv6 packets, and no outside entity can send 210 global scope packets to any autonomic node. 212 7. IANA Considerations 214 This document makes no request of the IANA. 216 8. Acknowledgements 218 Excellent suggestions were made by Michael Richardson and other 219 participants in the ANIMA WG. 221 9. References 223 9.1. Normative References 225 [MACsec] "IEEE Standard for Local and metropolitan area networks - 226 Media Access Control (MAC) Security", IEEE Standard 227 802.1AE-2018, 2018, 228 . 231 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 232 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 233 DOI 10.17487/RFC3810, June 2004, 234 . 236 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 237 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 238 DOI 10.17487/RFC4007, March 2005, 239 . 241 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 242 (IPv6) Specification", STD 86, RFC 8200, 243 DOI 10.17487/RFC8200, July 2017, 244 . 246 [WiFi] "Information technology - Telecommunications and 247 information exchange between systems - Local and 248 metropolitan area networks - Specific requirements - Part 249 11: Wireless LAN Medium Access Control (MAC) and Physical 250 Layer (PHY) specifications", IEEE Standard 802.11-2016, 251 2016, . 254 9.2. Informative References 256 [I-D.ietf-anima-autonomic-control-plane] 257 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 258 Control Plane (ACP)", Work in Progress, Internet-Draft, 259 draft-ietf-anima-autonomic-control-plane-24, 9 March 2020, 260 . 263 [I-D.ietf-anima-grasp] 264 Bormann, C., Carpenter, B., and B. Liu, "A Generic 265 Autonomic Signaling Protocol (GRASP)", Work in Progress, 266 Internet-Draft, draft-ietf-anima-grasp-15, 13 July 2017, 267 . 269 [I-D.ietf-anima-reference-model] 270 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 271 and J. Nobre, "A Reference Model for Autonomic 272 Networking", Work in Progress, Internet-Draft, draft-ietf- 273 anima-reference-model-10, 22 November 2018, 274 . 277 [RFC8368] Eckert, T., Ed. and M. Behringer, "Using an Autonomic 278 Control Plane for Stable Connectivity of Network 279 Operations, Administration, and Maintenance (OAM)", 280 RFC 8368, DOI 10.17487/RFC8368, May 2018, 281 . 283 Appendix A. Change log [RFC Editor: Please remove] 285 draft-carpenter-anima-l2acp-scenarios-00, 2019-02-28: 287 * Initial version 289 draft-carpenter-anima-l2acp-scenarios-01, 2019-10-03: 291 * Added discussion of MACsec and WPA2 292 * Editorial improvements 294 draft-carpenter-anima-l2acp-scenarios-02, 2020-04-09: 296 * Updated references 297 * Editorial improvements 298 * Converted to xml2rfc v3 300 Authors' Addresses 302 Brian Carpenter 303 The University of Auckland 304 School of Computer Science 305 University of Auckland 306 PB 92019 307 Auckland 1142 308 New Zealand 310 Email: brian.e.carpenter@gmail.com 312 Bing Liu 313 Huawei Technologies 314 Q14, Huawei Campus 315 No.156 Beiqing Road 316 Hai-Dian District, Beijing 317 100095 318 P.R. China 320 Email: leo.liubing@huawei.com