Re: [tcpm] WG Last Call for ICMP Attacks
<toby.moncaster@bt.com> Thu, 03 September 2009 13:02 UTC
Return-Path: <toby.moncaster@bt.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 321783A6A13 for <tcpm@core3.amsl.com>; Thu, 3 Sep 2009 06:02:29 -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 JbYt7gim31mm for <tcpm@core3.amsl.com>; Thu, 3 Sep 2009 06:02:28 -0700 (PDT)
Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id D97283A6C60 for <tcpm@ietf.org>; Thu, 3 Sep 2009 06:01:52 -0700 (PDT)
Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Sep 2009 11:05:48 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 03 Sep 2009 11:05:47 +0100
Message-ID: <AEDCAF87EEC94F49BA92EBDD49854CC70CE19EA7@E03MVZ1-UKDY.domain1.systemhost.net>
In-Reply-To: <4A9F4AB1.6070605@gont.com.ar>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [tcpm] WG Last Call for ICMP Attacks
Thread-Index: AcosVD1b1g9yVBUiRXGetJUIlNrZdgAKJ+fA
References: <F1534040-EA0D-44E4-98F7-67C24CD12CCF@windriver.com><B01905DA0C7CDC478F42870679DF0F1005B64E383D@qtdenexmbm24.AD.QINTRA.COM> <4A9F4AB1.6070605@gont.com.ar>
From: toby.moncaster@bt.com
To: fernando@gont.com.ar, Donald.Smith@qwest.com
X-OriginalArrivalTime: 03 Sep 2009 10:05:48.0931 (UTC) FILETIME=[1C82B530:01CA2C7E]
Cc: tcpm@ietf.org, 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: Thu, 03 Sep 2009 13:02:29 -0000
> -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Fernando Gont > Sent: 03 September 2009 05:49 > To: Smith, Donald > Cc: 'tcpm Extensions WG'; 'David Borman' > Subject: Re: [tcpm] WG Last Call for ICMP Attacks > > Hello, Donald, > > Thanks so much for your feedback! Comments inline.... (I have removed > those comments that I will apply and didn't need further > clarification...) > > > Smith, Donald wrote: > > 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. > > The protocol suite is referred to as "TCP/IP"... > > > > > 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 > [...] > > I'll adopt the term/phrase you and Joe have converged to. > > > > > 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. > > Does "elicited" sound bad? (english as a second language here, sorry) > "elicited" implies that the packet specifically sought the ICMP packet to be sent (which I guess would indeed be the case in tcptraceroute) whereas the alternate wording is trying to make it clear that the ICMP packet wasn't the desired response in the first place. Not sure how clear my explanation actually is! Possible alternative wording: "Many TCP implementations have incorporated a validation check such that they only react to those ICMP messages that appear to relate to segments currently "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. > > Ok. Will add a note on this. If you have any proposed text, please let > me know. > > > > > 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. > > mmmm... aren't we meaning that "as long as *one* of them is too large"? > > > > > 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. > > Well, even with the discussion you provided about "forged" vs. > "crafted", the attacker does forge the IP/TCP packet contained in the > ICMP payload... > > Thanks so much! > > 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 > > > > > _______________________________________________ > 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