idnits 2.17.1 draft-carpenter-anima-l2acp-scenarios-00.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 (February 28, 2019) is 1883 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-18 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: September 1, 2019 Huawei Technologies 6 February 28, 2019 8 Scenarios and Requirements for Layer 2 Autonomic Control Planes 9 draft-carpenter-anima-l2acp-scenarios-00 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 September 1, 2019. 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 . . . . . . . . . . . . . . . . . . . . . . 4 58 5. Implementation Status [RFC Editor: please remove] . . . . . . 4 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 61 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 62 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 64 9.2. Informative References . . . . . . . . . . . . . . . . . 5 65 Appendix A. Change log [RFC Editor: Please remove] . . . . . . . 6 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 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 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. 86 2. Network Scenarios Suitable for a Layer 2 ACP 88 The ANI design is aimed at managed networks, as explained in the 89 reference model [I-D.ietf-anima-reference-model]. For a wide area 90 network (such as a large campus, a multi-site enterprise network, or 91 a carrier network considered as a whole) it is appropriate to 92 construct the ACP using network layer techniques and network layer 93 security. and that is the model described in 94 [I-D.ietf-anima-autonomic-control-plane], However, in at least two 95 cases an ACP covering a smaller geographical area may be appropriate: 97 1. A small enterprise that is completely within one building or 98 several adjacent buildings, but is large enough to require 99 autonomic network management. 101 2. An enterprise that prefers in any case to segment its network 102 into smaller units for management purposes. 104 In either case, we assume that the L2 ACP may extend into the Network 105 Operations Centre (NOC) so that it can be interfaced to traditional 106 tools for Operations, Administration and Maintenance, as described in 107 [RFC8368]. In the terminology of that document, an L2 ACP is an 108 instance of a Generalized ACP. 110 3. Requirements for a Layer 2 Technology 112 1. The technology must support transmission of IPv6 packets 113 according to [RFC8200]. Since GRASP can run on a single network 114 segment using link-local addresses, there is not required to be 115 an IPv6 router or DHCPv6 server. 117 2. The technology must support multicast. If the switches are not 118 completely transparent to layer 2 multicast, they must support 119 Multicast Listener Discovery Version 2 (MLDv2) for IPv6 120 [RFC3810]. 122 3. The technology should have a minimum MTU of 1500 bytes. 124 4. The technology must support isolation of a given set of nodes 125 (the "ACP VLAN"). 127 5. The technology must support secure authorization for access to 128 the ACP VLAN. If the VLAN technology in use does not support 129 password protection, a VLAN access control list could be used. 131 6. The technology should support both the normal dataplane VLAN and 132 the ACP VLAN on the same physical sockets. (Possibly the 133 dataplane may be the native VLAN, i.e. frames with no VLAN tag.) 135 7. The technology should support line speed encryption of the ACP 136 VLAN. 138 8. The technology should support wired/wireless bridging if 139 relevant. 141 9. The technology should require minimal manual configuration of ACP 142 nodes. However, it is expected that the nodes will need to be 143 preconfigured before deployment with the VLAN ID, and a password 144 or encryption key if necessary. A solution which is both secure 145 and self-configuring at Layer 2 is out of scope for this 146 document. 148 A small ACP software module will be needed in each autonomic node, 149 whose job is to provide the GRASP core with the following information 150 about the L2 ACP: 152 1. A signal that the L2 ACP is available and secure. 154 2. The current global scope IPv6 address that GRASP should use as 155 its primary locator, preferably a ULA, if available. As 156 mentioned, if no such address is available, GRASP will simply 157 operate with link-local addresses. 159 3. A list of [interface_index, link_local_address] pairs for all 160 valid IPv6 interfaces attached to the L2 ACP. The interface 161 index is an integer for maximum portability between operating 162 systems. 164 4. Multiple Segments 166 This section is for further study. 168 The L2 ACP could in principle be extended across multiple segments or 169 even multiple sites by use of secure L2VPN technology. 171 5. Implementation Status [RFC Editor: please remove] 173 A simple ACP software module emulating that needed for a secure L2 174 ACP has been implemented, but it does not in fact verify security. 175 It may be found at 176 and is 177 briefly documented in 178 . 180 6. Security Considerations 182 The assumption of this document is that any Layer 2 solution chosen 183 must have adequate security against interlopers and eavesdroppers. 184 It should be noted that (at least in a wired network) this also 185 requires adequate physical security to prevent access by unauthorized 186 persons, including physical intrusion detection. 188 The fact that an IPv6 router is not required in an L2 ACP excludes 189 many Layer 3 vulnerabilities by construction. No outside entity can 190 generate link-local IPv6 packets, and no outside entity can send 191 global scope packets to any autonomic node. 193 7. IANA Considerations 195 This document makes no request of the IANA. 197 8. Acknowledgements 199 Excellent suggestions were made by TBD and other participants in the 200 ANIMA WG. 202 9. References 204 9.1. Normative References 206 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 207 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 208 DOI 10.17487/RFC3810, June 2004, 209 . 211 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 212 (IPv6) Specification", STD 86, RFC 8200, 213 DOI 10.17487/RFC8200, July 2017, 214 . 216 9.2. Informative References 218 [I-D.ietf-anima-autonomic-control-plane] 219 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 220 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 221 plane-18 (work in progress), August 2018. 223 [I-D.ietf-anima-grasp] 224 Bormann, C., Carpenter, B., and B. Liu, "A Generic 225 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 226 grasp-15 (work in progress), July 2017. 228 [I-D.ietf-anima-reference-model] 229 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 230 and J. Nobre, "A Reference Model for Autonomic 231 Networking", draft-ietf-anima-reference-model-10 (work in 232 progress), November 2018. 234 [RFC8368] Eckert, T., Ed. and M. Behringer, "Using an Autonomic 235 Control Plane for Stable Connectivity of Network 236 Operations, Administration, and Maintenance (OAM)", 237 RFC 8368, DOI 10.17487/RFC8368, May 2018, 238 . 240 Appendix A. Change log [RFC Editor: Please remove] 242 draft-carpenter-anima-l2acp-scenarios-00, 2019-02-28: 244 Initial version 246 Authors' Addresses 248 Brian Carpenter 249 The University of Auckland 250 School of Computer Science 251 University of Auckland 252 PB 92019 253 Auckland 1142 254 New Zealand 256 Email: brian.e.carpenter@gmail.com 258 Bing Liu (editor) 259 Huawei Technologies 260 Q14, Huawei Campus 261 No.156 Beiqing Road 262 Hai-Dian District, Beijing 100095 263 P.R. China 265 Email: leo.liubing@huawei.com