- db-wg - mailman.ripe.net

Re: Deletion of German domains
by Simon Leinen 28 Jun '00

28 Jun '00

>>>>> "mn" == mike norris <mike.norris(a)heanet.ie> writes: > What ever happened to the auto-referral mechanism, whereby a query > about a moved object could be referred onward to the appropriate > whois server? Such a mechanism has been in place for a while. The domains under .ch have been using it since December 1998. $ whois -h whois.ripe.net '-r -R -T domain ch' [...] domain: ch [...] refer: SIMPLE whois.nic.ch changed: gottsponer(a)switch.ch 19981223 In the meantime there has been an improved version of the referral mechanism which provides the IP address (or hostname?) of the original requestor to the delegated Whois server, which can be useful for logging/rate limiting purposes. It's certainly documented somewhere on the RIPE Web server. -- Simon Leinen simon(a)babar.switch.ch SWITCH http://www.switch.ch/misc/leinen/ Who is General Failure & why's he reading my disk?

2 1

registry handle issues [was: Deletion of German domains]
by Wilfried Woeber, UniVie/ACOnet 28 Jun '00

28 Jun '00

Andre, Randy, wrt handles we have to declare defeat, unfortunately. One of the last major (undeclared :-) battles we lost was the migration of data from the "InterNIC model" environment (IP addresses and gTLDs) into, eventually, the NSI domain stuff and the ARIN IP stuff. Not only was this the biggest case of handle and object duplication into 2 different regsitries (to my knowledge without an announcement being made or the victims being warned), but the then implicit convention of deriving Handle-"RegistryCode" suffixes (i.e. XY12-RIPE, AB89-APNIC) was broken by the invention or things like -NET -DOM -ROLE and the like. A while ago, there were a few ideas and proposals floating around (like using a DNS-like approach: WW144-RIPE.NET or WW144-NIC.AT), but as to my knowledge, no consensus was developing. Requiescat in pacem. Sigh. Btw, I'm really looking forward to the point in time when we'll see the first clash in registry names. That's going to be the beginning of the end of mirrors.... Wilfried. > > given > > whois -h whois.ripe.net dom.ain.de > > returning <handle>-DENIC, so i then follow with > > whois -h whois.ripe.net <handle>-DENIC > > i can only conclude, givem the first quoted paragraph above, that the data > must be manually entered in both databases or that ripe mirrors denic's > database. > Seems like we need a referal meganisme for nic-handles? Regards, Andre --------------------------------------------------------------------------------

1 0

domain referrals [was: Deletion of German domains]
by Wilfried Woeber, UniVie/ACOnet 28 Jun '00

28 Jun '00

Oli, the IS stuff looks *very* good. With some other domains (i.e. CH :-) there are still loose ends) Here's the RIPE objects: > wripe -RT domain is % Rights restricted by copyright. See http://www.ripe.net/ripencc/pub-services/db/copyright.html domain: is descr: Top level domain for Iceland descr: Internet Iceland - INTIS [ ... ] admin-c: HJ18 tech-c: MO33 zone-c: MO33 [ ... ] refer: ripe whois.isnet.is changed: marius(a)isgate.is 19931123 changed: marius(a)isgate.is 19970728 source: RIPE person: Helgi Jonsson [ ... ] changed: marius(a)isnet.is 20000218 source: RIPE person: Marius Olafsson [ ... ] changed: marius(a)isnet.is 20000218 source: RIPE and here's the referred-to output: > wripe -T domain is % Rights restricted by copyright. See http://www.ripe.net/ripencc/pub-services/db/copyright.html The object shown below is NOT in the RIPE database. It has been obtained by querying a remote server: (whois.isnet.is) at port 43. To see the object stored in the RIPE database use the -R flag in your query. % Rights restricted by copyright. See http://www.isnet.is/whois/copyright.html % % Útgáfuréttur áskilinn. Sjá http://www.isnet.is/whois/utgafurettur.html domain: is descr: Top level domain for Iceland descr: Internet Iceland - INTIS [ ... ] changed: marius(a)isgate.is 19931123 changed: marius(a)isgate.is 19970728 source: IS person: Helgi Jonsson [ ... ] changed: hostmaster(a)isnet.is 20000323 source: IS person: Marius Olafsson [ ... ] changed: marius(a)isnet.is 19950201 changed: hostmaster(a)isnet.is 20000323 source: IS As the referral type is RIPE, even passing flags like -r to suppress recursion is working fine: > wripe -rT domain is % Rights restricted by copyright. See http://www.ripe.net/ripencc/pub-services/db/copyright.html The object shown below is NOT in the RIPE database. It has been obtained by querying a remote server: (whois.isnet.is) at port 43. To see the object stored in the RIPE database use the -R flag in your query. % Rights restricted by copyright. See http://www.isnet.is/whois/copyright.html % % Útgáfuréttur áskilinn. Sjá http://www.isnet.is/whois/utgafurettur.html domain: is descr: Top level domain for Iceland [ ... ] changed: marius(a)isgate.is 19931123 changed: marius(a)isgate.is 19970728 source: IS %%% End of referred query result CH for example is working in principle, but the remote server still refuses to serve data for it's own TLD root ;-) > wripe -T domain ch % Rights restricted by copyright. See http://www.ripe.net/ripencc/pub-services/db/copyright.html The object shown below is NOT in the RIPE database. It has been obtained by querying a remote server: (whois.nic.ch) at port 43. To see the object stored in the RIPE database use the -R flag in your query. Malformed query string <------------------------------ %%% End of referred query result The RIPE-DB object looks fine, though: > wripe -rRT domain ch % Rights restricted by copyright. See http://www.ripe.net/ripencc/pub-services/db/copyright.html domain: ch descr: Switzerland admin-c: MS219-RIPE tech-c: WH1101 zone-c: WH1101 nserver: domreg.nic.ch nserver: merapi.switch.ch nserver: ns1.ip-plus.net nserver: ns.eu.net nserver: ns.uu.net nserver: dns.princeton.edu nserver: ctina.ar nserver: ns.apnic.net remarks: Website: http://www.nic.ch/ remarks: a complete list of the ch-subdomains can be found via remarks: ftp://ftp.switch.ch/registry/CH.domains mnt-by: CH-DOMREG mnt-lower: CH-DOMREG refer: SIMPLE whois.nic.ch changed: gottsponer(a)switch.ch 19981223 source: RIPE It would be a nice project for the CENTR tech folks to check all the referred-to servers for those obvious things?! Wilfried.

