netdev - Re: TCP: orphans broken by RFC 2525 #2.17

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:	Mon, 27 Sep 2010 07:39:01 +0200
From:	Willy Tarreau <w@....eu>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org
Subject: Re: TCP: orphans broken by RFC 2525 #2.17

On Sun, Sep 26, 2010 at 06:12:02PM -0700, David Miller wrote:
> From: Willy Tarreau <w@....eu>
> Date: Mon, 27 Sep 2010 01:25:30 +0200
> 
> > Agreed. But that's not a reason for killing outgoing data that is
> > being sent when there are some data left in the rcv buffer.
> 
> What alternative notification to the peer do you suggest other than a
> reset, then?  TCP gives us no other.

I know, and I agree to send the reset, but after the data are correctly
transferred. This reset's purpose is only to inform the other side that
the data it sent were destroyed. It is not a requirement to tell it they
were destroyed earlier or later. What matters is that it's informed they
were destroyed.

That's why I think that it is perfectly reasonable to either destroy them
after the ACK or simply notify about their destruction after the ACK.

Instead of having :

        A                                               B

       --->     <SEQ=100><ACK=300>                     --->
       <---     <SEQ=300><ACK=100><DATA=10>            <---
       --->     <SEQ=100><ACK=310>                     --->
       send(100)
       shutdown()
       close()
       --->     <SEQ=100><CTL=RST>                     --->

We would just have :

        A                                               B

       --->     <SEQ=100><ACK=300>                     --->
       <---     <SEQ=300><ACK=100><DATA=10>            <---
       --->     <SEQ=100><ACK=310>                     --->
       send(100)
       shutdown()
       close()
       --->     <SEQ=100><ACK=310><DATA=100><CTL=FIN>  --->
       <---     <SEQ=300><ACK=111>                     <---
       --->     <SEQ=111><CTL=RST>                     --->

Note that the notification is exactly the same as if we wanted
to notify B about the destruction of data that were sent just
after the close, because the RST only carries a SEQ field and
no ACK indicating what it destroyed :

        A                                               B

       --->     <SEQ=100><ACK=300>                     --->
       send(100)
       shutdown()
       --->     <SEQ=100><ACK=310><DATA=100><CTL=FIN>  --->
       <---     <SEQ=300><ACK=111><DATA=10>            <---
       close()
       --->     <SEQ=111><CTL=RST>                     --->

In my opinion, last two examples are perfectly valid, they just mean
"after that, I close and don't want to hear about you again".

> That's the thing, data integrity is full duplex, thus once it has been
> compromised in one direction everything currently in flight must be
> zapped.

I'm well aware of that, and even though that's an annoying method, we
must live with it, it's probably one of the things that contribute TCP
its well known reliability. But I think that RFC 2525 abused the TCP
use based on traces showing a bad behaviour and overlooked all impacts
(nothing there talks about the case of data being sent or in flight at
the moment of the close).

Regards,
Willy

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