Re: [tcpm] WG Last Call for ICMP Attacks

Carlos Pignataro <cpignata@cisco.com> Wed, 09 September 2009 15:11 UTC

Return-Path: <cpignata@cisco.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 29FC828C238 for <tcpm@core3.amsl.com>; Wed, 9 Sep 2009 08:11:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.428
X-Spam-Level:
X-Spam-Status: No, score=-6.428 tagged_above=-999 required=5 tests=[AWL=0.171, 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 7+wboHBAkuuq for <tcpm@core3.amsl.com>; Wed, 9 Sep 2009 08:11:46 -0700 (PDT)
Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id 360A428C2CB for <tcpm@ietf.org>; Wed, 9 Sep 2009 08:11:46 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n89FCGq0019937; Wed, 9 Sep 2009 11:12:16 -0400 (EDT)
Received: from [10.116.85.238] (rtp-cpignata-87113.cisco.com [10.116.85.238]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n89FCFZ3014907; Wed, 9 Sep 2009 11:12:16 -0400 (EDT)
Message-ID: <4AA7C5CF.10400@cisco.com>
Date: Wed, 09 Sep 2009 11:12:15 -0400
From: Carlos Pignataro <cpignata@cisco.com>
Organization: cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0
MIME-Version: 1.0
To: Joe Touch <touch@ISI.EDU>
References: <F1534040-EA0D-44E4-98F7-67C24CD12CCF@windriver.com> <B01905DA0C7CDC478F42870679DF0F1005B64E383D@qtdenexmbm24.AD.QINTRA.COM> <4A9F4AB1.6070605@gont.com.ar> <4AA6E2CC.2000905@isi.edu> <4AA73910.7080002@gont.com.ar> <4AA74639.4000500@isi.edu> <4AA7B738.10400@cisco.com> <4AA7B930.10300@isi.edu> <4AA7BFE4.5050209@cisco.com> <4AA7C32B.3020606@isi.edu>
In-Reply-To: <4AA7C32B.3020606@isi.edu>
X-Enigmail-Version: 0.96.0
X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+, Z+jj`4%06nd'y9[ln&ScJT5S+O18e^
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: "Smith, Donald" <Donald.Smith@qwest.com>, 'tcpm Extensions WG' <tcpm@ietf.org>, 'David Borman' <david.borman@windriver.com>, Fernando Gont <fernando@gont.com.ar>
Subject: Re: [tcpm] WG Last Call for ICMP Attacks
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: Wed, 09 Sep 2009 15:11:47 -0000

On 9/9/2009 11:00 AM, Joe Touch wrote:
> 
> 
> Carlos Pignataro wrote:
> ...
>> The document says the following; would s/discarded/discarded or delayed/
>> cover it?
> 
>>    It is important to note that ICMP error messages are unreliable, and
>>    may be discarded due to data corruption, network congestion or rate-
>>    limiting.  Thus, while they provide useful information, upper layer
>>    protocols cannot depend on ICMP for correct operation.
> 
> That would help there, but it is also useful in other places to indicate
> what happens when a legitimate ICMP is delayed, i.e., how that affects
> what your algorithm would do.
> 
> It's OK to qualify it with "this is unlikely", but IMO it needs to be
> discussed with more than a single word in a single paragraph.

I think that "this is unlikely" or "this is highly unlikely" would still
be understating the probability (I am curious to see any experienced
example of ICMP being delayed minutes). Redundancy architectures of
routers typically cover the planned upgrade (or even unexpected reload)
scenarios you presented.

Perhaps a separate sentence in that paragraph before the "Thus, " with
some variation of "rate-limiting can delay ICMPs, and some other highly
unlikely theoretical scenarios can compound the delay"?

Thanks,

-- Carlos.

> 
> Joe