Re: [ncc-services-wg] RIPE50 - NCC Services WG Draft Minutes
Dear Sir, let me second Mr. Hank Nussbacher's proposal. CESNET, the Czech Republic NREN, had been using the RIPE NCC hostcount data since 1997 for the same purpose. Its use is briefly described in the CESNET 1998 Annual report: http://www.cesnet.cz/doc/zprava1998/kap04.html (unfortunately, only the Czech language version seems to be available now). This data has been extremely useful for us as it helped us find organisations trying to misuse the CESNET IP space. Our access to the raw hostcount data stopped in January 2005 as well. Best regards, Pavel Vachek, CESNET NIC, Prague, The Czech Republic. On Mon, 27 Jun 2005, Hank Nussbacher wrote:
As someone who was not at RIPE50 but who uses hostcount, I would like to add my comments and support. I find this service extremely useful. One real world use is as follows: the university network in Israel has IP addresses spanning a range of about 16 /16s. All domain names inside the universities should terminate with ac.il or at the worst org.il. But often students take a university Unix system that they have access to and start using it for non-academic purposes (left as an exercise for the reader to think of what constitutes non-academic :-)). Using grep on the raw data file I can easily spot those systems that are running questionable content based on their domain name (co.il for example).
Sometimes, hackers change an IP address to some name that has certain character strings that are unique to the hacker realm. By running a series of greps on the raw data file I can find those systems that may have been compromised and contact the appropriate ISP in Israel.
So please - make hostcount work again. Incidentally, it stopped working in Jan 2005.
Regards, Hank
Pavel Vachek wrote:
This data has been extremely useful for us as it helped us find organisations trying to misuse the CESNET IP space. Our access to the raw hostcount data stopped in January 2005 as well.
while this is tempting and depending on who actually does the necessary "grep" might be covered by the AUP, I'd like to state that the issue is two-edged. First, it's never complete, so you only find those organisations who both happen to use the wrong IP addresses and are within your TLD, while nothing prevents them from using COM, BIZ or XXX {filter food} names as well. Second, and more important, this kind of policing, although it has been done for years, might reduce the willingness of affected and other parties to allow AXFR access. Experience shows that many organisations have only and explicitly granted AXFR access to support the hostcount statistics data collection (and some DNS quality postprocessing). So, declaring "raw data access" a feature of the hostcount is detrimental to its success. It was a side effect that's gone. -Peter PS: Just to be clear: the DE hostcount raw data must not be published.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear Peter, you wrote:
First, it's never complete, so you only find those organisations who both happen to use the wrong IP addresses and are within your TLD, while nothing prevents them from using COM, BIZ or XXX {filter food} names as well.
You are perfectly right. I have been using only the `.cz' hostcount TLD raw data and no other TLD data because I thought that this was the most common kind of misuse here.
Second, and more important, this kind of policing, although it has been done for years, might reduce the willingness of affected and other parties to allow AXFR access. Experience shows that many organisations have only and explicitly granted AXFR access to support the hostcount statistics data collection (and some DNS quality postprocessing). So, declaring "raw data access" a feature of the hostcount is detrimental to its success. It was a side effect that's gone.
Noone from our TLD has ever complained about my access to the hostcount data. If they did not like it, they probably just inhibited the AXFR access to their domains.
-Peter
PS: Just to be clear: the DE hostcount raw data must not be published.
I had never even looked at it. Whan I was signing the Hostcount AUP statement I had explicitly written that I was interested only in the `.cz' TLD data. Best regards, Pavel Vachek, CESNET NIC, Prague. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: For info see http://quantumlab.net/pine_privacy_guard/ iD8DBQFCxCE7Prynl47KNS4RApkFAKCSJVv2I9XqDvHXM8nmpAsH9H5EDACglI7B IAVhKETXRk01V0wFvV989EQ= =JoNT -----END PGP SIGNATURE-----
On Thu, 30 Jun 2005, Pavel Vachek wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dear Peter, you wrote:
First, it's never complete, so you only find those organisations who both happen to use the wrong IP addresses and are within your TLD, while nothing prevents them from using COM, BIZ or XXX {filter food} names as well.
You are perfectly right. I have been using only the `.cz' hostcount TLD raw data and no other TLD data because I thought that this was the most common kind of misuse here.
I only access the .il hostcount raw data and have only a need to access that particular cctld and am willing to be either technically or administratively limited that cctld. -Hank
Second, and more important, this kind of policing, although it has been done for years, might reduce the willingness of affected and other parties to allow AXFR access. Experience shows that many organisations have only and explicitly granted AXFR access to support the hostcount statistics data collection (and some DNS quality postprocessing). So, declaring "raw data access" a feature of the hostcount is detrimental to its success. It was a side effect that's gone.
Noone from our TLD has ever complained about my access to the hostcount data. If they did not like it, they probably just inhibited the AXFR access to their domains.
-Peter
PS: Just to be clear: the DE hostcount raw data must not be published.
I had never even looked at it. Whan I was signing the Hostcount AUP statement I had explicitly written that I was interested only in the `.cz' TLD data.
Best regards, Pavel Vachek, CESNET NIC, Prague. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: For info see http://quantumlab.net/pine_privacy_guard/
iD8DBQFCxCE7Prynl47KNS4RApkFAKCSJVv2I9XqDvHXM8nmpAsH9H5EDACglI7B IAVhKETXRk01V0wFvV989EQ= =JoNT -----END PGP SIGNATURE-----
+++++++++++++++++++++++++++++++++++++++++++ This Mail Was Scanned By Mail-seCure System at the Tel-Aviv University CC.
Wouldn't it be more reasonable, and straightforward, to obtain the particular ccTLD's raw data from the particular environment locally? I really don't like the NCC being somewhere in that loop, evne if it is "only" on a technical level... Wilfried.
participants (4)
-
Hank Nussbacher -
Pavel Vachek -
Peter Koch -
Wilfried Woeber, UniVie/ACOnet