Re: BGP-4+
Brad Smith <brad@cse.ucsc.edu> Tue, 24 December 1996 06:07 UTC
Received: from cnri by ietf.org id ae16908; 24 Dec 96 1:07 EST
Received: from merit.edu by CNRI.Reston.VA.US id aa22196; 23 Dec 96 20:10 EST
Received: (from daemon@localhost) by merit.edu (8.8.4/merit-2.0) id TAA17327
for idr-outgoing; Mon, 23 Dec 1996 19:47:29 -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 TAA17322 for <bgp@merit.edu>;
Mon, 23 Dec 1996 19:47:25 -0500 (EST)
Received: by interlock.ans.net id AA21629
(InterLock SMTP Gateway 3.0 for bgp@ans.net);
Mon, 23 Dec 1996 19:47:24 -0500
Received: by interlock.ans.net (Internal Mail Agent-1);
Mon, 23 Dec 1996 19:47:24 -0500
Message-Id: <199612240047.QAA01031@toltec.cse.ucsc.edu>
To: Geert Jan de Groot <GeertJan.deGroot@ripe.net>
Cc: bgp@ans.net
Subject: Re: BGP-4+
In-Reply-To: Your message of "Mon, 23 Dec 1996 17:07:07 +0100."
<9612231607.AA02505@ncc.ripe.net>
Date: Mon, 23 Dec 1996 16:47:10 PST
From: Brad Smith <brad@cse.ucsc.edu>
Sender: owner-idr@merit.edu
Precedence: bulk
> I think you need to re-focus your question. What are you trying to protect? > a. RST-attachs to BGP sessions and such, including spoofing of BGP data? > IPSEC-AH will fix that in an exportable manner.. > b. People knowingly and willingly injecting false routes (such as host route) > to play games with traffic? > That's a much harder problem and IMHO that would be out of scope for > BGP4++ > > I think you'll get more useful answers if you post your questions that way. > What do others think? I agree. Addressing (a) is pretty straight-forward and protects you from "outside" attackers (masquerading speakers, unauthorized speakers, and subverted links). Addressing (b) is non-trivial and protects you from subverted speakers. (a) is pretty well understood, with reasonably effective and efficient solutions available; (b) is less well understood, and there are no adequately efficient solutions available. Asking if secure TCP or similar mechanisms is sufficient for addressing the threat (a) is straight-forward (I'd answer yes; I'd also be interested in seeing an analyisis of how IPSEC accomplishes the same goal... although the claim that it does sounds right to me). The same question for (b) would be answered no. Brad
- 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