netdev - Re: TCP_DEFER_ACCEPT wakes up without data

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] [day] [month] [year] [list]

Date:   Tue, 9 Jun 2020 09:45:09 -0700
From:   Christoph Paasch <christoph.paasch@...il.com>
To:     Florian Westphal <fw@...len.de>
Cc:     Eric Dumazet <eric.dumazet@...il.com>,
        Julian Anastasov <ja@....bg>,
        Wayne Badger <badger@...oo-inc.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Leif Hedstrom <lhedstrom@...le.com>
Subject: Re: TCP_DEFER_ACCEPT wakes up without data

Hello,

On Sun, Jun 7, 2020 at 3:00 AM Florian Westphal <fw@...len.de> wrote:
>
> Eric Dumazet <eric.dumazet@...il.com> wrote:
> > > Sure! TCP_DEFER_ACCEPT delays the creation of the socket until data
> > > has been sent by the client *or* the specified time has expired upon
> > > which a last SYN/ACK is sent and if the client replies with an ACK the
> > > socket will be created and presented to the accept()-call. In the
> > > latter case it means that the app gets a socket that does not have any
> > > data to be read - which goes against the intention of TCP_DEFER_ACCEPT
> > > (man-page says: "Allow a listener to be awakened only when data
> > > arrives on the socket.").
> > >
> > > In the original thread the proposal was to kill the connection with a
> > > TCP-RST when the specified timeout expired (after the final SYN/ACK).
> > >
> > > Thus, my question in my first email whether there is a specific reason
> > > to not do this.
> > >
> > > API-breakage does not seem to me to be a concern here. Apps that are
> > > setting DEFER_ACCEPT probably would not expect to get a socket that
> > > does not have data to read.
> >
> > Thanks for the summary ;)
> >
> > I disagree.
> >
> > A server might have two modes :
> >
> > 1) A fast path, expecting data from user in a small amount of time, from peers not too far away.
> >
> > 2) A slow path, for clients far away. Server can implement strategies to control number of sockets
> > that have been accepted() but not yet active (no data yet received).

to add to that: There are indeed scenarios where TCP-SYN/... without
payload go through fine but as soon as the packet-size increases
WiFi/Cell has problems because of smaller grants given by the
AP/tower. But even those connections should be able to get the data
through within a "reasonable" timeframe. Anything beyond that
timeframe will anyways have such a bad user-experience that it is
pointless to continue.

So, a use-case here would be where the user is in such a slow network
and a TCP-split proxy is deployed (such proxies are very common in
cellular networks). That proxy will be ACKing the server's SYN/ACK
retransmission at the end of the defer-accept period, while the client
is still trying very hard to get the data through to the proxy (or
even, the client might have gone totally out-of-service).

For those kinds of scenarios it would make sense to have a different
DEFER_ACCEPT-behavior (maybe with a separate socket-option as Florian
suggested).

Christoph

>
> So we can't change DEFER_ACCEPT behaviour.
> Any objections to adding TCP_DEFER_ACCEPT2 with the behaviour outlined
> by Christoph?