<html><head></head><body>This can be fixed by generating your own fake routes that would effectively blackhole all the unassigned traffic, using the publicated RIPE Invalid ROAs. <br><br>Maria<br><br><div class="gmail_quote">On November 3, 2019 5:12:54 PM GMT+01:00, Alexander Azimov <a.e.azimov@gmail.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div dir="ltr">Hi,<div><br></div><div>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? </div><div><br></div><div>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.<br></div><div><br></div><div><div>While I support the goals behind this proposal, it seems that ROA with its current model of use is not applicable for this purpose.<br></div><div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">сб, 2 нояб. 2019 г. в 14:15, Tim Bruijnzeels <<a href="mailto:tim@nlnetlabs.nl">tim@nlnetlabs.nl</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br>
<br>
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:<br>
<br>
- rpki ta key rolls<br>
- robustness wrt abuse of the system (producing thousands or millions of objects)<br>
- aspa path validation with rpki<br>
<br>
Tim<br>
<br>
<br>
> On 2 Nov 2019, at 10:52, Carlos Friaças via routing-wg <<a href="mailto:routing-wg@ripe.net" target="_blank">routing-wg@ripe.net</a>> wrote:<br>
> <br>
> <br>
> <br>
> Hi,<br>
> (please see inline)<br>
> <br>
> <br>
>> On Fri, 1 Nov 2019, Gert Doering wrote:<br>
>> <br>
>> Hi,<br>
>> <br>
>>> On Fri, Nov 01, 2019 at 07:09:42AM +0100, Job Snijders wrote:<br>
>>> So we really have to wonder whether this is worth it, or whether a few<br>
>>> emails or phone calls can also solve the issue.<br>
>> <br>
>> Isn't that the whole question underlying RPKI deployment?<br>
>> <br>
>> What is it that we want to stop with RPKI? Only classic "prefix hijacking"<br>
>> (announcing space that is formally delegated somewhere)<br>
> <br>
> With RPKI alone, mistakes.<br>
> <br>
> 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.<br>
> <br>
> If that *doesn't* happen, maybe some conclusions can be drawn.<br>
> (there is a recent thread on the NANOG list where someone raised that "feature"...)<br>
> <br>
> <br>
>> or other misuses<br>
>> of BGP, like "announce unallocated space, use that for spamming or other<br>
>> sorts of network attacks, withdraw announcement before people can track<br>
>> things back to you".<br>
> <br>
>> From *one* computer security emergency response team's angle:<br>
> RPKI is a good first step. Then, hopefully, ASPA can be added at some point.<br>
> <br>
> 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).<br>
> <br>
> 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...<br>
> <br>
> ps: i wish to express support for 2019-08 in its current form.<br>
> <br>
> Cheers,<br>
> Carlos<br>
> <br>
> <br>
> <br>
>> Gert Doering<br>
>> -- NetMaster<br>
>> -- <br>
>> have you enabled IPv6 on something today...?<br>
>> <br>
>> SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer<br>
>> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann<br>
>> D-80807 Muenchen HRB: 136055 (AG Muenchen)<br>
>> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279<br>
>> <br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Best regards,<div>Alexander Azimov</div></div></div>
</blockquote></div><br>-- <br>Sent from my Android device with K-9 Mail. Please excuse my brevity.</body></html>