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

"Scott G. Kelly" <scott@hyperthought.com> Wed, 15 December 2010 18:30 UTC

Return-Path: <scott@hyperthought.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8179B28C1EA for <secdir@core3.amsl.com>; Wed, 15 Dec 2010 10:30:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.907
X-Spam-Level:
X-Spam-Status: No, score=-3.907 tagged_above=-999 required=5 tests=[AWL=-0.308, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDys5LlVw2ss for <secdir@core3.amsl.com>; Wed, 15 Dec 2010 10:30:33 -0800 (PST)
Received: from smtp112.iad.emailsrvr.com (smtp112.iad.emailsrvr.com [207.97.245.112]) by core3.amsl.com (Postfix) with ESMTP id 92D2228C18D for <secdir@ietf.org>; Wed, 15 Dec 2010 10:30:31 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp41.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id BCFF1290CD4; Wed, 15 Dec 2010 13:32:14 -0500 (EST)
X-Virus-Scanned: OK
Received: from dynamic7.wm-web.iad.mlsrvr.com (dynamic7.wm-web.iad1a.rsapps.net [192.168.2.148]) by smtp41.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 1E5B0B81E8; Wed, 15 Dec 2010 13:31:45 -0500 (EST)
Received: from hyperthought.com (localhost [127.0.0.1]) by dynamic7.wm-web.iad.mlsrvr.com (Postfix) with ESMTP id 0BCEE1538081; Wed, 15 Dec 2010 13:31:45 -0500 (EST)
Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Wed, 15 Dec 2010 10:31:45 -0800 (PST)
Date: Wed, 15 Dec 2010 10:31:45 -0800 (PST)
From: "Scott G. Kelly" <scott@hyperthought.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, draft-ietf-tcpm-tcp-timestamps.all@tools.ietf.org
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Importance: Normal
X-Priority: 3 (Normal)
X-Type: plain
Message-ID: <1292437905.046510307@192.168.2.229>
X-Mailer: webmail8
Subject: [secdir] secdir review of draft-ietf-tcpm-tcp-timestamps-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Dec 2010 18:30:34 -0000

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