Re: [tcpm] WG Last Call for ICMP Attacks

"Smith, Donald" <Donald.Smith@qwest.com> Wed, 02 September 2009 20:50 UTC

Return-Path: <Donald.Smith@qwest.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 C27F728C130 for <tcpm@core3.amsl.com>; Wed, 2 Sep 2009 13:50:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 E60rS30bMiVC for <tcpm@core3.amsl.com>; Wed, 2 Sep 2009 13:50:18 -0700 (PDT)
Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by core3.amsl.com (Postfix) with ESMTP id 9209628C105 for <tcpm@ietf.org>; Wed, 2 Sep 2009 13:50:18 -0700 (PDT)
Received: from sudnp796.qintra.com (sudnp796.qintra.com [151.116.2.212]) by suomp64i.qwest.com (8.14.0/8.14.0) with ESMTP id n82KmfiA029462; Wed, 2 Sep 2009 15:48:41 -0500 (CDT)
Received: from qtdenexhtm22.AD.QINTRA.COM (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.0/8.14.0) with ESMTP id n82Kmar5005529; Wed, 2 Sep 2009 14:48:36 -0600 (MDT)
Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm22.AD.QINTRA.COM ([151.119.91.231]) with mapi; Wed, 2 Sep 2009 14:48:35 -0600
From: "Smith, Donald" <Donald.Smith@qwest.com>
To: 'David Borman' <david.borman@windriver.com>, 'tcpm Extensions WG' <tcpm@ietf.org>
Date: Wed, 02 Sep 2009 14:48:34 -0600
Thread-Topic: [tcpm] WG Last Call for ICMP Attacks
Thread-Index: AcorFskRSIZDh8r5QwqfUYGf5oE7ZAAA38Kg
Message-ID: <B01905DA0C7CDC478F42870679DF0F1005B64E383D@qtdenexmbm24.AD.QINTRA.COM>
References: <F1534040-EA0D-44E4-98F7-67C24CD12CCF@windriver.com>
In-Reply-To: <F1534040-EA0D-44E4-98F7-67C24CD12CCF@windriver.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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, 02 Sep 2009 20:50:19 -0000

1.
ICMP [RFC0792] is a fundamental part of the TCP/IP protocol suite,
   and is used mainly for reporting network error conditions.

ICMP is part of the IP protocol suite.

2.2
Therefore, in the case of TCP, an attacker could send a forged ICMP
   message to the attacked system, and, as long as he is able to guess
   the four-tuple (i.e., Source IP Address, Source TCP port, Destination
   IP Address, and Destination TCP port) that identifies the
   communication instance to be attacked, he will be able to use ICMP to
   perform a variety of attacks.

Forged usually implies that source ip address has been spoofed usually to come from some type of trusted host.
Crafted is the term generally used to mean the packets contents (not header) were modified.
In this case there is no need to spoof the source ip address as the end host has no knowledge about the routers in between them and the end host system. So I recommend you change forged to crafted.

2.2
The need to be more more cautious when processing received ICMP error
   messages in order to mitigate or eliminate the impact of the attacks

Grammer:
The need to be more cautious when processing received ICMP error
   messages in order to mitigate or eliminate the impact of the attacks



4.1
Many TCP implementations have incorporated a validation check so
   makes TCP react only to those ICMP error messages elicited by
   segments that were "in-flight" to the destination system.

Grammer and minor correction for elicited:
Many TCP implementations have incorporated a validation check to
make TCP react only to those ICMP error messages that 
appear to have been caused by segments that were "in-flight" to the destination system.

 5.2
Assuming that once a connection is
      established it is not usual for the transport protocol to change
      (or be reloaded), it should be unusual to get these error
      messages.
Should be:
Assuming that once a connection is
      established it is usual for the transport protocol to change
      (or be reloaded), it should be unusual to get these error
      messages.


...(still 5.2)

ICMPv6 type 1 (Destination Unreachable), code 1 (communication with
   destination administratively prohibited)

      This error message indicates that the destination is unreachable
      because of an administrative policy.  For connection-oriented
      protocols such as TCP, one could expect to receive such an error
      as the result of a connection-establishment attempt.  Receiving
      such an error for a connection in any of the synchronized states
      would mean that the administrative policy changed during the life
      of the connection.  However, in the same way this error condition
      (which was not present when the conenction was established)
      appeared, it could get solved solved in the near term.

This actually does occur in some cases where bruteforce password attempts causes a tool such as fail2ban to block access.
and connection not conenction.


7.1
The PMTUD mechanism for IPv4 uses the Don't Fragment (DF) bit in the
   IP header to dynamically discover the Path MTU.  The basic idea
   behind the PMTUD mechanism is that a source system assumes that the
   MTU of the path is that of the first hop, and sends all its datagrams
   with the DF bit set.  If any of the datagrams is too large to be
   forwarded without fragmentation by some intermediate router, the
   router will discard the corresponding datagram, and will return an
   ICMP "Destination Unreachable" (type 3) "fragmentation neeed and DF
   set" (code 4) error message to the sending system.  This message will
   report the MTU of the constricting hop, so that the sending system
   can reduce the assumed Path-MTU accordingly.

Spelling and grammer:
If any of the datagrams is too large ->
If any of the datagrams are too large.

fragementation needed


...


As discussed in both [RFC1191] and [RFC1981], the Path-MTU Discovery
   mechanism can be used to attack TCP.  An attacker could send a forged
   ICMP "Destination Unreachable, fragmentation needed and DF set"
   packet (or their ICMPv6 counterpart) to the sending system,
   advertising a small Next-Hop MTU.  As a result, the attacked system
   would reduce the size of the packets it sends for the corresponding
   connection accordingly.

Again I would suggest crafted instead of forged.

7.2
The IETF has standardized a Path-MTU Discuvery mechanism called
   "Packetization Layer Path MTU Discovery" that does not depend on ICMP
   error messages.

Spelling -> Discovery


Review stopped at page 17.



(coffee != sleep) & (!coffee == sleep)
Donald.Smith@qwest.com gcia   

> -----Original Message-----
> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On 
> Behalf Of David Borman
> Sent: Tuesday, September 01, 2009 9:12 AM
> To: tcpm Extensions WG
> Subject: [tcpm] WG Last Call for ICMP Attacks
> 
> Wes and I are starting a Working Group Last Call for the ICMP 
> Attacks  
> document:
> 
> 	http://www.ietf.org/id/draft-ietf-tcpm-icmp-attacks-06.txt
> 
> This document is intended to be published as Informational.  
> The WGLC  
> will end on Sep. 15, 2009.  Please send any comments to list before  
> then.
> 
> 		-David Borman & Wes Eddy, TCPM WG chairs
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>