In message <B5889499-D9CA-4422-9F93-E926991F1A9D@heanet.ie>, Brian Nisbet <brian.nisbet@heanet.ie> wrote:

This conversation has gone far beyond what can be considered acceptable on a community mailing list and far into ad hominem attacks. ... This working group does not exist to change ICANN policy, it exists to create & change RIPE policy, amongst other things.

From where I am sitting however it appears me that the both the data contained in the RIPE WHOIS record for AS204224 and also whatever

Brian, First let me say that I agree with you 100%. Gratuitous ad hominem attacks which attempt to impugn a person's background, ancestry, religious or racial affiliation, or their fundamental honesty are inappropriate, both here and now, and at all places and at all times. I myself never make such personal attacks. I do believe however that in the case of someone who himself (or herself) elects to actively engage in a debate about policy... policy which affects literally billions of Internet users... it is more than appropriate to at least mention that person's possible direct financial interest in the question at hand. (If Donald Trump, currently running for President of these United States, were to propose the elimination of all hotel related taxes, I doubt that anyone would see it as being an ad hominem attack to mention that such a policy might benefit his interests personally.) Mr. Neylon himself voluntarily entered into a discussion regarding the pressure that had been applied, by registrars, to insure that their contractual responsibilities for insuring WHOIS accuracy would be minimized and minimal. I pointed out that he might very well have a personal financial interest in that issue. I am not at all apologetic for having done so. It is a relevant fact which subscribers have a right to know. Second, I also must agree with you 100% that this is not exactly the perfect place to discuss ICANN policy. And I, for one, am perfectly willing to refrain entirely from doing so in future. However RIPE itself only holds its own position and authority by dint of the charter which has been granted to it by IANA. And IANA in turn only holds its position and authority by dint of the charter which has been granted to it by ICANN. Thus, in short, it appears to me that ICANN effectively sets the policy for everyone, and specifically for all five of the Regional Internet Registries, including RIPE. But we aren't talking about ICANN anymore. Fine. Let's talk about RIPE. RIPE, of course, maintains it own WHOIS data base. Let's talk about that. Let's talk about RIPE, and the polices and procedures that RIPE NCC is currently following as it adds, removes, and modifies entries in its own WHOIS data base. As I have already made abundantly clear, the current policies of {the entity which we are not discussing anymore} have rendered the domain name WHOIS data base a joke. It is perfectly useless in most cases for actually identifying any bad actor, because there is no serious verification of anything (other than disposable e-mail addresses) that go into that data base. In particular there is no verification whatsoever of either street addresses or phone numbers. Nobody even contests this sad fact. But we aren't talking about that. So be it. Let's change the subject entirely. What is the *RIPE* policy with respect to verification and/or validation of *RIPE* WHOIS records? Are RIPE and RIPE NCC simply following the lead of the over-arching entity-that-shall-not-be-named? Are RIPE and RIPE NCC doing absolutely and positively NOTHING at all to verify or validate the street addresses and phone numbers that appear in RIPE's own WHOIS data base? If anyone here even has the cajones to attempt an answer to the above question, and/or if anyone here attempts to claim that RIPE _isn't_ allowing any and all unverified garbage into its own WHOIS data base, then I am eager to have that person or persons explain to me the deeply curious case of the RIPE WHOIS record for AS204224... which I myself mentioned here a day or two ago. Is anyone here either willing or able to defend _either_ the accuracy and correctness of that specific RIPE WHOIS record _or_ the vetting process that RIPE NCC applied to the data contained therein? If so, please proceed. I'm all ears. process RIPE NCC followed to validate that data are... not to put too fine a point on it... nothing short of bovine excrement. Forget ICANN. Is _RIPE_ also a slacker when it comes to maintaining its own WHOIS data base? Are officially sanctioned RIPE policies and procedures making to harder than it ought to be to stop, or even to just merely identify criminals, con men, and spammers on the Internet? If so, when was that decision ratified, and by whom? Regards, rfg P.S. The case of the WHOIS record for AS204224 is not, by any stretch of the imagination, just a "one off" as the brits would say. I am writing a report now that will detail the utter and complete bogosity contained in a number of other RIPE WHOIS records. It is self-evident from these examples that no checking of any kind is being performed by RIPE NCC staff to insure that contact data which appears within the RIPE WHOIS data base is anything other than untrustworthy baloney.

Caveat - “we are not the [xyz] police” .. in this case, “the document police” .. a fine old trope, that. —srs

On 02-Nov-2015, at 9:14 AM, Sascha Luck [ml] <aawg@c4inet.net> wrote:

While I can't speak for the accuracy of the AS204224 record, I can say that the procedures used by the RIPE NCC to verify the identity of its members are sufficient and, in my personal opinion sometimes overreaching. So are the sanctions available for incorrect or false registry entries. If you were a member or had you bothered to read the relevant documentation of the process as detailed at https://www.ripe.net you would know that.

Hi Ronald,

Op 2 nov. 2015, om 07:38 heeft Ronald F. Guilmette <rfg@tristatelogic.com> het volgende geschreven:

The claim clearly being asserted by the RIPE WHOIS record for AS204224 is that this is an *IN-REGION* (Russian) company, one which, as I noted, is apparently a 16 year old parts & equipment supplier for the oil & gas industry, that suddenly, and for no apparently clear reason, this past summer, after 16 years in business, decided that it needed its own RIPE-sponsored AS

Apparently. Although in this case you may be right in that it is a fake registration (I have no idea and I don't have the resources to verify) there are plenty of companies that need their own AS for i.e. multi-homing. Even if they are 16 years old, they may have changed their business model etc. 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. Our community and service region is much too diverse for that.

, got one, and then proceeded to announce a bunch of self-evidently bogus routes to relatively large swaths of APNIC address space.

"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?

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.

That AS, as I pointed out, was registered within 7 minutes of yet another highly dubious AS (i.e. AS204223)

RIPE NCC has assigned 2044 ASNs so far this year (based on delegated-ripencc-latest). It isn't that strange that two ASNs get registered within 7 minutes of each other. Especially not of they both have the same sponsoring LIR, where an employee might just have saved all requests to RIPE NCC to process them all at once for efficiency. When you see later that multiple ASNs have been used to send spam it is not difficult to find some similarities between them. But that doesn't mean that all ASN requests which show some similarities are suspicious by default. Again: what exactly do you propose to do with this data? How does this help us make better policies?

, which also, perhaps not conincidently, has itself recently also been caught red-handed, also announcing several similarly sized bogons from the exact same geographical region as the bogons that AS204224 has been announcing.

Hindsight is always nice, but this doesn't help us in trying to prevent abuse.

Oh! And let's not forget what started this, i.e. the fact that AS204223 is itself upstream from yet a third dubious AS, and one which Furio Ercolessi reported here as ALSO announcing a number of bogons, AND ACTIVELY SPAMMING FROM THOSE.

Again: hindsight is nice.

You apparently think that all of this is mere coincidence.

Doesn't sound like it the way you put it, but you haven't shown anything yet that isn't based on hindsight and speculation...

...

...

From where I am sitting however it appears me that the both the data contained in the RIPE WHOIS record for AS204224 and also whatever process RIPE NCC followed to validate that data are... not to put too fine a point on it... nothing short of bovine excrement.

Evidence please, until then I will regard this as baseless slander.

So, you are of the opinion that the WHOIS data for AS204224 is all perfectly fine and dandy, yes? You don't find anything at all in the least bit suspicious about a 16 year old Russian oil & gas parts supplier suddenly coming out of the woodwork, suddenly needing their own AS number

Not at all. As I said: these things happen. Businesses change, evolve. And at some point they may need their own ASN.

, and, as their very first act upon acquiring their shiny new AS number, announcing a bunch of bogons to IP space they have no rights to

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. Is it space allocated to someone else? In that case there is no way you can say that they have no right without contacting the legitimate holder.

, exactly like ANOTHER different AS number is doing, a different AS that just happens to have been created only 7 minutes earlier?

Maybe suspicious with hindsight. Nothing that RIPE NCC could/should have acted on when the request was made.

I want to be clear here. Is that really what you are saying? I'd like to get your answer on the record... for posterity.

Here you have mine :)

...

...

Forget ICANN. Is _RIPE_ also a slacker when it comes to maintaining its own WHOIS data base? Are officially sanctioned RIPE policies and procedures making to harder than it ought to be to stop, or even to just merely identify criminals, con men, and spammers on the Internet? If so, when was that decision ratified, and by whom?

The Policy Development Process is detailed in documentation on the abovementioned website.

[...]

My question was: When was the DECISION made not to bother to verify the phone numbers and mailing addresses that go into the RIPE WHOIS data base? And also: Who made that specific DECISION?

The current rules for assigning ASNs are here: https://www.ripe.net/publications/docs/ripe-638 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" Their content has been decided by the RIPE Address Policy Working Group.

(I understand that I may have failed to be adequately clear earlier, but I wanted to be clear now that my question was not about the "Policy Development Process". I thank you however for you kind attempts to educate me about this largely unrelated topic.

It's not unrelated, it's how DECISIONS are made.

I'm interested in the moment in THE DECISION, not in official pronouncements regarding the idealized notion of the political process that may or may not have been followed leading up to THE DECISION.)

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.

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. The policy says that there has to be either an indirect or a direct contractual link between the End User and RIPE NCC. For the ASNs you mentioned the link goes from RIPE NCC to a sponsoring LIR to the end user. Contract between RIPE NCC and LIRs is published here: https://www.ripe.net/publications/docs/ripe-626 9.4f entitles the RIPE NCC to terminate the contract "if the Member provides the RIPE NCC with falsified or misleading data or provides the RIPE NCC repeatedly with incorrect data" The exact contents of the contract between the LIR and the end user are not public, but it must contain things like keeping data up-to-date (see ripe-637 above).

If THAT was really what you were trying to say, then you'll have to excuse me while I pick my jaw up off the floor.

The policies contain requirements for up-to-date data, and the RIPE NCC service contract does contain language against falsified, misleading and incorrect data. The big problem has always been: how do you verify that data? Many things you labelled as "self-evident" are certainly not, especially not up front. 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? 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. Those answers can then lead to a policy. This policy must be neutral, unambiguous, implementable, verifiable etc. and not be based on circumstantial "evidence", "self-evident" data and hindsight. This is not easy. Cheers, Sander 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.

On Mon, Nov 02, 2015 at 12:29:18PM -0800, Ronald F. Guilmette 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.

Do you actually operate a network? I think no, because then it would be obvious to you how utterly unmanageable such a setup would be. Do you seriously propose that DB objects can only be created during NCC business hours (8-17h MET, ttbomk)? Who is going to pay for the phone bill? You?

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.

If you do believe you have evidence that there is something fraudulent going on, make a complaint here: https://www.ripe.net/support/contact/reporting-procedure if the NCC determines that there is a case of fraud or ID theft, it will be investigated and rectified. Sanctions go all the way up to closure of the registry. Instead I see pages of ridicule and demands to change the RIPEDB to something you want it to be. Tell me, how much are you paying for access to the database? People like you are the very reason I am campaigning to make the database accessible to paying and identified members only. Just go away. s. Luck

Hi Roland,

...

...

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.

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. 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 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.)

