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

[Pasi Sarolahti <[e-mail]>]

On May 29, 2013, at 11:07 PM, Joe Touch <[e-mail]> wrote:

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

The PAWS algorithm motivates sending ACK with recovering from half-open connections (referring to fig. 10 in RFC 793), when one side crashes and re-opens the connection. Wouldn't this same reasoning apply also for missing timestamps case? It is possible that after a reboot the system timestamps setting is reset from enabled to disabled, if that happens to be the boot-time default. In such case the newly opening connection would have its segments discarded by the other side that still remains in established state, because of lack of timestamps, isn't that right?

Admittedly this is not the most likely scenario, but just trying to dig up the reasoning for choosing one way or the other.

Since we are on the path of clarifying the text with normative language, why not do the same also for Section 4.3? We should decide

1) MAY/SHOULD/MUST send response for missing timestamp

2) MAY/SHOULD/MUST send response when timestamp comparison fails (current text on R1 seems to want that this is MUST)

It would be good to provide these with some reasoning, too. For (2) this reasoning already seems to be in place.

Nit: start of section 4.3 uses "REQUIRES" that should not be capitalized because it is not a RFC 2119 keyword. How about just saying something like "if PAWS algorithm is enabled, the following steps MUST be followed", or something. Sorry about splitting hairs, but I think we should be pedantic about the keywords.

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

Because that paragraph talks about removal of timestamps option. But I agree that the proposed sentence doesn't sit there very well. How about including the reference in the beginning of the Middleboxes section of the text:

"Some middleboxes have been known to remove the TCP options
      described in this document from the TCP segments [Honda11]." (changed <SYN> segment to TCP segments)

The main point is that the current text only talks about dropping options from SYN segments, but this happens also for data segments, as the paper shows. Since we have fairly recent quantified data about this, why not include the reference?

- Pasi