Database development plans

[Andrei Robachevsky <]

Dear colleagues,


Please find below a list of the projects that we included in our
development plan. We would appreciate if you could indicate importance
and usefullness of specific projects so we can adjust their priorities.

Several more detailed proposals will follow. Here I just included brief
description of the projects not to enter premature implementation
discussion.

Regards,


Andrei Robachevsky
DB Group Manager
RIPE NCC


1. Authorisation checks across multiple databases

Migration to v3/RPSL made creating objects in the routing registry a much
more complex process due to the introduction of the Routing Policy System
Security (RFC 2725). The real problem was with so called "foreign" route
objects that either announce non-RIPE address space or are originated from
non-RIPE ASN. As there were no corresponding objects in the RIPE database
such transactions failed. A workaround is in place now that requires
duplication of objects in the RIPE RR and as a result - low security level.

The proposed solution is to get this information from sources that contain
authoritative information about network objects that are supposed to
authorise the transaction. For example, when creating a route from APNIC's
address space, but originated from a RIPE ASN, authorisation information
will be requested from both RIPE and APNIC sources.


2. Real-time (interactive) updates

Currently only e-mail updates are supported by the RIPE Database which
complicates automation of the update process at the clients side. The
facility that will allow connection oriented interactive, or real-time
updates, will simplify development of the client tools and make
synchronising of LIR's address management database an easier task.

Once implemented this project will present a facility for other tools, such
as web-based update interface, or a standalone syntax checker.


3. Automatic cleanup of unreferenced person objects

You may find the initial proposals:
http://www.ripe.net/ripe/mail-archives/db-wg/20010701-20020101/msg00079.html
http://www.ripe.net/ripe/mail-archives/db-wg/20010701-20020101/msg00092.html

The problem statement and the solution remains almost the same, with some
modifications:

- cleanup process is based on internal DB data, rather than object
  attributes or meta-attributes
- "holders" of the objects to be deleted are notified n days before using
  standard DB notification mechanisms.


4. Further development of the database software

- Improving error reporting 
- Improving server performance
- Software portability and configuration


5. Improve database security

These ideas were discussed at the RIPE-41, the detailed proposals will follow
- Deprecate MAIL-FROM as a weak auth scheme that doesn't serve todays's
  security requirements.  This will be done in several phases starting form
  not allowing updating mntner objects containing this scheme, and ending
  with not allowing updates to be authorised with MAIL-FROM.
- Implement authentication scheme using MD5 as a more secure mechanism
  compared to crypt. Passphrases can be used instead of 8 character
  passwords and MD5 fingerprint will be presented in the auth value.
- Implement inverse queries on auth, encryption, signature for PGP keys only 
  (key-cert's).