The ASNs were requested through a sponsoring LIR. They are the one that should do the verification bit. 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. 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.

...

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.

network operators should be filtering better on announced prefixes anyway. It's always frustrating to see so many are still letting bad routes through (plug: https://www.routingmanifesto.org/manrs/)

...

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.

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. 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?

(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.)

You don't have to tell a Dutchman that ;)

...

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.

We have already improved quite a lot. Until https://www.ripe.net/participate/policies/proposals/2007-01 there was no link between the end user and the RIPE NCC at all for independent resources (ASN, PI).

...

...

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".

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.

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.

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. But you are right: we shouldn't tolerate completely bogus information.

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.

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?

Don't make this into a ridiculous argument please. I am very serious. 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. 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.

You have thoughtfully replied, for which I thank you. I believe that I have done likewise.

You have! Thank you for that. I am glad we can have a serious discussion about this. I still see many more problems than you see, but let's see how we can resolve those.

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.

Is "privacy" actually a consideration when discussing the accuracy (or lack thereof) of RIPE WHOIS records? If so, when exactly did THAT happen?

RIPE NCC has to comply with data protection laws.

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?

I personally think that someone holding resources should at least be identifiable in the DB, and as far as I know that is still the case for the RIPE DB. If you look up my data (SJMS1-RIPE) you'll have my home address, home and mobile phone numbers, private email address etc. I look at this from a network operator's point of view, and I want people to be able to reach me in case something goes wrong. I don't have a problem with that but I am not sure how much of that we are legally allowed to require from people requesting resources.

Is this kind of ludicrous and counter-productive "privacy" already a stated RIPE policy goal?

Nope, just the law protecting information about individuals. I'll leave the details to the RIPE NCC lawyers because IANAL etc. Cheers, Sander

In message <31D31283-06BF-40D7-AFDF-6BED4B11961F@steffann.nl>, Sander Steffann <sander@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

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@steffann.nl>, Sander Steffann <sander@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

On Tue, Nov 03, 2015 at 02:28:03PM +0100, David Hofstee wrote:

In that line of thought: I would like email validation on a regular basis. There are so many email addresses that do not work properly (what then is the sense of registering invalid data?).

There are LIRS that register many thousands of objects. Even small LIRs can have many hundreds. Is the idea that they employ someone full-time to solve captchas for the NCC (another idea from this discussion)? Frankly, I'd rather have the spam, at least I can filter that. rgds, Sascha Luck

On Tue, Nov 03, 2015 at 07:18:45PM +0530, Suresh Ramasubramanian wrote:

I doubt - 1. You are being asked to code this for RIPE NCC

Irrelevant, I'm talking about the LIR contacts or end-users being made to deal with this.

2. You get all that much spam to filter out - as far as I can see from linkedin, your previous experience is all in desiging and running IXPs and coordinating peering - I wouldn’t presume to argue with you about any of those.

You know nothing about me. What I do or do not have experience with is none of your concern. If you want to make this personal, go right ahead. I'm not afraid of any amateur spook, I have had to deal with the real thing.

Yet, all the outraged howls in this thread I hear come mostly from people who are from a routing or an addressing background rather than from any kind of a security background.

All the "outraged howls" I've seen in this thread are from so-called "security experts" with evidently little or no experience in LIR operations. rgds, Sascha Luck

In message <0F2494D8-D060-4496-807A-ABBE30D264F0@gmail.com>, (in response to Sascha Luck) Suresh Ramasubramanian <ops.lists@gmail.com> wrote:

I doubt -

1. You are being asked to code this for RIPE NCC ...

For the record, I agree completely with Sascha Luck on this one. CAPTCHAs are an awful idea in this context. I hate them. Everybody hates them. They are only useful when one is trying to keep random anonymous idiots from spamming your blog... a blog which otherwise allows comments from random anonymous idiots. But we were discussing validation of phone numbers allegedly belonging *not* to anonymous people/entities, but rather to people/entities that are in fact *known* to RIPE (and which already have, or which can pretty easily create a RIPE login account). Bottom line: I don't see CAPTCHAs as being at all useful in a phone validation system. That having been said it might still be either necessary or advisable to put a CAPTCHA in front of the RIPE account creation process, e.g. if there isn't one there already, just to stop some mindless automaton from trying to create 100,000 new RIPE accounts on some given day. Regards, rfg

Dear Sascha, as you seem to have quite a knowledge about this I'm sure you already have an idea on how the data can be up to date. Care to share? Yours, esa On Tue, Nov 3, 2015 at 2:42 PM, Sascha Luck [ml] <aawg@c4inet.net> wrote:

On Tue, Nov 03, 2015 at 02:28:03PM +0100, David Hofstee wrote:

...

In that line of thought: I would like email validation on a regular basis. There are so many email addresses that do not work properly (what then is the sense of registering invalid data?).

There are LIRS that register many thousands of objects. Even small LIRs can have many hundreds. Is the idea that they employ someone full-time to solve captchas for the NCC (another idea from this discussion)? Frankly, I'd rather have the spam, at least I can filter that.

rgds, Sascha Luck

-- Mr Esa Laitinen Skype: reunaesa Yahoo: reunaesa Mobile: +4178 838 57 77

In message <20151103143413.GI47126@cilantro.c4inet.net>, "Sascha Luck [ml]" <aawg@c4inet.net> wrote:

On Tue, Nov 03, 2015 at 03:14:54PM +0100, Esa Laitinen wrote:

...

as you seem to have quite a knowledge about this I'm sure you already have an idea on how the data can be up to date. Care to share?

I don't think it can be done without turning the NCC into something like the NSA and even then I doubt it would be 100% effective. Many governments throughout history have tried to have all the data they can on their citizens...

I am not persuaded that this is at all a valid or fair comparison. As a retorical flourish, it is admirable, but as a reasoned argument against RIPE (or RIPE NCC, or the LIRs) merely checking the validity of data that is limited to only addresses and phone numbers... data which is already contractually required to be correct... I think it is a bit over the top to intimate that RIPE (or RIPE NCC, or the LIRs) are going to turn into another NSA. Much to my distress, the NSA knows what I had for breakfast. (And by the way, I am a staunch defender of Snowden and, since I have no direct heirs, I plan to leave him whatever assets I have left when I die... for either his defense or, hopefully, by that time, merely for his well-deserved comfort back in Hawaii.) In contrast, my own local city, Roseville, California, knows next to nothing about me. The city did somehow aquire my phone number... I have no idea how... and in over 20 years I believe that they have used that exactly one time, placing an automated call to me to warn me about possible local flooding. I was not (and am not) incensed by that intrusion into my privacy. Rather, I was somewhat grateful that the city cared enough to call and give me the heads up. Mr. Luck, you have expressed the view that you wouldn't mind at all if the RIPE WHOIS data base became available, in future, only to paying members. I'd like to put to you a somehat different question. If a formal proposal was put forward to the entire RIPE membership which proposed that all mailing addresses and phone numbers be completely removed from the WHOIS data base, would you personally vote "yea" or "nay" on that proposal? I am just trying to understand your policy views in toto. Regards, rfg

On Wed, Nov 04, 2015 at 03:41:39PM -0800, Ronald F. Guilmette wrote:

If a formal proposal was put forward to the entire RIPE membership which proposed that all mailing addresses and phone numbers be completely removed from the WHOIS data base, would you personally vote "yea" or "nay" on that proposal?

Something sort of - just to make them optional in person objects: https://www.ripe.net/ripe/mail/archives/db-wg/2015-April/004520.html Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl

Hi, On Tue, Nov 03, 2015 at 04:17:19PM +0100, David Hofstee wrote:

Every email address in the RIPE database should work. There is a reason to register an email address (and that is not for historical purposes). There should be someone that is able to read those emails (or it should serve its purpose). If it doesn't work, and that was determined correctly (and maybe escalated to the org itself), then it should be removed.

I totally agree that it should work, but you can't test that without actually sending something there which causes a human to do something. Now, for a LIR contact, this is ok ("part of the job description"). For an end user, I share Sasha's sentiments - this is contact information to be used for *contacting* them, not for harrassing them with robots they don't want to know about. In doubt, send mail to the *LIR* asking "are your customer contact x, y and z still valid?" - and I seem to remember that the NCC is actually doing that (verifying end user contracts for sponsoring LIRs). The NCC has a business relation with the LIR, and part of that contract is "make sure your end user registration data is valid". I could see an occasional call in the case of "funny smelling things" ("so the LIR claims that this is valid, but we start to distrust the LIR"), but not automated and regular calls/emails to end users... (some might call this "spamming", and under german law, it might actually be unless prior consent or a contractual relation exists) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

