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
| ||
|
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
Powered by blists - more mailing lists