Re: [Sidrops] request for adoption call for draft-spaghetti-sidrops-rpki-doa

[Mikael Abrahamsson <[e-mail]>]

On Tue, 19 Apr 2022, Jay Borkenhagen wrote:

> Before discussing WG adoption, please help me understand more about
> your intent for DOA.  Allow me to ask it this way:
>
> ---------------
>
> I agree that there are situations in which it makes sense today for a
> service provider to accept rpki-invalid announcements from their
> customers.  As the draft points out, RTBH is one such case.  Another
> case is for traffic engineering: my customer has a /23 with a ROA.
> They assign one /24 to one site and the other /24 to a different site,
> both sites connected to my network.  They have no need for the entire
> DFZ to learn the /24s, so there is no need to publish ROAs for the
> /24s.
>
> Service providers must continue to maintain prefix-list route filters
> on all their customers (and ROAs can play a big role in that, as has
> been discussed).
>
> If this service provider wants to allow its customers to send it RTBH
> or TE more-specifics in apparent opposition of published ROAs, it can
> require those more-specifics to come with suitable communities:
>
> - "We will accept rpki-invalid RTBH route announcements from
>   customers IFF (a) they are accepted by the prefix-list
>   route-filters AND (b) they carry the RTBH community."
>
> - "We will accept rpki-invalid TE route announcements from customers
>   IFF (a) they are accepted by the prefix-list route-filters AND (b)
>   they carry our community signifying they are for use only within
>   our network and will not be propagated further."  This community
>   could possibly be no-export, or perhaps some other community
>   defined by the service provider.
>
> ---------------
>
> Given the above description, is there a gap that DOA helps to close?

I don't disagree with anything you wrote above, they're all valid 
use-cases, with the comment that running strict prefix-list for permitting 
routes is not feasible for all customers due to the poor quality of 
IRR/RPKI. Also, there is no way for the customer to delegate the RTBH 
creation to their upstream and have the upstream signal this to their 
peers/upstreams if that's desired.

However, I'd like to see us move towards a more automated/secure future 
(both when it comes to sourcing information but also pushing out updated 
information into the network) with less hands-on when it comes to managing 
prefix filters, and one way is that everything that needs to go into these 
filters, goes into RPKI, and is continously updated/pushed to the routers. 
This is partly to solve the problem that we've seen problems maintaining 
huge configurations with prefix lists that are batch run/updated 
periodically. It's a problem both where the information that goes into 
these lists come from, and how they're stored on-device. With DOA going 
into RPKI we shift the mechanism to a system where the prefixes are not 
stored in configuration, but are stored in a different way on the device, 
plus it's signed, and the customer administrates it using the regular RPKI 
tools.

Each step towards a future without IRR but with information instead 
residing in RPKI would enable us to have less hands-on with prefix list 
changes and have smaller configurations on the routers.

One argument that I've had regarding DOA is that it's quite specific and 
question is if a more generic mechanism should be created, perhaps for 
other use-cases. My experience however is that as soon as we aim for 
something more generic, the work scope explodes and the time to completion 
increases by years. There is a tendency to let perfect get in the way of 
good.

-- 
Mikael Abrahamsson    email: [e-mail]