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

Commentary: During IETF 106 I solicited some feedback on the ACP IPsec / IKEv2 usage from Valery Smyslov ; I 've tried to digest that feedback into new text here . Some aspects are still subject to change . I also made a minor tweak to the DTLS section to bring it into parity with the IPsec one . 
 Merging first , then fixing .
Any security association protocol MUST use PFS (such as profiles
providing PFS).
Any security association protocol MUST provide Forward Secrecy
(whether inherently or as part of a profile of the security
association protocol).
An ACP node announces its ability to support IKEv2 as the ACP secure
channel protocol in GRASP as "IKEv2".
An ACP node that is supporting native IPsec MUST use IPsec security
setup via IKEv2 for tunnel mode and IPsec/IKE signaling accordingly
for IPv6 payload (e.g.: ESP next header of 41).  It MUST use local
and peer link-local IPv6 addresses for encapsulation.
Authentication MUST use the ACP domain certificates.  Certificate
Encoding MUST support "PKCS #7 wrapped X.509 certificate" (0) (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.
An ACP node announces its ability to support IPsec, negotiated via
IKEv2, as the ACP secure channel protocol in GRASP as the "IKEv2"
method for the "AN_ACP" objective.
The ACP usage of IPsec and IKEv2 mandates a narrow profile of the
current standards-track usage guidance for IPsec RFC8221 and IKEv2
RFC8247.  This profile provides for stringent security properties and
can exclude deprecated/legacy algorithms because there is no need for
interoperability with legacy equipment for ACP channels.  Any such
backward compatibility would lead only to increased attack surface
and implementation complexity, for no benefit.
An ACP node that is supporting native IPsec MUST use IPsec in tunnel
mode, negotiated via IKEv2, and with IPv6 payload (e.g., ESP Next
Header of 41).  It MUST use local and peer link-local IPv6 addresses
for encapsulation.  Manual keying MUST NOT be used (independent of
the security weaknesses of manual keying, it is incompatible with an
autonomic platform).
IKEv2 authentication MUST use authentication method=1 ("RSA Digital
Signature") for ACP certificates with RSA key and methods 9,10,11 for
ACP certificates with ECC key according to the keys size/curve.
A certificate payload with the ACP certificate MUST be included
during IKEv2 authentication to support the ACP domain membership as
described in certcheck, because it is using additional elements of
the ACP certificates.  ACP peers are expected to have the same set of
Trust Anchors (TA), so a certificate path MUST only be included in
the signaled payload when the path contains intermediate certificates
not in the TA set, such as sub-CAs (see acp-registrars).
IPsec MUST support ESP with ENCR_AES_GCM_16 (RFC4106) due to its
higher performance over ENCR_AES_CBC.  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).  These requirements are based
on RFC8221 but limited to the minimum necessary options because there
is no need for interoperability with legacy equipment for ACP
channels, instead any such backward compatibility would reduce the
minimum security or performance required for ACP channels or increase
the implementation complexity of the ACP.
ACP IPsec implementations MUST support ESP with ENCR_AES_GCM_16
(RFC4106) due to its higher performance over ENCR_AES_CBC.  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).  When
using AES encryption, 256-bit keys MUST be used.  AES-GCM is an AEAD
cipher mode, so no ESP authentication algorithm requirement is
needed.
IKEv2 MUST follow RFC8247 as necessary to support the above listed
IPsec requirements.
As for ESP (above), for IKEv2, the ENCR_AES_GCM_16 encryption
algorithm (with 256-bit keys) MUST be supported.  The IKEv2
PRF_HMAC_SHA2_512 pseudorandom function MUST be supported.
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.
A certificate payload with the ACP certificate MUST be included
during IKEv2 authentication to support the ACP domain membership
check as described in certcheck, because it is using additional
elements of the ACP certificates.  ACP peers are expected to have the
same set of Trust Anchors (TA), so a certificate path MUST only be
included in the signaled payload when the path contains intermediate
certificates not in the TA set, such as sub-CAs (see acp-registrars).
ACP nodes are identified by their ACP address, so the ID_IPv6_ADDR
IKEv2 identification payload MUST be used and MUST convey the ACP
address.  If the peer's ACP domain certificate includes an ACP
address in the domain information, the address in the identification
payload must match the address in the certificate (allowing for the
presence of virtualization bits in the ACP addressing scheme used).
IKEv2 authentication MUST use authentication method 14 ("Digital
Signature") for ACP certificates; this authentication method can be
used with both RSA and ECDSA certificates, as indicated by a PKIX-
style OID.
The Digital Signature hash SHA2-512 MUST be supported (in addition to
SHA2-256).
Once there are updates to RFC8247, 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 or the key-
exchange group recommendations are changed.
Additional requirements from RFC8247 MAY be used for ACP channels as
long as they do not result in a reduction of security over the above
MTI requirements.
An ACP node announces its ability to support DTLS as the ACP secure
channel protocol in GRASP as the "DTLS" method for the "AN_ACP"
objective.