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

Joe Touch <touch@ISI.EDU> Tue, 03 June 2008 03:20 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 520563A6AC8; Mon, 2 Jun 2008 20:20:28 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3298B3A6A33 for <>; Mon, 2 Jun 2008 20:20:26 -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 nAYquMvhXAQe for <>; Mon, 2 Jun 2008 20:20:25 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 02E7C3A6B63 for <>; Mon, 2 Jun 2008 20:18:23 -0700 (PDT)
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id m533IEgO007547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Jun 2008 20:18:16 -0700 (PDT)
Message-ID: <>
Date: Mon, 02 Jun 2008 20:18:13 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20080421)
MIME-Version: 1.0
To: "Anantha Ramaiah (ananth)" <>
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="===============2057998244=="

Anantha Ramaiah (ananth) wrote:
>> 	- with source port randomization, the mitigations are not needed
>> 	(port randomization provides a 2^15 strength amplification),
>> 	even presuming source IP addresses are known
> Source port randomization is one way of adding robustness and does not
> every situation. Also you can't assume everyone is doing src port
> randomization. 

No, you cannot. The responsibility for protecting the session then falls 
to the side that initiates it (fair territory, IMO), rather than the 
side that receives the RST (which is arbitrary).

> Even then having these mitigations would make the attacks
> described in the document harder to accomplish.

Agreed that it makes the attacks still harder, but if they're already 
hard enough, then the mitigations aren't needed.

>> 	- if source IP addresses are not known, the mitigations are not
>> 	needed
> I think this is very obvious in the document. Right from the intro which
> talks about the attack vectors, and what is needed to accomplish the
> attack. 
>> 	- the mitigations may increase the time needed to respond to
>> 	a legitimate RST, incurring extra RTTs or retransmissions
>> 	vs. an unmodified system
> Yes, this is obvious too due to the challenge ACK being sent.
>> 	- the mitigations are not a substitute for network or
>> 	transport authentication, either of which obviate the need
>> 	for the mitigations (yes, this is noted in the security
>> 	considerations, but it's buried w.r.t. applicability)
> Oh, the way I read the draft the above fact is mentioned all over the
> draft.. I can point out all the places if you want, but we have been
> thru this before and I have incorporated the feedback received from you
> but I am surprised that you are bringing this one up now.

I noted below why I am raising it now (the FreeBSD note).

>>   - the mitigations protect only off-path attacks; on-path
>> 	attacks, such as ISPs shutting connections down deliberately,
>> 	are not prevented by this mitigation (yes, also noted
>> 	in security considerations, but again worth noting in
>> 	applicability, and worth adding the ISP example, IMO)
> Well, I would think that we generally don't want to repeat the same text
> all over the document again and again, but if the work group believes in
> this redundancy as you semm to do, I am more than willing to add it. 

I don't think it's huge; it is just a summary of - as you note - 
information noted elsewhere.


tcpm mailing list