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

[Joe Touch <[e-mail]>]

On 5/27/2013 1:40 PM, Pasi Sarolahti wrote:
> On May 27, 2013, at 9:31 PM, Joe Touch <[e-mail]> wrote:
>
>> Regarding handling of non-RSTs lacking TSopt, we did discuss this
>> onthe 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.

It was the part about PAWS; if you accept segments omitting TSopt, those
segments aren't PAWS-protected, and so the connection isn't protectd.

>> 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
>> silentlydiscard 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,

There are four alternatives here regarding robustness:

	1. should the segment be accepted fully?

	2 should the segment generate a response (resend last ACK)?

	3. should the segment be silently ignored?

	4. should the segment generate an error?

Robustness suggests preferring these in order, where appropriate. 
However, if the point of TSopt is PAWS protection, then the best you can 
do is nothing (#3).

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

If you cannot point out such a problem, the MUST was clearly 
inappropriate. If there is *any* situation in which a receiver should do 
more than ignore a segment or report an error, then the condition is, at 
best, a SHOULD.

 > Perhaps the possible unreliability of PAWS is such, then.

That was my impression of the list discussion on this issue.

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

Sure. It's defeating the value of the TSopt. It's inappropriate for a 
connection to claim TSopt protection and not have it.

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

If there's a safe way to interpret segments without TSopt in a 
TSopt-protected connection, then sure, do it. I don't recall any being 
raised, which is why I suggested the way forward I did.

Joe