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>
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 EA4113A6A19 for <tcpm@core3.amsl.com>; Tue, 8 Sep 2009 23:08:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.519
X-Spam-Level:
X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599]
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 uae+eYrdO5AA for <tcpm@core3.amsl.com>; Tue, 8 Sep 2009 23:08:00 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 01E5C3A69E1 for <tcpm@ietf.org>; Tue, 8 Sep 2009 23:07:59 -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 nitro.isi.edu (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: <4AA74639.4000500@isi.edu>
Date: Tue, 08 Sep 2009 23:07:53 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
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>
In-Reply-To: <4AA73910.7080002@gont.com.ar>
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
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>
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 06:08:01 -0000

-----BEGIN PGP SIGNED MESSAGE-----
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.

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,
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqnRjkACgkQE5f5cImnZrsmZACg7OrUOrfV8HMx7jmXSndfolRO
0iQAoNnVicCl6ZMdLw5wj+PunXcY6zzz
=EjYy
-----END PGP SIGNATURE-----