You are here: Home > Participate > Join a Discussion > RIPE Forum
RIPE Forum v1.4.1

Routing Working Group

Threaded
Collapse

Re: [routing-wg] [anti-abuse-wg] 2019-08 New Policy Proposal (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space) to be discussed on Routing Working Group Mailing List

User Image

Randy Bush

2019-12-23 11:39:43 CET

erik,

> Personally, I'm not in favour of this policy as I don't like the NCC
> to start to injecting ROA's that are not allocated or assigned to
> members or end-users.
> 
> I think it sets the wrong precedence for the community and it could
> open up for scope creep to abuse the system for other usage.  So on
> that regards, I wouldn't mind if the proposal would be dropped.

first, as $subject says, if anywhere, this should be in the routing wg.
let us resist the inclination to make what was the anti spam wg the net
police, judge, and jury.

on the proposal itself, i am of two minds.  while i see negligible
initial harm, it's not clear it will do a lot of good.  and i see your
point about the slippery slope of mission creep.

i do find it amusing that it uses the singular case where an ROV origin
can not be 'usefully' forged.  i.e. the attacker can not postpend AS 0
and have it accepted.  but this cute factor still does not sell the
proposal to me.

randy

User Image

Tim Bruijnzeels

2019-12-23 12:18:49 CET

Hi

> On 23 Dec 2019, at 11:39, Randy Bush <randy _at_ psg _dot_ com> wrote:
> 
> erik,
> 
>> Personally, I'm not in favour of this policy as I don't like the NCC
>> to start to injecting ROA's that are not allocated or assigned to
>> members or end-users.
>> 
>> I think it sets the wrong precedence for the community and it could
>> open up for scope creep to abuse the system for other usage.  So on
>> that regards, I wouldn't mind if the proposal would be dropped.
> 
> first, as $subject says, if anywhere, this should be in the routing wg.
> let us resist the inclination to make what was the anti spam wg the net
> police, judge, and jury.
> 
> on the proposal itself, i am of two minds.  while i see negligible
> initial harm, it's not clear it will do a lot of good.  and i see your
> point about the slippery slope of mission creep.
> 
> i do find it amusing that it uses the singular case where an ROV origin
> can not be 'usefully' forged.  i.e. the attacker can not postpend AS 0
> and have it accepted.  but this cute factor still does not sell the
> proposal to me.

I agree with the above. Further, as Alexander Azimov pointed out: people can just announce a *less* specific, which will be "Not Found" even if an AS0 ROA exists for more specific. And because there is no competing (valid/not found) announcement they will attract the traffic.

So, it seems that these AS0 ROAs will not be very effective.


Tim


User Image

Randy Bush

2019-12-23 20:19:26 CET

> as Alexander Azimov pointed out: people can just announce a *less*
> specific, which will be "Not Found" even if an AS0 ROA exists for more
> specific. And because there is no competing (valid/not found)
> announcement they will attract the traffic.

this was brought up in the sidr wg when as0 was first proposed.  but it
is very hard to stop the bright idea train in sidr[ops] or the ietf in
general.

randy

Ronald F. Guilmette

2019-12-24 00:08:35 CET

Regarding this general idea of having some authority make route
announcements for unallocated/unassigned blocks, Mr. Azimov is
quite clerly correct that Bad Actors could still promulgate more
specific announcements.  The solution is obvious.  All such preemptive
announcements could be deaggregated down to the /24 level.  This
would not be dramatically different from what innumerable foolish
providers are already doing on a fairly routine basis, and the net
effects would surely make the equipment vendors almost as happy as
IPV6.

An alternative that seems to have gotten rather less attention would
be to simply work to try to get all of the toxic sludge that is
currently present in various IRRs (not including RIPE anymore, thank
goodness) cleaned up.  Until such time as more than 50% of the net
is actively using and relying on RPKI, this is the low hanging fruit
with regards to routing security.

The most glaring offender is RADB.

