netdev - Re: [PATCH ipsec] xfrm: check DST_NOPOLICY as well as DST

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 for Android: free password hash cracker in your pocket

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

Message-ID: <dc657389-aab2-2174-7571-29ebd5972316@6wind.com>
Date:   Thu, 5 Dec 2019 11:51:32 +0100
From:   Nicolas Dichtel <nicolas.dichtel@...nd.com>
To:     Mark Gillott <mgillott@...tta.att-mail.com>, netdev@...r.kernel.org
Cc:     steffen.klassert@...unet.com, herbert@...dor.apana.org.au
Subject: Re: [PATCH ipsec] xfrm: check DST_NOPOLICY as well as DST_NOXFRM

Le 05/12/2019 à 11:05, Mark Gillott a écrit :
> On Thu, 2019-12-05 at 09:52 +0100, Nicolas Dichtel wrote:
>> Le 05/12/2019 à 09:10, Mark Gillott a écrit :
>>> On Wed, 2019-12-04 at 17:57 +0100, Nicolas Dichtel wrote:
>>>> Le 04/12/2019 à 16:17, Mark Gillott a écrit :
>>>>> Before performing a policy bundle lookup, check the
>>>>> DST_NOPOLICY
>>>>> option, as well as DST_NOXFRM. That is, skip further processing
>>>>> if
>>>>> either of the disable_policy or disable_xfrm sysctl attributes
>>>>> are
>>>>> set.
>>>>
>>>> Can you elaborate why this change is needed?
>>>
>>> We have a separate DPDK-based dataplane that is responsible for all
>>> IPsec processing - policy handing/encryption/decryption.
>>> Consequently
>>> we set the net.ipv[4|6].conf.<if>.disable_policy sysctl to 1 for
>>> all
>>> "interesting" interfaces. That is we want the kernel to ignore any
>>> IPsec policies.
>>>
>>> Despite the above & depending on configuration, we found that
>>> originating traffic was ending up deep inside XFRM where it would
>>> get
>>> dropped because of a route lookup problem.
>>
>> And why don't you set disable_xfrm to thoses interfaces also?
>> disable_policy means no xfrm policy lookup on output, disable_xfrm
>> means no xfrm
>> policy check on input.
I inverted them! :/
disable_policy => no xfrm policy check on input
disable_xfrm => no xfrm encryption on output

>>
> 
> True, setting disable_xfrm=1 would solve the issue. Except this is
> output - the test case is a ping from a peer, the corresponding ICMP
> response is discarded by the kernel. Feels like disable_policy is the
> right check (the kernel is doing XFRM output).
If you don't want to perform xfrm encryption on output, you have to set
disable_xfrm. disable_policy is for input path only.

Nicolas