RIPE 42

RIPE 42, Apr. 29 - May 3, 2002, Amsterdam

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. 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.