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

[Fernando Gont <[e-mail]>]

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:

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

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


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

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: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1