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
>