netdev - Re: [PATCH RFC net-next 1/1] tcp: close socket without reset on incoming data

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: <20180519.225204.1995440148754220332.davem@davemloft.net>
Date:   Sat, 19 May 2018 22:52:04 -0400 (EDT)
From:   David Miller <davem@...emloft.net>
To:     dbanerje@...mai.com
Cc:     netdev@...r.kernel.org, kuznet@....inr.ac.ru,
        yoshfuji@...ux-ipv6.org
Subject: Re: [PATCH RFC net-next 1/1] tcp: close socket without reset on
 incoming data

From: "Banerjee, Debabrata" <dbanerje@...mai.com>
Date: Sat, 19 May 2018 22:57:48 +0000

> It does the same thing the application would do, but with much less
> overhead. The application called close() because it no longer cares
> about new data, but it still expected send() prior to close() to
> actually send.

It's not the same.

If you just sink the data in the protocol stack, the sender has no
way whatsoever to know that the application did not see the data.

The sender must have a way to know that the application at the other
end received the data, whether they used it or not.  And what breaks
the ambiguity is that reset.

This is critcially important.

> Well if the intersection with the definition of the close() spooks
> you something similar could be implemented as a
> setsockopt(TCP_SINK_DATA) around shutdown(), to instruct the socket
> to immediately dump data, but with higher resource usage. However as
> above, I don't currently believe this patch violates the protocol.

The SHOULD you quoted in RFC 1122 is explicitly listed in a another
RFC as an explicitly recommended behavior.  I know, because that text
is what led me to implement the current behavior.

Please see RFC 2525, section 2.16: Failure to send a RST after Half
Duplex Close.