Re: [tcpm] Some comments on tcpsecure

Joe Touch <touch@ISI.EDU> Mon, 07 April 2008 20:31 UTC

Return-Path: <>
Received: from (localhost []) by (Postfix) with ESMTP id E0D3F3A6E0A; Mon, 7 Apr 2008 13:31:51 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id BEDB63A6C6E for <>; Mon, 7 Apr 2008 13:31:50 -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 kgrwzIDG9Euo for <>; Mon, 7 Apr 2008 13:31:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BD9EF28C37A for <>; Mon, 7 Apr 2008 13:31:48 -0700 (PDT)
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id m37KVTte012917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 Apr 2008 13:31:31 -0700 (PDT)
Message-ID: <>
Date: Mon, 07 Apr 2008 13:31:28 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20080213)
MIME-Version: 1.0
To: Ted Faber <faber@ISI.EDU>
References: <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.95.6
X-ISI-4-43-8-MailScanner: Found to be clean
Cc:, Fernando Gont <>
Subject: Re: [tcpm] Some comments on tcpsecure
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: multipart/mixed; boundary="===============1002844878=="

Ted Faber wrote:
> 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.

If that's the case, then what's the point of protecting TCP this way?

If ICMPs aren't filtered out, then they remain a simpler attack vector, 
and thus the protections afforded are moot.


tcpm mailing list