Draft: draft-ietf-anima-autonomic-control-plane

Commentary: I 've done some slight editing of your text for readability . I have removed text that is repeating RFC8247 and RFC8221 poorly , leveraging those documents better . I have made a change to say that trust anchor certificates should be sent . ( Believe me , without that , it makes debugging really difficult )
ACP nodes MUST support RSA and Elliptic Curve (ECC) public keys in
ACP certificates.  ACP certificates wth ECC keys MUST indicate to be
Elliptic Curve Diffie-Hellman capable (ECDH) if X.509 v3 keyUsage and
extendedKeyUsage are included in the certificate.
ACP nodes MUST support RSA and Elliptic Curve (ECC) public keys in
ACP certificates.  ACP certificates with ECC keys MUST indicate to be
Elliptic Curve Diffie-Hellman capable (ECDH) if X.509 v3 keyUsage and
extendedKeyUsage are included in the certificate.
ACP IPsec implementations MUST comply with RFC8221 (and its updates),
with the following modifications to simplify hardware accelerated ACP
IPsec implementation requirements by eliminating requirements for
legacy or cryptographically weak options.
ACP MUST NOT use any NULL encryption option due to the
confidentiality of ACP payload that may not be encrypted by itself
when carrying legacy management protocol traffics as well as hop-by-
hop GRASP, which is designed to rely on the ACP for confidentiality
of hop-by-hop distributed information.  Therefore, IPsec MUST support
ESP and MUST NOT use AH.  For ESP, ENCR_NULL MUST NOT be used for ACP
secure channels.
Only ENCR_AES_GCM_16 is REQUIRED as an encryption algorithm for ACP
secure channels with ESP.
AES-GCM is an authenticated encryption with associated data
(AEAD) cipher mode, so no ESP authentication algorithm
requirement is needed (unless further encryption algorithms are
supported), further simplifying ACP IPsec implementations.
there is no requirement to interoperate with legacy equipment
in ACP secure channels, so a single MTI encryption algorithm
for IPsec in ACP secure channels is sufficient for
interoperability.
There is no unconditional requirement against ENCR_AES_CCM_8
because it is currently not likely that it would be preferrable in
ACP secure channels for more constrained IoT devices over options
such as DTLS.  In RFC8221 this algorithm is more desirable,
because of solutions relying only on IPsec without such non-IPsec
alternatives.
There is no unconditional requirement against
ENCR_CHACHA20_POLY1305 because there is currently no mechanism in
the ACP to migrate all secure channels in an ACP domain to a
different preferred encryption algorithm in the case of future
discovered crypto weaknesses of AES.  Once such mechanisms are
defined, ENCR_CHACHA20_POLY1305 would be a good encryption
algorithm, but due to the transitive traffic through ACP secure
channels only when this does not result in an unexpected drop in
performance.
When using AES for encryption, keys less than 256 bits MUST NOT be
used, and 256-bit keys MUST be supported.
Once there are updates to RFC8221, these should accordingly be
reflected in updates to these ACP requirements, for example if
ENCR_AES_GCM_16 was to be superceeded in the future.
IKEv2 for ACP secure channels MUST support the requirements of
RFC8247 (as necessary to support the above described modified RFC8221
requirements for IPsec via ESP).  Because IKEv2 for ACP secure
channels is sufficient to be implemented in control plane software as
opposed to ESP (which may need to be implemented in accelerated
forwarding plane for sufficient performance), there are no
restrictions on the requirements of RFC8247 for ACP secure channels.
Instead, the following paragraphs describe additional or stricter
requirements necessary for the authentication of ACP secure channels
in IKEv2 via ACP domain certificates.
IKEv2 Diffie-Hellman key exchange group 19 (256-bit random ECP) MUST
be supported (in addition to 2048-bit MODP).  ECC provides a similar
security level to finite-field (MODP) key exchange with a shorter key
length, so is generally preferred absent other considerations.
IKEv2 authentication MUST use the ACP domain certificates.  The
Certificate Encoding "PKCS #7 wrapped X.509 certificate" (1) MUST be
supported (see IKEV2IANA for this and other IANA IKEv2 parameter
names used in this text).  If certificate chains are used, all
intermediate certificates up to, but not including the locally
provisioned trust anchor certificate must be signaled.
The ACP MUST NOT use any NULL encryption option due to the
confidentiality of ACP payload.  All other MUST and SHOULD algorithms
specified by RFC8221 (and replacement documents) are to be supported.
The order of the proposals is not specified by RFC8221.  The first
protocol offered which is supported by both ends is generally chosen,
and so this document recommends listing the higher performance
protocols first.
The ENCR_AES_GCM_16 is listed as a MUST in RFC8221 and is often the
faster protocol, so it is to be listed first.
If an ACP node can perform ENCR_AES_CBC, or ENCR_AES_CCM_8 at higher
performance than ENCR_AES_GCM_16 or ENCR_CHACHA20_POLY1305, then
those should be listed first in the policy.
There is no unconditional requirement against ENCR_AES_CBC use.
AES-GCM is an authenticated encryption with associated data (AEAD)
cipher mode, so no ESP authentication algorithm requirement is
needed (unless further encryption algorithms are supported),
further simplifying ACP IPsec implementations.
there is no requirement to interoperate with legacy equipment in
ACP secure channels, so a single MTI encryption algorithm for
IPsec in ACP secure channels is sufficient for interoperability.
RFC8221 allows for 128-bit or 256-bit AES keys.  This document
mandates that only 256-bit AES keys MUST be supported.
When RFC8221 is updated, ACP implementations will need to consider
legacy interoperability, and the IPsec WG has generally done a very
good job of taking that into account in its recommendations.
RFC8247 provides a baseline recommendation for mandatory to implement
ciphers, integrity checks, pseudo-random-functions and Diffie-Hellman
mechanisms.  Those recommendations, and the recommendations of
subsequent documents apply well to the ACP.  Because IKEv2 for ACP
secure channels is sufficient to be implemented in control plane
software, rather than in ASIC hardware, this documents makes no
changes to the recommendations.
This document does establish a policy statement as permitted by
RFC8247 for the specific case of ACP traffic.
The IKEv2 Diffie-Hellman key exchange group 19 (256-bit random ECP),
listed as a SHOULD, is to be configured, as long as with the 2048-bit
MODP (group 14).  The ECC provides a similar security level to
finite-field (MODP) key exchange with a shorter key length, so is
generally preferred absent other considerations.
IKEv2 authentication MUST use the ACP domain certificates.  The
Certificate Encoding "PKCS #7 wrapped X.509 certificate" (1) MUST be
supported (see IKEV2IANA for this and other IANA IKEv2 parameter
names used in this text).  If certificate chains are used, all
intermediate certificates up to, and including the locally
provisioned trust anchor certificate must be signaled.  While the
top-trust anchor will never be used by a properly configured peer, it
can provide a significant amount of useful information to debug an
ACP network.  There is some small concern that it might provide
useful information to an attacker about who the network is, the other
certificates that are sent already clearly indicate this information.