Re: [sidr] BGPSEC Threat Model ID

[Christopher Morrow <[e-mail]>]

On Fri, Nov 4, 2011 at 3:05 PM, Eric Osterweil <[e-mail]> wrote:
>
> This is a list of three questions.  Until there is discussion of the first, it is premature to address the second two.  Therefore, how about we just choose a specific case of the first: how would BGPSec protect against an instance of an event found here:
>        http://puck.nether.net/bgp/leakinfo.cgi
>

I'm not randy, but I was talking about this very thing in the office
today with a co-worker... I'm not clear on how anything can stop an
instance like:
src      time                                        prefix
puck	2011-11-04 16:15:49.157742	8.10.160.0/23	
   path
   2914 2828 12989 12189 3356 19181 19181 19181
  Contact   score  blame_asn
   2828	3	12989

As I read this, 12989 (highwind) is 'accidentally' announcing
reachability for 8.10.160.0/23 (CWIE? AS19181). Looking at one popular
source of routing data:
  <http://www.robtex.com/as/as19181.html>

it actually seems that the 2 people may be peers :( the route that we
see is merely an artifact of their connectivity and 'poor route
selection' inside their networks :(

Point being that in cases like this (or really all route leak cases)
the only thing that stops this is filtering routes between bgp peers.
(transits, customers, SFP peers) There isn't anything in the protocol
itself (which is Stephen's, Russ's, Randy's comment through out) that
tells you/me/them that 12989 should not be permitted to announce this
route. (looking at available data, it seems that they SHOULD, perhaps
not with this ASPath, but...)

How would you go about telling, from the data on the wire in bgp, that
a route is a hijack?
How would you propose changing the data on the wire in bgp today to do
this tomorrow?

Would having data you could mechanically verify about the routes and
origins and relationships (say connectivity only?) between bgp peers
help solve this problem?

In my view I don't see a change to the BGP wire format helping, I do
see existence of data to mechanically verify ownership (and perhaps
connectivity information?) helping.

-chris