Re: [tcpm] TCPM and draft-ietf-tcpm-icmp-attacks

Joe Touch <touch@ISI.EDU> Fri, 19 February 2010 17:59 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 A74AA28C25C for <tcpm@core3.amsl.com>; Fri, 19 Feb 2010 09:59:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.495
X-Spam-Level:
X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 bDqN5Xp++moz for <tcpm@core3.amsl.com>; Fri, 19 Feb 2010 09:59:15 -0800 (PST)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id F1A3928C2D2 for <tcpm@ietf.org>; Fri, 19 Feb 2010 09:59:14 -0800 (PST)
Received: from [192.168.1.97] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o1JHxd25015065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 19 Feb 2010 10:00:24 -0800 (PST)
Message-ID: <4B7ED18B.8070304@isi.edu>
Date: Fri, 19 Feb 2010 09:59:39 -0800
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Jari Arkko <jari.arkko@piuha.net>
References: <20100218175622.61BB028C2E3@core3.amsl.com> <2002D196-D83C-4B44-870C-8E9A94D2D640@nokia.com> <4B7D8B9F.1010608@piuha.net> <4B7D8F55.90406@piuha.net>
In-Reply-To: <4B7D8F55.90406@piuha.net>
X-Enigmail-Version: 0.96.0
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="------------enigC97ACB21F1F9AAA733F89957"
X-MailScanner-ID: o1JHxd25015065
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm@ietf.org
Subject: Re: [tcpm] TCPM and draft-ietf-tcpm-icmp-attacks
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: Fri, 19 Feb 2010 17:59:18 -0000

Hi, Jari,

Jari Arkko wrote:
> Hi,
> 
> This document was recently in IESG review. My opinion is that the
> document should be approved as an RFC. Thanks for writing it.
> 
> However, I would like to note the following text from the document:
> 
> The consensus of the TCPM WG (TCP Maintenance and
> Minor Extensions Working Group) was to document this widespread
> implementation of nonstandard TCP behavior but to not change the TCP
> standard.
> 
> This would seem to imply that the TCPM WG has decided to deviate from
> the old IETF operating principle of "rough consensus and running code".
> For at least some of the techniques described in this draft, they are
> generally accepted and widely implemented on key implementations. I ask
> what the reason is for divorcing IETF standards from established best
> practices and actual running code? TCP RFCs are not sacred documents,
> they should reflect what we want our implementations to do. But maybe
> there are important use cases for the actual standard TCP behavior in
> this space, just that I don't know about them. Please educate me about
> the background for this decision.

The issue, from my view, in TCPM has been a penchant for trying to
upturn a long history of "be liberal in what you receive" to react to a
number of specific recent threats to TCP.

Much of this "rush to react" has led to a perspective that any incoming
packet that isn't expected is an indication of *attack*. That could
easily lead to changes to TCP that make it inappropriately complex and
fragile, at the expense of protecting every home computer from attacks
that are typically waged only at routers or other core network components.

I agree with Wes that the role of ICMP in the Internet needs to be
re-examined, and some changes made. However, I also believe that many of
the current TCPM "rush to react" changes (including tcpsecure, some of
the ICMP checks, some parts of the TCP cookie transactions proposal) are
a poor substitute for the use of true security (IPsec, TCP-AO), which
may also need to include more widely-deployable variants with different
levels of protection (e.g., BTNS).

Yes, I have been the most vocal proponent of this view on TCPM, and
perhaps in TSV. I do not believe I represent only myself, however - if
that's the "rough consensus", there are mechanisms to override me
anyway. It's also useful to note that some of the most vocal proponents
of "it's deployed, so let's change the standard" were involved in their
deployment.

TCP, IMO, ought to be treated with a lot more careful consideration than
that.

Joe