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