Mailing List Archive

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.

Re: RPKI unknown for superprefixes of existing ROA ? [ In reply to ]

Oct 21, 2023, 1:49 PM

Post #3 of 28 (352 views)

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/

Re: RPKI unknown for superprefixes of existing ROA ? [ In reply to ]

amir.lists at gmail

Oct 22, 2023, 8:41 AM

Post #4 of 28 (352 views)

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/
>

Re: RPKI unknown for superprefixes of existing ROA ? [ In reply to ]

Oct 22, 2023, 8:46 AM

Post #5 of 28 (352 views)

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

>

Re: RPKI unknown for superprefixes of existing ROA ? [ In reply to ]

Oct 22, 2023, 9:10 AM

Post #6 of 28 (352 views)

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/

Re: RPKI unknown for superprefixes of existing ROA ? [ In reply to ]

rubensk at gmail

Oct 22, 2023, 9:17 AM

Post #7 of 28 (352 views)

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

Re: RPKI unknown for superprefixes of existing ROA ? [ In reply to ]

Oct 22, 2023, 9:27 AM

Post #8 of 28 (352 views)

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/

Re: RPKI unknown for superprefixes of existing ROA ? [ In reply to ]

Oct 22, 2023, 9:37 AM

Post #9 of 28 (352 views)

>
> 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/
>

Re: RPKI unknown for superprefixes of existing ROA ? [ In reply to ]

Oct 22, 2023, 9:46 AM

Post #10 of 28 (352 views)

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

Re: RPKI unknown for superprefixes of existing ROA ? [ In reply to ]

Oct 22, 2023, 9:57 AM

Post #11 of 28 (352 views)

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/

Re: RPKI unknown for superprefixes of existing ROA ? [ In reply to ]

Oct 22, 2023, 10:05 AM

Post #12 of 28 (352 views)

>
> 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/
>

Re: RPKI unknown for superprefixes of existing ROA ? [ In reply to ]

Oct 22, 2023, 10:24 AM

Post #13 of 28 (352 views)

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/

Re: RPKI unknown for superprefixes of existing ROA ? [ In reply to ]

Oct 22, 2023, 10:34 AM

Post #14 of 28 (352 views)

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.
Of course, if RIRs were issuing AS0 ROAs for unissued space, this wouldn’t be a problem, but sadly, several communities have opposed that process.
Owen

On Oct 22, 2023, at 08:47, 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"]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

Re: RPKI unknown for superprefixes of existing ROA ? [ In reply to ]

Oct 22, 2023, 10:38 AM

Post #15 of 28 (352 views)

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 http://0.0.0.0/1"]0.0.0.0/1 and
>> http://128.0.0.0/1"]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"]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/"]https://bill.herrin.us/

Re: RPKI unknown for superprefixes of existing ROA ? [ In reply to ]

Oct 22, 2023, 10:40 AM

Post #16 of 28 (352 views)

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/
>

Re: RPKI unknown for superprefixes of existing ROA ? [ In reply to ]

Oct 22, 2023, 10:44 AM

Post #17 of 28 (352 views)

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

>

Re: RPKI unknown for superprefixes of existing ROA ? [ In reply to ]

Oct 22, 2023, 10:45 AM

Post #18 of 28 (352 views)

>
> 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/
>>
>

Re: RPKI unknown for superprefixes of existing ROA ? [ In reply to ]

amir.lists at gmail

Oct 22, 2023, 11:20 AM

Post #19 of 28 (352 views)

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/
>>>
>>

Re: RPKI unknown for superprefixes of existing ROA ? [ In reply to ]

Oct 22, 2023, 11:33 AM

Post #20 of 28 (352 views)

>
> 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/
>>>>
>>>

Re: RPKI unknown for superprefixes of existing ROA ? [ In reply to ]

Oct 22, 2023, 11:48 AM

Post #21 of 28 (352 views)

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

>

Re: RPKI unknown for superprefixes of existing ROA ? [ In reply to ]

mangawilly at gmail

Oct 23, 2023, 5:24 AM

Post #22 of 28 (349 views)

.
On 23/10/2023 16:00, nanog-request@nanog.org wrote:
> Message: 19 Date: Sun, 22 Oct 2023 14:20:56 -0400 From: Amir Herzberg
> <amir.lists@gmail.com>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.

https://console.rpki-client.org/AS0.html

--
Willy Manga
@ongolaboy
https://ongola.blogspot.com/

Re: RPKI unknown for superprefixes of existing ROA ? [ In reply to ]

Oct 24, 2023, 5:26 PM

Post #23 of 28 (315 views)

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/

Re: RPKI unknown for superprefixes of existing ROA ? [ In reply to ]

Oct 24, 2023, 5:28 PM

Post #24 of 28 (315 views)

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

Re: RPKI unknown for superprefixes of existing ROA ? [ In reply to ]

Oct 24, 2023, 5:29 PM

Post #25 of 28 (315 views)