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

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