Brainstorm on guarded information

Marten,

  This was good--#3 is delightful.  Any more thoughts or progress on this
in the last month?

--Dale

=========================================================================
> From marten at ripe.net Thu May 19 07:48:29 1994
> Received: from ncc.ripe.net (ncc.ripe.net [192.87.45.2]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id HAA02723; Thu, 19 May 1994 07:48:27 -0400
> Received: from rijp.ripe.net by ncc.ripe.net with SMTP
> 	id AA07470 (5.65a/NCC-2.2); Thu, 19 May 1994 13:48:23 +0200
> Received: from localhost.ripe.net by rijp.ripe.net with SMTP
> 	id AA02896 (5.65a/NCC-2.2); Thu, 19 May 1994 13:48:23 +0200
> Message-Id: <9405191148.AA02896 at rijp.ripe.net>
> To: rr-impl at ripe.net
> Subject: Brainstorm on guarded information
> From: Marten Terpstra <Marten.Terpstra at ripe.net>
> X-Organization: RIPE Network Coordination Centre
> X-Phone: +31 20 592 5064
> X-Fax: +31 20 592 5090
> Date: Thu, 19 May 1994 13:48:22 +0200
> Sender: Marten.Terpstra at ripe.net
> Status: RO
> 
> 
> 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 3 14:39:18 MET DST 1994  ---------