<html><head></head><body><div style="color:#000; background-color:#fff; font-family:Helvetica Neue-Light, Helvetica Neue Light, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif;font-size:16px"><div dir="ltr" id="yui_3_16_0_1_1446572963081_16281">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.</div><div id="yui_3_16_0_1_1446572963081_16476" dir="ltr"> </div><div id="yui_3_16_0_1_1446572963081_16500" dir="ltr">cheers</div><div id="yui_3_16_0_1_1446572963081_16501" dir="ltr">denis</div><div id="yui_3_16_0_1_1446572963081_16284" style="font-family: Helvetica Neue-Light, Helvetica Neue Light, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif; font-size: 16px;"><div id="yui_3_16_0_1_1446572963081_16283" style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif; font-size: 16px;"> </div> </div> </div></body></html>