netdev - Re: IPsec: Why do pfkey_getspi and xfrm_alloc_userspi call xfrm_find_acq

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] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 23 Aug 2010 15:30:46 +0200
From:	Christophe Gouault <christophe.gouault@...nd.com>
To:	David Miller <davem@...emloft.net>
CC:	netdev@...r.kernel.org
Subject: Re: IPsec: Why do pfkey_getspi and xfrm_alloc_userspi call xfrm_find_acq_byseq?

Hi David,

First of all, thank you for your answer.

David Miller wrote:
> From: Christophe Gouault <christophe.gouault@...nd.com>
> Date: Thu, 19 Aug 2010 14:55:21 +0200
>
>> The call to xfrm_find_acq_byseq() by the pfkey_getspi() and
>> xfrm_alloc_userspi() functions is quite costly and proves to entail
>> scalability issues when performing thousands of IKE negotiations with
>> racoon (from ipsec-tools distribution) or charon (from strongswan
>> distribution).
>>
>> Removing this call in the kernel drastically accelerates the
>> processing and does not seem to entail functional problems.
>>
>> For now, I don't see the point of this call. I need to understand its
>> purpose, because I'm highly tempted to simply remove it.
> First of all, removing a function because you don't understand
> why it's there is rarely a good idea :-)
Yes, don't worry, I never act that way. I was deliberately a little 
provocative ;-)
> I think the semantics require that we check for existing ACQUIRE
> state entries before we allocate an SPI.
Well, I still don't see in which case this can happen. The only 
situations in which an ACQUIRE state entry is created is when an acquire 
message is raised by the kernel (this creates a temporary outbound 
state) or when a getspi is issued from the userland (this creates a 
temporary state, as far as I know, this is the future inbound state 
negotiated by IKE).

In my humble opinion, issuing a getspi for the output state does not 
make sense since the SPI is chosen by the destination host.
So the possibly existing ACQUIRE state entry would be the result of a 
former getspi with the same value of the seq field. So this call would 
aim at cancelling a former call to getspi, maybe to cope with an 
application that would retry a failed negotiation before the former 
getspi expired?... I'm not really convinced by this explanation.

But there are maybe other uses of the getspi call than assigning a SPI 
for the inbound state of an IKE negotiation...
> The likelyhood of breaking something if you remove the call is very
> high.
Probably. I'm still interested in a concrete example ;-)

Christophe
--
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