Re: [tcpm] tcpsecure recommendations

"Anantha Ramaiah (ananth)" <> Sun, 10 February 2008 23:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 482143A69B1; Sun, 10 Feb 2008 15:24:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.518
X-Spam-Status: No, score=-3.518 tagged_above=-999 required=5 tests=[AWL=-3.081, 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 ozqo-PsBbgzD; Sun, 10 Feb 2008 15:24:49 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id 932E33A695D; Sun, 10 Feb 2008 15:24:48 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 57CB53A68A8 for <>; Sun, 10 Feb 2008 15:24:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KFUCcL+EZ6RG for <>; Sun, 10 Feb 2008 15:24:46 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 696823A6923 for <>; Sun, 10 Feb 2008 15:24:25 -0800 (PST)
Received: from ([]) by with ESMTP; 10 Feb 2008 15:25:52 -0800
Received: from ( []) by (8.12.11/8.12.11) with ESMTP id m1ANPqKK010524; Sun, 10 Feb 2008 15:25:52 -0800
Received: from ( []) by (8.12.10/8.12.6) with ESMTP id m1ANPp6K002524; Sun, 10 Feb 2008 23:25:51 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Sun, 10 Feb 2008 15:25:51 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Sun, 10 Feb 2008 15:25:36 -0800
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [tcpm] tcpsecure recommendations
Thread-Index: AchsOJnosIYR5+V6T96F7i2HTYU/4wAAN3CQ
References: <><><><><> <>
From: "Anantha Ramaiah (ananth)" <>
To: Joe Touch <touch@ISI.EDU>
X-OriginalArrivalTime: 10 Feb 2008 23:25:51.0534 (UTC) FILETIME=[466B64E0:01C86C3C]
Authentication-Results: sj-dkim-3;; dkim=pass ( sig from verified; );
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


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

"data corruption may result" because it is not the data what the
application intended to receive in the first place. Keeping the focus
intact, the liberal ACK allowed by the RFC has led to this condition
which otherwise would have been prevented. So data corruption can happen
in various places and various layers, we are simply talking about
plugging one hole which is in the jurisdiction of TCP.

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

Agree that the connection might get torn down due to UTO/application
timeout, but why did this happen due to the liberal ACK range allowed.
Now this is what is being debated and the mitigation suggested. 

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

Data plane versus control plane, the distinction becomes blurry when FIN
comes into picture... Not sure how the data/control plane distinction is
made and why it is needed for determining the strength of the
mitigation. You haven't made this clear so far. 

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

Agreed but again the above statement doesn't help in debate which we are
having, ie., the strength of the data mitigation. All so far I can
gather is that : somehow you are saying data mitigation is tied to "data
plane" and the rest are tied to control plane and hence in one case is a
SHOULD and the other a MAY. Sounds very dubious to me.

tcpm mailing list