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~
On Oct 19, 2023, at 11:47, Owen DeLong via NANOG <nanog@nanog.org> 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
On Thu, 19 Oct 2023 at 11:46, Owen DeLong via NANOG <nanog@nanog.org> 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?
This would be a bad idea and cause needless fragility in the network without any upsides. 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. Regards, Aftab A. Siddiqui On Fri, 20 Oct 2023 at 05:49, Owen DeLong via NANOG <nanog@nanog.org> 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
On Thu, 19 Oct 2023 at 12:12, Aftab Siddiqui <aftab.siddiqui@gmail.com> wrote:
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 [0] https://www.arin.net/announcements/20200826/
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
On Oct 19, 2023, at 12:17, Job Snijders <job@fastly.com> wrote:
On Thu, 19 Oct 2023 at 12:12, Aftab Siddiqui <aftab.siddiqui@gmail.com <mailto:aftab.siddiqui@gmail.com>> wrote:
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
On Thu, 19 Oct 2023 at 1:37 pm, Owen DeLong <owen@delong.com> wrote:
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”.
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.
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? -- 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 <nanog@nanog.org> 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
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.
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/
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/
On Sun, 22 Oct 2023 at 17:42, Amir Herzberg <amir.lists@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
On Sun, Oct 22, 2023 at 8:47 AM Job Snijders <job@fastly.com> wrote:
The attacker won’t be drawing traffic towards itself destined for addresses in the /22, because of LPM
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 -- William Herrin bill@herrin.us https://bill.herrin.us/
On Sun, Oct 22, 2023 at 9:10 AM William Herrin <bill@herrin.us> wrote:
In essence, this means that a ROA to AS0 doesn't work as intended.
Let me ground it a bit: He's saying that someone could come along and advertise 0.0.0.0/1 and 128.0.0.0/1 and by doing so they'd hijack every unrouted address block regardless of the block's ROA. RPKI is unable to address this attack vector. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
Let me ground it a bit:
He's saying that someone could come along and advertise 0.0.0.0/1 and 128.0.0.0/1 and by doing so they'd hijack every unrouted address block regardless of the block's ROA.
RPKI is unable to address this attack vector.
https://www.rfc-editor.org/rfc/rfc6483 Section 4
A ROA with a subject of AS 0 (AS 0 ROA) is an attestation by the holder of a prefix that the prefix described in the ROA, and any more specific prefix, should not be used in a routing context. The route validation procedure, described in Section 2 <https://www.rfc-editor.org/rfc/rfc6483#section-2>, will provide a "valid" outcome if any ROA matches the address prefix and origin AS, even if other valid ROAs would provide an "invalid" validation outcome if used in isolation. Consequently, an AS 0 ROA has a lower relative preference than any other ROA that has a routable AS as its subject. This allows a prefix holder to use an AS 0 ROA to declare a default condition that any route that is equal to or more specific than the prefix to be considered "invalid", while also allowing other concurrently issued ROAs to describe valid origination authorizations for more specific prefixes. By convention, an AS 0 ROA should have a maxLength value of 32 for IPv4 addresses and a maxlength value of 128 for IPv6 addresses; although, in terms of route validation, the same outcome would be achieved with any valid maxLength value, or even if the maxLength
element were to be omitted from the ROA. A property constructed AS 0 ROA for 1.2.4/22 ( in Amir's scenario ) would cause an RPKI participating router to properly mark any more specific announcement inside 1.2.4/22 as INVALID, which is in fact 'addressing the attack vector, WITH the assertion that all routers in the routing domain are RPKI enabled, and discarding RPKI INVALIDs. The fact that RPKI INVALID routes *cannot* be summarily discarded TODAY because of the state of the internet as a whole is a separate issue. Fundamentally, in the scenario described by Amir originally, the operator is being dumb by NOT announcing AT LEAST the prefix for their allocation to ensure that nobody can just toss out an announcement to snipe the unannounced space. On Sun, Oct 22, 2023 at 12:28 PM William Herrin <bill@herrin.us> wrote:
On Sun, Oct 22, 2023 at 9:10 AM William Herrin <bill@herrin.us> wrote:
In essence, this means that a ROA to AS0 doesn't work as intended.
Let me ground it a bit:
He's saying that someone could come along and advertise 0.0.0.0/1 and 128.0.0.0/1 and by doing so they'd hijack every unrouted address block regardless of the block's ROA.
RPKI is unable to address this attack vector.
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/
On Sun, Oct 22, 2023 at 9:38 AM Tom Beecher <beecher@beecher.cc> wrote:
He's saying that someone could come along and advertise 0.0.0.0/1 and 128.0.0.0/1 and by doing so they'd hijack every unrouted address block regardless of the block's ROA.
RPKI is unable to address this attack vector.
https://www.rfc-editor.org/rfc/rfc6483
Section 4
A ROA with a subject of AS 0 (AS 0 ROA) is an attestation by the holder of a prefix that the prefix described in the ROA, and any more specific prefix, should not be used in a routing context.
And is it your belief that this addresses the described attack vector? AFAICT, it does not. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
And is it your belief that this addresses the described attack vector? AFAICT, it does not.
Quoting myself : WITH the assertion that all routers in the routing domain are RPKI enabled,
and discarding RPKI INVALIDs.
In the mixed RPKI / non-RPKI environment of today's internet, no it doesn't. This does not mean that RPKI is deficient, or the AS 0 ROA doesn't work as intended, as was stated. On Sun, Oct 22, 2023 at 12:57 PM William Herrin <bill@herrin.us> wrote:
On Sun, Oct 22, 2023 at 9:38 AM Tom Beecher <beecher@beecher.cc> wrote:
He's saying that someone could come along and advertise 0.0.0.0/1 and 128.0.0.0/1 and by doing so they'd hijack every unrouted address block regardless of the block's ROA.
RPKI is unable to address this attack vector.
https://www.rfc-editor.org/rfc/rfc6483
Section 4
A ROA with a subject of AS 0 (AS 0 ROA) is an attestation by the holder of a prefix that the prefix described in the ROA, and any more specific prefix, should not be used in a routing context.
And is it your belief that this addresses the described attack vector? AFAICT, it does not.
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/
On Sun, Oct 22, 2023 at 10:06 AM Tom Beecher <beecher@beecher.cc> wrote:
And is it your belief that this addresses the described attack vector? AFAICT, it does not.
In the mixed RPKI / non-RPKI environment of today's internet, no it doesn't.
I don't see a path to an Internet where a serious network operator can broadly discard routes for which there is no RPKI information. Especially given that many legacy folks are barred by the registry from participating in RPKI. Do you see a path? Then we have to treat this as a case where RPKI is non-performant and operate with the understanding that an AS0 ROA will not, as a practical matter, accomplish the thing it was designed to do. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
Can an operator discard no RPKI / RPKI INVALID *from the DFZ* today, or at any time in the foreseeable future? No. Probably not ever. That does not mean there are other perfectly reasonable RPKI use cases where an AS 0 ROA does accomplish exactly that with which it was designed. On Sun, Oct 22, 2023 at 1:24 PM William Herrin <bill@herrin.us> wrote:
On Sun, Oct 22, 2023 at 10:06 AM Tom Beecher <beecher@beecher.cc> wrote:
And is it your belief that this addresses the described attack vector? AFAICT, it does not.
In the mixed RPKI / non-RPKI environment of today's internet, no it doesn't.
I don't see a path to an Internet where a serious network operator can broadly discard routes for which there is no RPKI information. Especially given that many legacy folks are barred by the registry from participating in RPKI.
Do you see a path?
Then we have to treat this as a case where RPKI is non-performant and operate with the understanding that an AS0 ROA will not, as a practical matter, accomplish the thing it was designed to do.
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/
Look again, Tom. This is an attack vector using a LESS specific route. The /22 gets discarded, but a covering /0-/21 would not.
Yes. And reliant on the operator doing something exceptionally not smart to begin with. Relying on an AS0 ROA alone and not actually announcing the covering prefix as well isn't a good thing to do. On Sun, Oct 22, 2023 at 1:39 PM Owen DeLong <owen@delong.com> wrote:
Look again, Tom. This is an attack vector using a LESS specific route. The /22 gets discarded, but a covering /0-/21 would not.
Owen
On Oct 22, 2023, at 10:06, Tom Beecher <beecher@beecher.cc> wrote:
And is it your belief that this addresses the described attack vector? AFAICT, it does not.
Quoting myself :
WITH the assertion that all routers in the routing domain are RPKI
enabled, and discarding RPKI INVALIDs.
In the mixed RPKI / non-RPKI environment of today's internet, no it doesn't. This does not mean that RPKI is deficient, or the AS 0 ROA doesn't work as intended, as was stated.
On Sun, Oct 22, 2023 at 12:57 PM William Herrin <bill@herrin.us> wrote:
On Sun, Oct 22, 2023 at 9:38 AM Tom Beecher <beecher@beecher.cc> wrote:
He's saying that someone could come along and advertise 0.0.0.0/1 and 128.0.0.0/1 and by doing so they'd hijack every unrouted address block regardless of the block's ROA.
RPKI is unable to address this attack vector.
https://www.rfc-editor.org/rfc/rfc6483
Section 4
A ROA with a subject of AS 0 (AS 0 ROA) is an attestation by the holder of a prefix that the prefix described in the ROA, and any more specific prefix, should not be used in a routing context.
And is it your belief that this addresses the described attack vector? AFAICT, it does not.
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/
I agree that a good, sensible defense would be to simply announce your entire address block, e.g., in the example, your entire /22 (with a ROA to your ASN), and filter the traffic to the unused prefixes. Basically, I guess, it means that the AS 0 solution shouldn't be used, at least not usually. I wonder if anyone is using it , in fact. It would be nice to know if someone has the data handy. Thanks! 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 Sun, Oct 22, 2023 at 1:50 PM Tom Beecher <beecher@beecher.cc> wrote:
Look again, Tom. This is an attack vector using a LESS specific route. The
/22 gets discarded, but a covering /0-/21 would not.
Yes. And reliant on the operator doing something exceptionally not smart to begin with. Relying on an AS0 ROA alone and not actually announcing the covering prefix as well isn't a good thing to do.
On Sun, Oct 22, 2023 at 1:39 PM Owen DeLong <owen@delong.com> wrote:
Look again, Tom. This is an attack vector using a LESS specific route. The /22 gets discarded, but a covering /0-/21 would not.
Owen
On Oct 22, 2023, at 10:06, Tom Beecher <beecher@beecher.cc> wrote:
And is it your belief that this addresses the described attack vector? AFAICT, it does not.
Quoting myself :
WITH the assertion that all routers in the routing domain are RPKI
enabled, and discarding RPKI INVALIDs.
In the mixed RPKI / non-RPKI environment of today's internet, no it doesn't. This does not mean that RPKI is deficient, or the AS 0 ROA doesn't work as intended, as was stated.
On Sun, Oct 22, 2023 at 12:57 PM William Herrin <bill@herrin.us> wrote:
On Sun, Oct 22, 2023 at 9:38 AM Tom Beecher <beecher@beecher.cc> wrote:
He's saying that someone could come along and advertise 0.0.0.0/1 and 128.0.0.0/1 and by doing so they'd hijack every unrouted address block regardless of the block's ROA.
RPKI is unable to address this attack vector.
https://www.rfc-editor.org/rfc/rfc6483
Section 4
A ROA with a subject of AS 0 (AS 0 ROA) is an attestation by the holder of a prefix that the prefix described in the ROA, and any more specific prefix, should not be used in a routing context.
And is it your belief that this addresses the described attack vector? AFAICT, it does not.
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/
Basically, I guess, it means that the AS 0 solution shouldn't be used, at least not usually.
It's like everything else. Understand what the tools do and what they don't do, and use them appropriately. On Sun, Oct 22, 2023 at 2:21 PM Amir Herzberg <amir.lists@gmail.com> wrote:
I agree that a good, sensible defense would be to simply announce your entire address block, e.g., in the example, your entire /22 (with a ROA to your ASN), and filter the traffic to the unused prefixes. Basically, I guess, it means that the AS 0 solution shouldn't be used, at least not usually. I wonder if anyone is using it , in fact. It would be nice to know if someone has the data handy.
Thanks! 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 Sun, Oct 22, 2023 at 1:50 PM Tom Beecher <beecher@beecher.cc> wrote:
Look again, Tom. This is an attack vector using a LESS specific route.
The /22 gets discarded, but a covering /0-/21 would not.
Yes. And reliant on the operator doing something exceptionally not smart to begin with. Relying on an AS0 ROA alone and not actually announcing the covering prefix as well isn't a good thing to do.
On Sun, Oct 22, 2023 at 1:39 PM Owen DeLong <owen@delong.com> wrote:
Look again, Tom. This is an attack vector using a LESS specific route. The /22 gets discarded, but a covering /0-/21 would not.
Owen
On Oct 22, 2023, at 10:06, Tom Beecher <beecher@beecher.cc> wrote:
And is it your belief that this addresses the described attack vector? AFAICT, it does not.
Quoting myself :
WITH the assertion that all routers in the routing domain are RPKI
enabled, and discarding RPKI INVALIDs.
In the mixed RPKI / non-RPKI environment of today's internet, no it doesn't. This does not mean that RPKI is deficient, or the AS 0 ROA doesn't work as intended, as was stated.
On Sun, Oct 22, 2023 at 12:57 PM William Herrin <bill@herrin.us> wrote:
On Sun, Oct 22, 2023 at 9:38 AM Tom Beecher <beecher@beecher.cc> wrote:
He's saying that someone could come along and advertise 0.0.0.0/1 and 128.0.0.0/1 and by doing so they'd hijack every unrouted address block regardless of the block's ROA.
RPKI is unable to address this attack vector.
https://www.rfc-editor.org/rfc/rfc6483
Section 4
A ROA with a subject of AS 0 (AS 0 ROA) is an attestation by the holder of a prefix that the prefix described in the ROA, and any more specific prefix, should not be used in a routing context.
And is it your belief that this addresses the described attack vector? AFAICT, it does not.
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/
On Sun, 22 Oct 2023 at 20:33, Tom Beecher <beecher@beecher.cc> wrote:
Basically, I guess, it means that the AS 0 solution shouldn't be used, at
least not usually.
It's like everything else. Understand what the tools do and what they don't do, and use them appropriately.
A primary risk for an IXP is the existence of a more-specific of the IX peering LAN prefix, a less-specific wouldn’t matter or inflict damage. So in the above context an AS 0 ROAs can be useful to improve protection of IXP Peering LANs where the IX operator doesn’t want the fabric to be globally reachable - and one of the IX participants failed to correctly EBGP in/out policies. Kind regards, Job
Yes, but we weren’t talking about an IXP here. We’re talking about an ISP. Believe it or not, Job, there are parts of the internet that exchange traffic and move packets that are not IXPs. Owen
On Oct 22, 2023, at 11:48, Job Snijders via NANOG <nanog@nanog.org> wrote:
On Sun, 22 Oct 2023 at 20:33, Tom Beecher <beecher@beecher.cc <mailto:beecher@beecher.cc>> wrote:
Basically, I guess, it means that the AS 0 solution shouldn't be used, at least not usually.
It's like everything else. Understand what the tools do and what they don't do, and use them appropriately.
A primary risk for an IXP is the existence of a more-specific of the IX peering LAN prefix, a less-specific wouldn’t matter or inflict damage.
So in the above context an AS 0 ROAs can be useful to improve protection of IXP Peering LANs where the IX operator doesn’t want the fabric to be globally reachable - and one of the IX participants failed to correctly EBGP in/out policies.
Kind regards,
Job
On Tue, Oct 24, 2023 at 05:28:31PM -0700, Owen DeLong wrote:
Yes, but we weren’t talking about an IXP here. We’re talking about an ISP.
Sure, perhaps you were I intended to submit an example where a resource holder constructively uses a ROA designating AS 0 as purported originator, actually helps the overall ecosystem.
Believe it or not, Job, there are parts of the internet that exchange traffic and move packets that are not IXPs.
¯\_(ツ)_/¯
In fairness, however, there is a natural tendency for many of those PNIs to be built in locations in common with IXPs and often they start as IXP connections and with growth of traffic end up migrating to PNIs for further expansion. Owen
On Oct 24, 2023, at 18:15, Randy Bush <randy@psg.com> wrote:
Believe it or not, Job, there are parts of the internet that exchange traffic and move packets that are not IXPs.
in fact, measurements had shown that the majority of inter-domain traffic is over pnis
randy
The covering /20 isn’t his to announce… He has a /22. He’s announcing all 4 /24s, and may not have a legitimate place to announce the covering /22, which wouldn’t help in this case anyway. So I’m not sure why you think that’s a solution. Owen
On Oct 22, 2023, at 10:45, Tom Beecher <beecher@beecher.cc> wrote:
Look again, Tom. This is an attack vector using a LESS specific route. The /22 gets discarded, but a covering /0-/21 would not.
Yes. And reliant on the operator doing something exceptionally not smart to begin with. Relying on an AS0 ROA alone and not actually announcing the covering prefix as well isn't a good thing to do.
On Sun, Oct 22, 2023 at 1:39 PM Owen DeLong <owen@delong.com <mailto:owen@delong.com>> wrote:
Look again, Tom. This is an attack vector using a LESS specific route. The /22 gets discarded, but a covering /0-/21 would not.
Owen
On Oct 22, 2023, at 10:06, Tom Beecher <beecher@beecher.cc <mailto:beecher@beecher.cc>> wrote:
And is it your belief that this addresses the described attack vector? AFAICT, it does not.
Quoting myself :
WITH the assertion that all routers in the routing domain are RPKI enabled, and discarding RPKI INVALIDs.
In the mixed RPKI / non-RPKI environment of today's internet, no it doesn't. This does not mean that RPKI is deficient, or the AS 0 ROA doesn't work as intended, as was stated.
On Sun, Oct 22, 2023 at 12:57 PM William Herrin <bill@herrin.us <mailto:bill@herrin.us>> wrote:
On Sun, Oct 22, 2023 at 9:38 AM Tom Beecher <beecher@beecher.cc <mailto:beecher@beecher.cc>> wrote:
He's saying that someone could come along and advertise 0.0.0.0/1 <http://0.0.0.0/1> and 128.0.0.0/1 <http://128.0.0.0/1> and by doing so they'd hijack every unrouted address block regardless of the block's ROA.
RPKI is unable to address this attack vector.
https://www.rfc-editor.org/rfc/rfc6483
Section 4
A ROA with a subject of AS 0 (AS 0 ROA) is an attestation by the holder of a prefix that the prefix described in the ROA, and any more specific prefix, should not be used in a routing context.
And is it your belief that this addresses the described attack vector? AFAICT, it does not.
Regards, Bill Herrin
-- William Herrin bill@herrin.us <mailto:bill@herrin.us> https://bill.herrin.us/
He’s announcing all 4 /24s
That's not what was described as the original situation. 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.
On Tue, Oct 24, 2023 at 8:27 PM Owen DeLong <owen@delong.com> wrote:
The covering /20 isn’t his to announce… He has a /22. He’s announcing all 4 /24s, and may not have a legitimate place to announce the covering /22, which wouldn’t help in this case anyway.
So I’m not sure why you think that’s a solution.
Owen
On Oct 22, 2023, at 10:45, Tom Beecher <beecher@beecher.cc> wrote:
Look again, Tom. This is an attack vector using a LESS specific route. The
/22 gets discarded, but a covering /0-/21 would not.
Yes. And reliant on the operator doing something exceptionally not smart to begin with. Relying on an AS0 ROA alone and not actually announcing the covering prefix as well isn't a good thing to do.
On Sun, Oct 22, 2023 at 1:39 PM Owen DeLong <owen@delong.com> wrote:
Look again, Tom. This is an attack vector using a LESS specific route. The /22 gets discarded, but a covering /0-/21 would not.
Owen
On Oct 22, 2023, at 10:06, Tom Beecher <beecher@beecher.cc> wrote:
And is it your belief that this addresses the described attack vector? AFAICT, it does not.
Quoting myself :
WITH the assertion that all routers in the routing domain are RPKI
enabled, and discarding RPKI INVALIDs.
In the mixed RPKI / non-RPKI environment of today's internet, no it doesn't. This does not mean that RPKI is deficient, or the AS 0 ROA doesn't work as intended, as was stated.
On Sun, Oct 22, 2023 at 12:57 PM William Herrin <bill@herrin.us> wrote:
On Sun, Oct 22, 2023 at 9:38 AM Tom Beecher <beecher@beecher.cc> wrote:
He's saying that someone could come along and advertise 0.0.0.0/1 and 128.0.0.0/1 and by doing so they'd hijack every unrouted address block regardless of the block's ROA.
RPKI is unable to address this attack vector.
https://www.rfc-editor.org/rfc/rfc6483
Section 4
A ROA with a subject of AS 0 (AS 0 ROA) is an attestation by the holder of a prefix that the prefix described in the ROA, and any more specific prefix, should not be used in a routing context.
And is it your belief that this addresses the described attack vector? AFAICT, it does not.
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/
On Sun, 22 Oct 2023 at 18:10, William Herrin <bill@herrin.us> wrote:
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.
Right, so in order to discard packets towards a network, it’s more robust to actually advertise the IP space which you don’t intend to publicly use, and use ACLs on that edge to discard the packets yourself (rather than relying on all other ISPs having deployed ROV and less-specifics not existing). Given the frequency of ISPs accidentally announcing giant blocks, and this apparently not causing much grief https://www.ripe.net/ripe/mail/archives/routing-wg/2022-July/004588.html I’m skeptical there much need for change. As to Ruben’s point - when an ISP is operating their network with a default route & an incomplete routing table, indeed chances are packets will end up on the wrong path … because the ISP is using an incomplete routing table. Kind regards, Job
On Sun, Oct 22, 2023 at 5:47 PM Job Snijders via NANOG <nanog@nanog.org> wrote:
On Sun, 22 Oct 2023 at 17:42, Amir Herzberg <amir.lists@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.
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
On Sun, 22 Oct 2023 at 19:35, Owen DeLong <owen@delong.com> wrote:
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.
You wouldn’t create AS 0 ROAs if you want to announce the IP space pull traffic into the discard filters on your edge. Kind regards, Job
participants (12)
-
Aftab Siddiqui -
Amir Herzberg -
Dale W. Carder -
Fearghas Mckay -
JASON BOTHE -
Job Snijders -
Mark Tinka -
Owen DeLong -
Randy Bush -
Rubens Kuhl -
Tom Beecher -
William Herrin