Re: RPKI unknown for superprefixes of existing ROA ?
On Sat, Oct 21, 2023 at 11:47 AM Mark Tinka 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 b...@herrin.us https://bill.herrin.us/
Re: RPKI unknown for superprefixes of existing ROA ?
On 10/21/23 16:03, Amir Herzberg wrote: Hi Owen, Randy, Job and other NANOGers, I surely agree with you all that we shouldn't expect discarding of ROA-unknown `anytime soon' (or ever?). But I have a question: what about discarding ROA-unknowns for very large prefixes (say, /12), or for superprefixes of prefixes with announced ROAs? Or at least, for superprefixes of prefixes with ROA to AS 0? For motivation, consider the `superprefix hijack attack'. Operator has prefix 1.2.4/22, but announce only 1.2.5/24 and 1.2.6/24, with appropriate ROAs. To avoid abuse of 1.2.4/24 and 1.2.7/24, they also make a ROA for 1.2.4/22 with AS 0. Attacker now announces 1.2.0/20, and uses IPs in 1.2.4/24 and 1.2.7/24 to send spam etc.. We introduced this threat and analyzed it in our ROV++ paper, btw (NDSS'21 I think - available online too of course). 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? The question is - who gets to decide how much space is "too large"? "Too large" will most certainly be different for different networks. If we try to get the RPKI to do things other than for which it was intended which may be interpreted as "unreasonable control", we make the case for those who think that is what it was destined to become. Mark.
RPKI unknown for superprefixes of existing ROA ?
Hi Owen, Randy, Job and other NANOGers, I surely agree with you all that we shouldn't expect discarding of ROA-unknown `anytime soon' (or ever?). But I have a question: what about discarding ROA-unknowns for very large prefixes (say, /12), or for superprefixes of prefixes with announced ROAs? Or at least, for superprefixes of prefixes with ROA to AS 0? For motivation, consider the `superprefix hijack attack'. Operator has prefix 1.2.4/22, but announce only 1.2.5/24 and 1.2.6/24, with appropriate ROAs. To avoid abuse of 1.2.4/24 and 1.2.7/24, they also make a ROA for 1.2.4/22 with AS 0. Attacker now announces 1.2.0/20, and uses IPs in 1.2.4/24 and 1.2.7/24 to send spam etc.. We introduced this threat and analyzed it in our ROV++ paper, btw (NDSS'21 I think - available online too of course). 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? -- 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 Thu, Oct 19, 2023 at 2:49 PM Owen DeLong via NANOG wrote: > A question for network operators out there that implement ROV… > > Is anyone rejecting RPKI unknown routes at this time? > > I know that it’s popular to reject RPKI invalid (a ROA exists, but doesn’t > match the route), but I’m wondering if anyone is currently or has any > plans to start rejecting routes which don’t have a matching ROA at all? > > Thanks, > > Owen > >
