Scenarios and Requirements for Layer 2 Autonomic Control Planes
draft-carpenter-anima-l2acp-scenarios-01

Abstract

This document discusses scenarios and requirements for Autonomic Control Planes (ACPs) constructed and secured at Layer 2. These would be alternatives to an ACP constructed and secured at the network layer. A secure ACP is required as the substrate for the Generic Autonomic Signaling Protocol (GRASP) used by Autonomic Service Agents.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on April 5, 2020.

Copyright Notice

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Network Scenarios Suitable for a Layer 2 ACP
• 3. Requirements for a Layer 2 Technology
• 4. Multiple Segments
• 5. Implementation Status [RFC Editor: please remove]
• 6. Security Considerations
• 7. IANA Considerations
• 8. Acknowledgements
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Appendix A. Change log [RFC Editor: Please remove]
• Authors' Addresses

1. Introduction

As defined in [I-D.ietf-anima-reference-model], the Autonomic Service Agent (ASA) is the atomic entity of an autonomic function, and it is instantiated on autonomic nodes. When ASAs communicate with each other, they should use the Generic Autonomic Signaling Protocol (GRASP) [I-D.ietf-anima-grasp]. It is essential that such communication is strongly secured to avoid malicious interference with the Autonomic Network Infrastructure (ANI).

For this reason, GRASP must run over a secure substrate that is isolated from regular data plane traffic. This substrate is known as the Autonomic Control Plane (ACP). A method for constructing an ACP at the network layer is described in [I-D.ietf-anima-autonomic-control-plane]. The present document discusses scenarios and requirements for constructing an ACP at layer 2. It is not intended to be a normative specification, since implementation details will depend on individual layer 2 technologies.

2. Network Scenarios Suitable for a Layer 2 ACP

The ANI design is aimed at managed networks, as explained in the reference model [I-D.ietf-anima-reference-model]. For a wide area network (such as a large campus, a multi-site enterprise network, or a carrier network considered as a whole) it is appropriate to construct the ACP using network layer techniques and network layer security. and that is the model described in [I-D.ietf-anima-autonomic-control-plane], However, in at least two cases an ACP covering a smaller geographical area may be appropriate:

1. A small enterprise that is completely within one building or several adjacent buildings, which also requires autonomic network management.
2. An enterprise that prefers in any case to segment its network into smaller units for management purposes.

In either case, we assume that the L2 ACP may extend into the Network Operations Centre (NOC) so that it can be interfaced to traditional tools for Operations, Administration and Maintenance, as described in [RFC8368]. In the terminology of that document, an L2 ACP is an instance of a Generalized ACP.

3. Requirements for a Layer 2 Technology

These requirements are intended to ensure that a layer 2 ACP can meet the needs of all components of the ANI.

1. Since GRASP is specified to run over IPv6, the technology must support transmission of IPv6 packets according to [RFC8200]. Since GRASP can run on a single network segment using link-local addresses, there is not required to be an IPv6 router or DHCPv6 server.
2. The technology must support multicast. If the switches are not completely transparent to layer 2 multicast, they must support Multicast Listener Discovery Version 2 (MLDv2) for IPv6 [RFC3810].
3. The technology should have a minimum MTU of 1500 bytes. Note that since GRASP is specified to run unicast operations over TCP, this is not an absolute requirement and the IPv6 minimum MTU of 1280 bytes would be acceptable. GRASP UDP multicast messages could in principle be fragmented but in normal operation this would be unusual.
4. The technology must support isolation of a given set of nodes (the "ACP VLAN").
5. The technology must support secure authorization for access to the ACP VLAN. If the VLAN technology in use does not support password protection, a VLAN access control list could be used.
6. The technology should support both the normal dataplane VLAN and the ACP VLAN on the same physical sockets. (Possibly the dataplane may be the native VLAN, i.e. frames with no VLAN tag.)
7. The technology should support line speed encryption of the ACP VLAN.
8. The technology should support wired/wireless bridging if relevant.
9. The technology should require minimal manual configuration of ACP nodes. However, it is expected that the nodes will need to be preconfigured before deployment with the VLAN ID, and with a password or encryption key if necessary. A solution which is both secure and self-configuring at Layer 2 is out of scope for this document.

A specific security protocol that supports both authentication and encryption of layer 2 packets for Ethernet LANs is MACsec, i.e. the IEEE Standard 802.1AE-2018 [MACsec]. For multicast packets, authentication is on a group basis (i.e., the originator is guaranteed to be a member of the group, rather than a specific interface). MACsec applies across all VLANs, but the ACP VLAN can be isolated from the data plane VLAN independently of MACsec. This solution does not extend to wireless networks. For IEEE 802.11 networks, IEEE Standard 802.11-2016 [WiFi] "WPA2" security within a dedicated Basic Service Set (BSS) might be considered adequate.

An ACP software module will be needed in each autonomic node, whose job is to provide the GRASP core with the following information about the L2 ACP:

1. A signal that the L2 ACP is available and secure.
2. The current global scope IPv6 address that GRASP should use as its primary locator, preferably a ULA, if available. As mentioned, if no such address is available, GRASP will simply operate with link-local addresses.
3. A list of [interface_index, link_local_address] pairs for all valid IPv6 interfaces attached to the L2 ACP. The interface index is an integer for maximum portability between operating systems.

4. Multiple Segments

This section is for further study.

The L2 ACP could in principle be extended across multiple segments or even multiple sites by use of secure L2VPN technology.

5. Implementation Status [RFC Editor: please remove]

A simple ACP software module emulating that needed for a secure L2 ACP has been implemented, but it does not in fact verify security. It may be found at <https://github.com/becarpenter/graspy/blob/master/acp.py> and is briefly documented in <https://github.com/becarpenter/graspy/blob/master/graspy.pdf>.

6. Security Considerations

The assumption of this document is that any Layer 2 solution chosen must have adequate security against interlopers and eavesdroppers. It should be noted that (at least in a wired network) this also requires adequate physical security to prevent access by unauthorized persons, including physical intrusion detection.

The fact that an IPv6 router is not required in an L2 ACP excludes many Layer 3 vulnerabilities by construction. No outside entity can generate link-local IPv6 packets, and no outside entity can send global scope packets to any autonomic node.

7. IANA Considerations

This document makes no request of the IANA.

8. Acknowledgements

Excellent suggestions were made by Michael Richardson and other participants in the ANIMA WG.

9. References

9.1. Normative References

9.2. Informative References

Appendix A. Change log [RFC Editor: Please remove]

draft-carpenter-anima-l2acp-scenarios-00, 2019-02-28:

Initial version

draft-carpenter-anima-l2acp-scenarios-01, 2019-10-03:

Added discussion of MACsec and WPA2

Editorial improvements

Authors' Addresses