October 1998 - lir-wg - mailman.ripe.net

Re: Massive changed in the Ripe Database..
by Petra Zeidler 05 Nov '98

05 Nov '98

Thus wrote Mike Norris (mike.norris(a)heanet.ie): > > well we should collect money for Mr. McBryan to spend him a > > two-week-last-minute-trip to ... lets say mallorca without > > internet access, then the community has time to fix all the > > mistakes he made :-))) > > Maybe he's signed up for one of the RIPE Local IR > training courses; wouldn't that be a lot better? shoot him to the moon? :-3 Would suit my feelings better .. anyone can err, but then messing with my repair work by faking our headers is way off bounds. This whole little escapade cost Xlink about 3 man-days work, and we're not finished mopping up yet. kind regards, Petra Zeidler -- [X] Xlink Internet Service GmbH | | i.A. Petra Zeidler, Neukundenanschluss | zeidler(a)xlink.net | | Vincenz-Prie_nitz-Stra_e 3 [X] D-76131 Karlsruhe | Tel: 0721/9652-220 [X] Fax: 0721/9652-209 | | Geschdftsf|hrer: Michael Rotert. Amtsgericht Karlsruhe HRB 8161. | Auftrdge erledigen wir zu unseren Allgemeinen Geschdftsbedingungen. ---------------------------------------------------------------------[ ]

6 5

Re: Events of Tuesday, 27 October 1998.
by Daniel Karrenberg 03 Nov '98

03 Nov '98

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(a)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.

4 6

Events of Tuesday, 27 October 1998
by RIPE Database Administration 03 Nov '98

03 Nov '98

Dear Colleagues, On Tuesday, 27 October 1998, a user of the RIPE Network Management Database accidentally deleted many [person] objects. The objects affected were either not maintained by a 'mntner' object or were maintained by a 'mntner' object with an authentication mechanism of NONE. The RIPE NCC has investigated this and learned that it was a genuine mistake by this user. When a person object is deleted, its nic-handle is available for re-use immediately. Therefore, you may find that a nic-handle now points to a different person or role object. We recommend that you check the consistency of your data i.e. see if the nic-handles in the admin-c, tech-c, and zone-c lines of your objects refer to the correct person or role objects. We understand that an attempt was made to re-create the deleted objects by the individual who originally deleted them. Please search for your person objects using both the name and the nic-handle. It is possible that your object has been re-created, but with a different nic-handle. If so, you must update your inetnum, route, mntner, etc. objects that refer to the previous nic-handles in the admin-c, tech-c, and zone-c lines. You should replace the old nic-handles with the new ones. To check whether a certain nic-handle is referenced anywhere, you can use the inverse look-up flag. For example, you can do: "whois -i admin-c,tech-c,zone-c <nic-handle>" to see if that nic-handle is referenced anywhere as admin-c, tech-c, or zone-c (e.g. as in domain objects). If one or more of your person and/or role objects have not been re-created, we suggest that you first try to re-create them using the original nic-handle. This way, you do not have to change any of the references that use this nic-handle. If the nic-handle has been re-used, you should try to create the person or role object with the AUTO-1 keyword. In this case, however, you will have to change the inetnum, domain, or other objects that reference this nic-handle to point to the new one. (Use the the "-i" flag mentioned above to find which objects reference the old nic-handle). The RIPE NCC shall, as a part of its service to the RIPE community, support users to restore their data to a consistent state. We estimate that this should take about one working day. Please note that it is the users responsibility to restore their own data. We would like to stress that the RIPE NCC operates the RIPE Database, however the responsibility for managing user data lies with the users. Mechanisms to protect data against unauthorised or unintentional modification exist for several years now. The RIPE NCC has always emphasized the importance of authentication mechanisms and has been recently working to introduce even stronger procedures. We encourage users to deploy these authentication mechanisms. Please read ripe-157, section 2.3 on how this works. If you have any problems with the RIPE Database, please send an email to <ripe-dbm(a)ripe.net>. Regards, The RIPE NCC Database Group.

2 2

RE: Database performance - an update.
by Mike Norris 30 Oct '98

30 Oct '98

