linux-kernel - DTLS and UDP servers

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

Message-ID: <b2c00870-c2bf-bd62-0476-4140c3a5a4e6@nc.rr.com>
Date:   Fri, 11 Jan 2019 09:19:44 -0500
From:   bnv@...rr.com
To:     linux-kernel@...r.kernel.org
Subject: DTLS and UDP servers

[Due to list volume, this address is not subscribed.  Please CC with any 
replies]

Standard practice when using DTLS on a UDP server is to bind and connect 
a new socket upon receipt of a valid ClientHello on the listener 
socket.  SO_REUSEPORT is required to ensure new sockets can bind to the 
same port as the listener socket.

This works because the listener socket will see nothing but ClientHello 
messages, and clients will block on a ServerHello message which is sent 
after the new connected socket is created.

However, there is a window of opportunity between the bind and connect 
calls, where the new socket temporarily takes over the port from the 
listener socket.  Ingress ClientHello messages will get delivered to the 
queue of the new socket within this window. The result is that 
authentication fails for the new client, and isn't begun for the other 
clients whose ClientHello messages were diverted.

Arguably, this is UDP so clients should not expect reliability and 
simply try again.However, this issue is addressable if a mechanism 
existed to bind and connect simultaneously.  Is it feasible?

Note: This would benefit the unsecured UDP server case as well, where it 
is desired to move a new "session" off the listener descriptor to its 
own for better scaling.  SO_REUSEPORT addresses this to a degree, but is 
modeled on multiple server processes rather than multiple threads within 
a single server process.

Regards, BH