Re: Events of Tuesday, 27 October 1998.
Dimitrios Kaloger wrote:
Dear Madam,/Sir
Mistakes are not improbable, however I can not condone your inadequate backup procedures. Its totally out of imagination that you may have rouinned the RIPE database. You have to keep yourself more dedicated to your work.
This cannot stand as is. It is important to understand that the data in the RIPE database is maintained by the users of the database, and not by the RIPE NCC itself. As was already said by the RIPE database administrator:
We would like to stress that the RIPE NCC operates the RIPE Database, however the responsibility for managing user data lies with the users.
I suspect that the problem is that a backup cannot easily be used to restore the current "desired" state (minus the unfortunate update). The reason is that old NIC handles may have been recycled, i.e. reassigned to another object, and that object can subsequently have been referenced by an explicit use of that recycled NIC handle in an update. Sure, the subsequent updates could perhaps be doctored to remedy this, but that is perhaps not easily or quickly done, and would also mean "intervention in the data maintenance" by the RIPE NCC. I would thus tend to turn the argument above on its head and say that we collectively, the maintainers of the data in the RIPE database, have made inadequate use of the already available methods for protecting the data we maintain there from unauthorized updates or removals. Regards, - Håvard
Harvard , thank you for your support. It is indeed not straightforward to roll back specific changes in a database that receives thousands of upates each day which are not independent of each other. One thing we have leared from this is that it may be a good idea not to re-use handles before some time period has expired in order to facilitate tis process. However there are other interdependencies as well and it will be impossible to design a system to roll back any amount of changes consistently and repecting constraints such as authorisation. I further would like to point out to everyone that we do provide authorisation and authentication methods *for more than five years* already. Those who used them properly weree not affected by this mistake at all! If you want to be safe, all you have to do is to use authorisation on your objects. See ripe-120 on how to do that. mLaswly, and maybe unnecessarily, I'd like to stress that we indeed have backup procedures in place which are designed to cope with failures under our responsibility, such as machine or storage media problems. If you have any further questions, please do not hesitate to contact us. Kind regards Daniel Karrenberg RIPE NCC Manager
Havard.Eidnes@runit.sintef.no writes:
It is important to understand that the data in the RIPE database is maintained by the users of the database, and not by the RIPE NCC itself.
I suspect that the problem is that a backup cannot easily be used to restore the current "desired" state (minus the unfortunate update). The reason is that old NIC handles may have been recycled, i.e. reassigned to another object, and that object can subsequently have been referenced by an explicit use of that recycled NIC handle in an update. Sure, the subsequent updates could perhaps be doctored to remedy this, but that is perhaps not easily or quickly done, and would also mean "intervention in the data maintenance" by the RIPE NCC.
I would thus tend to turn the argument above on its head and say that we collectively, the maintainers of the data in the RIPE database, have made inadequate use of the already available methods for protecting the data we maintain there from unauthorized updates or removals.
On 31 Oct 98, at 1:07, Daniel Karrenberg wrote:
Harvard ,
thank you for your support. It is indeed not straightforward to roll back specific changes in a database that receives thousands of upates each day which are not independent of each other. One thing we have leared from this is that it may be a good idea not to re-use handles before some time period has expired in order to facilitate tis process.
why reuse it at all? siegfried
However there are other interdependencies as well and it will be impossible to design a system to roll back any amount of changes consistently and repecting constraints such as authorisation.
I further would like to point out to everyone that we do provide authorisation and authentication methods *for more than five years* already. Those who used them properly weree not affected by this mistake at all! If you want to be safe, all you have to do is to use authorisation on your objects. See ripe-120 on how to do that.
mLaswly, and maybe unnecessarily, I'd like to stress that we indeed have backup procedures in place which are designed to cope with failures under our responsibility, such as machine or storage media problems.
If you have any further questions, please do not hesitate to contact us.
Kind regards
Daniel Karrenberg RIPE NCC Manager
Havard.Eidnes@runit.sintef.no writes:
It is important to understand that the data in the RIPE database is maintained by the users of the database, and not by the RIPE NCC itself.
I suspect that the problem is that a backup cannot easily be used to restore the current "desired" state (minus the unfortunate update). The reason is that old NIC handles may have been recycled, i.e. reassigned to another object, and that object can subsequently have been referenced by an explicit use of that recycled NIC handle in an update. Sure, the subsequent updates could perhaps be doctored to remedy this, but that is perhaps not easily or quickly done, and would also mean "intervention in the data maintenance" by the RIPE NCC.
I would thus tend to turn the argument above on its head and say that we collectively, the maintainers of the data in the RIPE database, have made inadequate use of the already available methods for protecting the data we maintain there from unauthorized updates or removals.
"Siegfried Langenbach" <svl@nrw.net> writes:
why reuse it at all? siegfried
At the time of the design there was concern that the handles would get unconveniently long. Maybe the trade-off between the consistency problems this causes and a conveninent user interface should be re-evaluated. MfG Daniel
Hallo Daniel, thank you for the argument, as you may know, within CORE I am dealing with similar problems and decisions. siegfried On 1 Nov 98, at 21:14, Daniel Karrenberg wrote:
"Siegfried Langenbach" <svl@nrw.net> writes:
why reuse it at all? siegfried
At the time of the design there was concern that the handles would get unconveniently long. Maybe the trade-off between the consistency problems this causes and a conveninent user interface should be re-evaluated.
MfG
Daniel
Hi there!
"Siegfried Langenbach" <svl@nrw.net> writes:
why reuse it at all? siegfried
At the time of the design there was concern that the handles would get unconveniently long. Maybe the trade-off between the consistency problems this causes and a conveninent user interface should be re-evaluated.
Currently, there is another issue why reuse should be possible: To correct a misspelled person name, the only way is to delete the person object an to immediately recreate ist, reusing the handle. Perhaps a good idea would be, not to issue "used" handles in the AUTO-n process. (Which I thought would not happen, but obviously it does sometimes.) Greetings from Germany, Christian Halbe. Product Engineering UUNET Deutschland GmbH Tel. +49 231 972 00 Emil-Figge-Strasse 80 Fax. +49 231 972 1177 D-44227 Dortmund, Germany chh@de.uu.net URL: http://www.de.uu.net Mit freundlichen Gruessen UUNET Deutschland GmbH Christian Halbe Internet Koordinator NIC & DNS Team UUNET Deutschland GmbH Tel. +49 231 972 00 Emil-Figge-Strasse 80 Fax. +49 231 972 1177 44227 Dortmund, Germany Christian.Halbe@de.uu.net URL: http://www.de.uu.net
Hi, Daniel Karrenberg wrote:
I further would like to point out to everyone that we do provide authorisation and authentication methods *for more than five years* already. Those who used them properly weree not affected by this mistake at all! If you want to be safe, all you have to do is to use authorisation on your objects. See ripe-120 on how to do that.
But you should not use the auth: MAIL-FROM !!! We were happy with the MAIL-FROM for years now ... but our "friend" from rain.fr knows to fake message-id and from-line. | > From: Trevor McBryan <hostmaster@xlink.net> | > Cc: hostmaster@xlink.net | > Subject: longack | > Date: Wed, 28 Oct 1998 12:34:27 +0000 | > Msg-Id: <36370F53.30E4F99F@xlink.net> | | [...] | | Delete OK: [person] MW1699-RIPE (Martin Weber) If you have any further questions, please do not hesitate to contact us. Kind regards, Wilhelm Hostmaster @ Xlink - Network Information Centre -- [X] Xlink Internet Consulting GmbH | | Wilhelm Buehler, Xlink Network Information Centre | hostmaster@xlink.net | | Vincenz-Priessnitz-Strasse 3 [X] D-76131 Karlsruhe | Tel: +49 721/6635-410 [X] Fax: +49 721/6635-349 | | Geschaeftsfuehrer: Michael Rotert. Amtsgericht Koeln, HRB 3526. | Auftraege erledigen wir zu unseren Allgemeinen Geschaeftsbedingungen. ---------------------------------------------------------------------[ ]
To be perfectly clear: 'forging' mail headers to get around mail-from authentication is not accepted behaviour. To quote from ripe-120: "Each RIPE database object has an optional attribute called mnt-by (maintained by). The value of the mnt-by attribute is a reference to a mntner object in the database which describes those authorised to make changes to the object." So forging the mail header must be seen as a deliberate attempt to modify data one is not authorised to modify and defeating a protection scheme (however weak) to do so. This is a crime in most places nowadays. If it is true and we can identify the person who did this beyond doubt, they will owe all "victims" more than an apology. This is the first I hear of mail-from protected objects being modified too. I have been on travel for more than a week now and was not at the NCC when this happened. So my knowledge about the facts is sketchier than I'd like. If this is true I would assume malicious intent on the part of the the person concerned. I have asked the database staff to look into this a bit further. More tomorrow (European time) Daniel
Wilhelm Buehler <hostmaster@xlink.net> writes:
But you should not use the auth: MAIL-FROM !!!
We were happy with the MAIL-FROM for years now ... but our "friend" from rain.fr knows to fake message-id and from-line.
| > From: Trevor McBryan <hostmaster@xlink.net> | > Cc: hostmaster@xlink.net | > Subject: longack | > Date: Wed, 28 Oct 1998 12:34:27 +0000 | > Msg-Id: <36370F53.30E4F99F@xlink.net> | | [...] | | Delete OK: [person] MW1699-RIPE (Martin Weber)
participants (5)
-
Christian.Halbe＠de.uu.net -
Daniel Karrenberg -
Havard.Eidnes＠runit.sintef.no -
Siegfried Langenbach -
Wilhelm Buehler