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

[Geoff Huston <[e-mail]>]

> On 9 Aug 2023, at 5:04 pm, Sriram, Kotikalapudi (Fed) <[e-mail]> wrote:
> 
> 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?



There are no words in the draft to this effect.




> 
> [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. 

The prefix list is not irrelevant. but doe not apply in this scenario. If an AS has published a prefix list and the prefix is not in this list, yet it purports to be originated by this AS, then the prefix list provides grounds for a relying party to drop the route. 


> 
> [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?

So this is a a re-run of the maxlength issue with ROAs, and frankly I have no particular opinion one way or the other, though in this particular working groupo I suspect opinions are all over the place. The prefix List could require explicit enumeration of all prefixes including more specifics and insist on exact match. Or it could folk in a maxlength parameter and imnplicitly define more specifics. Like I said, I personally have no opinion one way or the other. I think this also relates to your following comments.

> 
> [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. 
> 
>