1 0

RE: Deletion of German domains
by mike.norris＠heanet.ie 28 Jun '00

28 Jun '00

> > > No, this is a working agreement about technical details. It > > > is based on the community consensus that domain related > > > information (excluding reverse delegations) should be moved > > > from the RIPE Database to the respective ccTLD databases. > > > > Fair enough, but community consensus must be recorded. Was > > this consensus achieved at RIPE 36 and we're still waiting for > > the relevant minutes? > > Frankly, I don't see what the great fuss is about, Mike. No great fuss, Håvard, just a request for a reminder of the original action point leading to this operational change. Andrei has now provided this. > > I think this has been discussed in the CENTR arena, and if I'm > not mistaken there's been developed a consensus between the RIPE > NCC and the CENTR folks for the preferred way forward. The RIPE > DB's primary purpose isn't to serve as a repository for domain > objects and related person objects -- I have for a long time had > the impression that this has been rather obvious, and that a > better solution for all parties would be preferable (less work > for the CC registries to maintain the RIPE DB data, tighter > coupling to the underlying registry database, costs for running > the system where they can be accounted for, etc. etc.) Indeed, and this has been raised in the db-wg many times in the past, even in pre-CENTR days. It would make sense if other CC registries could adopt the practice of .nl, .no, .de etc when it comes to providing a database of their registered domains and ancillary data. Regards. Mike

2 1

RE: Deletion of German domains
by mike.norris＠heanet.ie 28 Jun '00

28 Jun '00

> According to the agreement between RIPE NCC and DENIC we plan Has this agreement been published? > to delete German (.de) domain objects from RIPE whois database > on June 28th. From then on, information about German domains will > be available from DENIC's whois server, whois.nic.de. While speed and efficiency are to be commended, this is rather short notice, isn't it? From the mail on 8th June, I understood that DENIC would need between one and two months after moving the domain objects before the associated person objects could be moved. Regards. Mike

8 18

RE: Deletion of German domains
by mike.norris＠heanet.ie 28 Jun '00

28 Jun '00

> >>>> According to the agreement between RIPE NCC and DENIC we plan > >>> Has this agreement been published? > >> No, this is a working agreement about technical details. It is based on > >> the community consensus that domain related information (excluding > >> reverse delegations) should be moved from the RIPE Database to the > >> respective ccTLD databases. > > Fair enough, but community consensus must be recorded. > > i am confused here. i presume the communities involved, ripe ncc and denic, > reached a consensus and one or the other would be whining if not. why > should this be a concern of the other lirs or the wg or you or me? See Andrei's reply, which points to a decision at RIPE 35 of the db-wg. So the WG has an interest, else RIPE NCC wouldn't have sent it the announcement about today's change in the first place. All I wanted was a reference to the original decision. Regards. Mike

1 0

RE: Deletion of German domains
by mike.norris＠heanet.ie 28 Jun '00

28 Jun '00

> > > According to the agreement between RIPE NCC and DENIC we plan > > > > Has this agreement been published? > > > No, this is a working agreement about technical details. It is based on > the community consensus that domain related information (excluding > reverse delegations) should be moved from the RIPE Database to the > respective ccTLD databases. Fair enough, but community consensus must be recorded. Was this consensus achieved at RIPE 36 and we're still waiting for the relevant minutes? It would be useful to have some reference document, even a draft, but this is **no reflection whatsoever** on the excellent work of RIPE and its working groups! > > The RIPE Database will still be the source for domain related > information using referral mechanism (as long as top level domain > objects point to the actual domain databases). Though it may be more > efficient to query these databases directly. > > > > to delete German (.de) domain objects from RIPE whois database > > > on June 28th. From then on, information about German domains will > > > be available from DENIC's whois server, whois.nic.de. > > > > While speed and efficiency are to be commended, this is rather short > > notice, isn't it? From the mail on 8th June, I understood that DENIC > > would need between one and two months after moving the domain objects > > before the associated person objects could be moved. > > > > You are right, we are moving only domain objects. The person objects > will remain in the RIPE Database for several months. What ever happened to the auto-referral mechanism, whereby a query about a moved object could be referred onward to the appropriate whois server? Regards. Mike

4 3

RIPE whoisd re-implementation: RIP-0.3.1beta1 software snapshot
by RIPE Database Administration 27 Jun '00

27 Jun '00

Dear All, This mail is to notify you of the further advancements in the development of the new implementation of the RIPE Database software. Today, we have freezed the source code into a new snapshot. This is mostly a bugfix snapshot. A considerable change, however, has been made in the installation procedure, i.e. the Makefile structure. It is now easier to compile and run the software. You can download this last snapshot at the following URL: ftp://ftp.ripe.net/ripe/dbase/reimp/RIP-0.3.1beta1.tar.gz You can also test the functionality of this snapshot of the RIP whois server in 2 ways: - By querying host reimp.ripe.net at port 43; you will find there a Near-Real-Time Mirror of the RIPE Database. - By using RIP Test Database. You can send test updates to this database at the address <rip-test(a)ripe.net>, and you can query this database at reimp.ripe.net port 4343. We would be very pleased if you could test the new implementation in both ways, and let us know your opinions. This release also includes a "test" bug, which can be spotted by sending a query satisfying certain conditions to the server and checking the results, which will clearly appear to be wrong. We challenge you to find this bug. The first one to catch it will be granted a wonderful prize! :-) Please send your comments and bug reports to the <db-beta(a)ripe.net> mailing list. To subscribe to this list, send a message to <majordomo(a)ripe.net> with the line: subscribe db-beta in the body of your letter. This is a moderated mailing list, so some delays in subscription are possible. If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, Filippo Portera ____________________________ RIPE Database Administration.

