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