Re: [tcpm] Some comments on tcpsecure

Ted Faber <faber@ISI.EDU> Mon, 07 April 2008 18:34 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: tcpm-archive@megatron.ietf.org
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9A7A28C32D; Mon, 7 Apr 2008 11:34:48 -0700 (PDT)
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 34AA328C302 for <tcpm@core3.amsl.com>; Mon, 7 Apr 2008 11:34:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 2AQWAlKqQ6iN for <tcpm@core3.amsl.com>; Mon, 7 Apr 2008 11:34:47 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 2BA5828C2C9 for <tcpm@ietf.org>; Mon, 7 Apr 2008 11:34:47 -0700 (PDT)
Received: from zod.isi.edu (zod.isi.edu [128.9.168.221]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m37IY09h004604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 Apr 2008 11:34:01 -0700 (PDT)
Received: (from faber@localhost) by zod.isi.edu (8.14.2/8.14.2/Submit) id m37IY0vK036075; Mon, 7 Apr 2008 11:34:00 -0700 (PDT) (envelope-from faber)
Date: Mon, 07 Apr 2008 11:34:00 -0700
From: Ted Faber <faber@ISI.EDU>
To: Joe Touch <touch@ISI.EDU>
Message-ID: <20080407183359.GB68982@zod.isi.edu>
References: <200804041832.m34IWTC5025090@venus.xmundo.net> <47F68794.6050100@isi.edu> <200804042012.m34KCk8U022643@venus.xmundo.net> <47F68DC7.2050303@isi.edu>
Mime-Version: 1.0
In-Reply-To: <47F68DC7.2050303@isi.edu>
User-Agent: Mutt/1.4.2.3i
X-url: http://www.isi.edu/~faber
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: faber@zod.isi.edu
Cc: tcpm@ietf.org, Fernando Gont <fernando@gont.com.ar>
Subject: Re: [tcpm] Some comments on tcpsecure
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-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>
Content-Type: multipart/mixed; boundary="===============0952710080=="
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

On Fri, Apr 04, 2008 at 01:21:27PM -0700, Joe Touch wrote:
> 
> 
> Fernando Gont wrote:
> >At 04:55 p.m. 04/04/2008, Joe Touch wrote:
> >
> >>>The first one is the ICMP attacks draft 
> >>>(draft-ietf-tcpm-icmp-attacks). While tcpsecure mentions the security 
> >>>implications of ICMP on TCP conenctions, it does not reference the 
> >>>I-D. IIRC, this had already been pointed out by Joe (?). As far as 
> >>>the specifications are concerned, you shouldn't bother to fix 
> >>>TCP-based reset attacks if you don't fix the the ICMP-based ones.
> >>
> >>Agreed; should this doc recommend filtering out ICMPs as a result? 
> >>(there's no in-window checks that are meaningful, since ICMPs are not 
> >>guaranteed to be timely) I.e., something stronger than "there's 
> >>nothing we can do", which is what is implied in the current security 
> >>considerations.
> >
> >Ha... So we have been arguing about the ICMP stuff for almost four years 
> >on the idea that it is too aggressive to require ICMP error messages to 
> >be in-window, and now we're going to propose to filter them out? 
> 
> ICMPs are already filtered out for security reasons at firewalls. The 
> key here is whether to recommend that action or not.

And, IMHO, hat off, we're not.  Not here anyway.

This document has generated enough controversy on its own.  Hitching it
to another controversial document guarantees even slower progress.
Point off to the other documents that discuss the ICMP problem and move
on.  Yes there's a huge hole that someone's network architect needs to
plug, but the purpose of this document is not to be that architect; the
purpose of this document is to specify a standard protocol extension to
address the problem of off-path TCP control message spoofing.  Pointing
off to documents that discuss other problems in detail is helpful and
useful.

IMHO.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm