Re: [tcpm] WG Last Call for ICMP Attacks

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ABF853A688F for <>; Wed, 9 Sep 2009 07:09:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.994
X-Spam-Status: No, score=-5.994 tagged_above=-999 required=5 tests=[AWL=-0.395, BAYES_00=-2.599, J_BACKHAIR_22=1, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ClqOz0HNO3+P for <>; Wed, 9 Sep 2009 07:09:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A3B923A67A8 for <>; Wed, 9 Sep 2009 07:09:31 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from ( []) by (8.13.8+Sun/8.13.8) with ESMTP id n89EA0NC016098; Wed, 9 Sep 2009 10:10:00 -0400 (EDT)
Received: from [] ( []) by (8.13.8+Sun/8.13.8) with ESMTP id n89EA08r020780; Wed, 9 Sep 2009 10:10:00 -0400 (EDT)
Message-ID: <>
Date: Wed, 09 Sep 2009 10:10: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:09:32 -0000

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).

> 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:


-- Carlos.

>>> In Sec 4.1:
>>>    It should be note that as there are no timeliness for ICMP error
>>>    messages, the TCP Sequence Number check described in this section
>>>    might cause legitimate ICMP error messages to be discarded
>>> This should also note that it is also possible to end up acting on ICMPs
>>> that are old even when such checks are in place, depending on the
>>> lateness of the ICMP and the width of the valid sequence number window.
>> I have no problem with this. However, the doc tries to address
>> deliberate attacks rather than ligitimate old packets. That said, if you
>> still feel this should be addressed in the document, please let me know
>> and I will incorporate text about this.
> The point is that the solutions tries to deal with deliberate attacks,
> but *in doing so* it changes how it reacts to legitimate events -
> whether legitimate old packets (above) or other legitimate events that
> would otherwise have been ignored (due to state). It's important to note
> this change.
> Joe
>>> - --
>>> top Page 13, space is missing:
>>>    synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT,
>>>    CLOSING, LAST-ACK or TIME-WAIT)as "soft errors".  That is, they do
>> Thanks!
>>                                   ^
>>> - --
>>> Section 8 would benefit from a summary of the different techniques used
>>> (e.g., parameter checking to drop ICMPs, state checking to drop ICMPs,
>>> etc.) and a description of how each basic technique affects the system -
>>> i.e., they (in general) make the system more robust to deliberate
>>> attacks, but could make the system react less rapidly to legitimate
>>> network errors. This is a deliberate trade-off, and perhaps a reasonable
>>> one, but worth noting, IMO.
>> Will do.
>> Thanks again!
>> Kind regards,
tcpm mailing list