Re: [tcpm] Some comments on tcpsecure

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

Return-Path: <>
Received: from (localhost []) by (Postfix) with ESMTP id 1C0E628C408; Tue, 8 Apr 2008 13:31:32 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id E64A228C395 for <>; Tue, 8 Apr 2008 13:31:30 -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 TvA5710lEBXc for <>; Tue, 8 Apr 2008 13:31:29 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 09DD428C36A for <>; Tue, 8 Apr 2008 13:31:26 -0700 (PDT)
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id m38KVLpi003147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 Apr 2008 13:31:23 -0700 (PDT)
Message-ID: <>
Date: Tue, 08 Apr 2008 12:56:09 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20080213)
MIME-Version: 1.0
To: Fernando Gont <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.95.6
X-ISI-4-43-8-MailScanner: Found to be clean
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="===============0631882371=="

Fernando Gont wrote:
>> But this is still somewhat off topic if there's a way to get 95% of 
>> the way there without doing a seq check, which is what I'm suggesting. 
>> That would correct the *intent* of the current code without *needing 
>> to change the current specs* (which is the only way to *require* 
>> timely ICMPs).
> ICMP code has been for a long time (>20+ years, in some cases) to do 
> "hard errors -> soft errors". The TCP SEQ check was originally 
> implemented in Linux as a general validation check. Then applied in 
> virtually all stacks for the same reason.
> The TCP SEQ check is particularly useful as a mitigation against PMTUD 
> attacks... and some have seen as something quicker/easier to implement 
> than the mechanism proposed in my draft (although FWIW, I implemented 
> the mechanism myself for OpenBSD, and it wasn't what pne would call 
> "complex" at all...)

I'd like to see a mechanism that's sufficiently easy to implement that 
accomplishes the intent, even if it differs from what's currently 
deployed. That presumes we're trying to find a good solution, rather 
than document the existing deployed solution.

>> Robustness also allows signalled connection faults to recover quickly, 
>> rather than on the same timescale as a 'no message' timeout. Yes, 
>> though, the devil is in the detail of what that timeout would be.
> You say it allows a connection to recover quickly, but... why would it 
> actually recover, if you are not affecting the path that packets follow?

Recovery could involve the application terminating a poor connection in 
favor of a better alternate, e.g., to a different IP address. By 
prolonging the agony, we're failing to indicate that the connection is 
having a substantial problem.


tcpm mailing list