- db-wg - mailman.ripe.net

Adding nic handles to contact objects without one
by Joao Luis Silva Damas 02 Mar '99

02 Mar '99

Dear all, during the last RIPE meeting, in Amsterdam, the database working group discussed a proposal to automatically add NIC Handles to all person and role objects in the RIPE Database that don't yet have one (new objects can't be created without nic handles anymore). This proposal was supported by the working group and it was agreed that it should be circulated to the mailing lists to give people not attending a chance to provide input. This does not affect how other objects reference these person or role objects. This is only intended to bring old objects into conformance with the current object definitions and does not mean that data provided by the user will be modified. Only the nic handle attribute will be given a value when the object lacks one. No other attributes will be touched. Objects which already have nic handles will not be touched. The nic handle is a tag conveying no information about the user or role described in the object. It is an identifier for the object. This addition would make data more uniform and could be a benefit for everyone. For more information on nic handles, please read RIPE 157 and RIPE 189 available at http://www.ripe.net/docs Best regards, Joao Damas Database Group RIPE NCC

4 5

Fwd: RE: Database security
by Wilfried Woeber, UniVie/ACOnet 11 Feb '99

11 Feb '99

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

2 1

RIPE32 DB-WG Draft Agenda, version 3
by Wilfried Woeber, UniVie/ACOnet 28 Jan '99

28 Jan '99

Attached please find the 3rd draft of the Proposed Agenda for the DB-WG meeting during RIPE32 in Amsterdam, next week. As compared to version 2 there are some addition and some editorial improvements. Regards, Wilfried. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Proposed Agenda for the Database Working Group Meeting RIPE-32, January 1999, Amsterdam 3. Draft A. Administrative stuff (Wilfried Woeber, chair) - appointment of scribe - agenda bashing | - deputy chair B. RIPE DB, operational update (RIPE NCC) - statistics, performance, changes, most recent mod.s - RPSL migration update, usage - documentation update C. PGP deployment in the RIPE DB (RIPE NCC: Roman) - current status of delpoyment, feedback D. DB SW Re-implementation (RIPE NCC: Joao) - status, milestones/roadmap, resources required/available E. Migration to the new SW - operational aspects - beta-test program and information exchange (ml ?) - proposal to *not* migrate obsoleted objects and attributes . dom-prefix . any others? F. I-D draft-ietf-rps-auth-01, -rps-dist-?? (??) - RIPE region requirements/comments - any progress G. Handling of person: & role: objects | - proposal to auto-generate handles for objects without a handle - proposal to *not* allow re-use of handles, pro.s and con.s - proposal to force-add maintainers for contact objects - operational issues, e.g. sharing maintenance of an object - impact on tools or scripts? | H. Timestamping & Serial #s - implementation proposal (RIPE NCC) | I. inet6num object - modification proposal (RIPE NCC) | J. Y2K cleanup - proposal to have the YYMMDDs changed to YYYYMMDD automatically | K. DB Consistency - status update (RIPE NCC) X. IETF report(s) (??) Y. Input from other WGs - Review of referral mechanism (might be promoted to be an agenda item in it's own right) - Tagging IP-Address ranges as Dial-In (proposal by Poul-Henning Kamp <phk(a)freebsd.org>) - t.b.d. Z. AOB ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WW, 26-JAN-1999 15:45 -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)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 --------------------------------------------------------------------------

2 1

DB-WG Minutes RIPE32 Edinburgh
by Wilfried Woeber, UniVie/ACOnet 26 Jan '99

26 Jan '99

