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

Fernando Gont <fernando@gont.com.ar> Tue, 30 March 2010 03:12 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 920CC3A6813 for <tcpm@core3.amsl.com>; Mon, 29 Mar 2010 20:12:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.206
X-Spam-Level:
X-Spam-Status: No, score=-1.206 tagged_above=-999 required=5 tests=[AWL=1.263, 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 TWAAD6nbA-2j for <tcpm@core3.amsl.com>; Mon, 29 Mar 2010 20:12:08 -0700 (PDT)
Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 65F6C3A67FF for <tcpm@ietf.org>; Mon, 29 Mar 2010 20:12:07 -0700 (PDT)
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id AE9146B6AC7; Tue, 30 Mar 2010 00:12:41 -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 o2U3CWxc025064; Tue, 30 Mar 2010 00:12:33 -0300
Message-ID: <4BB16C1D.2020502@gont.com.ar>
Date: Tue, 30 Mar 2010 00:12:29 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: mallman@icir.org
References: <20100330030653.EB19EC2124C@lawyers.icir.org>
In-Reply-To: <20100330030653.EB19EC2124C@lawyers.icir.org>
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:12:40 -0300 (ART)
Cc: Christian Huitema <huitema@microsoft.com>, "tcpm@ietf.org" <tcpm@ietf.org>, Joe Touch <touch@isi.edu>
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:12:09 -0000

Mark,

I can publish such a rev.

Will split the "timestamps generation" into a separate I-D, and will
address in the current draft those points that needed clarification, etc.

Thanks,
Fernando




Mark Allman wrote:
> 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.
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

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