ARIN / RIR Pragmatism (WAS: Re: RADB)

Sat Oct 25 12:38:49 UTC 2014

On 2014-10-24 15:24, Christopher Morrow wrote:

> it seems to me that there are a couple simple issues with IRR data
> (historically):
>   1) no authority for it (really, at least in the ARIN region)
>   2) no common practice of keeping it updated
>   3) proxy-registration issues (probably part of cleanup and 
> authority issues)
>   4) lack of widespread use due to the above issues.

I think that's a subset of the issues.  Those and others are captured 
here:

<https://tools.ietf.org/html/draft-ietf-grow-irr-routing-policy-considerations-05>

Ironically, many of the issues that lead to decay in IRR use have been 
resolved, while others exist in RPKI, even.

Baldur's RIPE IRR point is a fair one and worthy of consideration, I'm 
all for low-hanging fruit.

> I was/am hopeful that providing some path from IANA (eventually) on
> down through RIR to LIR to end-user for 'authority to use' ip
> resources would help in letting people use the IRR data cleansed of
> insanity by the data from this path, and then into routers for route
> filters.

And datapath filters for inter-domain anti-spoofing, perhaps, as it's 
largely the same policy (I know there are corner cases people that don't 
want to do this point out).

> The RPKI system looks like the path in question, to me.

I know you're an RPKI fan, I'm at peace with that :-)

However, unless you can fortify the systems that RPKI (or any other 
resource certification infrastructure) would inform, operators have 
little incentive to use it as all the systems that are already deployed 
and still have to use (e.g., whois, in-addr.arpa, IRR, etc.) still have 
to be used and managed and operated.   RPKI adds considerable 
complexity, costs, scaling challenges, new external dependencies, etc..  
I actually think it'd have been a challenge to design something _more 
complicated than RPKI to address the problem space, but that's just me.

-danny