> I shall begin by saying that I wrote the two messages to > the local-ir, lir-wg and db-wg yesterday. I wrote them > for, and on behalf of, the RIPE NCC Database Group. I > realise that many of you are unhappy that these messages > had no personal signature. The responsibility for this > oversight is mine. In all previous postings to these lists, > I have signed my name. I shall continue to do this. Ambrose, you may not have put your name at the end of the mail, but we knew it was you anyway - your style is inimitable and your sense of humour unique. Keep up the good work and watch out for ghosts this weekend. Cheers. Mike Norris

1 0

Database performance - an update.
by RIPE Database Administration 30 Oct '98

30 Oct '98

Dear Colleagues, I shall begin by saying that I wrote the two messages to the local-ir, lir-wg and db-wg yesterday. I wrote them for, and on behalf of, the RIPE NCC Database Group. I realise that many of you are unhappy that these messages had no personal signature. The responsibility for this oversight is mine. In all previous postings to these lists, I have signed my name. I shall continue to do this. You already know what happened on Tuesday, 27 October, last. Yesterday morning, we had no option but to do preventative maintenance of the database; this was not related to the activity of any user last Tuesday. However, nearly all updates were stopped until around 1630 MET. Unfortunately, there was a higher than usual number of updates sent to the database yesterday. These two facts had one result: a very long delay before your updates were processed. At this time there is still a long queue of unprocessed updates, but updates are being processed again. Obviously, a faster, more powerful machine would process updates quicker than the current machine. On Tuesday, the problem was that it was possible to delete objects referenced somewhere in the database before deleting all references to that object. Imposing such a constraint (referential integrity check) has been already been considered. Tuesday's incident was not a security problem - anyone with the correct authorization can still make a mistake. At the previous RIPE meeting in Edinburgh, we announced new software, including a referential integrity check, and new hardware, a Sun E450 machine. We intended to deploy both of these at the end of October or early November. We had bad luck that several unrelated problems occurred this week, just before the planned deployment of the new code and the new machine. Now, a status report. All your updates have been queued - there is no need to re-send them. We estimate that the situation should be back to normal tomorrow, if not sooner. We still plan to introduce the new software and hardware next week. We thank you all for your support in the past and we assure you of our continuing efforts to support you in your work. Your sincerely, Ambrose Magee -------------------------------------------------- for, and on behalf of, the RIPE NCC Database Group.

1 0

Re: Events of Tuesday, 27 October 1998.
by Petra Zeidler 30 Oct '98

30 Oct '98

Dear Mr. Kalogeras, Thus wrote Dimitrios Kalogeras (D.Kalogeras(a)noc.ntua.gr): [...] > > 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. > You forget that the RIPE DB is very much a moving target. There were backups, we (Xlink) even have a copy due to running a RIPE mirror, but what does that help? it took some time until the mass deletions were detected, and there were ample changes in the meantime. Re-enacting these would have been almost as much headache and also prone to oversights as repairing what was done and not interfering with standard operations. The only thing that /would/ have helped would have been a switch from take-first-free-handle to take-highest-existing+1, but that is not a trivial change either. kind regards, Petra Zeidler -- [X] Xlink Internet Service GmbH | | i.A. Petra Zeidler, Neukundenanschluss | zeidler(a)xlink.net | | Vincenz-Prie_nitz-Stra_e 3 [X] D-76131 Karlsruhe | Tel: 0721/9652-220 [X] Fax: 0721/9652-209 | | Geschdftsf|hrer: Michael Rotert. Amtsgericht Karlsruhe HRB 8161. | Auftrdge erledigen wir zu unseren Allgemeinen Geschdftsbedingungen. ---------------------------------------------------------------------[ ]

1 0

Objects affected by events of 27/10/1998.
by RIPE Database Administration 30 Oct '98

30 Oct '98

Dear Colleagues, We keep detailed logfiles of all updates to the RIPE Database. We processed these files to produce lists of all objects affected by the incidents earlier this week. We have decided to make these files public, to support you when ensuring that your data is consistent. These files contain only the name and nic-handle of affected person objects. These files may be obtained by anonymous ftp from: ftp://ftp.ripe.net/ripe/dbase/981027-incident.Delete ftp://ftp.ripe.net/ripe/dbase/981027-incident.New ftp://ftp.ripe.net/ripe/dbase/981027-incident.Update There are also gzip'ed versions available, using the same filenames, with the .gz extension. If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ----------------------- RIPE NCC Database Group

