* Flaw in RFC793 (Fwd: New Version Notification for draft-gont-tcpm-tcp-seq-validation-03.txt)
[not found] <152029339529.12825.5038413838558267392.idtracker@ietfa.amsl.com>
@ 2018-03-06 7:21 ` Fernando Gont
2018-03-06 16:37 ` Eric Dumazet
0 siblings, 1 reply; 3+ messages in thread
From: Fernando Gont @ 2018-03-06 7:21 UTC (permalink / raw)
To: netdev
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@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-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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Flaw in RFC793 (Fwd: New Version Notification for draft-gont-tcpm-tcp-seq-validation-03.txt)
2018-03-06 7:21 ` Flaw in RFC793 (Fwd: New Version Notification for draft-gont-tcpm-tcp-seq-validation-03.txt) Fernando Gont
@ 2018-03-06 16:37 ` Eric Dumazet
2018-03-06 16:41 ` Fernando Gont
0 siblings, 1 reply; 3+ messages in thread
From: Eric Dumazet @ 2018-03-06 16:37 UTC (permalink / raw)
To: Fernando Gont, netdev; +Cc: Yuchung Cheng, Neal Cardwell
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
>
>
>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Flaw in RFC793 (Fwd: New Version Notification for draft-gont-tcpm-tcp-seq-validation-03.txt)
2018-03-06 16:37 ` Eric Dumazet
@ 2018-03-06 16:41 ` Fernando Gont
0 siblings, 0 replies; 3+ messages in thread
From: Fernando Gont @ 2018-03-06 16:41 UTC (permalink / raw)
To: Eric Dumazet, netdev; +Cc: Yuchung Cheng, Neal Cardwell
On 03/06/2018 01:37 PM, Eric Dumazet wrote:
> 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.
Thank you so much!
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2018-03-06 16:42 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <152029339529.12825.5038413838558267392.idtracker@ietfa.amsl.com>
2018-03-06 7:21 ` Flaw in RFC793 (Fwd: New Version Notification for draft-gont-tcpm-tcp-seq-validation-03.txt) Fernando Gont
2018-03-06 16:37 ` Eric Dumazet
2018-03-06 16:41 ` Fernando Gont
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox