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

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-next>] [day] [month] [year] [list]

Message-ID: <1da2d1de-cb93-dc8b-7909-a8628a71a60b@si6networks.com>
Date:   Tue, 6 Mar 2018 04:21:32 -0300
From:   Fernando Gont <fgont@...networks.com>
To:     netdev <netdev@...r.kernel.org>
Subject: Flaw in RFC793 (Fwd: New Version Notification for
 draft-gont-tcpm-tcp-seq-validation-03.txt)

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?

* 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@...f.org
To: Fernando Gont <fgont@...networks.com>, David Borman
<david.borman@...ntum.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-validation-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-validation-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