This can be fixed by generating your own fake routes that would effectively blackhole all the unassigned traffic, using the publicated RIPE Invalid ROAs. Maria On November 3, 2019 5:12:54 PM GMT+01:00, Alexander Azimov <a.e.azimov@gmail.com> wrote:
Hi,
Let discuss the next scenario: there are two prefixes: x.x.0.0/24 and x.x.1.0/24, first one assigned to an ISP, second - unallocated. The proposal suggests that RIPE should create ROA with AS0 for x.x.1.0/24. Will it stop an attacker from squatting this address space?
The answer will be No. An attacker will still be able to hijack x.x.0.0/23, which will have an 'unknown' status and will be passed on, as a result finally capturing traffic for x.x.1.0/24.
While I support the goals behind this proposal, it seems that ROA with its current model of use is not applicable for this purpose.
сб, 2 нояб. 2019 г. в 14:15, Tim Bruijnzeels <tim@nlnetlabs.nl>:
Hi all,
I am not opposed to this in principle. I see some value. However, I think it would be good to take an impact analysis into account in order to prioritise this relative to other rpki improvements. I agree with others who have said that there may be more valuable things for the ripe ncc to focus on, eg:
- rpki ta key rolls - robustness wrt abuse of the system (producing thousands or millions of objects) - aspa path validation with rpki
Tim
On 2 Nov 2019, at 10:52, Carlos Friaças via routing-wg < routing-wg@ripe.net> wrote:
Hi, (please see inline)
On Fri, 1 Nov 2019, Gert Doering wrote:
Hi,
On Fri, Nov 01, 2019 at 07:09:42AM +0100, Job Snijders wrote: So we really have to wonder whether this is worth it, or whether a few emails or phone calls can also solve the issue.
Isn't that the whole question underlying RPKI deployment?
What is it that we want to stop with RPKI? Only classic "prefix hijacking" (announcing space that is formally delegated somewhere)
With RPKI alone, mistakes.
But when in doubt if network X has rights over network Y, it's rather simple to ask network X to create a proper ROA for network Y.
If that *doesn't* happen, maybe some conclusions can be drawn. (there is a recent thread on the NANOG list where someone raised that "feature"...)
or other misuses of BGP, like "announce unallocated space, use that for spamming or other sorts of network attacks, withdraw announcement before people can track things back to you".
From *one* computer security emergency response team's angle: RPKI is a good first step. Then, hopefully, ASPA can be added at some point.
Playing the quick withdraw game will only work (and it is working, i suspect!) until people start understanding they need to log who announces what to them (24/7/365).
Speaking about "network attacks" -- there is a lot of focus about the address space being hijacked, while major focus should be on those who receive the announcements. While it's terrible for the people/networks being impersonating, the potential targets are really everyone...
ps: i wish to express support for 2019-08 in its current form.
Cheers, Carlos
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
-- Best regards, Alexander Azimov
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.