[Swan-dev] regression newoe-02-klips rasie some questions.

Andrew Cagney andrew.cagney at gmail.com
Tue Jun 27 14:46:08 UTC 2017

On 26 June 2017 at 16:40, Paul Wouters <paul at nohats.ca> wrote:
> On Mon, 26 Jun 2017, Antony Antony wrote:
>>> We should have rejected the ESP transform before getting to the AUTH
>>> payload. We used to do this, and it did depend on the stack choice
>>> because it checked the "registered" esp/ah algorithms, which are
>>> also shown in "ipsec status".
>> in this test case the initiator, road, klips stack, is proposing
>> GCM to the responder east, netkey stack. When east respond with gcm road
>> can
>> not install SA.
> A similar thing is true for initiating. We should not propose any
> transform that is not "registered" for ESP/AH.

It looks like this issue has been around since v3.18 (July 27, 2016)
which included:

commit 52c7ac4c2548569e9c9348a45851c2ab03e3b37b
Date:   Mon May 30 09:30:12 2016 -0400

    pluto: for ESP/AH, strongly prefer aes-gcm; update passing tests

    Along with a preference for MODP2048; ESN=YES+NO (still needs
default change),
    and a real dislike (i.e., last on the list), for aes-cbc+sha1.

and I suspect the potential for this has been there for much longer -
the quirk where INTEG is checked before creating the proposal but
ENCRYPT is checked after accepting the proposal dates back to before
the IKEv2 proposal rewrite.

Since XFRM hides this, when did it become the default?

I'll park the changes to to the parser so it checks for kernel support for now.


More information about the Swan-dev mailing list