Fwd: RE: Database security
Dear all, due to finger trouble I failed to send my reply to the list(s) as well. My apologies - here you go... Wilfried. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ First of all I'd like to start out by confirming, IMHO, the usefulness of this sort of on-line discussion. Next, in order to balance what I'm going to add as my comments further downstream, I'd like to assure you that I *do* understand your concerns. And on top of that, it might be useful to include the Local-IR WG... => Lets discuss, what measures should be taken to circumvent the situation you describe. => I can see the problem from two different point of views: => => 1) Yours. Then we have to close the database down, to a bare => documentation-tool for IP-Nets, accessible only by the registries. = = Thats not what I said. For example, the DB could only hide specific fields =behind a password. For example, the "descr" field which gives away the company =name. There's two basic problems with that: . I don't expect any agreement (soon) as to *which* fields should be hidden. We've been through that one recently - and painfully :-( All of the fields have been invented and defined because there was a community consensus about the usefulness of that sort of *public* information. If we can identify attributes which we do not need any longer, let's scrap them rather sooner than later :-) . The DB is not used by the operations folks exclusively, but also by the LIRs, I suppose, e.g. to cross-check the more complex IP-Address requests. Hiding descr: attributes would severly impede that possibility... On a more general level, restricting access to "registries" doesn't get you anywhere. Re-living the scenary you describe, the new "nasty" new-comer would simply arrange for a service contract with the NCC, and off we go. The cost: according to ripe-188, it's 2.650,- + 2.100,- ECU. That sounds like a bargain. And doing so gives them access to pre-paid education by the NCC staff about the use of the DB ;-) As long as I've been following the IANA/ICANN stuff recently, or have read some of the IETF drafts (rps-auth, rps-dist, amongst others), there's really no bottom to that pit we're supposed to dig... => 2) Mine. I need the database to track technical problems and people who are =able to solve them. (hopefully, this view is shared by most of the people here =;)) = = Including myself. But on the other hand, there is a problem here which, I feel, =needs to be addressed. The database structure was implemented in times when the =Internet was not so business oriented as it is today. I think that it may need =some rethinking to fit the times, so to speak :-) I fully agree with you that a fair amount of re-thinking is required during the immediate future. In particular about the usefulness of attempts to implement rules, BCPs, code of conduct and regulations by spending programming resources. It's not going to buy us anything. => The security mechanism, which is in place, is not technical, it is just =organisational. There is a copyright on the database. The uses, you describe, =are forbidden by this copyright. => => If someone violates this copyright, at least in Germany there are other =measures to forbid such a use of the database. = = Well, lucky for you in Germany :-) = Seriously, though, there is no way in which you could actually prove, in court, =the sort of thing I describe. I am talking from personal experience... *sigh* Well... I suppose in many, if not most regions, there is *quite a lot* of interesting data accessible to the "public", which does indeed have commercial value. For example in our old little country, it's access to - a comrehensive register of real estate ownership (and the debts secured by that!), - the official place of residence for an individual, - an official registry for companies (including management strucure and directors,...) and for assocations, - car ownership and license plates, - phone books (and eventually we've got PNO regulation going!) on and on... I could come up with zillions of good ideas to make use of that data. And indeed some people do. Some of these attempts are legal, some others are frowned upon, the rest is illegal and triggers prosecution. This is real life. I think we have to spend more effort in the future to work on the legal and social aspects, instead of on setting up technical "filters".... Any arguments to the contrary appreciated! Regards, Wilfried (DB-WG chair) PS: Still the best way for keeping customers is offering "the" better service, whatever that is :-) -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber@CC.UniVie.ac.at Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Vienna University : Fax: +43 1 4277 - 9 140 Universitaetsstrasse 7 : RIPE-DB (&NIC) Handle: WW144 A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 --------------------------------------------------------------------------
[ lengthy discussion from db-wg@ripe.net on the issue of exposing contact information and descriptions deleted. ]
As an RPS WG geek I feel that the issue of how much personal contact information to expose should not be decided in the WG. (I don't expect any argument from the ripe community on that point. :) In order to facilitate local decision on how to protect the people and role objects, I'd like to make a proposal that would allow for standardization of the exchange between repositories but also make the decision as to how much data to expose an entirely local decision. The people and role objects would *NOT* be redisributed in the the distributed registry model. They are not needed to configure routers. The need to get people or role information is an exception that can be handled by contacting the authoritative registry (query instructions would be found using the repository objects in the registry itself). Each registry would be free to impose any restrictions that they felt their clients favor and change them since the restrictions would be implemented solely in the query interface. Part of the db-wg discussion suggested that the descr attribute should be restricted. This would be ineffective if the descr had to be included in the flooded information in order to keep the signature on the submission accurate. If it is desirable to have similar local control over access to the description information, then a new "identity" object should be created. The descr can still be placed inline for backward compatibility. Alternately a reference to an identity object can be placed in any object that now allows a descr. The reference can be called "detail" just to be different from descr. [Please separate arguments about the proposal from arguments about the choice of the names "identity" and "detail".] If we decide to do an identity object, the identity object should *NOT* be flooded just as the person and role objects are not flooded. Decisions on whether and how to restrict access to person, role, and identity would be registry local decisions and could be changed by any one registry as they felt it neccesary to do so. Do we have agreement on: 1. don't flood person and role objects (needs to be in rps-dist). 2. add a "identity" object and "detail" attribute (if so, should be added to rpsl-v2 before last call ends). Not flooding identity should be mentioned in rps-dist. 3. the names "identity" and "detail" are resonable choices. Please feel free to continue your argument (on db-wg not rps :) about how RIPE will protect the and person and role objects, and the descr (as an identity object if you decide to protect it). As long as we can make this a registry local decision RPS need not be involved. Thanks. Curtis
participants (2)
-
Curtis Villamizar
-
Wilfried Woeber, UniVie/ACOnet