Hi all Interesting conversation. It took me a while to read it all. I would like to add a few of my own thoughts based on my experiences. Although I will target my comments in response to specific points raised by many of the contributors to the discussion, I offer all my comments with the intention of being objective and constructive :) For those who don't know me let me first declare my position regarding the RIPE Database. I worked for the RIPE NCC for 14 years entirely focused on the RIPE Database. I have been involved in the design, development, analysis, specification, operation, legal and privacy issues, policy implementation and documentation of all parts of the database service since the deployment of the first RPSL version in 2001. I no longer work for the RIPE NCC or anyone else connected with the service. Everything I say here is my own opinion and based on publicly available knowledge. I am not giving away any secrets here (not that there are any) :) Ronald "I neither mentioned nor asked about out-of-region objects." "then proceeded to announce a bunch of self-evidently bogus routes to relatively large swaths of APNIC address space." Last time I checked APNIC address space is 'out of region' for RIPE. Although the discussion has been largely based around the verification of data in the RIPE Database, and I agree that is an important issue, the main reason people are concerned about this data seems to be because of what 'bad guys' do with the resources they acquire based on invalid data. A lot of what they do also seems to involve out of region resources. If we eliminated the false registration of ROUTE objects in the RIPE Database for out of region resources then we would have removed one of the main causes why many 'bad guys' offer false data to obtain a legitimate RIPE ASN. So in a way we are back to the same discussion we had 6 months ago just before the last RIPE Meeting. That discussion seemed to centre on wonderful, technically brilliant, perfectionist systems of cross registry authentication to solve the entire problem. Six months on and I haven't seen any further discussion on the subject. At the time I offered a quick and simple solution, not to the entire problem, but to the issue of untrusted ROUTE objects in the RIPE Database. All the parts needed for it already exist in the RIPE Database software. It could be up and running in a month and we could now have more trusted ROUTE objects. But alas no one was interested in my quick, dirty solution and continue to pursue perfection. "When was the DECISION made not to bother to verify the phone numbers and mailing addresses that go into the RIPE WHOIS data base?  And also: Who made that specific DECISION?" "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" " Historically this has never been part of the RIPE Database design. So there has never been any decision NOT to do something. There has simply never been any decision to do something. It has been brought up many, many times over the years. But never even reached the stage of becoming the topic of a policy proposal. It is always shot down for being technically difficult, administratively difficult, "we are not the internet police", or it is pointless because all you prove is the 'bad guys' phone or email address is valid. These may all be true. But if you want anything like this to happen, regardless of who does it (RIPE NCC or members), then you have to move beyond the initial arguments against it, propose a policy and take it through the stages of discussion. If there is a consensus on doing it/something/whatever then that will happen. "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." This point has been said by others, but I will put it in a slightly different way. The RIPE NCC has been tasked as the Data Controller of the RIPE Database. There are formal Terms & Conditions on the use of the RIPE Database that cover who is allowed to put what into and take whatever out of the Database and do what with. The responsibility for accountability for the contents of the RIPE Database is distributed. The RIPE NCC is primarily responsible for validating the information about it's members. As all these members pay an annual fee to the RIPE NCC they have payment details from all the members. So even if all the other public details in the RIE Database were incorrect for a member (which they are not) there is still a strong connection through the payment details. The members cannot avoid accountability. The RIPE NCC also validates legal details of it's members. The RIPE NCC allocates internet resources to it's members also using a community approved allocation process. But even though the members details are valid and they qualify for resources under the allocation policies, the RIPE NCC has no knowledge of or control over what a member does with those resources. This is where the "we are not the internet police" bit comes in. If someone gets around the legal requirements in their country and is able to set up a bogus company with legitimate papers, they will get internet resources. As you have noted, there are many countries in the RIPE region where corruption runs at very high levels. If you have the right contacts you will get your bogus company. No amount of validation done by the RIPE NCC or a local LIR will show anything wrong with that company. But the true identity of the real person behind the company will still be hidden. So however much work you put onto those people who do everything right, these 'bad guys' will still drive a coach and horses straight through all your checks. You have to accept that Europe, Middle East and Central Asia is a very different landscape than the USA. Whilst I applaud efforts to validate data, the misuse of valid data will still happen. That is where your investigative and analysis skills come into play to spot where things look wrong and close these doors. Yes every time you close one of these doors another may open. But you may only be able to spot these doors after they open. "if RIPE NCC merely had a standing policy of performing an automated phone verification step when registering new entities and/or resources." "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." "Someone needs to CALL the phone number listed there and simply ask if Mr. Soloviev is available." "I would do it myself, but I don't speak Russian" Several points here. First of all I notice this ORGANISATION object ORG-CM117-RIPE does not have an "abuse-c:" attribute. All internet resources registered in the RIPE Database must now have an abuse contact. As this was only registered a few months ago it should have one. So something went wrong with the business rules. It has already been suggested that there is a hierarchy of validation requirements regarding data in the RIPE Database. The RIPE NCC validates data for it's members. It's members should validate data for the organisations they sponsor. I see in this case the resource end user is based in Russia and the sponsoring LIR is based in Ukraine. It is quite likely that staff at the sponsoring organisation do speak Russian. What if they had approached a French company to sponsor them? They most likely would not speak Russian. But I don't think the policy prevents it. If the French LIR accepted the business, how effective could their validation of the end user's information be? I don't know how acceptable or practical this suggestion will be, but maybe the sponsoring LIR should be restricted to an LIR in the same geographical/political/language area as the end user resource holder. Otherwise it could render the whole notion of an LIR validating their sponsored user's data pointless. Interesting point about the creation of this ORGANISATION object. It touches on an issue I have been trying to raise for a number of years. But I am almost universally shouted down by most of the vocal members of the RIPE community whenever I mention it. Even though many less vocal members have privately agreed with me. That is a serious review of the whole data model that the RIPE Database is built on. The software for the database has been completely re-written twice in the last 14 years. But the data model it is based on has barely been touched. It is almost a 20 year old design. There are serious limits on how much you can change on the top floor when you stick with the foundations. You can re-decorate but you can't re-model. For a long time I have been suggesting an organisation centric model. Where anyone who holds a resource, or has any involvement in any part of managing that resource, should have a validated ORGANISATION object in the database with details of who they are. These ORGANISATION objects should form a chain of trust from the RIPE NCC, down through their members, to the members customers, consultants, sponsored resource holders. No one should be able to get an ORGANISATION object unless they are known by, or have validated themselves with, an existing ORGANISATION object holder. There should be no object in the database that is not directly or indirectly linked to an ORGANISATION object. There are many other things wrong with this data model but this would be a good start. Sascha Caveat - “we are not the [xyz] police” .. in this case, “the document police” .. a fine old trope, that. "There are LIRS that register many thousands of objects. Even small LIRs can have many hundreds" "Now, if registering an assignment to an end-user with the end-user's contact data (as you are supposed to do)" It is so often said "we are not the 'whatever' police" or "it is not our data" or "we are not responsible for this". We have to separate registration from usage. As far as registration is concerned who else has this responsibility? Internet resources come from IANA to RIRs to LIRs to customers and end users. At each layer there is a responsibility to properly document who holds a resource. If any one of these layers gets information wrong then resources become anonymous. In principle it is that simple. How you get it right is where the complexity arises. When you talk about thousands of objects I am not sure if you mean assignments to LIR customers or sponsored end users. They are recorded slightly differently. Whose information you record depends on your view of my idea above about an organisation centric database model. It should be recorded who a resource is registered to. But contact data should be whoever can help with the purpose of that contact. A technical contact should be able to answer technical questions. If a sponsored end user has no idea how anything works and outsources 'all that' to some other person/organisation, then technical contact details should reflect that consultant. Where an LIR has provided large numbers of single IPv4 addresses or blocks of IPv6 addresses to end users which are reflected in assignment objects in the database it is normal to put the LIRs details in that object. The end user's may not even know this database exists. But the LIR will hold details of who uses each of those addresses. Sander "I personally think that someone holding resources should at least be identifiable in the DB," I absolutely agree, but also anyone who partly manages any aspect of a resource should be identifiable. Jeffrey "One  informs registrants that  CONTINUOUSLY working contact modes (e-mail, fax, phone, postal, say at least three of four) are mandatory to avoid suspension/rescission" "Then one automates a routine to transmit tokenized letters/faxes/ calls/e-mails" As pointed out above, this is fine but so easy to cheat. You can have a legitimate company with valid email, phone and fax who will respond to all your tokens, but they are still the 'bad guys'. David "Make sure that the data is sufficient, valid and remains to be valid" 'Sufficient' comes back to the data model again that no one will talk about. Is the data that was agreed to store almost 20 years ago still sufficient for purpose today? Brian "The implementation details would come from conversation & collaboration with the NCC and not be contained within the policy." Just to clarify the way this is done. Generally, as Brian says, a policy does not include any/many implementation details. This is left for the RIPE NCC to look into. But the RIPE NCC does not just go off and do what it likes. They have some great analysts and engineers who will look at best ways to achieve the policy aims. This may involve many public discussions with the community and talks with the WG chairs. In the end, when the RIPE NCC thinks it has worked out the best way to achieve the policy, they present the final implementation plan with timelines to the mailing list. If and when consensus is reached on the implementation, the RIPE NCC will go ahead and do the work. Suresh "If you can tell me just how a consensus at APWG and MAAWG, say, or on various actually security focused lists, that the RIPE community needs policy changes is going to make an iota of difference to what policies get implemented by RIPE NCC" "in a RIPE meeting or in the AAWG, where the defenders of RIPE are many, and people criticizing it pitifully few in number" You sound rather skeptical of how the system works :) Accepting the confusion on your definition of APWG, anything agreed by a RIPE working group is implemented by the RIPE NCC. The RIPE NCC may not agree with everything or may argue constructively for other options, but in the end once the community has reached consensus the RIPE NCC WILL implement the decision. The difficulty is sometimes getting the community to reach a consensus. cheersdenis

On Wed, Nov 04, 2015 at 12:05:28AM +0000, ripedenis@yahoo.co.uk wrote:

the sponsoring LIR should be restricted to an LIR in the same geographical/political/language area as the end user resource holder. Otherwise it could render the whole notion of an LIR validating their sponsored user's data pointless.

IANAL, but I can't imagine that such a rule would even be legal under EU legislation. Common Market, remember? Considering that the Internet doesn't recognise any borders or political blocs, this is one of the more outlandish suggestions even for this forum.

Interesting point about the creation of this ORGANISATION object. It touches on an issue I have been trying to raise for a number of years. But I am almost universally shouted down by most of the vocal members of the RIPE community whenever I mention it. Even though many less vocal members have privately

Ah, "the majority agrees with me in email"

Sascha Caveat - “we are not the [xyz] police” .. in this case, “the document police” .. a fine old trope, that.

I didn't actually write this, your quoting appears to be broken.

Sander "I personally think that someone holding resources should at least be identifiable in the DB,"

I absolutely agree, but also anyone who partly manages any aspect of a resource should be identifiable.

No. Just NO. I am, frankly, flabbergasted at this mindset: 1) All resource holders are presumed to be bad actors and all of their data must be kept in a database, their correctness to be strictly enforced. 2) It's no problem making this data available, for free, to every Tom, Dick & Harry with an internet connection. The very idea that someone might use this data for nefarious purposes is obviously farcical. There is a need to be able to reach a resource holder to notify them of abuse coming from their network (the abuse-c) or technical problems (the tech-c). There is NO need to have the street address and phone number of every *person* "who partly manages any aspect of a resource" in a public database, just to satisfy the curiosity of some curtain-twitcher or give actual criminals some data for ID theft purposes.

community and talks with the WG chairs. In the end, when the RIPE NCC thinks it has worked out the best way to achieve the policy, they present the final implementation plan with timelines to the mailing list. If and when consensus is reached on the implementation, the RIPE NCC will go ahead and do the work.

For completeness' sake, if the policy leads to changes in the members' contract or the Terms & Conditions, a membership vote at the GM is also required for implementation. rgds, Sascha Luck

Hi Sascha On 04/11/2015 15:32, Sascha Luck [ml] wrote:

On Wed, Nov 04, 2015 at 12:05:28AM +0000, ripedenis@yahoo.co.uk wrote:

...

the sponsoring LIR should be restricted to an LIR in the same geographical/political/language area as the end user resource holder. Otherwise it could render the whole notion of an LIR validating their sponsored user's data pointless.

IANAL, but I can't imagine that such a rule would even be legal under EU legislation. Common Market, remember? Considering that the Internet doesn't recognise any borders or political blocs, this is one of the more outlandish suggestions even for this forum.

That may well be right, but if the sponsor cannot understand the language of the resource holder the validation may not be very effective.

...

Interesting point about the creation of this ORGANISATION object. It touches on an issue I have been trying to raise for a number of years. But I am almost universally shouted down by most of the vocal members of the RIPE community whenever I mention it. Even though many less vocal members have privately

Ah, "the majority agrees with me in email"

