Re: [tcpm] WG Last Call for ICMP Attacks

Carlos Pignataro <> Wed, 09 September 2009 14:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2A12A3A6C31 for <>; Wed, 9 Sep 2009 07:46:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.958
X-Spam-Status: No, score=-5.958 tagged_above=-999 required=5 tests=[AWL=-0.359, BAYES_00=-2.599, J_BACKHAIR_22=1, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KV5xZo9vCHhd for <>; Wed, 9 Sep 2009 07:46:32 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0B2AE3A67D8 for <>; Wed, 9 Sep 2009 07:46:31 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from ( []) by (8.13.8+Sun/8.13.8) with ESMTP id n89El1WN018405; Wed, 9 Sep 2009 10:47:01 -0400 (EDT)
Received: from [] ( []) by (8.13.8+Sun/8.13.8) with ESMTP id n89El0ZA009505; Wed, 9 Sep 2009 10:47:01 -0400 (EDT)
Message-ID: <>
Date: Wed, 09 Sep 2009 10:47:00 -0400
From: Carlos Pignataro <>
Organization: cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20090812 Thunderbird/ Mnenhy/
MIME-Version: 1.0
To: Joe Touch <touch@ISI.EDU>
References: <> <B01905DA0C7CDC478F42870679DF0F1005B64E383D@qtdenexmbm24.AD.QINTRA.COM> <> <> <> <> <> <>
In-Reply-To: <>
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: 8bit
Cc: "Smith, Donald" <>, 'tcpm Extensions WG' <>, 'David Borman' <>, Fernando Gont <>
Subject: Re: [tcpm] WG Last Call for ICMP Attacks
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 09 Sep 2009 14:46:33 -0000


Thanks for the response, please see inline.

On 9/9/2009 10:18 AM, Joe Touch wrote:
> 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.

My point was not about impossibility, but about qualifying these
possibilities with a of tint of (and gauge them with their degree of)
operational realism. Have you (personally or second hand) seen an ICMP
being delayed by minutes?

> And they'd be *compliant* with FC1812.

I think that it should refer to what the specs envision, and not
necessarily to an ICMP delayed several minutes during an upgrade: e.g.,
rate-limit as per <>;
note that for example the specs even deal with ICMP generation for
bursts of traffic (e.g., traceroute), at
<> item (f).

>>> 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:
>> <>
>> Joe Touch > Routers are not required to return ICMPs on any particular
>> Joe Touch > timescale.
>> thread started at:
>> <>
> 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.

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.


-- Carlos.

> Joe
tcpm mailing list