Re: Internet Routing Registries - RADb, etc
On 2014-01-16, at 18:21, Jeroen Massar jer...@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 d...@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 signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Internet Routing Registries - RADb, etc
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:n...@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-supp...@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
Re: Internet Routing Registries - RADb, etc
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
Re: Internet Routing Registries - RADb, etc
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 -- Another possible scenario. a.b.c.d/24-small_isp-regional_isp-Level3 Imagine a regional ISP is a customer of Level3. Level3 filters the regional ISP based on Regional ISP's IRR objects. Small ISP buys access from Regional. Small ISP doesn't maintain their own objects. Regional ISP wants Small's business so doesn't force the issue. Regional manually maintains the filters. Regional adds objects under Regional's maintainer whenever Small request a filter change. If they don’t, Level3 wont accept the announcement from them. Customer with a.b.c.d/24 has no idea about any of this. Now we are years later. Customer has either moved to another small ISP or Small ISP found a different regional ISP. a.b.c.d/24-small_isp-new_regional_isp-Level3 or a.b.c.d/24-new_small_isp-new_regional_isp-Level3 The original Regional ISP didnt remember to delete all the objects related to Small ISP's customers. The objects just sit there until one day customer has interest in registring their own object. Customer sees entries for their /24 under Regional ISP's objects. Customer knows they have never done business with Regional. Also the objects are newer than the customer's allocation from their RIR. Customer comes to the conclusion that Regional ISP must have been hi-jacking their space or doing some other naughtiness. Proxy registering objects isn't a good idea. However, the number of networks with allocations from ARIN registering objects in any IRR appears to be extremely low. ARIN doesn’t charge you more to use rr.arin.net. Folks seem to not be aware of IRR or perceive it provides no benefit to them. Will RPKI adoption suffer the same fate?
Re: Internet Routing Registries - RADb, etc
courtneysm...@comcast.net wrote the following on 1/16/2014 12:26 PM: 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 -- Another possible scenario. a.b.c.d/24-small_isp-regional_isp-Level3 Imagine a regional ISP is a customer of Level3. Level3 filters the regional ISP based on Regional ISP's IRR objects. Small ISP buys access from Regional. Small ISP doesn't maintain their own objects. Regional ISP wants Small's business so doesn't force the issue. Regional manually maintains the filters. Regional adds objects under Regional's maintainer whenever Small request a filter change. If they don’t, Level3 wont accept the announcement from them. Customer with a.b.c.d/24 has no idea about any of this. Now we are years later. Customer has either moved to another small ISP or Small ISP found a different regional ISP. a.b.c.d/24-small_isp-new_regional_isp-Level3 or a.b.c.d/24-new_small_isp-new_regional_isp-Level3 The original Regional ISP didnt remember to delete all the objects related to Small ISP's customers. The objects just sit there until one day customer has interest in registring their own object. Customer sees entries for their /24 under Regional ISP's objects. Customer knows they have never done business with Regional. Also the objects are newer than the customer's allocation from their RIR. Customer comes to the conclusion that Regional ISP must have been hi-jacking their space or doing some other naughtiness. Proxy registering objects isn't a good idea. However, the number of networks with allocations from ARIN registering objects in any IRR appears to be extremely low. ARIN doesn’t charge you more to use rr.arin.net. Folks seem to not be aware of IRR or perceive it provides no benefit to them. Will RPKI adoption suffer the same fate? I can understand the scenarios you've described. In fact, the timing does seem to indicate that someone was thinking they were doing something helpful (the route objects were introduced around the time we started announcing the allocation). The part that doesn't make sense is that one of the route objects has valid information and the other three were entered for AS #'s that are not peers of ours and should not have ever been transit paths to L3. We do peer with folks that peer with L3, however the route objects in L3's databases are for different ASs. I'm glad that ARIN provides an IRR, and hope to use it. With an authority that actually has the information necessary to perform authorization checks, I'm not sure why there's a need for independent IRRs to exist. Perhaps they filled a gap at some point in the past? --Blake
RE: Internet Routing Registries - RADb, etc
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_
Re: Internet Routing Registries - RADb, etc
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
Re: Internet Routing Registries - RADb, etc
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 d...@ripe.net resolves any issues quite quickly if something fake is there) Greets, Jeroen
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-supp...@merit.edu) and they can delete stuff, assuming that source: is RADB and you can prove that you legitimately hold the address space. Nick
Re: Internet Routing Registries - RADb, etc
-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-
RE: Internet Routing Registries - RADb, etc
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:n...@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-supp...@merit.edu) and they can delete stuff, assuming that source: is RADB and you can prove that you legitimately hold the address space. Nick
Re: Internet Routing Registries - RADb, etc
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