I never mentioned email or majority. 'Some' people I have talked to at RIPE Meetings have agreed with me. The majority will not even talk about it.

...

Sascha Caveat - “we are not the [xyz] police” .. in this case, “the document police” .. a fine old trope, that.

I didn't actually write this, your quoting appears to be broken.

My apologies it was in a reply 'to' you not from you.

...

Sander "I personally think that someone holding resources should at least be identifiable in the DB,"

I absolutely agree, but also anyone who partly manages any aspect of a resource should be identifiable.

No. Just NO. I am, frankly, flabbergasted at this mindset:

1) All resource holders are presumed to be bad actors and all of their data must be kept in a database, their correctness to be strictly enforced.

That seems to be the basis of this whole thread....not my assumption

2) It's no problem making this data available, for free, to every Tom, Dick & Harry with an internet connection.

I actually have some very strong views on making parts of the data in the RIPE Database private, but that is another proposal...

The very idea that someone might use this data for nefarious purposes is obviously farcical.

You have a very negative and misguided view of what I am saying.

There is a need to be able to reach a resource holder to notify them of abuse coming from their network (the abuse-c) or technical problems (the tech-c). There is NO need to have the street address and phone number of every *person* "who partly manages any aspect of a resource" in a public database, just to satisfy the curiosity of some curtain-twitcher or give actual criminals some data for ID theft purposes.

First of all I never said anything about personal data. Maybe you have not heard of the concept of business data. Maybe also you have never had problems trying to contact people regarding resources in the RIPE Database. The 2007-01 policy to contact all resource holders took about 7 years to implement. I suspect many of them are uncontactable again by now. The complexity of this database schema allows for many ways to hide yourself. By manipulating the relationship between PERSON, ROLE, MNTNER, ORGANISATION objects and building complex references and chains of objects it can become very difficult to find who to contact. Do you realise you can make a business out of a MNTNER object? If you 'own' the MNTNER object you can provide a service to other people. You put the password of some anonymous person into your MNTNER and this anonymous person can then maintain resources. As the 'owner' of the MNTNER you can claim you have nothing to do with the resource. You are simply providing a service to your customers. By creating a new MNTNER for each customer only they (and you) can manage their data. You try contacting that resource holder!! The RIPE NCC and maybe the sponsoring LIR knows who it is, but no one else does. A proper implementation of personalised auth and dropping the MNTNER object would solve this issue of anonymity. Unfortunately the watered down version of my original plan being offered now does not go far enough. My main point was the chain of trust for resource holders and resource managers. Also being contactable does not mean personal contact data must be displayed to the public. There are many ways to be contactable. But few people are even willing to discuss possibilities when it comes to changing the data model. cheers denis

...

community and talks with the WG chairs. In the end, when the RIPE NCC thinks it has worked out the best way to achieve the policy, they present the final implementation plan with timelines to the mailing list. If and when consensus is reached on the implementation, the RIPE NCC will go ahead and do the work.

For completeness' sake, if the policy leads to changes in the members' contract or the Terms & Conditions, a membership vote at the GM is also required for implementation.

rgds, Sascha Luck

On Wed, Nov 04, 2015 at 06:17:10PM +0100, denis wrote:

That may well be right, but if the sponsor cannot understand the language of the resource holder the validation may not be very effective.

The price you pay for a globalised society. I can see your point but this isn't something you can prevent par ordre du mufti. Besides, what if the only one in the company who speaks English leaves?

I never mentioned email or majority. 'Some' people I have talked to at RIPE Meetings have agreed with me. The majority will not even talk about it.

Well, they may agree privately but at the end of the day they probably vote the interests of their employer. It happens.

...

1) All resource holders are presumed to be bad actors and all of their data must be kept in a database, their correctness to be strictly enforced.

That seems to be the basis of this whole thread....not my assumption

Oh, no, I don't want to accuse you personally of this assumption! This entire topic is being discussed on this assumption and *that* is what I take issue with. For the record, in my experience: - The NCC is doing the job assigned to it by relevant policy fairly, justly and to the best of its abilities. - The *vast* majority of its members are perfectly law-abiding LIRs who only want to go about their business. - The procedures to deal with them are generally sufficient A few people or companies who act in bad faith do not change this fact and there is no reason to put the entire membership under general suspicion and waste its time and fees with elaborate data collection / verification schemes. In the absence of any hard evidence to the contrary (beyond one or two suspicious cases) *that* is the basis on which this discussion should be maintained.

I actually have some very strong views on making parts of the data in the RIPE Database private, but that is another proposal...

Well. It is on-topic insofar as I could live with more data collection *if* that data were properly protected.

...

The very idea that someone might use this data for nefarious purposes is obviously farcical.

You have a very negative and misguided view of what I am saying.

Again, not an attack on you but of the prevailing opinion that the data in the ripedb is only used by "good" people for "good" purposes... If these show up in a reply to you it's only because it's a good plce, dialectically.

First of all I never said anything about personal data. Maybe you have not heard of the concept of business data. Maybe also

Many resource holders are persons. Many more people involved somehow with the management of resources are persons. Besides, even business data is somewhat sensitive. Where else outside the LIR/RIR world do businesses have to maintain all information about all of their business relationships in a public database?

you have never had problems trying to contact people regarding resources in the RIPE Database. The 2007-01 policy to contact all resource holders took about 7 years to implement. I suspect many of them are uncontactable again by now.

the sponsoring-org object is very helpful with that. Admittedly I was against it but it has shown to be very useful now that it is deployed.

The complexity of this database schema allows for many ways to hide yourself. By manipulating the relationship between PERSON, ROLE, MNTNER, ORGANISATION objects and building complex references and chains of objects it can become very difficult to find who to contact. Do you realise you can make a business out of a MNTNER object?

Yes. I do. I'm mntner or co-mntner on a few objects.

If you 'own' the MNTNER object you can provide a service to other people. You put the password of some anonymous person into your MNTNER and this anonymous person can then maintain resources. As the 'owner' of the MNTNER you can claim you have nothing to do with the resource. You are simply providing a service to your customers.

Yes. And what is wrong with that? All the mntner object does is grant access to change a ripedb object. It says nothing about who operates a resource or what they are doing with it. The reason I have mntner on a few objects is that the resource holder neither want nor are able to deal with the ripedb and as backup so the resource stays maintainable in the inevitable event of the other mntners losing their password. This does not make me responsible for what this resource holder or their customers do.

By creating a new MNTNER for each customer only they (and you) can manage their data

Er, isn't that the *point* of the mntner object? Who else should be able to besides the NCC? (and they are)

You try contacting that resource holder!!

tech c, admin-c, abuse-c...

The RIPE NCC and maybe the sponsoring LIR knows who it is, but no one else does.

Nobody else NEEDS to know. If the NCC knows and the sponsoring-org knows, it is contactable. If they won't talk to you, get on to the NCC. If they don't talk to them either, they are going to be deregistered anyway.

implementation of personalised auth and dropping the MNTNER object would solve this issue of anonymity. Unfortunately the watered down version of my original plan being offered now does not go far enough.

This much anonymity is required. I have several customers, why is there a need that, a) they know of each other b) every other randomer on the Internet knows whom I work for? And, yes, a different mntner for every object is a possibility but it's unmanageable and really makes things much harder than they need to be.

My main point was the chain of trust for resource holders and resource managers. Also being contactable does not mean personal contact data must be displayed to the public. There are many ways to be contactable. But few people are even willing to discuss possibilities when it comes to changing the data model.

Maybe because it has served us reasonably well over the years, it's a massive effort to completely change it and it's still a damn sight better than most other RIRs' databases. rgds, Sascha Luck

Do you feel that the numbers community comparing notes with the ICANN whois EWG would help? https://www.icann.org/news/announcement-3-2015-09-25-en

On 05-Nov-2015, at 1:32 AM, denis <ripedenis@yahoo.co.uk> wrote:

Seriously, with a review of the data model we can end up with: -a lot less personal data in the database -contact data more relevant to the purpose -relevant contacts only visible to the groups of people who need it -chain of trust in organisations who manage the data -verification done closer to the data source -more accurate and more trusted and better protected contact data

In message <563A6462.7080708@yahoo.co.uk>, denis <ripedenis@yahoo.co.uk> wrote:

You{r} talk about privacy and this whole thread is about making lots of personal data public and how many over engineered processes can be put in place to the detriment of all the good folk to trip up a few of the bad folk.

Excuse me, but I think that perhaps you have been reading some entirely different thread on some entirely different mailing list someplace. Either that or else you're employing scare tactics to try to derail what was a simple discussion about validating contact data which is already in the public data base. I started this thread, and have actively participated throughout. I, for one, *never* proposed or even vaguely suggested "making lots of personal data public" to use your words. That is a grotesque mischaracterization of the discussion up till now, I think. It's totally out of left field and has nothing whatever to do with the (informal) proposal on the table. Personal data _is_ already and currently present in the publically- accessible RIPE data base. You may personally object to that fact. If so, then fine. State your objection and make a proposal for change. But please do not put words in other people's mouths. Speaking only for myself, I made no suggestion whatsoever to increase the amount of personal information present in the data base. Mr. Luck, for his part, has clearly and vigorously expressed the view that the amount of such information in the data base (and/or in the publically accessible part thereof) should be decresed to zero. But the decision to do, or not do that is totally orthogonal to the separate decision of whether or not to check the data for validity. The data can be checked and left public. The data can remain both unchecked and public. The data can be checked and can be hidden behind a paywall. Or the data can remain unchecked and can disappear behind a paywall, just as, it appears, Mr. Luck would prefer. I object also to your use of the loaded phrase "over engineered processes". This is clearly intended to make it sound as if some exceptionally complicated Rube Goldberg Apollo Moon-shot system is being discussed. That is not the case. Millions of businesses world-wide allow end users to create accounts on their corporate web sites, and the vast majority of those then COMFIRM and VALIDATE those account creations by sending the person who is alleged to have created the account a magic cookie (often embedded within a URL) and asking them to return that in some fashion. Many other businesses employ an analogous process only with telephones. Still others perform an analogous process with snail-mail. If these all constitute "over engineered processes" then I'm sure that news will come as shock to all those millions of businesses who have spent time and money to implement and deploy theses systems.

Seriously, with a review of the data model we can end up with:...

So let me see if I understand this... So on the one hand, performing even just some simple process to try to validate data fields that are already in the public data base is an "over engineered" solution, but YOU want to totally re-engineer the entire data base from the ground up. Is that about the size of it? Did I miss anything? I personally have no reason to be either for or against the idea of entirely throwing out the existing data base and redesigning and re-implementing it from scratch. If that proposal seems worthwhile to the majority, then by all means it should be done. What I _do_ object to is having a pie-in-the-sky redesign-from-scratch proposal thrown into the mix while discussing what started out as an exceptionally modest, simple, and above all *incremental* and purely *procedural* change... a change that would have no effect at all on either the content or the structure or the permissions associated with the data base as it currently exists. Regards, rfg P.S. I do understand that many people have ideas... some of them excellent, some of them less so... about how the structure, content, or public-accessibility of the data base should be changed, going forward. I do not begrudge anyone who advances such ideas. I only request, humbly, that discussion of these other ideas not be confusingly intertwined with discussion of the (admittedly still informal) _procedural_ proposal that I've put forward. That only serves to confuse matters all around, befuddling everyone.

