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

[Pasi Sarolahti <[e-mail]>]

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. 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.

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).

- Pasi