Re: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03

Mark Allman <mallman@icir.org> Tue, 30 March 2010 03:06 UTC

Return-Path: <mallman@icir.org>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB3373A68D7 for <tcpm@core3.amsl.com>; Mon, 29 Mar 2010 20:06:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.438
X-Spam-Level:
X-Spam-Status: No, score=-3.438 tagged_above=-999 required=5 tests=[AWL=-0.569, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4]
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 PK3kPI75YasR for <tcpm@core3.amsl.com>; Mon, 29 Mar 2010 20:06:30 -0700 (PDT)
Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 9FB993A6835 for <tcpm@ietf.org>; Mon, 29 Mar 2010 20:06:30 -0700 (PDT)
Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o2U36sec002309; Mon, 29 Mar 2010 20:06:54 -0700 (PDT)
Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id EB19EC2124C; Mon, 29 Mar 2010 23:06:53 -0400 (EDT)
To: Joe Touch <touch@isi.edu>
From: Mark Allman <mallman@icir.org>
In-Reply-To: <4BB161F5.3060805@isi.edu>
Organization: International Computer Science Institute (ICSI)
Song-of-the-Day: Zombie
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="--------ma27341-1"; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Mon, 29 Mar 2010 23:06:53 -0400
Sender: mallman@icir.org
Message-Id: <20100330030653.EB19EC2124C@lawyers.icir.org>
Cc: Christian Huitema <huitema@microsoft.com>, "tcpm@ietf.org" <tcpm@ietf.org>, Fernando Gont <fernando@gont.com.ar>
Subject: Re: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mallman@icir.org
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Mar 2010 03:06:31 -0000

Catching up, I will chime in with three things ...

  - It still seems to me like we have pretty well converged that the
    draft's value is in terms of the TIME_WAIT truncation scheme.

  - My own opinion is that the draft can simply say "this scheme works
    best with monotonically increasing timestamps" and leave it at
    that.

    I.e., it isn't a strict requirement because the fall-back is just
    what we have without timestamps and if it were a strict requirement
    we'd have to think about flags and such.

    I.e., TCP implementers are smart folks who don't need RFC pages to
    define for them how to generate a monotonic sequence of timestamps
    and so my view is that doing so is useless detail.

  - I agree with Joe's note below that this discussion has led to an
    evolved understanding of the issues and what will be in the draft
    and it'd be nice to see either (a) a new draft from Fernando that we
    can adopt or at least (b) an outline from the chairs that sketches
    a WG document and its major components that can then be filled in by
    some editor.

allman




> The 03 draft focused on creating an algorithm that prevented guess-based
> attacks.
> 
> The discussion, as far as I can tell, has focused on the most peripheral
> part of 03 - the use of TS to cut TIME_WAIT.
> 
> IMO, that's a sufficient change that we're no longer considering a mere
> evolution of 03. The title, abstract, and most of the discussion will
> change.
> 
> Other points need to be addressed, notably:
> 
> 	- are TS values already sufficiently monotonic, or is
> 	an alg needed?
> 
> 	- is per-socketpair state needed to support monotonicity?
> 
> 	- interaction with SYN cookies
> 
> 	- corner cases (when not monotonic, whether that can be
> 	known, when it's supported on only one side, etc.)
> 
> 	- whether this depends on knowing which end will close the
> 	connection first at SYN time
> 
> I don't feel discussion on the mailing list is sufficient to consider
> the entirety of this proposal, and not just whether it's possible, but
> whether it's necessary.