- db-wg - mailman.ripe.net

Re: Who should do entries in RIPE database?
by Carol Orange 31 Oct '97

31 Oct '97

Dear Carsten, Yes indeed, the consistency problems in the RIPE database are well known and are even well documented in: ftp://ftp.ripe.net/ripe/dbase/info/consistency* and ftp://ftp.ripe.net/ripe/presentations/ripe-m26-orange-dbcons.ps.gz or http://www.ripe.net/meetings/ripe/ripe-26/pres/db-consist/ Our plans to deal with them are also documented in: ftp://ftp.ripe.net/ripe/presentations/ripe-m27-orange-woeber-dbcons.ps.gz or http://www.ripe.net/meetings/ripe/ripe-27/pres/db/consistency/ We do plan to try to eliminate multiple objects pointing to the same person, as well as other clean ups of the person data. [As a side note, this project is now well underway.] We have not however discussed limiting the ability to enter data in the RIPE database, outside of the current and proposed authorization mechanisms. That would certainly be a significant change of course, and for that reason, I have cc'd the RIPE Database working group on this mail to get their feedback on this idea. Greetings, Carol Orange RIPE NCC In message <3456024C.70C28953(a)contrib.com>, Carsten Schiefner writes: >> As a result of a voluminous discussion with one of POPs I would like to >> point your interest on the following topic I am a little bit upset of: >> >> Almost everybody who knows about about the RIPE database schema (which >> is no secret at all!) can do entries just by sending a mail to >> 'auto-dbm(a)ripe.net'. This leads to an overwhelming bunch of multiple, >> bad maintained or what-ever-you-want entries - especially person >> objects - without any fun in grepping through them and selecting the >> right one to create a new object. Example: >> >> There are four(!) entries for the entity "Joerg Schmidt" of "ZWF >> Digitale Informations Technologie GmbH": JS893-RIPE, JS1161-RIPE, >> JS1163-RIPE and JS1438-RIPE. This should be definitely stopped! >> >> My idea is that we should discuss future restrictions on the possibility >> for everybody to put entries in the RIPE database, maybe by setting up >> and maintaing access lists for every LIR. >> >> For me this database is a central tool in my daily work and I am very >> interested in keeping quality and reliability of stored data as high >> as possible. >> >> Kind regards, >> >> Carsten Schiefner >> -- >> >> Carsten Schiefner mailto:schiefner@contrib.com >> TCP/IP GmbH, Berlin (Germany) - Contrib.Net http://www.contrib.com >> Phone: +49.30.44 33 66-0 Fax: +49.30.44 33 66-15 >> ======================================================================

2 1

Re: Who should do entries in RIPE database?
by NCC local-ir list Moderator 30 Oct '97

30 Oct '97

------- Forwarded Message From: Dale Amon as Operator <root(a)starbase1.gpl.net> Date: Thu, 30 Oct 97 11:21:59 GMT To: Carsten Schiefner <schiefne(a)contrib.com> Subject: Re: Who should do entries in RIPE database? Cc: local-ir(a)ripe.net Reply-To: amon(a)galileo.gpl.com References: <3456024C.70C28953(a)contrib.com> > There are four(!) entries for the entity "Joerg Schmidt" of "ZWF > Digitale Informations Technologie GmbH": JS893-RIPE, JS1161-RIPE, > JS1163-RIPE and JS1438-RIPE. This should be definitely stopped! > Why? > My idea is that we should discuss future restrictions on the possibility > for everybody to put entries in the RIPE database, maybe by setting up > and maintaing access lists for every LIR. > Please let's not add more things to remember. The job of admin people at ISP's is rough enough as it is. I'd personally rather see every possible effort made to decrease work loads on everyone's part, and to decrease the number of things that need to be remembered. I applaud the improvements made in the RIPE database over the last 5 years. The "smarts" in the process are a real help for people who are trying to do so many things at once that errors are inevitable. > For me this database is a central tool in my daily work and I am very > interested in keeping quality and reliability of stored data as high > as possible. It is also a central tool in my work and I am more interested in simplicity of the process of working with my own data than I am in simplicity of others using my data. So long as my routing and DNS work, I could care less if someone has 500 entries under their name. ------- End of Forwarded Message

1 0

Re: Who should do entries in RIPE database?
by NCC local-ir list Moderator 30 Oct '97

30 Oct '97

------- Forwarded Message From: Christian Kratzer <ck(a)toplink.net> Message-Id: <199710301109.MAA17929(a)toplink1.toplink.net> Subject: Re: Who should do entries in RIPE database? To: schiefne(a)contrib.com (Carsten Schiefner) Date: Thu, 30 Oct 1997 12:09:58 +0100 (MET) Cc: local-ir(a)ripe.net In-Reply-To: <3456024C.70C28953(a)contrib.com> from "Carsten Schiefner" at Oct 28, 97 04:18:36 pm X-Mailer: ELM [version 2.4 PL24 ME8a] Content-Type: text Content-Length: 1555 Hi > As a result of a voluminous discussion with one of POPs I would like to > point your interest on the following topic I am a little bit upset of: > > Almost everybody who knows about about the RIPE database schema (which > is no secret at all!) can do entries just by sending a mail to > 'auto-dbm(a)ripe.net'. This leads to an overwhelming bunch of multiple, > bad maintained or what-ever-you-want entries - especially person > objects - without any fun in grepping through them and selecting the > right one to create a new object. Example: > > There are four(!) entries for the entity "Joerg Schmidt" of "ZWF > Digitale Informations Technologie GmbH": JS893-RIPE, JS1161-RIPE, > JS1163-RIPE and JS1438-RIPE. This should be definitely stopped! > > My idea is that we should discuss future restrictions on the possibility > for everybody to put entries in the RIPE database, maybe by setting up > and maintaing access lists for every LIR. > > For me this database is a central tool in my daily work and I am very > interested in keeping quality and reliability of stored data as high > as possible. it would propably be sufficient to require a passphrase for auto-dbm(a)ripe.net so only regisitiers with registered passwords could submit entries or change records. This would definetely keep the "internet experts" from mucking around in the database.d Greetings Christian - -- TopLink GbR, Internet Services info(a)toplink.net Christian Kratzer http://www.toplink.net/ Phone: +49 7032 2701-0 Fax: +49 7032 2701-19 FreeBSD spoken here! ------- End of Forwarded Message

