In message <3E9D317C-F715-4208-AC13-9F874439E716@steffann.nl>, Sander Steffann <sander@steffann.nl> wrote:
How do you propose to distinguish people/companies with bad intentions (for some value of bad, let's assume "planning to send spam") from normal companies? It is certainly not self-evident.
It's an interesting question, but it is NOT one that is raised by the specific case of AS204224, I think. In this case, as I already pointed out, the name of the company, as shown in the RIPE WHOIS record, *and* the phone number also shown there, and perhaps also (I didn't check) even the mailing address in the WHOIS are all 100% correct and accurate. They all appear to point to a real, and most probably 100% legitimate oil & gas parts supplier. In this case, the available evidence suggests that the identity of this perfectly legitimate company was simply stolen, and then used by someone totally unconnected to the real company in order to obtain a RIPE AS registration. If my theory is correct, then this could have been prevented, quite simply, easly, and inexpensively, if RIPE NCC merely had a standing policy of performing an automated phone verification step when registering new entities and/or resources. In this case, the verification call would have gone to the real company, company personal would have been mystified by why they were being asked, by an entity they had never even heard of (RIPE NCC) to verify a request for something they themselves had never actually requested. Thus, the phone verification step would have failed, and the AS would never have been registered. Indeed if this process had existed, and if it had been applied also to the creation of entity records, then the record for ORG-CM117-RIPE (CJSC Mashzavod-Marketing-Servis), which itself was also only created on the same day as AS204224, would also have failed the phone verification steps and would also have never made it into the RIPE WHOIS data base.
"Self-evidently" is a lousy argument. The routes may be bogus in this case, but how do you propose to distinguish bogus routes from merely unusual routes?
I don't. In this specific case at least, the route announcements are merely an end-stage _symptom_ of the actual problem, which is that one, two, or perhaps three different fradulent AS registrations were accepted by RIPE NCC and installed into the WHOIS data base. Whoever is actually behind all this, whoever is actually pulling all of these shenanigans, that party quite obviously believed that they were going to be in some way better off if they began by registering some actual AS numbers, getting those registrations accepted by RIPE NCC, and getting them properly installed into the WHOIS data base. So that's precisely what they did. My best guess is that they believed that this step would help them to evade detection for a longer period of time, e.g. relative to the alternatives, which include (a) announcing their bogus routes using an unallocated/unassigned AS number or (b) announcing their bogus routes using someone else's already properly allocated and assigned AS. I can only agree with the thoughts and beliefs of the fraudsters in this case. If they had not been able to so easily steal the identity of an pre-existing legitimate company, then their scheme to route bogus address space might have been detected earlier, and perhaps even prevented altogether.
The issue isn't the announcement of out-of-region IP space. The issue is the self-evidently fradulent nature of the registration of, and the WHOIS record for, AS204224.
Again that lousy "self-evidently" argument. Please don't use that, it is often used by people who don't have any better arguments and want to fool the casual reader into agreeing with them without thinking. Real data please.
Here is the contact data for AS204224: person: Boris Soloviev address: 192284, city Sankt-Peterburg, av.Kosmonavtov 47, k.2B phone: +7-812-3630014 nic-hdl: BS8826-RIPE mnt-by: CJSCMMS-MNT created: 2015-07-21T17:43:59Z last-modified: 2015-07-21T17:43:59Z source: RIPE Someone needs to CALL the phone number listed there and simply ask if Mr. Soloviev is available. Once he is on the line, someone needs to ask if he even works for Mashzavod Marketing Services, and if so, whether or not he or his company requested an AS from RIPE NCC in early July. I would do it myself, but I don't speak Russian. (And I suspect that there is no firm requirement that contact persons listed in RIPE WHOIS records be even minimally profficient in English.)
Again: what exactly do you propose to do with this data? How does this help us make better policies?
See above. Two words: Phone verification.
How do you know that they don't have the right to announce those addresses? Is it unallocated space? In that case it's easy.
It _is_ unallocated (bogon) space in this case, so yes, it is easy.
Maybe suspicious with hindsight. Nothing that RIPE NCC could/should have acted on when the request was made.
I disagree. As noted above, I believe that a simple phone verification system, much like the one already used by Google Voice, by CraigsList, by credit card companies, and by countless other businesses would have prevented what appears to be a clear-cut case of identity fraud.
This policy refers to this policy on contractual requirements: https://www.ripe.net/publications/docs/ripe-637
Which includes: "the LIR is responsible for liaising with the resource holder to keep registration records up-to-date"
"the resource holder is obliged to provide up-to-date registration data to the LIR and that some or all of this registration data will be published in the RIPE WHOIS Database"
It is certainly a Good Thing that resource holders are required to be honest. I have asked however what, if anything, RIPE NCC has done or is doing to try to insure that they are not otherwise. (In this country, everyone is told from an early age that they ought to be honest. But people still do lock up their bicycles anyway.)
The RIPE Address Policy Working groups are where THE DECISIONS are made. It uses the Policy Development Process to reach those DECISIONS in an open and transparent way. If you don't care about the process: fine. But if you want to change policies then that's how you do it.
I have only learned/realized, during the course of this discussion, that what I was suggesting (phone verification of the validity of new WHOIS records) might represent a new policy. And quite frankly, I am stunned, amazed, and appalled to learn that existing RIPE policy does not, apparently, already mandate that RIPE NCC should do at least _something_ to verify the accuracy of WHOIS records. I mean my God! This isn't 1995! There are literally trillions of dollars of commerce flowing through the Internet on an annual basis now. And yet nobody thought that it might be a good idea to check to see if anybody who has an IP block even really is who they say they are?? (It appears that it may be easier to present fradulent information to RIPE NCC, and to have that accepted, than it would be to achieve the exact same feat at my own local convenience store.)
Or were you trying, in a back-handed sort of way, to tell me that the verification of phone and address parts of RIPE WHOIS records isn't being done because it wasn't even ever considered as being either necessary or useful enough to even insert the idea into the front end of the meat grinder known as "The Policy Development Process" ?
Policy usually doesn't contain details like that explicitly. It defines that registration data has to be up-to-date, and the implementation is done by RIPE NCC.
I take the strongest possible exception to your characterization of WHOIS data accuracy as a mere "detail".
The policies contain requirements for up-to-date data, and the RIPE NCC service contract does contain language against falsified, misleading and incorrect data.
Yes, and it is illegal to steal bicycles. But people do still lock them up at night anyway.
The big problem has always been: how do you verify that data?
In the case of phone numbers, it is simple: You call them. In the case of street addresses, it is also simple. RIPE NCC could ask either UPS, or any one of the myriad companies that are in business exactly and only to supply other parties with software and/or services to check the legitimacy and accuracy of postal addresses. This isn't impossible. It isn't even hard. It isn't even expensive. This isn't rocket science. Plenty of companies who need to deliver products are already doing this, day in and day out, 365 days a year.
The RIPE NCC covers a huge service region with many different jurisdictions. Some are politically unstable (this might be an understatement) like Syria and Ukraine. How do you propose an association based in The Netherlands like the RIPE NCC consistently verifies business records, phone numbers and addresses in such a variety of countries and jurisdictions?
See above. For phone numbers, simply calling them would be a good (and, I would have thought) obvious start. Readily available VOIP services already make this easy and fabulously inexpensive to any and all countries throughout the world. For mailing addresses, I respectfully suggest googling for "mailing address validation" and start reading. Again, this isn't rocket science. Numerous companies already offer this as a professional service. It is not expensive. And you'll have to excuse me for saying so, but this nonsense you raise about "political instability" is just that, nonsense. Are people and entities to whom RIPE resources have been given required to have a working phone number or not? Are all of the phone lines down in either Ukraine or Syria? And if they are, if these people don't even have working telephones, then what the hell do they need the Internet for?? It would seem that they have bigger problems to worry about. Should we worry also that the penguins in Antartica won't be able to obtain RIPE number resources because they also don't have working phones?
Complaining that "things should be better" is easy. But the RIPE NCC isn't a government entity or a business. It's an association of people and organisations. And the policies it implements are those decided on by the wider RIPE internet community, which is open to all. If things need to improve it is there that the work needs to be done. I have asked you a number of questions, and I think those are the questions that need to be though about and answered if you want to make things better.
You have thoughtfully replied, for which I thank you. I believe that I have done likewise.
PS: And then you should also remember that not all resources are allocated or assigned to businesses. A private person can also hold address space and ASNs (popular amongst network engineers, but also for e.g. small associations and other groups). There needs to be a balance between public records and privacy there.
Wait just a minute now. I've said, as clearly as I can, that RIPE NCC should be taking at least some minimal, practical, and inexpensive steps to verify both the mailing addresses and the phone numbers that appear in RIPE WHOIS records. There is no reason in the world that this cannot be just as easily done for individuals as it can be for businesses. Both have phone numbers. Both have addresses. There is no practical distinction. But at the very last minute you have elected to throw the ultimate spanner (or as we here say, monkey wrench) into the works, i.e. "privacy". (And you'll have to excuse me, but I cannot help but think that you did so in order to derail any progress on WHOIS accuracy.) Is "privacy" actually a consideration when discussing the accuracy (or lack thereof) of RIPE WHOIS records? If so, when exactly did THAT happen? Are we going to wake up one morning in the very near future and find that the RIPE WHOIS data base, like the domain name WHOIS data base before it, has fallen victim to the religious fervor and zelotry of the "privacy" lobby, and that most RIPE WHOIS records, particularly ones behind which lurk criminal activities, are masked and concealed behind dubious "services" which cloak the true identity of the true registrant? Is this kind of ludicrous and counter-productive "privacy" already a stated RIPE policy goal? Regards, rfg