Re: [tcpm] tcpsecure recommendations

Joe Touch <touch@ISI.EDU> Sun, 10 February 2008 22:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BFBFD3A695E; Sun, 10 Feb 2008 14:57:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.707
X-Spam-Status: No, score=-0.707 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GYJFN6JPw5Rc; Sun, 10 Feb 2008 14:57:58 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id BE0DC3A6890; Sun, 10 Feb 2008 14:57:58 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id BDD0B3A68D5 for <>; Sun, 10 Feb 2008 14:57:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7ig3K74hnph2 for <>; Sun, 10 Feb 2008 14:57:56 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id EBC0C3A686B for <>; Sun, 10 Feb 2008 14:57:55 -0800 (PST)
Received: from [] ( [] (may be forged)) by (8.13.8/8.13.8) with ESMTP id m1AMx7gA011731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 10 Feb 2008 14:59:08 -0800 (PST)
Message-ID: <>
Date: Sun, 10 Feb 2008 14:58:58 -0800
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20071031)
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] tcpsecure recommendations
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hash: SHA1

Anantha Ramaiah (ananth) wrote:
| Actaully it is not a "stream" of forged segments. A malicious segment
| (which utilizes the liberal range of ACK value) can come and occupy any
| place within the receive window, it could be in the re-assembly queue/or
| somewhere inline, but this just like a "time-bomb' waiting to explode.

There are three issues listed in the ID:

"Blind reset attack using the RST bit"
"Blind reset attack using the SYN bit"
"Blind data injection attack"

The third one says "data corruption may result" - IMO, data corruption
is a possibility any time you don't use strict authentication, so it's
inaccurate to imply that if these checks are in place that data
corruption won't occur (which is what is implied, IMO).

The ACK war doesn't take down the connection. What takes down the
connection is that it accepted data it shouldn't have. IMO, the UTO
taking the connection down at this point is not as much an attack
succeeding, as it is TCP succeeding in not letting the attack go unnoticed.

Again, I don't see this case as needing a SHOULD. This is a data plane
issue, not, IMO, a control plane one.

| Data injection is about strict ACK checking and applies to FIN segments.
| To re-iterate: preventing anything which causes the connection tear down
| maliciously is critical. So it could be a RST/SYN or Data or FIN.

If preventing anything that could cause a malicious teardown is
critical, then use of strict authentication is required. Implications to
the contrary endorse the use of this "protocol robustness" mechanism for
true security (a misconception that the title doesn't help abate).

- ---

Also, FWIW, Section 9 doesn't appear to address the non-amplification
ACK exchange issue promised in the end of each of the previous sections.


Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla -

tcpm mailing list