Re: BGP-4+
"Dorian R. Kim" <dorian@cic.net> Thu, 19 December 1996 20:47 UTC
Received: from cnri by ietf.org id aa13952; 19 Dec 96 15:47 EST
Received: from merit.edu by CNRI.Reston.VA.US id aa20071; 19 Dec 96 15:47 EST
Received: (from daemon@localhost) by merit.edu (8.8.4/merit-2.0) id PAA07594
for idr-outgoing; Thu, 19 Dec 1996 15:21:51 -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 PAA07531 for <bgp@merit.edu>;
Thu, 19 Dec 1996 15:21:46 -0500 (EST)
Received: by interlock.ans.net id AA28284
(InterLock SMTP Gateway 3.0 for bgp@ans.net);
Thu, 19 Dec 1996 15:21:45 -0500
Received: by interlock.ans.net (Internal Mail Agent-1);
Thu, 19 Dec 1996 15:21:45 -0500
Date: Thu, 19 Dec 1996 15:21:42 -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: <199612192005.MAA11542@toltec.cse.ucsc.edu>
Message-Id: <Pine.GSO.3.95.961219151510.22740C-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: > 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). Permit me to observe here that when there is subverted speaker, change to BGP protocol spec isn't good enough to contain possible damage. > Is this threat considered unlikely enough that it can be ignored? 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. I especially wonder about scalability aspect of such modifications, strictly from an operational perspective. -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