Re: [tcpm] Q&C regarding tcpsecure-09 recommendations

Joe Touch <touch@ISI.EDU> Wed, 04 June 2008 20:50 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id BCF603A68AA; Wed, 4 Jun 2008 13:50:24 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id B52113A6928 for <>; Wed, 4 Jun 2008 13:50:23 -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 E9rzeO267AfH for <>; Wed, 4 Jun 2008 13:50:22 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C8FBA3A68AA for <>; Wed, 4 Jun 2008 13:50:22 -0700 (PDT)
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id m54Ko7nw006519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Jun 2008 13:50:11 -0700 (PDT)
Message-ID: <>
Date: Wed, 04 Jun 2008 13:50:07 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20080421)
MIME-Version: 1.0
To: Lars Eggert <>
References: <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.95.6
X-ISI-4-43-8-MailScanner: Found to be clean
Subject: Re: [tcpm] Q&C regarding tcpsecure-09 recommendations
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: multipart/mixed; boundary="===============0509839157=="

Lars Eggert wrote:
> Hi,
> On 2008-6-2, at 20:41, ext Joe Touch wrote:
>> This is, IMO, a signal to review the recommendations in Section 1.1. I 
>> was always concerned that these mitigations would be misinterpreted as 
>> applying to hosts in general, which they do not.
> do you think that a short paragraph in Section 1.1 that discusses the 
> downsides of implementing the checks where not needed would be helpful?


> Currently the document says "The mitigations suggested in this draft 
> SHOULD be implemented in devices where the TCP connections are most 
> vulnerable to the attacks described in this document. (...) These 
> mitigations MAY be implemented in other cases." I think you're saying 
> that the last sentence may not be detailed enough to allow implementors 
> to judge the tradeoffs?

Yes, that's partly it. The key is that there are two issues that don't 
come out just because they're ref'd off to the document (i.e., 
"described in this document" isn't sufficient; it's important to 
summarize these):

	1. these mitigations help only a very small class of situations
	that may be typical for unprotected routers, but are currently
	very rare otherwise.

	2. of particular recent note, these mitigations are not useful
	to on-path attacks, such as ISP-issued RSTs

	2. adding these mitigations complicates the TCP implementation,
	and makes it less robust to legitimate RSTs, esp. in the
	presence of reordering; it can increase the time needed to
	reset a connection by one or more RTTs


tcpm mailing list