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:53:43 -0800
From:	Tom Herbert <tom@...bertland.com>
To:	Eric Dumazet <eric.dumazet@...il.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, Nov 19, 2015 at 1:41 PM, Eric Dumazet <eric.dumazet@...il.com> 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.
>
>
That covers the case where the local address is removed, but the not
the case where the network manager is informed of an error in the path
and wants to signal the application. My understanding was that
SIOCKILLADDR would work for the first case, but this patch was need to
cover the second case.

btw, instead of closing the TCP socket can we just report an error and
wake up the application without affecting the connection? That is this
just becomes an error on the socket. The response by the application
will be the same in any case, porbablly just close the socket and try
to reestablish the connection.

Tom
--
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