netdev - Re: [net-next] tcp: add TCP_INFO status for failed client TFO

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: <0841fe66-15a7-418f-4b57-4af6e2d45922@akamai.com>
Date:   Mon, 21 Oct 2019 17:10:43 -0400
From:   Jason Baron <jbaron@...mai.com>
To:     Eric Dumazet <edumazet@...gle.com>,
        Christoph Paasch <cpaasch@...le.com>
Cc:     Yuchung Cheng <ycheng@...gle.com>,
        Neal Cardwell <ncardwell@...gle.com>,
        David Miller <davem@...emloft.net>,
        Netdev <netdev@...r.kernel.org>
Subject: Re: [net-next] tcp: add TCP_INFO status for failed client TFO

On 10/21/19 4:36 PM, Eric Dumazet wrote:
> On Mon, Oct 21, 2019 at 12:53 PM Christoph Paasch <cpaasch@...le.com> wrote:
>>
> 
>> Actually, longterm I hope we would be able to get rid of the
>> blackhole-detection and fallback heuristics. In a far distant future where
>> these middleboxes have been weeded out ;-)
>>
>> So, do we really want to eternalize this as part of the API in tcp_info ?
>>
> 
> A getsockopt() option won't be available for netlink diag (ss command).
> 
> So it all depends on plans to use this FASTOPEN information ?
> 

The original proposal I had 4 states of interest:

First, we are interested in knowing when a socket has TFO set but
actually requires a retransmit of a non-TFO syn to become established.
In this case, we'd be better off not using TFO.

A second case is when the server immediately rejects the DATA and just
acks the syn (but not the data). Again in that case, we don't want to be
sending syn+data.

The third case was whether or not we sent a cookie. Perhaps, the server
doesn't have TFO enabled in which case, it really doesn't make make
sense to enable TFO in the first place. Or if one also controls the
server its helpful in understanding if the server is mis-configured. So
that was the motivation I had for the original four states that I
proposed (final state was a catch-all state).

Yuchung suggested dividing the 3rd case into 2 for - no cookie sent
because of blackhole or no cookie sent because its not in cache. And
then dropping the second state because we already have the
TCPI_OPT_SYN_DATA bit. However, the TCPI_OPT_SYN_DATA may not be set
because we may fallback in tcp_send_syn_data() due to send failure. So
I'm inclined to say that the second state is valuable. And since
blackhole is already a global thing via MIB, I didn't see a strong need
for it. But it sounded like Yuchung had an interest in it, and I'd
obviously like a set of states that is generally useful.

Thanks,

-Jason