RIPE 37

Thursday, Sept 14, 2000 at 09:00-12:30

Part I: WG-Meeting

PI-A. Administrative stuff (WW, chair)

• Volunteering a scribe
  Nigel Titley volunteered to take the minutes
• List of participants
• Agenda bashing
  The agenda was accepted (4th draft).
• Minutes distributed
  Minutes as distributed were accepted.

PI-B. Actions Items

• Fwd domain object migration
  Details under the "Input from other WGs heading". Progress is being made, and the performance of the database has improved.
• Follow up on IRT pointer facility
  This was addressed in the meeting

PI.C. RIPE DB, operations update (RIPE NCC) 20min

Presented by Ambrose MaGee of the RIPE-NCC.

Statistics

There has been continuous growth in the number of objects, as usual, excepting the outward migration of domain objects (approx 200,000) leaving 300,000 objects. This has resulted in person objects becoming the majority of the database (71%). 60% of person objects are now unreferenced. The majority of these are unprotected. PGP has increased (311 key-cert objects, an increase from 247). The number of protected objects has dropped and now is only 1.4% of the database.

Operations

Average query rate is about 7 per sec. However this is now fairly stable, probably because of the loss of the domain objects. The underlying query rate however, is still increasing. The query rate for domains is still high (but many are refered), IP obejcts have increased. The update rate is down by 66% since July. The vast majority of updates are now for person objects (77%), followed by domain and then inetnum.

There has been no downtime of the database since the last meeting. There is now dynamic failover to the backup server. A debt of gratitude is owed to the DB maintainance team who do such a wonderful job.

1700 messages are received by ripe-dbm@ripe.net of which the majority are mail-bounces. The number of requests for PGP licenses is woefully low.

The database is monitored to make sure that proper use is being made of it, and to ensure that its performace is good.

50% of mntner object requests are denied, mainly because of slow response from some ccTLD registires. 124 PGP licenses have been distributed to date (much too low).

Database Consistency Project

Runs on a dedicated machine. Summary stats are on the Web

Secondary Sites

TEST: a playpen machine for testing and training

BETA new software (RPSL):

Routing Reality Check

ARIN legacy Objects

ARIN expects to transfer some legacy objects to RIPE shortly.

Database re-implementation

Most functionality now present. An average of about 20 downloads for each beta release.

Live data at reimp.ripe.net (port 43). Update to auto-rip@ripe.net

Information is available on the DB services web page and snapshots of the code are available.

PI.D. IRRd: experiences, registration software weaknesses
(G.Winters, MERIT) 20min

A presentation was given by Gerald Winters from Global Crossing.

Motivation

The talk is just to let other people know what we are doing and to open the possibility of collaboration.

GBLX DB Wish list items

Allocation

Would like to be able to generate export access lists on a per region basis in order to minimise access list size.

Eliminating the paper trail

SWIP templates for ARIN need to be updated. This should be able to be derived from the DB.

IGP support

This would turn the DB from a global registry to an everyday tool (really applies more to RADB rather than RIPE). Makes the DB more useful.

Hide sensitive data

Need to add security filters on top of the registry so need to seperate public from private data.

Access control granularity

By object, IRR etc

Relational DB Backend

Integrating IRRD with TimesTen backend giving relational queries giving better support for allocation registry functions.

RPS-DIST (RFC2769)

Built a prototype over the summer. The overal reaction seems to be good. It scales better and has better security, a good RFC. It has more functionality but is more complex. The RFC still has some holes which need filling in.

There are some performance problems. The unit of exchange is too small and this results in overhead as all registries are consulted. Syntax checking could be an issue unless a uniform syntax is specified for main fields and object canonicalisation is repeated at each site, which can be expensive. DBs must be transaction version controlled for auth checking.

General observations are that the protocol is not fully dynamic. Rpsdist daemon will not dynamically accept new connections. If you want to join the global DB mesh you must first register information at a trusted source such as IANA or RIPE. Also if a transaction fails no one will update your DB until the transaction is overridden with a successful transaction. This can result in queuing and loss of transactions. However, it was pointed out that this was actually one of the design goals.

Also detached PGP signatures are not supported (not a show stopper). Nothing is specified for the case where a poll request cannot be satisfied. There is missing information from the "repository" object (needs a snapshot URL). Finally although there is a section on "mirror-only" nodes, there is no prescribed method for it to join the mesh.

Despite these minor issues, the RFC is good in the main, and it was pointed out that it could be updated if necessary. Gerald felt that some updates will be necessary, with which the authers of the RFC agree. It was felt that RIPE should be at least tracking this work, and it should be added to the agenda for the January meeting.

PI.E. Activity Plan proposal(s) for next year

Summary

Call for activity plan proposals has turned up two requests: enhanced security mechanisms, and how to represent IPv6 and multicast information in the DB. They have been added to the activity plan.

PI.F. Recommendation on the use of auth. methods in the DB (WW) 10min

Mechanisms documented on NCC web pages

NONE, MAIL-FROM, CRYPT-PASS, PGP. All documented on the RIPE-NCC web page. No recommendation on which method to use.

Recommendation from the community

Proposal to write a recommendation from the community on which methods to use.

There was a feeling that the older methods should be retained for some objects, where it was felt to be approriate in some cases. It was also felt that the weak methods could be used as the start of a chain of trust. Authors for the proposed draft will be solicited.

Operational impact

A general plea was made to change operational procedures to use PGP where useful.

PI.G. Globally unique handles for person:/role: ? (R. Bush)

Is there a need for globally unique handles?

At the moment different registries have different handles. This can lead to enormous confusion (cf RB366, RB366-ARIN, RB366-RIPE). The identifier is just a local identifier within a registry. There are a number of reasons for this. The main reason is that database formats have not been made consistent.

What could they look like?

Examples could be

< local-id >.< registry >

Well known net-unique ids (email, pgp etc)

Socially unique (Nat Insurance no)

The latter two don't refer to registries, so we are stuck with something like the first form. So we need to clean up.

How to obtain and use such a handle, and for what?

Registries need to agree on a common format.

There was a suggestion that any scheme should be hierachical (possibly just two levels). PGP key-id was suggested for the .

Part of the problem is lack of incentive to move.

The basic technical problem is lack of consistency in wire format, so the DBs are unhappy or unable to transfer data between each other.

The group was asked whether it was worth working on common formats for identifiers, and/or wire formats. Some work seems to be being done on similar problems (character sets and referrals) although this now seems hung. It was suggested that the RIPE community should come up with some suggestions for the San Diego IETF meeting.

Maillist list details will be sent to the DB-WG mailing list.

PI.H. IRT-Pointer for DB Objects (WW) 10min

What is this all about?

Homogenous set of information pointing to CERT team for an object. A means to explicitly advertise the response team contact for an object to allow, for example, abuse complaints to be properly targetted.

Consensus to go ahead?

It was suggested that a more concrete example would help people to decide. There are a couple of examples available which will be sent to the list

Which Objects?

Which objects to apply it to needs deciding.

PI.Y. Input from other WGs

CENTR TECH

Query referrals mechanisms have been devised to allow the delegation of domains (for example). Sometimes these are not being properly used. The top level domain objects need to be properly protected and maintained. The RIPE-NCC is understandably unhappy to modify data in the DB, based on precedent. This is a general problem, should person objects be removed if un-referenced. Should junk entries be removed?

Opinion was divided on whether it was the registry's responsibility to clean up the junk, but with the balance of opinion being that we should ask the registries to clean up, for example, unreferenced person objects after a certain amount of time. But procedures should be set up so that this is done in a controlled fashion.

PI.Z. AOB:

Do we want a PGP tutorial next January? No real interest but it was unclear whether this was due to apathy, ignorance or a general air of superiority.

Part II: Re-Implementation/Migration TF

PII.A: New Database implementation

Presentation by Andrei Robachevsky (copy available)

PII.B: Re-implementation Task force

Volunteer was sought to coordinate this (Ulf Kieber). Other volunteers are extremely welcome to help, especially people who are running mirrors at present, or who are deriving router configurations from the DB.

The Task force would need to look at the following items:

• Test Reports/Feedback
• Deployment Plan
• Next steps
• Logistics