An Autonomic Control Plane (ACP)
Extracted elements (28)
DULL GRASP was chosen for ACP neighbor discovery over LLDP or mDNS because GRASP is already a required ACP dependency and can be confined to link-local scope without traversing L2 domains that would undermine the hop-by-hop security model. LLDP lacks security and mDNS has L2 domain propagation issues incompatible with ACP's per-link authentication.
RPL was chosen as the ACP routing protocol because it produces a smaller routing table footprint in large networks compared to link-state protocols operating in a single autonomically configured area. Large-scale IoT deployments provide operational validation of RPL at scale. The ACP profile intentionally avoids RPI extension headers to keep ACP a pure software control-plane addition.
The acp-node-name is encoded as a single email-like string in the X.509 SubjectAlternativeName otherName field rather than split across multiple certificate fields, enabling backend systems to identify ACP nodes by one unique string and avoiding occupation of the subject field attributes needed for other LDevID uses. The otherName form also avoids misinterpretation as a real email address.
The ACP uses ULA (RFC 4193) IPv6 addressing to provide autonomically managed, collision-resistant addresses without a central global registry. The /48 ULA prefix is derived by hashing the ACP routing-subdomain, enabling per-domain automatic address generation; the rsub field allows a single ACP domain to employ multiple /48 prefixes for structured routing.
The ACP uses only IPv6 to avoid dual-stack complexity, but can be integrated into otherwise IPv4-only networks without changing the data plane. IPv6 is additional implementation footprint required solely for ACP. Support for constrained devices is opportunistic but incomplete because GRASP reliable transport specifies only TCP/TLS, which is not suitable for the most constrained environments.
ACP context separation MUST keep ACP traffic in its dedicated VRF, isolated from the data plane. This ensures the ACP operates independently of any data plane misconfiguration, routing changes, or security policies applied to the data plane.
ACP nodes acting as EST servers MUST announce the 'SRV.est' objective via GRASP M_FLOOD messages. The flood MUST be sent periodically (default 60 seconds, operator-configurable but not less than 60 s); TTL SHOULD be 3.5 times the period. The 'SRV.est' objective SHOULD only be announced when the node can successfully communicate with the CA.
ACP nodes MUST NOT support RSA keys with modulus less than 2048 bits or ECC curves with group order less than 256 bits. RSA 2048-bit and ECDSA P-256 MUST be supported; P-384 and P-521 SHOULD be supported. ECDSA signatures on ECDSA certificates MUST be supported; RSA signatures on ECDSA certificates MUST also be supported because CAs may not yet support ECC.
ACP nodes MUST support certificate and TA renewal via EST. An ACP network MUST have at least one EST server node. The EST server MUST present a certificate passing the ACP domain membership check and MUST include the id-kp-cmcRA extended key usage attribute; EST clients MUST verify its presence to prevent illicit EST servers from supplying fake CA certificates.
ACP secure channels MUST be established using either IPsec (with IKEv2) or DTLS; both MUST authenticate the peer via the ACP domain membership check using ACP certificates. The channel type is negotiated per adjacency, and the ACP secure channel profiles define which combinations of protocol and encapsulation are mandatory vs. optional.
ACP support on L2 switches is achieved by running per-L2-port DULL GRASP. L2 switches supporting ACP MUST run DULL GRASP on each L2 port to discover ACP-capable neighbors and establish ACP secure channels, enabling the ACP to operate hop-by-hop through L2 segments.
An ACP certificate MUST carry an otherName in the X.509 SubjectAlternativeName extension containing a syntactically valid AcpNodeName. Nodes MUST be able to receive their ACP address via the 32HEXDIG acp-address field and MUST also be able to authenticate peers whose acp-address is '0' (address determined by other means) or whose acp-address is omitted (non-secure-channel domain members).
An ACP node MUST have an LDevID (ACP) certificate containing an AcpNodeName and information about one or more Trust Anchors. Manual keying via shared secrets is prohibited; asymmetric keying material without certificates also does not meet requirements for autonomous peer-to-peer ACP domain authentication.
Certificate renewal SHOULD start after less than 50% of the domain certificate lifetime has elapsed, providing ample time for operators to investigate renewal failures and supporting nodes that operate disconnected from the CA for extended periods.
For ACP via IPsec, IKEv2 MUST be used. The cipher suite profile MUST follow RFC 8221 (IPsec/ESP) and RFC 8247 (IKEv2). An optional GRE-over-IPsec variant is defined for environments where native IPsec ESP encapsulation is problematic (e.g., certain middleboxes).
TA information MUST be provisioned to an ACP node during initial enrollment and MUST also be renewable via EST. ACP nodes MUST support certificate path validation with zero or one intermediate CA; they SHOULD support two intermediate CAs and two TAs to permit TA migration.
The ACP domain membership check is a 5-step process: (1) peer proves private key ownership; (2) certificate path validation against TAs per RFC 5280; (3) OCSP/CRL revocation check when available — if revocation is later discovered, the ACP secure channel MUST be closed; (4) matching lowercase-normalized acp-domain-name; (5) non-omitted acp-address required for ACP secure channel establishment.
The ACP uses RPL (RFC 6550) as its routing protocol in a single-instance configuration. The ACP RPL profile operates without RPL Packet Information (RPI) IPv6 extension headers, making it a pure control-plane software requirement with no forwarding-plane changes needed.
TLS used by ACP components MUST comply with RFC 7525; TLS 1.2 is REQUIRED and older versions MUST NOT be used. TLS 1.3 SHOULD be supported. Cipher suites MUST offer TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 and MUST NOT offer options with less than 256-bit symmetric key strength or hash strength less than 384 bits.
ACP addresses are IPv6 ULA addresses within a /48 prefix derived by hashing the routing-subdomain (formed from acp-node-name). The base addressing sub-scheme allocates a 64-bit Node-ID in the low 64 bits; alternative sub-schemes (ACP-Zone, ACP-Manual, ACP-Vlong-8/16) vary the zone and extension field layouts within the same /48.
ACP connect interfaces allow non-ACP-capable nodes (NMS, SDN controllers) to access the ACP without establishing ACP secure channels. An ACP node exposes a connect interface directly into its ACP VRF; the non-ACP node is explicitly configured to use it. A VRF-select variant allows combined ACP and data-plane access on one physical interface.
DULL GRASP (Discovery Unsolicited Link-Local GRASP) is used for per-link ACP neighbor discovery on all native interfaces without any prior configuration. Each candidate peer discovered via multiple interfaces results in one adjacency entry per interface in the ACP adjacency table.
GRASP runs as a core service inside the ACP, using the ACP VRF as its security and transport substrate (TCP/TLS over ACP addresses). The ACP GRASP instance supports service discovery for BRSKI, OAM functions, and ACP certificate maintenance. DULL GRASP operates separately on each link outside the ACP for neighbor discovery.
The ACP is implemented as a VRF instance with a dedicated IPv6 forwarding table and routing table, entirely separate from the data plane. ACP secure channels are mapped to ACP virtual interfaces attached to this VRF. An ACP loopback interface within the VRF holds the node's ULA ACP address.
IANA registered id-on-AcpNodeName (OID 1.3.6.1.5.5.7.8.10) in the 'PKIX Other Name Forms' (id-on) registry and the ASN.1 module ANIMA-ACP-2020 with identifier id-mod-anima-acpnodename-2020 (97) in the 'SMI Security for PKIX Module Identifier' (id-mod) registry, both defined by this document.
An ACP node's certificate (including acp-node-name and optional serialNumber fields) may be retrievable by unauthenticated neighbors during a failing ACP secure channel setup attempt, exposing device type information that could aid targeted attacks. Operators should consider what device-identifying fields to include in ACP certificates.
The ACP provides hop-by-hop authentication, integrity protection, and confidentiality for all ACP traffic independently of the data plane. Even if the data plane is compromised or misconfigured, ACP connectivity and its security guarantees are maintained as long as a physical path exists between ACP nodes and their certificates remain valid.
The AcpNodeName is an IA5String encoded as 'acp-address@acp-domain-name' where acp-address is 32 hexadecimal digits (128-bit IPv6 address) or '0', optionally preceded by a '+rsub' routing-subdomain component in the local-part. It is carried in the X.509 SubjectAlternativeName otherName extension with OID id-on-AcpNodeName (1.3.6.1.5.5.7.8.10).