This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[routing-wg] 2019-08 New Policy Proposal (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
- Previous message (by thread): [routing-wg] 2019-08 New Policy Proposal (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
- Next message (by thread): [routing-wg] 2019-08 New Policy Proposal (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Ehsan Ghazizadeh
ehsan.ccsp at gmail.com
Sun Nov 3 19:58:56 CET 2019
despite the fact that the amount of unassigned/unallocated IPv4 address blocks are so few, but I think the idea behind this proposal is merit, also I think it would be much more effective if it becomes a global policy on all RIRs. On Sun, Nov 3, 2019 at 9:50 PM Maria Matějka <jan.matejka at nic.cz> wrote: > 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 at 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 at 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 at 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. > -- http://about.me/AphroditeEmpire -------------- next part -------------- An HTML attachment was scrubbed... URL: </ripe/mail/archives/routing-wg/attachments/20191103/d127c524/attachment.html>
- Previous message (by thread): [routing-wg] 2019-08 New Policy Proposal (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
- Next message (by thread): [routing-wg] 2019-08 New Policy Proposal (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]