Jack,
sorry about that late reply. First I have been away and then swamped.
The answer has been a little longer than expected. Thus I CC it to the
relevant RIPE working groups too fort their information.
Daniel
> Haven't mailed for awhile. I hope everything is going well over the
> pond. I was wondering if you could fill me in on a little RIPE
> philosophy.
Tall order. :-)
If we keep it down to specifics ...
> Right now, its my understanding that authorized users can
> automatically update the ripe database. If that is correct, how do you
> make sure that what the authorized user is telling you is the correct
> information.
The original RIPE DB authorisation scheme:
"No authorisation but *very* good audit trails."
Anyone can change anything in the database but it will be logged. True,
if you are mailicious and really determined you can do things and we
will not be able to trace you far. But we will know what was done when
and from where and we will be able to take appropriate action. We have
decided to cross that particular bridge when we get to it.
Together with a very quick response to queries about update problems
this has worked rather well. After three years of experience with now
38,000 objects in the database and just under 1000 updates on an average
working day I can not recall more than about a dozen incidents of
unintentional changes being made by third parties. All of those have
been resolved rather quickly and none has been intentional or malicious.
Since we are now starting to do routing registry functions which are
critical to operations we are starting to introduce some authorisation
for the routing policy elements in the database.
Some objects will not be changeable at all but by an authorised
guardian. Currently these are some deprecated objects nad the
autonomous system and community objects.
Additionally some attributes will be guarded. The most important is the
"aut-sys" attribute of the network object which defines membership of a
network in an AS. These attribute will not be updated or updatable via
the normal method but via a totally separate authorised method by the
guardians of the respective autonomous system. The authorisation method
for this will be Unix login security in most cases.
You can read more about all this in ripe-81 ripe-96 ripe-89 ripe-72
and others.
> An example:
>
> Say I'm a mean guy and I want to register a net that I do not own, and
> is currently not in the RIPE database, to myself before my competitor
> has registered it. How do you make sure that I'm allowed to register
> this new net in the database?
We do not. But we keep track of registry assignments separately from
the database. If someone claims a network and has no assignment from
the appropriate registry (either the NCC or a local registry) then he
looses.
> The only way I can check this today is
> to see if the internic has given the net out and if it is registered
> to the apporpriate person sending in the database addition.
Same thing here.
> Now if I'm
> a provider, I do not "own" this address so things get a little
> confusing.
Not at all. The registry has the obligation to keep a record of what
they assigned separately from the database and to register networks in
the RIPE database no less than 24h after assignment. So there will be a
trace. Also a flag will be raised if such an assignment is made for a
net already in the database.
At the NCC we keep simple SCCS files (yes I am *that* old) for the
register. Together with the database audit trail this is more than
adequate to document who did what when. We also keep an archive of all
registry mail messages and faxes (full-text indexed with WAIS). We also
have a filing cabinet used for those old fashioned hardcopy requests.
It is not too full yet so we can keep office supplies and other stuff in
it as well. :-)
If there is a conflict both the datbase audit trails and the register of
the registry concerned will be examined. If there are conflicts the
latter is most likely to be ruled authoritative.
To date such a case still has to happen - apart from administrative
snafus which *do* happen once in a while.
Daniel
