Re: [tcpm] TCP-AO and ICMP attacks (was Re: comments on draft-ietf-tcpm-icmp-attacks-05)
Fernando Gont <fernando@gont.com.ar> Tue, 16 June 2009 19:09 UTC
Return-Path: <fernando.gont.netbook.win@gmail.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 EA50C3A6BA4 for <tcpm@core3.amsl.com>; Tue, 16 Jun 2009 12:09:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.778
X-Spam-Level:
X-Spam-Status: No, score=-1.778 tagged_above=-999 required=5 tests=[AWL=-0.822, BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643]
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 Zk0A+vnq5eKI for <tcpm@core3.amsl.com>; Tue, 16 Jun 2009 12:09:57 -0700 (PDT)
Received: from mail-gx0-f168.google.com (mail-gx0-f168.google.com [209.85.217.168]) by core3.amsl.com (Postfix) with ESMTP id D1AAD3A6951 for <tcpm@ietf.org>; Tue, 16 Jun 2009 12:09:56 -0700 (PDT)
Received: by gxk12 with SMTP id 12so648497gxk.13 for <tcpm@ietf.org>; Tue, 16 Jun 2009 12:09:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=wUSWbA4bkITQlzm/0d/xFp1XWCWeXaq1cLrF4/xSNk8=; b=fWmvgOyUJWp9R28WMzdrF6C/vi8HcZDy4a1IKL426XFLdn31YlcF1O6+LWtWbYvvUu 5STrO7t/bEw9W8FmX35uuTxhSzgVkzr/w2n/+plf7rc9/h/fZnizsxHMfTiWxK7AOlF7 4gcuq9blyr+HjQArbYCBSrwBRQYaUnQm8aS+8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=L3zb+GvcffIvIqCmaWXp30+wg+WUtzmJ3nwT3gI27NIvv9fxhi+UUlBmoreJty+DeT B+/Txe6vDYDkbWgqqJCXe/5pw/Azx6QiibBlwO4D6Hamy7SIIkIRnqcMQSCGrbPO65AA 92kkIVJjFswZQUuLTypJqXSlkb5m4R4t5v8Q4=
Received: by 10.90.26.3 with SMTP id 3mr7510451agz.27.1245179380572; Tue, 16 Jun 2009 12:09:40 -0700 (PDT)
Received: from ?190.48.201.80? ([190.48.201.80]) by mx.google.com with ESMTPS id 30sm239364agc.29.2009.06.16.12.09.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Jun 2009 12:09:39 -0700 (PDT)
Sender: Fernando Gont <fernando.gont.netbook.win@gmail.com>
Message-ID: <4A37EDEC.1030908@gont.com.ar>
Date: Tue, 16 Jun 2009 16:09:32 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Joe Touch <touch@ISI.EDU>
References: <C304DB494AC0C04C87C6A6E2FF5603DB221796D53C@NDJSSCC01.ndc.nasa.gov> <4A30BED6.3050308@gont.com.ar> <4A32BD5F.5030503@isi.edu> <4A379700.3070808@gont.com.ar> <4A37A551.60800@isi.edu> <4A37D6FC.4040005@gont.com.ar> <4A37E494.60904@isi.edu>
In-Reply-To: <4A37E494.60904@isi.edu>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, Fernando Gont <fernando.gont@gmail.com>
Subject: Re: [tcpm] TCP-AO and ICMP attacks (was Re: comments on draft-ietf-tcpm-icmp-attacks-05)
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: Tue, 16 Jun 2009 19:09:58 -0000
Joe Touch wrote: >>>> I think that for the sake of the "principle of least surprise", ICMP >>>> hard errors SHOULD NOT abort connections for which TCP AO has been enabled. >>> Please explain why you think that TCP-AO needs more strict advice in >>> this regard than IPsec. >> Because TCP-AO is TCP-specific. IPsec is not. The term "TCP" is almost >> not even mentioned in RFC 4301. So it wouldn't make sense for RFC 4301 >> to get into the details of how a specific transport protocol (TCP) would >> react to specific ICMP error messages. > > It does, though, in detail. Can you quote the text you are referring to, or provide a citation to the specific Section you are referring to? >> In the case of TCP-AO, it's TCP specific, and thus I believe it should >> provide stricter advice wrt how TCP should react to ICMP error messages >> when they are received for connections that employ TCP-AO. > > It's probably useful to split out the discussion of ICMP to a separate > section. However, the advice therein seems like it should still not > exceed what is in 4301 for the same reason for the same transport > protocol - there are pros and cons of either leaving open or closing > ICMP handling. As I mentioned, IPsec is by far more general. And thus it sort of makes sense to avoid being specific about any protocol that it could possibly encapsulate. TCP-AO is TCP-specific. And IMHO it would thus make sense for the document to be as specific/detailed as necessary. I guess you could come up with some scenario in which it makes sense to process ICMP messages for connections that employ TCP-AO. However, principle of least surprise: one of the main drivers for TCP MD5 was to mitigate connection-reset attacks. Thus, by default, you should close the avenue of ICMP-based attacks, too. IMO, that is the safe default. > This document is not a place where the difference between hard and soft > ICMPs and TCP opening vs. established should be resolved, since it has > not been resolved for TCP without authentication, and authentication > does not apply to the ICMP messages. Agreed. Easier: ignore ICMP error messages, or "do not abort connections in response to ICMP error messages". >>> We can add a discussion of PLPMTUD, but rfc4821 doesn't have any >>> particular recommendations of implementation. We would need to be >>> careful to not tie TCP-AO to PLPMTUD in a way that impedes TCP-AO >>> deployment. >> I believe it could/should be suggested that PLPMTUD be implemented >> without support for ICMP frag needed (i.e., ignore them). (FWIW, RFC4821 >> leaves it open as to whether PMTUD should only be implemented for >> dealing with ICMP blackholes, or as an ICMP-free version of PMTUD). > > There are a few possibilities: > > - use DF=0 Could be an option. However, considering that the IP ID field is 16-bits long, I don't think that relying on IP fragmentation should not be considered a viable option nowadays. > - use DF=1 with PMTUD > this requires ICMP frag-needed be passed > which opens a vulnerability on that ICMP type > however, the attack of additional frag-neededs > could reduce efficiency but won't shut down TCP > - use DF=1 with PLPMTUD > this allows ICMP frag-needed to be dropped > > The security benefits of PLPMTUD are more significant when ICMPs are > dropped more than when they are spoofed, but it can be noted. FWIW, if you implement the PMTUD counter-measure described in the ICMP attacks I-D, you get the benefits of ICMP-enabled PMTUD, without the security drawback of the traditional PMTUD (check for progress on the connection before honoring the ICMP error message). Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
- [tcpm] comments on draft-ietf-tcpm-icmp-attacks-05 Eddy, Wesley M. (GRC-MS00)[Verizon]
- Re: [tcpm] comments on draft-ietf-tcpm-icmp-attac… Eddy, Wesley M. (GRC-MS00)[Verizon]
- Re: [tcpm] comments on draft-ietf-tcpm-icmp-attac… Eddy, Wesley M. (GRC-MS00)[Verizon]
- Re: [tcpm] comments on draft-ietf-tcpm-icmp-attac… Fernando Gont
- Re: [tcpm] comments on draft-ietf-tcpm-icmp-attac… Fernando Gont
- Re: [tcpm] comments on draft-ietf-tcpm-icmp-attac… Joe Touch
- Re: [tcpm] comments on draft-ietf-tcpm-icmp-attac… Joe Touch
- Re: [tcpm] comments on draft-ietf-tcpm-icmp-attac… Eddy, Wesley M. (GRC-MS00)[Verizon]
- Re: [tcpm] comments on draft-ietf-tcpm-icmp-attac… Fernando Gont
- Re: [tcpm] comments on draft-ietf-tcpm-icmp-attac… Florian Weimer
- Re: [tcpm] comments on draft-ietf-tcpm-icmp-attac… Florian Weimer
- Re: [tcpm] comments on draft-ietf-tcpm-icmp-attac… Joe Touch
- Re: [tcpm] comments on draft-ietf-tcpm-icmp-attac… Joe Touch
- Re: [tcpm] comments on draft-ietf-tcpm-icmp-attac… Fernando Gont
- Re: [tcpm] comments on draft-ietf-tcpm-icmp-attac… Fernando Gont
- Re: [tcpm] comments on draft-ietf-tcpm-icmp-attac… Fernando Gont
- Re: [tcpm] comments on draft-ietf-tcpm-icmp-attac… Joe Touch
- Re: [tcpm] comments on draft-ietf-tcpm-icmp-attac… Joe Touch
- Re: [tcpm] comments on draft-ietf-tcpm-icmp-attac… Fernando Gont
- [tcpm] TCP-AO and ICMP attacks (was Re: comments … Fernando Gont
- Re: [tcpm] TCP-AO and ICMP attacks (was Re: comme… Joe Touch
- Re: [tcpm] TCP-AO and ICMP attacks (was Re: comme… Fernando Gont
- Re: [tcpm] TCP-AO and ICMP attacks (was Re: comme… Joe Touch
- Re: [tcpm] TCP-AO and ICMP attacks (was Re: comme… Fernando Gont
- Re: [tcpm] TCP-AO and ICMP attacks (was Re: comme… Joe Touch
- Re: [tcpm] TCP-AO and ICMP attacks (was Re: comme… Fernando Gont
- Re: [tcpm] TCP-AO and ICMP attacks (was Re: comme… Joe Touch
- Re: [tcpm] TCP-AO and ICMP attacks (was Re: comme… Fernando Gont
- Re: [tcpm] TCP-AO and ICMP attacks (was Re: comme… Joe Touch
- Re: [tcpm] TCP-AO and ICMP attacks (was Re: comme… Fernando Gont
- Re: [tcpm] TCP-AO and ICMP attacks (was Re: comme… Joe Touch