Re: [sidr] BGPSEC Threat Model ID

[Shane Amante <[e-mail]>]

Hi Chris,

On Nov 4, 2011, at 3:07 PM, Christopher Morrow wrote:
> 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>

The specific route leak noted above would _NOT_ appear if one or more of those AS'es was following what I thought was a "Best Current Practice"[1] of performing AS_PATH filtering for peer ASN's showing up on routes from their customers.  Please note that this is an extremely simple set of 3 lines of config to 'sanity check' inbound routes from customers, (similar to and probably in the same route-map/policy-statement that is, hopefully, rejecting RFC1918 prefixes from customers, as well).

If we can't seem to get the basics right, then how well do we expect a much more complicated set of machinery, which doesn't currently account for this particular scenario anyway, to perform?  Or, to be more sanguine :-), if these BCP's were used, then how much would that reduce the attack surface area, in the _real_ world, that is presently trying to be solved for?

-shane

[1] I wish I could point to an authoritative reference, but I don't recall one.  Perhaps someone with a better memory and/or search skills can find one.


> 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
> _______________________________________________
> sidr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidr