[Swan-dev] defaults for ike= and esp= need updating?

Andrew Cagney andrew.cagney at gmail.com
Fri Dec 9 15:13:42 UTC 2016


[inline]

On 8 December 2016 at 11:36, Paul Wouters <paul at nohats.ca> wrote:

> On Thu, 8 Dec 2016, Andrew Cagney wrote:
>
> Given something like ike=sha1 or ike=aes or ...  pluto uses the following
>> table to fill in the ENCR-PRF;MODP blanks:
>>
>
> It should basically act as a filter on the "default set".
>
>    DH:OAKLEY_GROUP_MODP2048, OAKLEY_GROUP_MODP1536, OAKLEY_GROUP_MODP1024,
>>
>
>
> Can this behaviour be tuned for IKEv1 or IKEv2? I would like IKEv2 to
> not have 1536/1024. And I would like IKEv1 to not have 1024.
>
>
I think so.  The ike_alg structures contain this information, we just need
to take the bit between our teeth and use it.

One technical nit.  This makes the ESP/AH parser code dependent on ike_alg
(the IKE code, via plutoalg.c) is already).  That in turn breaks the,
unmaintained and probably already broken, testing/lib/libswan/algparse.c.
Fixing means moving the deck chairs ike_alg*.[hc] and crypt_*.[hc] to
libswan.a, I think I'll hold off :-)



>    ENCRYPT: OAKLEY_AES_CBC, OAKLEY_3DES_CBC,
>>
>
> This is fine for IKEv1. For IKEv2 we would want AES_GCM and not 3DES.
>
>    PRF: OAKLEY_SHA1, OAKLEY_MD5,  (it's actually a HMAC based on)
>>
>
> Actually, we sort of only do PRF == INTEG, so for ike=sha1 it should
> pick sha1 as prf. For ike=aes it should pick the strongest default,
> so a sha2 flavour? (sha2_256 is fine for IKE, we just want to avoid
> it for ESP due to the linux bug still existing and badly fixed in
> 2.6.33)
>
>
IKE and ESP have separate tables and separate implementations so that works.



> Similarly, for esp:
>>
>>     encrypt=AES
>>
>
> SHA2_512 or SHA1
>
> and esp/ah:
>>
>>     INTEG="MD5", "SHA1" (its actually a truncated HMAC based on ...)
>>
>> do these need updating?
>>
>
> Yes.
>
> (my preference is to drop the magic defaults but I suspect that is too
>> radical)
>>
>
> Yes, that falls in the category "pony" and "world peace" :)
>
> For guidance please see:
>
> https://tools.ietf.org/html/draft-ietf-ipsecme-rfc7321bis
>
> https://tools.ietf.org/html/draft-ietf-ipsecme-rfc4307bis
>
> Paul
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan-dev/attachments/20161209/d2fe8f97/attachment.html>


More information about the Swan-dev mailing list