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

[Yoshifumi Nishida <[e-mail]>]

Hi Fernando,

Please allow us some time to think about how to proceed this.
In the meantime, we welcome further feedback on the draft.

Regards,
--
Yoshi

On Tue, Mar 31, 2015 at 10:41 PM, Fernando Gont <[e-mail]>
wrote:

> Folks,
>
> Would it make sense to do a wg call for adoption of this document?
>
> Thanks!
>
> Best regards,
> Fernando
>
>
>
>
> On 03/28/2015 02:59 AM, David Borman wrote:
> > 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
> >
> > _______________________________________________
> > tcpm mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tcpm
> >
>
>
> --
> Fernando Gont
> SI6 Networks
> e-mail: [e-mail]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
>