Re: [tcpm] WG Last Call for ICMP Attacks
"Smith, Donald" <Donald.Smith@qwest.com> Thu, 03 September 2009 17:59 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 36A303A67F8 for <tcpm@core3.amsl.com>; Thu, 3 Sep 2009 10:59:49 -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 71GbBsnv2DDx for <tcpm@core3.amsl.com>; Thu, 3 Sep 2009 10:59:48 -0700 (PDT)
Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by core3.amsl.com (Postfix) with ESMTP id C33A83A67EC for <tcpm@ietf.org>; Thu, 3 Sep 2009 10:59:44 -0700 (PDT)
Received: from suomp61i.qintra.com (suomp61i.qintra.com [151.117.69.28]) by suomp64i.qwest.com (8.14.0/8.14.0) with ESMTP id n83HwmT0008896; Thu, 3 Sep 2009 12:58:50 -0500 (CDT)
Received: from qtdenexhtm22.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.0/8.14.0) with ESMTP id n83Hwguk021889; Thu, 3 Sep 2009 12:58:43 -0500 (CDT)
Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm22.AD.QINTRA.COM ([151.119.91.231]) with mapi; Thu, 3 Sep 2009 11:58:43 -0600
From: "Smith, Donald" <Donald.Smith@qwest.com>
To: "'toby.moncaster@bt.com'" <toby.moncaster@bt.com>, "'fernando@gont.com.ar'" <fernando@gont.com.ar>
Date: Thu, 03 Sep 2009 11:58:31 -0600
Thread-Topic: [tcpm] WG Last Call for ICMP Attacks
Thread-Index: AcosVD1b1g9yVBUiRXGetJUIlNrZdgAKJ+fAAA5kAEA=
Message-ID: <B01905DA0C7CDC478F42870679DF0F1005B64E3967@qtdenexmbm24.AD.QINTRA.COM>
References: <F1534040-EA0D-44E4-98F7-67C24CD12CCF@windriver.com><B01905DA0C7 CDC478F42870679DF0F1005B64E383D@qtdenexmbm24.AD.QINTRA.COM> <4A9F4AB1.6070605@gont.com.ar> <AEDCAF87EEC94F49BA92EBDD49854CC70CE19EA7@E03MVZ1-UKDY.domain1.systemhost.net>
In-Reply-To: <AEDCAF87EEC94F49BA92EBDD49854CC70CE19EA7@E03MVZ1-UKDY.domain1.systemhost.net>
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
Cc: "'tcpm@ietf.org'" <tcpm@ietf.org>, "'david.borman@windriver.com'" <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 17:59:49 -0000
Hi Fernando. Thanks for reviewing my comments. Toby and others did a good job of answering most of the addition questions but I have one or two clarifications below inline. 01100101000010|10011010111101? Hint 7 bit ascii Donald.Smith@qwest.com gcia > -----Original Message----- > From: toby.moncaster@bt.com [mailto:toby.moncaster@bt.com] > Sent: Thursday, September 03, 2009 4:06 AM > To: fernando@gont.com.ar; Smith, Donald > Cc: tcpm@ietf.org; david.borman@windriver.com > Subject: RE: [tcpm] WG Last Call for ICMP Attacks > > > > > -----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"... Since this documents focus is TCP/IP's interaction with ICMP I am ok with it but ICMP is an IP protocol (protocol number 1 :) A LOT of people use the expression "tcp/ip" to describe things that are IP (not dependant on tcp). > > > > > > > > > 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) Not bad there is an implication that I don't think you intended. > > > > "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." This wording is better. Yes elicited tends to imply "caused by". By adding the "appear" above this statement is clearer. > > > > > > > > > > > 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