1 0

RE: Deletion of German domains
by Shaun O'keefe 27 Jun '00

27 Jun '00

I think you should move the domains over to DENIC but still keep them on the RIPE server untill everything is up and running fine. Shaun O'keefe, Assistant Network Administrator CITEL Technologies Ltd., http://www.citel.com/<?xml:namespace prefix = o /> shaun.okeefe(a)citel.com +44 (115) 940 5444 -----Original Message----- From: mike.norris(a)heanet.ie [ mailto:mike.norris@heanet.ie <mailto:mike.norris@heanet.ie> ] Sent: Tuesday, June 27, 2000 3:21 PM To: 'RIPE Database Administration'; db-wg(a)ripe.net; lir-wg(a)ripe.net Subject: RE: Deletion of German domains > According to the agreement between RIPE NCC and DENIC we plan Has this agreement been published? > to delete German (.de) domain objects from RIPE whois database > on June 28th. From then on, information about German domains will > be available from DENIC's whois server, whois.nic.de. While speed and efficiency are to be commended, this is rather short notice, isn't it? From the mail on 8th June, I understood that DENIC would need between one and two months after moving the domain objects before the associated person objects could be moved. Regards. Mike

1 0

Antwort: Deletion of German domains
by Jörg Bauer/Denic 27 Jun '00

27 Jun '00

On 27.06.00 11:33 RIPE Database Administration <ripe-dbm(a)ripe.net> wrote: > > > Dear Colleagues, > > According to the agreement between RIPE NCC and DENIC we plan > to delete German (.de) domain objects from RIPE whois database > on June 28th. From then on, information about German domains will > be available from DENIC's whois server, whois.nic.de. nearly correct ;-) The server name is whois.denic.de -- ----------------------------------+------------------------------------------- Joerg Bauer | eMail : Joerg.Bauer(a)denic.de DENIC eG | Fon : +49 69 272 35 180 Wiesenhuettenplatz 26 | Fax : +49 69 27235 235 D-60329 Frankfurt | ----------------------------------+-------------------------------------------

1 0

Deletion of German domains
by RIPE Database Administration 27 Jun '00

27 Jun '00

Dear Colleagues, According to the agreement between RIPE NCC and DENIC we plan to delete German (.de) domain objects from RIPE whois database on June 28th. From then on, information about German domains will be available from DENIC's whois server, whois.nic.de. Please note that you may experience some delays in processing your updates on June 28-29. We are sorry about any inconvenience this may cause. If you have any more questions, please don't hesitate to contact <ripe-dbm(a)ripe.net>. We are sorry about any inconvenience this may cause. Regards, Engin Gunduz ____________________________ RIPE Database Administration.

1 0

Flaw in PGP 5.0 key auto-generation
by RIPE Database Administration 16 Jun '00

16 Jun '00

