netdev - Re: [devel-ipsec] [PATCH ipsec-next v10 00/16] 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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m2le09ikle.fsf@owl-home.int.chopps.org>
Date: Mon, 02 Sep 2024 20:10:26 -0400
From: Christian Hopps <chopps@...pps.org>
To: Antony Antony <antony@...nome.org>
Cc: Christian Hopps <chopps@...pps.org>, Steffen Klassert
 <steffen.klassert@...unet.com>, netdev@...r.kernel.org, Florian Westphal
 <fw@...len.de>, Sabrina Dubroca <sd@...asysnail.net>, Simon Horman
 <horms@...nel.org>, devel@...ux-ipsec.org
Subject: Re: [devel-ipsec] [PATCH ipsec-next v10 00/16] Add IP-TFS mode to xfrm


Antony Antony via Devel <devel@...ux-ipsec.org> writes:

> Hi Chris,
>
> On Fri, Aug 23, 2024 at 10:20:38PM -0400, Christian Hopps wrote:
>> * Summary of Changes:
>>
>> 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.
>>
>> Patchset Structure:
>> -------------------
>
> I ran few tests. The basic tests passed. I noticed packet loss with ping -f
> especilly on IPv6.
>
> ping6 -f  -n -q -c 50 2001:db8:1:2::23

[ ... ]

> Occessionally, once every, 3-4 tries, I noticed packet loss and kernel
> splat.
>
> $ping6 -f -n -q -c 100 -I  2001:db8:1:2::23
> PING 2001:db8:1:2::23(2001:db8:1:2::23) from 2001:db8:1:2::45 : 56 data bytes
>
> --- 2001:db8:1:2::23 ping statistics ---
> 100 packets transmitted, 38 received, 62% packet loss, time 17843ms
> rtt min/avg/max/mdev = 7.639/8.652/36.772/4.642 ms, pipe 2, ipg/ewma
> 180.229/11.165 ms
>
> Without iptfs, in tunnel mode, I  have never see the kernel splat or packet losss.
>
> Have you tried ping6 -f? and possibly with "dont-frag"?

I will run some IPv6 flood tests with dont-frag, and see if I can replicate this.

> The setup is a simple one, host-to-host tunnel,
> 2001:db8:1:2::23 to 2001:db8:1:2::45 wit policy /128
>
> root@...t:/testing/pluto/ikev2-74-iptfs-02-ipv6$ip x p
> src 2001:db8:1:2::45/128 dst 2001:db8:1:2::23/128
> 	dir out priority 1703937 ptype main
> 	tmpl src 2001:db8:1:2::45 dst 2001:db8:1:2::23
> 		proto esp reqid 16393 mode iptfs
> src 2001:db8:1:2::23/128 dst 2001:db8:1:2::45/128
> 	dir fwd priority 1703937 ptype main
> 	tmpl src 2001:db8:1:2::23 dst 2001:db8:1:2::45
> 		proto esp reqid 16393 mode iptfs
> src 2001:db8:1:2::23/128 dst 2001:db8:1:2::45/128
> 	dir in priority 1703937 ptype main
> 	tmpl src 2001:db8:1:2::23 dst 2001:db8:1:2::45
> 		proto esp reqid 16393 mode iptfs
>
> src 2001:db8:1:2::45 dst 2001:db8:1:2::23
> 	proto esp spi 0x64b502a7 reqid 16393 mode iptfs
> 	flag af-unspec esn
> 	aead rfc4106(gcm(aes)) 0x4bf7846c1418b14213487da785fb4019cfa47396c8c1968fb3a38559e7e39709fa87dfd9 128
> 	lastused 2024-08-29 09:30:00
> 	anti-replay esn context:	 oseq-hi 0x0, oseq 0xa
> 	dir out
> 	iptfs-opts drop-time 0 reorder-window 0 init-delay 0 dont-frag
> src 2001:db8:1:2::23 dst 2001:db8:1:2::45
> 	proto esp spi 0xc5b34ddd reqid 16393 mode iptfs
> 	replay-window 0 flag af-unspec esn
> 	aead rfc4106(gcm(aes)) 0x9029a5ad6da74a19086946836152a6a5d1abbdd81b7a8b997785d23b271413e522da9a11 128
> 	lastused 2024-08-29 09:30:00
> 	anti-replay esn context:
> 	 seq-hi 0x0, seq 0xa
> 	 replay_window 128, bitmap-length 4
> 	 00000000 00000000 00000000 000003ff
> 	dir in
> 	iptfs-opts pkt-size 3 max-queue-size 3
>
> Did I misconfigure "reorder-window 0" even then it should not drop packets?

Is this a custom version? The output is suspicious. The reorder window is for handling the receipt of out-of-order tunnel packets, it's a `dir-in` attribute. The above output shows reorder-window under the `dir out` SA and is missing from the `dir in` SA. FWIW `drop-time` is also a receiving parameter, and `pkt-size` is a sending parameter, these both appear to be in the wrong spot.

Here's example output from the iptfs-dev project iproute2:

    src fc00:0:0:1::3 dst fc00:0:0:1::2
            proto esp spi 0x80000bbb reqid 11 mode iptfs
            replay-window 0 flag af-unspec
            aead rfc4106(gcm(aes)) 0x4a506a794f574265564551694d6537681a2b1a2b 128
            lastused 2024-09-03 01:35:57
            anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
            if_id 0x37
            dir in
            iptfs-opts drop-time 1000000 reorder-window 3
    src fc00:0:0:1::2 dst fc00:0:0:1::3
            proto esp spi 0x80000aaa reqid 10 mode iptfs
            replay-window 0 flag af-unspec
            aead rfc4106(gcm(aes)) 0x4a506a794f574265564551694d6537681a2b1a2b 128
            lastused 2024-09-03 01:35:57
            anti-replay context: seq 0x0, oseq 0x8, bitmap 0x00000000
            if_id 0x37
            dir out
            iptfs-opts init-delay 0 max-queue-size 10485760 pkt-size 0

Thanks,
Chris.


>
> -antony


Download attachment "signature.asc" of type "application/pgp-signature" (858 bytes)