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
- Re: BGP-4+ Yakov Rekhter
- Re: BGP-4+ Susan Hares
- Re: BGP-4+ Susan Hares
- Re: BGP-4+ John W. Stewart III
- Re: BGP-4+ Yakov Rekhter
- Re: BGP-4+ John W. Stewart III
- Re: BGP-4+ Yakov Rekhter
- Re: BGP-4+ Yakov Rekhter
- Re: BGP-4+ Brandon Black
- Re: BGP-4+ John W. Stewart III
- Re: BGP-4+ Dorian R. Kim
- Re: BGP-4+ Yakov Rekhter
- Re: BGP-4+ Tony Bates
- BGP-4+ Dave Katz
- Re: BGP-4+ Dimitry Haskin
- Re: BGP-4+ John W. Stewart III
- Re: BGP-4+ Brad Smith
- Re: BGP-4+ Dorian R. Kim
- Re: BGP-4+ bmanning
- Re: BGP-4+ Tony Li
- Re: BGP-4+ Brad Smith
- Re: BGP-4+ Dorian R. Kim
- Re: BGP-4+ Brad Smith
- Re: BGP-4+ Curtis Villamizar
- Re: BGP-4+ Curtis Villamizar
- Re: BGP-4+ Curtis Villamizar
- Re: BGP-4+ Curtis Villamizar
- Re: BGP-4+ Dennis Ferguson
- Re: BGP-4+ Brandon Black
- Re: BGP-4+ Yakov Rekhter
- Re: BGP-4+ Dennis Ferguson
- Re: BGP-4+ John W. Stewart III
- Re: BGP-4+ Yakov Rekhter
- Re: BGP-4+ Yakov Rekhter
- Re: BGP-4+ John W. Stewart III
- Re: BGP-4+ Yakov Rekhter
- Re: BGP-4+ Geert Jan de Groot
- Re: BGP-4+ Brad Smith
- Re: BGP-4+ [QOS et al] John G. Scudder
- Re: BGP-4+ Paul Traina