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