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
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
>
> 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
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
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:
.
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
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
>
> 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
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
>
> 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
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
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,
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
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
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
>
> 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
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.
>
>
>
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.
>
>
>
> 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.
>
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
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
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
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
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
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
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
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
28 matches
Mail list logo