Dear Colleagues, We are forwarding a warning about a flaw in PGP 5.0 key auto-generation. Please note that the problem appears _only_ when one auto-generates the key (using /dev/random device). If you have any questions, please don't hesitate to contact <ripe-dbm(a)ripe.net>. Regards, Engin Gunduz ____________________________ RIPE Database Administration. >CERT Advisory CA-2000-09 Flaw in PGP 5.0 Key Generation > > Original release date: May 30, 2000 > Last Revised: -- > Source: CERT/CC > > A complete revision history is at the end of this file. > >Systems Affected > > * UNIX systems having a /dev/random device running any version of > PGP 5.0, including U.S. Commercial, U.S. Freeware, and > International versions > * Keys created non-interactively on such a system > * Documents encrypted with such a key > * Signatures generated with such a key > >Overview > > Under certain circumstances, PGP v5.0 generates keys that are not > sufficiently random, which may allow an attacker to predict keys and, > hence, recover information encrypted with that key. > >I. Description > > In order to generate cryptographically secure keys, PGP (and other > products) need to use random numbers as part of the input to the key > generation process. Generating truly random numbers is a difficult > problem. PGP has traditionally solved that problem by prompting the > user to type some random characters or to move the mouse in a random > manner, measuring the time between keystrokes and using this as a > source of random data. Additionally, PGP uses a file (usually called > randseed.bin) as a source of randomness. However, PGP also provides > the ability to generate keys non-interactively (useful, for example, > if you need to generate a large number of keys simultaneously or > provide a script to generate a key). When generating keys > non-interactively, PGP needs a source of random numbers; on some > systems PGP v5.0 uses the /dev/random device to provide the required > random numbers. > > PGP v5.0, including U.S. Commercial, U.S. Freeware, and International > versions, contains a flaw in reading the information provided by > /dev/random. This is not a flaw in /dev/random but instead is the > result of a flaw in how PGP processes the information returned from > /dev/random. Thus, when a key is generated non-interactively using a > command such as > > pgpk -g <DSS or RSA> <key-length> <user-id> <timeout> <pass-phrase> > > it does not contain sufficient randomness to prevent an attacker from > guessing the key. If such a command were issued on a system with no > available randseed.bin file, then the resulting key may be > predictable. > > This problem was discovered and analyzed by Germano Caronni > <gec(a)acm.org>, and verified by Thomas Roessler <roessler(a)guug.de> and > Marcel Waldvogel <mwa(a)arl.wustl.edu>. A copy of their analysis can be > found at > > http://www.securityfocus.com/templates/ > archive.pike?list=1&msg=20000523141323.A28431(a)olymp.org > >II. Impact > > Keys produced non-interactively with PGP v5.0 on a system with > a /dev/random device may be predictable, especially those > produced in an environment without a pre-existing randseed.bin > file. > > Documents encrypted with a vulnerable key may recoverable by an > attacker. Additionally, an attacker may be able to forge a > digital signature corresponding to a vulnerable key. > > Signatures produced using a vulnerable key, including > signatures in certificates, may be untrustworthy. > >III. Solution > > If your PGP key was generated non-interactively using any > version of PGP v5.0 on a system with a /dev/random device, you > may wish to revoke it. > > Documents encrypted with a predictable key may need to be > re-encrypted with a non-vulnerable key, if your particular > circumstances warrant it; that is, if the information still > needs to be encrypted. > > You may need to resign documents signed with a vulnerable key > if your circumstances warrant it. > >Appendix A Vendor Information > >Network Associates > > Network Associates Security Advisory > Date: May 30, 2000 > Author: PGP Engineering > Background: > > A security issue has been discovered in the following PGP > products: > > PGP 5.0 for Linux, US Commercial and Freeware editions > > PGP 5.0 for Linux, Source code book (basis for PGP 5.0i for Linux) > > The following PGP products are NOT affected by this issue: > > + PGP 1.x products > + PGP 2.x products > + PGP 4.x products > + All other PGP 5.x products > + PGP 6.x products > + PGP 7.x products > > Synopsis: > > During a recent review of our published PGP 5.0 for Linux > source code, researchers discovered that under specific, rare > circumstances PGP 5.0 for Linux will generate weak, predictable > public/private keypairs. These keys can only be created under > the following circumstances: > > + Keys are generated using PGP's command line option for > unattended batch key generation, with no user interaction for > entropy (random data) collection > + No keys were generated interactively on this system > previously (e.g., a PGP random seed file is not present on > this system prior to unattended batch key generation) > + PGP is able to access the UNIX /dev/random service to gather > entropy during unattended batch key generation > > PGP 5.0 for Linux does not process the data read from > /dev/random appropriately, and therefore does not gather enough > entropy required to generate strong public/private keypairs. > This issue affects both RSA and Diffie-Hellman public/private > keypairs, regardless of keysize. Network Associates has > verified that this issue does not exist in any other version of > PGP. > > Solution: > > Users who generated keys in the manner described above are > strongly urged to do the following: > > + Revoke and no longer use keys suspected to have this problem > + Generate new public/private keypairs with entropy collected > from users' typing and/or mouse movements > + Re-encrypt any data with the newly generated keypairs that is > currently encrypted with keys suspected to have this problem > + Re-sign any data with the newly generated keypairs, if > required > > Users are also urged to upgrade to the latest releases of PGP, > as PGP 5.0 products have not been officially supported by > Network Associates since early 1999, or distributed by Network > Associates since June 1998. > > Additional Information: > > US commercial and freeware versions of PGP 5.0 for Linux were > released in September 1997 by PGP, Inc., a company founded by > Phil Zimmermann. Source code for the PGP 5.0 product family was > published in September 1997. PGP, Inc. was acquired by Network > Associates in December 1997. > > Acknowledgements: > > PGP appreciates the efforts of Germano Caronni, Thomas Roessler > and Marcel Waldvogel in identifying this issue and bringing it > to our attention. > > A pgp signed version of this statement is also available at > > http://www.cert.org/advisories/CA-2000-09/pgp.asc > __________________________________________________________ > > The CERT Coordination Center thanks Germano Caronni, Thomas > Roessler, and Marcel Waldvogel for initially discovering and > reporting this vulnerability, and for their help in developing > this advisory. Additionally we thank Brett Thomas for his > insights. > __________________________________________________________ > > Shawn Hernan was the primary author of this document. > _______________________________________________________________ > > This document is available from: > http://www.cert.org/advisories/CA-2000-09.html > _______________________________________________________________ > >CERT/CC Contact Information > > Email: cert(a)cert.org > Phone: +1 412-268-7090 (24-hour hotline) > Fax: +1 412-268-6989 > Postal address: > CERT Coordination Center > Software Engineering Institute > Carnegie Mellon University > Pittsburgh PA 15213-3890 > U.S.A. > > CERT personnel answer the hotline 08:00-20:00 EST(GMT-5) / > EDT(GMT-4) Monday through Friday; they are on call for > emergencies during other hours, on U.S. holidays, and on > weekends. > >Using encryption > > We strongly urge you to encrypt sensitive information sent by > email. Our public PGP key is available from > > http://www.cert.org/CERT_PGP.key > > If you prefer to use DES, please call the CERT hotline for more > information. > >Getting security information > > CERT publications and other security information are available > from our web site > > http://www.cert.org/ > > To be added to our mailing list for advisories and bulletins, > send email to cert-advisory-request(a)cert.org and include > SUBSCRIBE your-email-address in the subject of your message. > > * "CERT" and "CERT Coordination Center" are registered in the > U.S. Patent and Trademark Office. > _______________________________________________________________ > > NO WARRANTY > Any material furnished by Carnegie Mellon University and the > Software Engineering Institute is furnished on an "as is" > basis. Carnegie Mellon University makes no warranties of any > kind, either expressed or implied as to any matter including, > but not limited to, warranty of fitness for a particular > purpose or merchantability, exclusivity or results obtained > from use of the material. Carnegie Mellon University does not > make any warranty of any kind with respect to freedom from > patent, trademark, or copyright infringement. > __________________________________________________________ > > Conditions for use, disclaimers, and sponsorship information > > Copyright 2000 Carnegie Mellon University. > > Revision History > >May 30, 2000: initial release

1 0

First steps in moving *.de domain objects
by Andrei Robachevsky 08 Jun '00

08 Jun '00

