Brainstorm on guarded information

Folks,

As said yesterday, I have written up some ideas on how to implement
the idea of guarded information. I have worked out the current
procedure in more detail than others below, simply because we have
some experience with it. You will also see this could be the most
complicated in a new ripe-81++ type scheme. We feel most for option 3
in the text below.

Let's have some discussion.

-Marten

These are some ideas on how the principle of guarded attributes and
objects can be implemented. All of this is in light of the ripe-81++
proposal for the route and autonomous system number. It deals mainly
with the interface the guardian will have to the database, and how
guarded information will be included in the database. 

These are very rough ideas. The first thing I want to get a feel of is
what direction to go to. Details about implementation are not yet an
issue, altough of course we have to keep in mind that whatever
procedure we choose it can be implemented ;-)

Some general remarks:

- up till now, there has been a distinction between guarded attributes
and guarded objects. If at all possible we should look for one method
that can implemenent both.

- we will have to find a balance between what is reasonably easy to
implement, operate and usable for guardians.


1- The guarded file method

This is basically the method as we have things now. Guarded attributes
and objects are dealt with in different ways. Guarded attributes
through the once a day examination of the files, guarded objects by
means of the authorisation.

I can currently see a few disadvantages:

- guarded attributes are added only once a day
- guarded attributes that change will be removed from normal updates
- scaling issues with respect to guardian accounts
- guarded objects have to be dealt with differently

With the introduction of the route object, some more disadvantages can
be found:

- in the current inetnum object, the "aut-sys" attribute is optional.
That means that whenever an object is send in with an aut-sys
different than the current value it can be reset or ignored.
Specifically in the case of new entries, the aut-sys will be removed.
In the route object however, the "origin" attribute is mandatory. That
means that for a new route object the origin cannot be ignored because
that would invalidate the object.

There is of course a way around that. One way would be to leave the
once a day update mechanism and move to an on-the-fly guardian check.
That means whenever an object is send in, the referenced guardian file
is checked to see if it is allowed, and accepted if OK, bounced if
NOK. Then another problem arises, because this means you will have to
synchronize the updating of guardian files and the updating of route
objects. The file must be updated first before a route object can be
added. Some people I spoke with saw this as a problem. Solution for
this would be to put the update request on hold if NOK, through some
requeing mechanism, and bounce if after a day it still fails. Another
solution mentioned was to accept the objects, but keep them hidden,
and still do a nightly run to find all these objects and "unhide"
them. I am not too fond of either of these solutions, although the
requeueing is the best of the two.

The complexity for the old but updated guarded file solution could get
out of hand quite quickly I would think.

2- Modified guarded files

Another solution that keeps the guardian account principle could be to
change the format of the guardian file. Why should the guardian file
only contain pointers to objects and not the objects themselves. So,
in stead of guardians sending in objects and then check the files,
they simply keep a file with all their objects on the database
machine. On the database machine a daemon would scan around all
guardian files every X minutes to find files that have been changed
and update the information in that file. There can of course some
refinements in the way the file is handled but that does not change
the general principle. Advantages in my view are abvious:

- definately guarded
- no one a night procedure
- no difficult checking for the database software
- can be refined in many ways
- the difference between guarded objects and attributes dissapears

Disadvantages:

- updates will not be immediate but can take X minutes

There may be some other disadvantages, but many of them I can can be
resolved by adding refinements to the file(s) the guardian keeps and
the way the file is handled for updates.

3- Authentication in updates

The perhaps most obvious solution is to do authentication on the
updates people send in. In our case there would be some authentication
in the mails people send there updates in, or even as far as per
object. This could be implemented as simple as a magic string per mail
where the string identified the guardian, or more complicated things like
PEM or what have you. My vote would be to keep this as light but
secure as possible. Obvious advantages:

- no need for guardian accounts and files
- no special procedures for guardians, they simply send in updates as
they always would, just include some magic
- less complexity and administration for database maintainer
- the difference between guarded attributes and objects dissapears





-------- Logged at  Tue May 24 12:26:27 MET DST 1994  ---------