[DBWG] All AFRINIC-administered IP space

[Frank Habicht]

Hi Ronald,

thanks for this longer explanation, and I personally think that it helps
us all understand.


On 24/07/2021 00:58, Ronald F. Guilmette wrote:

> ...

> I should perhaps explain why I would like to have a list of all AFRINIC

> administered IP space.

> 

> As we all know, routing on the Internet is, at the present time, still quite

> fraught with insecurity.  Until the whole world starts accepting (and also

> enforcing) RPKI checks, there will remain quite a lot of goofy stuff on the

> Internet when it comes to routing.

> 

> Of course, anybody can just announce a route to any IP space they like and

> nobody can really stop them from doing that.  But in the absence of any

> "authority" that effectively "validates" a given route, the route announcement

> itself is likely to get filtered.

> 

> The world has not yet fully adopted RPKI so when it comes to validating

> routes, the world still relies a lot on Internet Route Registries (IRRs).

> And it is to be hoped that each of these will contain only "good" and

> "valid" information.  Sadly, that is not even nearly the case.  I've

> been researching this recently, so I know.

> 

> Each of the five Regional Internet Registries operates its own IRR...

> in the case of both RIPE and ARIN, they actually each operate -two-

> of these... a so-called "AUTH" IRR and also a "NONAUTH" one.  Anyway,

> my research has shown that -all- of the IRRs being operated by all of

> the RIRs have had some provably invalid route objects in them... either

> (a) routes that are invalid because they refer to "bogon" (unassigned) IP

> address space or else (b) routes that refer to "bogon" (unassigned) AS

> numbers.  I have been trying to work with all five of the RIRs to get

> these "bogon" route objects eliminated from their respective IRRs.

> 

> I am pleased to say that AFRINIC has been most cooperative in this effort,

> and that AFRINIC now has exactly and only -zero- bogon route objects in

> its IRR. 


That is great to hear and after 2nd read I noted the past tense in the
previous paragraph :-)

I think it's in all our interest to have and keep the IRRs as much as
possible in a state that's extremely close to the truth, authoritative
and trusted.


> Alas, the IRRs that belong to the four other RIRs are still a

> work in progress, and each are still in need of more cleanup to insure

> that they contain only 100% valid route objects.

> 

> The only other IRR that seems to be in really widespread use is is the

> privately operated one that is run by Merit, Inc. in the U.S. and that

> is called "RADB".  Sadly, this one has minimal security and apparently

> no routine maintenance of any kind.  As a result, it has, over time

> accumulated a LOT of bogon route objects, many of which were abandoned

> by their creators, long long ago, and many of which have been quite

> deliberately created by Internet criminals and miscreants.

> 

> My long term hope is that I'll be able to get bogon route objects removed

> not just from the IRRs that are operated by the five RIRs, but also from

> the RADB data base as well.


I agree that making RADB "cleaner" than now would make a positive
operational impact.


> Unfortunately, the folks at RADB don't listen to me when I tell them

> about problems in their published route data.  (I think that maybe they

> don't like me.  If so, they would certainly not be alone.)  But I've

> been informed that they *do* listen when any RIR staff talks to them.


I've once-or-twice told them of much more specific problems, with
explanation and supporting info for each case, and it went ok.
*maybe* too much change at once makes it "suspicious" to them....



> So, here is the bottom line:

> 

> Within the RADB there currently exists vast gobs of bogon route objects

> that refer to IP space that is administered by AFRINIC but which is

> currently not *assigned* by AFRINIC to any party.  The effect of at

> least some of these RADB route objects is to allow various parties to

> freeload off of unassigned AFRINIC-administered address space.

> 

> Here is a clear example:

> 

>     https://bgp.he.net/AS37155#_prefixes

> 

> I believe that all of the IPv4 address blocks shown on the above page are

> (a) administered by AFRINIC and also (b) unassigned to any party by AFRINIC

> at the present time.


I occasionally download -delegated files.
I see (AS) "37155" and "41.72.0.0" delegated to the same entity until
(at least) 20200825 and not delegated from 20210101. So there's a case
where resources (that once were delegated) were apparently de-registered.
And we don't want to speculate /here/ about the reasons.

Maybe for our understanding: could AfriNIC staff confirm that
- in this case of ORG-NT1-AFRINIC, or
- in general, per internal procedure
members are contacted before de-registration of resources?


>From personal experience I know that even upstream providers of members

are contacted in case of no responding contact with the member.
I've also come to know of one member returning resources after they were
such contacted, because of "no need" - well.....

Knowing of again other entities, that had resources de-registered, but
later got into contact with AfriNIC and got the same resources
re-instated, I am wondering if this could be a similar case.


> Please notice all of the GREEN checkmarks next to the routes shown.  Those

> are indicating that *some* IRR contains a corresponding route object for

> each of the routes shown.

> 

> As it turns out, the specific IRR that contains the corresponding route

> objects for all of these routes is RADB.

> 

> The problem here isn't just that someone is squatting on unassigned AFRINIC-

> administered IP address space.  The real problem is that RADB is, in effect,

> *validating* those route announcements as being "legitimate".

> 

> I'd like to persuade RADB to stop doing that.  But I alone cannot do that

> because they don't listen to me.

> 

> What I would like to do instead is to create a list of *all* of the bogon

> route objects currently present in the RADB route registry and that refer

> to any AFRINIC-administered IP space, and then send that whole list to

> hostmaster(at)afrinic.net along with my request that AFRINIC itself

> should ask the RADB people to delete all of the bogon routes they have

> that refer to (unassigned) AFRINIC-administered IP space.

> 

> Obviously, in order to carry out this plan, I need to start by having a

> list of all AFRINIC-administered IP space... both assigned and unassigned.


So this is the important first step and I'm in agreement that this
should be published. From previous email, we understand Nishal to think
the same. Any input from others?



> Equally obviously, *someone* on the AFRINIC staff *must* have such a list.

> Otherwise, how would AFRINIC know what is "their's" and what isn't?


Yep.

Regards,
Frank