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

[David Borman <[e-mail]>]

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 <[e-mail]> wrote:
> 
> Hi Richard,
> 
> On Fri, Mar 27, 2015 at 4:41 AM, Scheffenegger, Richard <[e-mail]> 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:[e-mail]] On Behalf Of Yoshifumi Nishida
> Sent: Donnerstag, 26. März 2015 18:23
> To: Fernando Gont
> Cc: [e-mail]
> 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 <[e-mail]> wrote:
> 
> 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: [e-mail]
> To: Fernando Gont <[e-mail]>, David Borman
> <[e-mail]>, Fernando Gont <[e-mail]>, David
> Borman <[e-mail]>
> 
> 
> 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
> 
> 
> 
> 
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
> 
>  
> 
> 
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm