Re: [tcpm] WG Last Call for ICMP Attacks

Fernando Gont <fernando@gont.com.ar> Wed, 09 September 2009 05:11 UTC

Return-Path: <fernando@gont.com.ar>
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 EC1F33A6A9F for <tcpm@core3.amsl.com>; Tue, 8 Sep 2009 22:11:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.232
X-Spam-Level:
X-Spam-Status: No, score=-3.232 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 888pjtsSVlL5 for <tcpm@core3.amsl.com>; Tue, 8 Sep 2009 22:11:18 -0700 (PDT)
Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 54E523A6B8C for <tcpm@ietf.org>; Tue, 8 Sep 2009 22:11:17 -0700 (PDT)
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id D23AB6B6723; Wed, 9 Sep 2009 02:11:54 -0300 (ART)
Received: from [192.168.0.167] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id n895BkFU019854; Wed, 9 Sep 2009 02:11:47 -0300
Message-ID: <4AA73910.7080002@gont.com.ar>
Date: Wed, 09 Sep 2009 02:11:44 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Joe Touch <touch@ISI.EDU>
References: <F1534040-EA0D-44E4-98F7-67C24CD12CCF@windriver.com> <B01905DA0C7CDC478F42870679DF0F1005B64E383D@qtdenexmbm24.AD.QINTRA.COM> <4A9F4AB1.6070605@gont.com.ar> <4AA6E2CC.2000905@isi.edu>
In-Reply-To: <4AA6E2CC.2000905@isi.edu>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Wed, 09 Sep 2009 02:11:54 -0300 (ART)
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 05:11:20 -0000

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



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



> - --
> 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,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1