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
