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

Fernando Gont <> Tue, 16 June 2009 17:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E8F8D3A6D83 for <>; Tue, 16 Jun 2009 10:31:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nytL4jNM2hJX for <>; Tue, 16 Jun 2009 10:31:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 88DAE3A68BC for <>; Tue, 16 Jun 2009 10:31:46 -0700 (PDT)
Received: by qyk17 with SMTP id 17so34302qyk.29 for <>; Tue, 16 Jun 2009 10:31:48 -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=Wr16ihG+RHNMca7kgL4z7sE7Tb9cDKHMLnTE1L1uCHA=; b=MlcbSJWxdr1WrvzpxUsy6UODc6Yw2bafIVQwpadEP+tTuEq4Yne/rNbXENVJqAH3Uh Ze/oTgxsjexphI271FfSsw3T0pbHV1YIflhJ5Sk53HqYlWG4Ezdd/Xyq9/aBAEZ2nC0u +Sr2X+RSRJW5kQzN8PoebJuFOYAHc20xGTioE=
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=wT+PDdl+QFu/NMmjkKaYUfEBiwgwlZqaI9G2aYI00lVoaA1yXG+KAaO7O47TU+ZCfA lQ7wKkhUqklXfCeBnp1NQgizBoBiOfPLICi+kzq5iXIRr2VJ5r1wMFTSxMsPz/4R+68Q JxoRXpB0+yoBj+UVEXUzlWIToXPgoAbJvslQE=
Received: by with SMTP id n19mr6121403vcl.33.1245173508551; Tue, 16 Jun 2009 10:31:48 -0700 (PDT)
Received: from ? ( []) by with ESMTPS id 6sm125761ywc.31.2009. (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Jun 2009 10:31:47 -0700 (PDT)
Sender: Fernando Gont <>
Message-ID: <>
Date: Tue, 16 Jun 2009 14:31:40 -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 17:31:48 -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.

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.

>> What to do with "frag needed" might vary. Although one could argue that
>> you SHOULD implement PLPMTUD.
> ---
> We could add that TCP-AO, like IPsec (text copied from 4301):
>    ...A compliant TCP-AO
>    implementation MUST permit a local administrator to configure an
>    IPsec implementation to accept or reject unauthenticated ICMP
>    traffic.  This control MUST be at the granularity of ICMP type and
>    MAY be at the granularity of ICMP type and code.  Additionally, an
>    implementation SHOULD incorporate mechanisms and parameters for
>    dealing with such traffic.  For example, there could be the ability
>    to establish a minimum PMTU for traffic (on a per destination basis),
>    to prevent receipt of an unauthenticated ICMP from setting the PMTU
>    to a trivial size.

Makes sense to me. Although, again, I believe there should be (safe)
defaults for this.

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


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