Dear DB-WG, attached is the draft minutes for the Edinburgh meeting. Thanks for the scribe, and apologies for not having been able to properly distribute them in time. I'm going to come back to this during the WG meeting on Thursday. Wilfried. ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10667.907769257.1(a)ripe.net> Hi, Wilfried ! I have revised the draft minutes. Here is the second draft. Regards, AMRM ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10667.907769257.2(a)ripe.net> Content-Description: Minutes Minutes of the DB-WG, RIPE-31, Edinburgh, Scotland. ================================================== The minutes at a glance: ----------------------- Introduction: ------------ Wilfried Woeber opened the session and welcomed the participants. The task of scribe was ascribed to AMRM. The attendance list was circulated to the participants. Agenda Bashing -------------- The agenda had already been sent to the mailing list. There were two additions: a proposal to redefine the IPv6 network object (inet6num) and site; and a proposal to hide the "notify" attribute in the output from a whois look-up. The running order or sequence of the agenda was modified to allowd David Kessens to chair the IPv6 WG. Minutes from RIPE-30: -------------------- WW said that the minutes from RIPE-30 had been misplaced, but that a search for them was in progress. Actions from RIPE-30: -------------------- Ronald van der Pol, SURFnet -To summarise the proposal to allow role objects in the admin-c attribute DONE ==> PROPOSAL RIPE NCC -To clearly document the use of contact information in the RIPE db. (This was an implicit action on the RIPE NCC). David Kessens - To circulate a proposal about DNS-style tagging of NIC-handles. DONE Ambrose Magee -To publish the URL for the inconsistency report on the DB-WG list DONE (but this project was suspended in July, 1998). [NCC -To implement pgp-authentication in the db software. DONE] Summary, with Action Points: --------------------------- Administration: Participants: 50 (or 110010, Base2). Notes by Ambrose Magee. Actions & Agenda Regular reports Internet Draft presentation: draft-zsako-ripe-dbsec-pgp-authent-00.txt draft-ietf-rps-auth-01 Recommendations & Decisions: * Stop special handling of "changed:" * allow role objects in "admin-c" lines * semantics of "refer:" alert, control flag * suppress notification-related attributes, similar to "changed:" ? No, see previous item. Discussion & Input received for semantices and handling of PGP functionality => further input welcome/required !!! Actions from RIPE #31 --------------------- *AP1* Referral Mechanism: _NCC_ To document the new mechanism; by default show authoritative data only and include a hint for the end-user; provide a flag to include the "local" object as well. Circulate to TLD, DNS, DB WG's; require input from TLD's. *AP2* _WW144_ To circulate the proposal to roll-back the whois -c change (the "changed:" attribute). *AP3* _WW144_ With input from _EJB3-RIPE_, to circulate the proposal to allow role objects to be referenced by the admin-c attribute. *AP4* _NCC Registration Services_ To review the impact of this change and, if required, to specify operational restrictions (e.g. not to be used in inetnum objects that describe allocations). *AP5* _Steve Byrne_ (Steven Burley ???) To circulate a write-up or description of the proposed nameserver object. *AP6* _Kevin Hayton_ To send to the DB-WG list his input on naming RIPE documents and on how to use the names. *AP7* _NCC_ To release the draft for ripe-157++ asap; target date: mid-November 1998. DB-Software-related activites: - document "changed:"/whois -c option interactions - develop a proposal on how to generate serial numbers (for updates) and to retire the "changed" line - input from the DB-WG to the re-implementation project is required asap. - new code to handle the "auth" issues raised in the Routing WG - release specification and design information for the re-implementation asap; DB-WG to provide input; the new code is to be made available as soon as it is written. Minutes of the DB WG, RIPE #31 ============================== [Note from the scribbler: *AP* == Action Point] RIPE Database Operations Update ------------------------------- - written by AMRM, but the presentation was given by JLSD1-RIPE (AMRM was on temporary loan to the Scottish National Opera :-) ) This presentation may be seen at: http://www.ripe.net/meetings/ripe/ripe-31/pres/r31upd/index.html RIPE Database Software Development ---------------------------------- Roman Karpiuk gave a presentation on the status of the development of the RIPE Database Software. (WW144 pointed out that this is the existing software, not the new implementation). This presentation may be seen at: http://www.ripe.net/meetings/ripe/ripe-31/pres/ripe-db-software/index.html There was some discussion during and after this presentation. -Duplicate Person Objects: Gert Doering, (SpaceNet), asked if fuzzy matching would be done on duplicate person objects. RK answered that currently, only simple string comparison would be done. Janos Zsako, JZ38, (BankNet), suggested that the proposal to disallow duplicate person objects should be discussed with the ccTLD's. He suggested that each ccTLD should allow other ccTLD's to add "notify" attributes to person objects that are referenced by domain objects from more than one country. WW144 felt that the ccTLD must be consulted. -Plans RK asked for input from the WG. -Questions && Discussion + Referral Mechanism for Domain objects WW144 thanked the NCC for implementing this referral mechanism. He suggested that an option be added to "whois" that forces a whois look-up to return the local object. He suggested that alternatively, both (or all objects, if they exist) should be returned - a sort of recursion. He asked for input. David Kessens suggested that "-R" be used as the option or flag to suppress referral or look-ups outside the RIPE database. Asger Kring (?), DK ccTLD Registry, said that these look-ups are often done by end-users and thus, it would be better to keep things simple. He suggested that the default behaviour be referral only and that a "flag" or option be required to get the local object. David Kessens agreed with this. WW144 suggested that we reverse the default behaviour of whois, for _new_ functionality. DK58 recommended that if a referral is done, then a notice should be prepended to indicate that recursion has occured - otherwise, the RIPE NCC may be open to complaints about the content of someone else's database. WW144 agreed with this recommendation and pointed out that the output of whois is already prepended with a copyright statement. MN131 suggested that comments on the use of national [TLD] registries be obtained, in particluar on the replication of data. *AP* WW144 asked the NCC to document this proposal and to circulate it to the mailing lists (DB, TLD, DNS). NO8 recommended an insistance on feedback from the TLD-WG. He went on to suggest that the default behaviour be to show only the authoritative data, but that a flag would show the local object. JZ38 again raised the issue of ccTLD's and their response to the issue of detecting duplicate person objects and how to handle them. "changed" attribute WW144 agreed with RK that the change in the output of whois was agree in the DB list, but that problems with updating objects, and the "knock-on" or consequent problems with the auto-inaddr robot were not seen. He further suggested that it would be required to document all these interactions and a proposal would then be made to the RIPE community. Eventually, we might use the "-c" flag again. David Kessens suggested that we roll back to the original situation and fix the problem. He did not like the idea of hacking the existing situation. Hans Petter Holen suggested that an internal history of the database objects be maintained. JLSD1-RIPE pointed out that such an internal history would require internally generated data and that first, the users must agree to this. PC111-RIPE explained the problems with the auto-inaddr robot. The robot checked the inetnum object in the db to see when a certain assignment was made and to see if this assignment was done within the range that the assignment window had at that time. DK13-RIPE suggested using serial numbers and timestamps as a method to keep an internal history of the objects. JLSD1-RIPE agreed in principle with this idea. JZ38 pointed out that it was not documented that the first "changed" line should be kept. WW144 supported this idea. *AP* WW144 promised to circulate this proposal to the DB mailing list (i.e. to roll-back the change to the output of whois and the "changed" line). He further suggested that the RIPE NCC and the DB WG devise a method of tracking updates of objects (using serial numbers ?) and then retire or redefine the function of the "changed" line. Role objects in admin-c lines ----------------------------- EJB3-RIPE, following up the proposal made by RVDP3-RIPE at RIPE #30, said that the current use of the role object is limited to non-admin-c attributes. He went on to say that address space is not assigned to an individual, but to an organisation. He then made a presentation about using role object in admin-c lines. This presentation is available at: http:// His presentation may be summarised by saying: the use of the role object in the admin-c line should be allowed. - Questions & Discussion AVA4-RIPE pointed out that NCC Registration Services need to see when someone leaves a local registry, especially when that person has experience of LIR procedures and policy. Currently, when a local registry changes its admin-c, the top level allocation object must be changed manually by NCC Registration Services. EJB3-RIPE replied that the information is still in the role object. WW144 recommended that the admin-c for a role object must reference a person object and not another role object. *AP* WW144 proposed that role objects should not be allowed for top level allocation objects. He went on to say that if there was consensus on this issue, then the boundary conditions should be defined. JZ38 agreed with this exception i.e. that role objects should not be permitted in top level allocation objects. DK58 agreed with the proposal and suggested that an "organisation" object be specified in the new implementation of the db. EJB3-RIPE recommended that this proposal be implemented asap. *AP* WW144 recommended that the DB WG should accept this proposal and thanked EJB3-RIPE for making it. At this point, the session adjourned for coffee. ----- Coffee ----- Suppression of the "notify" attribute in the output of whois ------------------------------------------------------------ WW144 said that there was a proposal from Australia (who ???) to suppress the "notify" attribute in the output from whois. The DB WG did not have a strong opinion on this and this proposal was not considered any more. IPv6, inet6num and site object ------------------------------ WW144 reminded the DB-WG that, following decisions made at IETF-42, formal requests for IPv6 address space were sent to the three regional registries. The regional registries will design the procedures and co-ordinate the activities. JLSD1-RIPE showed a template and an example of an inet6num object in the RIPE database. He requested comments on what functionality could be added to, or deleted from the object. He pointed out that there is no "route" object for IPv6, but said that the Routing WG will look at this. WW144 discussed the site object; he said that currently it is used to track tunnelling and IPv6/IPv4 address translation. He recommended that the DB WG look at the 6 Bone homepage on the web at http://www.6bone.net/ and he recommended that they read the RPSL specifications, the RIPE-181 document and review the inet-rtr object. Nameserver object ----------------- Steve Byrne (Steven Burley ??? ) suggested that a "nameserver" object be used in the RIPE database. *AP* WW144 asked him to write a proposal and to circulate it on the DB WG list. DB Software Re-implementation ----------------------------- JLSD1-RIPE gave a presentation on the re-implementation of the db software. This presentation is available at: http://www.ripe.net/meetings/ripe/ripe-31/pres/reimp/index.html - Questions && Answers Kevin Hayton (KH220-RIPE) asked if the new software would address the security issues as done in the IRR. He went on to ask if a web-interface [for updates] would be provided. JLSD1-RIPE said that the security issues would be handled in the new implementation and that if required, a web-interface would be developed. JLSD1-RIPE went on to say that the new implementation would have three separate modules: one each for Inetnum, Domain and Routing object, but that the underlying access would be the same. WW144 asked if the progress of the new code would be made public ? JLSD1-RIPE replied that there would be regular reports, which would be quickly followed up with the new code. He went on to say that the current aim was to support the current functionality. SB-RIPE asked if the new code would be written in PERL. JLSD1-RIPE replied: "No". WW144 said that he hoped that the package would be self-contained. JLSD1-RIPE said that the new implementation would not specify which SQL engine should be used. Thus, the new implementation would have a well-defined API and users could then obtain appropriate drivers. He added that, initially, MySQL would be used. AH102-RIPE asked what was the proposed implementation language. JLSD1-RIPE replied that it would be C - for reasons of maintainablility and resources. He went on to say that if the new code was to adequately support the RAToolSet, then it must be capable to respond _very_ quickly to look-ups. Thus, a faster response time was required (e.g. to support prefix authentication, as supported by the code of the Routing Registry). WW144 thanked JLSD1-RIPE for his presentation. Internet Draft on database security ----------------------------------- WW144 introduced the presentation by JZ38 by saying that he [JZ38] had written an internet draft and that this document would be adopted by the RPS WG of the IETF. JZ38 presentation may be found at http:// WW144 thanked JZ38 for his presentation and added that the code was now available on the RIPE NCC's Beta site. Deployment of PGP in the RIPE db -------------------------------- JLSD1-RIPE gave a presentation on the deployment of PGP in the RIPE db. This presentation is available at: http://www.ripe.net/meetings/ripe/ripe-31/pres/pgp-sup/index.html He said that licenses would only be be issued for users who already had a mntner object and that licences would issued within the next two to three weeks. JLSD1-RIPE said that details about support would be sent to the DB-WG mailing list. WW144 asked that that this mail be also sent to the LIR WG. HPH2/HPH14-RIPE agreed with this. WW144 emphasised that the licences were for PGP Version 5.0, although newer versions were available. Steven Byrne (Burley ???) asked if the licences were issued to a user. JLSD1-RIPE replied that the licences were issued on a per cpu basis; if a user requires more, s/he should ask for them. There were no questions about the cost of these licences. Upgrade of ripe-157 ------------------- JLSD1-RIPE gave a presentation on an upgrade of, and a replacement for, ripe-157. This presentation is available at: http://www.ripe.net/meetings/ripe/ripe-31/pres/ripe157plus/index.html - Questions && Answers; ripe-157++ Kevin Hayton (KH220-RIPE) said that although the content of RIPE documents was important, the presentation was also important. Furthermore, he suggested that the naming structure be reviewed and that the documents be redesigned to include hot links to other documents. WW144 agreed with this idea for html versions of RIPE documents. He suggested that key documents be given *AP* generic names. He also asked Kevin Hayton to send his ideas to the mailing list. - Questions && Answers; PGP and the RIPE db Kevin Hayton (KH220-RIPE) asked if the key certificate object would be listed in the general whois enquiries. JLSD1-RIPE replied that it would. KH220-RIPE suggested that this might be a security compromise. JZ38 said that a user must submit the public key to the db so that it is available for anyone to check the signature. Petra Zeidler, Xlink, felt that sending a key-certificate object to the RIPE db by e-mail, with no other checks was risky. JZ38 felt that the RIPE NCC should identify to whom a given certificate belongs and that is why they require that that anyone who requests a key certificate object must first have a mntner object in the RIPE db. He added that any problems with this approach would be detected by the notification mechanism and then the problem could be solved off-line afterwards. WW144 pointed out that this is the first attempt to upgrade security in the RIPE db, but that it is not the definitive one. The goal was to implement an useable system, sooner rather than later, although the shortcomings of the initial implementation were known. Petra Zeidler suggested that key certificate objects should only be visible to the maintainer her/himself. The meeting felt that there was a danger that some people will use the PGP key in the RIPE db for other purposes. JZ38 recommended that users should check other sources of public key rings. Petra Zeidler suggested that the type of key be mapped into the key certificate object itself. JZ38 recommended that users should always retrieve the local key. Petra Zeidler commented that a key-ring of 1200 keys would be slow. AH102-RIPE commented on how to check the authenticity of a key, instead of the NCC not taking responsibility for the authenticity of a key. JZ38 said that people who use PGP should be aware of this. RPS authorisation && authentication ----------------------------------- Cengiz Alaettinoglu gave a presentation on RPS authorisation and distributed RPS. This presentation may be found at: http://www.isi.edu/~cengiz/talks/ and it is based on these Internet-Drafts: draft-ietf-rps-dist-00 draft-ietf-rps-auth-01 - Questions && Answers Kevin Hayton questioned whether or not RPS authorisation and authentication could cope with multi-homing. *AP* WW144 and Cengiz Alaettinoglu promised to send the name of the appropriate draft to the mailing list. IETF-42 reports --------------- WW144 said that there were no important reports from IETF-42. Input from other WG's: --------------------- Routing WG: + An IPv6 Routing Registry is being planned. WW144 invited the DB-WG to give input. + IRR Acceptable Use Policy; WW144 asked if this would form a basis for a code of conduct for the RIPE db. WW144 invited the DB-WG to contact the appropriate individuals privately. AOB: --- NULL Close ----- WW144 thanked the members of the DB-WG for participating that morning and then formally closed the session. ------- =_aaaaaaaaaa0-- --------------------------------------------------------------------------------

