Folks, As I have had no comments following the posting of the minutes in draft form to this list and to the Ripe web site, I am publishing the minutes in final form (see below) Best regards Nigel Minutes for the Database Working Group Meeting RIPE-42, Apr. 29 - May 3, 2002, Amsterdam, NL Thursday, May 2nd, 2002 09:00-12:30 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A. Administrative stuff (WW, chair) . scribe (offer from Nigel received) . circulate list of participants . agenda bashing . status of minutes Minutes have been circulated to the list in both draft and final form and are posted to the web site. B. Action Items . status of actions [AP-41.1 WW] To send list of proposed updates to IRRToolSet to mailing list for WG members to vote on. Deadline 3 weeks. Ongoing, no action yet [AP-41.2 C&W] To send their proposal to allow referencing external objects in the DB to the mailing list for discussion. Ongoing, no action yet [AP-41.3 RIPE-NCC] Create Documentation and BCP for IRT object. Ongoing, some work done. [AP-41.4 ALL] Create IRT object and tag inetnum for all appropriate objects. Ongoing, some objects created [AP-41.5 WW] To put together a group to put together a short guidance document to guide reference document writers. This team to include Ruediger. Ongoing, no action yet, nothing from Ruediger. [AP-41.6 RIPE-NCC] Put up a mailing list for the above purpose and advertise to the db-wg list. Ongoing, no action yet [AP-41.7 RIPE-NCC] To investigate soluton for mirroring "stickiness". Complete, a solution is now available. [AP-41.8 C&W] To formulate their proposals on the list for discussion. Complete. No response from C&W. [AP-41.9 RIPE-NCC] To document the mirroring protocol and the operational requirements of using it. Ongoing. Some work done. [AP-41.10 RIPE-NCC] Provide nag message to maintainer owners Ongoing. See presentation below. [AP-41.11 RIPE-NCC] Look at implementing MD5 password authentication Complete. [AP-41.12 RIPE-NCC] Look at general password authentication methods Ongoing. No action yet. C. DB update (RIPE NCC, Andrei R.) Usual DB update. Presentation available on the www.ripe.net web site. . Operational update 70% of queries are for IP addresses, 10% are domain references. The rest are various, including person. System is scaling well and average response time is less than 1s, despite a doubling of load over the past year. 50% of messages to ripe-dbm are spam. It is suggested that a simple spam filter (To: or Cc: ripe-dbm) may reduce this. Ticketing system to be introduced in the next few weeks. . Database developments MD5-PW scheme introduced, based on md5-crypt. Available on test database, soon to move into production. MAIL-FROM now to be deprecated. Notification to go out soon. 4 weeks later updates will be rejected (except for maintainer object updates). 4 weeks later submission will be rejected. Finally 4 weeks later the MAIL-FROM attribute will be removed from all maintainer objects. There is a suggestion that the same thing should be done with NONE. The meeting formally approved the MAIL-FROM timeline. The process to start before the end of May. IRT object has been available since Jan 2002. Two IRT objects have been created. Creation procedure still needs some development. DB Consistency and Statistics project 113 reports displaying 34000 inconsistences were produced. Please act on these and fix data. [AP-42.1 ALL] To check own data and correct inconsistencies if possible. SYNCUPDATES prototype Available in test as a syntax checker only so far. RRCC full prototype is ready IRRToolset is being managed. Update requests are very welcome. APNIC will be using the RIPE database code. The procedural changes needed will be rolled into the main database code. DB Documentation Structure and parts of several chapters are ready. Should be consistent with LIR training. D. Complex authentication scenarios (Alex G. SWITCH) . Background There are some scenarios which require multiple signatures. This has revealed a small bug in the database which has been worked around. It is better to sign a clear text update rather than using mime encapsulation. In the event of multiple signatures being required the clear text should be signed by the first maintainer, then the entire email signed again by the second maintainer. [AP-42.2 RIPE-NCC] To send instructions on multiple credentials to the DB working group mailing list. E. Discussion on "hiding" credentials (RIPE NCC, N.N.) . "shadow password" concept The idea is to not include the encrypted credential in the whois response. This prevents "brute force" attacks. However, this breaks with DB tradition of returning all attributes of all objects when requested and means that the DB can be the primary repository of the data. A proposal for a two level authentication scheme was received with full access for the DBA, but no password access from the general public. It was pointed out that this was a wider issue than just the RIPE community, but was also being discussed in the RPSLng working groups. It was also pointed out that packages are available which can attack digested passwords. The very valid point was raised that those who have problems with weak authentication methods, should use strong ones (eg PGP). Objects to this were that Windows users had problems with PGP and its "complex" interface. [AP-42.3 RIPE-NCC] To investigate the issues involved in shadow passwords and multiple level authentication schemes. [AP-42.3 Larry Blunk] To investigate the problems of multiple hashed passwords and the possibilies of embedding an ID within the hash and to submit a proposal to the working group. A proposal came from Janos to embed such information in the remarks field. F. IRT Object creation process The technical implementation is in place. Procedures need some work. Two IRT objects are registered so far. Objects need some authentication, to give them some cedibility. A "trusted introducer" currently provides authentication and labelling when an object is created. This may need updating. There is a meeting on the 23 - 24th May in Copenhagen on Computer Security IRT coordination. Attend if appropriate. G. Org object? This has been discussed in the past. Were people still interested in creating this object? APNIC and ARIN also carry these objects. This might be used in the registration of inet-nums. The role object partially answers this need, but cannot be used for an admin-contact. An org object could also be used to make a LIR object more visible and allow remote updating. The question also arises as to whether the owners of PI space could create org objects. H. Migration of objects between registries This is affecting legacy address space which pre-dates RIRs. This is currently in the ARIN database. It is proposed to migrate this data to the appropriate geographic RIR database. A great deal of inter-RIR liasison has already taken place. A number of approaches are possible, ranging from moving the data completely, using the referral mechanism, carrying all data in all databases etc. The thing that mustn't happen is to delete more up to to date data in the non-authoritative database in favour of old data in the authoritative database. It has been suggested that the "delegated" attribute be used to implement. This would only be used for inet-num and as-set objects. The issue was raised that one of the top level domain servers is in the 192.0.0.0/8 block, and deletion of the route objects for this would be disastrous. The response to this is that there was no intention to move route objects, just inet-num objects. I. Input from other WGs No other input J. AOB: No other business.