idnits 2.17.1 draft-carpenter-anima-l2acp-scenarios-01.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 (October 3, 2019) is 1661 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-20 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. Carpenter 3 Internet-Draft Univ. of Auckland 4 Intended status: Informational B. Liu, Ed. 5 Expires: April 5, 2020 Huawei Technologies 6 October 3, 2019 8 Scenarios and Requirements for Layer 2 Autonomic Control Planes 9 draft-carpenter-anima-l2acp-scenarios-01 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 the 17 Generic Autonomic Signaling Protocol (GRASP) used by Autonomic 18 Service Agents. 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 April 5, 2020. 37 Copyright Notice 39 Copyright (c) 2019 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 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Network Scenarios Suitable for a Layer 2 ACP . . . . . . . . 2 56 3. Requirements for a Layer 2 Technology . . . . . . . . . . . . 3 57 4. Multiple Segments . . . . . . . . . . . . . . . . . . . . . . 5 58 5. Implementation Status [RFC Editor: please remove] . . . . . . 5 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 61 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 62 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 64 9.2. Informative References . . . . . . . . . . . . . . . . . 6 65 Appendix A. Change log [RFC Editor: Please remove] . . . . . . . 6 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 68 1. Introduction 70 As defined in [I-D.ietf-anima-reference-model], the Autonomic Service 71 Agent (ASA) is the atomic entity of an autonomic function, and it is 72 instantiated on autonomic nodes. When ASAs communicate with each 73 other, they should use the Generic Autonomic Signaling Protocol 74 (GRASP) [I-D.ietf-anima-grasp]. It is essential that such 75 communication is strongly secured to avoid malicious interference 76 with the Autonomic Network Infrastructure (ANI). 78 For this reason, GRASP must run over a secure substrate that is 79 isolated from regular data plane traffic. This substrate is known as 80 the Autonomic Control Plane (ACP). A method for constructing an ACP 81 at the network layer is described in 82 [I-D.ietf-anima-autonomic-control-plane]. The present document 83 discusses scenarios and requirements for constructing an ACP at layer 84 2. It is not intended to be a normative specification, since 85 implementation details will depend on individual layer 2 86 technologies. 88 2. Network Scenarios Suitable for a Layer 2 ACP 90 The ANI design is aimed at managed networks, as explained in the 91 reference model [I-D.ietf-anima-reference-model]. For a wide area 92 network (such as a large campus, a multi-site enterprise network, or 93 a carrier network considered as a whole) it is appropriate to 94 construct the ACP using network layer techniques and network layer 95 security. and that is the model described in 97 [I-D.ietf-anima-autonomic-control-plane], However, in at least two 98 cases an ACP covering a smaller geographical area may be appropriate: 100 1. A small enterprise that is completely within one building or 101 several adjacent buildings, which also requires autonomic network 102 management. 104 2. An enterprise that prefers in any case to segment its network 105 into smaller units for management purposes. 107 In either case, we assume that the L2 ACP may extend into the Network 108 Operations Centre (NOC) so that it can be interfaced to traditional 109 tools for Operations, Administration and Maintenance, as described in 110 [RFC8368]. In the terminology of that document, an L2 ACP is an 111 instance of a Generalized ACP. 113 3. Requirements for a Layer 2 Technology 115 These requirements are intended to ensure that a layer 2 ACP can meet 116 the needs of all components of the ANI. 118 1. Since GRASP is specified to run over IPv6, the technology must 119 support transmission of IPv6 packets according to [RFC8200]. 120 Since GRASP can run on a single network segment using link-local 121 addresses, there is not required to be an IPv6 router or DHCPv6 122 server. 124 2. The technology must support multicast. If the switches are not 125 completely transparent to layer 2 multicast, they must support 126 Multicast Listener Discovery Version 2 (MLDv2) for IPv6 127 [RFC3810]. 129 3. The technology should have a minimum MTU of 1500 bytes. Note 130 that since GRASP is specified to run unicast operations over TCP, 131 this is not an absolute requirement and the IPv6 minimum MTU of 132 1280 bytes would be acceptable. GRASP UDP multicast messages 133 could in principle be fragmented but in normal operation this 134 would be unusual. 136 4. The technology must support isolation of a given set of nodes 137 (the "ACP VLAN"). 139 5. The technology must support secure authorization for access to 140 the ACP VLAN. If the VLAN technology in use does not support 141 password protection, a VLAN access control list could be used. 143 6. The technology should support both the normal dataplane VLAN and 144 the ACP VLAN on the same physical sockets. (Possibly the 145 dataplane may be the native VLAN, i.e. frames with no VLAN tag.) 147 7. The technology should support line speed encryption of the ACP 148 VLAN. 150 8. The technology should support wired/wireless bridging if 151 relevant. 153 9. The technology should require minimal manual configuration of ACP 154 nodes. However, it is expected that the nodes will need to be 155 preconfigured before deployment with the VLAN ID, and with a 156 password or encryption key if necessary. A solution which is 157 both secure and self-configuring at Layer 2 is out of scope for 158 this document. 160 A specific security protocol that supports both authentication and 161 encryption of layer 2 packets for Ethernet LANs is MACsec, i.e. the 162 IEEE Standard 802.1AE-2018 [MACsec]. For multicast packets, 163 authentication is on a group basis (i.e., the originator is 164 guaranteed to be a member of the group, rather than a specific 165 interface). MACsec applies across all VLANs, but the ACP VLAN can be 166 isolated from the data plane VLAN independently of MACsec. This 167 solution does not extend to wireless networks. For IEEE 802.11 168 networks, IEEE Standard 802.11-2016 [WiFi] "WPA2" security within a 169 dedicated Basic Service Set (BSS) might be considered adequate. 171 An ACP software module will be needed in each autonomic node, whose 172 job is to provide the GRASP core with the following information about 173 the L2 ACP: 175 1. A signal that the L2 ACP is available and secure. 177 2. The current global scope IPv6 address that GRASP should use as 178 its primary locator, preferably a ULA, if available. As 179 mentioned, if no such address is available, GRASP will simply 180 operate with link-local addresses. 182 3. A list of [interface_index, link_local_address] pairs for all 183 valid IPv6 interfaces attached to the L2 ACP. The interface 184 index is an integer for maximum portability between operating 185 systems. 187 4. Multiple Segments 189 This section is for further study. 191 The L2 ACP could in principle be extended across multiple segments or 192 even multiple sites by use of secure L2VPN technology. 194 5. Implementation Status [RFC Editor: please remove] 196 A simple ACP software module emulating that needed for a secure L2 197 ACP has been implemented, but it does not in fact verify security. 198 It may be found at 199 and is 200 briefly documented in 201 . 203 6. Security Considerations 205 The assumption of this document is that any Layer 2 solution chosen 206 must have adequate security against interlopers and eavesdroppers. 207 It should be noted that (at least in a wired network) this also 208 requires adequate physical security to prevent access by unauthorized 209 persons, including physical intrusion detection. 211 The fact that an IPv6 router is not required in an L2 ACP excludes 212 many Layer 3 vulnerabilities by construction. No outside entity can 213 generate link-local IPv6 packets, and no outside entity can send 214 global scope packets to any autonomic node. 216 7. IANA Considerations 218 This document makes no request of the IANA. 220 8. Acknowledgements 222 Excellent suggestions were made by Michael Richardson and other 223 participants in the ANIMA WG. 225 9. References 227 9.1. Normative References 229 [MACsec] "IEEE Standard for Local and metropolitan area networks - 230 Media Access Control (MAC) Security", IEEE Standard 231 802.1AE-2018, 2018, . 234 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 235 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 236 DOI 10.17487/RFC3810, June 2004, 237 . 239 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 240 (IPv6) Specification", STD 86, RFC 8200, 241 DOI 10.17487/RFC8200, July 2017, 242 . 244 [WiFi] "Information technology - Telecommunications and 245 information exchange between systems - Local and 246 metropolitan area networks - Specific requirements - Part 247 11: Wireless LAN Medium Access Control (MAC) and Physical 248 Layer (PHY) specifications", IEEE Standard 802.11-2016, 249 2016, . 252 9.2. Informative References 254 [I-D.ietf-anima-autonomic-control-plane] 255 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 256 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 257 plane-20 (work in progress), July 2019. 259 [I-D.ietf-anima-grasp] 260 Bormann, C., Carpenter, B., and B. Liu, "A Generic 261 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 262 grasp-15 (work in progress), July 2017. 264 [I-D.ietf-anima-reference-model] 265 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 266 and J. Nobre, "A Reference Model for Autonomic 267 Networking", draft-ietf-anima-reference-model-10 (work in 268 progress), November 2018. 270 [RFC8368] Eckert, T., Ed. and M. Behringer, "Using an Autonomic 271 Control Plane for Stable Connectivity of Network 272 Operations, Administration, and Maintenance (OAM)", 273 RFC 8368, DOI 10.17487/RFC8368, May 2018, 274 . 276 Appendix A. Change log [RFC Editor: Please remove] 278 draft-carpenter-anima-l2acp-scenarios-00, 2019-02-28: 280 Initial version 281 draft-carpenter-anima-l2acp-scenarios-01, 2019-10-03: 283 Added discussion of MACsec and WPA2 285 Editorial improvements 287 Authors' Addresses 289 Brian Carpenter 290 The University of Auckland 291 School of Computer Science 292 University of Auckland 293 PB 92019 294 Auckland 1142 295 New Zealand 297 Email: brian.e.carpenter@gmail.com 299 Bing Liu (editor) 300 Huawei Technologies 301 Q14, Huawei Campus 302 No.156 Beiqing Road 303 Hai-Dian District, Beijing 100095 304 P.R. China 306 Email: leo.liubing@huawei.com