Dear all,
I am Troy from NTT's Global IP Network IRR team.
Today we upgraded rr.ntt.net to IRRd 4.1.2!
This marks the completion of a multi-year initiative to seamlessly
integrate IRR and RPKI.
While this version might not seem remarkable, 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.
Anyone using the rr.ntt.net service to build their filters will benefit
from this change!
See RPKI integration — IRRd 4.1.2 documentation for more information.
If you require any assistance, please send a message to the team at
db-admin@rr.ntt.net.
Kind regards,
Troy
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
Stay far away from AS0...
Mark.
i am sure there are more things to do; and hope that wiser folk will
expand, comment, and correct.
Stay far away from AS0...
one of 42 ways, invented by clever people, to shoot yourself in the foot
randy