Influencing triggering of xfrm acquire messages?

Influencing triggering of xfrm acquire messages?

[David Martin]

Hi,
I have got a question regarding the triggering of xfrm acquire messages.

The setup is the following:
I'm using HIPL (https://launchpad.net/hipl) which implements the
Host Identity Protocol (HIP) and provides a control channel for the mutual peer
authentication and the generation of keying material. In the end of the initial
handshake, HIPL sets up the Linux Kernel IPsec implementation for the protection
of payload data.
The initial exchange is triggered by the following policy for outgoing traffic.
Note that 2001:10::/28 is the prefix for HIP addresses.

> martin@pisa1:~$ sudo ip xfrm policy
> src 2001:10::/28 dst 2001:10::/28
>    dir out priority 0
>    tmpl src :: dst ::
>        proto 0 reqid 0 mode transport

Anything matching the policy (eg. a ping matching the address prefix) triggers
an acquire message, so far so good. Everytime an acquire is triggered the kernel
sets up a SA looking like this:

> martin@pisa1:~$ sudo ip xfrm state
> src 2001:1a:a148:104c:92bb:671e:8100:9354 dst 2001:1c:5000:45b6:2d33:2c10:2726:a043
>   proto 0 reqid 0 mode transport
>   replay-window 0
>   sel src 2001:1a:a148:104c:92bb:671e:8100:9354/128 dst 2001:1c:5000:45b6:2d33:2c10:2726:a043/128 proto udp sport 49024 dport 1025

As long as it exists no additional acquire will be triggered which is a problem,
for example when shortly after an exchange the daemon is restarted and needs to
start another exchange with the same peer host.

Is this state supposed to be set up? Is it supposed to be removed automatically
once we set up our own SA? Is there a way to remove it manually to
trigger another acquire? Any input is welcome, thanks a lot in advance.

Greetings, David

Re: Influencing triggering of xfrm acquire messages?

[David Miller]

From: David Martin <david.martin.mailbox@googlemail.com>
Date: Thu, 11 Aug 2011 16:21:07 +0200

> As long as it exists no additional acquire will be triggered which is a problem,
> for example when shortly after an exchange the daemon is restarted and needs to
> start another exchange with the same peer host.
> 
> Is this state supposed to be set up? Is it supposed to be removed automatically
> once we set up our own SA? Is there a way to remove it manually to
> trigger another acquire? Any input is welcome, thanks a lot in advance.

The usage model is that the IPSEC daemon, like a routing daemon, manages
all IPSEC state.  And therefore it flushes all IPSEC state when it starts
up.

If you want the acquire messages, you need to flush the entries for which
you want the acquire to trigger when you startup.

Re: Influencing triggering of xfrm acquire messages?

[David Martin]

Hi,

On Thu, Aug 11, 2011 at 4:36 PM, David Miller <davem@davemloft.net> wrote:
> From: David Martin <david.martin.mailbox@googlemail.com>
> Date: Thu, 11 Aug 2011 16:21:07 +0200
>
>> As long as it exists no additional acquire will be triggered which is a problem,
>> for example when shortly after an exchange the daemon is restarted and needs to
>> start another exchange with the same peer host.
>>
>> Is this state supposed to be set up? Is it supposed to be removed automatically
>> once we set up our own SA? Is there a way to remove it manually to
>> trigger another acquire? Any input is welcome, thanks a lot in advance.
>
> The usage model is that the IPSEC daemon, like a routing daemon, manages
> all IPSEC state.  And therefore it flushes all IPSEC state when it starts
> up.
>
> If you want the acquire messages, you need to flush the entries for which
> you want the acquire to trigger when you startup.

thanks for your reply, that sounds reasonable. The problem is this
specific state I
mentioned (see below).

> martin@pisa1:~$ sudo ip xfrm state
> src 2001:1a:a148:104c:92bb:671e:8100:9354 dst 2001:1c:5000:45b6:2d33:2c10:2726:a043
>   proto 0 reqid 0 mode transport
>   replay-window 0
>   sel src 2001:1a:a148:104c:92bb:671e:8100:9354/128 dst 2001:1c:5000:45b6:2d33:2c10:2726:a043/128 proto udp sport 49024 dport 1025

It is not set up explicitly by us but on its own when the acquire is triggered.
We already take care of "our" states and flush them on exit / startup so that
they do not prohibit another acquire. This one though remains for a certain
time and the question is: how can I remove it? Which parameters do I need
to pass to the xfrm interface to flush it?

It does not seem to be possible with the iproute2 implementation
('ip xfrm state delete ...') as it requires a protocol in
{esp | ah | comp | route2 | hao} to delete a state. proto 0 as it is here is not
supported and refused as invalid. I have tried to adapt our code and send
a delete request with protocol, spi and ports set to 0 but this does not have
the desired effect.

Any idea how to tackle this?

David