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

[Joe Touch <[e-mail]>]

Hi, all,

On 5/30/2013 1:36 AM, Pasi Sarolahti wrote:
> On May 29, 2013, at 11:07 PM, Joe Touch <[e-mail]> wrote:
...
> 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.

REQUIRED is a 2119 keyword; I can't see why the present tense shouldn't 
be treated the same way, but MUST is fine too.

>>> " *  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?
>> Ifthere 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)

Yup - that's better, IMO.

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

That's fine, it was the placement issue.

However, if your point is that they remove options from data segments 
then you might point that out explicitly in the revised text.

Question - is there a reason a midbox would let the option through on a 
SYN and block it on the data segments? Or are you worried about path 
changes whose data segments go through midboxes that the SYN didn't? 
Again, if that's the case, then you might explain that in the text above 
in the midbox section (1-2 sentences).

Joe