From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f175.google.com ([209.85.192.175]:35563 "EHLO mail-pf0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752055AbeCFQh2 (ORCPT ); Tue, 6 Mar 2018 11:37:28 -0500 Received: by mail-pf0-f175.google.com with SMTP id y186so8948949pfb.2 for ; Tue, 06 Mar 2018 08:37:28 -0800 (PST) Message-ID: <1520354245.109662.19.camel@gmail.com> Subject: Re: Flaw in RFC793 (Fwd: New Version Notification for draft-gont-tcpm-tcp-seq-validation-03.txt) From: Eric Dumazet To: Fernando Gont , netdev Cc: Yuchung Cheng , Neal Cardwell Date: Tue, 06 Mar 2018 08:37:25 -0800 In-Reply-To: <1da2d1de-cb93-dc8b-7909-a8628a71a60b@si6networks.com> References: <152029339529.12825.5038413838558267392.idtracker@ietfa.amsl.com> <1da2d1de-cb93-dc8b-7909-a8628a71a60b@si6networks.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: netdev-owner@vger.kernel.org List-ID: 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: > 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 , David Borman > > > > 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 > > >