1 0

RIPE Database software release 2.1
by Chris Fletcher 27 Oct '97

27 Oct '97

RIPE Database software Version 2.1 is now available from: ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-2.1.tar.gz The release notes are included below. There a some new features including a new installation procedure and conversion to perl5. Please let us know if you have problems. Replies to <ripe-dbm(a)ripe.net>. Regards, Chris Fletcher - RIPE NCC RELEASE NOTES for RIPE Database 2.1 SUPPORTED SYSTEMS This release has been tested with perl5.00401 on bsdi2.1 and GNU/linux systems. Please let us know if you have problems running it on other systems. FEATURES When an update sends an acknowledgement and a notification to the same mail address one or the other can be suppressed see SUPPRESSMESS in the config file. New concise format for acknowledgements and notifications. '-v' provides detailed object descriptions. Re-implemented Makefiles and package configuration for ease of use. Includes an 'uninstall' target to carefully remove the executable and libraries when upgrading. Now two help files, one about the whois interface delivered by whois and one about the mail interface delivered by mail. Notifications are sent when an object is created with a notify: attrib. Whole package runs under perl5.004 with DB_File interface to Berkley db. Perl5 hides a lot of platform specific things from scripts so various configuration options have been made obsolete and removed. DB_File allows you to increase the size of the in memory db file cache which greatly improves indexing performance. see DBCACHESIZE We have not tried it with other DBM packages but it should not be hard to change if you want to use GDBM_File. This could become a configuration option (or maybe use AnyDBM_File) if there is demand for it. Changed syntax of 'changed:' & 'withdrawn:' to allow a 4 digits in the year part of the date (8 digits in total rather than 6). Automatically added dates are 8 digits. Existing 6 digit date fields are left unchanged. BUG FIXES added word boundary matches to subject line parsing now matches 'new object' and not 'My Apple Newton'. added 'i' to regexp check of MAIL-FROM so is not case-sensitive changed code to match comments in ripedb.config won't log incoming serial updates to files if SERIALINCOMINGDIR is not defined. MISC Added copyright message to all source files to better assert our rights but licence has not changed from previous versions. I have had problems with bitwise operations on the large integers used to represent IP addresses. With some versions of perl5 a bitwise '&' returns a signed result. This causes classless lookups to fail. See comments about iprightzeromask in misc.pl. It seems to work with perl5.00401 Changes to ripedb.config The following values have been removed... HELP (replaced by WHOISHELP & AUTODBMHELP) RENICECMD (optional - will use setpriority(2) if not set) The following values have been added... WHOISHELP AUTODBMHELP ATTDESC OBJDESC DBCACHESIZE SUCCESSTXT HELPHEADER FAILURETXT

1 0

Re: some problem in syntax.pl
by Steven Bakker 20 Oct '97

20 Oct '97

