[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6505b7d2-7792-429d-42a6-d41711de0dc1@gmail.com>
Date: Thu, 23 Sep 2021 10:38:49 +0300
From: Leonard Crestez <cdleonard@...il.com>
To: Francesco Ruggeri <fruggeri@...sta.com>
Cc: Dmitry Safonov <0x7f454c46@...il.com>,
David Ahern <dsahern@...nel.org>,
Shuah Khan <shuah@...nel.org>,
Eric Dumazet <edumazet@...gle.com>,
"David S. Miller" <davem@...emloft.net>,
Herbert Xu <herbert@...dor.apana.org.au>,
Kuniyuki Iwashima <kuniyu@...zon.co.jp>,
Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
Jakub Kicinski <kuba@...nel.org>,
Yuchung Cheng <ycheng@...gle.com>,
Mat Martineau <mathew.j.martineau@...ux.intel.com>,
Christoph Paasch <cpaasch@...le.com>,
Ivan Delalande <colona@...sta.com>,
Priyaranjan Jha <priyarjha@...gle.com>,
Menglong Dong <dong.menglong@....com.cn>,
netdev <netdev@...r.kernel.org>, linux-crypto@...r.kernel.org,
linux-kselftest@...r.kernel.org,
open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 00/19] tcp: Initial support for RFC5925 auth option
On 9/22/21 11:23 PM, Francesco Ruggeri wrote:
> On Tue, Sep 21, 2021 at 9:15 AM Leonard Crestez <cdleonard@...il.com> wrote:
>> * Sequence Number Extension not implemented so connections will flap
>> every ~4G of traffic.
>
> Could you expand on this?
> What exactly do you mean by flap? Will the connection be terminated?
> I assume that depending on the initial sequence numbers the first flaps
> may occur well before 4G.
> Do you use a SNE of 0 in the hash computation, or do you just not include
> the SNE in it?
SNE is hardcoded to zero, with the logical consequence of incorrect
signatures on sequence number wrapping. The SNE has to be included
because otherwise all signatures would be invalid.
You are correct that this can break much sooner than 4G of traffic, but
still in the GB range on average. I didn't test the exact behavior (not
clear how) but if signatures don't validate the connection will likely
timeout.
My plan is to use TCP_REPAIR to control sequence numbers and test this
reliably in an isolated environment (not interop with a cisco VM or
similar). I want to implement TCP_REPAIR support for TCP-AO anyway.
It was skipped because the patch series is already quite large.
--
Regards,
Leonard
Powered by blists - more mailing lists