Dear Colleagues, As part of the process of moving *.de domains from the RIPE Database today, 8 July, we started updating unmaintained person objects referenced from German domain objects. Currently there are about 100,000 such objects in the RIPE database and all of them will be protected by DENIC-P maintainer. The Database performance should not be affected. This step is essential because the setup of DENIC database is planned to be done in two phases: first moving domain objects and then moving/copying person ones. The time needed between the two phases is 1-2 months as estimated by DENIC. In such circumstances after the first phase is completed person objects referenced only from *.de domains may be occasionally deleted if not protected by maintainer. Best regards, Andrei Robachevsky Database Group Manager RIPE NCC

1 0

Top 100 Maintainers List 20000605
by RIPE Database Administration 05 Jun '00

05 Jun '00

1 0

Top 100 Maintainers List 20000524
by RIPE Database Administration 24 May '00

24 May '00

1 0

Delay in processing updates
by RIPE Database Administration 24 May '00

24 May '00

Dear Colleagues, We have currenly a larger update queue than usual. We expect that updates in the queue will be processed in 4-5 hours. If you have not yet received an acknowledgement to your updates, there is no need to send them again. All updates received by auto-dbm(a)ripe.net have been queued. We are sorry about the inconvenience. If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, Engin Gunduz ____________________________ RIPE Database Administration.

1 0

RIPE Database working normally again.
by RIPE Database Administration 18 May '00

18 May '00

Dear Colleagues, Thank you for your patience. The RIPE Database is working normally again. Updates are being processed and queries are being answered by the primary server. If you have any questions, please contact <ripe-dbm(a)ripe.net>. Daniele Arena ------------- RIPE NCC

1 0

raw minutes for RIPE35 DB-WG
by Wilfried Woeber, UniVie/ACOnet 18 May '00

18 May '00

Dear DB-WG, attached pleae find a copy of the raw notes as taken by the Scribe. Many thanks to Engin for compiling the notes and sending them shortly after the meeting. The fact that they are still in raw format is exclusively my fault. As I've received offers for help this situation should improve... A more comprehensive version could be posted to the web-site. Please refer to the draft agenda and to tomorrow's wg meeting for more details. Thank you. Wilfried. ______________________________________________________________________ Date: Thu, 2 Mar 2000 11:11:38 +0100 (CET) From: Engin Gunduz <engin(a)ripe.net> To: woeber(a)cc.univie.ac.at Subject: Draft minutes of RIPE35 DB WG Hi Wilfried, I'm attaching the draft minutes for RIPE35 DB WG. I couldn't pick up the names of a couple of participants, unfortunately. Also, since they are not on the web site, the URLs of presentations are not complete yet. Regards, -engin Engin Gunduz RIPE NCC DB Group -=-=-=-=-=-=-=-=-=-=-=- RIPE 35 Database Working Group Thursday, Feb 24th Agenda: Slot#1 ,9:00 A. Administrative Stuff (Wilfried Woeber, Chair) B. RIPE DB, operational update (NCC: AMRM, 20 mins) C. A short review on the maintainer mechanism - are there any security concerns? D. A "smarter" whois client E. (tentatively) Is there an interest to register CERT/IRT-related info? Slot#1, 11:00 F. Status of reimplementation project (NCC, JLSD 20mins) G. Transition to RIPE DB v3.0 and transition TF (JLSD & WW, 15 mins) H. Do we need/want a DB review/re-structuring TF - future topics of interest - I/O with other WGs - Logistics Y. Input from other WGs Z. AOB ------------------- Chair: Wilfried Woeber Scribe: Engin Gunduz Participants: 65 A. Administrative Stuff The proposed agenda agreed with an addition of item "D". Scribe appointed, Engin Gunduz. B. RIPE DB, operational update (NCC: AMRM) (presentation is available at http://www.ripe.net/ripe/meetings/archive/ripe-35/presentations/...... ) AMRM provided an update on: - Performance - Software status - Reimplementation - Other RIPE DB services - ripe-dbm mailbox - Operational issues C. A short review on the maintainer mechanism WW: 1. There was a useful presentation by Olaf (Kolkman) about PGP. DB is an example for PGP being used with weaker authorisation methods. Has anybody used PGP? (4 people raised their hands). 2. CENTR activity. We've been talking about removing domain objects from whois db. Do you have any timing for this? AMRM: This is a political question, please ask this to Joao. D. A "smarter" whois client WW: Technical framework: NCC has offered mechanism to referral mechanism. This is working nicely. The central whois server has to act as a proxy. But, whois client needs to know whois.ripe.net. Now, we can have a client who tries to find a TXT field from DNS, so that it would know which whois server to query. We may ask NCC to implement this. What do you think? Should NCC spend resources for this? We will chase this issue. Peter Koch: There was some intelligence in one of the old RIPE whois clients which enabled it to query whois-<tld>.ripe.net. AMRM: We don't know about this. E. Is there an interest to register CERT/IRT-related info? WW: Background: It's becoming more frequent that people are abusing network resources. Now, how would you find out whom to contact in such cases? Proposal: We can have a mechanism to point the user to a proper point. Would anybody be volunteer for a blueprint? AMRM: In roles, we have "trouble" attribute. This is for such cases. But I think you mean a more sophisticated thing. Former chair of FIRST: You must be in FIRST organisation. (Break) Slot #2: (11:00) F. Status of reimplementation project (NCC, JLSD) (presentation is available at http://www.ripe.net/ripe/meetings/archive/ripe-35/presentations/...... ) Questions: Jake Khoun: There are three-five groups trying to implement RPSL. Isn't it possible to create a subgroup to coordinate activities? JLSD: We tried to bind people together. WW: This is a good input. We can found (a top level, not local) an open forum. RIPE NCC employees can follow ARIN & APNIC mailing lists. WW: More than 50% of the objects in the RIPE whois DB are not exactly related to RIPE, being an IP registry. JLSD: It will be hard to find a solution to this. Domains are growing extremely fast. We are trying to find a solution. We have talked to DENIC & Norwegian domain registry, they are going to move their objects. They expect to get their domain objects in approximately 3 weeks, and person objects in 2-3 months. We are happy to help them. So, I just ask for coordination here. If you want to delete your domain objects, please let us know. We have referral mechanism, we can use it. Jake Khoun: I had a proposal: The behaviour of whois server could be to search all sources, instead of only RIPE source, and, to stop at the first match. David Kessens: I think the main reason for current default behaviour was to save computer resources. But I don't think that this is the case anymore. We must be able to change the default behaviour. But I don't like the idea of stopping at the first match. G. Transition to RIPE DB v3.0 and transition TF (JLSD & WW) WW: Who is in general think that they will be hit by new interfaces? (Three persons raised their hands, Jake Khoun, Nigel Titley, and one more person). WW: So, could we count on you to form a Transition Task Force? JLSD: We can use db-beta list for this. WW: We will get back to you about this before May. JLSD: Agreed. WW: Another point: There was a bug report on security of RIPE DB software. JLSD: The mntner "feature" was already there. Finally the community say that it is a bug. But at this point of time, there is no point in fixing this in the old DB. A participant: Is it difficult to fix this? JLSD: The question is, should we divert the resourses to it or not. Jake Khoun: The actual fix would be to put proper mntners to objects. WW: There was a report on some unauhorised changes to objects. So, nobody must have unprotected objects in the DB. Now, should we tell the users that they must use at least CRYPT-PW, but not MAIL-FROM? Dmitry Morozovsky: RIPN does not put unprotected objects in their DB. Can RIPE do that with the reimplementation? WW: We must have the social engineering first, I think, e.g., putting a text in ACK messages which says that the MAIL-FROM authorisation is not good enough. AMRM: Some users just don't read ACK or notification messages. Jake Khoun: There should be enough emphasis on using CRYPT-PW & PGP instead of MAIL-FROM. Action Point: on NCC to draft a proposal. H. Do we need/want a DB review/re-structuring TF WW: I'm looking for someone to help me documenting our achievements. I don't have time to do proper documentation. Please any volunteer find me in breaks. WW: What should be the future of the DB WG? I'd like to get some input on what should we have as a charter? What are we supposed to do. Please think about your personal priorities, and provide input. Apologies for no minutes. Y. Input from other WGs No input. Z. AOB There wasn't any other business. Chair thanks to participants and closes RIPE35 DB WG meeting. -=-=-=-=-=-=-=-=-=-=-=-

