Subject: [tcpm] TCP SEQ validation (Fwd: New Version Notification for draft-gont-tcpm-tcp-seq-validation-02.txt)

From: Fernando Gont <[email-masked]>
Date: Thu, 26 Mar 2015 14:03:57 -0500

Folks,

Thanks to some folks' push over time, and the fact that both co-authors
happened to find themselves at IETF 92, we've reposted our latests
version of this I-D (since the previous one had expired), in the hopes
of making progress.

Any comments on this rev will be appreciated. Additionally, I'll
repost/fwd Karen's latest comments on this I-D, which will be the basis
for the changes in the next rev.

Thanks!

Best regards,
Fernando

-------- Forwarded Message --------
Subject: New Version Notification for
draft-gont-tcpm-tcp-seq-validation-02.txt
Date: Thu, 26 Mar 2015 11:55:46 -0700
From: [email-masked]
To: Fernando Gont <[email-masked]>, David Borman
<[email-masked]>, Fernando Gont <[email-masked]>, David
Borman <[email-masked]>

A new version of I-D, draft-gont-tcpm-tcp-seq-validation-02.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.

Name:		draft-gont-tcpm-tcp-seq-validation
Revision:	02
Title:		On the Validation of TCP Sequence Numbers
Document date:	2015-03-26
Group:		Individual Submission
Pages:		16
URL:
http://www.ietf.org/internet-drafts/draft-gont-tcpm-tcp-seq-validation-02.txt
Status:
https://datatracker.ietf.org/doc/draft-gont-tcpm-tcp-seq-validation/
Htmlized:
http://tools.ietf.org/html/draft-gont-tcpm-tcp-seq-validation-02
Diff:
http://www.ietf.org/rfcdiff?url2=draft-gont-tcpm-tcp-seq-validation-02

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: Wesley Eddy <[email-masked]>
Date: Thu, 26 Mar 2015 15:33:23 -0400

> for the changes in the next rev.

I've read it.  I think it's quite clear in all regards, and that the
draft should definitely be adopted.

-- 
Wes Eddy
MTI Systems

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Thu, 26 Mar 2015 19:52:55 +0000

Hi,

I've definitely read the earlier version of this draft (and this is only a repost); odd that I appear to have posted to the list that I also support this...

Tl;dr: +1

> -----Original Message-----
> From: tcpm [mailto:[email-masked]] On Behalf Of Fernando Gont
> Sent: Donnerstag, 26. März 2015 14:04
> To: [email-masked]
> Subject: [tcpm] TCP SEQ validation (Fwd: New Version Notification for
> draft-gont-tcpm-tcp-seq-validation-02.txt)
> 
> Folks,
> 
> happened to find themselves at IETF 92, we've reposted our latests version
> of this I-D (since the previous one had expired), in the hopes of making
> progress.
> 
> has been successfully submitted by Fernando Gont and posted to the IETF
> repository.
> 
> 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
> 
> 
> 
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 26 Mar 2015 16:23:25 -0700

Hi,
I would like to check people who are willing to support it also agree that
this draft is published as a PS and it updates 793, or prefer other ways.
--
Yoshi

On Thu, Mar 26, 2015 at 12:03 PM, Fernando Gont <[email-masked]>
wrote:

> submission

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Fri, 27 Mar 2015 11:41:02 +0000

I would think PS is the proper way – there is no experimenting with a buggy spec, and Fernando pointed out, that most stacks had fixed that particular bug in 793 for quite some while, right?

Richard

From: tcpm [mailto:[email-masked]] On Behalf Of Yoshifumi Nishida
Sent: Donnerstag, 26. März 2015 18:23
To: Fernando Gont
Cc: [email-masked]
Subject: Re: [tcpm] TCP SEQ validation (Fwd: New Version Notification for draft-gont-tcpm-tcp-seq-validation-02.txt)

Hi,
I would like to check people who are willing to support it also agree that this draft is published as a PS and it updates 793, or prefer other ways.
--
Yoshi

On Thu, Mar 26, 2015 at 12:03 PM, Fernando Gont <[email-masked]<mailto:[email-masked]>> wrote:
Folks,

Thanks!

Best regards,
Fernando

-------- Forwarded Message --------
Subject: New Version Notification for
draft-gont-tcpm-tcp-seq-validation-02.txt
Date: Thu, 26 Mar 2015 11:55:46 -0700
From: [email-masked]<mailto:[email-masked]>
To: Fernando Gont <[email-masked]<mailto:[email-masked]>>, David Borman
<[email-masked]<mailto:[email-masked]>>, Fernando Gont <[email-masked]<mailto:[email-masked]>>, David
Borman <[email-masked]<mailto:[email-masked]>>

Abstract:

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<http://tools.ietf.org>.

The IETF Secretariat

_______________________________________________
tcpm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tcpm

---

From: Yoshifumi Nishida <[email-masked]>
Date: Fri, 27 Mar 2015 10:54:43 -0700

Hi Richard,

