Re: irrd 4.1.2 deployed at NTT

[Randy Bush <randy () psg com>]

> this change means that NTT's IRR mirror service will now use RPKI
> Validated ROAs to filter out invalid IRR objects! This filtering
> strategy is similar to RIPE-731.
>
> Creation of RPKI ROAs will trigger deletion of conflicting IRR
> objects, this helps clean up stale objects. Existing RPKI ROAs help
> prevent future creation of unauthorized IRR objects.

cool!

what stands between my current world and when i can remove my irrd
instance and when i can remove (which) objects from the ripe whois?

< psa >

15-20 years back, when designing early rpki deployment, folk wanted the
irr to be equally if not more authoritative than the rpki.  trust what
you are already familiar with.  some where downright rabid about irr /
whois rulz.

the pendulum swings.

while i confess to helping to create this rpki origin validation
thingie, i would warn that it is pretty rigid.  notice how many xnog
threads we see about broken dnssec or just dns meaning my.mtv is mot
reachable?  this is analogous, except it is at the routing layer.

recommended actions:

   get your roas correct and monitor their correctness

   use an external service which ensures your roa data are propagating
   correctly globally

   use reliable and correct relying party softweare; there is crap
   out there

   monitor your routers to ensure that they are getting current relying
   party data

   familiarize your noc and engs with a toolset to provide assurance
   of and debug all of the above

i am sure there are more things to do; and hope that wiser folk will
expand, comment, and correct.

randy

---
randy () psg com
`gpg --locate-external-keys --auto-key-locate wkd randy () psg com`
signatures are back, thanks to dmarc header butchery