Patrick, Le 30/04/2014 16:54, Patrick W. Gilmore a écrit :
It's fairly easy to punch a hole in a larger prefix, but winning the reachability race while unable to propagate a more specific prefix significantly increase hijacking costs.
Excellent point, Jérôme.
Let's make sure nothing is hijack-able. Quick, let's de-agg -everything- to /24s. Everyone's routers can sustain > 10 million prefixes per full table, right? Jérôme, how many prefixes can your routers handle?
Or we could stop thinking that abusing a shared resource for personal gain is a great idea.
I totally agree with you. It's a shame to have to consider bad practices from a network perspective as necessities from a security standpoint. That beeing said, let's try to consider adverse interests on that matter. Large routing tables are an issue for smaller networks generating less value than major players usually providing transits to others. The constant growth of the routing table gives a technical and economical advantages to established carriers (roughly the same arguing OTTs _must_ pay premium PNIs because of an arbitrary ratio-driven peering policy). The necessity for higher-end routers to provide transit services could also slow down the steep fall of transit prices. It would establish a sensible barrier to newcomers on local transit services. It's also reducing the value of older equipments and killing the grey-market and brokers. Well, the power-draw of 6500's and other oldies could be enough, but their unability to scale to today's standards helps newer hardware sales. Now there would be a smart way to handle the issue with SDN. A "smart" network controler could manage a larger RIB with ease and provide routing-ASICs with a virtualy agregated FIB much smaller than the previous 256k routes limit, thus creating more interest for older routing-switches. Would a manufacturer develop such a smart conroller ? Nah, let's sell bigger overpriced TCAMs instead. Oh, and of course, the argument about hijack-prevention would disapear if everyone was doing there part and deploy RPKI in a matter of weeks. As did everyone feel the responsability to deploy IPv6, for that matter.
See my previous post. Of course deaggregation can have a use, but for a network is no peering an one or a few transits, those more specifices never have to hit the global table. Sending that /24 to your transit provider(s) with no-export will have the _exact_same_effect_, and not pollute anyone's routers whom you are not paying.
I'm not sure we're on the same page here. De-agregating with a no-export tag will have no effect at all but on TE between the orinating AS and its transit provider. If the more specific prefix isn't propagated, a hijack may occur locally anywhere else on the Internet. Let's consider someone willing to intercept mails from major hosted services (gmail, outlook...) to a company connected through bad transits. The hijacker would simply announce the more specific prefix on a few IXPs and win the reachability. The backchannel route could then be established over any other T1 (who won't pick up the more-specific anyway). Simply put, you have to be no more than one hop away from most IXPs to get a decent hijack-proof reachability. De-agg with no-export is a nonsense.
The idea "I have a 'reason' for hurting everyone else, so it is OK" has got to stop. Just because you have a reason does not make it OK. And even when it is a good idea, most people implement it so poorly as to cause unneeded harm.
Alright, let's implement new policies at a RIR, IXPs and T1s levels to forbid anyone from de-agregation without no-exports. Culprits would fall under a three-strike policy before definitive de-peering and public humiliation. Who's with me ? :) -- Jérôme Nicolle