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

From: Fernando Gont <[email-masked]>
Date: Tue, 6 Mar 2018 15:38:08 -0300

Folks,

There is bug in the TCP Sequence Number validation algorithm from
RFC793. Most major implementations have addressed it, but the bug still
remains in our specs.

We got a bit of extra energy to try to get this one fixed. Our I-D
(draft-gont-tcpm-tcp-seq-validation) is available at the usual repository.

We have incorporated some minor edits done after the cut-off here:
<https://www.si6networks.com/publications/drafts/draft-gont-tcpm-tcp-seq-validation-04.txt>
 -- but modulo minor grammar corrections, version -03 is the same.

We'd like to receive feedback from the wg regarding the "problem
statement" (so to speak), and the proposed/described fixes.

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: [email-masked]
To: Fernando Gont <[email-masked]>, David Borman
<[email-masked]>

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

---

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 6 Mar 2018 19:05:27 +0000

Hi,

isn't this something that could simply go into 793bis, after there is consensus that something needs to be fixed?

Lars

On 2018-3-6, at 19:38, Fernando Gont <[email-masked]> wrote:
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Fernando Gont <[email-masked]>
Date: Tue, 6 Mar 2018 17:18:28 -0300

Hello, Lars,

> isn't this something that could simply go into 793bis, after there is consensus that something needs to be fixed?

(me thinking out loud) Dunno. My understanding was the rfc793bis was
only taking documents that had already formally updated rfc793.

A "feature" of that is that the rationale for the changes incoporated in
rfc793bis are documented in the updating documents, and rfc793bis
doesn't need to delve too much into such rationales, or explain the
changes -- just incorporate them.

What's in draft-gont-tcpm-tcp-seq-validation is certainly necessary to
illustrate where RFC793 fails. But I doubt you'd like the time-sequence
diagrams of all these corner-cases in RFC793bis. But you'd also like to
have something that you can point to explain these changes (even more,
if different popular implementations decided to address this in a
different way).

One possible way would be to add all this to an Appendix in RFC793. But
I guess that would warrant to do the same for other stuff (e.g., update
for the TCP URG mechanism).

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 6 Mar 2018 13:53:14 -0800

Hello,

On Tue, Mar 6, 2018 at 11:05 AM, Eggert, Lars <[email-masked]> wrote:

> Hi,
>
> isn't this something that could simply go into 793bis, after there is
> consensus that something needs to be fixed?
>

I think the observation of the bug can go into 793bis (which has been done
in the current version).
However, I think the solution for it needs to be reviewed and discussed.

It will be really great if some implementers speak up if the solution in
the draft looks good or they take different approach to address the issue.
--
Yoshi

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 6 Mar 2018 22:17:57 -0500

On 3/6/2018 4:53 PM, Yoshifumi Nishida wrote:
> Hello,
>
> On Tue, Mar 6, 2018 at 11:05 AM, Eggert, Lars <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     isn't this something that could simply go into 793bis, after there
>     is consensus that something needs to be fixed?
>
>
> I think the observation of the bug can go into 793bis (which has been 
> done in the current version).

FYI - there is a paragraph on the issue in Appendix A of the current 
revision, which was added after discussion around the Chicago meeting 
(IIRC).  I think if no solution is blessed by the working group, that 
this warning about a "known bug" would be the best we can do in 793bis, 
but is certainly far less desirable than having an actual solution in 
the body of the document.  To work that solution out, discuss the 
options, etc., I'm in favor of advancing it via the draft Fernando and 
David have put together.  They already briefly discuss the Linux 
approach, for instance.

> It will be really great if some implementers speak up if the solution 
> in the draft looks good or they take different approach to address the 
> issue.

Agreed; feedback is useful, though I do think this bug is evident and we 
at least can see what has evidently been done about it already in open 
source stacks, as examples.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 8 Mar 2018 02:59:19 -0300

> the draft looks good or they take different approach to address the issue.

Dave Borman (co-author) is an implementer. I have asked other
implementers to provide input.

Thanks,

---

From: "Scharf, Michael (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Sun, 11 Mar 2018 21:19:01 +0000

Having a small document that precisely describes the issue and solutions seems useful to me. I think it is easier to discuss and review a dedicated document than adding changes only in 793bis.

So, in my personal view, even an (informational) document that just describes the problem and known solutions would be better than having to sort this out in 793bis without a good reference. If the TCPM community agrees to a wording in a PS, that would even be a cleaner solution.

In any case, it would really help if TCP implementers could have a look at this short document.

Michael

From: tcpm [mailto:[email-masked]] On Behalf Of Wesley Eddy
Sent: Wednesday, March 07, 2018 4:18 AM
To: [email-masked]
Subject: Re: [tcpm] Flaw in RFC793 (Fwd: New Version Notification for draft-gont-tcpm-tcp-seq-validation-03.txt)

Hello,

On Tue, Mar 6, 2018 at 11:05 AM, Eggert, Lars <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

I think the observation of the bug can go into 793bis (which has been done in the current version).
However, I think the solution for it needs to be reviewed and discussed.

FYI - there is a paragraph on the issue in Appendix A of the current revision, which was added after discussion around the Chicago meeting (IIRC).  I think if no solution is blessed by the working group, that this warning about a "known bug" would be the best we can do in 793bis, but is certainly far less desirable than having an actual solution in the body of the document.  To work that solution out, discuss the options, etc., I'm in favor of advancing it via the draft Fernando and David have put together.  They already briefly discuss the Linux approach, for instance.

It will be really great if some implementers speak up if the solution in the draft looks good or they take different approach to address the issue.

Agreed; feedback is useful, though I do think this bug is evident and we at least can see what has evidently been done about it already in open source stacks, as examples.