Draft Minutes of DB-wg minutes for RIPE 42

Gentlefolk,

Here is the first cut of the minutes for the DB working group.
Corrections to me please, within 2 weeks, after which the final version
will be posted to the group.

RIPE webmaster, please post these to the web site as the first draft
version

Best regards

Nigel



-------------- next part --------------
                          Minutes for the
                       Database Working Group Meeting

               RIPE-42, Apr. 29 - May 3, 2002, Amsterdam, NL
				 1. Draft



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.

Y.  Input from other WGs
        No other input

Z.  AOB:
	No other business.