Re: [tcpm] Some comments on tcpsecure

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

Return-Path: <>
Received: from (localhost []) by (Postfix) with ESMTP id 1A2603A6990; Mon, 7 Apr 2008 14:04:55 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id C47593A6990 for <>; Mon, 7 Apr 2008 14:04:53 -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 XBS6eBb7KgrC for <>; Mon, 7 Apr 2008 14:04:51 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C96703A6774 for <>; Mon, 7 Apr 2008 14:04:51 -0700 (PDT)
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id m37L2QGU023827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 Apr 2008 14:02:28 -0700 (PDT)
Message-ID: <>
Date: Mon, 07 Apr 2008 14:02:26 -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="===============1982343440=="

Ted Faber wrote:
> On Mon, Apr 07, 2008 at 01:31:28PM -0700, Joe Touch wrote:
>> Ted Faber wrote:
>>> On Fri, Apr 04, 2008 at 01:21:27PM -0700, Joe Touch wrote:
>>>> 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.
> You understand, of course, that our hypothetical network architect might
> read these documents in the other order - ICMP protections/ingress
> filtering first, then tcpsecure.   In that sequence the point is closing
> the hole remaining after ICMP is blocked and assuming that IPSec (or
> however it's spelled) is ruled out.
> Again, the purpose of this document is to standardize a protocol
> extension that makes a specific attack more difficult.  It is not a
> primer on securing TCP against all attacks - or even all spoofing
> attacks.  It's not the job of a standards document to mandate all
> possible (or even all relevant) countermeasures to all related attacks.
> This document needs to point to the ICMP document - perhaps strongly -
> but needn't RECOMMEND, in a 2119 sense, anything therein.  And given that
> this is a standards document, I don't think it should recommend them
> either.

Fair enough. It can warn - in the security considerations - that these 
protections assume corresponding protections on ICMPs, however. I.e., it 
  would be incorrect to recommend, but it can warn that "without 
corresponding ICMPs, this document may not provide the desired protection"


tcpm mailing list