- db-wg - mailman.ripe.net

New Draft Document announcement
by RIPE NCC WebMaster 29 Apr '03

29 Apr '03

Dear Colleagues, The RIPE NCC has prepared a draft document titled "Improved Secure Communication System for RIPE NCC Members": http://www.ripe.net/ripe/draft-documents/pki-20030429.html Abstract There is a need for secure communication between the RIPE NCC and its members. This document presents an overview of the current communication system, and a new approach based on X.509 PKI (Public Key Infrastructure) technology and standards that will make interaction with the services provided by the RIPE NCC to its members more convenient and secure. Finally, the phases necessary to implement the system are described. The idea behind publishing this as a draft document is to give RIPE NCC members time to read it and provide feedback. If the LIRs agree with the ideas presented, then it will become a RIPE document and act as a basis for the project. The draft document can be discussed on the LIR Working Group, <lir-wg(a)ripe.net>, or you can send comments to <pki-suggestions(a)ripe.net>. Best regards, -- Shane Kerr RIPE NCC

1 0

Call for agenda items for DB-WG session in BCN
by Wilfried Woeber, UniVie/ACOnet 26 Apr '03

26 Apr '03

Dear DB-WG! The date for the next RIPE meeting in Barcelona is approaching and I am supposed to submit the draft agenda for the DB-WG meeting in Barcelona. If you want to have a topic on the agenda, please speak up - either on the list or to my personal mailbox. I hope to see many of you in Barcelona! Wilfried. _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

Deprecating auth=NONE
by Hank Nussbacher 24 Apr '03

24 Apr '03

Back in March 2002 we started to deprecate auth=MAIL-FROM. In August we finished it: http://www.ripe.net/ripencc/pub-services/db/mailfrom.html We did not do the same for auth=NONE and the RIPE announcement stated: "Though NONE "auth" scheme is even weaker it is not supposed to be consciously used for object protection, but rather as notification facility. Therefore NONE "auth" scheme is outside the scope of this proposal." It has come lately to the attention in the Internet security realm that spammers as well as crackers are hijacking IP address space. One easy way to "steal" IP address space is via those that have auth=NONE on their objects. Go to: http://www.ripe.net/db/whois-free.html select ALL and type in the search bar "auth: none". The results of those that can have their IPs easily hijacked is, how shall I say this, enormous. Luckily the RIPE search form is limited to 100 hits. Just as an example and not to pick on C&W but: aut-num: AS13186 as-name: UNSPECIFIED descr: C&W SA Autonomous System descr: Alcalde Barnils 64-68 descr: Parque Empresarial Sant Joan descr: 08190 Sant Cugat del Valles descr: BARCELONA import: from AS3352 action pref=100; accept ANY import: from AS12541 action pref=100; accept ANY import: from AS3561 action pref=100; accept ANY import: from AS16091 action pref=100; accept AS16091 export: to AS3352 announce AS13186 AS16091 export: to AS12541 announce AS13186 AS16091 export: to AS3561 announce AS13186 AS16091 export: to AS16091 announce ANY default: to AS12541 action pref=100; networks ANY admin-c: RV4415-RIPE tech-c: XL5-RIPE remarks: AS3352 -> anvazque@obscured-domain remarks: AS12541 ->graham.cole@obscured-domain mnt-by: AS13186-MNT mntner: AS13186-MNT descr: Cable and Wireless SA admin-c: RV4415-RIPE tech-c: XL5-RIPE upd-to: d12@obscured-domain auth: NONE mnt-by: AS13186-MNT referral-by: RIPE-DBM-MNT route: 212.66.160.0/19 descr: Intercom Servicios Telematicos Avanzados, S.A. origin: AS13186 notify: xlario@obscured-domain mnt-by: AS13186-MNT I could right now remove the route entry for 212.66.160.0/19 or change it to some other origin and thereby hijack the entry. All those that use auto-build tools based on the info in RIPE would allow me to announce the /19 and not C&W in Spain. Just an example. There are thousands. RIPE NCC won't deprecate auth=NONE without us telling them to do it. Why would we not want this? -Hank

