Re: [tcpm] TCP-AO and ICMP attacks (was Re: comments on draft-ietf-tcpm-icmp-attacks-05)

Fernando Gont <> Tue, 16 June 2009 19:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EA50C3A6BA4 for <>; Tue, 16 Jun 2009 12:09:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.778
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Zk0A+vnq5eKI for <>; Tue, 16 Jun 2009 12:09:57 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D1AAD3A6951 for <>; Tue, 16 Jun 2009 12:09:56 -0700 (PDT)
Received: by gxk12 with SMTP id 12so648497gxk.13 for <>; Tue, 16 Jun 2009 12:09:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id 3mr7510451agz.27.1245179380572; Tue, 16 Jun 2009 12:09:40 -0700 (PDT)
Received: from ? ([]) by with ESMTPS id 30sm239364agc.29.2009. (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Jun 2009 12:09:39 -0700 (PDT)
Sender: Fernando Gont <>
Message-ID: <>
Date: Tue, 16 Jun 2009 16:09:32 -0300
From: Fernando Gont <>
User-Agent: Thunderbird (Windows/20090302)
MIME-Version: 1.0
To: Joe Touch <touch@ISI.EDU>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "" <>, Fernando Gont <>
Subject: Re: [tcpm] TCP-AO and ICMP attacks (was Re: comments on draft-ietf-tcpm-icmp-attacks-05)
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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

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).

Fernando Gont
e-mail: ||
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1