In message <563BF1E0.3090106@yahoo.co.uk>, denis <ripedenis@yahoo.co.uk> wrote:

First of all I apologise if I have mixed up some of your views, some of Sacha's views and some of my own views. If I have I did so with good intentions. I was not trying to derail anything, but I disagree that this is a simple discussion.

Apology accepted. As regards to whether this topic is "simple" or not, certainly, what I propose is reasonably simple and straightforward. I'll grant that you may perhaps have a point that the subject matter may perhaps not be as straightforward as it either could be or should be, based on your point(s) below.

...

... Millions of businesses world-wide allow end users to create accounts on their corporate web sites, and the vast majority of those then COMFIRM and VALIDATE those account creations by sending the person who is alleged to have created the account a magic cookie (often embedded within a URL) and asking them to return that in some fashion... ... If these all constitute "over engineered processes" then I'm sure that news will come as shock to all those millions of businesses who have spent time and money to implement and deploy theses systems.

On this point I believe you are wrong. "allow end users to create accounts on their corporate web sites". This is not how the RIPE Database works. The accountability for these 'accounts' is distributed. The RIPE NCC has no relationship with many of the personal data sets created in this database.

I feel sure you will correct me if I'm wrong, but I suspect that what you most probably actually intended to say here is that RIPE has no _direct_ and/or _contractual_ relationship with some (many?) of the entities whose contact details appear in the RIPE data base. Would that not be a more precise formulation of what you had intended to convey? Quite obviously RIPE NCC has a "relationship"... in the broadest sense of the word... with all of the entities whose contact details appear in the data base. The relationship, at the very least, is that RIPE NCC is storing (and yes, distributing) contact details for these entities. It may seem like I am quibbling over a minor semantic point here, and perhaps I am, but I think that it is somewhat inaccurate to say that there's no relationship at all between RIPE / RIPE NCC and the entities whose data is in the data base.

So first of all any validation process must also be distributed.

The conclusion does not follow from the premise.

Are you suggesting the RIPE NCC should re-check what was entrusted to the members to do?

Bingo!

In the end most members do enter valid data that they have checked by some means in good faith.

In the end, most people do not steal my bicycle. I still lock it up at night, regardless.

...

So let me see if I understand this...

So on the one hand, performing even just some simple process to try to validate data fields that are already in the public data base is an "over engineered" solution, but YOU want to totally re-engineer the entire data base from the ground up. Is that about the size of it? Did I miss anything?

Yes you did miss something. I never suggested we through out the baby with the bathwater. I proposed a discussion on reviewing the data model. That is not suggesting we through out everything we have now. It may lead to re-arranging data, storing it more efficiently, or maybe storing different data, or only allowing some of the data to be seen by groups of people who need it.

Any and all of that sounds like it might involve some really SERIOUS and hevy-weight re-engineering to me! That's not to say that any of what you're suggesting isn't useful, and perhaps even vitally needed. I am only reiterating my point that it seems rather bizzare to assert that a purely procedural change, i.e. to begin to validate the data that's already there, is an "over engineered" step to take when you are proposing some different (and, it seems, almost entirely unrelated) ideas about how to restructure... perhaps radically... the data base.

As I said above, validating data in a system with a distributed accountability is not going to be simple.

On this point I agree... UNLESS some single central entity undertakes that task on behalf of the entire community. Some single central entity like, um, RIPE NCC.

I think you have over complicated my point while over simplifying yours.

Understood. I hold the exact same view, i.e. I think that you have over-complicated my point while over-simplifing your's.

My main point was that there are many issues with personal data, including validation, and maybe we should take a step back and look at them all.

"Taking a step back" may or may not be the wisest course of action. http://report.president.msu.edu/360/_/img/assets/crew-view/jim-peck/jim-stan... Regards, rfg

On Fri, Nov 06, 2015 at 11:56:51AM +0100, denis wrote:

Add to that all the possible language issues and I am not sure how you will expect the RIPE NCC to validate all this personal contact data with people who they have no relationship with and who may have never heard of the RIPE NCC or RIPE. Anyone who receives an email from an organisation they have never heard of, possibly in a language they don't understand, asking to validate personal information...well you know how that will be treated these days.

I've occasionally done db cleanup death-marches for customers where I've created/updated/deleted 100 or so objects in a single day. (usually with contact data relating to the LIR which does have a contract with the NCC) Is the idea seriously that someone doing this will have to field 100 phone calls or reply to 100 emails over the day? What about the numerous LIRs who do their resource management programatically, without human input? IMO, such actions would actually discourage proper resource management and lower the quality of the db.

Also bear in mind a single data validation is quite pointless. What is valid today may not be tomorrow. So you cannot trust data that was validated yesterday. To have any benefit this data would have to be routinely re-validated. Given the quantity of personal data sets in the RIPE Database (we are talking millions), many of whom have never heard of the RIPE NCC, to ask them to undertake this exercise would result in the RIPE NCC being reported to many law enforcement authorities for phishing.

Not even considering the inevitable members' revolt. rgds, Sascha Luck

On Fri, Nov 06, 2015 at 07:23:39PM +0530, Suresh Ramasubramanian wrote:

That is what floating this in the db wg will establish - whether it is actually a member revolt or one individual’s opinion

Consensus is a wonderful thing when it is achieved

You're touching on a very sore point for me. There are probably very few of the 14k members subscribed here. The vast majority may only learn about this new policy (if it happens) when they start getting the emails/phone calls. I am not sure what value the consensus of a few people interested in ripedb management has. rgds, Sascha Luck

On Fri, 6 Nov 2015 11:56:51 +0100, denis wrote:

Add to that all the possible language issues and I am not sure how you will expect the RIPE NCC to validate all this personal contact data with people who they have no relationship with and who may have never heard of the RIPE NCC or RIPE. Anyone who receives an email from an organisation they have never heard of, possibly in a language they don't understand, asking to validate personal information...well you know how that will be treated these days.

An essential element in cleaning up the mess is to educate everyone that periodic revalidations will occur (e.g. using tokens as mentioned earlier) and the process; it becomes part of the mechanism by which users retain their access to the entrusted public resources. Same idea as inputting a pin when I turn on my mobile phone, or dealing with the periodic messages I receive in a standard format from NetSol regarding maintenance of my website

Also bear in mind a single data validation is quite pointless.

Periodic automated revalidations :) Jeffrey Race

Hi Ronald,

On the one hand, you say that all these entities (both people and businesses) have consented to have RIPE NCC store and distribute their contact data. On the other hand you say that RIPE NCC has no knowledge of the terms and conditions of the contracts they have signed. Given that RIPE NCC is bound by European privacy laws, wouldn't it be fair to say that RIPE NCC is 100% confident of the content of at least one part of the contracts that all of these entities have individually signed, i.e. the part in which they consent to have RIPE NCC store and distribute their data?

The contract between the end user and the LIR must comply with https://www.ripe.net/publications/docs/ripe-637. At the minimum, all contracts must include: - Notice that the LIR is responsible for liaising with the resource holder to keep registration records up-to-date - Notice that 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 - Notice that none of the provider independent resources may be sub-assigned to a third party - Notice that the resource holder is obliged to pay an annual fee to the LIR for the resources - A clear statement that the resources will return by default to the RIPE NCC if - The resource holder cannot be contacted - The annual fee to the LIR is not paid - A clear statement that the use of resources is subject to RIPE policies as published on the RIPE web site and which may be amended from time to time But the RIPE NCC isn't an official party in that contract. The contract is between end user and LIR. Cheers, Sander

As sascha says and for once I agree with him, It can be argued that the LIR is a mere intermediary in this transaction, and executing contracts with the end user while standing in for ripe ncc. Like, say, a VW car dealer - who sells you a Passat TDI diesel car and their name is on all the paperwork, and they are responsible for support such as fitting accessories, servicing and repairs. But if its ECU is tampered with to game emission testing, it is still VW on the hook and not the dealer. --srs

On 07-Nov-2015, at 4:14 AM, Sascha Luck [ml] <aawg@c4inet.net> wrote:

...

On Fri, Nov 06, 2015 at 11:38:52PM +0100, Sander Steffann wrote:

But the RIPE NCC isn't an official party in that contract. The contract is between end user and LIR.

Well... Considering that such a contract must be submitted to, and approved by, the RIPE NCC (or it will not result in the assignment of resources); I'm of the opinion that a court might well see the NCC as a party. It has never been tested though (and neither has the NCC data protection policy) and my view doesn't seem to be shared by many...

rgds, Sascha Luck

In message <B6D5AF09-57C5-4CB0-8DAB-85BD57139BBE@steffann.nl>, Sander Steffann <sander@steffann.nl> wrote:

The contract between the end user and the LIR must comply with https://www.ripe.net/publications/docs/ripe-637. At the minimum, all contracts must include:

- Notice that the LIR is responsible for liaising with the resource holder to keep registration records up-to-date - Notice that 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 ... - A clear statement that the use of resources is subject to RIPE policies as published on the RIPE web site and which may be amended from time to time

But the RIPE NCC isn't an official party in that contract. The contract is between end user and LIR.

As a matter of law, you are, I believe, wrong. Based on all of the above, RIPE is quite clearly both (a) named explicitly in all of these LIR/end-user contracts and also (b) a third-party beneficiary of all of these contracts. I certainly give everyone involved with drafting the language you've quoted above (and also everyone who is out there who has drafted any LIR/ end-user contract) high marks for these elaborate efforts to try to dance around the uncomfortable fact that RIPE actually _is_ a party to all these contracts. But at the end of the day, all of the lingusitic contortions cannot change the facts of the matter. RIPE _is_ a party to all of these contracts, and thus, all end-users holding RIPE number resources _do_ already have a contractual relationship with RIPE at the present time. To claim that they do not seems to me to be merely a matter of diverting one's eyes from the unpleasant truth of the matter. Regards, rfg P.S. By a very strange coincidence, I was recently investigating one particular spammed-for web site which, on its Terms and Conditions page, made what seemed at the time to be a rather obscure refrence to an equally obscure UK law. I looked up the relevant law and found that it was really rather interesting. I do believe that it most probably has direct bearing on the present discussion and thus, that it might possibly inform further debate: https://en.wikipedia.org/wiki/Contracts_%28Rights_of_Third_Parties%29_Act_19... See also: https://en.wikipedia.org/wiki/Beswick_v_Beswick P.P.S. If nothing else, this discussion has given me a new appreciation for Alexander Hamilton (and the early Federalists generally).

In message <CAF8DC1C-2538-4E45-B19E-50490CAA7D1A@gmail.com>, Fearghas Mckay <fearghas@gmail.com> wrote:

