[routing-wg] 2019-08 New Policy Proposal (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/routing-wg/attachments/20191103/70766eec/attachment.html>