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

[Joe Touch <[e-mail]>]

Hi, all,

On 5/30/2013 7:28 AM, Scheffenegger, Richard wrote:
> Thanks Pasi, Joe.
>
>> 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.
>
> My understanding is, that failing the PAWS test should be treated like receiving
> a segment that is out-of-window. The reason for failing the PAWS test (missing TSopt,
> or invalid TSval) is secondary, not?
>
> Thus an ACK for the last in-sequence segment should be sent.
>
>> 1) MAY/SHOULD/MUST send response for missing timestamp
>
> This case is not currently covered. As consensus was reached that
> TSopt should not be allowed to be sent arbitratily for some segments and
> not for others, I would think a missing timestamp in a segment means,
> that segment needs to be treated like any other out-of-window segment.

Missing a timestamp is a bit different; it not only means that the 
segment should be treated as out-of-window, but there's something else 
amiss with the connection.

I.e., out-of-window might be fixed at some point, but missing TSopt will 
never be fixed. So I don't see what the point of sending a response here 
would be - it's like sending the last-valid ACK when you get any other 
malformed packet (because malformed != expired timestamp) -- which we 
don't do.

>> 2) MAY/SHOULD/MUST send response when timestamp comparison fails (current
>> text on R1 seems to want that this is MUST)
>
> For both, I think a MUST would be a appropriate, a SHOULD may
> suffice.(as an individual contributor).

FWIW, I never like "SHOULD" unless we have an explicit reason for not 
selecting MUST - either a known exception (which we should mention), or 
a reason for wanting to keep the door open.

In this case, I'm not sure what the appropriate behavior would be - 
what's the point of sending a response (e.g., an ACK of the last 
correctly received data) when the timestamp fails?

I.e., I wouldn't send a message unless it provides a purpose. Does it here?

Joe

>
>
> Fixed the Nit, and updated section 6 as indicated.
>
> Best regards,
>
> Richard Scheffenegger
>
>
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>> Pasi Sarolahti
>> Sent: Donnerstag, 30. Mai 2013 10:36
>> To: Joe Touch
>> Cc: [e-mail] Extensions
>> Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt
>>
>> 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
>>
>> _______________________________________________
>> tcpm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tcpm