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

[Joe Touch <[e-mail]>]

Hi, Pasi,

On 6/3/2013 3:18 AM, Pasi Sarolahti wrote:
>
> On Jun 1, 2013, at 4:57 PM, "Scheffenegger, Richard" <[e-mail]> wrote:
>
>> I agree with your reasoning, and think that IF Tsopt was
>> established, under the current semantics, subsequent segments
>> without Tsopt MUST not be accepted.
>
> This is true for reliable operation of PAWS, but I did not find any
> language in RFC 1323 that speaks about the situation when a segment
> is received without timestamp. Instead, the way how R1 was written
> "if there is a timestamp option and [...Ts conditions...] then treat
> the arriving segment as not acceptable" easily leads to
> interpretation that segment that arrives without timestamp is
> acceptable.

I disagree with your logic.

On connections that successfully negotiate TSopt, a segment lacking 
TSopt has insufficient information to be considered "acceptable", which 
to me indicates that it is "not acceptable".

I.e., we agree that a segment lacking TSopt has insufficient info; so do 
we assume that such a segment is in-window? or not?

Assuming such a segment is acceptable effectively disables PAWS.

> So the implementations that accept such segments are
> compliant with RFC 1323 in my reading, even if it opens a window of
> possible failure to the PAWS check.

RFC1323 does not specifically address segments lacking TSopt in the PAWS 
section. IMO, you can't claim compliance, but you can claim it doesn't 
violate it if you want - but I don't see the point in that.

> If we want reliable PAWS, I agree that "MUST not be accepted" is
> needed, but it seems that practical deployments have opted for
> imperfect PAWS in favor of being able to deal with problematic
> middleboxes in the network (or whatever other reason), no matter how
> rare those might be. I guess this is one of the principle vs.
> practice issues that implementations need to face these days. If we
> include this as MUST, I think it would be appropriate to note that
> many (or most?) current implementations do not have it (i.e., we do
> not necessarily know about all the deployment implications, referring
> to the discussion in middlebox part), and also note the check wasn't
> required by RFC 1323 (but this might have been an oversight).

I agree that we should note that 1323 doesn't address the case of TSopt 
being dropped or selectively omitted after being negotiated, and that 
the current recommendation may cause some broken middlebox behavior to 
be detected.

Joe