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

Message-id: <20181101221118.GG1685@MacBook-Pro-19.local>
Date:   Thu, 01 Nov 2018 15:11:18 -0700
From:   Christoph Paasch <cpaasch@...le.com>
To:     Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc:     Network Development <netdev@...r.kernel.org>, ianswett@...gle.com,
        lhedstrom@...le.com, jri.ietf@...il.com,
        Eric Dumazet <eric.dumazet@...il.com>
Subject: Re: [RFC 0/2] Delayed binding of UDP sockets for Quic per-connection
 sockets

On 01/11/18 - 17:51:39, Willem de Bruijn wrote:
> On Wed, Oct 31, 2018 at 7:30 PM Christoph Paasch <cpaasch@...le.com> wrote:
> >
> > Implementations of Quic might want to create a separate socket for each
> > Quic-connection by creating a connected UDP-socket.
> >
> > To achieve that on the server-side, a "master-socket" needs to wait for
> > incoming new connections and then creates a new socket that will be a
> > connected UDP-socket. To create that latter one, the server needs to
> > first bind() and then connect(). However, after the bind() the server
> > might already receive traffic on that new socket that is unrelated to the
> > Quic-connection at hand.
> 
> This can also be achieved with SO_REUSEPORT_BPF and a filter
> that only selects the listener socket(s) in the group. The connect
> call should call udp_lib_rehash and take the connected socket out
> of the reuseport listener group. Though admittedly that is more
> elaborate than setting a boolean socket option.

Yeah, that indeed would be quite a bit more elaborate ;-)

A simple socket-option is much easier.


Cheers,
Christoph

> 
> > The ideas for the implementation came up after a discussion with Ian
> > and Jana re: their implementation of a QUIC server.
> 
> That might have preceded SO_TXTIME? AFAIK traffic shaping was the
> only real reason to prefer connected sockets.