4 3

draft agenda for DB-WG meeting, RIPE 36, Budapeat
by Wilfried Woeber, UniVie/ACOnet 17 May '00

17 May '00

Proposed Agenda for the Database Working Group Meeting RIPE-36, May 2000, Budapest, HU 1. Draft Thursday, May 18, 2000 at 10:30 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A. Administrative stuff (Wilfried Woeber, chair) . scribe . list of participants . agenda bashing . raw scribe notes distributed . help offered by - Nigel Titley, - Ulf Kieber chair asks for approval Actions: . to install the RE-Impl.-TF . "move weak authentication to historical" (ed. comm.) B. RIPE DB, operational update (RIPE NCC) C. DB Software Re-Implementation (RIPE NCC) D. Report on Certification Authority activities (APNIC) E. Activity Plan for next year! . . Y. Input from other WGs - Routing: native multicast routing (Jan Novak)? Z. AOB: Common XML Registration Template (Joel Rowbottom) mail-to: proposal with token and confirmation (Michael C. Battilana) A brief update on CERT/IRT-related issues (WW144/Jaques Schuurman) a more clever whois and using DNS for "remote control" (WW144) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WW, 17-MAY-2000 20:34:22

1 0

RE: Thoughts about authentication schemes
by Wilfried Woeber, UniVie/ACOnet 17 May '00

17 May '00

