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

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.

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

Fixed the Nit, and updated section 6 as indicated.

Best regards,

Richard Scheffenegger

> -----Original Message-----
> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of
> Pasi Sarolahti
> Sent: Donnerstag, 30. Mai 2013 10:36
> To: Joe Touch
> Cc: tcpm@ietf.org Extensions
> Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt
> 
> On May 29, 2013, at 11:07 PM, Joe Touch <touch@ISI.EDU> 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
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm