route policy (Re: Public shaming list for ISPs announcing other ISPs IP space by mistake)

[Mikael Abrahamsson <swmike () swm pp se>]

On Wed, 13 Aug 2008, Mikael Abrahamsson wrote:

> How do we hinder this in the short term? I know there are a lot of long 
> term solutions that very few is implementing, but would the fact that 
> these mistakes are brought up into the (lime)light by a public shaming 
> list make ISPs shape up and perform less mistakes?

My thoughts on the prefix filtering issue would be that we need some kind 
of system that works along the same principles as DNSSEC and SPF, ie 
a holder of IP space can publish that they would like everybody to filter 
in a certain way for announcements for that perticular prefix, and then 
the other end can do so if they want to. This needs to be automatic and 
quick, ie a change in RADB policy should be reflected in the real world in 
minutes (preferrably) or hours (more realistically perhaps) and not in 
days or months.

This might already be in place, I don't know other than RIPE, but in RIPE 
you can register a route object with a certain IP space, and IP space can 
have multiple route objects. The thing here is that to implement this 
policy in IOS creates *huge* rulesets that are really cumbersome and 
cluttery. Also, people tend not to rebuild these very often, so for 
customer routes, doing a handover between ISPs when moving PI space might 
involve outages and days of limited connectivity. Also, change of policy 
doesn't isn't reflected unless a route is cleared (soft though) which 
involves re-hashing a lot of routes very often if filters are updated 
often.

I also think that the information in RADB doesn't really contain 
everything I would need in it, so it might need to be extended, but this 
is easier than getting a new framework into our routers (routing policy 
server?) that might work in near realtime. Is there work being done that 
could realistically be implemented anytime soon? Does benefit outweigh the 
potential catastrophies that might happen when rolling out and running 
such a system?

Perhaps it's too late for IPv4 in this aspect, but it might be feasable 
for IPv6? Fewer prefixes and (hopefully) no break-outs, would mean PA 
blocks could be filtered hard, and if larger ISPs do hard filtering based 
on RADB, ISPs getting into IPv6 would need to get their prefixes properly 
registered there before getting IPv6 working to any extent.

Anyhow, as people are continuing to use null routes to enforce regulatory 
demands (likely cause for the latest outages) this problem will most 
likely escalate.

This would also help with <http://eng.5ninesdata.com/~tkapela/iphd-2.ppt> 
problem I guess.

--
Mikael Abrahamsson    email: swmike () swm pp se