[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZhY_O_6w1Yz_R6aS@hog>
Date: Wed, 10 Apr 2024 09:26:51 +0200
From: Sabrina Dubroca <sd@...asysnail.net>
To: Nicolas Dichtel <nicolas.dichtel@...nd.com>
Cc: Antony Antony <antony@...nome.org>,
Antony Antony <antony.antony@...unet.com>,
Herbert Xu <herbert@...dor.apana.org.au>, netdev@...r.kernel.org,
devel@...ux-ipsec.org, Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
"David S. Miller" <davem@...emloft.net>
Subject: Re: [devel-ipsec] [PATCH ipsec-next v6] xfrm: Add Direction to the
SA in or out
2024-04-10, 08:27:49 +0200, Nicolas Dichtel wrote:
> Le 08/04/2024 à 15:02, Sabrina Dubroca a écrit :
> [snip]
> > Nicolas, since you were objecting to the informational nature of the
> > attribute in v5: would you still object to the new attribute (and not
> > just limited to offload cases) if it properly restricted attributes
> > that don't match the direction?
> It's a good step, sure. Does this prevent an 'input' SA to be used in the output
> path? This is the case I'm objecting.
Not in the latest version, what we were discussing here was only
checking attributes that don't match the direction of the SA.
Adding checks on the input and output patch to only look up and use
SAs with the correct direction (or no direction set) should be doable,
and probably has a negligible impact on performance. If we do this, we
should maybe add a counter for direction mismatch
(Xfrm{In,Out}StateDirMismatch?) to help admins.
I agree that it would make more sense.
--
Sabrina
Powered by blists - more mailing lists