ARIN / RIR Pragmatism (WAS: Re: RADB)

Sandra Murphy sandy at tislabs.com
Thu Oct 23 21:02:41 UTC 2014


> IRR usage, training, tools, and better hygiene, perhaps expressly validated from resource certification from either RPKI

You might be interested in the draft-ietf-sidr-rpsl-sig-05.txt, which suggests using RPKI to protect RPSL objects.

That would help solve the trust problem in the current IRR world, which is that most IRRs can't tell if the object being registered is authorized.  RIPE and, I think, APNIC being the exception, for their region resources.  Lots of proxy registered objects aren't a good sign.

--Sandy


On Oct 23, 2014, at 2:26 PM, Danny McPherson <danny at tcb.net> wrote:

> <soapbox>
> 
> I think the routing system would be in a much happier [less bad] place if only had a minor amount of the energy and resources that USG (and RIRs) have been put towards RPKI and BGPSEC (i.e., IETF SIDR work) would have been redirected to lower hanging fruit and better recognizing / leveraging existent systems and operational practices (e.g., more IRR usage, training, tools, and better hygiene, perhaps expressly validated from resource certification from either RPKI or in-addr.arpa, etc).  Given that many of the same derived "policies" there could also be employed for inter-domain datapath anti-spoofing (BCP38-ish inter-domain) and that all the existing machinery and practices already deployed could more easily accommodate this in the near term, it seems only natural to me.
> 
> As for the visionaries playing the long game, they've made progress, but surely the only way to get there is with more incremental "putty" and small practical steps to fill the gaps at this point.
> 
> </soapbox>
> 
> I for one would like to see ARIN (as well as other RIRs and the adjacent community) invest more pragmatically in this area, particularly given the governance climate and other externalities at play these days.
> 
> Alas,
> 
> -danny
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20141023/d5929145/attachment.sig>


More information about the NANOG mailing list