RIPE Working Groups

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.

A full action list is available at http://www.ripe.net/wg/db/db-actions.html

C. DB update (RIPE NCC, Andrei R.) 
           
           Usual DB update. Presentations are available at: 
           http://www.ripe.net/ripe/meetings/archive/ripe-42/presentations/index.html#db
           . 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.

Presentations are available on the at: 
           http://www.ripe.net/ripe/meetings/archive/ripe-42/presentations/index.html#db