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

Andre Oppermann <> Wed, 04 June 2008 23:01 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 2BF653A69AD; Wed, 4 Jun 2008 16:01:47 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id C58A23A69DB for <>; Wed, 4 Jun 2008 16:01:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nRJE5Cqmd6ng for <>; Wed, 4 Jun 2008 16:01:44 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DBEC93A6938 for <>; Wed, 4 Jun 2008 16:01:43 -0700 (PDT)
Received: (qmail 1461 invoked from network); 4 Jun 2008 21:58:19 -0000
Received: from localhost (HELO []) ([]) (envelope-sender <>) by (qmail-ldap-1.03) with SMTP for <touch@ISI.EDU>; 4 Jun 2008 21:58:19 -0000
Message-ID: <>
Date: Thu, 05 Jun 2008 01:01:46 +0200
From: Andre Oppermann <>
User-Agent: Thunderbird (Windows/20071210)
MIME-Version: 1.0
To: Joe Touch <touch@ISI.EDU>
References: <> <> <> <> <> <>
In-Reply-To: <>
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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Joe Touch wrote:
> 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.

Port randomization is complex to implement.

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

There are just as many corner cases with (true) port randomization.
Have a look at its CVS history in the BSDs.  Or Linux.  Took a couple

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

Normally the connection is in an idle state.  It is primarily observed
with web servers where either the client or server wants to do persistent
connections and the other end does not.  Or it times out.  There would be
no extra round-trip for the RST to be come effective.

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

I'm all ears on your magic RST/SYN burst filter.


tcpm mailing list