Re: [tcpm] WG Last Call for ICMP Attacks

Carlos Pignataro <cpignata@cisco.com> Wed, 09 September 2009 14:09 UTC

Return-Path: <cpignata@cisco.com>
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 ABF853A688F for <tcpm@core3.amsl.com>; Wed, 9 Sep 2009 07:09:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.994
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClqOz0HNO3+P for <tcpm@core3.amsl.com>; Wed, 9 Sep 2009 07:09:31 -0700 (PDT)
Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id A3B923A67A8 for <tcpm@ietf.org>; Wed, 9 Sep 2009 07:09:31 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n89EA0NC016098; Wed, 9 Sep 2009 10:10:00 -0400 (EDT)
Received: from [10.116.85.238] (rtp-cpignata-87113.cisco.com [10.116.85.238]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n89EA08r020780; Wed, 9 Sep 2009 10:10:00 -0400 (EDT)
Message-ID: <4AA7B738.10400@cisco.com>
Date: Wed, 09 Sep 2009 10:10:00 -0400
From: Carlos Pignataro <cpignata@cisco.com>
Organization: cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0
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> <4AA73910.7080002@gont.com.ar> <4AA74639.4000500@isi.edu>
In-Reply-To: <4AA74639.4000500@isi.edu>
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" <Donald.Smith@qwest.com>, 'tcpm Extensions WG' <tcpm@ietf.org>, 'David Borman' <david.borman@windriver.com>, Fernando Gont <fernando@gont.com.ar>
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 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:
<http://www.ietf.org/mail-archive/web/tcpm/current/msg03623.html>
Joe Touch > Routers are not required to return ICMPs on any particular
Joe Touch > timescale.
thread started at:
<http://www.ietf.org/mail-archive/web/tcpm/current/msg03621.html>

Thanks,

-- 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
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm