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

[Joe Touch <[e-mail]>]

Hi, Pasi,

On 5/28/2013 1:45 AM, Pasi Sarolahti wrote:
> On May 28, 2013, at 12:38 AM, Joe Touch <[e-mail]> wrote:
>
>> 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).
>
>
> After the latest addition, there is some inconsistency between Sec.
> 3.2 and 4.3.
>
> * In the PAWS algorithm in sec. 4.3., there should be an additional
> step before R1 for checking if Timestamps option is present, and if not,
> tell to discard the segment (if negotiation had been successful).

IMO, yes.

> * PAWS algorithm tells to send acknowledgment if the check fails.
> Shouldn't we then, for consistency, require sending acknowledgment also
> if TSopt is missing? Current MAY in Sec. 3.2. is not very informative in
> my mind.

I don't think it's useful to send the ACK in that case. The point of 
PAWS is to ignore segments that are not protected. Even sending an ACK 
defeats that. At best, send a dup ack for last segment received 
correctly, but I still think that doing *anything* other than 
silent-drop isn't what PAWS protection intends.

> But based on my quick Linux check, I believe that currently
> implementations follow what sec. 4.3. currently says, and what it said
> in RFC 1323: "if there is Timestamps option in the segment, then [do
> PAWS check]....". So this would be relevant change compared to RFC 1323
> that should also be highlighted in Appendix H, because it may require
> action from implementors.

Yes, if so.

>>> 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.
>
> So, to reflect the comment Olivier made earlier, I'd suggest
> expanding  the third bullet in the Security Considerations section with something
> like following:
> OLD:
> " *  If the Timestamps option is removed from the <SYN> or <SYN,ACK>
>           segment, high speed connections that need PAWS would not have
>           that protection.  Middleboxes should not remove the Timestamps
>           option."
>
> NEW:
> " *  If the Timestamps option is removed from the <SYN> or <SYN,ACK>
>           segment, high speed connections that need PAWS would not have
> that protection. Successful negotiation of Timestamps option
> enforces a stricter verification of incoming segments at receiver. If
> the Timestamps option was removed from a subsequent data segment
> after a successful negotiation (for example, as part of
> re-segmentation), the segment is discarded by the receiver without
> further processing. Middleboxes should not remove the Timestamps
> option. One study found that 6% of measured HTTP connections had the
> Timestamps option removed from data segments [Honda11]."

The last sentence seems out of place; why are you including that? If 
there are implications to the 6% drop then you should mention that, but 
I would expect that elsewhere than the security considerations section.

Joe