2 1

v6wpd release announcement
by DB Role Account 24 Apr '03

24 Apr '03

[apologies for duplicate messages] Dear Colleagues, We are happy to announce the IPv6 Whois Proxy Daemon source code release. The release contains the software for proxying a RIPE Whois server on an IPv6 network. It contains the facility of mapping individual IPv6 addresses to RFC1918 IPv4 addresses, in order to ensure proper access list controls. The software is available at ftp://ftp.ripe.net/ripe/dbase/software/v6wpd-1.0.0.tar.gz Please contact dbtools(a)ripe.net for any comments. Best regards, -- Can Bican DB Group RIPE NCC

1 0

Improvements to database update software
by DB-News 23 Apr '03

23 Apr '03

[apologies for duplicate messages] Dear Colleagues, The Database Group at the RIPE NCC has been working on restructuring the dbupdate program. This is the part of the RIPE Whois server that processes update requests from users. The main goal has been to improve the acknowledgement messages that users receive from the RIPE Whois Database and provide clearer error reporting and authorisation information. We have also been able to make the software easier to maintain and modify. This will reduce the time spent fixing bugs and adding new features. Details may be found here: http://www.ripe.net/db/dbupdate/ A page further explaining the new acknowledgements can be found here: http://www.ripe.net/db/dbupdate/acknowledgments.html The new dbupdate messages have a different format. Therefore a phased approach to introducing the new server has been taken. For a period we will use the new dbupdate in parallel with the old one. This will allow people using automated tools time to update their software. PRE-MIGRATION Before the new dbupdate was available. auto-dbm-old(a)ripe.net DOES NOT EXIST auto-dbm(a)ripe.net --> old dbupdate auto-dbm-new(a)ripe.net DOES NOT EXIST DAY-X, Wednesday, 23 April, 2003 The new dbupdate is available but must be requested specifically. auto-dbm-old(a)ripe.net --> old dbupdate auto-dbm(a)ripe.net --> old dbupdate auto-dbm-new(a)ripe.net --> new dbupdate DAY-Y, Wednesday, 7 May, 2003 The new dbupdate is the default but the old dbupdate may be requested specifically. auto-dbm-old(a)ripe.net --> old dbupdate auto-dbm(a)ripe.net --> new dbupdate auto-dbm-new(a)ripe.net --> new dbupdate DAY-Z (POST-MIGRATION), Wednesday, 4 June, 2003 The old dbupdate is no longer available. auto-dbm-old(a)ripe.net DOES NOT EXIST auto-dbm(a)ripe.net --> new dbupdate auto-dbm-new(a)ripe.net DOES NOT EXIST Best regards, -- Shane Kerr Database Group RIPE NCC

1 0

announcement of unreferenced person cleanup mechanism
by RIPE Database Manager 16 Apr '03

16 Apr '03

[apologies for duplicate messages] Introduction ------------ The primary function of the person records in the RIPE Whois Database is to document the contact people for IP address space, Autonomous System Numbers, or routing-related records. While all the data in the RIPE Database can be viewed publicly, unnecessary public dispersal of the information may cause infringement privacy rights of individuals. Periodic automatic deletion of person objects that are not referenced as a contact will help to reduce the amount of private data and free the resources consumed by them. This cleanup was discussed on the Database Working Group mailing list, and previously presented as part of the development plans. More information can be found at: http://www.ripe.net/ripe/mail-archives/db-wg/2002/msg00096.html Clean-up Process ---------------- The proposed operation of periodically removing unreferenced person objects will consist of three steps: 1. Periodically counting the references to person objects. 2. Warning the owners of objects by e-mail if they are unreferenced for more than 60 days. 3. Deleting the object automatically if it is still unreferenced 30 days after the warning. The warning will be sent to the e-mail addresses in the "mnt- by:" or the "e-mail:" attributes of person objects. - If the person object is maintained, each maintainer will be notified as follows: - If there are "mnt-nfy:" attributes, the e-mail addresses listed there will be mailed. - Or, the e-mail addresses in the "e-mail:" fields of the "admin-c:" and "tech-c:" entries of the maintainers will be mailed. - If the person object is not maintained, and there are "e-mail:" attributes in the object, those e-mail addresses will be mailed. Due to the initial high amount of unreferenced person objects, the time intervals mentioned above will not be observed for all person objects. In order to eliminate possible service outages, a limited amount of warnings will be mailed and a limited amount of person objects will be deleted every day. Timeline -------- On Tuesday, 29 April, 2003, the first e-mails will be sent notifying the appropriate parties about person objects that have been unreferenced for more than 60 days. The first deletions will occur 30 days later, on Thursday, 29 May, 2003. The process will be an on-going service, and objects that become and remain unreferenced will be treated in the same manner in the future. -- Can Bican DB Group RIPE NCC

