Hi Chris, 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). 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 > [email protected] > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
