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

["Sriram, Kotikalapudi (Fed)" <[e-mail]>]

Hi Geoff:

My comments are marked with [KS]:

[GH] wrote (responding to Yangyang's scenario where it is shown that a hijacker owning AS3 can create a false PrefixList and take advantage):
"Not wrong, but not all that relevant either. If there is no ROA for a prefix then _any_ AS can originate a route to that prefix, and there is no ROA that can be used to say whether such an origination is authentic or not. That’s always been the case."

[KS]: The question is: Does the draft propose giving a higher authenticity to an ROV-unknown route if the apparent origin AS has the prefix included in its PrefixList versus another route for the same prefix with a different origin AS that does not have a PrefixList?

[KS]: If you give equal status to the two competing routes (one with an origin AS that has a PrefixList including the prefix and another with an origin AS that has no PrefixList; both routes are ROV-unknown), then the PrefixList is irrelevant (lacks a use case) for this scenario. However, only then the said hijacker does not gain any advantage over the legitimate announcement. 

[GH] wrote: "However, the prefix list can prevent others from accepting some forms of synthetic routes that would otherwise pass undetected. If a third party synthesised a route for 10.0.5.0/24, originated by AS1, then the valid prefix list signed by AS 1 would inform a relying party that 10.0.5.0/24 is not a route that AS 1 has acknowledged that it will originate, and the relying party may choose not to accept the route on that basis." 

[KS]: This is the classic case of AS hijacking as defined in the REAP draft. AS1 is being hijacked. It is being made to appear like it is hijacking a ROV-unknown prefix. ASPA-based path verification solves this problem only in the upstream path (Update received from a customer or lateral peer). REAP solves it more generally in any direction without side effects. PrefixList seems to solve it but not really... as explained below with examples.

[KS]: The prefix owner of 10.1.0.0/16 does not register any ROA. They originate the route from AS1. AS1 includes the /16 in its PrefixList. But if the prefix owner senses a hijack situation with the /16, they should have the liberty to deaggregate and announce two more specific prefixes: 10.1.0.0/17 and 10.1.128.0/17. At another time, the prefix owner may announce a more specific 10.1.1.0/24 (subsumed under the /16) for traffic engineering purposes. But according to your scheme above, AS1 (or any other RP along the AS path) will find these more specific prefixes not included in AS1's PrefixList. This seems to point to a design flaw. Does AS1 try to learn what more specific prefixes (subsumed under the /16)  may be announced in the future by the prefix owner? How can that information be collected by AS1 so it may include all possible more specific prefixes (in routes announced) out of the /16 into its PrefixList?

[GH] wrote (in the IETF 117 presentation slides): "Any route originated by this AS not contained in a validated RPKI Prefix List SHOULD be regarded as invalid". 

[KS]: This is similar to your earlier quoted statement and poses a problem as discussed below.

[KS]: When creating the PrefixList, is any attention paid by the AS owner to the ROAs of the prefixes being included? The following are examples of real ROAs using maxLength:

   AS2518, 2001:260::/32-48, apnic

   AS24560, 223.235.0.0/16-24, apnic
   AS9785, 223.164.0.0/16-24, apnic 

[KS]: If the ASes that originate the above prefixes include only the prefixes but not all the more-specific prefixes that are allowed due to the maxLength, then when the prefix owner choses to announce some of the more specific prefixes, they will be found to be Invalid by the PrefixList verification process and will be erroneously rejected. When the maxLength is much bigger than the prefix length in the ROA (though that is discouraged by RFC 9319), it is a very difficult task of enumerating and including the huge number of allowed more specific prefixes in the PrefixList! 

[KS]: A problem also arises when a prefix is actually originated by an AS but that AS's network engineer made a minor typo while typing in that prefix into the PrefixList. There may be other inconsistency issues between the PrefixList and the ROAs that are relevant to it. 

[KS]: No other comments below.

Sriram


-----Original Message-----
From: Geoff Huston <[e-mail]> 
Sent: Wednesday, August 2, 2023 11:52 PM
To: Yangyang Wang <[e-mail]>
Cc: Sriram, Kotikalapudi (Fed) <[e-mail]>; [e-mail]
Subject: Re: [Sidrops] request to consider draft-spaghetti-sidrops-rpki-prefixlist for WG adoption

> On 2 Aug 2023, at 8:01 pm, Yangyang Wang <wangyy=[e-mail]> wrote:
> 
> Dear Geoff and Sriram,
> 
> 
>> 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
> 
> And if AS 3 has a prefix list with:
>    10.0.2.0/24
>    10.0.5.0/24
> 
> For 10.0.5.0/24, no ROA and other Prefix List covers them due to partial deployment of ROA and Prefix List.
> 
> If a BGP speaker receives a route 10.0.2.0/24 originated by AS3, it can accept 10.0.2.0/24 because AS 3's Prefix List includes it and the validation of ROA is 'unknown'. Thus, AS 3 successfully creates a hijack if  AS 2 is the true originator for 10.0.2.0/24.  The same is true for 10.0.5.0/24.
> 
> pls correct me if I'm wrong.

Not wrong, but not all that relevant either. If there is no ROA for a prefix then _any_ AS can originate a route to that prefix, and there is no ROA that can be used to say whether such an origination is authentic or not. That’s always been the case.

However, the prefix list can prevent others from accepting some forms of synthetic routes that would otherwise pass undetected. If a third party synthesised a route for 10.0.5.0/24, originated by AS1, then the valid prefix list signed by AS 1 would inform a relying party that 10.0.5.0/24 is not a route that AS 1 has acknowledged that it will originate, and the relying party may choose not to accept the route on that basis.