RIPE 43

RIPE-43, Sept. 9 - 13, 2002, Rhodes, GR

Thursday, Sept. 12, 2002 09:00-12:30


A. Administrative stuff (WW, chair)
. scribe (offer to take notes received from Nigel)
. circulate list of participants, agenda bashing
. status of minutes
. All presentation slides are available on the RIPE NCC 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.
Expired and superceded by AP-43.6 and AP-43.9

[AP-41.2 C&W] To send their proposal to allow referencing external
objects in the DB to the mailing list for discussion.
Superceded by AP-43.7 and AP-43.8

[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.
Complete. IRT objects are being created (4 so far) and no
problems being reported with process.

[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.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 using MAIL-FROM
Complete.

[AP-41.12 RIPE-NCC] Look at general password authentication methods
Ongoing. No action yet.

[AP-42.1 ALL] To check own data and correct inconsistencies if
possible.
Closed

[AP-42.2 RIPE-NCC] To send instructions on multiple credentials
to the DB working group mailing list.
Complete. Instructions are now on the RIPE web site.

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

C. DB update (RIPE NCC, Andrei R.)
. operations report
Statistics
Slightly more objects (1.6M)
80,000 users on average
18q/s average, peaking to 65q/s
2 updates per second average

Still some growth in unreferenced personal objects. Need
garbage collection process.

70% of queries are for contact information

Updates pretty average apart from spike in mntner object
caused by removal of mail-from authentication

Back-end problems solved. Performance issues with long
queries is still to be resolved. Otherwise scaling well

User support
6 support staff shared with other software projects

Introduced anti-spam filter for mail to ripe-dbm (mail
routed to folder) since 20th May 2002

Added ripe-dbm ticket system (shared with hostmaster)

MAIL-FROM phasing out process. 1500 maintainers missed
the deadline. High fax load on DB staff. Robot now in
place.

Developments

New MD5-PW authentication scheme. 41% of maintainers
are using it.

New status values for intetnum6 are not now generated.

DB consistency and statistics project is now generated
useful data

RRCC full prototype is now up and running

IRRToolset. New version 4.7.3 released. Mostly bug-fixes.



The database user manual "Getting Started" has been published.
(Dummies guide to the RIPE Database).


Real Database user's manual is being progresses

IRT Document has been published (functionality and procedures)

Plans

Further improving of server software (Error reporting,
performance, and configuration management).

Support auth checks across multiple registries

IPv6 and multicast support

Automatic database cleanup (if object is not
referenced then delete after a certain time (following
nag messages to user)). There are other possibilities

[AP43.1 RIPE NCC] Look at other possibilities for
database cleanup.

Additional user support (Documentation, Sync and Web
interface)

Main Events

Improvements in security (MD5 and MAIL-FROM)

Documentation and User support

Web and syncupdate interfaces.


D Web interface and Syncupdates for DB (RIPE NCC, Can Bican)

Currently updates are via email
Hard to automate
Difficult for beginner

Syncupdates allows online updates to database, web interface
built on top of this
TCP based
Extensible, maintainable, same functionality, easy to use.

Minimal client (HTTP) can be used

Notifications are sent by email as usual

WebUpdates is a prototype of an update client which allows
adding, deleting and updating of an object. Only password
authentication. Passwords are stored via cookies.

No PGP authentication
Multi-line attributes not properly handled
Only one object may be updated in a submission

All suggestions and feature requests are welcomed.

http://webupdates-test.ripe.net
http://syncupdates-test.ripe.net

Probably one month before coming into production (syncupdates)
Webupdates can be earlier, but please send comments to the db tools
email address.

E. Database Consistency Project Statistics (RIPE NCC, Shane)

This refers to data that can be seen as incorrect merely by
looking at the database itself (eg not routing inconsistencies)

Changes in rules
Abandoned data
User error

Examples
Non handle admin-c
Syntactic errors
Missing or incorrect status attributes
Unreferenced person objects
Unreferenced maintainer objects
CSIRT for no networks
Unreferenced PGP key

Also non-authoritative Data
Prehistoric inetnum (non-RIPE)
Objects in unprotected space
Possibly unauthorized route objects

Abandoned objects
Unresponsive maintainers (both LIR and non-LIR)
Outdated contacts

Solutions

Reports
RRCC reports
Database consistency reports

Really only helpful for actively maintained objects

Restrict Input
Many of these checks already but will soon include
integrity checks and RPSS checks

Does not address current problems

Revocation
Allow higher level maintainer to delete objects
lower in the hierarchy. (Currently can only be done
by ripe-dbm).

Unresponsive maintainers? Use another maintainer, or
delete maintainer?

Cleanups
RIPE NCC implementation of WG decision
Has been done in the past successfully.


Discussion

Normally starts on the mailing list, generating proposals
which are then voted on at the RIPE meeting.

Opinions
Why spend a lot of resources to clean it up? It will
never be completely clean? Only 5% garbage.

Difference between structural problems and operational
problems.

Garbage can prevent the generation of accurate reverse
delegation zone files, and address allocation reports.
Even 5% garbage can render these useless.

Registration of contact information can be really
useful, even if not related to operational data. Should
we be removing this data if it is useful? However,
privacy issues now pertain to this data.

We should also be wary of using the DB as a general
key-server.


F. "Early Registration Transfer" (ERX) Project (Andrei, RIPE NCC)
. Introduction
ASN and IP registration inherited by ARIN from Internic
Pre-RIR
Non-geographical

. Goals and Phases
Transfer of DB records and conflict resolution
Transfer of associated documentation

Phase 1 ASN registrations

Phase 2 IPv4 registration

. AS number migration
ARIN only (419 ASNs) just created and protected in the RIPE DB
Completed 21st August

ARIN & RIPE (conflicting data, no RP) (87 ASNs) merge and lock. Resolve
conflict and then unlock
Completed 21st August

ARIN & RIPE (with RP specifications) (177 ASNs) manual 2 week conflict
resolution prior to transfer
Completed 21st August

30% of notification emails bounced.

Lessons
Don't use August.....
Often no evidence. Makes resolution very difficult in
cases of dispute.
Do not lock objects. They may be in use.
Some people only wake up at the deadline

. IP V4 migration
47 /8s to be transferred

Conflicts are likely to be more complex.

Transfer of DNS reverse delegations.

Group 1 (ARIN only)
Create and protect in the RIPE DB

Group 2 (Exact match between ARIN and RIPE, except for contact and
description)
Resolve conflicts and then merge (do not lock)

Group 3 (RIPE does not match ARIN)
If NCC allocation then keep in RIPE
Otherwise delete (after response time)

. Discussion

Thanks for the RIPE NCC from ARIN for their cooperation

Human matching of records cannot necessarily be done by machine.
Records that obviously match on visual inspection may not be easily
matchable automatically.

Two weeks (especially in August) is not enough time to resolve conflicts

[AP43.3 RIPE NCC] Provide detailed action plan to the WG before
implementing Phase 2.

Trying to obtain authorization from contacts in the ARIN database is
likely to be difficult, as in many cases the authoritative data is
the RIPE database. Hence it may be necessary to extend the time for
resolution of conflicts.

What happens to IPv4 objects that are in an undefined state after the
process? They will remain locked until the holder emerges. At which
point the appropriate procedures will be invoked.

Is there any chance of getting information about what IP objects
will be transferred, prior to the actual transfer process?
[AP43.4 RIPE NCC] To produce a list of requirements for such a list.

Is there a possibility of automatically aggregating eg /24s in the ARIN
database to the appropriate aggregated object in the RIPE DB? Probably
not, as there don't seem to be many such objects. This will probably be
a manual process.

A suggestion that more resource be allocated to the IPv4 migration
than was allocated to the ASN migration.

[AP43.5 WW] Set up a task force to go through some test cases before
hand. It should report on the mailing lists (DB and LIR) within 4 weeks.
(Wilfried Woeber, Nigel Titley, Joao Luis Damas at least)

Are there any requirements from the outside for target dates? No fixed
date, but should get it done as quickly as possible.

G. IRRToolSet Development Brainstorming (+ external refs?)
. how to find out who is using what?
A few people are... one at least is using a home-brew set of tools

It was noted that those who are using the toolset are using it together
with other tools. This may have to be taken into account.

Some things are missing
eg Support for zebra

[AP-43.6 ALL] Those who have requirements to send to IRRToolSet@localhost

What tools do people find useful?

[AP-43.9 RIPE NCC] To try and track down some of the outdated references
to the IRRToolset out on the web and get them corrected.

. External reference

Who needs it? Need at a minimum things like AS-sets
which are referred to in the RFC. Need a list of things for which it
makes sense and those for which it would be insane (Ruediger Volk)

The status of external reference in the RPSS RFC is "out of document
scope", although a possible mechanism is described.
There is a clear need for this, and the C&W registry is using this
syntax. It is also needed in order forms etc (and is already included
in some forms from some providers). The RPSS working group needs
waking up to properly resolve this issue. Should the DB be prepared
to accept this syntax? No real performance issues (Andrei) and not
a real problem. The RPSL-dist informal proposal suggests a new
"registry" object.

[AP-43.7 Ruediger Volk] To produce a short report on what would be
useful and how to start.
[AP-43.8 RIPE NCC] To investigate how much effort would be required to
add this functionality to the RIPE DB.


Y. Input from other WGs
. None


Z. AOB:
. Organi[sz]ation object proposal
Examples would be a local registry which could be well described in
such an object.

. IRT object
There are only 4 such objects. However no one has had problems creating