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

[Pasi Sarolahti <[e-mail]>]

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

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

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.

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

[Honda11]  M. Honda, Y. Nishida, C. Raiciu, A. Greenhalgh, M. Handley, and H. Tokuda. Is it still possible to extend TCP?. In Proc. of ACM Internet Measurement Conference (IMC) '11, Berlin, Germany, November 2011. 

- Pasi