[DBWG] RPKI/IRR Integration Feedback

[Ben Maddison]

Hi all,

Some feedback to the questions posed in Amreesh's presentation. I
wasn't in the room, but I've done my best to parse the minutes. Let me
know if I have misunderstood any of the points raised.

> 1. What should we do with the 20k route(6) objects in the IRR? Can we
> create equivalent ROAs?
> a. Can we create ROAs on members’ behalf?
No!
> b. Are the route(6) objects accurate?
No!
> c. What about BPKI certificate enrolment?
For existing members, this is an outreach issue. What, if any, steps
are staff currently taking to improve enrollment rates?

> 2. Should we do a ‘loose’ or ‘tight’ coupling between route(6) and
> ROAs?
> a. Loose: Create ROA -> Create one or more route(6) objects?
> Delete/Edit not handled
This is likely to lead to a build-up of garbage over time. Although
conflict handling is easier (by omission), i'm not wild about this
option.
> b. Tight: Create/Edit/Delete all sync’ed
If we go this route, my preference would be for a separate 'source:'
which is read-only via the usual db-update methods, and is tightly
coupled to the rpki.
That way, relying parties are in a position to choose whether they eat
the rpki-linked data.
This raises a few questions:
- Do we have a list of the people with active NRTM sessions set up? Is
that a short enough list that communicating this change would be
feasible?
- How would we deal with people who mirror via the dump?
- Have we ever studied where end users are retrieving their data from?
My guess would be mostly RADb, plus a long-tail of local mirrors. This
would have been useful information in the context of the ripe-nonauth
change too. Perhaps a project for Amreesh?
- How should queries (either `2001:db8::/32` or `-i origin AS65000`) be
returned where data exists in AFRINIC and AFRINIC-RPKI sources?

> 3. How to deal with ROAs having multiple prefixes?
route(6) per prefix. easy.

> 4. How to deal with max-length in ROAs?
> a. Minimal ROAs?
> b. Loose ROAs?
For the ROA->route(6) mapping, I would suggest that we ignore the max-
length altogether. Creating an object per prefix in 2001:db8::/32-48
would quickly explode the database.
We should not be auto-creating ROAs from existing route objects, so the
reverse is not relevant.

> 5. How to deal with expiry dates? Auto-renewal? 10 years ROA?
Above.

> 6. How and where to handle “route-set”, “AS-SET”, ASN-import/export,
> etc?
There is currently to analogue for an as-set in rpki. We can come back
to this when that changes (maybe as-cones).
route-set should be considered deprecated at this point. Another I-D
for someone to write.
(mp-)import/export are as harmless as they are useless. See 
https://tools.ietf.org/html/draft-azimov-sidrops-aspa-verification-01
for the likely successor.

Note that none of the above solves the issues surrounding the UI for
the whois/irr database. We urgently need sane programmatic access to
that. GUI enhancements could be built over the top of such a layer
quickly and easily.
Addressing the GUI problem first is, IMO, entirely the wrong way
around.

Cheers,

Ben