Dear Michael, Thank you very much for the suggestion and the write-up on what the use of the proposed mechanisms c/would be. First of all, cc:ing the WG list is to distribute your comments, as they are very appropriate and useful for the on-going discussions on improving security in the registry operations. Secondly I'd like to (briefly) address a couple of comments: The WG has already been chartered to work on a more up-to-date document as to which security mechanisms should be recommended. The common understanding is that anything weaker than digital signatures should be strongly dicouraged, exactly for the reasons you were giving. Still has to find it's way into a document. All the other mechanism should be phased out in due time - at least for any objectof "value". The other aspect, as to *which* particular mechanism or product should be used, is up for discussion and for consensus amongst the users of the RIPE DataBase. Initially, the recommendation from the TaskFore on DB Security was to go for PGP as the *first* mechanism to implement. At the same time we understood that PGP w/sh/could not be the *only* mechanism in the long run. Meanwhile the DB software re-implementation is close to being completed, GNU Privacy Guard has become available, and I'm sure things like S/MIME should be looked at. Actually, this might be a reason to revive the TF-SEC later this year? Please continue to participate in this discussion, and whenever you can, to pop in during one of the DB working group meetings. Regards, Wilfried. ______________________________________________________________________ From: mcb(a)cloanto.com To: "'Wilfried Woeber'" <Woeber(a)CC.UniVie.ac.at> Subject: Thoughts about authentication schemes Date: Fri, 12 May 2000 07:41:44 -0700 Hello, I just had an exchange of ideas with Marek Bukowy of RIPE Database Administration, and he suggested that I submit this to your attention before the RIPE 36 meeting. Basically, I was setting up CLOANTO-MNT, and looking at the authentication options I somehow wondered why there isn't something like a "MAIL-TO". As the recent case of fraud suffered by Network Solutions shows, MAIL-FROM can too easily be circumvented. This week even our company in Italy had to file criminal charges against an entity who forged email headers, using one of our domain names. This was a case of "spamming", but it could just as easily have been an episode of MAIL-FROM fraud. So I looked at CRYPT-PW, and searching for a tool to generate the encrypted password I quickly found out that an 8-character password, as is used by RIPE, can be un-encrypted in a matter of days, if not hours. Now, as documents like ripe-157 express (e.g. "It is very difficult to keep the information confidential and thus the RIPE NCC cannot take this responsibility."), RIPE is concerned about both security and responsibilities, and here we have a case where it is known that two authentication schemes are not secure, and thus somebody might even object that, given today's standards and knowledge, maybe their status of being qualified to serve as "authentication" could be challenged. True, there now is PGP, which IMHO is technically uncompromising for this purpose. In theory it has legal limitations in a few countries, but not any I am aware of in the RIPE area. PGP however can be pretty... complex to set up compared to an email-only authentication scheme. Not that I see PGP as being unreasonably complex, but apparently, if people still prefer MAIL-FROM or CRYPT-PW, they must have their practical reasons for doing so. PGP also expresses a "political" choice in a field where other "official" standards would tend towards S/MIME, X.509, etc. For this reason I would like to go back, with my consideration, to a possibly new, simple, yet more secure authentication method (compared to MAIL-FROM) which does not use any encryption, and which can therefore be quickly used with any email client. As such, maybe it could be one choice more to offer, and in the long term it could maybe become part of a more robust set of minimum standards. The way I thought of "MAIL-TO" is basically like MAIL-FROM, but the server (e.g. you), after receiving a request from one of the authorized "MAIL-TO" addresses, would send back to the same address a "magic number" (or alphanumeric data) to the sender, who would have to reply (quoting this data anywhere in the email body, even possibly with "> " etc. at the beginning of each line), and only after the reply the request would be accepted. This data would have both a unique part (no risk of duplicates) and a pseudo-random one (no practical way to guess it). In this way, "MAIL-TO" would formally verify that the sender has access to the given email address, in such a way as has been adopted in everyday practice for years by companies such as VeriSign and Thawte for the distribution of email and web certificates. It is true that a possible "MAIL-TO" scheme would be open to sniffing, but MAIL-FROM and CRYPT-PW also are, and the data which is transmitted is not sensitive by definition, as RIPE itself says it prefers not to take responsibility for securing sensitive data, and the data usually ends up in a whois database anyway. Also, "MAIL-TO" would indeed require one more step than "MAIL-FROM". This is in my opinion the small price to pay if one prefers not to use full encryption or digital signing. Yes, I think it would be only one more step, because in my experience, where MAIL-FROM is implemented, two or three steps (not one) are already required, because the second part of the system involves that a preset address receives a notification of the change request. This is not subject to confirmation (as would be in "MAIL-TO"), but it is nevertheless a second step, and it requires attention and readiness for a possible third step ("CANCEL" action) in case an abuse is detected. So on one hand we have one step more (or zero steps more in case of abuse), but on the other hand we get peace of mind. The reply mechanism could even be implemented in an automatic way on the side of the data submitter. Well, this now got a bit more lengthy than I intended it to be, sorry about that! It's just that I felt the need for such an option, and I would not like to see what happened to Network Solutions also happen to you, or to one of the national NICs who adopt your guidelines, especially knowing that forging email headers happens everyday, and that it has already happened in a major case involving a major registration authority. Thanks for caring, and I wish you a nice time in Budapest! Regards, Michael C. Battilana --------------------------------------------------------------------------------

1 0

Problems RIPE Whois Service.
by RIPE Database Administration 17 May '00

17 May '00

Dear Colleagues, (Apologies if you receive this message more than once). Earlier this evening, the main RIPE Database server crashed. Your updates are not being processed at this time, but they are being queued; there is no need to send them again. Queries are being processed by a backup server; thus, the response time may be longer than usual. We are aware of the inconvience that this causes you and we are working to restore the service as quickly as possible. We shall keep you informed. If you have any questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ------------- RIPE NCC

1 0

ANNOUNCEMENT: Beta 0.1 of asused-public released
by John Crain 15 May '00

15 May '00

Dear Colleagues, We, the RIPE NCC, are pleased to announced the release of the beta version of asused-public. This is a tool to summarise address space that is registered in the RIPE database. For a given list of allocations the software prints various information concerning the allocations and the assignments they contain. the software "asused-public" is based on one the NCC's internal tools. It has been revised for public release in a form that does not make use of any customer confidential information. The software which uses several perl modules, these are included, is stored in the following file: ftp://ftp.ripe.net/tools/asused-public.0.1.tar.gz We are keen to receive your feedback on the beta release. Please address your comments and/or suggestions to our Software Manager, Maldwyn Morris <Maldwyn.Morris(a)ripe.net> Yours, John LeRoy Crain Head of Internal Services RIPE NCC

2 1

domreg tools
by Randy Bush 15 May '00

15 May '00

