Re: [sidr] BGPSEC Threat Model ID

[Shane Amante <[e-mail]>]

Hi Chris,

On Nov 4, 2011, at 8:56 PM, Christopher Morrow wrote:
>> 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. :(

Please note that, for the specific case above, I did not mention "complicated" & "burdensome" prefix-list filtering … just AS_PATH sanity check filtering, i.e.: if you see AS (FOO|BAR|BAZ) in the path, drop (don't learn) the route.  Also, I would note that this type of configuration re-emphasizes what Russ White has said, specifically that (this) policy is local to each AS and is _not_ 'shared' with any other ASN.


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

Thanks for the pointers … now I need to go read them.  :-p

-shane


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