Re: [tcpm] Some comments on tcpsecure

Fernando Gont <> Tue, 08 April 2008 20:39 UTC

Return-Path: <>
Received: from (localhost []) by (Postfix) with ESMTP id 79E833A6C2D; Tue, 8 Apr 2008 13:39:06 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id D8E7128C134 for <>; Tue, 8 Apr 2008 13:39:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.443
X-Spam-Status: No, score=-0.443 tagged_above=-999 required=5 tests=[AWL=-0.295, BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643, SARE_RECV_SPEEDY_AR=0.808]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 61e0LMpf56+H for <>; Tue, 8 Apr 2008 13:39:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9AF963A6C2D for <>; Tue, 8 Apr 2008 13:39:02 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2FD105A8DC8; Tue, 8 Apr 2008 17:39:22 -0300 (ART)
Received: from ( [] (may be forged)) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id m38KcgjB026910; Tue, 8 Apr 2008 17:38:59 -0300
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Tue, 08 Apr 2008 17:36:36 -0300
To: Joe Touch <touch@ISI.EDU>
From: Fernando Gont <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 ( []); Tue, 08 Apr 2008 17:39:16 -0300 (ART)
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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

At 04:56 p.m. 08/04/2008, Joe Touch 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.

As I said, I did implement the PMTUD stuff in the icmp attacks draft. 
It now ships with OpenBSD and NetBSD, at least. And it's really easy 
to implement.

Regarding the mechanism you want to see (I'd say it's the same thing 
that's currently in the draft, except for what happens after the 
10-minute timeout), it will be the subject of some future 
standards-track draft. This one is informational, and documents what's done.

>>>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.

Well, this is even more agressive than the soft errors stuff/draft we 
have argued about for years. However, applications can already 
benefit of the soft errors behavior (what's described in the draft), 
but cannot currently benefit from what you propose.
They only loop through the A records while trying to establish a 
connection... but they don't loop through them if there's an error 
afterwards. The only exception to this might be an MTA.

Kind regards,

Fernando Gont
e-mail: ||
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

tcpm mailing list