does anyone have forms and scripts to automate domain registration? what i mean by that is o a form for the registrant to fill out and email (and/or web page) i have appended what i currently use o a script to - extract person, and domain info and create ripe format objects - create nic handles if needed - extract server info and create dns database entry texts o etc. i have the form (appended) and some elisp and scripting to make a dns file entry. but now i want to go the whois path. all help appreciated. randy --- PLEASE DO NOT ALTER THIS APPLICATION IN ANY WAY. Send your GN registration to randy(a)psg.com. See attached detailed instructions. - - - - - - - - - - - - - - c u t h e r e - - - - - - - - - - - - - - 0. KE DOMAIN TEMPLATE....: 1.30 99.12.05 1. REGISTRATION TYPE * (N)ew (M)odify (D)elete..: 2. * FULLY-QUALIFIED DOMAIN NAME: 3. ORGANIZATION INFORMATION 3a.* Organization Name.....: 3b.* Address Line 1........: 3b.* Address Line 2........: 3c.* City..................: 3d.* Postal Code...........: 3e.* Country...............: 4. * DESCRIPTION OF ORG/DOMAIN: 5. Date Operational......: 6. ADMINISTRATIVE CONTACT OF ORG/DOMAIN 6a. NIChandle (if known)..: 6b.* Whole Name............: 6c. Organization Name.....: 6d.* Address Line 1........: 6d. Address Line 2........: 6e.* City..................: 6f.* Postal Code...........: 6g.* Country...............: 6h.* Voice Phone...........: 6i.* Electronic Mailbox....: 7. TECHNICAL AND ZONE CONTACT 7a. NIChandle (if known)..: 7b.* Whole Name............: 7c. Organization Name.....: 7d.* Address Line 1........: 7d. Address Line 2........: 7e.* City..................: 7f.* Postal Code...........: 7g.* Country...............: 7h.* Voice Phone...........: 7i.* Electronic Mailbox....: 7j.* Registration Mailbox..: 7k. Fax Number............: FILL OUT QUESTION 8 AND 9 FOR DELEGATIONS ONLY (i.e those organizations running nameservers for a branch of the KE Domain namespace, 8. PRIMARY SERVER: HOSTNAME, NETADDRESS 8j.* Hostname..............: 8k.* IP Address............: 9. SECONDARY SERVER: HOSTNAME, NETADDRESS 9a.* Hostname..............: 9b.* IP Address............: FILL OUT QUESTION 10 FOR DIRECT REGISTRATIONS IP HOSTS (if you answered 8 & 9, do not answer 10, 11, and 12) 10. RESOURCE RECORDS (RRs) FOR IP INTERNET HOSTS 10a.* IP ADDRESS (required).: 10b. HARDWARE .............: 10c. OPERATING SYS ........: 10d.* MX ...................: It is your responsibility to see that an IN-ADDR pointer record is entered in the DNS database. Contact the administrator of the IP network your host is on to have this done. FILL OUT QUESTIONS 11 AND 12 FOR NON-IP HOSTS (such as UUCP) 11. FORWARDING HOST INFORMATION 11a.* Forwarding Host.......: 11b.* Contact Name (req)....: 11c.* Contact Email (req)...: 12. RESOURCE RECORDS (RRs) FOR NON-IP HOSTS (UUCP) 12a. DOMAIN NAME ..........: 12b. HARDWARE .............: 12c. OPERATING SYS ........: 12d.* MX (required).........: < and all sorts of instructions > --- and my elisp/perl hacks produce, for example ; T F Nyammo ; Kenya School of Professional Studies ; P.O.Box 60550 ; Nairobi ; 60550 ; Kenya ; 750255-58 ; ftnyammo(a)swiftkenya.com ; FD1304 ; DNS-admin FutureQuest ; FutureQuest ; PO Box 420820 ; Kissimmee, FL ; 34742-0820 ; United States ; dns-admin(a)FutureQuest.net ; ksps.ac.ke. NS ns1.FutureQuest.net. NS ns1.granitecanyon.com. ;----------------------------------------------------------------------- dig +norec ksps.ac.ke. @ns1.FutureQuest.net. ns dig +norec ksps.ac.ke. @ns1.granitecanyon.com. ns the two dig commands are so i can cut and past to check for properly configured servers. -30-

2 1

ke
by Randy Bush 14 May '00

14 May '00

-----BEGIN PGP SIGNED MESSAGE----- domain: KE descr: Kenya ccTLD admin-c: SJO2 tech-c: RB366 zone-c: RB366 refer: RIPE whois.rg.net mnt-by: MAINT-RGNET changed: randy(a)psg.com 20000513 source: RIPE -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQCVAwUBOR4Yd/vCP42xMxQ5AQEPLwP+L1h/+Ht9e5RphVXn6yqdhs8N//xjXZQU Hic1jbknbVqtpFzmBapy61EX3G1u+viTJmIRODaCK2z0Sik07g4z0At4bmMpt+gD /Nw4cNsPTA+DhbQt3/k06a0LO8MmacOM3ZcvFRsdmncPs+zQ9brrXwWcL6OfzY7s xmUNKBTJuNs= =YKxX -----END PGP SIGNATURE-----

1 1

New beta release of the RIPE Database Reimplementation software
by RIPE Database Administration 12 May '00

12 May '00

Dear All, This mail is to notify you of the further progress in the development of the new implementation of the RIPE Database software. The software has a temporary name of RIP, which stands for "Re-Implementation Project". Today, we have made a new prototype of the source code. There have been many changes since the last prototype: most notably, the update functionality has been integrated to the server. You can download this last prototype at the following URL: ftp://ftp.ripe.net/ripe/dbase/reimp/RIP-0.3.0beta2.tar.gz You can also test the functionality of this prototype of the RIP whois server in 2 ways: - By querying the host reimp.ripe.net at port 43; you will find there a Near-Real-Time Mirror in RPSL format of the live RIPE Database. - By using the RIP Test Database. You can send test updates to this database at the address <auto-rip(a)ripe.net>, and you can query this database at reimp.ripe.net port 4343. Please note the following things when sending updates to the RIP Test DB: - you will get very simple acknowledgements; - mntner, as-block and aut-num objects cannot be created yet; - no notifications are being sent to the "notify" addresses. We would be very pleased if you could test the new implementation in both ways, and let us know your opinions. Please let us also know of any bugs you can find. Please send your comments to the <db-beta(a)ripe.net> mailing list. To subscribe to this list, send a message to <majordomo(a)ripe.net> with the line: subscribe db-beta in the body of your letter. This is a moderated mailing list so some delays in subscription are possible. If you have any more questions, please don't hesitate to contact <ripe-dbm(a)ripe.net>. Regards, Marek Bukowy ____________________________ RIPE Database Administration.

1 0