netdev - Re: Add a SOCK_DESTROY operation to close sockets from userspace

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:	Thu, 19 Nov 2015 13:41:04 -0800
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Tom Herbert <tom@...bertland.com>
Cc:	David Miller <davem@...emloft.net>,
	zenczykowski <zenczykowski@...il.com>,
	Lorenzo Colitti <lorenzo@...gle.com>,
	Hannes Frederic Sowa <hannes@...essinduktion.org>,
	Stephen Hemminger <stephen@...workplumber.org>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	Eric Dumazet <edumazet@...gle.com>, Erik Kline <ek@...gle.com>,
	Dmitry Torokhov <dtor@...gle.com>
Subject: Re: Add a SOCK_DESTROY operation to close sockets from userspace

On Thu, 2015-11-19 at 13:29 -0800, Tom Herbert wrote:
> > We (TCP stack) compete with QUIC, based on UDP, which has no issues like
> > that. We need to allow TCP sessions being signaled of a non temporary
> > network disruption.
> >
> 
> Eric, can you provide some detail on this statement?
> 
> I don't understand why QUIC wouldn't have this same issue. Seems like
> it is still connection oriented just like TCP, so if the application
> does a read expecting data from a peer and reverse reachability is
> lost, the the read on the socket hang just like reading a TCP would.
> If this is true, then the TCP solution would might actually be a
> better since it allows a means for a third party (presumably a daemon
> monitoring the network) to signal the application via closing specific
> TCP sockets. I don't see how this could work in UDP especially if
> these are unconnected sockets. What am I missing?

Quic simply sends UDP packets to a destination IP, port 443 (generally)

Say your UDP client binds to 0.0.0.0:<allocated/ephemeral port>

Kernel pick up source address given current working routing, on a per
packet basis.

Their notion of 'flow' is provided by the use of an unique connection
ID, included somewhere in the payload.

The replies from QUIC server will then reach the UDP port, because
server learned the latest source IP known for the client.


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html