IETF Logo Mail Archive

Re: [tcpm] AD Review: draft-ietf-tcpm-icmp-attacks-09

Lars Eggert <lars.eggert@nokia.com> Mon, 01 February 2010 09:30 UTC

Return-Path: <lars.eggert@nokia.com>
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 83A3D3A6933 for <tcpm@core3.amsl.com>; Mon, 1 Feb 2010 01:30:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.602
X-Spam-Level:
X-Spam-Status: No, score=-6.602 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, 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 XIoNrGypR3vY for <tcpm@core3.amsl.com>; Mon, 1 Feb 2010 01:30:04 -0800 (PST)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 90B973A68F5 for <tcpm@ietf.org>; Mon, 1 Feb 2010 01:30:03 -0800 (PST)
Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o119Tcvv023349; Mon, 1 Feb 2010 11:29:44 +0200
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Feb 2010 11:29:26 +0200
Received: from mgw-sa01.ext.nokia.com ([147.243.1.47]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Feb 2010 11:29:26 +0200
Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o119TOMc005361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Feb 2010 11:29:24 +0200
From: Lars Eggert <lars.eggert@nokia.com>
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.95.3 at fit.nokia.com
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: multipart/signed; boundary="Apple-Mail-21--1053461670"; protocol="application/pkcs7-signature"; micalg="sha1"
Date: Mon, 01 Feb 2010 11:29:06 +0200
In-Reply-To: <50DBEEEC-1EA0-4C8D-8B52-3063F13BAB7B@nokia.com>
To: Fernando Gont <fernando@gont.com.ar>, "tcpm@ietf.org WG" <tcpm@ietf.org>
References: <20100120010001.6D3913A67FB@core3.amsl.com> <3183E44E-124A-4C80-A112-72FBC00FEAFF@nokia.com> <4B60A3EC.20308@gont.com.ar> <EC58033A-8C2D-4C0D-A63E-7B5808DEA5B4@nokia.com> <4B6204F7.1070908@gont.com.ar> <50DBEEEC-1EA0-4C8D-8B52-3063F13BAB7B@nokia.com>
Message-Id: <729695D0-6DF5-4599-908C-9B375C30E9E8@nokia.com>
X-Mailer: Apple Mail (2.1077)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Mon, 01 Feb 2010 11:29:13 +0200 (EET)
X-OriginalArrivalTime: 01 Feb 2010 09:29:26.0331 (UTC) FILETIME=[0BF4A0B0:01CAA321]
X-Nokia-AV: Clean
Subject: Re: [tcpm] AD Review: draft-ietf-tcpm-icmp-attacks-09
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: Mon, 01 Feb 2010 09:30:05 -0000

Hi,

On 2010-1-29, at 11:32, Eggert Lars (Nokia-NRC/Espoo) wrote:
> On 2010-1-28, at 23:43, Fernando Gont wrote:
>>> If yes, then with delayed ACKs (or otherwise in corner cases)
>>> acked_packet_size is actually larger than maxsizesent always. 
>> 
>> Well, that depends on the amount of data you send. But yes, you could
>> say that "acked_packet_size is actually larger than maxsizesent *usually*".
>> 
>>> On
>>> second reading, I don't think that's a problem for the technique, but
>>> the name and description of the variable confused me earlier.
>> 
>> Should I add a clarification?
> 
> I think this would make sense. You might also want to change the name of the variable.

this is the only issue I haven't seen addressed in -10.

I'll start the IETF Last Call based on -10 now; we can work out the few remaining issues (incl. this one) in parallel.

Lars

v2.23.0 | Report a Bug | By Email