1 0

Deprecating auth=NONE
by Hank Nussbacher 15 Apr '03

15 Apr '03

Back in March 2002 we started to deprecate auth=MAIL-FROM. In August we finished it: http://www.ripe.net/ripencc/pub-services/db/mailfrom.html We did not do the same for auth=NONE and the RIPE announcement stated: "Though NONE "auth" scheme is even weaker it is not supposed to be consciously used for object protection, but rather as notification facility. Therefore NONE "auth" scheme is outside the scope of this proposal." It has come lately to the attention in the Internet security realm that spammers as well as crackers are hijacking IP address space. One easy way to "steal" IP address space is via those that have auth=NONE on their objects. Go to: http://www.ripe.net/db/whois-free.html select ALL and type in the search bar "auth: none". The results of those that can have their IPs easily hijacked is, how shall I say this, enormous. Luckily the RIPE search form is limited to 100 hits. Just as an example and not to pick on C&W but: aut-num: AS13186 as-name: UNSPECIFIED descr: C&W SA Autonomous System descr: Alcalde Barnils 64-68 descr: Parque Empresarial Sant Joan descr: 08190 Sant Cugat del Valles descr: BARCELONA import: from AS3352 action pref=100; accept ANY import: from AS12541 action pref=100; accept ANY import: from AS3561 action pref=100; accept ANY import: from AS16091 action pref=100; accept AS16091 export: to AS3352 announce AS13186 AS16091 export: to AS12541 announce AS13186 AS16091 export: to AS3561 announce AS13186 AS16091 export: to AS16091 announce ANY default: to AS12541 action pref=100; networks ANY admin-c: RV4415-RIPE tech-c: XL5-RIPE remarks: AS3352 -> anvazque@obscured-domain remarks: AS12541 ->graham.cole@obscured-domain mnt-by: AS13186-MNT mntner: AS13186-MNT descr: Cable and Wireless SA admin-c: RV4415-RIPE tech-c: XL5-RIPE upd-to: d12@obscured-domain auth: NONE mnt-by: AS13186-MNT referral-by: RIPE-DBM-MNT route: 212.66.160.0/19 descr: Intercom Servicios Telematicos Avanzados, S.A. origin: AS13186 notify: xlario@obscured-domain mnt-by: AS13186-MNT I could right now remove the route entry for 212.66.160.0/19 or change it to some other origin and thereby hijack the entry. All those that use auto-build tools based on the info in RIPE would allow me to announce the /19 and not C&W in Spain. Just an example. There are thousands. RIPE NCC won't deprecate auth=NONE without us telling them to do it. Why would we not want this? -Hank

1 0

Problems with RipeWhois.pm
by Arnd Vehling 28 Mar '03

28 Mar '03

Hi All, i am experiencing the following problem with the RipeWhois perl modul supplied with asused-3.65 / $Id: RipeWhois.pm,v 1.4 2001/04/18 17:01:20 timur Exp $ The "RipeWhois" function only works as long as i have the environment variables WHOIS_HOST set. If i unset the var the function stops working. I verified that with the supplied test client "cwhois". All command-line parameters and in-script defaults are ignored. OS is Solaris, perl version is: v5.6.1 Any Ideas? best regards, Arnd -- NetHead Network Design and Security Arnd Vehling av(a)nethead.De Gummersbacherstr. 27 Phone: +49 221 8809210 50679 Köln Fax : +49 221 8809212

