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 _______________________________________________ DBWG mailing list [email protected] https://lists.afrinic.net/mailman/listinfo/dbwg
