netdev - Re: [PATCH ipsec-next v4] xfrm: Add Direction to the SA in or out

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]

Message-ID: <b3e0c716-fc74-4cb4-9778-c92749cd4b4b@6wind.com>
Date: Fri, 22 Mar 2024 09:20:05 +0100
From: Nicolas Dichtel <nicolas.dichtel@...nd.com>
To: Antony Antony <antony@...nome.org>
Cc: antony.antony@...unet.com, Steffen Klassert
 <steffen.klassert@...unet.com>, Herbert Xu <herbert@...dor.apana.org.au>,
 devel@...ux-ipsec.org, netdev@...r.kernel.org
Subject: Re: [PATCH ipsec-next v4] xfrm: Add Direction to the SA in or out

Le 17/03/2024 à 23:34, Antony Antony a écrit :
> Hi Nicolas,
> 
> On Thu, Mar 14, 2024 at 03:28:57PM +0100, Nicolas Dichtel via Devel wrote:
>> Le 13/03/2024 à 22:04, Antony Antony via Devel a écrit :
>>> This patch introduces the 'dir' attribute, 'in' or 'out', to the
>>> xfrm_state, SA, enhancing usability by delineating the scope of values
>>> based on direction. An input SA will now exclusively encompass values
>>> pertinent to input, effectively segregating them from output-related
>>> values. This change aims to streamline the configuration process and
>>> improve the overall clarity of SA attributes.
>>
>> If I correctly understand the commit, the direction is ignored if there is no
>> offload configured, ie an output SA could be used in input. Am I right?
>>
>> If yes:
>>  1/ it would be nice to state it explicitly in the commit log.
>>  2/ it is confusing for users not using offload.
> 
> 
> I see why you're asking for clarification. This patch is designed for 
> broader use in the future beyond its current application, specifically for 
> the HW offload use case. Notably, the upcoming IP-TFS patch, among others, 
> will utilize the 'direction' (dir) attribute. The absence of a 'direction' 
> for an SA can lead to a confusing user experience. While symmetry is nice,
Thanks for the explanation.

> configuring values that are not utilized and are direction-specific can be 
> very confusing. For instance, many users configure a replay window 
> (specifically without ESN) on an outbound SA, even though the replay window 
> is only applicable to an inbound SA. With ESN, you can just leave it at 1.  
> SAs have historically lacked a direction attribute. It has been brought up 
> many times but never implemented.
Maybe it would be worse to reject this new XFRMA_SA_DIR attribute when it is not
used (for example if there is no offload configured). It will make the API clearer.


Regards,
Nicolas

> 
> Following the email I shared earlier 
> (https://lore.kernel.org/netdev/ZV0BSBzNh3UIqueZ@Antony2201.local/), I 
> discussed this proposal with more users/developers, and there is interest in 
> adding a direction to SA for future values. Maybe I will addd one line in 
> the message this is in preperartion for upcoming IP-TFS.
> 
> -antony