[hope its fine to cross-post ipsec and ipsecme given how one is concluded, but may have more long-time subscribers]
We're looking for opinions about an IPsec profile for "Autonomic Control Plane" draft-ietf-anima-autonomic-control-plane, or specifically 6.7.1.1.1 of: https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/be056679b9c9cac8c2d664958a3b91585b010a83/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane.txt Quick background so you do not need to read anything more than 6.7.1.1.1: ACP builds an "overlay" network with hop-by-hop IKEv2/ESP "tunnels". These hops are meant to be typical enterprise/WAN/DC software...Giga/Terrabit routers. Hence some interest on side of the authors (me) to see how we can adopt the crypto algorithm rementserofile of RFC8221 to minimize high-speed algorithm implementation requirements so that ACP would be as easy to adopt across various vendor crypto HW as possible. Note that ACP also supports DTLS, but we think that DLS would primarily be used in lower-end devices, so crypto woould be done in software there, hence we do not bother taking the step to try to optimize / minimize the number of required algorithms. Here is the adoption of the RFC8221 algorithms: OTHERS - as in RFC8221 (MUST NOT / SHOULD NOT) ENCR_NULL - MUST NOT (require confidentiality of payload in ACP) (was MUST in RFC8221) ENCR_AES_GCM_16 - MUST (was MUST in RFC8221) ENCR_AES_CBC - SHOULD if higher perf than ENCR_AES_GCM_16, else MAY (was MUST in RFC8221) ENCR_AES_CCM_8 - SHOULD if higher perf than ENCR_AES_GCM_16, else MAY (was SHOULD in RFC8221) ENCR_CHACHA20_POLY1305 - SHOULD with equal or higher perf than ENCR_AES_GCM_16, else MAY (was SHOULD in RFC8221) To make life easy, we have one ESP MTI algo to interop, that's GCM_16. Because packets will be hop-by-hop forwarded across multiple tunnels, ACP has no legacy interop requirements. Aka: We only need to think about the relevant algorithms for device types so old, that they would never implement ACP (and we have to guess for those devices of course, but we have some good experience of pre-standard vendor implementations). Effectively, we downgrade and modify requirements for CBC, CCM_8 and POLY1305 acording to our understandings: 1. Given how we have one MTI (GCM_16), and no further need for legacy compatibility, there is no need for additional MTI (MUST), so the remaining desirable algorithms can be SHOULD or less. 2. A SHOULD only makes sense in the ACP use case if the actual performance is higher than that of the MTI, hence the opportunistic performance conditioned SHOULD in CBC and CCM_8. Expectation is that those algos would be supported by a vendor if it can make it faster, and then that speed benefit would be had when connecting that vendors devices together. 3. POLY1305 is really desirable as crypto backup to the AES options, so the performance based SHOULD is not opportunistic as for CBC and CCM_8. Maybe the language is not 100% correct. Maybe the language is not perfect. seems like i could leave out all the "MAY" at the end and achieve the same. Cheers Toerless _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
