Sorry, saw this as I hit send:
There was a discussion in the routing wg on Monday
plenary session, not routing wg.
On May 17, 2018, at 5:09 PM, Sandra Murphy <sandy@tislabs.com> wrote:
There was a discussion in the routing wg on Monday of converting ROAs into IRR route objects for easy incorporation into the scripts many ISPs have for building filters from IRR data.
(I wanted to share this in time for the routing wg meeting Thursday morning, but woke in the teeny hours of Thu night/morning to find that the household Internet connection was down. Diagnosis and switch to backup plan did not get me connected until the opportunity was lost.)
The ability to translate ROAs into route objects was recognized early on and is/was incorporated into at least three RPKI implementations that I know of. If I recall correctly, Ruediger Volk was the first to suggest that strategy.
Geoff Huston made an interesting observation when this was mentioned in a SIDR working group meeting. There might be an unintended consequence when adding ROA-based-route objects into the filter generation mix, depending on the ISP's filter generation rules.
Suppose you had an AS XYZ that created no route objects.
Suppose you had an ISP that generated filters from IRR data. When the list of route objects is null, the ISP might generate a deny all filter and it might generate a permit all filter.
Suppose then that a prefix holder mistakenly generated a ROA for one of its prefixes for AS XYZ.
The list of route objects for AS XYZ is now not null.
If the ISP had previously generated a deny all filter, the filter now permits one prefix. Not much damage there.
If the ISP had previously generated a permit all filter, the filter now permits just one prefix. That’s a big change.
This presently doesn’t happen with RIPE route objects, because the RIPE model is that route objects have to have the permission of both prefix holder and ASN holder. So the mistake would not get registered.
[I believe this scenario also works if the IRR rule for route object registration is only that it has the permission of the prefix holder. According to the presentation Monday, that is the case today in some IRRs. A prefix holder might mistakenly register a route object for AS XYZ.]
Any ISP that generates a permit all filter when the route object list is null should be aware of this corner case and take appropriate care in their filter generation.
I suspect that generating a deny all filter is much more common.
—Sandy