Re: BGP-4+
Tony Li <tli@jnx.com> Thu, 19 December 1996 22:25 UTC
Received: from cnri by ietf.org id aa15805; 19 Dec 96 17:25 EST
Received: from merit.edu by CNRI.Reston.VA.US id aa22816; 19 Dec 96 17:25 EST
Received: (from daemon@localhost) by merit.edu (8.8.4/merit-2.0) id RAA11702
for idr-outgoing; Thu, 19 Dec 1996 17:04:22 -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 RAA11697 for <bgp@merit.edu>;
Thu, 19 Dec 1996 17:04:18 -0500 (EST)
Received: by interlock.ans.net id AA02405
(InterLock SMTP Gateway 3.0 for bgp@ans.net);
Thu, 19 Dec 1996 17:04:17 -0500
Received: by interlock.ans.net (Internal Mail Agent-2);
Thu, 19 Dec 1996 17:04:17 -0500
Received: by interlock.ans.net (Internal Mail Agent-1);
Thu, 19 Dec 1996 17:04:17 -0500
Date: Thu, 19 Dec 1996 14:03:35 -0800 (PST)
Message-Id: <199612192203.OAA23260@chimp.jnx.com>
From: Tony Li <tli@jnx.com>
To: "Dorian R. Kim" <dorian@cic.net>
Cc: bgp@ans.net
Subject: Re: BGP-4+
References: <199612192005.MAA11542@toltec.cse.ucsc.edu>
<Pine.GSO.3.95.961219151510.22740C-100000@nic.hq.cic.net>
Sender: owner-idr@merit.edu
Precedence: bulk
> 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. True. In fact, Radia Perlman has looked at the subverted speaker problem quite a bit. It turns out that you basically need a link state protocol to disseminate enough information to still have a functioning network. And the cost in redundancy and additional computation is non-trivial. It's a major architectural change, which I haven't seen any willingness to pay for either in the enterprise market or in the Internet backbone. Tony
- 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