1 0

RIPE32 DB-WG Draft Agenda, version 2
by Wilfried Woeber, UniVie/ACOnet 22 Jan '99

22 Jan '99

Attached please find the 2nd draft of the Proposed Agenda for the DB-WG meeting during RIPE32 in Amsterdam, next week. As compared to version 1 there is a small addition and some editorial improvements. Regards, Wilfried. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Proposed Agenda for the Database Working Group Meeting RIPE-32, January 1999, Amsterdam 2. Draft A. Administrative stuff (Wilfried Woeber, chair) - appointment of scribe - agenda bashing B. RIPE DB, operational update (RIPE NCC) - statistics, performance, changes, most recent mod.s - RPSL migration update, usage - documentation update C. PGP deployment in the RIPE DB (RIPE NCC: Roman) - current status of delpoyment, feedback D. DB SW Re-implementation (RIPE NCC: Joao) - status, milestones/roadmap, resources required/available E. Migration to the new SW - operational aspects - proposal to *not* migrate obsoleted objects and attributes . dom-prefix . any others? F. I-D draft-ietf-rps-auth-01, -rps-dist-?? (??) - RIPE region requirements/comments - any progress G. Handling of person: & role: objects - proposal to auto-generate handles for objects without | - proposal to *not* allow re-use of handles, pro.s and con.s - proposal to force-add maintainers for contact objects - operational issues, e.g. sharing maintenance of an object - impact on tools or scripts? H. Review of referral mechanism (this might go to Input from other WGs) X. IETF report(s) (??) Y. Input from other WGs - Review of referral mechanism (might be promoted to be an agenda item in it's own right) - Tagging IP-Address ranges as Dial-In (proposal by Poul-Henning Kamp <phk(a)freebsd.org>) - t.b.d. Z. AOB ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WW, 22-JAN-1999 15:09:12 -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)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 --------------------------------------------------------------------------

1 0

RIPE32 DB-WG Draft Agenda, version 1
by Wilfried Woeber, UniVie/ACOnet 21 Jan '99

21 Jan '99

Attached please find the 1st draft of the Proposed Agenda for the DB-WG meeting during RIPE32 in Amsterdam, next week. As usual - comments, additions, proposals appreciated. I would also invite you to review the content hints for the individual topics, to maybe review the WG mailing list archive and - where appropriate - to submit comments and proposals to the list before the meeting; in particular if you do *not* intend to be there during the WG meeting itself. Due to considerable over-load on my end at the moment, there's a very good chance that some items are missing from the 1st draft, even if I had acknowledged them beforehand. There is no intention to drop these things! Please request them again and I'll amend the proposed agenda. I might still find them on my own, though :-) Thanks, regards, and see you in Amsterdam during next week! Wilfried. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Proposed Agenda for the Database Working Group Meeting RIPE-32, January 1999, Amsterdam 1. Draft A. Administrative stuff (Wilfried Woeber, chair) - appointment of scribe - agenda bashing B. RIPE DB, operational update (RIPE NCC) - statistics, performance, changes, most recent mod.s - RPSL migration update, usage - documentation update C. PGP deployment in the RIPE DB (RIPE NCC: Roman) - current status of delpoyment, feedback D. DB SW Re-implementation (RIPE NCC: Joao) - status, milestones/roadmap, resources required/available E. Migration to the new SW - operational aspects - proposal to *not* migrate obsoleted objects and attributes . dom-prefix . any others? E. I-D draft-ietf-rps-auth-01, -rps-dist-?? (??) - RIPE region requirements/comments - any progress F. Handling of person: & role: objects - proposal to auto-generate handles for objects without - proposal to force-add maintainers for contact objects - operational issues, e.g. sharing maintenance of an object - impact on tools or scripts? G. Review of referral mechanism (this might go to Input from other WGs) X. IETF report(s) (??) Y. Input from other WGs - Review of referral mechanism (might be promoted to be an agenda item in it's own right) - Tagging IP-Address ranges as Dial-In (proposal by Poul-Henning Kamp <phk(a)freebsd.org>) - t.b.d. Z. AOB ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WW, 21-JAN-1999 17:03:42 -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)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 --------------------------------------------------------------------------

1 0

RIPE NCC PGP license distribution
by Joao Luis Silva Damas 20 Jan '99

20 Jan '99

Dear all, as you may be aware from past presentations at RIPE meetings and discussions in the lists, the RIPE Database now supports PGP authentication as a stronger way of protecting your database objects. This use of PGP with the RIPE Database is seen by PGP Inc as a commercial use of their software that therefore requires a commercial license. To enable users to take advantage of the new feature, the RIPE NCC will distribute PGP licenses to Database users according to the policy and procedures described in a new RIPE Document: RIPE 190, available now at the RIPE NCC's website. http://www.ripe.net/docs/ripe-190.html To obtain more information on how to use PGP with the RIPE Database, please refer to the recently release RIPE 189 document, also available at the RIPE NCC's website. http://www.ripe.net/docs/ripe-189.html Please direct any questions/comments to ripe-dbm(a)ripe.net Best regards, Joao Damas Database Group RIPE NCC

1 0

New RIPE doc + new RIPE Database release
by Joao Luis Silva Damas 14 Jan '99

14 Jan '99

Dear colleagues, we are happy to announce a new RIPE document together with a new maintenance release of the RIPE Database code. New RIPE Document RIPE 189 - RIPE NCC Database documentation update to support RIPE DB ver. 2.2.1 A new RIPE document to supplement RIPE 157 as reference material on the use of the RIPE Database. Describes new or modified functionality since RIPE 157 was issued. Covers DB releases up to the 2.2.1 release (see below). New RIPE Database release Version 2.2.1 is mostly a maintenance release. There are very little user visible changes from version 2.2. For more details please read the release notes available at ftp://ftp.ripe.net/ripe/dbase/software/RELEASE-NOTES-2.2.1 This version will go into production at whois.ripe.net next Monday. It is available for download now from ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-2.2.1.tar.gz Best regards, Joao Damas & all the Database Group RIPE NCC

1 0

FW: Database security
by Barak Engel 05 Jan '99

05 Jan '99

Hi all, Wilfried asked me to forward this to the list, so here goes :-) 10x, Sincerely, \'"'/ Barak Engel ( o o ) ---------------------ooOO-^-oOOo--------------------------- barak(a)netvision.net.il Network Expert BE-RIPE BE174 Phone/Fax: +972 48 560600/551132 Cellular: +972 50 469 341 ----------------------------------------------------------- -----Original Message----- From: Barak Engel [mailto:barak@netvision.net.il] Sent: Tuesday, January 05, 1999 6:10 PM To: Wilfried Woeber, UniVie/ACOnet Subject: RE: Database security Wilfried hi, Many 10x. As I didnt see that this went to the list, Im not mailing my answer to the list too. See my comments in the text body. Barak > -----Original Message----- > From: Wilfried Woeber, UniVie/ACOnet [mailto:woeber@cc.univie.ac.at] > Sent: Tuesday, January 05, 1999 5:12 PM > Subject: RE: Database security > > 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... Sorry :-) IL-NETVISION > => 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 :-( Alright, as I said, I wasnt here... sorry if its an old wound. > 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 :-) Agreed. > . 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... Hmm... well, this sort of functionality could be preserved by adding a new field, or doing the searches by netname instead of descr. I guess. > 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 ;-) True. But this may require more knowlegde and research, and therefore might be missed by some. In any case, it is possible to restrict each object by password (i.e. add password field or whatever), which will solve this problem. > 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... Yes, I guess thats true... Im just trying to point everyone's attention to this issue, TBH. I dont have any magical solutions short of descussing the whole DB structure. > => 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. Well, this is again true... but if we could find some ways to close the bigger loopholes, we may achieve most of what I feel we should be looking for. > 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(a)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 > -------------------------------------------------------------------------- >

