netdev - Re: [devel-ipsec] [RFC ipsec-next v2 0/8] Add IP-TFS mode to xfrm

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]

Date: Tue, 21 Nov 2023 20:13:12 +0100
From: Antony Antony <antony@...nome.org>
To: Steffen Klassert <steffen.klassert@...unet.com>
Cc: Christian Hopps <chopps@...pps.org>, devel@...ux-ipsec.org,
	netdev@...r.kernel.org, Christian Hopps <chopps@...n.net>
Subject: Re: [devel-ipsec] [RFC ipsec-next v2 0/8] Add IP-TFS mode to xfrm

On Mon, Nov 13, 2023 at 08:15:47AM +0100, Steffen Klassert via Devel wrote:
> On Sun, Nov 12, 2023 at 10:52:11PM -0500, Christian Hopps wrote:
> > From: Christian Hopps <chopps@...n.net>
> > 
> > This patchset adds a new xfrm mode implementing on-demand IP-TFS. IP-TFS
> > (AggFrag encapsulation) has been standardized in RFC9347.
> > 
> > Link: https://www.rfc-editor.org/rfc/rfc9347.txt
> > 
> > This feature supports demand driven (i.e., non-constant send rate) IP-TFS to
> > take advantage of the AGGFRAG ESP payload encapsulation. This payload type
> > supports aggregation and fragmentation of the inner IP packet stream which in
> > turn yields higher small-packet bandwidth as well as reducing MTU/PMTU issues.
> > Congestion control is unimplementated as the send rate is demand driven rather
> > than constant.
> > 
> > In order to allow loading this fucntionality as a module a set of callbacks
> > xfrm_mode_cbs has been added to xfrm as well.
> 
> I did a multiple days peer review with Chris on this pachset. So my
> concerns are already addressed.
> 
> Further reviews are welcome! This is a bigger change and it would
> be nice if more people could look at it.

I'd like to pose a basic question to understand the new IP-TFS config 
options for an SA.

When configuring IP-TFS parameters on an SA, are all parameters actively 
used by that SA? or does their usage vary based on the direction of the 
traffic?
Currently, each IP-TFS SA includes both init-delay and drop-time parameters. 
I would like to understand whether both parameters are necessary for every SA.

ip xfrm state

src 2001:db8:1:2::45 dst 2001:db8:1:2::23
proto esp spi 0x32af1f6d reqid 16389 mode iptfs
replay-window 0 flag af-unspec esn
aead rfc4106(gcm(aes)) 0x0... 128
anti-replay esn context:
seq-hi 0x0, seq 0x0, oseq-hi 0x0, oseq 0x0
replay_window 128, bitmap-length 4
00000000 00000000 00000000 00000000
iptfs-opts pkt-size 0 max-queue-size 1048576 drop-time 1000000 reorder-window 3 init-delay 0

Chris, would like to you share which of iptfs-opts are for input and which 
are for output?

My current understanding suggests that, depending on the traffic direction, 
onlysome of these parameters might be in active use for each SA. If this is 
indeed the case, I propose we discuss the possibility of refining our 
configuration approach. Could we consider making these parameters mutually 
exclusive and dependent on the traffic direction? Furthermore, given that 
the xfrm community has previously discussed the idea of adding direction to 
the SA — a concept also used in hardware offload scenarios — why not explore 
adding direction to the SA?

We currently have DIR with offload.

ip xfrm state { add | update } ... offload [ crypto|packet ] dev DEV dir DIR

Implementing direction could imply that an IP-TFS SA would require only fewer parameters
– init-delay or drop-time, depending on the specified direction. This would 
make ip x s output simple and comprehensible, thereby reducing potential 
confusion. Also avoid confusing when creating state say input, why add 
output parameters to an input SA?"