On Fri, Nov 4, 2011 at 10:39 PM, Shane Amante <[email protected]> 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 <[email protected]> >> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/sidr > > _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
