Re: [tcpm] WG Last Call for ICMP Attacks

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

Return-Path: <touch@ISI.EDU>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EA4113A6A19 for <>; Tue, 8 Sep 2009 23:08:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.519
X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uae+eYrdO5AA for <>; Tue, 8 Sep 2009 23:08:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 01E5C3A69E1 for <>; Tue, 8 Sep 2009 23:07:59 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id n8967saX006816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 Sep 2009 23:07:55 -0700 (PDT)
Message-ID: <>
Date: Tue, 08 Sep 2009 23:07:53 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20090812)
MIME-Version: 1.0
To: Fernando Gont <>
References: <> <B01905DA0C7CDC478F42870679DF0F1005B64E383D@qtdenexmbm24.AD.QINTRA.COM> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-MailScanner-ID: n8967saX006816
X-ISI-4-69-MailScanner: Found to be clean
Cc: "Smith, Donald" <>, 'tcpm Extensions WG' <>, 'David Borman' <>
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 06:08:01 -0000

Hash: SHA1

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. That
includes queues, low priority processing, etc. Regardless of rate
limiting, there's still no requirement about timeliness at all.

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


>> - --
>> 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,
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla -