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  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]
Date:   Thu, 23 Sep 2021 10:38:49 +0300
From:   Leonard Crestez <>
To:     Francesco Ruggeri <>
Cc:     Dmitry Safonov <>,
        David Ahern <>,
        Shuah Khan <>,
        Eric Dumazet <>,
        "David S. Miller" <>,
        Herbert Xu <>,
        Kuniyuki Iwashima <>,
        Hideaki YOSHIFUJI <>,
        Jakub Kicinski <>,
        Yuchung Cheng <>,
        Mat Martineau <>,
        Christoph Paasch <>,
        Ivan Delalande <>,
        Priyaranjan Jha <>,
        Menglong Dong <>,
        netdev <>,,,
        open list <>
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 <> 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 

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.


Powered by blists - more mailing lists