1 0

Big delays with <auto-dbm>.
by RIPE Database Administration 29 Oct '98

29 Oct '98

Dear Colleagues, Last night, there was a higher than usual number of messages to <auto-dbm(a)ripe.net>. Thus, there were some delays in processing these messages. This morning, we carried out some unrelated preventative maintenance and this has led to more delays. Your messages are being stored and will be processed as soon as possible. BTW, this maintenance was not linked to the recent actions of any user of the RIPE Database :-) If you have any questions, please contact <ripe-dbm>. It is either Murphy's Law, or Hallowe'en, or the Great Pumpkin, or whatever, that this happened this week. We thank you for your patience. Regards, --------------------------- The RIPE NCC Database Group.

1 0

ripe-141 web interface
by Paula Caslav 29 Oct '98

29 Oct '98

Hi, Thanks for the interest in and discussion about our proposed release of the web interface for ripe-141 forms. We think there is sufficient interest to proceed, and would like to clarify what we are planning: First, we will write and install a public web page at RIPE NCC which allows the entry of a ripe-141 form for *syntax* checking. The output will be a plain text page which can be pasted into an email. Second, we will release the source code of the above, with an added hook to allow sending of the output by email. LIRs will be able to install adaptations of this for use by their customers to check and submit their requests to the LIR, and by their hostmasters to check and submit their requests to RIPE NCC. The LIRs will be free to use this code in any other systems they have. We will implement a public page at RIPE NCC first to allow us to debug the software before it is made publicly available, and understand any problems the LIRS have in the implementation. We would hope to release the software soon after it is written. We cannot release the full code that we use here at the RIPE NCC, because it does some checks that we can only make available for requests that are within a registry's assignment window. These checks include looking for policy problems (as opposed to pure syntax problems) such as reserved addresses or inefficient address space usage. This is something that we'd like to be able to track. For example if a registry sends a request through the robot and it gives an error that the addresses are not being used efficiently, and then they decide to just increase the numbers everywhere to make it look more efficient, we'd like to be able to track this (yes, we have seen this happen). Therefore we will only make this part of the code available for the requests that are within a registry's assignment window and do not have to be sent to the RIPE NCC for approval. Therefore, we can only make this available on our web server (as part of the third stage). The third stage would be a public web page at RIPE NCC with some form of password authentication, which would allow LIRs to *fully* check assignments both smaller and larger than their assignment window, with larger assignments being sent on to the RIPE NCC hostmasters. We hope this meets most people's requirements. Inetnum database object submission thorugh a web page is being discussed in the db-wg. Therefore if you are interested in this topic, please get involved in that working group. To clarify the setup here at RIPE NCC: All mail to hostmaster(a)ripe.net is handled by the 'autohmdist' robot. This robot calls the 'autohm' robot to check and respond to ripe-141 requests, which we are discussing here. Both robots add messages to the hostmaster ticketing system, 'rtt'. Human hostmasters read and respond to messages through rtt. Paula Caslav Registration Services Manager RIPE NCC Maldwyn Morris Software Manager RIPE NCC

1 0

Re: Massive changed in the Ripe Database..
by Oliver J. Albrecht 28 Oct '98

28 Oct '98

[ Moderator note: changed local-ir(a)ripe.net -> lir-wg(a)ripe.net ] Hi, On Wed, Oct 28, 1998 at 05:34:20PM +0200, Pavel Golubev wrote: > I think PGP-signed request (Internic for example) - good way to stop > unauthorized access to database... That's probably the best approach, *if* it's done right. Internic PGP authentication has a really bad track record of (mostly) not working as expected. Those of you who with PGP enabled handles or readers of the guardian list are probably well aware of this :-) Just my $0.02... -- Oliver J. Albrecht AllCon GmbH http://www.allcon.net/ Network Administration Westerallee 139 Tel: +49 461 90393-0 olli(a)spike.allcon.net D-24941 Flensburg Fax: +49 461 90393-33

3 2