1 0

Database security
by Barak Engel 04 Jan '99

04 Jan '99

Hello all, I am new to this mailing list, so please forgive me if I do not adhere to established processes. I promise to learn as we go on :-) The issue I would like to bring up is that of database security, namely, the fact that the database is completely accessible by anyone. Why do I propose that this is a problem? Let us, for the sake of this example, consider two fictive companies, NetISP and ISPNet. Both are ISP's, and they compete over market share in their country. As you are aware, a full customer list is considered very useful information in industrial espionage in this field, something that one company would most certainly not want to reveal to the other. Yet, with the RIPE DB open for prying eyes, both ISPs could easily gain this info. Alright, you say, so what? Both suffer from the same disadvantage, right? Well, not really. Following are just two scenarios I cooked up to explain why: 1) NetISP has been in the market for four years. ISPNet is new, and is interested primarily in market share. Since this is their focus, being new, they can allow themselves the luxury of selling at losing prices, in an effort to establish a market share. Looking at the RIPE DB, they can immediately find all the customers of NetISP, and try to "steal" them away. NetISP, however, has no such option. 2) NetISP got RIPE allocations, while ISPNet got other allocations. Why? It happens. In Israel, for example, the range 192.114.0.0-192.118.255.255 can be allocated without having to update the RIPE DB. Assume for a moment that NetISP have RIPE allocated IPs, while ISPNet have those "special" IPs. Only the latter will be able to check on the former. Again NetISP will lose. I suggest that some security feature be added to the database. Maybe hide some fields with a password, or make the retrieval utility more secure. There is a serious business problem here that I feel needs to be resolved. Many 10x, Sincerely, \'"'/ Barak Engel ( o o ) ---------------------ooOO-^-oOOo--------------------------- barak(a)netvision.net.il Network Expert BE-RIPE BE174 Phone/Fax: +972 48 560600/551132 Cellular: +972 50 469 341 -----------------------------------------------------------

3 4