>>>>> On Sat, 18 Oct 1997, "HH" == Hwang Hyojung wrote: HH> why do you eval check ? Isn't this necessary ? Rather, I think, HH> $regex is checked if it is valid email address. How do you think HH> about it ? If it is necessary, please explain why this is needed . HH> Thanks in advance !! Please read RIPE-157, section 2.3.3., Authorization Schemes (shouldn't that be "Authorisation", Ambrose? :-). There is a section labeled, `The "MAIL-FROM" scheme:', which explains that the MAIL-FROM value in the "mntner" object is treated as a regular expression, against which From:- headers will be matched. So, yes the "eval" is necessary to make sure people submit a valid regex in their "mntner" objects. While we are on the subject, RIPE-157 mentions that the regex should comply to the rules in "POSIX 1003.2 section 2.8." Not having read that document, I wonder if the POSIX syntax and Perl are identical. "syntax.pl" checks whether the regex is Perl-compliant. For example, does '(abc)' mean "the literal string '(abc)'", or (a-la Perl), "the subpattern 'abc'"? Cheers, Steven

1 0

some problem in syntax.pl
by Hwang Hyojung 18 Oct '97

18 Oct '97

Hi, I am Hyojung Hwang and working for Korea Telecom. I am using ripe dbase software. I found some problem or starnge things in this code. In syntax.pl, checking 'auth' attribute, --- elsif ($authstr[0] eq "MAIL-FROM") { local($regex) = $value; $regex =~ s/^\s*MAIL\-FROM\s*//; eval "/$regex/;"; if ($@) { return $O_ERROR, "\"$regex\" is not a legal regular expression"; } else { return $O_OK; } } --- why do you eval check ? Isn't this necessary ? Rather, I think, $regex is checked if it is valid email address. How do you think about it ? If it is necessary, please explain why this is needed . Thanks in advance !! -- * _ _ ==GD@: 56@L0m Hq8A@: 1$1b@L4Y. ||_|| ||_| Hwang, Hyojung / jung(a)jean.kotel.co.kr / 82-2-526-5235 |_| _|_ Internet Team / Multimedia Laboratory / KT R&D Group |_| 137-792, 17 Umyun-Dong, Seocho-Gu, Seoul, Korea

1 0

Slow update processing.
by RIPE Database Administration 14 Oct '97

14 Oct '97

Dear Colleagues, This afternoon, two large update messages were sent to <auto-dbm(a)ripe.net>. They were sent very close together in time. This has created a queue which is longer than normal. We expect this queue to be at its normal size soon. We thank you for your patience. You are not required to send in your update message again. We ask that you think of other users when you send in long update messages; please send them in outside working, "office" times. If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

1 0

auto-dbm
by Helen Dagerus 14 Oct '97

14 Oct '97

Is there something wrong with the database auto-dbm? Kind Regards Helen Dagerus Tele2/SwipNet

1 1

Database Updates.
by RIPE Database Administration 02 Oct '97

02 Oct '97

Dear Colleagues, There is a queue of Database updates. This is because of a problem which we fixed this morning. We anticipate that the queue will be processed by 1300 UTC today. Thank you for your patience. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

1 0

Re: RIPE Database files.
by davidk＠isi.edu 02 Oct '97

02 Oct '97

[ CC'ed to the db-wg list since my question and your answer seems to be of interest for more people ] Ambrose, RIPE Database Administration writes: > > In particular, the person and role objects will only be available > if you agree to follow an acceptable use policy. > > ... > > The text files containing the whole database > > ftp://ftp.ripe.net/ripe/dbase/ripe.db.gz > > and > > ftp://ftp.ripe.net/ripe/dbase/ripe.db.long.gz > > will be removed. Are you removing the complete files ?!? I would appreciate if you could keep the files but without the person and role objects. This way, I (and probably other people) don't need to change any of my (their) scripts, Thanks in advance, David K. ---

1 0

for help
by abocintl＠public3.bta.net.cn 01 Oct '97

01 Oct '97

I choose the ripe dabase software to setup a intranet nic and need not to connect to internet. After i install the server software, i find i can use "dbupdate" applcation program to creat a new person object, but i can creat a new domain or inetnum objects which ip ranges from 10.71.0.0 to 10.71.255.255 and domain name is nic.cnpc.com.cn. Can you help me?thanks by the way, where can i find some information about "networkupdate" application program and could i creat a "mntner"object by myself?

2 1

subscribe
by Alexander Langer 25 Sep '97

25 Sep '97

subscribe langer(a)online-club.de Alexander Langer -- >>>>>>>>>>> Alexander Langer <langer(a)online-club.de> <<<<<<<<<<< >>> http://www.cichlids.com <<< >>> http://rheuma-online.de/ <<< >>> PGP-Key on Request <<< >>> <°))>< ICQ-UIN: 455213 <<< >>>>>>>>>>> Keyboard not found - Press F1 to continue... <<<<<<<<<<<

1 0

rpsl transition session
by SchmitzJo＠aol.com 22 Sep '97

22 Sep '97

Dear all, one topic which has been lurking in the back for quite some time for the IRR is a more elaborate description of routing policies than offered by RIPE-181. In the past months it has more and more emerged, become mature, and is now on the standards track of IETF: RPSL, the routing policy structured language. For future development of the Internet world it needs to be incorporated into the registries. Some preliminary work has already been done to include RPSL into the RIPE database software. But we are still in the beginning. We want to show you which work was done up to now, which work is currently done, and which work there is still to be done in the future. We also want your input to allow a smooth transition from the current version of the database to its future implementation. RPSL is a topic which is important both for routing issues, and for database evolution. Therefore, the chairmen of database wg and routing wg, Wilfried Woeber and Joachim Schmitz, decided to have a joint session of both working groups in addition to their individual wg sessions, on this special topic, the RPSL transition. The individual wg sessions (routing and db) are held on Wednesday. The RPSL transition session is prepared with the help of the RIPE NCC and RPSL developers. It will be held on Thursday at 9:00am (see meeting schedule). Its major goal is *not* to teach RPSL but to give an overview of the current situation and planned developments. Please find enclosed the draft agenda for this session. Regards Wilfried Woeber and Joachim Schmitz Draft Agenda RPSL Transition Session 1. Preliminaries (Joachim Schmitz, Wilfried Woeber) - participants' list - volunteering of scribe - questions to the audience, part one - introduction 2. Short Introduction to RPSL (Daniel Karrenberg) 3. RPSL Planned Development (David Kessens) - RaToolSet - Status of the DB code - conversion tools 4. Changes in RIPE Database Software Behaviour (David Kessens) 5. Outline of a Transition Plan for RIPE (Carol Orange) 6. AOB - questions to the audience, part two - Tutorial at next RIPE meeting ---

1 0

2nd draft agenda for RIPE 28 DB-WG meeting
by Wilfried Woeber, UniVie/ACOnet 17 Sep '97

17 Sep '97

Dear all! Apart from fixing some stupid editorial errors, I've included another item on RA-Tools and (RA-)whois server functions, requirements and compatibility. Wilfried. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Proposed Agenda for the Database Working Group Meeting RIPE-28, September 1997, Amsterdam 2nd Draft, Sept. 17, 1997 A. Administrative stuff (W.Woeber, chair) - volunteering of the scribe - WG-agenda bashing - handling of minutes and actions B. DB AUP enforcement - dealing with misuse of data - impact on mirrors, rules C. DB-SW status report by the RIPE NCC (DB-SW maintainers, RIPE-NCC) - operational changes - new functionality implemented and bugs fixed - documentation (current status, progress) - database consistency - feedback from the users D. Registry data exchange (RIDE) - progress E. RAWhoisD compatibility issues - review of differences in functionality - tool requirements (e.g. RAToolSet) Y. Input from other WGs - t.b.d. Z. AOB WW, 17-Sep-1997 17:58

1 0

draft agenda for RIPE 28 DB-WG meeting
by Wilfried Woeber, UniVie/ACOnet 16 Sep '97

16 Sep '97

Proposed Agenda for the Database Working Group Meeting RIPE-28, October 1997, Dublin 1st Draft, Sept. 16, 1997 A. Administrative stuff (W.Woeber, chair) - volunteering of the scribe - WG-agenda bashing - handling of minutes and actions B. DB AUP enforcement - dealing with misuse of data - impact on mirrors, rules C. DB-SW status report by the RIPE NCC (DB-SW maintainers, RIPE-NCC) - operational changes - new functionality implemented and bugs fixed - documentation (current status, progress) - database consistency - feedback from the users D. Registry data exchange (RIDE) - progress G. Input from other WGs - t.b.d. Z. AOB -WW, 16-Sep-1997 17:45

1 0

draft minutes RIPE-27 DB-WG (apologies for the delay.)
by Wilfried Woeber, UniVie/ACOnet 16 Sep '97

16 Sep '97

Dear DB-WG ! Enclosed please find the draft minutes for the Dublin DB-WG meeting. I'm very grateful to Joachim and Ambrose for taking notes and for providing me with the transcript! As usual, comments welcome! Apologies for the delay in circulating that stuff. Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : **** new PBX ! new phone/fax # ! **** Vienna University : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB (&NIC) Handle: WW144 -------------------------------------------------------------------------- Minutes Database WG Session RIPE 27 Dublin ------------------------------------------ Chairman: Wilfried Woeber (WW144) Scribe: Joachim Schmitz (JS395-RIPE), Ambrose Magee (AMRM1-RIPE) Attenders: 12 1. Administrativa Joachim Schmitz took minutes, supported by Ambrose Magee who took over during the presentations by Joachim. The number of attenders was relatively low due to the BOF on Toplevel Domains held in parallel. The RIPE 26 minutes from the Database WG are not yet finished. However, a rather detailed summary is available and was already circulated. Earlier actions: Open actions were either completed or the relvant topic was on the agenda (referral mechanism, status: attribute) 2. New Functionality of the RIPE Database, Reports, Proposals 2.1 DB referral mechanism (Carol Orange) Carol Orange repeated the presentation she gave at the DNS WG session. She described a DNS referral mechanism for the RIPE DB. This was one of the open issues regarding the RIPE DB and got a high priority on the DB action list. There was consensus in the DNS WG on adoption of the proposal by the RIPE NCC. Carol's presentation is available on the RIPE ftp server as ftp://ftp.ripe.net/ripe/presentations/ripe-m27-orange-woeber-referral.ps.gz Details of the discussion on the proposal in the DNS wg can be found in the DNS WG minutes. Two points were raised during the disucssion in the DB WG: - Who might access data of an ISP which are probably partly confidential or behind a firewall? This problem is partly solved by mirroring the "public" part at RIPE, only. - It was noted that measures must be taken to prevent loops if the referral mechanism is also implemented at other databases. As in the DNS WG, the DB WG found the proposal of the RIPE NCC all right and asked the NCC to implement it in the RIPE DB. 2.2 RAWhoisd - Whoisd merging (Gerald Winters) In the past development of whois daemons diverged. Namely, the Whoisd by RIPE and RAWhoisd of the RA Project differ in many respects. A team with representatives from the RIPE NCC (Chris Fletcher, Carol Orange, Ambrose Maggee) and the RA team (David Kessens, Gerald Winters) was formed to collect input for a preproposal. One year ago, the RIPE whoisd was integrated by the RA team with the RAWhoisd. The reasons for this were: - the RIPE whoisd has an extended interface compared to simple whoisd - the RAWhoisd again extends the RIPE whoisd - the RAToolSet requires RAWhoisd Currently the transition from RIPE181 to RPSL occurs. This adds new requirements, and an integration of RIPE and RA was agreed upon. The advantages are: - the new integrated daemon is a benefit to European RAToolSet users - DB users see a consistent interface - an extended query interface exists Gerald then presented a suggestion for the interface: - it should be backward compatible with both whoisd - RAWhois commands blend with current RIPE protocol, and no "mode" switching is necessary - RAWhois should appear as a separate function call in the DB code distribution The interface might be implemented by adding a new flag to the current RIPE whois interface like "-E <extended command>" for extended query options. Currently, there are less than 10 different extended commands. The flag blends well with the current RIPE whois protocol. The values of the flag parameter are passed through to the server without preprocessing, while old style queries still work. There was some discussion on this flag and how to use it. From the audience it was suggested that the whois client should be able to check which extended functions are available at a given server. Only then it can be used without additional manual tests by the user. In addition proper documentation of the extended functions is mandatory. For implementation of the interface, Gerald pointed out the following practical considerations: - RAWhois will appear as a function call in the RIPE code distribution - RIPE maintains its own code base and software decisions independently - Merit maintains the RAWhois module The integration of both interfaces was approved by the DB working group. 2.3 DB consistency (Carol Orange) Then Carol Orange presented a project plan on DB consistency. A copy of the presentation is available from the RIPE ftp server at ftp://ftp.ripe.net/ripe/presentations/ripe-m27-orange-woeber-dbcons.ps.gz In the talk she first gave a taxonomy of inconsistencies. They are mostly related to references and person objects. She identified two groups which are relevant to prevent inconsistencies: DB maintainers and DB users. Prevention measures are: - require NIC handles with persons - NIC handles are compulsory for references When deleting objects many more warnings especially regarding references are given. However, the DB software should *not* change objects by its own. The responsibility for changes remains completely with the data "owners". From the audience it was pointed out that, if a person object is deleted and there are still references to the corresponding NIC handle, the DB software must check also for references if looking for free NIC handles. Otherwise wrong references may be introduced. As additional measure users must be taught to use NIC handles, and to use role objects for references instead of persons in the contact attributes because they are more "stable". Besides person objects, role objects, and maintainers, a change for the inetnum objects was described as well: in the future the "status" attribute will be compulsory for inetnum objects. Moreover, a new class of "allocated" objects will be introduced based on already existing syntax elements, and simplifying the structure. These objects will all be managed by the RIPE NCC. However, this new class of objects might break existing tools like prtraceroute which reference inetnum objects. To find out whether problems may occur the RIPE NCC will inquire on the DB mailing list on tools which make use of inetnum objects. Finally, the RIPE NCC will initiate a major cleanup of the DB. This includes detection of inconsistencies, determination of the maintainers, urging them to clean up their objects, and education of the users. In this process several issues arise which were discussed in the DB working group: - How often shall reports be generated? There was no consistent agreement. Running checks too often is demanding, and may lessen awareness on the user's side. Weekly checks seem to be reasonable. - How large should reports be? They should be concise hitting on the spot. - How should they be presented? General consensus was that they should be presented on the web. - How public should the reports be displayed? The general feeling was that nobody should be offended by being displayed as bad netizen. Therefore, the reports shall not be actively distributed. However, to put a certain pressure on the lazy guys, data will be publicly available but must be actively fetched. - What if no maintainer can be found? A suggestion is to age corresponding objects. The open question is how to timestamp the objects to delete them after a certain time - the "changed" attribute is not relevant enough. Consensus was that the objects should not be left alone. However, a final decision is still pending. Special advice to the users will include: - checking their objects in general - replace names by NIC handles in references - replace the "notify" attribute by "mnt-by" attributes - this is done to avoid spurious mail addresses not linked to any object (mail addresses are the only value the notify attribute can take) All of the above is comprised in a project plan. In Q3/97 changes in the DB software will be implemented accordingly, and user advice shall be given on the web server. In Q4/97 the focus is on gathering of statistics and reports on the state of the DB. Further evaluation and extended plans will be prepared at the end of the year. 2.4 Security and Authentication (Joachim Schmitz) Joachim Schmitz gave a presentation on the topic of the RIPE DB and its security. It is available from the RIPE ftp server at ftp://ftp.ripe.net/ripe/presentations/ripe-m27-jschmitz-dbsec.html This presentation was originally planned for the previous RIPE meeting but dropped due to time constraints. However, it covers a topic which comes up again and again: registry databases and security. Some of the concerns were already taken account of in the past, e.g. by introducing maintainers. A current item also is hierarchical authorisation. In addition to these active measures also passive elements like the AUP for the DB, or restricted read access were introduced. However, this is not enough. The awareness of all possible incidents must be raised, and the overall security be improved. Some issues are a strong authentication (an inventory should be made), or arising from the distributed form of the DB. To get started on this important topic and to ensure progress, the chairmen of Routing WG and DB WG decided to initiate a task force. This task force shall collect information and define projects. Anybody who feels he/she may contribute is invited to participate in this task force. Currently, the idea is to try something informally around the IETF in Munich, and to have first results by RIPE 28. From the audience the question was posed whether certain attributes may be hidden in objects, e.g. phone numbers in a person object. However, this is also an important contact information. A solution might be to make such attributes optional, yet this is only possible to a certain extent. Another suggestion was to limit distribution of the information (especially to avoid spams or address dealers). There was no consensus on this question. However, it is considered as a topic which should be dealt with in the security task force. 3. Input from other WGs There was some input from the DNS WG, detailed in the presentation by Carol Orange on the DB referral mechanism earlier in the meeting. In addition, Joachim Schmitz had some input from the Routing WG where new elements for authorisation with aut-num and route objects were introduced. Details are shown in http://www.ripe.net/wg/routing/r27-minutes.html The most important elements are: - Authorisation of route objects in aut-num objects An additional "mnt-route" attribute may be added to the aut-num objects. The value of this attribute is a valid maintainer. The function is to define who is allowed to add/change/delete route objects for the origin of the aut-num object. - Notification on overlapping route objects Notifications will be done on creation *and* deletion. Submitters are *always* notified in the success message (by a warning), others are only notified if requested. The request is defined by an additional "x-notify" ("cross notify") attribute which points to the maintainer of a route object. A cross checking within the IRR is proposed. The original idea was to put the "x-notify" attribute in the aut-num object allowing a consistent description of an AS. However, discussion in the audience revealed that it also makes sense to put it in the route object. A final decision could not be reached. The open issues will be discussed on the DB and Routing WG mailing lists. 4. AOB Carol Orange gave a presentation on the RIPE DB survey by the NCC. In this survey initiated by the DB WG on the previous RIPE meeting, the RIPE community was asked to set priorities for open issues with the DB software. Carol's presentation is available from the RIPE ftp server at: ftp://ftp.ripe.net/ripe/presentations/ripe-m27-dbmaint.ps.gz There were 18 participants in the survey. The priority list resulting from this survey was circulated on the DB wg mailing list. Highest priorities were on DB consistency, and communication of the DB software to the user (email update feedback, notifications). A project plan of the RIPE NCC for consistency was already presented in this meeting. Moreover, the RIPE NCC implements more verbosity to the whois interface (options "-v", "-t", and "help"), improves contents of email feedback from updates, and supplies an "online" help for updates (mail to "auto-dbm(a)ripe.net" with subject "help") The presentation was continued with the DB software status report available at ftp://ftp.ripe.net/ripe/presentations/ripe-m27-orange-dbupdate.ps.gz Some of the items were already dealt with in the action review at the beginning of the session. The sequence of items is determined from the DB survey. The presentation was closed with some statistics. Wilfried Woeber pointed out that thanks to Ambrose Magee who did a great job, a new version of the RIPE DB documentation is available as RIPE document RIPE-157. Agenda ------ A. Administrative stuff (W.Woeber, chair) 10min - volunteering of the scribe - WG-agenda bashing - handling of minutes and actions B. New functionality, proposals, reports 30min - Database Referral mechanism (Carol Orange) - rwhois compatibility (Gerald Winters) - Database consistency (Carol Orange) - Security and Authentication (Joachim Schmitz) C. DB-SW status report by the RIPE NCC (DB-SW maintainers, RIPE-NCC) 10min - operational changes (handles mandatory) - new functionality implemented and bugs fixed - documentation (current status, progress) - feedback from the users (DB WS usefulness?) G. General input from other WGs 10min - Hier. Authorisation and Notification in the RR (Routing WG) Z. AOB - RIPE database survey Actions ------- RIPE-NCC: To implement the referral mechanism for domain objects. RIPE-NCC: To make DB consistency information publicly available (for information, no active distribution initially). RIPE-NCC: To implement the cross notification as soon as the technical details have been discussed and agreed. WW, 16-Sep-1997 17:00 # - # - #

1 0

Re: results on Ripe Database
by Wilfried Woeber, UniVie/ACOnet 08 Sep '97

08 Sep '97

Did you ever look into http://www.ripe.net/db/dbwais.html ? I just did a search on the string "tele2", and it definitely finds objects with that string in the address field. (Apologies to Tele 2 if this was not appropriate :-) Of course, in the context of the RIPE DB-WG, we're always open to discuss and propose additional (reverse) lookup keys for the database software itself, but I wonder if more complex searching isn't better taken care of using external tools. Comments welcome! Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : **** new PBX ! new phone/fax # ! **** Vienna University : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB (&NIC) Handle: WW144 -------------------------------------------------------------------------- On Mon, 8 Sep 1997, Helen Dagerus wrote: > Ripe4s Database for searching IPaddresses goes fine, but if you (like a > LIR) wants to find out if the customer (that requests for address space) > already have a range of addresses it4s very difficult to find out. My > wish is that you can search for "company name". You can sometimes get a > hit on "company name", but it is not often. A reverse lookup would seem ideal for this, and I believe many would benefit from it (well - *I* would) :-) A substring search would be nicest. Other opinions? -- Robert Martin-Leghne (RM59), Network Manager (AS2109) main(){int a[2],b[2];pipe(a);pipe(b);if(fork()){dup2(a[0],0);dup2(b[1],1) ;}else{dup2(b[0],0);dup2(a[1],1);write(1,"R",1);}execlp("cat","cat",0);} -------------------------------------------------------------------------------- Return-Path: <owner-db-wg(a)ripe.net> Received: from email.univie.ac.at by access.cc.univie.ac.at (MX V4.1 VAX) with SMTP; Mon, 08 Sep 1997 15:47:16 MET-DST Received: from postman.ripe.net by email.univie.ac.at with SMTP (PP); Mon, 8 Sep 1997 15:46:53 +0200 Received: (qmail 8545 invoked by alias); 8 Sep 1997 13:46:44 -0000 Delivered-To: lists-db-wg-out(a)lists.ripe.net Received: (qmail 8542 invoked by uid 66); 8 Sep 1997 13:46:44 -0000 Received: (qmail 8537 invoked from network); 8 Sep 1997 13:46:41 -0000 Received: from ncc.ripe.net (193.0.0.129) by postman.ripe.net with SMTP; 8 Sep 1997 13:46:41 -0000 Received: from ns.dknet.dk by ncc.ripe.net with SMTP id AA29429 (5.65a/NCC-2.41); Mon, 8 Sep 1997 15:46:39 +0200 Received: from ns.dknet.dk (robert(a)ns.dknet.dk [193.88.44.42]) by ns.dknet.dk (8.8.5/8.8.5) with ESMTP id PAA08442; Mon, 8 Sep 1997 15:46:22 +0200 (MET DST) X-Sender: robert(a)ns.dknet.dk Reply-To: db-wg(a)ripe.net In-Reply-To: <Pine.GSO.3.96.970908145825.19141R-100000@nix> Message-ID: <Pine.GSO.3.96.970908154132.5037D-100000(a)ns.dknet.dk> X-Ncc-Regid: dk.dknet MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: BINARY X-Mime-Autoconverted: from 8bit to quoted-printable by ns.dknet.dk id PAA08442 Sender: owner-db-wg(a)ripe.net Precedence: bulk X-MX-Comment: QUOTED-PRINTABLE message automatically decoded

1 0

results on Ripe Database
by Helen Dagerus 08 Sep '97

08 Sep '97

Greetings, This matter may already have been discussed here in the Ripe Database groupe, but I am a new arrival. Ripe´s Database for searching IPaddresses goes fine, but if you (like a LIR) wants to find out if the customer (that requests for address space) already have a range of addresses it´s very difficult to find out. My wish is that you can search for "company name". You can sometimes get a hit on "company name", but it is not often. What we do now is that we save down the database and there we can search for more details, like ompany name, administrative contact and so on. Have you some suggestion about what you can do about this? Kind Regards Helen Dagerus ---------------------------------------------------------- Tele2/SWIPnet NetCom Systems Tel: +46 8 5626 4000 Box 62 Fax: +46 8 5626 4210 S-164 94 Kista Email: dagerus(a)swip.net Sweden http://www.tele2.se/ ----------------------------------------------------------

3 3

Database proposal
by TOB 08 Sep '97

08 Sep '97

Dear Database group At present the RIPE database is quite open, which means that it potentially can be used as a marketing database. My proposal is that only allocations are shown to everyone e.g the 195.41.0.0 /16 below. There is sufficient information to contact the provider in e.g hacker cases. The idea is that only the provider and RIPE(and of course the customer itself) knows the individual assignments. It should be implemented by hiding individual assignments in the RIPE database for everyone. If a provider does not take a proper action in e.g hacker cases RIPE should have the right to identify who the exact user of e.g a /24 is. Best Regards Torben Bajlum Tele Danmark inetnum: 195.41.0.0 - 195.41.255.255 netname: DK-TELEDANMARK-961204 descr: Provider Local Registry descr: Tele Danmark Datacom country: DK admin-c: KBO1-RIPE tech-c: TB15-RIPE tech-c: CIN1-RIPE status: ALLOCATED PA mnt-by: RIPE-NCC-HM-MNT changed: hostmaster(a)ripe.net 961204 source: RIPE route: 195.41.0.0/16 descr: Tele Danmark origin: AS3292 mnt-by: AS3292-MNT changed: Torben.Bajlum(a)datacom.dk400.dk 961204 source: RIPE According to my proposal the information below should NOT be available to everyone: inetnum: 195.41.47.0 - 195.41.47.255 netname: AARHUS-STIFTSTIDENDE-NET descr: Aarhus Stiftstidende descr: Olof Palmesalle 39 descr: 8200 Aarhus N country: DK admin-c: BR286-RIPE tech-c: BR286-RIPE changed: pha(a)datacom.dk400.dk 970418 source: RIPE

3 2

Unsubscribing
by Ruth Guthrie 26 Aug '97

26 Aug '97

I wonder if you can help me unsubscribe my late husband, Dave Guthrie, from the Ripe mailing list. Dave died in March of this year, and in May I sold our shares of Technocom plc to the Easynet Group. Dave's e-mail address was dave(a)technocom.co.uk. Since his death, incoming messages have been routed to me at ruth(a)technocom.co.uk (until the sale of Technocom) and at the.guthries(a)worldnet.att.net (since May). There have also been occasional uses of @technocom.com and @technocom.net, just to confuse the issue further. If you are able to unsubscribe him, I would appreciate it. If not, have you any advice about how I would do so? Many thanks for your help... Ruth Guthrie

1 0

Bug in database software.
by RIPE Database Administration 22 Aug '97

22 Aug '97

Dear Colleagues, This message is to report a bug in the database software. If you send in an update of a route object in the classful net notation (e.g. 193.0.0.0) instead of the classless representation, you will get a warning message indicating that the route was rewritten to 127.255.255.255/24. You should find that you can lookup the original route object in the database. You should also find that you cannot lookup the new spurious route object, 127.255.255.255\24. You should do the following: (1) update your original route object using the classless notation; (2) delete the 127.255.255.255\24 object; you will find it in the acknowledgement you received from the first update. We will fix this problem as soon as possible. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

1 0

Power Tool For Webmasters
by powertools＠cybertools.net 06 Aug '97

06 Aug '97

With over 30 million documents on the Web today, and thousands more being added almost hourly, it is now harder than ever for potential customers to find your place on the Net. Which is why we've developed the Web Promotion Spider for Windows 95 / NT . This amazing new software automatically submits your site to over 250 (the list grows daily) major search engines, directories, and Usenet newsgroups! Not only that, The Web Promotion Spider has the ability to dynamically optimize your website, ensuring maximum visibility on the Internet - at the same time recording all registration data in a built in database. Originally engineered for use by the professional advertising industry, this program is easy and intuitive to use. Beginners will be amazed at how simple it is to take complete control over their search engine and index marketing efforts. But don't be fooled by its simplicity! The Web Promotion Spider is an industrial strength marketing tool and an extremely valuable part of any on-line publicity campaign. With this kind of power, it should come as no surprise that many of our customers have built profitable on-line promotional businesses with this product and their existing Internet connection! But don't just take our word for it. The Web Promotion Spider is available now for FREE immediate download on a limited trial basis (shareware). Visit http://www.cybertools.net/spider /////////////////////////////////////////////////////////////////////////////// If you wish to be removed from future mailings, please reply with the subject "Remove" and this software will automatically block you from future mailings. ////////////////////////////////////////////////////////////////////////////////

1 0

Power Tool For Webmasters
by powertools＠cybertools.net 29 Jul '97

29 Jul '97

With over 30 million documents on the Web today, and thousands more being added almost hourly, it is now harder than ever for potential customers to find your place on the Net. Which is why we've developed the Web Promotion Spider for Windows 95 / NT . This amazing new software automatically submits your site to over 250 (the list grows daily) major search engines, directories, and Usenet newsgroups! Not only that, The Web Promotion Spider has the ability to dynamically optimize your website, ensuring maximum visibility on the Internet - at the same time recording all registration data in a built in database. Originally engineered for use by the professional advertising industry, this program is easy and intuitive to use. Beginners will be amazed at how simple it is to take complete control over their search engine and index marketing efforts. But don't be fooled by its simplicity! The Web Promotion Spider is an industrial strength marketing tool and an extremely valuable part of any on-line publicity campaign. With this kind of power, it should come as no surprise that many of our customers have built profitable on-line promotional businesses with this product and their existing Internet connection! But don't just take our word for it. The Web Promotion Spider is available now for FREE immediate download on a limited trial basis (shareware). Visit http://www.cybertools.net/spider /////////////////////////////////////////////////////////////////////////////// If you wish to be removed from future mailings, please reply with the subject "Remove" and this software will automatically block you from future mailings. ////////////////////////////////////////////////////////////////////////////////

1 0

RIPE Database: New format for reply messages
by Chris Fletcher 21 Jul '97

21 Jul '97

As announced last week the RIPE database mail interface is now using a new format for replies. Please let ripe-dbm(a)ripe.net know of any problems or suggestions. Regards, Chris Fletcher - RIPE NCC

1 0

Is Your Web Site A Secret?
by owl＠owlsnest.com 18 Jul '97

18 Jul '97

Is your web site the best kept secret on the Internet? We'll promote it to 50 search engines and indexes for $85 and complete the job in 2 business days. Satisfaction is guaranteed! If you have a great product, but are not getting many inquiries from your Web site, you may not be adequately listed on the Web's search engines and indexes. Millions of viewers daily use these facilities to find the products and services they are looking for. But if your site is not listed, no one will see it. Listings on most of these services are free. However, locating and filling out the forms required to get a listing can take several days, and most people just don't have the time to do it. That is why we offer a web site promotion service. WHAT'S THE DEAL? We will submit your site to 50 indexes and search engines for $85. We will accept the return of this E-mail, with the form below filled out, as an order. We will bill you upon completion of the promotion. Our terms are net 15 days from date of invoice. Satisfaction guaranteed! HOW LONG WILL IT TAKE? Generally, we complete the submissions within 48 hours of receiving your order. It can take any individual search engine or index up to three weeks to process your submission, although most are much faster. WHAT SEARCH ENGINES AND INDEXES ARE INCLUDED IN THE PROMOTION? The list changes from time to time. This is our current list: Abaweb!, Alta Vista, Been There, BizWeb, Central Source Yellow Pages, Enterpreneurs on the Web, Excite, Four11, Galaxy, I-Network I-Systems Spiral Business Directory, I-World Web Pointer, Infoseek, Inktomi, Innovator's Network Yellow Pages, Internet Mall, Jayde Online Directory, Jumpcity, Jumper Hot Links, Linkmaster, Lycos, Magellan, Mega Mall, Net-Happenings, Net Navigator, Net Mall, NTG's List, NYNEX Big Yellow, One World Plaza, OnLine's WWWeb Index, Rex, Starting Point, Truenorth, URL Tree, Virtual Lynx, Web Point, WebCentral, Web Venture Hotlist, Webcrawler, Websurf, Win Mag/NetGuide Hotspots, WhatUSeek, Worldwide Announce Archive, WWW Business Yellow Pages, World Wide Yellow Pages, WWW Worm, YelloWWWeb. HOW WILL I KNOW THAT YOU HAVE PROMOTED MY SITE? When we have completed the promotion, we will send you an HTML file as an attachment to your E-mail bill. Save this file to your disk, and view it through your Web browser. It provides links to the search engine we submitted your site to, plus any comments we received from them when we did it. ARE THERE ANY GUARANTEES? We do not require prepayment. Your satisfaction is guaranteed or you don't pay the bill. WHO IS OWL'S EYE PRODUCTIONS? We are a web site promotion company located at: Owl's Eye Productions, Inc. 260 E. Main Street Brewster, NY 10509 Phone: (914) 278-4933 Fax: (914) 278-4507 Email: owl(a)owlsnest.com HOW DO I ORDER? The easiest way to order is by e-mail. Just hit the REPLY button on your e-mail program and fill out the following information. (This information will be posted to the search engines/indexes): Your name: Company Name: Address: City: State/Prov: Zip/Postal Code: Telephone: Fax: Email address: URL: http:// Site Title: Description (about 25 words): Key words (maximum of 25, in descending order of importance): Proofs (Where shall we e-mail proofs): If billing a different address, please complete the following: Addressee: Company Name: Address: City: State/Prov: Zip/Postal Code: Telephone: Fax: Email address: We will bill via Email. (7519) Terms: By returning this document via Email, you agree as follows: You have the authority to purchase this service on behalf of your company. Terms are net 15 days. Accounts sent to collections will be liable for collection costs. You agree to protect and indemnify Owl's Eye Productions, Inc. in any claim for libel, copyright violations, plagiarism, or privacy and other suits or claims based on the content or subject matter of your site. WHAT HAPPENS NEXT? When we receive your order, we will input the information into our system, and send you a proof. After we process any corrections, we will run your promotion, capturing any comments from search engines as we go. We will incorporate these into an HTML-formatted report to you, which we will attach to your bill. ===Web Promotions=====Press Releases=====Link Exchanges========= Owl's Eye Productions, Inc. 260 E. Main Street Brewster, NY 10509 Ph: 914-278-4933 Fx: 914-278-4507 E-mail: owlseye(a)owlsnest.com

1 0