Scenarios and Requirements for Layer 2 Autonomic Control Planes
The University of Auckland
School of Computer Science
University of Auckland
PB 92019
Auckland
1142
New Zealand
brian.e.carpenter@gmail.com
Huawei Technologies
Q14, Huawei Campus
No.156 Beiqing Road
Hai-Dian District, Beijing
100095
P.R. China
leo.liubing@huawei.com
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.
As defined in , 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) .
It is essential that such communication is strongly secured to avoid
malicious interference with the Autonomic 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 .
The present document discusses scenarios and requirements for constructing
an ACP at layer 2.
The ANI design is aimed at managed networks, as explained in the 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 ,
However, in at least two cases an ACP covering a smaller geographical area may be appropriate:
A small enterprise that is completely within one building or several adjacent buildings,
but is large enough to require autonomic network management.
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 .
In the terminology of that document, an L2 ACP is an instance of a Generalized
ACP.
The technology must support transmission of IPv6 packets according to
. 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.
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 .
The technology should have a minimum MTU of 1500 bytes.
The technology must support isolation of a given set of nodes (the "ACP VLAN").
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.
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.)
The technology should support line speed encryption of the ACP VLAN.
The technology should support wired/wireless bridging if relevant.
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 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 small 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:
A signal that the L2 ACP is available and secure.
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.
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.
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.
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
and is briefly documented in .
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.
This document makes no request of the IANA.
Excellent suggestions were made by
TBD
and other participants in the ANIMA WG.
draft-carpenter-anima-l2acp-scenarios-00, 2019-02-28:
Initial version