Re: RPKI unknown for superprefixes of existing ROA ?

[Owen DeLong via NANOG]

Actually, Job, the 1.2.0/20 would be the longest prefix announced for 1.2.4/24 and 1.2.7/24 in this case. It’s a rather clever end-run. The /20 won’t match the more specific as0 ROAs, so it gets accepted. The /24s either aren’t advertised or they get discarded as invalid.  Of course, if RIRs were issuing AS0 ROAs for unissued space, this wouldn’t be a problem, but sadly, several communities have opposed that process.  Owen On Oct 22, 2023, at 08:47, Job Snijders via NANOG <nanog@nanog.org> wrote:  On Sun, 22 Oct 2023 at 17:42, Amir Herzberg <amir.li...@gmail.com> wrote: Bill, thanks! You explained the issue much better than me. Yes, the problem is that, in my example, the operator was allocated  1.2.4/22 but the attacker is announcing  1.2.0/20, which is larger than the allocation, so the operator cannot issue ROA for it (or covering it). Of course, the RIR _could_ do it (but I don't think they do, right?). So this `superprefix hijack' may succeed in spite of all the ROAs that the operator could publish.  I'm not saying this is much of a concern, as I never heard of such attacks in the wild, but I guess it _could_ happen in the future. How is “success” measured here? The attacker won’t be drawing traffic towards itself destined for addresses in the /22, because of LPM  https://en.wikipedia.org/wiki/Longest_prefix_match Attackers don’t hijack IP traffic by announcing less-specifics. It don’t work that way. Kind regards, Job