Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt

Hi Pasi,

Yes, there was no formal requirement in 1323 (predating 2119), but its in 1323's PAWS section:

  4.2  The PAWS Mechanism
[...]
      The basic idea
      is that a segment can be discarded as an old duplicate if it is
      received with a timestamp SEG.TSval less than some timestamp
      recently received on this connection.

(an undefined TSval might be numeric zero, or TSrecent... 1323 doesn't say.)

We also had discussed the precedence of processing (1323 PAWS vs. 793 in-window acceptance testing), and the 1323 had some ambiguity how to go about this (the 1323 text would actually allow the omission of TSopt sometime along a session, voiding PAWS protection at that time, and potentially undefined (receiver) behavior then...

Regards,

Richard Scheffenegger

> -----Original Message-----
> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of
> Pasi Sarolahti
> Sent: Montag, 27. Mai 2013 22:41
> To: Joe Touch
> Cc: tcpm@ietf.org Extensions
> Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt
> 
> On May 27, 2013, at 9:31 PM, Joe Touch <touch@ISI.EDU> wrote:
> 
> > Regarding handling of non-RSTs lacking TSopt, we did discuss this on the
> list; you even cited this within the past day or so:
> >
> > ---
> >> Always including TSopt seems to represent the rough consensus of the
> >> WG, even if it might not be a uniform agreement. This was discussed
> >> quite extensively some time ago. (Though judging rough consensus from
> >> Emails is difficult... we'd need some sort of electronic hum tool
> > ---
> 
> My recollection is that this discussion concerned sender-side behavior,
> but there have been tens of Emails during the past weeks, so I might have
> missed something.
> 
> > Once you indicate a sender-side MUST, you need to describe how the
> receiver handles exceptions. IMO, there's little point to claiming PAWS
> protection if you're going to react *in any way* to a non-RST segment
> lacking TSopt.
> >
> > I.e., a sender MUST include implies - IMO - a receiver MUST silently
> discard when the 'must' isn't there.
> 
> My reading of the original robustness principle is that TCP receiver
> should have minimal required validation checks for segments, so I don't
> think sender-side "MUST include" automatically implies receiver-side "MUST
> ignore if missing", unless we can point out a clear problem in accepting
> the segment. Perhaps the possible unreliability of PAWS is such, then.
> 
> But there are possible deployment implications in additional receiver
> check, too. In a perfect world this might work, but RFC 1323 did not have
> as strict MUST requirement about including TSopt in all segments after
> handshake, and there are possible middlebox issues as Olivier mentioned.
> So I think it would be worthwhile addition to the middlebox section, then,
> to say if a middlebox removes TSopt option, or a resegmenting middlebox
> does not include it in all segments, that breaks the TCP connection
> entirely, if this version of spec is followed.
> 
> As a mere data point, I did a quick check on Linux that currently seems to
> first check if timestamp option was in incoming segment, and only then do
> PAWS check. It does not reject segments because of lack of TSopt, at least
> based on my quick reading.
> 
> - Pasi
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm