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]

Date:   Wed, 31 Oct 2018 22:07:14 -0700
From:   Christoph Paasch <cpaasch@...le.com>
To:     Eric Dumazet <eric.dumazet@...il.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 Oct 31, 2018, at 10:04 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> 
> 
> 
>> 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()

Oh, I didn’t knew about this socket option. Thanks :-)


Christoph

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