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