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

* Jared Mauch · * Thu Aug 14 08:19:33 2008

On Thu, Aug 14, 2008 at 08:03:28AM +0200, Mikael Abrahamsson wrote:
> 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.

	There was an idea years ago about utilizing a domain (rdi.int) for
this.

	eg:

	dig any 267.rdi.int.

> 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  

	Herein is the value, the RIR (RIPE) is also the holder of the policy.
With ARIN, this is not the case, there is RADB and a number of other RR's
that are out there for varying reasons, some personal and some business.

> 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 think in this web 2.0 world, everything you're speaking of
can be a challenge but not be impossible.  The problem I see is there are
no good tools.  Take http://prefix.pch.net/ for example.

	This can help you audit the routes that are going to be placed
in a prefix-list.  How do you integrate something like this into your
business policy?  Have customers submit a web form for their routes?  It's
easy when your customer is AS267, but what if your customer is something
larger like telstra?

> 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  

	I think it's a matter of having a semi-uniform industry policy
that is generally agreeable.  I don't want to see the ANS-days case where
you could not route without RADB and some fancy scripts probing their bay
networks devices with snmp sets.

	But I do agree that we need a better toolset built.  Now
the question is, who can/will do this?  How can it be shared?

	If I can make this backend uglyness called "RADB/irrd" invisible
to my customers, will that help?

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

	Yeah, the challenge here is those that are unwilling to take
action threaten the entire industry as it only takes a few bad actors
to disrupt the network currently, and if you do it correctly, who is
going to trust the infrastructure that we operate?

	- Jared

-- 
Jared Mauch  | pgp key available via finger from [email protected]
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.