1 1

Ref: Abuse contact
by Wilfried Woeber, UniVie/ACOnet 27 Mar '03

27 Mar '03

>To: s.willing(a)mops.net >CC: anti-spam-wg(a)ripe.net >From: RIPE Database Manager <ripe-dbm(a)ripe.net> >Date: Tue, 25 Mar 2003 10:07:29 +0100 >Subject: [anti-spam-wg(a)ripe.net] Re: NCC#2003034446 Abuse contact > >Dear Sebastian, > >Any changes to database schemas are decided upon in >RIPE Database Working Group, Yes, in principle, but as a matter of fact we prefer requests for object creations or modifications to come in from the "user base" (including a rough blueprint :-), i.e. the appropriate RIPE WG(s). >which is an open working >group. It has a mailing list. You can subscribe to it >and present your proposal there, for the review of other >members of the WG. Its web page is: > >http://www.ripe.net/ripe/wg/db/index.html In this particular case I'd expect (at least) Anti-SPAM to discuss any deployment scenarios, before we go ahead and modifify objects. As a personal note - I tend to think the IRT object might be a better place to put such stuff. Because the IP-address management role(s), being more administartive, often do not have close links to abuse or incident roles within an ISP. >If you have any more questions, please don't hesitate >to contact <ripe-dbm(a)ripe.net>. > >Regards, > >Engin Gunduz >____________________________ >RIPE Database Administration. Cheers, Wilfried (RIPE DB-WG Chair) _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ On Tue, 25 Mar 2003 09:53:28 +0100 (CET), S Willing wrote: * Hello! * * Some RIPE entries already include abuse information, but not in a uniform type. * * Arin has some extra abuse contact attributes: * OrgAbuseHandle: ABUSE23-ARIN * OrgAbuseName: Abuse * OrgAbusePhone: +1-800-436-8489 * OrgAbuseEmail: abuse(a)genuity.com * * I'ld like to suggest a new RIPE-DB attribute: "abuse-mail". * * It should be required for every new allocation and optional for assignments. * Somewhere in the future, the whois server should automatically return the * most-specific "abuse-mail"-entry which exists. * For example: 10.1.0.0/16 allocation has an "abuse-mail"-entry, but * 10.1.2.0/25 has none. In this case, the entry from the allocation * is returned. * 10.1.3.128/26 has an own "abuse-mail"-entry which is returned if * someone queries this object. * * MfG / Regards, * S.Willing * * ************************************************************************ * M / W / S Sebastian Willing * http://www.mops.net Technical director * Telefon: 01803/684310578 e-Mail: s.willing(a)mops.net * Telefax: 01805/445169111 SW88-RIPE * ************************************************************************ * --------------------------------------------------------------------------------

1 0

Mirroring of LEVEL3 database
by Koepp, Karsten 12 Mar '03

12 Mar '03

Hello around, does anyone besides me consider the Level (3) IRR database useful to be mirrored? I can find the Level(3) data on whois.ra.net but I would like to continue using whois.ripe.net. I understand the db admins position but I consider this source valuable. I have no statistics on the number of objects - I just happen to meet source LEVEL3 now and then. Karsten > Dear Karsten.Koepp, > > Regarding you question about the RIPE NCC mirroring the LEVEL > 3 database, > we currently have no plans on doing that as we were not requested by > LEVEL 3 to carry a mirror of their data. > > Our requirements for mirroring are: > 1. The source is a public IRR > 2. It should have considerable size > 3. It should be useful for the users in the RIPE region > > We don't seek out databases to mirror, although if a number > of our users > think that it can be useful we can ask permission for that. > > Best Regards, > Tiago Antao > ---------------------------- > RIPE Database Administration >

2 1