Re: [routing-wg] ROAs and route objects and filters

[Sandra Murphy]

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

Re: [routing-wg] Fwd: [bcop] Abstract of the MANRS BCOP

[Hank Nussbacher]

On 17/05/2018 17:02, Benno Overeinder wrote:

Maybe I'm missing it when reading the website and the BCOP but where
does it state to *not *allow /25 or more specifics?
The entire reason for MANRS is to prevent route hijacking.  An ISP that
allows /25s or /26s to be leaked will easily circumvent all filters and
protections put in place since the /25 will override the /24 that most
of us filter on.  Without it specifically stated, we can't come to an
ISP that just announced 1000 /25s and tell them they did something
wrong.  Cuz it doesn't appear anywhere in our BCOP.

Please clue me in as to what I am missing since the way it looks now, it
doesn't do what it is supposed to do.

Thanks,
Hank

> As discussed in the BCOP TF meeting on Monday, we want to inform the
> Routing WG on the status of the MANRS (https://www.manrs.org/manrs/) and
> the MANRS Abstract BCOP.
>
> MANRS have been presented a number of times at the BCOP TF and at the
> Routing WG.  The actual MANRS guidelines are published on the manrs.org
> website, but the BCOP TF had the opinion that a RIPE series document has
> value as a static reference to the MANRS.  With the community input and
> feedback an extended abstract has been written down (see attachment).
>
> Last year August the BCOP TF announced and closed the last call for
> comments on the MANRS Extended Abstract on the BCOP mailing list
> b...@ripe.net.  Somewhat delayed, we want announce on the Routing WG
> mailing list the last call for this document with a time window of two
> weeks (until June 1st).
>
> Thank you and best regards,
>
> Jan Zorz & Benno Overeinder
>
>
>  Forwarded Message 
> Subject: Re: [bcop] Abstract of the MANRS BCOP
> Date: Tue, 22 Aug 2017 15:44:12 +0200
> From: Benno Overeinder 
> To: BCOP Task Force 
> CC: Jan Zorz - Go6 
>
> This reminder is directed to the BCOP TF mailing list subscribers.
>
> In the BCOP TF meeting we announced a period of last comments on the
> extended MANRS BCOP abstract draft and to publish this as a RIPE document.
> We want to close the comments period in two weeks and move the draft
> further in the process to make it a RIPE document.  Note that the draft
> is an abstract of the MANRS BCOP and references the full MANRS BCOP that
> includes examples and can be extended in the future.  The MANRS extended
> abstract published as a RIPE document will be a stable document.
>
> Best regards,
>
> — Benno
>
>
>> On 8 May 2017, at 13:31, Andrei Robachevsky  wrote:
>>
>> Hi,
>>
>> The final version of the MANRS BCOP has been published on the MANRS
>> website: https://www.manrs.org/bcop/. Both a PDF and an online versions
>> are available.
>>
>> However, to bring the bcop process to an official closure, chairs
>> suggested that instead of publishing the MANRS BCOP as a RIPE document,
>> that might be too constrained, we publish just an abstract. And once the
>> BCOP global repository is in place, we can put it there in whatever
>> format is most convenient.
>>
>> I am attaching the abstract for your review and comments.
>>
>> Regards,
>>
>> Andrei
>> <20170508-MANRS-BCOP-abstract.txt><20170508-MANRS-BCOP-abstract.docx>