RPKI unknown for superprefixes of existing ROA ?

Sun Oct 22 15:41:49 UTC 2023

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 at herrin.us> wrote:

> On Sat, Oct 21, 2023 at 11:47 AM Mark Tinka <mark at 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 at herrin.us
> https://bill.herrin.us/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20231022/c66e33c3/attachment.html>