Skip to main content

Last Call Review of draft-ietf-tcpm-tcp-timestamps-
review-ietf-tcpm-tcp-timestamps-secdir-lc-kelly-2010-12-16-00

Request Review of draft-ietf-tcpm-tcp-timestamps
Requested revision No specific revision (document currently at 04)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2010-12-17
Requested 2010-11-30
Authors Fernando Gont
I-D last updated 2010-12-16
Completed reviews Secdir Last Call review of -?? by Scott G. Kelly
Assignment Reviewer Scott G. Kelly
State Completed
Request Last Call review on draft-ietf-tcpm-tcp-timestamps by Security Area Directorate Assigned
Completed 2010-12-16
review-ietf-tcpm-tcp-timestamps-secdir-lc-kelly-2010-12-16-00
I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat these comments just like any other
last call comments.

This document describes modified processing steps for SYN segments received for
connections in TIME-WAIT state, with the aim being to allow higher connection
rates. The security considerations section references a comprehensive
discussion of the security implications for TCP timestamps. I see no security
issues with this document.

Minor nits:

The last paragraph of section 3 includes this sentence:

   "As noted in [Silbersack], such randomization
   schemes break prevent the mechanism proposed in this document from
   recycling connections that are in the TIME-WAIT state."

Might want to remove the word "break".

The security considerations has this paragraph:

   While the algorithm described in this document for processing
   incoming SYN segments would benefit from TCP timestamps that are
   monotonically-increasing across connections, this document does not
   propose any specific algorithm for generating timestamps, nor does it
   require monotonically-increasing timestamps across connections.

Maybe I'm just naive, but based on the information given, I don't understand
why this statement is in the security considerations section. Does the failure
to propose any specific algorithms have security consideration (that might be
more obvious to someone who reads [CPNI-TCP])?