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
Assuming unknown encompasses no roa at all, im inclined to say most probably haven’t because that would break a lot of things because a lot of folks don’t have ROAs at all and some don’t seem to even have a plan around implementing them.
J~
This would be a bad idea and cause needless fragility in the network without any upsides.
Regards,
Job
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?
This would be a bad idea and cause needless fragility in the network without any upsides.
I’m not intending to advocate it, I’m asking if anyone is currently doing it.
I’m not aware of anyone doing this, and have not heard operators express interest in doing this (probably because it seems such an unpleasant concept).
Somewhat related:
I do know of operators that require a ROA (if it’s non-legacy space) during their customer onboarding process, for example, in BOYIP for DIA cases.
But those operators do not expect the ROA to continually exist after the provisioning has been completed successfully. Making the continued availability of a route dependent on the continued validity of a ROA is where friction starts to form.
Kind regards,
Job
A quick check to my routing table suggests that I have 206700 preferred routes (v4/v6) to notfound (unknown) destinations. So yeah I don’t think anyone can afford to do this right now.
I don’t think anyone can afford to ever do this, regardless of the number of unknown destinations!
Imagine not being able to reach North American destinations for 23 hours because of a cryptographic signing issue at the RIR [0] causing all ROAs to blip out of existence.
Kind regards,
Job
I ask because there was discussion at the ARIN meeting and Kevin Blumburg made the suggestion that “in 2024, routes will not be accepted without ROAs”.
I didn’t think this was likely, but as someone with resources for which I cannot create ROAs, it is a concern. So far, I haven’t really seen a significant benefit to going to the trouble of creating ROAs, but I also don’t want to suddenly find myself offline because I didn’t, so I figured it was a good idea to get a sense of the community on this.
Thanks to those that replied.
Owen
As someone who was there, that’s misrepresentation of what Kevin said. Im sure he can jump in and share his detailed point of view, but his point was many operators and cloud providers are already demanding to have a valid ROA to peer or use their services and that most likely become a requirement moving forward.
For legacy resource holders it is a problem but then it’s a bureaucratic issue rather technical and technology has a solution called SLURM.
For legacy resource holders it is a problem but then it’s a
bureaucratic issue rather technical and technology has a solution
called SLURM.
has arin not made it easier, lowering the legal insanity, for legacy
holders to obtain services?
randy
Yes but they need to jump now if they want to take advantage of it, as I understand it.
f
has arin not made it easier, lowering the legal insanity, for legacy
holders to obtain services?Yes but they need to jump now if they want to take advantage of it, as
I understand it.
arin has deep expertise in hurdles
randy
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?
This would be a bad idea and cause needless fragility in the network without any upsides.
I’m not intending to advocate it, I’m asking if anyone is currently doing it.
I’m not aware of anyone doing this, and have not heard operators express interest in doing this (probably because it seems such an unpleasant concept).
Somewhat related:
I do know of operators that require a ROA (if it’s non-legacy space) during their customer onboarding process, for example, in BOYIP for DIA cases.
In my region also, ISPs are asking valid ROAs before on-boarding users.
Thus spake Randy Bush (randy@psg.com) on Thu, Oct 19, 2023 at 03:16:21PM -0700:
> For legacy resource holders it is a problem but then it’s a
> bureaucratic issue rather technical and technology has a solution
> called SLURM.has arin not made it easier, lowering the legal insanity, for legacy
holders to obtain services?
Yes, and the process is pretty straightforward now even for public
entities.
We (AS293) recently updated our RSA and LRSA to the latest language
and also are cleaning up some ~40yrs of not-quite-accurate-enough
record keeping between multiple govt entities. If "we" can do it,
"you" can do it (probably a heck of a lot easier) 
Dale
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.
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
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
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
Hi Job,
The idea is that you have some infrastructure on IP addresses that you
don't route on the Internet. Maybe it's the /24 you use to number your
routers. Maybe it's a private network. Whatever it is, you intend for
that address block to be absent from Internet routing and produce a
ROA for AS0 which should, theoretically, force it to be absent from
the Internet.
Then someone comes along and advertises a portion of the RIR space
larger than any allocation. Since your subnet is intentionally absent
from the Internet, that larger route draws the packets allowing a
hijack of your address space.
In essence, this means that a ROA to AS0 doesn't work as intended.
Regards,
Bill Herrin
Even for positive ROAs (not AS 0 ROAs), that depends on how much of a
region's routers have full-routes or use partial routes.
In Brazil there are still many Mikrotik devices being used by
BGP-speaking networks that fumble on full-routes, and the offending
announcement might not have a LPM to choose from.
That might be yet more prevalent in routers connecting to IXPs,
because even default-route networks would see those announcements
without a LPM to follow.
Rubens