netdev - Re: Influencing triggering of xfrm acquire messages?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 17 Aug 2011 12:21:15 +0200
From:	David Martin <david.martin.mailbox@...glemail.com>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org
Subject: Re: Influencing triggering of xfrm acquire messages?

Hi,

On Thu, Aug 11, 2011 at 4:36 PM, David Miller <davem@...emloft.net> wrote:
> From: David Martin <david.martin.mailbox@...glemail.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@...a1:~$ 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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html