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

Fernando Gont <fernando@gont.com.ar> Tue, 30 March 2010 03:06 UTC

Return-Path: <fernando@gont.com.ar>
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 EDB053A6872 for <tcpm@core3.amsl.com>; Mon, 29 Mar 2010 20:06:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.08
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUcYI379RUCr for <tcpm@core3.amsl.com>; Mon, 29 Mar 2010 20:06:16 -0700 (PDT)
Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id AD2C13A67A2 for <tcpm@ietf.org>; Mon, 29 Mar 2010 20:06:14 -0700 (PDT)
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 7E0EC6B6AC7; Tue, 30 Mar 2010 00:06:48 -0300 (ART)
Received: from [192.168.0.102] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o2U36cTn023439; Tue, 30 Mar 2010 00:06:40 -0300
Message-ID: <4BB16ABB.4030506@gont.com.ar>
Date: Tue, 30 Mar 2010 00:06:35 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Joe Touch <touch@ISI.EDU>
References: <20100324192236.2D025BCAEF0@lawyers.icir.org> <4BAD02BD.6070907@gont.com.ar> <4BAD4827.7030202@isi.edu> <4BAD861C.1030401@gont.com.ar> <6B55F0F93C3E9D45AF283313B8D342BA68637D47@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> <4BAD98A4.5000708@gont.com.ar> <4BB13993.5040801@isi.edu> <4BB15156.3030408@gont.com.ar> <4BB161F5.3060805@isi.edu>
In-Reply-To: <4BB161F5.3060805@isi.edu>
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 (venus.xmundo.net [201.216.232.56]); Tue, 30 Mar 2010 00:06:47 -0300 (ART)
Cc: Christian Huitema <huitema@microsoft.com>, "tcpm@ietf.org" <tcpm@ietf.org>, "mallman@icir.org" <mallman@icir.org>
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
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:17 -0000

Joe,

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



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

Thanks,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1