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
On 15/01/2014 21:22, Blake Hudson wrote:
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
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 -----Original Message----- 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 On 15/01/2014 21:22, Blake Hudson wrote:
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
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
-----Original Message----- 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
On 15/01/2014 21:22, Blake Hudson wrote:
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
On 16/01/2014 14:32, Blake Hudson wrote:
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.
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
On Wed, 15 Jan 2014, Eric Krichbaum wrote:
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.
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. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On 16/01/2014 21:22, Jon Lewis wrote:
Also, at least of the ones I've dealt with, there is no verification of records as they're entered.
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
On 2014-01-16 23:11, Nick Hilliard wrote:
On 16/01/2014 21:22, Jon Lewis wrote:
Also, at least of the ones I've dealt with, there is no verification of records as they're entered.
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.
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
On 2014-01-16, at 18:21, Jeroen Massar <jeroen@massar.ch> wrote:
On 2014-01-16 23:11, Nick Hilliard wrote:
On 16/01/2014 21:22, Jon Lewis wrote:
Also, at least of the ones I've dealt with, there is no verification of records as they're entered.
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.
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)
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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 On 1/15/2014 1:22 PM, Blake Hudson wrote:
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
- -- Paul Ferguson PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLW/kkACgkQKJasdVTchbJL0AD/eU+UD9adD33gOw3YHyD8TjaE l2ISHTI628wbF+jZSmUA/0rj0WrWrba6HqCrNsnhgIp2DClJqCYLAD8m0a1xbtG7 =coKB -----END PGP SIGNATURE-----
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 ----- Original Message -----
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
participants (8)
-
Blake Hudson -
Eric Krichbaum -
Jeroen Massar -
Joe Abley -
Jon Lewis -
Larry J. Blunk -
Nick Hilliard -
Paul Ferguson