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

Fernando Gont <> Tue, 30 March 2010 03:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EDB053A6872 for <>; Mon, 29 Mar 2010 20:06:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.08
X-Spam-Status: No, score=-1.08 tagged_above=-999 required=5 tests=[AWL=1.389, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bUcYI379RUCr for <>; Mon, 29 Mar 2010 20:06:16 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AD2C13A67A2 for <>; Mon, 29 Mar 2010 20:06:14 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7E0EC6B6AC7; Tue, 30 Mar 2010 00:06:48 -0300 (ART)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id o2U36cTn023439; Tue, 30 Mar 2010 00:06:40 -0300
Message-ID: <>
Date: Tue, 30 Mar 2010 00:06:35 -0300
From: Fernando Gont <>
User-Agent: Thunderbird (Windows/20100228)
MIME-Version: 1.0
To: Joe Touch <touch@ISI.EDU>
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.96.0
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 ( []); Tue, 30 Mar 2010 00:06:47 -0300 (ART)
Cc: Christian Huitema <>, "" <>, "" <>
Subject: Re: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 30 Mar 2010 03:06:17 -0000


> The 03 draft focused on creating an algorithm that prevented guess-based
> attacks.

No. Version -03 focuses on creating an algorithm such that timestamps
are monotonically-increasing. Another property of the algorithm is that
timestamps are hard to guess. Finally, the doc proposes an algorithm for
improved handling of SYN segments.

See the abstract. It's not a "protecting TCP against blid attacks via
tcp timestamps" at all.

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

Peripheral? Please compare the length of Section 2 and Section 3. Most
of the I-D is about processing SYN segments, rather than about
generating timestamps.

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

I disagree. But won't continue arguing on this one. You have apposed to
this I-D since the thread was started. Hopefully the chairs have noted
that. But hey have also noted the rest of the people, that did support it.

> Other points need to be addressed, notably:
> 	- are TS values already sufficiently monotonic, or is
> 	an alg needed?

What's "sufficiently monotonic"? There's no requirement for
monotonically-increasing timestamps across connections.

> 	- is per-socketpair state needed to support monotonicity?

Obviously not. It *is* useful for the algorithm currently proposed in
the I-D.

> 	- interaction with SYN cookies

Note sure what you mean. Obviously, if timestamps are "on", you can take
advantage of this. If not, no.

> 	- corner cases (when not monotonic, whether that can be
> 	known, when it's supported on only one side, etc.)

This has all been clarified.

> 	- whether this depends on knowing which end will close the
> 	connection first at SYN time

I have already clarified this. It doesn't matter who ends-up closing the

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

Joe, you have been opposed to this I-D, are opposed to this I-D, and
will be opposed to this I-D. Point taken.

Can the rest of us, if we agree, get some work done?

P.S.: Again, nobody is shipping the I-D for publication as an RFC. So
don't expect the I-D to be perfect at this point.

Fernando Gont
e-mail: ||
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1