Today, even nearly a month after the ``explosive'' article in the
South African publication mybroadband.co.za regarding the activities
of a corrupt insider in Afrinic, and even after reports relative to
that have allegedly been filed with relevant law enforcement bodies,
I daresay that there are still route objects in RADB for a fair amount
of the illictly purloined IPv4 space.  But that is not even nearly the
end of the rot that is present there.  Additionally, I have seen
instances of route objects in RADB involving IPv4 blocks that were
formally and fully reclaimed by the relevant RIRs years ago, and
in a similar vein, RADB also contains route objects for ASNs that
were likewise reclaimed by their respective RIRs years ago.  I have
written to the RADB maintainers about some of these issues in the past.
My emails were ignored and I was not even given the courtest of a reply
to inform me that my messages were being ignored.  In short, it appears
from where I sit that RADB is being run on autopilot.  It is certainly
not being "maintained" in any sense of the word that I am familiar with.

If RADB were a toxic waste dump, it would be among those that we here
in the U.S. refer to as a "Superfund site".

I feel sure that other IRRs have some or all of the same issues.  RADB
stands out however due to its continued widespread use.

I say again that the glaring issues relating to the serious lack of
competent maintenance of IRRs generally is the low hanging fruit of
routing security.  As such, my hope is that others will join me in
at least trying to get the attention of RADB management focused on a
long-overdue and badly-needed competent cleanup effort.


Regards,
rfg

Job Snijders

2019-12-24 00:34:03 CET

Dear all,

On Tue, Dec 24, 2019 at 12:09 AM Ronald F. Guilmette
<rfg _at_ tristatelogic _dot_ com> wrote:
> I feel sure that other IRRs have some or all of the same issues.  RADB
> stands out however due to its continued widespread use.

The above statement is true, and the good news is that there is work
under way to reduce the clutter!

The largest IRRs (RADB, NTTCOM, ARIN, ALTDB, others) are either
actively working on, or have added to their roadmap, a variant of this
type of cleanup: https://www.ripe.net/publications/docs/ripe-731

For most of these IRR operators there is a project dependency on IRRd
4's ability to delete or suppress IRR "route:" objects that are in
conflict with RPKI data. This is tracked in
https://github.com/irrdnet/irrd4/issues/197 and hopefully the code can
be made available in Q1 2020 as part of the "IRRd 4.1" release. This
release in turn means for most organisations that they can probably
deploy in Q2 or Q3 2020 (after internal software testing & customer
outreach).

Given that there is active work underway in the community - I would
like to suggest that the topic of "stale data in IRRs" is brought up
again in about 6 months. After the deployment of IRRd 4.1 we'll have a
better view on what is still needs to be cleaned up and what mechanism
can be used.

Kind regards,

Job

Ronald F. Guilmette

2019-12-24 01:57:28 CET

In message <CACWOCC--q4g06o62Emtw08Skt+AY9EL4VOTAURRHHJkt+HR1+g _at_ mail.gmail _dot_ com>
Job Snijders <job _at_ ntt _dot_ net> wrote:

>On Tue, Dec 24, 2019 at 12:09 AM Ronald F. Guilmette
><rfg _at_ tristatelogic _dot_ com> wrote:
>> I feel sure that other IRRs have some or all of the same issues.  RADB
>> stands out however due to its continued widespread use.
>
>The above statement is true, and the good news is that there is work
>under way to reduce the clutter!
>
>The largest IRRs (RADB, NTTCOM, ARIN, ALTDB, others) are either
>actively working on, or have added to their roadmap, a variant of this
>type of cleanup: https://www.ripe.net/publications/docs/ripe-731

Long overdue, IMHO.  I mean it isn't as if the bogus/fradulent routing
problem just appeared last month or anything.  The games and funny business
have been going on for years now, aided and abetted, in many cases, by an
apparent utter lack of attention by IRR oprrators.

>For most of these IRR operators there is a project dependency on IRRd
>4's ability to delete or suppress IRR "route:" objects that are in
>conflict with RPKI data. This is tracked in
>https://github.com/irrdnet/irrd4/issues/197 and hopefully the code can
>be made available in Q1 2020 as part of the "IRRd 4.1" release. This
>release in turn means for most organisations that they can probably
>deploy in Q2 or Q3 2020 (after internal software testing & customer
>outreach).
>
>Given that there is active work underway in the community - I would
>like to suggest that the topic of "stale data in IRRs" is brought up
>again in about 6 months...

With all due respect to my friend Job, I am, have been, and remain totally
flummoxed and appalled by the consistant lack of urgency, within the
Internet community generally, with respect to what could be, quite
obviously, a swift, effective, and sensible resolution of many of these
problems, even without the need for any grand policy pronouncements or
fornalized ratifications thereof.  It shouldn't take a genius to note
that multiple conflicting route objects cannot all be right, or that
route objects to reserved or unallocated space, or involving reserved
or unallocated ASNs are, on their faces, utter rubbish which can be and
which ought to be removed from any IRR that contains them, immediately if
not sooner.

