netdev - Re: [RFC 0/2] Delayed binding of UDP sockets for Quic per-connection sockets

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: <74393778-62e8-76f5-3bfc-ae280b407278@gmail.com>
Date:   Wed, 31 Oct 2018 22:04:19 -0700
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     Christoph Paasch <cpaasch@...le.com>
Cc:     netdev@...r.kernel.org, Ian Swett <ianswett@...gle.com>,
        Leif Hedstrom <lhedstrom@...le.com>,
        Jana Iyengar <jri.ietf@...il.com>
Subject: Re: [RFC 0/2] Delayed binding of UDP sockets for Quic per-connection
 sockets



On 10/31/2018 08:50 PM, Christoph Paasch wrote:

> What we had here is that we wanted to let a server initiate more than 64K
> connections *while* binding also to a source-IP.
> With TCP the bind() would then pick a source-port and we ended up hitting the
> 64K limit. If we could do an atomic "bind + connect", source-port selection
> could ensure that the 4-tuple is unique.
> 
> Or has something changed in recent times that allows to use the 4-tuple
> matching when doing this with TCP?


Well, yes, although it is not really recent (this came with linux-4.2)

You can now bind to an address only, and let the sport being automatically chosen at connect()

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=90c337da1524863838658078ec34241f45d8394d