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

Joe Touch <touch@ISI.EDU> Tue, 16 June 2009 14:01 UTC

Return-Path: <touch@ISI.EDU>
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 BE9663A6B13 for <tcpm@core3.amsl.com>; Tue, 16 Jun 2009 07:01:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.482
X-Spam-Level:
X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 Jgin5gBUFxCC for <tcpm@core3.amsl.com>; Tue, 16 Jun 2009 07:01:07 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id C451E3A6845 for <tcpm@ietf.org>; Tue, 16 Jun 2009 07:01:07 -0700 (PDT)
Received: from [192.168.1.46] (pool-71-105-84-152.lsanca.dsl-w.verizon.net [71.105.84.152]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n5GDxiMl029288; Tue, 16 Jun 2009 06:59:46 -0700 (PDT)
Message-ID: <4A37A551.60800@isi.edu>
Date: Tue, 16 Jun 2009 06:59:45 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
References: <C304DB494AC0C04C87C6A6E2FF5603DB221796D53C@NDJSSCC01.ndc.nasa.gov> <4A30BED6.3050308@gont.com.ar> <4A32BD5F.5030503@isi.edu> <4A379700.3070808@gont.com.ar>
In-Reply-To: <4A379700.3070808@gont.com.ar>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
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 14:01:08 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Fernando Gont wrote:
> Joe Touch wrote:
> 
>>>> 5) (general) Section 5.1, last paragraph, it
>>>> seems like we should be mentioning TCP-AO as
>>>> well here, though I don't think it changes any
>>>> part of the claim.
>>> Agreed. Maybe this is also an indication that TCP-AO *should* change
>>> something in this respect!
>> TCP-AO already addresses ICMP attacks in the security considerations
>> section, and requires there to be a way to disable reaction to ICMPs.
>> Like IPsec, though, we don't make a-priori assessments as to whether
>> ICMPs should be blocked or not on connections on which TCP-AO (or IPsec)
>> is used.
> 
> What's the point of enabling TCP-AO, if you are not going to disable (or
> hard errors -> soft errors)?

See the text in RFC4301.

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

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

- ---

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.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAko3pVAACgkQE5f5cImnZruIhwCfccxoolqykof8xWtZ2Ud9cIZM
YB0AoMZ/1jeTrmKxvo2UPoy8KlGGmX0b
=Ermg
-----END PGP SIGNATURE-----