If any of these RIR operators are unable to develop scripts, within one
man-week, which would detect and purge route objects for unallocated
space or involving unallocated ASNs, then they obviously are reserving
their available cash for Christmas parties or executive bonuses in lieu
of adequate salaries for competent professional software engineers, and
even in those cases, I stand ready to volunteer my time to help each one
to do its homework, as may be needed... and not six months from now, but
by early January.

Clearly, an awful lot of people are not looking at the things I am looking
at, and this is apparently the root of the problem when it comes to the
apparent lack of urgency.  It is unfortunate that I must coordinate with
others in order to arrange for properly timed releases of what I know, but
that is unavoidable.  In the meantime, I can only state for the record
that if people knew about the various kinds of criminality that are
currently ongoing with and from a lot of these bogus and, for now at
least, IRR-sanctioned routes, then people wouldn't be taking the relaxed
attitude that all of this can and should be revisited in six months.
Innocent victims are being conned, ripped-off, and hacked every single
day, and as inconvenient as it may be for the rest of us, the scammers,
hackers, and criminals of the Internet are quite certainly not taking
Christmas off, nor are they dedicating any of their time to long term
scheduling, lengthy policy debates, committee meetings, or the development
of roadmaps.

I see no compelling reason why all IRRs either cannot or should not be
able to remove from their respecting published data bases 100% of all
route objects that refer to unalocated number resources by no later
than 2020-01-01 00:00:00 UTC, nor do I see any compelling reason why
they should not do so.  This is not rocket surgery.  Failure to take
these obvious remedial actions, and in short order, represents an
implicit acceptance of the victimization of yet more innocent parties.


Regards,
rfg

User Image

Petrit Hasani

2019-12-23 17:36:31 CET

RIPE NCC staff member

Hello Erik,

The Discussion Phase for 2019-08 ended on 29 November (note that this proposal is being discussed in the Routing WG).

The proposers and WG chairs have agreed that this can continue to the Review Phase with some updates to incorporate the community's input from the initial Discussion Phase.

When we receive this updated version, we will prepare our impact analysis of the proposal. The Review Phase will begin once we publish both of these documents.

Best wishes to everyone in the working group.

Regards

--
Petrit Hasani
Policy Officer
RIPE NCC





> On 23 Dec 2019, at 09:55, Erik Bais <erik _at_ bais _dot_ name> wrote:
> 
> Hi Petrit & Brian,
> 
> Could you provide some insight on the status of this proposal ?
> 
> I've seen not much (if at all...) discussion on the topic on the ML.
> 
> I've seen that the discussion phase is already passed and we are more than a month further . . . and even for the AA-WG ML, with no replies, that is probably one of the first ...
> 
> Personally, I'm not in favour of this policy as I don't like the NCC to start to injecting ROA's that are not allocated or assigned to members or end-users.
> 
> I think it sets the wrong precedence for the community and it could open up for scope creep to abuse the system for other usage.
> So on that regards,  I wouldn't mind if the proposal would be dropped.
> 
> Regards,
> Erik Bais
> 
> 
> 
> On 31/10/2019, 15:40, "anti-abuse-wg on behalf of Petrit Hasani" <anti-abuse-wg-bounces _at_ ripe _dot_ net on behalf of phasani _at_ ripe _dot_ net> wrote:
> 
>    Dear colleagues,
> 
>    A new RIPE Policy proposal, 2019-08, "RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space", is now available for discussion in the Routing Working Group
> 
>    This proposal aims to instructs the RIPE NCC to create ROAs with origin AS0 for all unallocated and unassigned address space under its control.
> 
>    You can find the full proposal at:
>    https://www.ripe.net/participate/policies/proposals/2019-08
> 
>    This proposed policy may be of interest to the Anti-Abuse working group as well.
> 
>    Therefore, we encourage you to review this proposal and send your comments to <routing-wg _at_ ripe _dot_ net> before 29 November 2019.
> 
>    Kind regards,
> 
>    --
>    Petrit Hasani
>    Policy Officer
>    RIPE NCC
> 
> 
> 
> 
> 
> 
>