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