Re: [sidr] BGPSEC Threat Model ID

[Christopher Morrow <[e-mail]>]

On Fri, Nov 4, 2011 at 10:39 PM, Shane Amante <[e-mail]> wrote:
> Hi Chris,

chello!

> 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).
>

agreed, some manner of prefix + as-path seems like it'd sure solve
this problem. :(

> 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?
>

I agree with some of this sentiment... I think one of the hopes is
that making this simpler over all (knowing that the path you see is
correct & that the prefix-list/as-path filters can be made
automagically) we'll get more BCP deployment. [1][2]

-chris

[1]: ws.edu.isoc.org/data/2006/2134808751448228e3c2055/bgpbcp.ppt
[2]: csrc.nist.gov/publications/nistpubs/800-54/SP800-54.pdf
> -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
>
>