Re: BGP-4+

"Dorian R. Kim" <dorian@cic.net> Thu, 19 December 1996 22:44 UTC

Received: from cnri by ietf.org id aa16036; 19 Dec 96 17:44 EST
Received: from merit.edu by CNRI.Reston.VA.US id aa23264; 19 Dec 96 17:44 EST
Received: (from daemon@localhost) by merit.edu (8.8.4/merit-2.0) id RAA14373 for idr-outgoing; Thu, 19 Dec 1996 17:24:55 -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 RAA14368 for <bgp@merit.edu>; Thu, 19 Dec 1996 17:24:52 -0500 (EST)
Received: by interlock.ans.net id AA03183 (InterLock SMTP Gateway 3.0 for bgp@ans.net); Thu, 19 Dec 1996 17:24:50 -0500
Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 19 Dec 1996 17:24:50 -0500
Date: Thu, 19 Dec 1996 17:24:47 -0500 (EST)
From: "Dorian R. Kim" <dorian@cic.net>
To: Brad Smith <brad@cse.ucsc.edu>
Cc: bgp@ans.net
Subject: Re: BGP-4+
In-Reply-To: <199612192208.OAA11834@toltec.cse.ucsc.edu>
Message-Id: <Pine.GSO.3.95.961219171259.22740P-100000@nic.hq.cic.net>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-idr@merit.edu
Precedence: bulk

On Thu, 19 Dec 1996, Brad Smith wrote:

> > Permit me to observe here that when there is subverted speaker, change to BGP
> > protocol spec isn't good enough to contain possible damage.
> 
> This is certainly the challenge; however, I think, if you take the
> perspective of minimizing or eliminating what a speaker can say
> about resources it doesn't have authority for, you can go a long
> way toward containing damage.

This seems to involve authentication AND authorization, and some manner in
which both can be independently verified. This too me is an absolutely
non-trivial set up, and I seriousl question the scalability of it. It would 
also IMO, imposes significant restrictions in routing flexibility.
Furthermore, this type of scheme is very likely to show operationally
unacceptable failure modes during network failures unless we someone come up
with completely out-of-band signaling. 

> > While this threat is not that unlikely and should not be ignored, my view on
> > this is that the prevention should take the form of speaker/host hardening
> > rather than modification of BGP transport.
> 
> Hardening involves procedures and people in addition to technology; what
> you say implies imposing significant restrictions on who can operate a
> BGP speaker to achieve any significant improvements in security.  Is this
> realistic?

Sure, you have to start from simple physical access to people to boxes and
bits. And then there is a point where you draw the line between manageability
and security. Routers can be protected better than they are currently
protected in most places without incurring too much of an overhead, human or
otherwise.

> > I especially wonder about scalability aspect of such modifications, strictly
> > from an operational perspective.
> 
> Absolutely.  This is the final measure... is the illness more painful
> than the cure.  It is certainly going to be quite painful.

I suspect that the cure's side affect will make it unpalatable.

-dorian