Re: [tcpm] WG Last Call for ICMP Attacks

Joe Touch <touch@ISI.EDU> Wed, 09 September 2009 14:18 UTC

Return-Path: <touch@ISI.EDU>
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 04A2A3A6912 for <tcpm@core3.amsl.com>; Wed, 9 Sep 2009 07:18:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.026
X-Spam-Level:
X-Spam-Status: No, score=-2.026 tagged_above=-999 required=5 tests=[AWL=-0.427, BAYES_00=-2.599, J_BACKHAIR_22=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 KV5CU4wMFUdQ for <tcpm@core3.amsl.com>; Wed, 9 Sep 2009 07:18:53 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 86AD028C203 for <tcpm@ietf.org>; Wed, 9 Sep 2009 07:18:26 -0700 (PDT)
Received: from [192.168.1.47] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n89EIPFl016291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 Sep 2009 07:18:27 -0700 (PDT)
Message-ID: <4AA7B930.10300@isi.edu>
Date: Wed, 09 Sep 2009 07:18:24 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Carlos Pignataro <cpignata@cisco.com>
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>
In-Reply-To: <4AA7B738.10400@cisco.com>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
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 14:18:54 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Carlos Pignataro wrote:
> Please find a couple of comments inline.
> 
> On 9/9/2009 2:07 AM, Joe Touch wrote:
>>
>> Fernando Gont wrote:
>>> Hello, Joe,
>>> Thanks for your feedback! Comments in-line....
>>>> - --
>>>> 2.1 indicates reasons why ICMPs are not reliable; it should include
>>>> reasons why ICMPs could be late - so late that, e.g., sequence numbers
>>>> aren't relevant.
>>>> - --
>>> Could you clarify what you have in mind, specificaly? ICMP error
>>> messages being assigned lower priority than normal traffic, or what?
>>> FWIW, routers typically rate-limit ICMP errors...
>> Routers aren't required to emit ICMP errors on any particular timescale.
>> They can queue the events and get around to them - whenever.
> 
> IMHO, this comment might need some realistic qualification -- "whenever"
> seems overly excessive and too dramatic in real life. Routers do not try
> to do busywork and delay ICMP generation (exaggeration purposely
> intended to counter-balance).

"whenever" is when routers get to do it. Consider a router that has an
error in its queue to process. A user installs an upgrade and reboots
it, during which it is offline. Or it goes down and comes back for power
reasons. In either case, there is *no* requirement that such errors be
flushed.

Routers sometimes get locked up doing various things. Their control
planes often operate completely independently of the data plane, and
have priorities that can starve various routines that aren't required to
be timely. Errors that get hit with that could end up on the wire
seconds, minutes - *any* time later.

And they'd be *compliant* with FC1812.

>> That
>> includes queues, low priority processing, etc. Regardless of rate
>> limiting, there's still no requirement about timeliness at all.
> 
> Yes, router architectures get more complex, but so do solutions. In many
> architectures, for example, ICMPs are generated by the line-card CPU,
> avoiding any central RP delay, and RP<->LC path. The more busy the
> router could get, the more switching is done in hardware, and the more
> free cycles control-plane CPUs get. My 2¢.
> 
> If it feels like déjà vu, this topic was discussed at:
> <http://www.ietf.org/mail-archive/web/tcpm/current/msg03623.html>
> Joe Touch > Routers are not required to return ICMPs on any particular
> Joe Touch > timescale.
> thread started at:
> <http://www.ietf.org/mail-archive/web/tcpm/current/msg03621.html>

I raised it several times before. Bob Braden reiterated it in the
microphone line at an IETF a while ago too. It never made it into this
doc, however, and it should.

Joe

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqnuTAACgkQE5f5cImnZrsY6QCfUEBATafVEX80QuC1qpS7r34s
h10Anjni76IiXXNzQaFfLTh+G5F4LQFt
=4My3
-----END PGP SIGNATURE-----