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 <> 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

Reply via email to