We hit half-million: The Cidr Report

Jérôme Nicolle jerome at ceriz.fr
Wed Apr 30 20:55:05 UTC 2014


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




More information about the NANOG mailing list