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 <[email protected]> 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 <[email protected]>: > >> 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 < >> [email protected]> 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.
