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

[Antony Antony]

On Mon, Jun 26, 2017 at 07:37:25AM -0400, Paul Wouters wrote:
> On Mon, 26 Jun 2017, Antony Antony wrote:
> 
> > AUTH payload failure is a different code path. This was AUTH payload success
> > and installing SA failed; ie AUTH exchange failure. So parent advanced and
> > the child didn't.
> 
> 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.

> The issue got more complicated because the XFRM/NETKEY stack does not
> implement a function (AFAIK) to ask which algorithms the kernel
> supports. It is part of the PFKEY API, and we used that for KLIPS and
> NETKEY. But we know NETKY lies to us, so we manually tweak the
> returned list to match our known reality.
> 
> Quoted from kernel_netlink.c:
> 
>         /*
>          * also open the pfkey socket, since we need it to get a list of
>          * algorithms.

is this comment still true? with crypto api, post 2010? or a dated comment.
Above part go back to 2007. Next lines are added in 2012. I would imagine 
netlink can get a list such as the /proc/crypto 

>          * There is currently no netlink way to do this.
>          */
>         init_pfkey();
> 
>         /*
>          * The PFKEY interface is on life support.  Since it isn't
>          * being extended to support new algorithms, they need to be
>          * hard wired.
>          *
>          * Kind of lame since pluto should query the kernel for what
>          * it supports.  OTOH, the query might happen before the
>          * crypto module gets loaded.
>          */