[NLNOG] FW: NTT now treats RPKI ROAs as IRR route(6)-objects

Job Snijders job at ntt.net
Fri Jul 20 17:34:23 CEST 2018


Dear Martin,

On Fri, Jul 20, 2018 at 11:27:18AM +0200, Martin Pels wrote:
> On 19/07/18 23:52, Job Snijders wrote:
> > [ TL:DR - From now on, NTT / AS 2914 allows customers to either
> > register their announcements in the IRR, or as RPKI ROAs. This is a
> > convenience service for relevant regions of the world where IRR is
> > not the norm but RPKI is commonly available. Previously NTT only
> > accepted IRR and ARIN-WHOIS. I hope competitors and partners will
> > use this approach too! ]
> 
> Cool. What do you do if someone registers in RPKI and IRR and the data
> does not match?

What was deployed here is what I'd call 'step 1'. RPKI now complements
the IRR data. Just like when you mirror RIPE and RADB, with default
settings both sources will be used to construct the list of prefixes
when you issue a '!gAS15562' command to the IRRd server.

The next step is to let RPKI ROAs 'drown out' or 'overwrite' conflicting
IRR information, and have the IRRd instance supress the conflicting IRR
information for all its outputs. This "RPKI supersedes IRR" approach has
two benefits:

  A/ It would provide the industry with a method of signaling to IRRs
     that there are stale proxy route objects (perhaps as old as 20
     years), and by issuing an RPKI ROA to me it is a clear signal that
     the route-object is outdated and should no longer be considered.

  B/ It prevents future IRR-based hijacks, because IRRd instances won't
     accept conflicting IRR information into their feasible output.
     We'll have to worry less about false IRR information popping up in
     one of the many IRRs because the RPKI ROA is leading.

In short: "RPKI supersedes IRR" will be both help clean-up old data, and
is security feature. The feature to facilitate this next step is tracked
here: https://github.com/irrdnet/irrd4/issues/3

Kind regards,

Job


More information about the NLNOG mailing list