Re: Flaw in RFC793 (Fwd: New Version Notification for draft-gont-tcpm-tcp-seq-validation-03.txt)

[Eric Dumazet <eric.dumazet@gmail.com>]

On Tue, 2018-03-06 at 04:21 -0300, Fernando Gont wrote:
> Folks,
> 
> Dave Borman  and me are trying to get this flaw fixed in the TCP spec
> --
> this is of particular interest since the IETF finally agreed to
> revise
> the old spec. The working copy of our document is:
> <https://www.si6networks.com/publications/drafts/draft-gont-tcpm-tcp-
> seq-validation-04.txt>
> 
> I'm wondering if any Linux TCP expert could help with this:
> 
> * Would you mind taking a look at our doc, and check if our
> description
> of the Linux behavior is correct?

Hi Fernando

I have opened Google Bug # 74230088 and copied your request.

We will take a look at this and will come back to you.

Thanks !

> 
> * If you do something different or better, we'd also like to know.
> 
> Thanks!
> 
> Cheers,
> Fernando
> 
> 
> 
> 
> -------- Forwarded Message --------
> Subject: New Version Notification for
> draft-gont-tcpm-tcp-seq-validation-03.txt
> Date: Mon, 05 Mar 2018 15:43:15 -0800
> From: internet-drafts@ietf.org
> To: Fernando Gont <fgont@si6networks.com>, David Borman
> <david.borman@quantum.com>
> 
> 
> A new version of I-D, draft-gont-tcpm-tcp-seq-validation-03.txt
> has been successfully submitted by Fernando Gont and posted to the
> IETF repository.
> 
> Name:		draft-gont-tcpm-tcp-seq-validation
> Revision:	03
> Title:		On the Validation of TCP Sequence Numbers
> Document date:	2018-03-05
> Group:		Individual Submission
> Pages:		16
> URL:
> https://www.ietf.org/internet-drafts/draft-gont-tcpm-tcp-seq-validati
> on-03.txt
> Status:
> https://datatracker.ietf.org/doc/draft-gont-tcpm-tcp-seq-validation/
> Htmlized:
> https://tools.ietf.org/html/draft-gont-tcpm-tcp-seq-validation-03
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-gont-tcpm-tcp-seq-validat
> ion-03
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-gont-tcpm-tcp-seq-validation-
> 03
> 
> Abstract:
>    When TCP receives packets that lie outside of the receive window,
> the
>    corresponding packets are dropped and either an ACK, RST or no
>    response is generated due to the out-of-window packet, with no
>    further processing of the packet.  Most of the time, this works
> just
>    fine and TCP remains stable, especially when a TCP connection has
>    unidirectional data flow.  However, there are three scenarios in
>    which packets that are outside of the receive window should still
>    have their ACK field processed, or else a packet war will take
> place.
>    The aforementioned issues have affected a number of popular TCP
>    implementations, typically leading to connection failures, system
>    crashes, or other undesirable behaviors.  This document describes
> the
>    three scenarios in which the aforementioned issues might arise,
> and
>    formally updates RFC 793 such that these potential problems are
>    mitigated.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> 
>