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. So my question is only:
So: would it be conceivable that operators will block such 1.2.0/20 - since it's too large a prefix without ROA and in particular includes sub-prefixes with ROA, esp. ROA to AS 0?
(note: I mentioned two possible rules for such blocking: overly large `unknown' prefixes and super-prefixes of AS 0 ROAs - but either could be applied or even their conjunction) tks, Amir -- Amir Herzberg Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home `Applied Introduction to Cryptography' textbook and lectures: https://sites.google.com/site/amirherzberg/cybersecurity On Sat, Oct 21, 2023 at 4:52 PM William Herrin <bill@herrin.us> wrote:
On Sat, Oct 21, 2023 at 11:47 AM Mark Tinka <mark@tinka.africa> wrote:
The question is - who gets to decide how much space is "too large"?
I thought Amir's point was that if an announced route is larger than the RIR allocation then unless you're intentionally expecting it, it's invalid.
Because there's no alignment with the RIR allocation, it's not possible to express this invalidity in RPKI.
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/