Hank, all exact match for prefix length? Or longer subnets covering the
whole?
(Is this leakage of a optimizer or possibly censorship leakage?)
On Sun, Oct 22, 2023, 1:03 PM Olivier Benghozi
wrote:
> Same stuff (with our ASN and our prefixes) detected here, coming
> from AS2027 (Milkywan), for
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
Same stuff (with our ASN and our prefixes) detected here, coming
from AS2027 (Milkywan), for a short time...
Le dim. 22 oct. 2023 à 17:18, Hank Nussbacher a
écrit :
> We just had every single prefix in AS378 start being announced by AS2027.
>
> Every announcement by AS2027 is failing RPKI yet
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.
>
Lightweight…..If I didn’t get both middle fingers at the same time it meant I wasn’t trying. EdSent from my iPhoneOn Oct 20, 2023, at 10:18 PM, Heasley wrote:How i (choose to) remember Abha. https:/shrubbery.net/~heas/colleagues/abha.jpghttps:/shrubbery.net/~heas/colleagues/abha2.jpg
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
We just had every single prefix in AS378 start being announced by AS2027.
Every announcement by AS2027 is failing RPKI yet being propagated a bit.
Is this yet another misbehaving device or an actual attack?
Thanks,
Hank
22 matches
Mail list logo
