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 <sa...@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
> I suspect that generating a deny all filter is much more common.