[Swan-dev] IKEv2: notes on parsing ike=aes_ctr-aes-3des-sha1-sha2-dh21-dh24, ...

[Paul Wouters]

On Sun, 19 Aug 2018, Andrew Cagney wrote:

>     ike=aes_ctr-aes-3des-sha1-sha2-dh21-dh24, ...

not sure I like this, because it doesn't handle mixed use of
AEAD/non-AEAD? Although we hope that non-AEAD is going extinct soon.

> Currently it isn't possible to descripe a single proposal with
> multiple algorithms.  This both limits what we can send across the
> wire (and annoying to me, means we can't feed the default proposals
> into the parser).  One possible syntax is:
>
>    ike=aes_ctr-aes-3des-sha1-sha2-dh21-dh24,...

or:

 	ike-encr=aes,aes_gcm
 	ike-integ=sha2,sha1
 	ike-dh=dh22,dh23
 	esp-encr=aes_gcm,aes
 	esp-integ=sha2

The issue is again AEAD/non-AEAD, where we turn integ into prf

also, we should be able to ignore dhXX when pfs=no. We already had our
first issue where someone adding pfs=no got their ike= line rejected.
I think I would prefer a silent ignore. I would really like to see the
future to mandate PFS. Since you cannot really know if your IPsec SA
will be established from the Initial Exchanges or the Create_Child_sa,
there is no sane configuration where this would/should have different
values.

Another way would be to allow people to specify actual proposals on the
wire:

 	ike=aes_gcm-sha2,chacha20poly1305,dh21;aes256,3des,sha2,sha1,dh21

Which would get simpler when non-AEAD usage dies of.

> The got-ya is with 'none'.  For instance, in both:
>
>     esp=aes-none
>     ike=aes_gcm-none
>
> while 'none' could mean either DH or INTEG (yes, the latest RFC added
> 'none' for DH), the above strategy interprets it as integrity.  The
> likely workaround is to specify:
>
>    ike=aes_gcm;none
>
> to force none as DH.

everything "none" should be autodetected by us and never need
specification by the enduser. It is simply too confusing to tell
them use "none" for integrity.

Paul