Re: BGP-4+

Brad Smith <brad@cse.ucsc.edu> Thu, 19 December 1996 20:42 UTC

Received: from cnri by ietf.org id aa13908; 19 Dec 96 15:42 EST
Received: from merit.edu by CNRI.Reston.VA.US id aa19955; 19 Dec 96 15:42 EST
Received: (from daemon@localhost) by merit.edu (8.8.4/merit-2.0) id PAA06876 for idr-outgoing; Thu, 19 Dec 1996 15:07:04 -0500 (EST)
Received: from interlock.ans.net (interlock.ans.net [147.225.5.5]) by merit.edu (8.8.4/merit-2.0) with SMTP id PAA06867 for <bgp@merit.edu>; Thu, 19 Dec 1996 15:07:00 -0500 (EST)
Received: by interlock.ans.net id AA27845 (InterLock SMTP Gateway 3.0 for bgp@ans.net); Thu, 19 Dec 1996 15:06:49 -0500
Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 19 Dec 1996 15:06:49 -0500
Message-Id: <199612192005.MAA11542@toltec.cse.ucsc.edu>
To: "Dorian R. Kim" <dorian@cic.net>
Cc: Yakov Rekhter <yakov@cisco.com>, Susan Hares <skh@merit.edu>, dkatz@cisco.com, bgp@ans.net
Subject: Re: BGP-4+
In-Reply-To: Your message of "Wed, 18 Dec 1996 18:56:52 EST." <Pine.GSO.3.95.961218185104.27290C-100000@nic.hq.cic.net>
Date: Thu, 19 Dec 1996 12:05:35 PST
From: Brad Smith <brad@cse.ucsc.edu>
Sender: owner-idr@merit.edu
Precedence: bulk

> > > 2) Security Considerations
> > > Is it your understanding that users need this security or is
> > > TCP good enough?
> > 
> > I would like to get a feedback from the WG on this question.
> 
> While security is a concern, I don't think we need in-protocol security
> support. IMO, the best place to apply effort is in securing TCP, where we
> already have tools at our disposal.
> 
> -dorian

A comment and question.  TCP and similar peer-to-peer security does
not protect against a subverted speaker.  If an intruder is able to
break into a speaker, where it would get access to all TCP security
related keys, it would then be able to have it's way with the protocol
(e.g. fabricate, modify, and replay routing information).

Is this threat considered unlikely enough that it can be ignored?

I've been working on countermeasures to this subverted speaker threat,
and it seems that it requires changes to the protocol.

Brad Smith
Computer Sciences
UC Santa Cruz

PS - A related question.  Has anyone looked into whether IP-SEC
     mechanisms secure TCP?  I started looking at this, and it
     seemed that IP-SEC went a long way, but maybe not all the
     way to securing TCP...