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

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

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 9343C3A6A84; Mon, 2 Jun 2008 17:42:14 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 598633A682B for <>; Mon, 2 Jun 2008 17:42:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lVV4QX+Fpr8z for <>; Mon, 2 Jun 2008 17:42:12 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B46603A6B07 for <>; Mon, 2 Jun 2008 17:41:20 -0700 (PDT)
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id m530f5Jh026841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Jun 2008 17:41:07 -0700 (PDT)
Message-ID: <>
Date: Mon, 02 Jun 2008 17:41:05 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20080421)
MIME-Version: 1.0
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="===============1874893403=="

Hi, all,

This is, IMO, a signal to review the recommendations in Section 1.1. I 
was always concerned that these mitigations would be misinterpreted as 
applying to hosts in general, which they do not.

The document, IMO, is insufficient in indicating therein that:

	- with source port randomization, the mitigations are not needed
	(port randomization provides a 2^15 strength amplification),
	even presuming source IP addresses are known

	- if source IP addresses are not known, the mitigations are not

	- the mitigations may increase the time needed to respond to
	a legitimate RST, incurring extra RTTs or retransmissions
	vs. an unmodified system

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

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

It seems like these ought to be added, in light of the note below.


Andre Oppermann wrote:
> I'm reworking/refactoring/rewriting the FreeBSD TCP input path (in a separate
> perforce tree at the moment) and in that process I'm evaluating all assumptions
> and test them against a close reading of all relevant RFCs.
> While reading and applying draft-ietf-tcpm-tcpsecure-09.txt I've come across a
> couple of inconsistencies and issues that require further clarification:
> Section 3.2 Mitigation of Blind RST
>   [Real world observation]
>   Some implementations send the RST not on rcv_nxt but on rcv_nxt-1 or
>   rcv_nxt+rcv_win.  Thus we accept three small windows of rcv_nxt(+-1),
>   last_ack_sent(+-1) and rcv_nxt+rcv_win(+-1).
>   Of course the challenge ACK should have the same effect at the expense
>   of another round trip.  While these three (two in case of rcv_nxt == last_ack_sent)
>   do increase the chances of a succesful attack (only every third seq# has to
>   be probed plus the average hit rate is increased due to having two/three
>   different places that match) real world behavior and interop should be
>   considered and discussed.
> Section 4.2 Mitigation of Blind SYN
>   [Possible inconsistency in text]
>   The test in 4.2 eq. 1) is a little different.  In RFC793 it is:
>   in tcpsecure it is described as one byte larger beyond the real window:
>   This seems to be incorrectly transcribed.
> Section 5.2 Mitigation of Blind data injection attack
>   [Clarification]
>   Data that doesn't satisfy the new check in first paragraph MUST be discarded
>   silently. Before RFC793 used to require an ACK to be sent back. This change
>   is not sufficiently explained and lacks an obvious rationale.
>   The second related issue is where this check should be placed relative to
>   RFC793 ordering?  Before the fifth check, last sentence (page 72) "If the ACK
>   acks something not yet sent (SEG.ACK > SND.NXT) then send an ACK, drop the
>   segment, and return." or right after it?  This has implications on the response
>   as tcpsecure requires to silently discard the segment.  If it weren't for the
>   silent discard the new tcpsecure check could simply replace/extend the fifth
>   check from RFC793.
> Feedback appreciated.

tcpm mailing list