RE: [tcpm] tcpsecure: how strong to recommend?

"Anantha Ramaiah \(ananth\)" <ananth@cisco.com> Wed, 26 September 2007 14:42 UTC

Return-path: <tcpm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaY5y-0002rp-3z; Wed, 26 Sep 2007 10:42:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaY5w-0002ra-UK for tcpm@ietf.org; Wed, 26 Sep 2007 10:42:32 -0400
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaY5v-0003p0-Ml for tcpm@ietf.org; Wed, 26 Sep 2007 10:42:32 -0400
X-IronPort-AV: E=Sophos;i="4.20,302,1186383600"; d="scan'208";a="20089643"
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 26 Sep 2007 07:42:31 -0700
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l8QEgVOZ026903; Wed, 26 Sep 2007 07:42:31 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8QEgUWO019463; Wed, 26 Sep 2007 14:42:30 GMT
Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Sep 2007 07:41:53 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [tcpm] tcpsecure: how strong to recommend?
Date: Wed, 26 Sep 2007 07:41:52 -0700
Message-ID: <0C53DCFB700D144284A584F54711EC5804052052@xmb-sjc-21c.amer.cisco.com>
In-Reply-To: <E1IaVI6-0005N1-00@alva.home>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [tcpm] tcpsecure: how strong to recommend?
Thread-Index: AcgAMx227pTakmMpTgi2Vowi/IMTbQAFICOg
From: "Anantha Ramaiah \(ananth\)" <ananth@cisco.com>
To: "Tim Shepard" <shep@alum.mit.edu>, "Joe Touch" <touch@ISI.EDU>
X-OriginalArrivalTime: 26 Sep 2007 14:41:53.0199 (UTC) FILETIME=[611E6BF0:01C8004B]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3356; t=1190817751; x=1191681751; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20\(ananth\)=22=20<ananth@cisco.com> |Subject:=20RE=3A=20[tcpm]=20tcpsecure=3A=20how=20strong=20to=20recommend ?=20 |Sender:=20; bh=SV2po3OJpZwtXTZJH8SnceoCVt3wiNbVhvfkPrpHaVE=; b=FJy6dHo9cIwAdbqukkt+lhAYoOtuWtjg7Xr80rFrcCwQUaPziU1q0GsAmOVZwtnjRSw+HTih MEXtsySfa7sM4vsDo/B65vWiTyzyNUIBktFPL38n2gRmrBxWiCOe8o2A;
Authentication-Results: sj-dkim-4; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; );
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
Cc: tcpm@ietf.org
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Errors-To: tcpm-bounces@ietf.org

Few points :-

- It is true that TCP secure recommendations might be useful for long
lived sessions like BGP. But there are many applications using TCP which
also could benefit from the proposed changes. The TCP secure changes
needs to be viewed as a standalone thing, since it focusses in providing
robustness to TCP connections w.r.t some spoofing attacks. 

- TCP secure changes are not going to solve the "world hunger problem".
Ipsec and TCP secure are completely orthogonal since Ipsec is generic
security solution with it's own pros and cons whereas TCP secure
attempts to illustrate some known issues w.r.t some TCP spoofing attacks
and proposes mitigations to the same.

- The WG is also talking about replacing the TCP MD5 with a more generic
TCP security algorithms. This came out of the need to provide security
at layer 4. I know some people would dis-agree but that is a different
story.

- TCP secure, TCP MD5, TCP advanced security algorithms, IPsec are all
different tools with varying degrees of complexity and usage. A user can
chose to use one of them depending on his/her requirements. Telling
people to only use IPsec is akin to saying "always fly in business
class". Yes I have used this analogy before, but this is one whih popped
up in mind after today's coffee :-)

So, I would not draw some comparisions between TCP secure and other
"security" solutions including BTNS etc., These need to be viewed upon
independently.

Well, I am speaking out of experience resulting from dealing with
working on many products which use TCP and confronting the differing
requirements imposed by those, so needless to say, OMMV.

-Anantha

> 
> > > How's BTNS coming along?   Will we be seeing BGP over 
> BTNS anytime soon?
> > > (I've not been following BTNS too closely recently).
> > 
> > See the Goals and Milestones at:
> > http://www.ietf.org/html.charters/btns-charter.html
> 
> 
> Cool.  But that is only a (partial) answer to my first 
> question.  From the status of Goals and Milestones on that 
> IETF WG charter page, I cannot tell if the result of the BTNS 
> WG is something that is sufficiently far along that "go do 
> BTNS" is a viable alternative to this "tcpsecure" draft.  
> Presumably I could read all the drafts that are there and 
> form my own opnion, but the queue of things that I ought to 
> read soon is much deeper than what I will be able to read soon.
> 
> (For those attempting to follow along... I believe the need 
> that  triggered this tcpsecure draft was also (one of?) the 
> trigger(s) that
>  led to the BTNS WG effort.    This tcpsecure draft is a collection of
>  hacks (which appear to solve the problems as we understand 
> them now)  while the BTNS effort was started in an attempt to 
> solve the problem  in an architecturally correct and more robust way.)
> 
> At some point there's a decision to be made, recommend what's 
> in the tcpsecure draft, or recommend what BTNS has produced.
> 
> So I ask: is BTNS succeeding such that it is a viable 
> alternative to this tcpsecure draft?
> 
> 			-Tim Shepard
> 			 shep@alum.mit.edu
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www1.ietf.org/mailman/listinfo/tcpm
> 

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm