Adequate contact information in the RIPE database must be enforced (was: NCC#2008090071 Unreachable Italian Host)
Anonymized extracts from a correspondence between a phish takedown operator and the RIPE NCC: PIRT: "There's a phish on 192.0.2.227. The server is rooted. The address a@a.example.net in the IP whois comes back 'host not found'. The ASN address we have, b@b.example.net, comes back 'connect timeout'. c@c.example.net comes back 'Address rejected'. The webform on the allocee's website (such as it is) doesn't actually do anything.--RIPE can you contact the IP owner and get them to update your database please." RIPE NCC: "Please try contact the Network owners/maintainers. Phone number registered for the maintainer is correct and working." PIRT: "I'm a volunteer and don't have the resources to make international phone calls. Plus I don't speak Italian (I don't write Italian either but there are websites for translation, which is why email is preferable). Doesn't RIPE have the resources to do this? And isn't it in your interest to keep the database accurate? Otherwise what's the point? I have already emailed the d@d.example.net address. I have had no reply and the phish is still active." RIPE NCC: "There may be options we could pursue to check the validity of the contact data in the objects in the RIPE Database. Where we have a direct relationship with the owners of these objects we could request that they update this information. But we do not have a mandate from the RIPE community to allocate any resources to this activity." (End of correspondence extracts.) The issue of false or otherwise inadequate RIPE database entries has been discussed before in various RIPE working groups. It is bizarre that the problems nevertheless continue, year in and year out. Publishing sufficient and up-to-date contact information in the RIPE database should be an absolute prerequisite for holding any kind of RIR-allocated resource. Whenever a deficiency is discovered and reported, the RIPE NCC should efficiently and urgently contact the allocee, requiring a full and immediate correction. If one is not made, the resources should be deregistered. I realize that IP connectivity is not directly contingent on registration, but I also believe that allocees would still want to avoid having their resources bogonized. Should this pressure nevertheless prove insufficient, further sanctions, such as elevated fees, should be available. It is intolerable that important and urgent security-related communications repeatedly fail due to a lack of adequate contact information. -- Thor Kottelin CISM, CISSP fax +358 102 961 064 thor@anta.net, PGP 0x327B7345 http://www.anta.net/
Thor, On Wed, 2008-09-03 at 11:00 +0300, Thor Kottelin wrote:
It is intolerable that important and urgent security-related communications repeatedly fail due to a lack of adequate contact information.
I don't think it is intolerable (after all it has been this way for more than 15 years now), but it would be nice for someone to do the work necessary on an on-going basis to update contact information. There are a couple of problems with this though: 1. It costs money, both on the side of the NCC and the contact. 2. There is no enforcement mechanism. I would be happy for the NCC to spend money on this, but I don't represent an LIR. ;) For resources allocated or assigned to an LIR, this should be pretty straightforward. Every LIR pays a fee each year, after all! For other resources (PI blocks and AS numbers) it is more difficult, since there is no established relationship with anyone(*). But, it is still possible to look at the routing tables and contact peers to figure this out, with some work. This is probably more something for the services working group. (*) There is a proposal to fix this problem: http://www.ripe.net/ripe/policies/proposals/2007-01.html But there is a lot of resistance. You can view the various threads on the address policy working group for a sense of the discussion. -- Shane
Shane Kerr wrote:
Thor, [...] This is probably more something for the services working group.
And|Or the Anti-Spam/Anti-Abuse WG which is in the process of agreeing on an updated charter pretty soon. One thing that might be useful to mention and to keep in mind - for historical reasons the RIPE NCC and the RIPE WGs are not directly and efficiently linked in with the Incident Response (in the wider sense) community in Europe and worldwide. While there are (pretty efficient) mechanisms to register response contacts for "Incidents" in the DB (that should be used more widely!), there are other (and imho better) paths to pursue in case of phishing, botnet-hunting and the like. Either FIRST or TERENA's TF-CSIRT and the Trusted Introducer activity, ENISA's CERT Directory, or simply the connectivity providers as seen in a traceroute, come to my mind immediately.
(*) There is a proposal to fix this problem: http://www.ripe.net/ripe/policies/proposals/2007-01.html But there is a lot of resistance. You can view the various threads on the address policy working group for a sense of the discussion.
-- Shane
Wilfried, NOT wearing my DB-WG hat!
On Sep 3, 2008, at 1:36 PM, Shane Kerr wrote:
There are a couple of problems with this though:
1. It costs money, both on the side of the NCC and the contact. 2. There is no enforcement mechanism.
I would be happy for the NCC to spend money on this, but I don't represent an LIR. ;)
I do and I'm happy to support and even co-author a proposal about something like this. But at this point in time I can't think of any working solution as we indeed lack the tools to enforce.
For resources allocated or assigned to an LIR, this should be pretty straightforward. Every LIR pays a fee each year, after all!
For other resources (PI blocks and AS numbers) it is more difficult, since there is no established relationship with anyone(*). But, it is still possible to look at the routing tables and contact peers to figure this out, with some work.
It basically also goes for PA, escpecially large LIR's usually can have multiple role accounts and not every country/department keeps their info accurate. And then of course theirs the group who actually put contacts in for the customer using the space. If you go upstream to the allocations I think the organisation object can be pretty accurate as it's also used for certain communications between the LIR and NCC but I can imagine you want a more fine grain.
This is probably more something for the services working group.
Agree... MarcoH
participants (4)
-
Marco Hogewoning -
Shane Kerr -
Thor Kottelin -
Wilfried Woeber, UniVie/ACOnet