Subject: [secdir] secdir review of draft-ietf-tcpm-tcp-timestamps-02

From: "Scott G. Kelly" <[email-masked]>
Date: Wed, 15 Dec 2010 10:31:45 -0800 (PST)

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

---

From: Fernando Gont <[email-masked]>
Date: Wed, 15 Dec 2010 17:58:20 -0300

Hi, Scott,

Thanks so much for your feedback! Please find my comments inline....

On 15/12/2010 03:31 p.m., Scott G. Kelly wrote:

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

I'll rephrase to:

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

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

The most obvious implementation of an algorithm that would produce
monotonically-increasing timestamps across connections would be to have
a global timestamp clock that is initialized to a fixed value (e.g.,
zero) at systemp boot-strap time, and that is incremented as specified
in RFC 1323. Such an algorithm could, e.g., leak information such as
system uptime.

How about if I re-write the SecCons as follows:

---- cut here ----
   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.
   [CPNI-TCP] contains a detailed discussion of the security
   implications of TCP timestamps and of different Timestamps
   generation algorithms.
---- cut here ----

?

Thanks!

Kind regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: "Scott G. Kelly" <[email-masked]>
Date: Wed, 15 Dec 2010 20:46:35 -0800

Hi Fernando,

Your proposed security considerations text does tie the two statements 
together better.

Thanks,

Scott