IETF - RFC 8994
An Autonomic Control Plane (ACP)
Organization: | IETF |
Publication Date: | 1 May 2021 |
Status: | active |
Page Count: | 128 |
scope:
Applicability and Scope
Please see the following Terminology section (Section 2) for explanations of terms used in this section.
The design of the ACP as defined in this document is considered to be applicable to all types of "professionally managed" networks: Service Provider, Local Area Network (LAN), Metropolitan Area Network (MAN/Metro), Wide Area Network (WAN), Enterprise Information Technology (IT) and Operational Technology (OT) networks. The ACP can operate equally on Layer 3 (L3) equipment and on L2 equipment such as bridges (see Section 7). The hop-by-hop authentication, integrity protection, and confidentiality mechanism used by the ACP is defined to be negotiable; therefore, it can be extended to environments with different protocol preferences. The minimum implementation requirements in this document attempt to achieve maximum interoperability by requiring support for multiple options depending on the type of device: IPsec (see "Security Architecture for the Internet Protocol" [RFC4301]) and Datagram Transport Layer Security (DTLS, see Section 6.8.4).
The implementation footprint of the ACP consists of Public Key Infrastructure (PKI) code for the ACP certificate including EST (see "Enrollment over Secure Transport" ), GRASP, UDP, TCP, and Transport Layer Security (TLS, see Section 6.1). For more information regarding the security and reliability of GRASP and for EST, the ACP secure channel protocol used (such as IPsec or DTLS), and an instance of IPv6 packet forwarding and routing via RPL, see "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks" [RFC6550], which is separate from routing and forwarding for the data plane (user traffic).
The ACP uses only IPv6 to avoid the complexity of dual-stack (both IPv6 and IPv4) ACP operations. Nevertheless, it can be integrated without any changes to otherwise IPv4-only network devices. The data plane itself would not need to change, and it could continue to be IPv4 only. For such IPv4-only devices, IPv6 itself would be additional implementation footprint that is only required for the ACP.
The protocol choices of the ACP are primarily based on wide use and support in networks and devices, well-understood security properties, and required scalability. The ACP design is an attempt to produce the lowest risk combination of existing technologies and protocols to build a widely applicable, operational network management solution.
RPL was chosen because it requires a smaller routing table footprint in large networks compared to other routing protocols with an autonomically configured single area. The deployment experience of large-scale Internet of Things (IoT) networks serves as the basis for wide deployment experience with RPL. The profile chosen for RPL in the ACP does not leverage any RPL-specific forwarding plane features (IPv6 extension headers), making its implementation a pure control plane software requirement.
GRASP is the only completely novel protocol used in the ACP, and this choice was necessary because there is no existing protocol suitable for providing the necessary functions to the ACP, so GRASP was developed to fill that gap.
The ACP design can be applicable to devices constrained with respect to CPU and memory, and to networks constrained with respect to bitrate and reliability, but this document does not attempt to define the most constrained type of devices or networks to which the ACP is applicable. RPL and DTLS for ACP secure channels are two protocol choices already making ACP more applicable to constrained environments. Support for constrained devices in this specification is opportunistic, but not complete, because the reliable transport for GRASP (see Section 6.9.2) only specifies TCP/TLS. See Appendix A.8 for discussions about how future standards or proprietary extensions and/or variations of the ACP could better meet expectations that are different from those upon which the current design is based, including supporting constrained devices better.
Document History
