Re: [Sidrops] draft-spaghetti-sidrops-rpki-prefixlist-00 (chapter #2 of what does IRR have that RPKI doesn't?)

[Job Snijders <[e-mail]>]

Hi Dale,

On Tue, Jun 06, 2023 at 01:15:26PM -0500, Dale W. Carder wrote:
> > I believe AS 293 is an autonomous system you have a relationship to?
> > You had no say in me creating the ROA. (I consider this a good
> > thing)
> > 
> > So with that in mind, perhaps you (and others in the same position)
> > should have the ability to reliably communicate to the public what
> > set of IP prefixes you intend to originate.
> 
> Yep, this helps clarify things.  I also have to wrap my mind around
> route-sets vs as-sets as an analogy, but have to ask why are IRR
> route-sets so underutilized?  I would just want be sure the roadblocks
> are not the same.  Is it that we expect user-facing tooling to be
> better, or the increased granularity of the roa+rpki-prefixlist
> combined attestations to be compelling?  Sorry this is a bit out of
> scope for the draft, but I think we're building towards an ecosystem.

User-facing tooling would be better: with IRR route-sets are plain-text
and lack object security, you have no idea if the AS holder was the one
who created the route-set. Additionally, you don't know the purpose of
the route-set: is it a list of prefixes that they found visually
pleasing? A list of networks to drop packets from? A random list?

In roa+rpki-prefixlist we can address such shortcomings and provide a
fully automated workflow (for example by extending RPKI-To-Router)

> > > Operationally, I think I would worry about the list getting out of
> > > sync.
> > 
> > But that's the point exactly - if such a list gets out of sync - the
> > out-of-syncness property is an information event which in turn could be
> > help make better informed routing decisions / BGP best path selection.
> 
> Got it!
> 
> Let's see if I can summarize section 6, figuring on an end-game RP policy
> of drop-invalid.  
> 
> scenario |   ROA    | rpki-prefixlist | Action
> ---------| ---------|-----------------|-------
>     1    | valid    | valid           | accept
>     2    | valid    | invalid         | drop
>     3    | valid    | unknown         | accept
>     4    | invalid  | valid           | drop
>     5    | invalid  | invalid         | drop
>     6    | invalid  | unknown         | drop
>     7    | unknown  | valid           | accept
>     8    | unknown  | invalid         | drop
>     9    | unknown  | unknown         | accept
> 
> Does this seem right?  

You are spot on. 

> For BGP UPDATE processing, scenarios (2) and (8) which I think would
> be new would definitely be of value. 

Yes! Thanks for summarizing the end-game.

> I think it does still fit in RTR (rfc8210)?

Yes, this can be made to work in RTR.

> For generation of RFC7454 style prefix route-policy filters, there's 
> some utility, but I think will we still might have the larger gap of 
> wanting an IRR as-set analog to define downstream ASN's.  Like, would
> we want the opposite of ASPA ASProviderAttestation.

That is a great question, I've authored two (in my opinion flawed)
proposals in that context:

https://datatracker.ietf.org/doc/html/draft-ietf-grow-rpki-as-cones
https://datatracker.ietf.org/doc/html/draft-spaghetti-sidrops-rpki-asgroup

In a nutshell: AS-Cones is underspecified and relies on some hopium, and
I made asgroups far too complex.

I think there are three questions I need to answer in order to produce a
third simple approach (which perhaps would have some viability).

1) Should the RPKI-based 'as-set' equivalent directly support recursion?
   (I'm starting to think 'no', because you'd be able to chain together
   non-recursive RPKI as-sets using ASPAs. We've also seen time after
   time that IRR as-sets expand to nearly infinite sizes when someone by
   accident references a gigantic as-set from their own as-set, this can
   be avoided if we simply don't allow referencing to anything other than
   ASNs. But what would the implications be for a partial-adoption
   world?)

2) Should a given referenced ASN 'actively opt-in' into being listed in
   the 'as-set' equivalent? The equivalent of the IRR 'member-of:'
   attribute.
   One could argue that being listed as Provider in an ASPA is a
   positive attestation that can be compared to the 'RPKI as-set' (the
   opposite of the ASPA ASProviderAttestation.)

3) What to call the thing? Between IRR 'as-set' and BGP 'AS_SET', I'm
   hesitant to do an additional overload of the letters 'asset'.

> Structurally the current draft mostly defines the profile, but presuming
> it's adopted, would we want to break out the verification process / usage
> considerations into a separate draft or keep it all together? (for example
> ASPA profile and verification are separate). 

Yes, it likely would end up becoming 3 documents:

1) profile
2) verification process for BGP implementations
3) RTR extension

I didn't write 2 + 3 as those are mostly mechanical, and not worth
spending time on if the profile / concept aren't adopted.

Kind regards,

Job