Re: RPKI unknown for superprefixes of existing ROA ?

[Owen DeLong via NANOG]

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

Re: RPKI unknown for superprefixes of existing ROA ?

[Randy Bush]

> 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

Re: RPKI unknown for superprefixes of existing ROA ?

[Job Snijders via NANOG]

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.

¯\_(ツ)_/¯

Re: RPKI unknown for superprefixes of existing ROA ?

[Tom Beecher]

>
> 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  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  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  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  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  wrote:
>>
>>> On Sun, Oct 22, 2023 at 9:38 AM Tom Beecher  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
>>> b...@herrin.us
>>> https://bill.herrin.us/
>>>
>>
>

Re: RPKI unknown for superprefixes of existing ROA ?

[Owen DeLong via NANOG]

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  wrote:
> 
> On Sun, 22 Oct 2023 at 20:33, Tom Beecher  > 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 ?

[Owen DeLong via NANOG]

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  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  > 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 >> > 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 >> > wrote:
 On Sun, Oct 22, 2023 at 9:38 AM Tom Beecher >>> > 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
 b...@herrin.us 
 https://bill.herrin.us/

Re: RPKI unknown for superprefixes of existing ROA ?

[Willy Manga]

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


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: RPKI unknown for superprefixes of existing ROA ?

[Job Snijders via NANOG]

On Sun, 22 Oct 2023 at 20:33, Tom Beecher  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 ?

[Tom Beecher]

>
> 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  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  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  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  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  wrote:
>>>
 On Sun, Oct 22, 2023 at 9:38 AM Tom Beecher  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
 b...@herrin.us
 https://bill.herrin.us/

>>>

Re: RPKI unknown for superprefixes of existing ROA ?

[Amir Herzberg]

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  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  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  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  wrote:
>>
>>> On Sun, Oct 22, 2023 at 9:38 AM Tom Beecher  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
>>> b...@herrin.us
>>> https://bill.herrin.us/
>>>
>>

Re: RPKI unknown for superprefixes of existing ROA ?

[Tom Beecher]

>
> 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  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  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  wrote:
>
>> On Sun, Oct 22, 2023 at 9:38 AM Tom Beecher  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
>> b...@herrin.us
>> https://bill.herrin.us/
>>
>

Re: RPKI unknown for superprefixes of existing ROA ?

[Job Snijders via NANOG]

On Sun, 22 Oct 2023 at 19:35, Owen DeLong  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 ?

[Tom Beecher]

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  wrote:

> On Sun, Oct 22, 2023 at 10:06 AM Tom Beecher  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
> b...@herrin.us
> https://bill.herrin.us/
>

Re: RPKI unknown for superprefixes of existing ROA ?

[Owen DeLong via NANOG]

Look again, Tom. This is an attack vector using a LESS specific route. The /22 gets discarded, but a covering /0-/21 would not. OwenOn Oct 22, 2023, at 10:06, Tom Beecher  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  wrote:On Sun, Oct 22, 2023 at 9:38 AM Tom Beecher  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
b...@herrin.us
https://bill.herrin.us/

Re: RPKI unknown for superprefixes of existing ROA ?

[Owen DeLong via NANOG]

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. OwenOn Oct 22, 2023, at 08:47, Job Snijders via NANOG  wrote:On Sun, 22 Oct 2023 at 17:42, Amir Herzberg  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_matchAttackers 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 ?

[William Herrin]

On Sun, Oct 22, 2023 at 10:06 AM Tom Beecher  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
b...@herrin.us
https://bill.herrin.us/

Re: RPKI unknown for superprefixes of existing ROA ?

[Tom Beecher]

>
> 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  wrote:

> On Sun, Oct 22, 2023 at 9:38 AM Tom Beecher  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
> b...@herrin.us
> https://bill.herrin.us/
>

Re: RPKI unknown for superprefixes of existing ROA ?

[William Herrin]

On Sun, Oct 22, 2023 at 9:38 AM Tom Beecher  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
b...@herrin.us
https://bill.herrin.us/

Re: RPKI unknown for superprefixes of existing ROA ?

[Job Snijders via NANOG]

On Sun, 22 Oct 2023 at 18:10, William Herrin  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 ?

[Tom Beecher]

>
> 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
> , 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  wrote:

> On Sun, Oct 22, 2023 at 9:10 AM William Herrin  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
> b...@herrin.us
> https://bill.herrin.us/
>

Re: RPKI unknown for superprefixes of existing ROA ?

[William Herrin]

On Sun, Oct 22, 2023 at 9:10 AM William Herrin  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
b...@herrin.us
https://bill.herrin.us/

Re: RPKI unknown for superprefixes of existing ROA ?

[Rubens Kuhl]

On Sun, Oct 22, 2023 at 5:47 PM Job Snijders via NANOG  wrote:
>
> On Sun, 22 Oct 2023 at 17:42, Amir Herzberg  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 ?

[William Herrin]

On Sun, Oct 22, 2023 at 8:47 AM Job Snijders  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
b...@herrin.us
https://bill.herrin.us/

Re: RPKI unknown for superprefixes of existing ROA ?

[Job Snijders via NANOG]

On Sun, 22 Oct 2023 at 17:42, Amir Herzberg  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 ?

[Amir Herzberg]

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  wrote:

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

[William Herrin]

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 ?

[Mark Tinka]

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 ?

[Amir Herzberg]

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