Subject: Re: [tcpm] New I-D "On the Validation of TCP Sequence Numbers" (Fwd: New Version Notification for draft-gont-tcpm-tcp-seq-validation-00.txt)

From: Yoshifumi Nishida <[email-masked]>
Date: Fri, 1 Mar 2013 00:28:35 -0800

Hello, I think this is interesting, but I'm wondering why we haven't
realized this for long time and how most implementations deal with
simultaneous open properly.

BTW, I'm also wondering why the Line 8 and 9 in 3.1 have SYN flags.
Aren't they just ACKs?

Thanks,
--
Yoshifumi

On Sat, Feb 16, 2013 at 3:45 PM, Fernando Gont <[email-masked]> wrote:
> Folks,
>
> We have just published a new IETF I-D entitled "On the Validation of TCP
> Sequence Numbers". The I-D is available at:
> <http://www.ietf.org/internet-drafts/draft-gont-tcpm-tcp-seq-validation-00.txt>.
>
> The abstract of the I-D is:
>
> ---- cut here ----
>    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.
> ---- cut here ----
>
> It discusses a problem that has affected a number of popular TCP
> implementations, and aims to formally update RFC 793 to mitigate these
> issues.
>
> Any comments will be welcome.
>
> Thanks!
>
> Best regards,
> Fernando
>
>
>
>
> -------- Original Message --------
> From: [email-masked]
> To: [email-masked]
> Cc: [email-masked]
> Subject: New Version Notification for
> draft-gont-tcpm-tcp-seq-validation-00.txt
> Message-ID: <[email-masked]>
> Date: Sat, 16 Feb 2013 15:02:18 -0800
>
>
> A new version of I-D, draft-gont-tcpm-tcp-seq-validation-00.txt
> has been successfully submitted by Fernando Gont and posted to the
> IETF repository.
>
> Filename:        draft-gont-tcpm-tcp-seq-validation
> Revision:        00
> Title:           On the Validation of TCP Sequence Numbers
> Creation date:   2013-02-16
> Group:           Individual Submission
> Number of pages: 15
> URL:
> http://www.ietf.org/internet-drafts/draft-gont-tcpm-tcp-seq-validation-00.txt
> Status:
> http://datatracker.ietf.org/doc/draft-gont-tcpm-tcp-seq-validation
> Htmlized:
> http://tools.ietf.org/html/draft-gont-tcpm-tcp-seq-validation-00
>
>
> 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.
>
>
>
>
>
> The IETF Secretariat
>
>
>
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Fri, 1 Mar 2013 09:42:13 +0100

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Yoshifumi Nishida
> Sent: Friday, March 01, 2013 9:29 AM
> To: Fernando Gont
> Cc: [email-masked]
> Subject: Re: [tcpm] New I-D "On the Validation of TCP 
> Sequence Numbers" (Fwd: New Version Notification for 
> draft-gont-tcpm-tcp-seq-validation-00.txt)
> 
> Hello, I think this is interesting, but I'm wondering why we 
> haven't realized this for long time and how most 
> implementations deal with simultaneous open properly.

I wonder on that as well. I just want to add that there is a new RFC 793 errata (reported 2012-07-31 by Botong Huang):

http://www.rfc-editor.org/errata_search.php?rfc=793&eid=3305

At first sight, it seems that this reports the same problem, right?

Michael

> > We have just published a new IETF I-D entitled "On the 
> Validation of 
> > TCP Sequence Numbers". The I-D is available at:
> >

---

From: Fernando Gont <[email-masked]>
Date: Fri, 01 Mar 2013 07:41:15 -0300

Hi, Yoshifumi,

On 03/01/2013 05:28 AM, Yoshifumi Nishida wrote:
> realized this for long time 

That depends on what you mean by "we". If "we" is some subset of
implementers, then "we" did realize about this a long time ago -- for
instance, *BSDs implement the behavior described in our I-D.

Why this has never resulted in an RFC update is a different question --
with the most simple answer being "none has ever proposed that".

> and how most implementations deal with

Some don't handle simultaneous opens -- e.g., at least some versions of
Windows.

> BTW, I'm also wondering why the Line 8 and 9 in 3.1 have SYN flags.

It assumes that the SYN flag is "adhered" to the SEQ being sent (i.e.,
the flag is always set when a segment with SEQ=100 (A -> B) or SEQ=300
(B -> A) is sent) -- but I'll reproduce the scenario with some buggy
implementation and see what they actually send on the wire.

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