Re: [tcpm] tcpsecure recommendations

"Anantha Ramaiah (ananth)" <> Sun, 10 February 2008 19:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6B7933A68D5; Sun, 10 Feb 2008 11:37:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TAIqVOhNpfjf; Sun, 10 Feb 2008 11:37:06 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id 95B5E3A68E5; Sun, 10 Feb 2008 11:37:05 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0BDB63A68E4 for <>; Sun, 10 Feb 2008 11:37:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0psfswiC7Cqd for <>; Sun, 10 Feb 2008 11:37:04 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id DED143A68E9 for <>; Sun, 10 Feb 2008 11:36:42 -0800 (PST)
Received: from ([]) by with ESMTP; 10 Feb 2008 11:38:09 -0800
Received: from ( []) by (8.12.11/8.12.11) with ESMTP id m1AJc9jF013861; Sun, 10 Feb 2008 11:38:09 -0800
Received: from ( []) by (8.12.10/8.12.6) with ESMTP id m1AJb46B015707; Sun, 10 Feb 2008 19:38:09 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Sun, 10 Feb 2008 11:38:08 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Sun, 10 Feb 2008 11:37:53 -0800
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [tcpm] tcpsecure recommendations
Thread-Index: AchsDNkM6Sw0keyTQ0GYzmSJxnLOnQACSU/A
References: <> <> <> <>
From: "Anantha Ramaiah (ananth)" <>
To: Joe Touch <touch@ISI.EDU>
X-OriginalArrivalTime: 10 Feb 2008 19:38:08.0565 (UTC) FILETIME=[76A7C650:01C86C1C]
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

> The key issues are:
> - - lack of protection against injected data itself (I'm not 
> sure if the doc actually calls this out specifically; it 
> probably should in the security considerations section - even 
> an off-path attacker can do this,
> e.g.)

There are references to IPsec and MD5 etc., in the security section. I
think all the above is implied and understood. Like it has been
emphasised before many times, the purpose of TCP secure is to add
robustness to some cases and not to replace IPsec/MD5.

> - - the word "eventually" above
> IMO, if you are running a TCP connection that is susceptible 
> to attacks only by a *stream* of forged segments, you 
> probably ought to use something besides TCP-secure as protection.

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.
[The document mentions these possibilities under the data injection
section] Also as mentioned in the document FIN attacks are also possible
which is a control plane thingy ( using your terminology)

> As a result, I think that you SHOULD protect the control 
> plane (if you employ this technique), but that protection of 
> attacks via data plane volume are not as critical, and thus a MAY.

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.

But if your point is the mitigation should not be called as "data
injection" and something else, I agree. OTOH, the assumption is that any
implementer (true for any RFC) is going to read and understand that
tcp-secure provides adds robustness in some cases and for a
comprehensive data/control protection one is going to use MD5/Ipsec.
Like I pointed out earlier many times tcp-secure is not an
authentication mechanism and lot of folks agree to that, but you seem to
thinking this as an authentication mechanism and with that line of
thinking, your reasoning is fine, but the basic point is tcp-secure is
NOT a authentication mechanism, it is about protocol robustness :-) 

tcpm mailing list