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

Joe Touch <touch@ISI.EDU> Wed, 26 September 2007 14:02 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 1IaXTL-0000VJ-VN; Wed, 26 Sep 2007 10:02:39 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaXTK-0000Ur-Nn for tcpm@ietf.org; Wed, 26 Sep 2007 10:02:38 -0400
Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaXTK-00083Z-64 for tcpm@ietf.org; Wed, 26 Sep 2007 10:02:38 -0400
Received: from [192.168.1.39] (pool-71-106-89-188.lsanca.dsl-w.verizon.net [71.106.89.188]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l8QE1ufj025454; Wed, 26 Sep 2007 07:01:56 -0700 (PDT)
Message-ID: <46FA664A.1050803@isi.edu>
Date: Wed, 26 Sep 2007 07:01:46 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Tim Shepard <shep@alum.mit.edu>
Subject: Re: [tcpm] tcpsecure: how strong to recommend?
References: <E1IaVI6-0005N1-00@alva.home>
In-Reply-To: <E1IaVI6-0005N1-00@alva.home>
X-Enigmail-Version: 0.95.3
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024
Cc: tcpm@ietf.org, "Mitesh Dalal \(mdalal\)" <mdalal@cisco.com>, mallman@icir.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>
Content-Type: multipart/mixed; boundary="===============1231014734=="
Errors-To: tcpm-bounces@ietf.org


Tim Shepard wrote:
>>> 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.)

FWIW:

tcpsecure reduces the impact of attacks on TCP that presume knowledge of
the socket pair (src/dst IP, src/dst port), the impetus of which was
attacks on BGP

as noted in RFC4953 (antispoof) discusses protections for such services,
and more direct protections using authentication mechanisms such as
TCP/MD5 (which we have a group revising - stay tuned...) and IPsec.

IPsec is sometimes not used in routers because of the need to configure
preshared keys or certificate authority information; BTNS enables IPsec
without either

BTNS has a large number of potential uses beyond BGP, though. TCP/MD5
and its alternates - despite the formers similar need for preshared keys
- may be more likely to be more widely used for the BGP case.

I.e., as was noted in antispoof, there are many ways to address this
problem, and the problem is of impact only for certain connections.

> At some point there's a decision to be made, recommend what's in the
> tcpsecure draft, or recommend what BTNS has produced.

Or the successor to TCP/MD5, or existing IPsec - and that recommendation
will probably involve collaboration with the Security Area.

> So I ask: is BTNS succeeding such that it is a viable alternative to
> this tcpsecure draft?

One of many alternatives, yes. The only alternative, no.

Joe

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