...

On 7 Nov 2015, at 21:13, Ronald F. Guilmette <rfg@tristatelogic.com> wrote: =20 P.S. By a very strange coincidence, I was recently investigating one particular spammed-for web site which, on its Terms and Conditions page, made what seemed at the time to be a rather obscure refrence to an equally obscure UK law.

Incorrect - it is an English and Northern Irish law, not a UK law. It does not apply in Scotland

I stand corrected. Thank you sir.

and why it would apply to a Dutch company, the RIPE NCC in this case, is somewhat uncertain as well.

To be clear, I did not assert that the Act in question applied to RIPE, nor to any other Dutch entity. I only mentioned it because (a) the Wikipedia entry relating to this goes into some lengthy... and interesting... discussion of the various complexities introduced when third parties are named in contracts and also because (b) in my experience, statues and regulations found useful in one jurisdiction are often also adopted in others, and thus, the Act in question may perhaps have some sort of counterpart in Dutch law, even though that might be radically different in both scope and implications. If anyone here could in fact provide a summary of Dutch legislation and/or jurisprudence applicable to contractual third parties, that would be both helpful and illuminating at this juncture. However in lieu of that, I feel compelled to (re-)assert that which seems self-evident, i.e. that RIPE is indeed a third-party beneficiary within all LIR/end-user contracts, and that it is explicitly named as such therein. Regards, rfg

On Sat, 07 Nov 2015 23:24:48 +0000, Ronald F. Guilmette wrote:

However in lieu of that, I feel compelled to (re-)assert that which seems self-evident, i.e. that RIPE is indeed a third-party beneficiary within all LIR/end-user contracts, and that it is explicitly named as such therein.

If you're prepared to assert that, I expect you to be prepared also to identify what benefit or advantage you understand RIPE (or, as I guess you probably meant, the RIPE NCC) draws from any of these contracts. Can you do this? Will you? If not, then what you feel compelled to assert is no more than a private hypothesis of yours, and by no means "self-evident". Best regards, Niall O'Reilly

On Mon, 09 Nov 2015 00:40:52 +0000, Ronald F. Guilmette wrote:

While I do feel that the tripartite nature of the contracts in question is in fact self-evident, I can only agree that my opinion on this point is not informed by either a law degree, a "bar card" (as we say here in this country), nor even with a personal perusal of any of the contracts at issue.

Thank you for confirming my belief that you've been guessing, and that your guesses form the basis for your assertion that the "nature of the contracts in question is [...] self-evident." Best regards, Niall O'Reilly

Hi Ronald On 06/11/2015 22:44, Ronald F. Guilmette wrote:

In message <563C8773.7000804@yahoo.co.uk>, denis <ripedenis@yahoo.co.uk> wrote:

...

...

It may seem like I am quibbling over a minor semantic point here, and perhaps I am, but I think that it is somewhat inaccurate to say that there's no relationship at all between RIPE / RIPE NCC and the entities whose data is in the data base.

It is not a semantic point it is a legal point. (I am sure the RIPE NCC legal team will correct me if I am wrong :) ) The RIPE NCC is the Data Controller for this database. They manage the service and facilitate its use by other parties. Some of the RIPE NCC members in some countries satisfy their local laws by documenting every customer in the RIPE Database. This results in hundreds of thousands of INETNUM/PERSON object pairs created in the RIPE Database.

The RIPE NCC has no relationship of any sort with these people. Their personal information is in this database because they consented to it being put their by someone they have signed a contract with. The RIPE NCC has no knowledge of that contract or it's terms.

Please excuse my feeble attempts to "drill down" as it were, and understand the facts and nuances of what you've just said. (I'll admit up front a substantial level of ignorance, if that will help to make clear that I _am_ attempting to understand, and not just simply being disagreeable.)

On the one hand, you say that all these entities (both people and businesses) have consented to have RIPE NCC store and distribute their contact data. On the other hand you say that RIPE NCC has no knowledge of the terms and conditions of the contracts they have signed. Given that RIPE NCC is bound by European privacy laws, wouldn't it be fair to say that RIPE NCC is 100% confident of the content of at least one part of the contracts that all of these entities have individually signed, i.e. the part in which they consent to have RIPE NCC store and distribute their data?

It would seem to be that case that RIPE NCC is a formal, legal, and an explicitly named third party in all those contracts. Is that statement innacurate? Haven't each and every one of these individual entities, in their contracts, granted certain rights to RIPE NCC as partial compensation for the number resources they are given? If not, then how can RIPE NCC get away with what appear to be rather massive and ongoing breaches of European privacy laws? If so however, then is it at all accurate to say that RIPE NCC has "no relationship" to all of these individual entities?? (It would appear that in fact RIPE NCC has direct contractual relation- ships with each and every one of them.)

OK lets look at this again. I re-read the policy that Sander referred to. I admit I am a little rusty on some of these policies. But there are still issues here. The RIPE Database has three categories of resources in it: 1/ There are allocations made to RIPE NCC members. These are subject to a direct contract with the RIPE NCC. 2/ There are end user independent resources that are typically subject to a contract with a member, but may be directly contracted by the RIPE NCC. As Sander pointed out there is a contractual relationship with the RIPE NCC even when a member has a contract with the end user. The policy says: "End Users of provider independent resources are responsible for maintaining a contractual link to the RIPE NCC either through a sponsoring LIR or else directly to the RIPE NCC for the purposes of managing these resources." 3/ There are assignments made by members to end users from the allocations made to the member by the RIPE NCC. For category 1 it is clear. The RIPE NCC not only has a contract with these people, but has regular contact with them as they pay an annual fee. For category 2 there is mostly a contract between a member and the end user which includes some contractual commitment with the RIPE NCC to keep the contact data up to date. So the RIPE NCC "can confirm that the End User exists, continues to exist and that they continue to fulfil their obligations to comply with the original assignment conditions." These end users must pay an annual fee to the member to maintain this link. So as far as contact details are concerned everything looks good. And in most cases we know most people do the right thing anyway. But what can people do who want to intentionally misuse these resources? These end users have full control over the resource. So they have the authority to create ROUTE objects. Either the RIPE NCC or the member can validate the contact details, but I am not sure how you check they "comply with the original assignment conditions". If the registered end user doesn't use the resource and later claim the password must have been cracked, then some untraceable person is actually using it. At some point that will be discovered and the RIPE NCC can take back the resource. But the registered end user has simply broken a commercial contract by not using the resource. They are not the one engaged in some criminal activity using the resource. You can't prove they gave away (or sold) the password allowing it to be misused. So I am not sure what benefit you gain by regularly validating contact details that are correct if that doesn't ensure the contacted person is using the resource. When the RIPE NCC takes the resource back they can just get another one under a different name. For category 3, these are the ones I referred to where the RIPE NCC has no direct contractual relationship with at all. They are the customers of a RIPE NCC member. The member can grant the customer the authority to create their own ROUTE objects and maybe even allow them to handle their own abuse complaints. If the member (intentionally) does not include a contract clause to not allow the resource to be reassigned by their customer it is not hard to lose track of who is actually using it. So even if all the contact data proves to be valid you may not be talking to the person actually using the resource. cheers denis

In message <20151104184211.GM47126@cilantro.c4inet.net>, "Sascha Luck [ml]" <aawg@c4inet.net> wrote:

A few people or companies who act in bad faith do not change this fact and there is no reason to put the entire membership under general suspicion and waste its time and fees with elaborate data collection / verification schemes.

In the absence of any hard evidence to the contrary (beyond one or two suspicious cases) *that* is the basis on which this discussion should be maintained.

It has been well more than just one or two cases, and I suspect that you know that. Only one or two GLARING cases per month perhaps, but over time it has added up.

Besides, even business data is somewhat sensitive. Where else outside the LIR/RIR world do businesses have to maintain all information about all of their business relationships in a public database?

I, for one, was not aware that RIPE (or RIPE NCC) required businesses to "maintain ALL information about ALL of their business relationships in a public database". If you could elaborate, I feel sure that it would be illuminating, for me at least.

... All the mntner object does is grant access to change a ripedb object. It says nothing about who operates a resource or what they are doing with it.

The above two sentences are simply and demonstratably false. I have the evidence to prove both statements false. Unfortunately, I am not at liberty to share that evidence just yet. Regards, rfg

In message <20151105220739.GW47126@cilantro.c4inet.net>, "Sascha Luck [ml]" <aawg@c4inet.net> wrote:

On Thu, Nov 05, 2015 at 01:50:37PM -0800, Ronald F. Guilmette wrote:

...

It has been well more than just one or two cases, and I suspect that you know that. Only one or two GLARING cases per month perhaps, but over time it has added up.

so what? the NCC has 14,000 members (or thereabouts) and there are however many end-users too. I still maintain that only a minuscule fraction are criminals.

Only a miniscule fraction of the general population are bicycle thieves. Should we all save ourselves the time and trouble and stop even buying bicycles locks?

...

I, for one, was not aware that RIPE (or RIPE NCC) required businesses to "maintain ALL information about ALL of their business relationships in a public database". If you could elaborate, I feel sure that it would be illuminating, for me at least.

For any NCC member, you can easily enough derive from the ripedb who their transits are, who their customers are, who they are peering with and so on. You won't probably find out who cleans their toilets but that is not what I meant.

I quoted you word for word. You said we could find out ALL information and ALL business relationships, just by perusing the RIPE data base. If you didn't mean it, why did you say it? And I was really hoping for a minute there that that was actually true! I was hoping that you could dive in and tell me who all of Volkswagen's firmware contractors are. :-)

...

...

... All the mntner object does is grant access to change a ripedb object. It says nothing about who operates a resource or what they are doing with it.

The above two sentences are simply and demonstratably false. I have the evidence to prove both statements false.

Please, Ron, RTFM for *once* before throwing accusations about.

It wasn't an "accusation". I stated a fact. I'm looking an a number resource which is registered to a bogus entity. The mntner object reveals the actual identity of the party currently controlling that resource.

...

Unfortunately, I am not at liberty to share that evidence just yet.

Ahaha.

Laugh now... while you can. Regards, rfg

In message <20151106003148.GX47126@cilantro.c4inet.net>, "Sascha Luck [ml]" <aawg@c4inet.net> wrote:

On Thu, Nov 05, 2015 at 03:48:43PM -0800, Ronald F. Guilmette wrote:

...

Laugh now... while you can.

Threats again, is it? I call on the chairs to point out to this individual that n.a.n.a.e tactics are not welcome on this list.

<<me, scratches head>> Other than my dastardly "threat" to eventually post data which will support my assertion that mntner records occasionally contain useful information about the true identities of the holders of certain number resources, I'm not at all sure what Mr. Luck has become so exercised about. <<shrug>> I call on the chairs to point out that the only thing that I threatened Mr. Luck with was eventually proving a couple of his assertions relating to the value of mntner records incorrect. Regards, rfg

