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

Paul Wouters paul at nohats.ca
Mon Jun 26 11:37:25 UTC 2017


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".

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.
          * 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.
          */



>>> Could it be KLIPS does not support ESP_AES_GCM_C? I am not sure yet. If

KLIPS should tell via PFKEY what it does support.

>>> Do we need another ESP default list based klips or netkey:)

No, the default set should be filtered based on known supported
algorithms we got via pfkey+manual registration.

> I wonder if all algorithms, if they are kernel modules, loaded at start? Or
> could a cryptp module get loaded when pluto install an SA? Or when ESP
> packet actually arrive xfrm/klips call that crypto function.

We load all known rypto algorithms in _stackmanager. Yes it is a
hardcoded list.

Paul


More information about the Swan-dev mailing list