[anti-abuse-wg] WHOIS (AS204224)
- Previous message (by thread): [anti-abuse-wg] WHOIS (AS204224)
- Next message (by thread): [anti-abuse-wg] WHOIS (AS204224)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Brian Nisbet
brian.nisbet at heanet.ie
Tue Nov 3 14:27:55 CET 2015
As an additional and very important note, to clarify what I have said below, my intent is not to micro-manage the activities of the NCC. The implementation details would come from conversation & collaboration with the NCC and not be contained within the policy. Apologies if I was not clear earlier. Brian On 03/11/2015 10:20, Brian Nisbet wrote: > Ronald, > > I'm not finding a great place to ask these questions in your > conversation with Sander, so I'm going to ask them here. > > You said, at one point, that you did not see the point in reporting > these issues, or even just specifically the AS204224 issue to the NCC. > Given the investigations you've done, I amn't sure why not? I accept > that the goal should be to improve the process, but surely reporting on, > and potentially dealing with, bad actors is still worth it if you've > gathered all the data anyway? > > However the core point here is I will, once again, extend an invite to > you, to Suresh, to Sascha, to Jeffrey, to Aftab, to everyone on this > list who is interested in this issue, to work on a policy that might help? > > As Sander said earlier, the community works on policy. The NCC, whether > they are technically able or not, will not put any such verification in > place unless the community asks them to. This is the way this system > works, from the bottom up. > > This is something that Tobias and I have discussed bringing to the > Database Working Group, but time has not permitted in this period > between meetings. I fully intend to allocate time to work on this during > the winter. But if you (all of you, any of you) want something done, > then the Policy Development Process is the way to do it and the more > people involved (to a point :) ), the better. > > I do not believe the RIPE NCC are or should become the Internet police, > for many reasons, but change is made incrementally in this community and > maybe movement is possible in a direction that would be useful? And if > we make a policy and it's wrong, we can make a different, better, > policy. That's the beauty of it. > > Thanks, > > Brian > On 03/11/2015 03:06, Ronald F. Guilmette wrote: >> In message <31D31283-06BF-40D7-AFDF-6BED4B11961F at steffann.nl>, >> Sander Steffann <sander at steffann.nl> wrote: >> >>>> 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. >>> >>> The spammer putting in a fake/temporary/etc mobile of VoIP number there >>> is easy, and the person answering the phone would just confirm >>> everything. >> >> As a *general* matter, yes. A bad actor could IN GENERAL put his own >> cell number into the WHOIS record, and by so doing, could, in theory >> at least, utterly foil _simple_ attempts to learn his true identity... >> at least if he used a so-called "unlisted" telephone number that could >> not be looked up in a public data base. (Do you folks in Europe even >> still have such things as both "listed" and "unlisted" phone numbers >> anymore?) >> >> But we weren't discussing the problem IN GENERAL. Rather, we were >> discussing the specific case of AS204224 and the specific contact >> phone number that appears in its RIPE WHOIS record, i.e. +7-812-3630014. >> >> In this specific case, all one has to do is to google that phone >> number. When you do, you'll see that this number isn't by any means >> just some miscreant's anonymous cell number that was only issued this >> past July, when the fradulent records for AS204224 were created. If >> it were, then there would be few if any google search results. But >> that's not what we see. >> >> Rather, in this specific case you get around 255 different google >> search results for that number, many of them dating back years, and >> all of them from web pages that make specific reference to Mashzavod >> Marketing Service. In short, +7-812-3630014 *is* the actual phone >> number of the *actual* Mashzavod Marketing Service company. Nothing >> could be more clear. >> >> Furthermore, one of the hits you get from a google search on that >> phone number even gives the domain name of the actual company's web >> site, i.e. www.zaomms.ru. Looking at that web site (in Google Translate) >> and simply going to the "Contacts" page, we find not only a perfect >> match for the phone number (+7-812-3630014) but also (translated) the >> name of the head of the company, Boris A. Solovyov, which also happens >> to be a perfect match for what is in the WHOIS record for AS204224. >> >> This is a lot like checking that forward and reverse DNS for a given >> IP address match. It is easy to do, and in this case, everything >> checks out completely. Everything is a perfect match. >> >> That leaves us with only a few possibilities: >> >> 1) The actual 16-year-old oil & gas equipment company Mashzavod >> Marketing >> Service itself actually _did_ obtain a new AS number from RIPE NCC this >> past July, and the company itself, whether by mistake/accident or due to >> actual malevolent intent, _did_ itself actually start announcing routes >> to several /19 bogons. (The bogons in question just happen to be in APNIC >> space, but that fact is not at all important.) >> >> 2) The actual 16-year-old oil & gas equipment company Mashzavod >> Marketing >> Service itself actually _did_ obtain a new AS number from RIPE NCC this >> past July, but then VERY SHORTLY thereafter, SOMEONE ELSE started using >> that AS number to announce a bunch of bogon routes, for reason or reasons >> unknown (but most probably for spamming, or something else even more >> evil). >> >> 3) The actual 16-year-old oil & gas equipment company Mashzavod >> Marketing >> Service is a victim of identity theft. Either someone outside who is not >> now and who never has been associated with the company, or else someone >> on the inside, who does not and did not have any permission to do so, >> asked RIPE NCC for a new AS number in July, and then programmed some >> router somewhere to start announcing various /19 bogon routes, using >> that new AS number, very shortly thereafter. (If this is what in fact >> happened, then it is almost certainly malevolent and intentional, *not* >> merely a "fat finger" accident.) >> >> Possibility #2, is absurd on the face of it. We can dismiss that one >> out of hand. That leaves only #1 and #3. >> >> We can easily distinguish between #1 and #3 by calling the company, >> asking to speak to the person who is, after all, *THE* listed and >> official contact for the company's RIPE-registered AS number, i.e. >> Mr. Boris A. Solovyov, who is Director of the company, as confirmed >> by the company's own current corporate web site. >> >> If Mr. Solovyov is unavailable and elects to never retun phone >> messages left for him at the company after a reasonable time, say, >> one week, then I would pose the question: What is the bloody point >> of insisting on having phone numbers into the RIPE WHOIS records anyway? >> >> If on the other hand, Mr. Solovyov _can_ be reached, and if he _can_ >> be communicated with (in some mutually understood language), then he >> can simply be asked if he requested a new RIPE AS number in July. If >> he denies having done so, then that will effectively confirm what I, >> for one, already believe to be either obvious or, at the very least, >> far more likely than not, i.e. that Mr. Solovyov's company has been >> the victim of identity theft, perhaps even by a company insider. >> >> Of course, on the other hand, in the unlikely event that Mr. Solovyov >> asserts that yes, indeed, his company *did* request a new AS number >> from RIPE in July, then the person speaking to him, although by no means >> having any obligation to do so, could, in the public interest, ask >> Mr. Solovyov an entirely reasonable follow-up question, i.e. "Well, >> if that _is_ your AS, were you aware of the fact that it is announcing >> a bunch of bogons?" (Of course, that question should most definitely >> *not* be asked with an accusatory tone, but rather with a helpful one. >> Perhaps these bogon announcements are in fact the result of a simple >> fat-finger mistake, or perhaps even a small misunderstanding about the >> normative rules of behavior and etiquette for RIPE members. In such >> cases, whoever makes the phone call could perhaps asist Mr. Solovyov's >> network engineer to sort out the problem.) >> >>> If you want to do real verification then you'd have to start >>> from an independent source and work your way down to the person in the >>> RIPE DB. And even then you would have only verified that this person >>> works at that company, not that the person is actually authorised to >>> make decisions on requesting ASNs for the company. So it could still be >>> a fake registration. It would make it harder though to fake stuff. >> >> I agree with all these points. >> >> The old saying is "The best is the enemy of the good". Validation and/or >> verification of RIPE WHOIS data can be improved, even though any system >> which attempts to do so most probably cannot be made foolproof. >> >> And I emphasize again that I *do not* propose for daily or routine use >> anything even remotely like the manual, labor-intensive googling process >> I have described above for the day-to-day validation of RIPE WHOIS data. >> That would be absurd. In this day and age, nobody in their right mind >> would seriously propose *any* process involving *any* manual steps for >> the routine processing of large amounts of data. This is what we have >> computers for! But fully automated phone verification systems exist >> and have been in practical day-to-day use by a number of companies for >> many years already. Likeiwse, the APIs made available from various >> service bureau type companies that assist the mailing industry can be >> used in a totally automated fasion to validate at least the form and >> content of mailing address records, if not actually their semantic >> validity for the context in which they are used. >> >>> The ASNs were requested through a sponsoring LIR. They are the one that >>> should do the verification bit. >> >> OK. >> >> It seems less efficient, and also less pragmatically possible to delegate >> out the responsibility for address & phone validation to all of the >> various >> individual LIRs than it would be to centralize this function at RIPE NCC, >> but if that's the only way it could get done, then that's the way it >> should >> get done. >> >> I'm a pragmatist and I'd be happy to see _anyone_ performing proper >> validation on _all_ RIPE WHOIS records. I doubt that all LIRs are >> technically competent enough to perform this function reliably, and >> if responsibility for getting it done were ever formally assigned >> to them, I suspect that many LIRs wuld be more than happy to delegate >> this responsibility back to RIPE NCC, which has much better technical >> capabilities, but perhaps I'm wrong about that. As I say, I don't >> care who does it as long as it gets done. Right now that doesn't >> seem to be happening, at least not with any consistancy. >> >>> The contractual link is RIPE NCC to LIR, >>> and LIR to end-user. It might be that the LIR is a victim as well or it >>> may be that the LIR is an accomplice. Difficult to tell. >> >> Yet another reason to assign the responsibility to RIPE NCC, which can >> do the job in a consistant, even-handed, and across-the-board manner, >> rather than foisting the responsibility down onto the LIRs. >> >>> For your phone verification system to work the RIPE NCC would have to >>> ignore the LIR and the data provided by the LIR and trace down the >>> contacts starting at an independent source that can not be faked by the >>> LIR or its customer. >> >> No. You're still thinking in terms of constructing an iron-clad and >> absolutely foolproof system that utterly prevents all fraud. I'm >> suggesting a system with vastly less ambitious goals, one which would >> simply check that the voice phone number for a given person or entity >> listed in the RIPE WHOIS db *isn't* simply disconnected, out-of-service, >> the number of a FAX machine, the number of a company or individual whose >> identity has been stolen, or the number of an unrelated brothel in >> Amsterdam. That alone would be a vast improvement over the current >> status quo, I think. >> >> Similarly, in the case of mailing addresses, either RIPE NCC or the LIRs >> could check the data base of one of the aforementioned service bureaus >> that serve that mailing industry, to see if the addresses in RIPE WHOIS >> records even exist. A clever crook will still put in the address of >> some vacant lot somewhere, or maybe his local meat market or police >> station, but at least we wouldn't be looking at "123 Galaxy St., Mars, >> The Universe" and such utter nonsense as that. >> >> There are other and even better ways to validate the mailing addresses, >> but we don't need to get into that now. >> >> Of course, some will argue that any attempt to validate the WHOIS data >> is a horrendous encroachment on liberty, and cannot be tolerated under >> any circumstances by a freedom-loving people, and also that any attempts >> to check the data will, in the end, prove imperfect, and thus, that it >> isn't even worth doing. These arguments identical in every important >> respect to the arguments that are made continuously, in my own country, >> against any regulation whatsoever of guns. And so far, in my country, >> these argument still hold sway, even though year after year we have the >> highest per-capita rates of gun violence, by far, in the industrialized >> world. My impression however is that you Europeans are both civilized >> enough and sohpisticated enough to reject such poor arguments, and to >> choose instead a more enlightened path leading to greater civility. >> >>>> It _is_ unallocated (bogon) space in this case, so yes, it is easy. >>> >>> network operators should be filtering better on announced prefixes >> >> Yes, and people shouldn't be purchasing stolen bicycles. It happens >> anyway, and thus, we should still put locks on our bicycles. >> >>> It's certainly something we should think about. I'm just thinking that >>> using the phone number from the RIPE DB doesn't prove anything as the >>> spammer will provide that data for themselves. >> >> Validating the phone number _would_ prove something. It would prove >> that the phone numbers that appear in the RIPE WHOIS data base are, >> at least at the time of the checking, *not* disconnected, *not* out >> of service, *not* the numbers of FAX machines, or company switchboards >> where nobody has any idea of who might know something about this Internet >> thing, and also *not* the numbers of unrelated brothels in Amsterdam. >> >> I agree that validating the phone number would not prove _everything_ >> that we might want to verify, but it also does not prove nothing. >> >>> Any ideas on how to make >>> sure we get a valid phone number that belongs to the >>> company/organisation/etc that the resources are being assigned to? >> >> Yes, but I prefer to leave that discussion for another day. There >> seems no point in having it now, when at least some RIPE members >> appear to feel that having to give their correct phone number to >> RIPE NCC (who will then publish it) might represent an unforgivable >> encrochment on their personal sovereignty, the UN's Universal >> Declaration of Human Rights, or their reasonable commercial >> interests in confidentiality. >> >> If that is the majority view, then even the minimalist suggestions >> I've made for validation of the data will not fly, and in that case >> it is certain that any even more comprehensive approach wouldn't >> either. >> >>> We have already improved quite a lot. >> >> Excellent. >> >> I cannot help but be impatient for further improvements. Unlike most >> folks, I look in depth at the crooked and less savory parts of the >> Internet virtually every day, and it is deeply disappointing for me, >> as it must also be for law enforcement, to see how little proper >> identification and attribution is helped by the (often inaccurate) >> available resources. >> >>> My apologies. I didn't mean to imply that accuracy of the RIPE DB is a >>> mere detail. That accuracy has been the reason behind quite a few >>> policies! I meant to say that policy doesn't contain implementation >>> details. The way a policy is implemented is left to the RIPE NCC. The >>> policy just says that contact information has to be up to date. >> >> I want to understand. Are you saying that RIPE NCC could unilaterally >> just decide to start performing phone verification of contact points >> listde in the WHOIS data base? >> >>> I'm just wondering what the existence of a postal address (or a phone >>> number) actually proves. I could provide some random address in >>> Amsterdam and a disposable VoIP phone number. They would be real, but >>> they wouldn't actually prove anything about who is requesting resources. >> >> I've been to Europe only one time, in 2010. I had to buy a cell phone >> there to communicate, and when I did I was entirely surprised to learn >> that one cannot do so without presenting some form of identification, >> passport, driver's license, etc. (We don't do that here.) The inference >> I draw is that in Europe, even more than other places, law enforcement >> at least can trace a phone number to a particular person. If true, that >> represents both a deterrent to fraud, and a useful assist when and if >> possible fraud in being investigated. >> >> Even for amateur sleuths such as myself, every additional data point >> helps during an investigation. The example of AS204224 is illustrative. >> If I knew for certain that someone had positively validated the phone >> number when that AS has been assigned in July, then I would also know, >> almost to a moral certainty, that the company itself, and not some >> identity thief, was the party engaged in the recent routing hanky >> panky. >> >> Positive confirmation of phone and/or address data would eliminate a >> lot of simple "fat finger" mistakes, a lot of casual (but not >> deternmined) >> "drive by" fraud, and would help in after-the-fact investigations >> which just simply try to determine who is misbehaving. >> >>>> And you'll have to excuse me for saying so, but this nonsense you raise >>>> about "political instability" is just that, nonsense. >>> >>> I am more thinking about e.g. business records. I have been told that in >>> regions of Ukraine both the Ukraine government and the Russian >>> government are claiming authority on chamber of commerce stuff. And I >>> have no idea who is authoritative on business registration in different >>> regions in Syria. >> >> You are thinking about formal, government-held business records. I >> myself >> am not. Official government business records, when available, are >> helpful >> to investigations. But if they aren't available, then they aren't, and >> that's all there is to it. You work with what you have. >> >>>> Should we worry that >>>> the penguins in Antartica won't be able to obtain RIPE number >>>> resources because they also don't have working phones? >>> >>> Don't make this into a ridiculous argument please. I am very serious. >> >> I'm sorry, but I have trouble taking seriously any argument that begins >> with the false assumption that just because someone belongs to the >> species homo sapiens, that RIPE then has some sort of a moral obligation >> to give them number resources, regardless of whether or not they are >> living in a war zone, and regardless of whether or not they are tribal >> people in Papua New Guinea with nothing to their names except grass >> skirts and mud huts. >> >> There are certain minimal requriements for connecting to, and >> participating >> in the modern Internet. Among these is a supply of electricity. Also >> on the list is a working phone, usable for contact purposes. Yes, >> undoubtedly, on the eastern edges of Donetsk, and most neighborhoods >> of Aleppo, phone coverage may range from spotty to non-existant. But >> as I've said, I think those people have bigger problems than worrying >> about how to connect up to the Internet. Finding enough to eat everyday >> might be high on that list. >> >>> Having a working phone number for a short period of time doesn't really >>> prove anything. Accepting bogus phone numbers is not good, but we also >>> shouldn't attach too much value to having a valid phone number. >> >> OK. I promise not to attach too much value to a validated phone >> number. Seriously, I agree with you that checking the phone number >> isn't a panacea, but it's better than nothing. >> >>> What needs to be verified is the entity requesting resources, and to >>> determine if a company or person exists and who is authorised to request >>> resources for that entity are the difficult bits. >> >> As I said, this would be aiming for a much broader and higher goal than >> what I personally am aiming at. It's good, but you have to walk before >> you can run. >> >>>> 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.) >>> >>> Wow. Stop it right there! I was enjoying having a good discussion with >>> you. Now don't start ruining it by making wild accusations. >> >> I apologize. You are correct, That comment on my part was utterly >> uncalled for, and I would very much like to retract it. >> >> But I hope that you understand my sensitivity. "Privacy" is a double >> edged sword. There are many contexts where I personally demand it, >> and others where it seems a reasonable bargain to give a little bit of >> it up in exchange for certain privledges to which all homo sapiens are >> _not_ automatically entitled, e.g. renting a car, getting on a commercial >> airliner, or connecting my network to the Internet. Neither any deity, >> nor the United Nations, nor the United States, nor the State of >> California, >> nor my local county or city have told me that I have an inalienable >> right to do any of these things, in particular without giving up anything >> at all in return, and I am neither silly enough nor arrogant enough to >> insist that I do. >> >> In contrast, I've seen signs, here and elswhere, of what could only >> properly be called radical fundamentalist privacy advocates, zelots >> who argue in favor of a ridiculous, impractical, and unworkable extreme >> when trying to draw a reasonable balance between personal privacy and >> personal privledges. These extremists were apparently gleeful when >> they succeded in preventing a multinational company from even giving >> its own internal European employee phone directory to their other >> employees in the U.S. who had perfectly legitimate business reasons >> for needing to contact their European counterparts. >> >> I agree with and applaud much of what Europe has done to advance the >> cause of personal privacy. But even the best ideas, taken to >> ridiculous extremes, yield only lunacy. Unfortunately, the hardest >> of the hard-core privacy jihadists often seem to have grabbed the >> reins in Europe, and I worry that in future, children born there >> won't even be able to find out their own names without a court order. >> >>> RIPE NCC has to comply with data protection laws. >> >> But there _are_ ``outs'' and exemptions that allow certain information >> to be published. Elsewise port 43 @ whois.ripe.net wouldn't be >> answering, >> right? >> >>> I personally think that someone holding resources should at least be >>> identifiable in the DB, >> >> We agree, but apparently this sentiment is not universally shared. >> >> >> Regards, >> rfg >> >
- Previous message (by thread): [anti-abuse-wg] WHOIS (AS204224)
- Next message (by thread): [anti-abuse-wg] WHOIS (AS204224)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]