Hi Ronald On 06/11/2015 00:48, Ronald F. Guilmette wrote:

In message <20151105220739.GW47126@cilantro.c4inet.net>, "Sascha Luck [ml]" <aawg@c4inet.net> wrote:

...

...

...

... All the mntner object does is grant access to change a ripedb object. It says nothing about who operates a resource or what they are doing with it.

The above two sentences are simply and demonstratably false. I have the evidence to prove both statements false.

Please, Ron, RTFM for *once* before throwing accusations about.

It wasn't an "accusation". I stated a fact.

I'm looking an a number resource which is registered to a bogus entity. The mntner object reveals the actual identity of the party currently controlling that resource.

Maybe you missed my comment about use of MNTNER objects. You cannot make this assumption. The MNTNER object is a box of anonymous tokens. In most cases those tokens relate to the holder of the MNTNER object and the resources they maintain because most people are open and honest and doing things right. But, especially when you have already identified a bogus entity, the MNTNER object may be held by someone unrelated to that entity or the resources it maintains. Only those anonymous authorisation tokens relate to the resource. Nothing in the database Terms & Conditions require the holder of that MNTNER object to reveal who sits behind an encrypted password in the object. They have not broken the T&C by setting the data up in this convoluted way. The data model allows it. cheers denis

...

...

Unfortunately, I am not at liberty to share that evidence just yet.

Ahaha.

Laugh now... while you can.

Regards, rfg

In message <20151104143230.GK47126@cilantro.c4inet.net>, "Sascha Luck [ml]" <aawg@c4inet.net> wrote:

No. Just NO. I am, frankly, flabbergasted at this mindset:

1) All resource holders are presumed to be bad actors and all of their data must be kept in a database, their correctness to be strictly enforced.

I am sure that your view is sincerly held, carefully considered, and shared by at least some, and perhaps many other RIPE members, but... I really would like to be there with a video camera the next time you find yourself having to go through airport security. YouTube stardom awaits us. Regards, rfg

In message <20151105214840.GU47126@cilantro.c4inet.net>, "Sascha Luck [ml]" <aawg@c4inet.net> wrote:

On Thu, Nov 05, 2015 at 01:31:31PM -0800, Ronald F. Guilmette wrote:

...

...

1) All resource holders are presumed to be bad actors and all of their data must be kept in a database, their correctness to be strictly enforced.

I am sure that your view is sincerly held, carefully considered, and shared by at least some, and perhaps many other RIPE members, but...

I really would like to be there with a video camera the next time you find yourself having to go through airport security.

This is an argument? The NCC should be like airport security?

From where I sit however, I see more parallels with the latter than

No. Ideally, I would like to see RIPE strike some appropriate and reasonable balance between airport security and "Lord of The Flies". the former. Regards, rfg

In message <637758753.2826426.1446595528880.JavaMail.yahoo@mail.yahoo.com>, ripedenis@yahoo.co.uk wrote:

Ronald "I neither mentioned nor asked about out-of-region objects." "then proceeded to announce a bunch of self-evidently bogus routes to relat= ively large swaths of APNIC address space."

Last time I checked APNIC address space is 'out of region' for RIPE.

Yes, but you're misplacing the emphasis. With regards to this specific incident (and this specific set of what looks to be 3 inter-related rogue ASNs) I myself don't really care which 1/5th of the world they are stealing IP space from. I just want to know who they really are. The region they are stealing from (at the moment) is almost irrelevant. By tomorrow, they'll be stealing from AFRINIC, and then from LACNIC the day afrer that.

A lot of what {bad guys} do also seems to involve out of region resources.

Yes, but not all. I say again, I don't care which 1/5th of the wold they are messing with. Regardless, I want to be able to identify them.

That {past} discussion seemed to centre on wonderful, technically brilliant, perfe= ctionist systems of cross registry authentication to solve the entire problem.

I'm not even talking about (or even interested in) route objects in the data base at the moment. That's a whole different problem and a whole different kettle of fish. At the moment, I personally am focused on ORG- records.

But if you want anything like this to happen, regar= dless of who does it (RIPE NCC or members), then you have to move beyond th= e initial arguments against it, propose a policy and take it through the st= ages of discussion. If there is a consensus on doing it/something/whatever = then that will happen.

Yes. Understood. Thank you.

If= someone gets around the legal requirements in their country and is able to= set up a bogus company with legitimate papers, they will get internet reso= urces. As you have noted, there are many countries in the RIPE region where= corruption runs at very high levels. If you have the right contacts you wi= ll get your bogus company.

To be clear, perhaps *someone* here noted that "there are many countries in the RIPE region where corruption runs at very high levels", but whoever that may have been, it wasn't me. I believe that to be a factually accurate statement, but I personally did not make any such comment here, I think. But regardless of whether I did or didn't, you are again missing the point and (thus) vearing off onto unrelated tangents. As I have repeatedly said, it is my clear impression that the case of AS204224 *does not* involve anybody bribing anybody to create a new and/or largely fictitious company, but rather, this seem to be a good old-fashioned case of identity theft. I may be wrong about that, but that also would be irrelevant. I am certainly not so deluded as to believe that anything with either RIPE or RIPE NCC might do erase all traces of corruption from the face of the earth, and I am *not* urging that either RIPE or RIPE NCC set out on any quixotic quest to do so. Rather, I've suggested the much more modest goal of at least trying to insure that contact details present in the data base are actually associated with the parties they allegedly represent. Such a step would, I think, foil many, if not all attempts at identity theft, as in the case of AS204224, even through they quite certainly would have no effect at all on world-wide corruption.

You have to accept that Europe, Middle East and Central Asia is a very diff= erent landscape than the USA. Whilst I applaud efforts to validate data, th= e misuse of valid data will still happen.

We are in agreement.

... There should be no object in the database that is not directly or indirectly linked to an ORGANISATION object.

Again, we are in agreement. I'll even go further and say I am frankly rather surprised that the simple rule you just elaborated is not already in place. Regards, rfg

In message <563BDB1C.4020408@yahoo.co.uk>, denis <ripedenis@yahoo.co.uk> wrote:

On 05/11/2015 21:33, Ronald F. Guilmette wrote:

...

In message <637758753.2826426.1446595528880.JavaMail.yahoo@mail.yahoo.com>, ripedenis@yahoo.co.uk wrote:

With regards to this specific incident (and this specific set of what looks to be 3 inter-related rogue ASNs) I myself don't really care which 1/5th of the world they are stealing IP space from. I just want to know who they really are. The region they are stealing from (at the moment) is almost irrelevant. By tomorrow, they'll be stealing from AFRINIC, and then from LACNIC the day afrer that.

This really does matter. Even with a valid RIPE ASN they cannot 'steal' RIPE address space.

Really??? If so, that's great news! Did everyone finally agree to use only fully authenticated route announcement protocols while I was sleeping?? Or is BGP fundamentally still wide open?

When it comes to getting an ASN the AUT-NUM does require reference to a PERSON/ROLE object. But you can pick any PERSON or ROLE object in the database and reference them. Technically there is no cross checking. The 'owner' of those objects will not get notified. So unless the RIPE NCC questions your choice of objects all the contact data in those objects will be perfectly valid. They just have no relationship with you.

I would like to thank you for explaining this to me. I really didn't know this. I _would_ actually thank you for bringing this to my attention, but I'm really feeling very unwell all of of sudden. I think that I may vomit. Plese excuse me. I hope to be back later. Regards, rfg

In message <563BF492.2020106@yahoo.co.uk>, denis <ripedenis@yahoo.co.uk> wrote:

On 06/11/2015 00:58, Ronald F. Guilmette wrote:

...

In message <563BDB1C.4020408@yahoo.co.uk>, denis <ripedenis@yahoo.co.uk> wrote:

...

This really does matter. Even with a valid RIPE ASN they cannot 'steal' RIPE address space.

Really???

If so, that's great news!

Did everyone finally agree to use only fully authenticated route announcement protocols while I was sleeping?? Or is BGP fundamentally still wide open?

I am only concerned with the RIPE Database and making sure what is in there is properly authenticated.

I understand. I'm just highlighting that your goals and mine are different. I want to be able to _identify_ the bad guys, no matter what they steal and no matter what mechanisms or subterfuges they may use to steal it. Even if they are making crooked route announcements that have no corresponding route objects in the data base, I still want as many clues as I can lay my hands on to help me figure out who they really are. Regards, rfg

On Thu, Nov 05, 2015 at 11:41:32PM +0100, denis wrote:

When it comes to getting an ASN the AUT-NUM does require reference to a PERSON/ROLE object. But you can pick any PERSON or ROLE object in the database and reference them. Technically there is no cross checking. The 'owner' of those objects will not get notified. So unless the RIPE NCC questions your choice of objects all the contact data in those objects will be perfectly valid. They just have no relationship with you.

To be fair, there is some egregious rubbish in the db. I have a person: object I can't delete because it is: a) not maintained by my mntner b) referenced from an org: object for a company that I once worked for but that hasn't existed in 10 years. I don't even know why this org: is still in there as the company is not on the membership list anymore so nobody is paying any bills. This has nothing to do with vile criminality but I think it makes a point for a database cleanup effort. I doubt it is the only "dead body" that's in the db.

In message <20151103134248.GE47126@cilantro.c4inet.net>, "Sascha Luck [ml]" <aawg@c4inet.net> wrote:

On Tue, Nov 03, 2015 at 02:28:03PM +0100, David Hofstee wrote:

...

In that line of thought: I would like email validation on a regular basis. There are so many email addresses that do not work properly (what then is the sense of registering invalid data?).

There are LIRS that register many thousands of objects. Even small LIRs can have many hundreds. Is the idea that they employ someone full-time to solve captchas for the NCC (another idea from this discussion)?

Frankly, I'd rather have the spam, at least I can filter that.

This seems to be a compltely valid question/point/argument. I'm frankly not sure how the idea of using CAPTCHAs even got mixed up in all this. I have trouble understanding how CAPTCHAs would be either necessary or useful in this context. (Maybe someone can enlighten me.) I am laboring under a huge disadvantage because, to be honest, I don't even understand the _current_ process... and that's probably the basis for my befuddlement about CAPTCHAs. Hos is an ORG-*-RIPE record currently created? Who creates it? In my own idealized version of future reality, which I freely admit may bear no resemblence to either current practice or even future possibility, the party that needs to have a specific ORG-*-RIPE record would start by creating an account someplace... maybe, you know, like at www.ripe.net or something. The party who needs the record would be the party who the record will represent. So if "Vladimir's Tool and Die Company" had reason to need an ORG- record, Vladimir himself, *not* his LiR, would start by creating an account someplace. Once he had that, then, while he's logged into that account, Vladimir would poke some button which would begin the process of creating the ORG record. He would then be asked to fill in a form with his contact details... name, company name, address, phone, e-mail. He would do this and then poke the submit button. Not long after that Vlad would get an automated phone call telling him that his magic cookie is 734926. Now... and this is the important part... WHILE HE IS STILL LOGGED IN, Vlad would poke some button that says "Validate", whereupon he would be presented with a really simple web form containing only a single small text entry box. Valdimir would put his magic cookie into the box and then poke the submit button. That would complete the validation. In this scenario, there is absolutely no need for any CAPTCHAs. Hypothetical attackers who might try to brute-force the magic cookie wouldn't ever even get the chance to even try, because they would have to be logged on to Vlad's account... using Vlad's login credentials... before they would even get to the screen containing the form where one enters the magic cookie. So, um, what am I missing? Regards, rfg

