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

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

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id A611C3A6AAF; Wed, 4 Jun 2008 14:58:51 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8C01A3A6D35 for <>; Wed, 4 Jun 2008 14:58: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 sTVIv0vJg3N3 for <>; Wed, 4 Jun 2008 14:58:49 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8DE1D3A67FA for <>; Wed, 4 Jun 2008 14:58:49 -0700 (PDT)
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id m54LwZSB000180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Jun 2008 14:58:38 -0700 (PDT)
Message-ID: <>
Date: Wed, 04 Jun 2008 14:58:34 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20080421)
MIME-Version: 1.0
To: Andre Oppermann <>
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="===============0287927131=="

Andre Oppermann wrote:
>>     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
> Agreed for the second part about the potential for the time increase.
> Not agreed to the first part.  All kinds of mitigations make TCP
> implementations more complex.  Port randomization does, TCP-MD5 does,
> IPsec does and so on.  You can trust me on this one. ;-)

IPsec has nothing to do with the TCP implementation; it may make the 
stack more complex, but not TCP. Port randomization is a one-time event 
during SYN creation, and should be easy to factor out as a separate 
call. TCP MD5 is complex, but already implemented.

The complexity I'm referring to is reflected in the exchange on details 
and corner cases you've posted to this list.

> Repeating myself:
> The extra time it may take in an edge case is not terribly high.  Most
> RSTs will match and do their thing. 

Actually, you've already indicated cases where that might not be true; 
if RSTs are used to shut down typical connections "just in case", if any 
of the in-transit data was lost, then these will trigger the ACK 
exchange and extra RTT. This costs extra time, extra packets, and extra 
processing on both ends - all for a NON MALICIOUS CASE.

 > As far as my understanding
> goes TCP is concerned with reliable transport of data, not absolutely
> reliable abortions of the same through RSTs and SYNs.  They do play
> an important role in the functioning of the overall system but they
> are not sensitive to a delay of a couple of milliseconds.

Correct; however, just because an endpoint didn't expect a packet does 
not imply it is an attack either. That's the flaw in this system, IMO - 
and a reason why bursts of RSTs or SYNs to the same addr/port pair are a 
fairly clear indication of a problem, the filtering out of which would 
make these mods completely unnecessary.


tcpm mailing list