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

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

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 420193A6880; Wed, 4 Jun 2008 16:53:09 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 29C8C3A6880 for <>; Wed, 4 Jun 2008 16:53:08 -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 y30hvVLhKLk6 for <>; Wed, 4 Jun 2008 16:53:07 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0D0243A6810 for <>; Wed, 4 Jun 2008 16:53:07 -0700 (PDT)
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id m54NmrOd001563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Jun 2008 16:48:57 -0700 (PDT)
Message-ID: <>
Date: Wed, 04 Jun 2008 16:48:53 -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="===============1207349757=="

Andre Oppermann wrote:
> 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.

It's already implemented. See my other reply.

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

Multiple iterations is not an indication of difficult corner cases.

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

It's also been observed in web servers that want to reduce the amount of 
TIME_WAIT state they hold - and thus kernel memory they tie up - for 
connections that clients close by normal means.


tcpm mailing list