Internet Routing Registries - RADb, etc

Can someone provide a little guidance on RADb (and other IRRs)?

Our organization is not a customer of any IRRs, but our ARIN IP allocation is registered in RADb and Level3's IRR. The majority of these entries are incorrect and list other AS#'s (AS's that have never been authorized to announce this IP space) as the originating AS for our ARIN IP allocation.

I have emailed Level3 about the incorrect entries in their IRR with no response. I have also emailed Cogent about their incorrect entry in RADb, also with no response.

Should I be concerned about these entries? Do these entries give someone the ability to announce our IP space? How is the information in these databases checked for accuracy and why did RADb and Level3 put these entries in their database when the posting party was not authorized to announce this space? And finally, what can be done to correct or remove these entries (as a non-customer of either RADb or Level3)?

Thanks in advance,
--Blake

It depends. Most organisations do not use IRRDBs for compiling prefix
lists, but some do. If you happen to get service from one of these
organisations, it's better to ensure that the prefixes are correctly
registered. Lots of European IXPs use IRRDBs for route-server prefix
filter lists, but this may not be relevant to you.

Level3 fills their IRRDB up with piles of crap. Good luck getting them to
remove anything.

RADB is well run, and if Cogent can't get their act together enough to
remove the entries from there, you can email Merit directly
(radb-support@merit.edu) and they can delete stuff, assuming that source:
is RADB and you can prove that you legitimately hold the address space.

Nick

Or perhaps this indicates that no one pays attention to what is in the
RAdb, and therefore makes a statement about the RAdb itself?

No idea myself...

- - ferg

I 100% agree with Nick. But, in dealing with Level3, you need Level3 Members Remarks in your objects to deal with multiple registries etc. They have an ok system that is a nightmare to pull from different datasources with them and they've churned the ultimately responsible individual a few times which makes it tough to get someone knowledgeable. Larry and team however at RADB will respond to remove your entries from someone else's stale records without much hassle.

Cogent will use your IRR data to generate a list the first time but they don't have a clue when it comes to keeping up to date.

The underlying problem is that there is incentive to enter objects (or have them entered for you) but none to remove old/stale/incorrect objects.

Eric

Blake,
   If you find that an RADb maintainer is unresponsive about removing
stale/incorrect objects in the RADb, we will review your request
and can remove the objects in question.

Regards,
  Larry Blunk
  Merit

Eric Krichbaum wrote the following on 1/15/2014 5:30 PM:

I 100% agree with Nick. But, in dealing with Level3, you need Level3 Members Remarks in your objects to deal with multiple registries etc. They have an ok system that is a nightmare to pull from different datasources with them and they've churned the ultimately responsible individual a few times which makes it tough to get someone knowledgeable. Larry and team however at RADB will respond to remove your entries from someone else's stale records without much hassle.

Cogent will use your IRR data to generate a list the first time but they don't have a clue when it comes to keeping up to date.

The underlying problem is that there is incentive to enter objects (or have them entered for you) but none to remove old/stale/incorrect objects.

Eric

From: Nick Hilliard [mailto:nick@foobar.org]
Sent: Wednesday, January 15, 2014 3:31 PM
To: Blake Hudson; nanog@nanog.org
Subject: Re: Internet Routing Registries - RADb, etc

I have emailed Level3 about the incorrect entries in their IRR with no
response. I have also emailed Cogent about their incorrect entry in
RADb, also with no response.

Should I be concerned about these entries? Do these entries give
someone the ability to announce our IP space? How is the information
in these databases checked for accuracy and why did RADb and Level3
put these entries in their database when the posting party was not
authorized to announce this space? And finally, what can be done to
correct or remove these entries (as a non-customer of either RADb or Level3)?

It depends. Most organisations do not use IRRDBs for compiling prefix lists, but some do. If you happen to get service from one of these organisations, it's better to ensure that the prefixes are correctly registered. Lots of European IXPs use IRRDBs for route-server prefix filter lists, but this may not be relevant to you.

Level3 fills their IRRDB up with piles of crap. Good luck getting them to remove anything.

RADB is well run, and if Cogent can't get their act together enough to remove the entries from there, you can email Merit directly
(radb-support@merit.edu) and they can delete stuff, assuming that source:
is RADB and you can prove that you legitimately hold the address space.

Nick

Thanks for the responses, these objects are all older. However, none of them are stale or from previous owners, allocations, etc. Each of these objects were posted to their respective IRR's after the IP space was allocated to us. This leads me to believe that the individual IRR's really do very little checking for accuracy and their usefulness is then questionable.

I have contacted Merit and found them to be responsive.

I will look at "securing" a spot in ARIN's and RIPE's databases, if possible. Hopefully this will make it unnecessary for someone to post an entry in a 3rd party IRR and possibly more difficult as well.

--Blake

Oh yeah. I got hit by that sort of thing a week or two back. It wasn't
origin: AS14179 / mnt-by: MAINT-AS28071, by any chance? AS14179 have been
hijacking chunks of space from the various registries.

Nick

Also, at least of the ones I've dealt with, there is no verification of records as they're entered. If your ASN/IPs are not already there, anyone can put them in under their own maintainer object. Since some providers do use IRR data to build and maintain customer prefix filters, it's not unusual for service providers to put customer ASNs/IPs into an IRR on behalf of their customers...and when the customer leaves, there's really no incentive to clean up and remove the objects.

on the RIPE IRRDB, there is validation, so you can't just go in and
register route: objects for someone else's allocations or assignments. Not
sure about the other RIRs, except for ARIN which doesn't support this on
rr.arin.net.

Nick

You mean auth for RIPE region prefixes, as one can also register
ARIN/APNIC/etc prefixes in the RIPEdb and then, there is no auth (but a
mail to dbm@ripe.net resolves any issues quite quickly if something fake
is there)

Greets,
Jeroen

Yep. For someone with non-RIPE NCC numbers the only manual part of the process is getting a maintainer object created. Once you've done that it's likely that your new parent route object in the RIPE db will be something like this:

inetnum: 199.91.32.0 - 199.255.255.255
netname: NON-RIPE-NCC-MANAGED-ADDRESS-BLOCK
descr: IPv4 address block not managed by the RIPE NCC
remarks: ------------------------------------------------------
remarks:
remarks: Networks in this range are not in use in
remarks: the RIPE NCC service region.
remarks:
remarks: You can find the whois server to query, or the
remarks: IANA registry to query on this web page:
remarks: http://www.iana.org/assignments/ipv4-address-space
remarks:
remarks: You can access databases of other RIR's at:
remarks:
remarks: AFRINIC (Africa)
remarks: http://www.afrinic.net/ whois.afrinic.net
remarks:
remarks: APNIC (Asia Pacific)
remarks: http://www.apnic.net/ whois.apnic.net
remarks:
remarks: ARIN (Northern America)
remarks: http://www.arin.net/ whois.arin.net
remarks:
remarks: LACNIC (Latin America and the Carribean)
remarks: http://www.lacnic.net/ whois.lacnic.net
remarks:
remarks: ------------------------------------------------------

which includes

mnt-routes: RIPE-NCC-RPSL-MNT

corresponding to

mntner: RIPE-NCC-RPSL-MNT
descr: This maintainer may be used to create objects to represent
descr: routing policy in the RIPE Database for number resources not
descr: allocated or assigned from the RIPE NCC.
admin-c: RD132-RIPE
auth: MD5-PW # Filtered
remarks: *******************************************************
remarks: * The password for this object is 'RPSL', without the *
remarks: * quotes. Do NOT use this maintainer as 'mnt-by'. *
remarks: *******************************************************
mnt-by: RIPE-DBM-MNT
referral-by: RIPE-DBM-MNT
source: RIPE # Filtered

Joe