[DBWG] All AFRINIC-administered IP space

[Frank Habicht]

Hi all,

I had some meta-info missing from my yesterday email.
Please allow me to correct/update.

On 24/07/2021 11:46, Frank Habicht wrote:

> Hi Ronald,

> 

<hat=personal>

> thanks for this longer explanation, and I personally think that it helps

> us all understand.

</hat>


> 

> 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. 

> 


<hat=personal>

> That is great to hear and after 2nd read I noted the past tense in the

> previous paragraph :-)

</hat>
<hat=co-chair>

> 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.

</hat>


>> 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.


<hat=network-operator>

> 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....

</hat>


>> 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.


<hat=community-member>> 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.

</hat>
<hat=co-chair>

> And we don't want to speculate /here/ about the reasons.

</hat>

<hat=co-chair>> 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?

</hat>

<hat=network-operator>

> 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.

</hat>


>> 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.


<hat=dbwg-member>

> 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.

</hat>
<hat=co-chair>

> 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.

</hat>


> Regards,

> Frank


sorry for the trouble.

Frank