In message <78C35D6C1A82D243B830523B4193CF5F9F4EF1D606@SBS1.blinker.local>, David Hofstee <david@mailplus.nl> wrote:

Neither do I. But what I do think is that RIPE should do the work that it is set out to do, namely registration of data. It should do that very well. Make sure that the data is sufficient, valid and remains to be valid. And that clear indicators of that not happening should be seen as a problem/abuse. That does not make them the internet police, it makes them police their own data validity (the only thing of value).

As should be obvious, I am in near total agreement with all of the above, however I feel absolutely compelled to take issue with that parenthetical remark at the very end. Yes, obviously, the WHOIS data base represents the "crown jewels" as it were. But as Brian has just reminded me, the value of RIPE is also enbodied in its human and institutional aspects... the meetings, the committees, and above all, the democratic process. (Constructing and maintaining a functioning democratic process isn't easy. Just ask any American. We don't have one at the moment. :-) Also, of course, the fine work done by RIPE NCC and RIPE Labs must be acknowledged. The Routing History tool, in particular, is one that I personally find invaluable, and it seems to have no counterpart or parallel anywhere else. I feel sure that you, David, fully appreciate these additional aspects of RIPE too, so this message is not a chastisment, merely a friendly reminder to all that RIPE is far more than just the data base. Regards, rfg

On Tue, Nov 03, 2015 at 07:13:17PM +0530, Suresh Ramasubramanian wrote:

I would actually prefer any such proposal to come from within the regular RIPE community, rather than from one of us outsiders.

For once I agree completely. If this goes to an actual proposal, this needs to be in APWG as it would be: a) address policy b) affecting the entire community Any contractual changes will also need membership approval via GM vote anyway. rgds, Sascha Luck

Hi, On Tue, Nov 03, 2015 at 07:25:44PM +0530, Suresh Ramasubramanian wrote:

If you can tell me just how a consensus at APWG and MAAWG, say, or on various actually security focused lists, that the RIPE community needs policy changes is going to make an iota of difference to what policies get implemented by RIPE NCC

None at all. If you want the NCC to do something, you need to do this in the RIPE community (and you are part of it, by being here). "APWG" in this context meant "RIPE community address policy WG", not whatever other APWGs exist :-) Gert Doering -- APWG chair, of RIPE -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

On Tue, Nov 03, 2015 at 07:25:44PM +0530, Suresh Ramasubramanian wrote:

If you can tell me just how a consensus at APWG and MAAWG, say, or on various actually security focused lists, that the RIPE community needs policy changes is going to make an iota of difference to what policies get implemented by RIPE NCC

APWG is the address-policy wg mailing list, the main RIPE list for anything to do with resource policy, so yes, it is relevant. Any lists outside the RIPE WGs are rather not.

The exact converse applies, however, in a RIPE meeting or in the AAWG, where the defenders of RIPE are many, and people criticizing it pitifully few in number, and occasionally, like RFG, rather noisy in nature, which doesn’t quite help but which is not quite relevant to the continual problem RIPE NCC has with criminals gaming their systems while staying perfectly within whatever restrictions are in place.

This is probably mostly because the vast majority in the RIPE WG lists and certainly the meetings are the membership of the NCC. The NCC is not some authority set over us, *we* are the NCC. We fund its services through membership fees, we elect the board, we try to find the best balance of policy for *all* its members as well as the wider RIPE community. We are the network operators and we tend to have experience with all facets of LIR operations, rather than just security or abuse handling. So yeah, in the opinion of this member, we are doing the best job possible given all these factors. rgds, Sascha Luck

On 04/11/2015 23:09, Ronald F. Guilmette wrote:

In message <C01FCD42-551B-496F-AFFF-BF5561150580@gmail.com>, Suresh Ramasubramanian <ops.lists@gmail.com> wrote:

...

Right now, most other lists that I see this thread start up on, there are a few people who defend RIPE NCC - and a lot of people who dump on it for this kind of thing.

I like to think that I am neither defending nor dumping on either RIPE or RIPE NCC. I'm still too busy being flummoxed and mystified to do either of those other things.

As I've said, everyone who cares about the quality of their data... from Google Voice, to Craigslist, to UPS... has already been doing the obvious thing for years, i.e. checking it. I'm still trying to get my arms around the idea that RIPE doesn't. That's so last century.

And anyway, this isn't a RIPE NCC thing. It's a RIPE thing. As I understand it, RIPE decides and RIPE NCC implements. What am I missing?

Somewhat, but there is, and always has been, quite a lot of confusion/conflation between the RIPE Community and the RIPE NCC. Also, there have been instances when the NCC (of whom I'm an unabashed fan) have taken actions that the Community have felt should have had a policy behind them. Mostly it works and a lot of people work hard to make sure it continues to work, but as with a lot of relationships, there are frictions and confusions at times. The NCC are responsible for the maintenance of the DB and who gets what resources, under the policies the Community have created. Of course the Community is a nebulous thing, the NCC are a company and are often the... I hesitate to use the word 'target' but I can't think of a better one. They (or it) are (or is) saying "We are not the Internet police." In short, it's complicated. :) However yes, policy is created by the Community and implemented by the NCC, but imo the NCC are likely to be the ones ultimately beaten up by people who do not like the policy and/or the way it may be implemented. Brian

Hi, On Tue, Nov 03, 2015 at 01:49:18PM +0000, Sascha Luck [ml] wrote:

On Tue, Nov 03, 2015 at 07:13:17PM +0530, Suresh Ramasubramanian wrote:

...

I would actually prefer any such proposal to come from within the regular RIPE community, rather than from one of us outsiders.

For once I agree completely. If this goes to an actual proposal, this needs to be in APWG as it would be:

a) address policy b) affecting the entire community

Any contractual changes will also need membership approval via GM vote anyway.

I'm not so sure about APWG. "Spending resources" is traditionally ncc-services-land, "combating abuse" is definitely anti-abuse-wg... so discussing the details here, and sending a heads-up over to APWG and ncc-services is good enough for me... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

If someone regular is willing to set a direction that I see a chance of achieving consensus with - I will contribute as much as I can when participating remotely. I do believe in putting my effort where my mouth is :) --srs

On 03-Nov-2015, at 8:07 PM, Brian Nisbet <brian.nisbet@heanet.ie> wrote:

Suresh, your point is noted, however I was asking more for people to undertake to help, rather than to lead.

On Wed, Nov 04, 2015 at 02:57:21PM -0800, Ronald F. Guilmette wrote:

Just curious... How would automated verification of snail-mail addresses and/or positive automated verification of contact phone numbers implicate any contractual issues?

This particular mechanism may or may not. That's for NCC Legal to answer, not for me. rgds, Sascha Luck

On Wed, Nov 04, 2015 at 12:49:34PM -0800, Ronald F. Guilmette wrote:

Police have guns. They have handcuffs. They can arrest people.

As long as RIPE's only power is to kick certain bogus and/or poorly maintained records out of the data base, there seems little danger that RIPE will functionally qualify as being the police of anything.

The NCC has the power to de-register resources, rescind services and close your LIR. This is pretty close to the death penalty in Internet terms. Moreover, in this context, it is "police", "court" and "executioner" in one handy package. It's not as toothless as you would describe it... rgds, Sascha Luck

Hi Roland,

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.

Ok

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.

Agreed

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.

NASA is going to be so disappointed ;) But seriously: I agree

...

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 listed in the WHOIS data base?

It probably would need a mandate from its members to approve the extra budget for implementing those checks etc. But I don't see why they couldn't.

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.

Understood

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.

+1

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.

Glad we're agreeing :)

I apologize. You are correct, That comment on my part was utterly uncalled for, and I would very much like to retract it.

Consider it retracted :)

But I hope that you understand my sensitivity.

I do. Sometimes when discussing difficult subjects the wording can get a bit too strong. I can deal with that, and I know you have good intentions. I now understand your ideas better, and understand that you are looking for a first step in improving the database accuracy. Not looking for a complete solution as I was :) I think we reached the point where we should ask the RIPE NCC on their opinion on this and to see what they think is doable. Cheers, Sander

On Wed, Nov 04, 2015 at 01:10:01PM -0800, Ronald F. Guilmette wrote:

I'm just putting myself in their shoes. If I were them, and I was asked my opinion about something that, in the short run at least. would, increase my workload, I would scream, holler, tear my hair out, pound my fist on the table, and insist that the whole thing is absolutely positively technically infeasible, and that even if it isn't, it will still cost fifty billion dollars and take ten years to fully implement.

The NCC Impact Statement is actually a formal part of the policy development process nowadays. It details how the proposed policy change affects the various departments, the manpower requirements, how much it'll cost, whether there are any legal problems with it, etc. I've not seen it happen but I'm sure there is a theoretical possibility that they'll say "Can't be done" but they'll also detail why and then the policy can be changed accordingly.

Are there any countries within the RIPE region that would allow one of their citizens to register to vote if that citizen gave his mailing address as "99999 Pluto Way, Mars, Milky Way" ? If

No idea, all I can say is that in Ireland you will give them your correct address and they'll still scratch you off the register because of "wrong address". I call it the Disenfranchise Department. Maybe in other places you can register without an address or a bogus one. rgds, Sascha Luck

On Mon, Nov 02, 2015 at 07:06:09PM -0800, Ronald F. Guilmette wrote:

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.

Please, don't treat Europe as a single jurisdiction/country/state etc. Just to comment - last week I have been given a disposable sim card with new phone number at the local student cafeteria without even asking for it. In Europe. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl

Ron, Some simple facts:

However RIPE itself only holds its own position and authority by dint of the charter which has been granted to it by IANA.

No. RIPE holds its own position and authority by the consent of the European Internet address using community.

And IANA in turn only holds its position and authority by dint of the charter which has been granted to it by ICANN.

No. IANA is a set of functions currently performed (depending on your point of view) by ICANN under RFC 2860 and RFC 7020 and/or via contract to the US Dept. of Commerce, NTIA.

Thus, in short, it appears to me that ICANN effectively sets the policy for everyone, and specifically for all five of the Regional Internet Registries, including RIPE.

No. All five RIR policies are defined by their respective communities, most assuredly NOT by ICANN. ICANN's role with respect to the RIRs is exclusively in relation to the establishment of new RIRs (RIPE existed prior to ICANN's creation) and the publication of IANA-related resource management policies that have reached consensus among all five RIRs. Regards, -drc