On Fri, Mar 27, 2015 at 4:41 AM, Scheffenegger, Richard <[email-masked]>
wrote:

>  I would think PS is the proper way – there is no experimenting with a
> buggy spec, and Fernando pointed out, that most stacks had fixed that
> particular bug in 793 for quite some while, right?
>

Yes.  I believe no one would argue the bug in 793 pointed out in the draft.
Also, I believe the solution presented in the draft is "make sense".
What I am wondering is this make sense solution can be the "once for all"
solution and we can happily update 793.
I guess some implementations have been using a bit different approach than
this, which gives me some concerns to update 793.
It will be very useful info if some implementations use this approach or
have a plan to use this approach.

Thanks,
--
Yoshi

>
> *From:* tcpm [mailto:[email-masked]] *On Behalf Of *Yoshifumi
> Nishida
> *Sent:* Donnerstag, 26. März 2015 18:23
> *To:* Fernando Gont
> *Cc:* [email-masked]
> *Subject:* Re: [tcpm] TCP SEQ validation (Fwd: New Version Notification
> for draft-gont-tcpm-tcp-seq-validation-02.txt)
>
>
>
> Hi,
>

---

From: David Borman <[email-masked]>
Date: Fri, 27 Mar 2015 20:59:48 -0500

Accepting the ACK in a packet one to the left of the window is what was implemented years (decades?) ago.  It’s what I put into BSD/OS, the comment at that time was:
                        /*
                         * If segment is just one to the left of the window,
                         * check three special cases:
                         * 1. Don't toss RST in response to 4.2-style keepalive.
                         * 2. If the only thing to drop is a FIN, we can drop
                         *    it, but check the ACK or we will get into FIN
                         *    wars if our FINs crossed (both CLOSING).
                         * 3. If we have sent a window probe, it may or may not
                         *    have been accepted.  If window probes crossed,
                         *    we must accept ACK on segments one to the left
                         *    of the window, or we can get ACK wars after
                         *    exchanging probes.  (After sending a probe,
                         *    ACK-only packets are sent with the pre-probe
                         *    sequence number.)
                         * In any of these cases, send ACK to resynchronize,
                         * but keep on processing for RST or ACK.
                         */
So mainly, the “accept the ACK if it is one to the left of the window” was the original implementation.

The only question is if there are any TCPs out there that actually do a window probe of more than 1 byte; in that case you’d want to accept an ACK if it is within the maximum window probe size to the left of the window.  But only the implementations that generate a window probe of more than one byte would need to worry about that, in case they had crossing probes with another TCP that also generated probes more than one byte in length.  If you have a one-byte probe crossing with a multi-byte probe, the one-byte probe check is sufficient to break the ACK war.

So maybe a comment needs to be inserted that if an implementation can generate a multi-byte probe, then they have to also implement accepting ACKs in packets within the maximum window probe size that they might generate.  That guarantees that whichever side sends the larger probe, it’ll accept the ACK from the smaller probe, and the ACK war will be broken.

			-David Borman

> On Mar 27, 2015, at 12:54 PM, Yoshifumi Nishida <[email-masked]> wrote:
> 
> Hi Richard,
> 
> On Fri, Mar 27, 2015 at 4:41 AM, Scheffenegger, Richard <[email-masked]> wrote:
> Yes.  I believe no one would argue the bug in 793 pointed out in the draft. Also, I believe the solution presented in the draft is "make sense".
> What I am wondering is this make sense solution can be the "once for all" solution and we can happily update 793. 
> I guess some implementations have been using a bit different approach than this, which gives me some concerns to update 793.
> It will be very useful info if some implementations use this approach or have a plan to use this approach.
> 
> Thanks,
> --
> Yoshi
> 
>  
> 
> On Thu, Mar 26, 2015 at 12:03 PM, Fernando Gont <[email-masked]> wrote:
> 
> Folks,
>

---

From: Fernando Gont <[email-masked]>
Date: Sun, 29 Mar 2015 04:00:26 -0500

On 03/27/2015 12:54 PM, Yoshifumi Nishida wrote:
> Hi Richard,
> 
> On Fri, Mar 27, 2015 at 4:41 AM, Scheffenegger, Richard <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     I would think PS is the proper way  there is no experimenting with
>     a buggy spec, and Fernando pointed out, that most stacks had fixed
>     that particular bug in 793 for quite some while, right?
> 
> 

With that in mind, I would propose that we take on this item as a wg
item (i.e., have the wg polled about it), and then converge on a fix (or
possible fixes). -- it's an I-D.. we don't need to agree on all minor
details at this stage.

The worst possible outcome is doing nothing about this item. So some fix
is better than no fix at all.

And since we're heading towards revising RFC793, it's even more
important that we get this done... It would be a shame to produce a
revision of RC793 that does not address this well-known bug.

Thanks!

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

---

From: Fernando Gont <[email-masked]>
Date: Wed, 01 Apr 2015 07:41:21 +0200

Folks,

Would it make sense to do a wg call for adoption of this document?

Thanks!

Best regards,
Fernando