From Daniel.Karrenberg at ripe.net Sun Nov 1 21:14:49 1998 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Sun, 01 Nov 1998 21:14:49 +0100 Subject: Events of Tuesday, 27 October 1998. In-Reply-To: Your message of Sun, 01 Nov 1998 16:56:51 +0100. <199811011555.QAA28385@mail.csl-gmbh.net> References: <199811011555.QAA28385@mail.csl-gmbh.net> Message-ID: <199811012014.VAA28936@kantoor.ripe.net> > "Siegfried Langenbach" 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 From hostmaster at xlink.net Mon Nov 2 17:11:34 1998 From: hostmaster at xlink.net (Wilhelm Buehler) Date: Mon, 2 Nov 1998 17:11:34 +0100 Subject: Events of Tuesday, 27 October 1998. In-Reply-To: <199810310007.BAA13392@kantoor.ripe.net>; "Daniel Karrenberg" on 31.10.1998 @ 01:07:32 MET References: <199810301720.SAA00160@vader.runit.sintef.no> <199810310007.BAA13392@kantoor.ripe.net> Message-ID: <19981102171134.A6811@xlink.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 | > Cc: hostmaster at xlink.net | > Subject: longack | > Date: Wed, 28 Oct 1998 12:34:27 +0000 | > Msg-Id: <36370F53.30E4F99F at 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 at 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. ---------------------------------------------------------------------[ ] From ripe-dbm at ripe.net Tue Nov 3 16:58:29 1998 From: ripe-dbm at ripe.net (RIPE Database Administration) Date: Tue, 03 Nov 1998 16:58:29 +0100 Subject: Events of Tuesday, 27 October 1998 In-Reply-To: Your message of Fri, 30 Oct 1998 09:00:22 +0100. References: Message-ID: <199811031558.QAA21772@office.ripe.net> Dear Rimas Janusauskas, We wish to correct this statement. When AUTO-# is used to create a nic-handle, it uses the lowest available number that is consistent with the initials of the name in the "person" line of the object. "Holes" can and do exist, but no-one should depend on this. Rimas Janusauskas writes: * On Thu, 29 Oct 1998, RIPE Database Administration wrote: * * > 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. * * It's true, that nic-handle is available for re-use, but it * could be (re)created only using directly. * If AUTO-# is used to creat new nic handle, bigest * value+1 is choosen although "holes" exists. * * > 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. * * Is it possible implement such feature, that "e-mail" attribute(s) * should be used as "notify" as well. In that case nic handle holder * will be always informed about (un)expected changes. * That is an interesting suggestion. Perhaps you should send it to the mailing list of the Database Working Group, . * best regards, * * Rimas Janusauskas, * Taide Net Hostmaster * * If you have any more questions, please don't hesitate to contact . Regards, Roman Karpiuk ____________________________ RIPE Database Administration. From svl at nrw.net Mon Nov 2 09:42:27 1998 From: svl at nrw.net (Siegfried Langenbach) Date: Mon, 2 Nov 1998 09:42:27 +0100 Subject: Events of Tuesday, 27 October 1998. In-Reply-To: <199811012014.VAA28936@kantoor.ripe.net> References: Your message of Sun, 01 Nov 1998 16:56:51 +0100. <199811011555.QAA28385@mail.csl-gmbh.net> Message-ID: <199811020841.JAA29161@mail.csl-gmbh.net> 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" 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 > From Christian.Halbe at de.uu.net Mon Nov 2 12:49:54 1998 From: Christian.Halbe at de.uu.net (CHristian Halbe) Date: Mon, 02 Nov 1998 12:49:54 +0100 Subject: Events of Tuesday, 27 October 1998. In-Reply-To: Your message of "Sun, 01 Nov 1998 21:14:49 +0100." <199811012014.VAA28936@kantoor.ripe.net> Message-ID: <199811021149.MAA17693@vulcan.de.uu.net> Hi there! > > "Siegfried Langenbach" 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 at 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 at de.uu.net URL: http://www.de.uu.net From svl at nrw.net Sun Nov 1 16:56:51 1998 From: svl at nrw.net (Siegfried Langenbach) Date: Sun, 1 Nov 1998 16:56:51 +0100 Subject: Events of Tuesday, 27 October 1998. In-Reply-To: <199810310007.BAA13392@kantoor.ripe.net> References: Your message of Fri, 30 Oct 1998 18:20:02 +0100. <199810301720.SAA00160@vader.runit.sintef.no> Message-ID: <199811011555.QAA28385@mail.csl-gmbh.net> 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 at 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. > From Daniel.Karrenberg at ripe.net Tue Nov 3 21:30:14 1998 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 03 Nov 1998 21:30:14 +0100 Subject: From Address Forged In-Reply-To: Your message of Mon, 02 Nov 1998 17:11:34 +0100. <19981102171134.A6811@xlink.net> References: <19981102171134.A6811@xlink.net> Message-ID: <199811032030.VAA04828@kantoor.ripe.net> 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 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 > | > Cc: hostmaster at xlink.net > | > Subject: longack > | > Date: Wed, 28 Oct 1998 12:34:27 +0000 > | > Msg-Id: <36370F53.30E4F99F at xlink.net> > | > | [...] > | > | Delete OK: [person] MW1699-RIPE (Martin Weber) From sh at nwu.de Tue Nov 3 22:36:26 1998 From: sh at nwu.de (Stephan Hermann) Date: Tue, 3 Nov 1998 22:36:26 +0100 Subject: Massive changed in the Ripe Database.. In-Reply-To: <19981030165450.B15292@xlink.net>; from Petra Zeidler on Fri, Oct 30, 1998 at 04:54:50PM +0100 References: <01BE040C.A9199FA0@pc19.heanet.ie> <19981030165450.B15292@xlink.net> Message-ID: <19981103223626.A26442@love> On Fri, Oct 30, 1998 at 04:54:50PM +0100, Petra Zeidler wrote: : 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. Well....I think, we must have another database access. My ideas: 1. No Public Access to the Database I think, we have all (and our customers) problems (with email spam, and the normal snail mail spam. Many of the addresses are only in the RIPE DB. 2. Protection of the RIPE DB Objects Well, we can protect the person objects with our mnt objects. if anyone change the local ir, the old local ir can change the mnt entry in the object to the new local ir. 3. special work with person objects the only way to create, modify and delete person objects is the way to create, modify and delete person objects at a regional IR (denic at germany etc.). Non-Members of regional IR can only create, modify and delete person templates @ the local ir, where they register domains, or register ip networks. 4. Special work with RIPE objects in common what about a timestamped list of requests to the RIPE DB ? If anyone wants to delete objects, and do it in an interval of 10 deletions in 5 seconds (or any other interval we can discuss), the deletions are rejected and the person who request the delete is asked: "Why ?" these 4 points are just ideas...dunno if we can deploy it, but I think we can discuss several problems with the RIPE DB, and think about a solution of the problems. My 2Cent :) sh -- Stephan Hermann, techn. Leiter eMail office: sh at nwu.de NWU GmbH, Am Brambusch 1, D-44536 Luenen home : sh at linux.de Sales: Widumer Str. 28, D-44339 Dortmund Tel.: +49-231-9809110 sales-eMail: vertrieb at nwu.de FAX : +49-231-98091120 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 319 bytes Desc: not available URL: From hostmaster at xlink.net Wed Nov 4 16:35:16 1998 From: hostmaster at xlink.net (Xlink Hostmaster W . Buehler) Date: Wed, 4 Nov 1998 16:35:16 +0100 Subject: From Address Forged In-Reply-To: <031B936404473008*/G=thierry/S=gall/O=not21/PRMD=francetelecom/ADMD=atlas/C=fr/@MHS>; "GALL Thierry TPC-SRD" on 04.11.1998 @ 13:11:32 MET References: <031B936404473008*/G=thierry/S=gall/O=not21/PRMD=francetelecom/ADMD=atlas/C=fr/@MHS> Message-ID: <19981104163516.A21522@xlink.net> Hi, apologize is cheap, the work we had until now is more than 5 person-days. Is Thierry Gall address: TRANSPAC France address: DSR/CSI address: 12 bis, rue Campagne Premiere address: 75014 Paris, France a valid billing-address? GALL Thierry TPC-SRD wrote: > Actually, the address was "forged" but only partially by Trevor, and Hostmaster > was in copy of the mail, > More over it was an attempt to repair the original error and to avoid the work > necessary to rebuild all the links that have destroyed. And destroyed other links!!! We do not create person-objects for fun. we do not protect person-objects for fun. 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 at 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. ---------------------------------------------------------------------[ ] From bs at eunet.ch Wed Nov 4 09:22:57 1998 From: bs at eunet.ch (Bernard Steiner) Date: Wed, 04 Nov 1998 09:22:57 +0100 Subject: Massive changed in the Ripe Database.. In-Reply-To: Your message of "Tue, 03 Nov 1998 22:36:26 +0100." <19981103223626.A26442@love> Message-ID: <199811040823.JAA10753@eunet.ch> Hi all, > 1. No Public Access to the Database > I think, we have all (and our customers) problems > (with email spam, and the > normal snail mail spam. Many of the addresses are only > in the RIPE DB. I have indeed found my own RIPE entries indexed on WWW search engines, which I find a violation of the copyright. However, one very significant purpose of the RIPE DB (IMHO) is that it is available for trouble-shooting. This makes it necessary to give ISPs/IAPs access to it. In other words, you might as well make it public. > 4. Special work with RIPE objects in common > what about a timestamped list of requests to the RIPE DB ? > If anyone wants to delete objects, and do it in an interval > of 10 deletions in 5 seconds (or any other interval=20 > we can discuss), the deletions are rejected and the person > who request the delete is asked: "Why ?" Same goes for all types of object, doesn't it ? Yeah, well... I got a message yesterday asking me to stop flooding one one the RIPE robots, just because I sent a batch of perfectly legitimate update requests. I'm afraid that idea doesn't work, either. Bernard -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 460 bytes Desc: not available URL: From leigh at wisper.net Wed Nov 4 11:23:11 1998 From: leigh at wisper.net (Leigh Porter) Date: Wed, 04 Nov 1998 10:23:11 +0000 Subject: Massive changed in the Ripe Database.. References: <01BE040C.A9199FA0@pc19.heanet.ie> <19981030165450.B15292@xlink.net> <19981103223626.A26442@love> Message-ID: <36402B0F.F64BD43C@wisper.net> Stephan Hermann wrote: > 1. No Public Access to the Database > I think, we have all (and our customers) problems > (with email spam, and the > normal snail mail spam. Many of the addresses are only > in the RIPE DB. The problem here is that RIPE is a very usefull resource for the whole Internet community. Personally I have not had much of a problem with spam sent to email addresses on the database so I do not know how much of a problem this is. -- Leigh From sh at nwu.de Wed Nov 4 11:46:32 1998 From: sh at nwu.de (Stephan Hermann) Date: Wed, 04 Nov 1998 11:46:32 +0100 Subject: Massive changed in the Ripe Database.. In-Reply-To: <36402B0F.F64BD43C@wisper.net> References: <01BE040C.A9199FA0@pc19.heanet.ie> <19981030165450.B15292@xlink.net> <19981103223626.A26442@love> Message-ID: <3.0.1.32.19981104114632.0399ee38@mail1.nwu.de> hi, Am/Um 10:23 04.11.98 +0000 Leigh Porter schrieb: >Stephan Hermann wrote: > >> 1. No Public Access to the Database >> I think, we have all (and our customers) problems >> (with email spam, and the >> normal snail mail spam. Many of the addresses are only >> in the RIPE DB. > >The problem here is that RIPE is a very usefull resource for the whole Internet >community. >Personally I have not had much of a problem with spam sent to >email addresses on the database so I do not know how much of a problem this >is. Well, the first task of the RIPE DB is to show the isps who is responsible for domains, ip networks, etc. But, in the time of collecting informations about people (not only netizens),the ripe db is for address collectors the first place in the net. In Germany (I don't know how it is in other countries) you can deny the print or announcement of your postal address in public addressbooks. the ripe db is sometimes like a public addressbook. but the persons can't deny the publication of their addresses if they register a domain or something like that. So, the solution must be to secure the dates in the database. Ok, in the database output you can find the copyright statement...but it's only a statement...and you can say if you have the address out of the db: "I found this address on the persons webpage, or in one usenet article" who can determine if this statement is right or wrong ? imho we (ripe/ncc, local/regional ir etc.) must enforce the copyright...if we can't do it with rules, then we must protect the database with technical solutions against the abuse. anyone who wants informations about a specific topic (here: persons, administrating contacts etc.) can ask the local/regional ir, the ripe/ncc. kind regards, sh -- Stephan Hermann eMail: sh at nwu.de priv: sh at linux.de Tel: 0231/9809-1113 techn. Leiter http://www.nwu.de/ Fax: 0231/9809-1120 Hauptsitz : NWU GmbH, Am Brambusch 1, D-44536 Luenen Vertriebsbuero: NWU GmbH, Widumer Str. 28, D-44339 Dortmund From thierry.gall at francetelecom.fr Wed Nov 4 13:11:32 1998 From: thierry.gall at francetelecom.fr (GALL Thierry TPC-SRD) Date: Wed, 4 Nov 1998 13:11:32 +0100 Subject: =?iso-8859-1?Q?R=E9f=2E_=3A_From_Address_Forged?= Message-ID: <031B936404473008*/G=thierry/S=gall/O=not21/PRMD=francetelecom/ADMD=atlas/C=fr/@MHS> Actually, the address was "forged" but only partially by Trevor, and Hostmaster was in copy of the mail, More over it was an attempt to repair the original error and to avoid the work necessary to rebuild all the links that have destroyed. Please apologize again for all these perturbations. Thierry GALL From phk at critter.freebsd.dk Thu Nov 5 11:50:53 1998 From: phk at critter.freebsd.dk (Poul-Henning Kamp) Date: Thu, 05 Nov 1998 11:50:53 +0100 Subject: Massive changed in the Ripe Database.. In-Reply-To: Your message of "Wed, 04 Nov 1998 10:23:11 GMT." <36402B0F.F64BD43C@wisper.net> Message-ID: <2611.910263053@critter.freebsd.dk> In message <36402B0F.F64BD43C at wisper.net>, Leigh Porter writes: >Stephan Hermann wrote: > >> 1. No Public Access to the Database >> I think, we have all (and our customers) problems >> (with email spam, and the >> normal snail mail spam. Many of the addresses are only >> in the RIPE DB. > >The problem here is that RIPE is a very usefull resource for the whole Internet > >community. Personally I have not had much of a problem with spam sent to >email addresses on the database so I do not know how much of a problem this >is. I think a far better long term strategy would be to sue the pants of people who trespass on the database... -- Poul-Henning Kamp FreeBSD coreteam member phk at FreeBSD.ORG "Real hackers run -current on their laptop." "ttyv0" -- What UNIX calls a $20K state-of-the-art, 3D, hi-res color terminal From Daniel.Karrenberg at ripe.net Thu Nov 5 17:45:48 1998 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 05 Nov 1998 17:45:48 +0100 Subject: From Address Forged In-Reply-To: Your message of Wed, 04 Nov 1998 16:35:16 +0100. <19981104163516.A21522@xlink.net> References: <19981104163516.A21522@xlink.net> Message-ID: <199811051645.RAA05639@kantoor.ripe.net> Wilhelm and other colleagues, it appears that the header forging did only occur in an effort to correct mistakes made earlier. Repeat: the updates that caused the problems originally were not done using forged headers. This does not mean header forging was not very bad judgement, but at least it occurred only in an effort to correct earlier mistakes. The RIPE NCC will work with Transpac on a post-mortem analysis. More news as it develops. Daniel From svl at nrw.net Thu Nov 5 18:01:23 1998 From: svl at nrw.net (Siegfried Langenbach) Date: Thu, 5 Nov 1998 18:01:23 +0100 Subject: From Address Forged In-Reply-To: <199811051645.RAA05639@kantoor.ripe.net> References: Your message of Wed, 04 Nov 1998 16:35:16 +0100. <19981104163516.A21522@xlink.net> Message-ID: <199811051659.RAA07117@mail.csl-gmbh.net> On 5 Nov 98, at 17:45, Daniel Karrenberg wrote: > > Wilhelm and other colleagues, > > it appears that the header forging did only occur in an effort to > correct mistakes made earlier. Repeat: the updates that caused the > problems originally were not done using forged headers. This does not > mean header forging was not very bad judgement, but at least it occurred > only in an effort to correct earlier mistakes. The RIPE NCC will work > with Transpac on a post-mortem analysis. More news as it develops. Hmm, if it was needed to forge a header to correct a mistake, how then the mistake could be done without forging the header? siegfried > > Daniel > From mlelstv at xlink.net Thu Nov 5 20:41:31 1998 From: mlelstv at xlink.net (Michael van Elst) Date: Thu, 5 Nov 1998 20:41:31 +0100 Subject: From Address Forged In-Reply-To: <199811051659.RAA07117@mail.csl-gmbh.net>; from Siegfried Langenbach on Thu, Nov 05, 1998 at 06:01:23PM +0100 References: <19981104163516.A21522@xlink.net> <199811051645.RAA05639@kantoor.ripe.net> <199811051659.RAA07117@mail.csl-gmbh.net> Message-ID: <19981105204131.A858@xlink.net> On Thu, Nov 05, 1998 at 06:01:23PM +0100, Siegfried Langenbach wrote: > On 5 Nov 98, at 17:45, Daniel Karrenberg wrote: > > > > > Wilhelm and other colleagues, > > > > it appears that the header forging did only occur in an effort to > > correct mistakes made earlier. Repeat: the updates that caused the > > problems originally were not done using forged headers. This does not > > mean header forging was not very bad judgement, but at least it occurred > > only in an effort to correct earlier mistakes. The RIPE NCC will work > > with Transpac on a post-mortem analysis. More news as it develops. > > Hmm, > if it was needed to forge a header to correct a mistake, > how then the mistake could be done without forging the header? > > siegfried I get tired discussing this. Yes, the original 'mistake' didn't involve forged headers. Yes, old records have been deleted this way. No, these records were not protected by their maintainers (auth: NONE). Yes, the handles were reallocated to other records. Yes, some of these new records were protected by their maintainers. Yes, these new records were deleted using forged mail headers. No, the old records were not restored because the restoring update was sent too early (usually in the same mail which inherently fails). Yes, the yet-again free handles have been reallocated to even more new records again. Yes, deleting the new records caused more inconsistencies and more data loss. No, deleting the new records didn't correct the original 'mistake' at all. Yes, deleting the new records produced more errors outside the RIPE-DB realm (for example, registrations of domains that reference the new-but-then-deleted person records in the RIPE-DB failed). Yes, deleting the new records sabotaged other people's attempt to recover from original 'mistake'. We have thus switched from MAIL-FROM to CRYPT-PW authorization. If I see any unauthorized update in the future, the responsible person gets shot. -- i.A. Michael van Elst / phone: +49 721 6635 330 Xlink - Network Information Centre \/ fax: +49 721 6635 349 Vincenz-Priessnitz-Str. 3 /\ link http://nic.xlink.net/ D-76131 Karlsruhe, Germany /_______ email: hostmaster at xlink.net [ Xlink Internet Consulting GmbH, Sitz Koeln ] [ Amtsgericht Koeln HRB 3526, Geschaeftsfuehrer: Michael Rotert ] From haug at seicom.NET Thu Nov 5 19:59:17 1998 From: haug at seicom.NET (Winfried Haug) Date: Thu, 5 Nov 1998 19:59:17 +0100 Subject: From Address Forged In-Reply-To: <199811051659.RAA07117@mail.csl-gmbh.net> Message-ID: <000101be08ee$63b50940$02ff61c2@winni-laptop.seicom.net> First of all, please dont quote complete mails for just 2 lines from you.. > Hmm, > if it was needed to forge a header to correct a mistake, > how then the mistake could be done without forging the header? > if you have attended at this topic you should have noticed that most handles had no protection (just a notify) but were not mounted. So there was no problem to delete these records... Thats it.. Winfried From mlelstv at xlink.net Fri Nov 6 11:17:05 1998 From: mlelstv at xlink.net (Michael van Elst) Date: Fri, 6 Nov 1998 11:17:05 +0100 Subject: From Address Forged In-Reply-To: <199811060815.JAA05147@mail.csl-gmbh.net>; from Siegfried Langenbach on Fri, Nov 06, 1998 at 09:16:36AM +0100 References: <199811051659.RAA07117@mail.csl-gmbh.net>; <19981105204131.A858@xlink.net> <199811060815.JAA05147@mail.csl-gmbh.net> Message-ID: <19981106111705.A2964@xlink.net> On Fri, Nov 06, 1998 at 09:16:36AM +0100, Siegfried Langenbach wrote: > On 5 Nov 98, at 20:41, Michael van Elst wrote: > > > > I get tired discussing this. > > > Dear Michael, Dear Siegfried, > I dont think that reaction is appropriate. I guess then you didn't waste days and weeks fixing the 'mistake' only to see that your work has been subverted using forged authorizations. I don't think that an emotional reaction is inappropriate. > I see a valid need of RIPE NCC > members to know what was going on. I am sure that the RIPE NCC members do know what was going on and have been providing real help. Thanks to them. [...] > Your listing of "affirmatives" is not really the report I am expecting (as > promised by Daniel). Who am I to give Daniel's report ? ;-) I merely answered your question and shared a sad little bit of information. Michael van Elst -- i.A. Michael van Elst / phone: +49 721 6635 330 Xlink - Network Information Centre \/ fax: +49 721 6635 349 Vincenz-Priessnitz-Str. 3 /\ link http://nic.xlink.net/ D-76131 Karlsruhe, Germany /_______ email: hostmaster at xlink.net [ Xlink Internet Consulting GmbH, Sitz Koeln ] [ Amtsgericht Koeln HRB 3526, Geschaeftsfuehrer: Michael Rotert ] From svl at nrw.net Fri Nov 6 09:16:36 1998 From: svl at nrw.net (Siegfried Langenbach) Date: Fri, 6 Nov 1998 09:16:36 +0100 Subject: From Address Forged In-Reply-To: <19981105204131.A858@xlink.net> References: <199811051659.RAA07117@mail.csl-gmbh.net>; from Siegfried Langenbach on Thu, Nov 05, 1998 at 06:01:23PM +0100 Message-ID: <199811060815.JAA05147@mail.csl-gmbh.net> On 5 Nov 98, at 20:41, Michael van Elst wrote: > On Thu, Nov 05, 1998 at 06:01:23PM +0100, Siegfried Langenbach wrote: > > On 5 Nov 98, at 17:45, Daniel Karrenberg wrote: > > > > > > > > Wilhelm and other colleagues, > > > > > > it appears that the header forging did only occur in an effort to > > > correct mistakes made earlier. Repeat: the updates that caused the > > > problems originally were not done using forged headers. This does not > > > mean header forging was not very bad judgement, but at least it occurred > > > only in an effort to correct earlier mistakes. The RIPE NCC will work > > > with Transpac on a post-mortem analysis. More news as it develops. > > > > Hmm, > > if it was needed to forge a header to correct a mistake, > > how then the mistake could be done without forging the header? > > > > siegfried > > > > I get tired discussing this. > > > Yes, the original 'mistake' didn't involve forged headers. > Yes, old records have been deleted this way. Dear Michael, I dont think that reaction is appropriate. I see a valid need of RIPE NCC members to know what was going on. As chair of CORE-SRS-WG I am personally envolved in that kind of problems and would like to learn. You may have more infos than others, thats fine with you, but please let us share them. Your listing of "affirmatives" is not really the report I am expecting (as promised by Daniel). siegfried [...] > -- > i.A. Michael van Elst / phone: +49 721 6635 330 > Xlink - Network Information Centre \/ fax: +49 721 6635 349 > Vincenz-Priessnitz-Str. 3 /\ link http://nic.xlink.net/ > D-76131 Karlsruhe, Germany /_______ email: hostmaster at xlink.net > [ Xlink Internet Consulting GmbH, Sitz Koeln ] > [ Amtsgericht Koeln HRB 3526, Geschaeftsfuehrer: Michael Rotert ] > > From joao at ripe.net Mon Nov 16 18:54:30 1998 From: joao at ripe.net (Joao Luis Silva Damas) Date: Mon, 16 Nov 1998 18:54:30 +0100 Subject: RIPE Database incident of 27th October Message-ID: <199811161754.SAA05711@x41.ripe.net> Dear all, the RIPE NCC Database group has been reviewing the events regarding the RIPE Database incident of 27 October. We have produced a report that can be found at http://www.ripe.net/db/incident.html All data sent to the database, related to this incident, is accessible through this URL. If you have any questions regarding this incident or otherwise related to the RIPE Database we will be glad to answer them. Best regards, Joao Damas RIPE DB Group RIPE NCC From ripe-dbm at ripe.net Thu Nov 26 18:06:44 1998 From: ripe-dbm at ripe.net (RIPE Database Administration) Date: Thu, 26 Nov 1998 18:06:44 +0100 Subject: Performance of auto-dbm, Thu, 27 Nov 1998 Message-ID: <199811261706.SAA15617@office.ripe.net> Dear Colleagues, We had some performance problems this morning and we had to temporarily stop updates in order to restore performance to its usual level. Updates were restarted as soon as we had finished working on this problem and the queue of updates was quickly processed. We appreciate your patience and we assure you that your updates were not lost. During this time, they were stored; there is no need to send them again. If you have any questions, please contact . Regards, A. M. R. Magee _______________________ RIPE NCC Database Group