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 >
- [tcpm] WG Last Call for ICMP Attacks David Borman
- Re: [tcpm] WG Last Call for ICMP Attacks Smith, Donald
- Re: [tcpm] WG Last Call for ICMP Attacks Joe Touch
- Re: [tcpm] WG Last Call for ICMP Attacks Smith, Donald
- Re: [tcpm] WG Last Call for ICMP Attacks Joe Touch
- Re: [tcpm] WG Last Call for ICMP Attacks Fernando Gont
- Re: [tcpm] WG Last Call for ICMP Attacks toby.moncaster
- Re: [tcpm] WG Last Call for ICMP Attacks Fernando Gont
- Re: [tcpm] WG Last Call for ICMP Attacks Smith, Donald
- Re: [tcpm] WG Last Call for ICMP Attacks Fernando Gont
- Re: [tcpm] WG Last Call for ICMP Attacks Smith, Donald
- Re: [tcpm] WG Last Call for ICMP Attacks Joe Touch
- Re: [tcpm] WG Last Call for ICMP Attacks Fernando Gont
- Re: [tcpm] WG Last Call for ICMP Attacks Lars Eggert
- Re: [tcpm] WG Last Call for ICMP Attacks Joe Touch
- Re: [tcpm] WG Last Call for ICMP Attacks Carlos Pignataro
- Re: [tcpm] WG Last Call for ICMP Attacks Joe Touch
- Re: [tcpm] WG Last Call for ICMP Attacks Carlos Pignataro
- Re: [tcpm] WG Last Call for ICMP Attacks Joe Touch
- Re: [tcpm] WG Last Call for ICMP Attacks Carlos Pignataro
- Re: [tcpm] WG Last Call for ICMP Attacks Joe Touch
- Re: [tcpm] WG Last Call for ICMP Attacks Anantha Ramaiah (ananth)
- Re: [tcpm] WG Last Call for ICMP Attacks Joe Touch
- Re: [tcpm] WG Last Call for ICMP Attacks Fernando Gont