Re: [Sidrops] request to consider draft-spaghetti-sidrops-rpki-prefixlist for WG adoption

[Geoff Huston <[e-mail]>]

> On 31 Jul 2023, at 6:20 pm, Sriram, Kotikalapudi (Fed) <kotikalapudi.sriram=[e-mail]> wrote:
> 
> Hi Geoff,
> 
>> Some specific examples may help me understand why you are making this assertion.
> 
> Maybe I am getting ahead of your thought process. So, let us step back a bit and ask the following questions:
> 
> One use case you mention in the draft is this:
> 
>   In other words, if a
>   given BGP route is covered by a RPKI PrefixList, but also is
>   "invalid" from a Route Origin Validation perspective, it is
>   RECOMMENDED to reject the route announcement.
> 
> Q1: ISPs today can (and do) reject a route if it is "invalid" from an ROV perspective [RFC 6811]. So, the first part of checking "if a given BGP route is covered by a RPKI PrefixList" is superfluous in this scenario. Do you agree?
> 
> So what is an actual use case for the PrefixList? Is there a scenario where an RP would use PrefixList-valid result to do something differently than how the RP uses the corresponding ROV result.   


If the route object does NOT have any ROA at all (like 60% of the IPv4 route objects) then IF the originating AS is using a Prefix List THEN a relying party can use the PrefixList to determine if the AS intended to originate this route or not. i.e. in such cases there is __NO__ ROA to help here.


>    
> 
>> given that we need to recognise the reality of partial adoption of ROAs
> 
> How is the PrefixList used to overcome a lack of a ROA?  


here’s an example to answer that question:...


So lets say that: 

10.0.1.0/24 has a valid ROA authorising AS 1,
10.0.2.0/24 has NO ROA at all,
10.0.3.0/24 has a valid ROA authorising AS 2 (but NOT AS 1)
10.0.4.0/24 has a valid ROA authorising AS 1,

and AS 1 has a valid prefix list with:
   10.0.1.0/24
   10.0.2.0.24
   10.0.3.0.24

then if a BGP speaker recieves the following routes:

10.0.1.0.24 originated by AS1
10.0.2.0.24 originated by AS1
10.0.3.0.24 originated by AS1
10.0.4.0/24 originated by AS1

then 

it can accept 10.0.1.0/24 becuase of a valid ROA and its inclusion in AS 1’s Prefix List
it can accept 10.0.2.0/24 becuase of its inclusion in AS 1’s Prefix List even though there is no valid ROA at all for 10.0.2.0/24
it may chose to reject 10.0.3.0/24 because the associated ROA does not authorise an AS 1 origination
it may chose to reject 10.0.4.0/24 because while the ROA authorises AS 1 to originate a route, it is NOT included in AS 1’s Prefix List, so AS 1 is claiming that it has no intention to originate this route.

In none of these cases can I see the Prefix List undermining the semantics of a ROA.

Geoff