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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 19 Nov 2015 22:53:02 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Eric Dumazet <eric.dumazet@...il.com>,
	Tom Herbert <tom@...bertland.com>
Cc:	David Miller <davem@...emloft.net>,
	zenczykowski <zenczykowski@...il.com>,
	Lorenzo Colitti <lorenzo@...gle.com>,
	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, Nov 19, 2015, at 22:41, Eric Dumazet wrote:
> 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.

You don't steer QUIC source addresses at all? I think most networking
failures are of transient nature thus the kernel routing subsystem is
not aware of link quality and packets get lost anyway e.g. in the air?
Thus binding on multiple interfaces and keepalives seem still
appropriate, no?

Bye,
Hannes
--
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