July 2005 - db-wg - mailman.ripe.net

<auto-dbm@ripe.net> is slow this afternoon.
by RIPE Database Administration 17 May '18

17 May '18

Dear Colleagues, Because of a very high level of use this afternoon, the response time of <auto-dbm(a)ripe.net> is longer than normal. I have made contact with those who are responsible and I expect the situation to improve as the machine works through the queue. Please be patient. Obviously we at the RIPE NCC Database Group are continuously working to make the performance of the database as good as possible. However, we cannot make improvements in zero time. We thank you for your co-operation up to now and we ask for your continued co-operation so that everyone receives the best possible service. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

2 2

Deprecation of the NONE Authentication Scheme
by Ziya Suzen 08 Nov '05

08 Nov '05

Dear Colleagues, As announced at RIPE 47 the NONE authentication scheme will be deprecated. After 26 April 2004 the RIPE Whois Database will not accept updates using the NONE authentication scheme. If you have objects protected by a MNTNER object which has the NONE authentication scheme, please assign another authentication scheme or create another MNTNER object to protect these objects. If you are a RIPE NCC member you can create new MNTNER objects through the LIR Portal or send your update to <auto-dbm(a)ripe.net>. History and details: -------------------- 1. Motivation The RIPE Database protects data from unauthorised modification through the use of references to maintainer objects. The maintainer objects contain an "auth:" attribute which specifiy how a user is authenticated during updates to the database. One of the allowed authentication schemes is "NONE", which is actually not an authentication at all, but rather specifies that no authentication is necessary. NONE is intended to be used consciously, as a notification facility or as a means to tag objects. In April 2003, a proposal was sent to the Database Working Group by Hank Nussbacher: 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. It is likely that in many cases NONE is used simply because it is easy. Currently approximately 500 maintainers use NONE - about 5% of all maintainers. 2. Plan Normally with a database cleanup effort, an announcement is sent to the appropriate mailing lists, posted to the RIPE web page, and also sent to the specific users affected. A period of time for cleanup is given. Finally, if the users have not fixed the data then it is modified. However, for the NONE deprecation, it is inadvisable to do this as it means announcing what is in effect a security vulnerability. Also, our operational experience with past cleanups shows that most users do not really participate through the phases of the effort. Therefore, the plan for MNTNER objects with the NONE authentication scheme is: o Announcement only to db-wg mailing list. (This announcement) o Remove "auth: NONE" attributes from all MNTNER objects, by changing them to a "remarks:" attribute with a URL explaining the change. o If that is the only authentication scheme, update the mntner objects, adding MD5-PW with a generated password. o E-mail the "admin-c:" and "tech-c:" of the objects, and the e-mail addresses listed in the "upd-to:" and "mnt-nfy:" attributes of the objects, explaining the change and including the new password if one is added. o Passwords can be requested via an e-mail to <ripe-dbm(a)ripe.net>. The reply with the password will be sent to the same contacts. After a certain period of time the service will be discontinued. Users wishing to use these maintainers may contact <ripe-dbm(a)ripe.net> for assistance. 3. RIPE-NCC-NONE-MNT A maintainer with NONE authentication, RIPE-NCC-NONE-MNT, was added to objects without any maintainer when the database was converted from RIPE-181 format to RPSL format in April 2001. There is a remark in these objects which includes the following: remarks: The RIPE NCC will never use this maintainer object to remarks: enforce any sort of control over user's objects. It is possible this could have been interpreted to mean that no restriction would ever be added to the object. One use of the RIPE-NCC-NONE-MNT has been to allow the creation of objects representing routing policy for resources not allocated or assigned by the RIPE NCC. This is done by using "mnt-routes: RIPE-NCC-NONE-MNT" or "mnt-lower: RIPE-NCC-NONE-MNT" as appropriate. A new maintainer object will be created for these cases, with a well- known password, published in the object: mntner: RIPE-NCC-RPSL-MNT descr: This maintainer may be used to create objects to represent descr: routing policy in the RIPE Database for number resources not descr: allocated or assigned from the RIPE NCC. admin-c: RD132-RIPE upd-to: ripe-dbm-notify(a)ripe.net auth: MD5-PW $1$GUExyzzy$XQtbZHGVqy9GW8BiAckBV1 remarks: ******************************************************* remarks: * The password for this object is 'RPSL', without the * remarks: * quotes. * remarks: ******************************************************* mnt-by: RIPE-DBM-MNT referral-by: RIPE-DBM-MNT changed: ripe-dbm(a)ripe.net 20040301 source: RIPE The main use of this maintainer is for INETNUM objects. There are approximately 60000 such objects - about 6% of the inetnums. Updates for objects with RIPE-NCC-NONE-MNT are rare, less than 2% of all updates. For objects using RIPE-NCC-NONE-MNT: o If there are other "mnt-by:" attributes it will be changed to a "remarks:" attribute. o Otherwise, the "mnt-by:" will be changed to RIPE-NCC-LOCKED-MNT, which has a locked password (or PGP key). o A "remarks:" attribute will be added explaining how to generate a maintainer. o An e-mail will be sent to the "admin-c:" and "tech-c:" of the objects, and the e-mail addresses listed in the "notify:" attributes of the objects, explaining the change and giving a URL which will help to generate a new maintainer or assign another existing maintainer. o At the URL, the object will be automatically updated to have a new maintainer. o After a certain period of time the service will be discontinued. Users wishing to use these maintainers may contact ripe-dbm(a)ripe.net for assistance. 4. Other maintainers with "auth: NONE" The RIPE-NCC-PN-NONE-MNT was used to mark PERSON objects not to be deleted in the 2001 person cleanup. It can be removed and the maintainer deleted. The LIM-MNT is used for limericks. It will have a well-known password similar to the RPSL maintainer. It will also be maintained by another maintainer (not itself, as currently). -- Ziya Suzen RIPE NCC

4 5

Wierd output of whois/database
by Matthew Smith 25 Jul '05

25 Jul '05

Hi all, if this is the wrong list, then please point me in the right direction. I am first assuming that I have done something wrong. I should have a role 'AHM' with two person objects (MS33051-RIPE and DB). The whois output (below) also gives two further records at the end which I cannot fathom how or why they appear. Comments please Regards Matthew msmith:mlnet%whois -h whois.ripe.net -- -B AHM % This is the RIPE Whois query server #1. % The objects are in RPSL format. % % Note: the default output of the RIPE Whois server % is changed. Your tools may need to be adjusted. See % http://www.ripe.net/db/news/abuse-proposal-20050331.html % for more details. % % Rights restricted by copyright. % See http://www.ripe.net/db/copyright.html % Information related to 'AHM' role: Aexiomus Hostmaster address: Aexiomus Limited address: United Kingdom phone: +44-906-7530143 fax-no: +44-906-7530143 e-mail: hostmaster(a)aexiomus.net e-mail: hostmaster(a)aexiomus.net.uk admin-c: DB tech-c: DB tech-c: MS33051-RIPE nic-hdl: AHM mnt-by: AEXIOMUS-MNT mnt-by: MLNET-MNT notify: hostmaster(a)aexiomus.net.uk source: RIPE changed: hostmaster(a)aexiomus.net.uk 20050504 person: Denesh Bhabuta address: PO Box 2023 address: Wickford address: SS12 9RX address: United Kingdom phone: +44-906-7530143 e-mail: denesh(a)cyberstrider.net e-mail: denesh(a)aexiomus.net.uk e-mail: denesh(a)bhabuta.co.uk e-mail: denesh(a)dbcl.net nic-hdl: DB mnt-by: AEXIOMUS-MNT changed: hostmaster(a)cyberstrider.net 20000821 changed: hostmaster(a)cyberstrider.net 20020208 changed: denesh(a)aexiomus.net.uk 20020515 changed: denesh(a)aexiomus.net.uk 20030630 source: RIPE person: Matthew Smith address: ML Associates, 11 Grove Lane, Great Kimble address: Aylesbury, Bucks, HP17 9TR, UK phone: +44-20-7871-0604 e-mail: hostmaster(a)aexiomus.net e-mail: matthew(a)aexiomus.net e-mail: m(a)mlnet.co.uk e-mail: hostmaster(a)mlnet.net remarks: skype: monthemove nic-hdl: MS33051-RIPE mnt-by: AEXIOMUS-MNT mnt-by: MLNET-MNT source: RIPE changed: m(a)mlnet.net 20050429 changed: m(a)mlnet.net 20050526 % Information related to 'DB' person: SAIDUR AHM RAHMAN address: RAHMAN SAIDUR AHM address: VIA BARTOLOMEO CRISTOFORI 11 address: 00100 ROMA address: Italy phone: +39655302089 fax-no: +39655302089 nic-hdl: SAR32-RIPE changed: order.manager2(a)telecomitalia.it 20041022 source: RIPE % Information related to 'SAR33-RIPE' person: SAIDUR AHM RAHMAN address: RAHMAN SAIDUR AHM address: VIA BARTOLOMEO CRISTOFORI 11 address: 00100 ROMA address: Italy phone: +39655302089 fax-no: +39655302089 nic-hdl: SAR33-RIPE changed: order.manager2(a)telecomitalia.it 20041022 source: RIPE

3 3

Signature expiration check proposal
by Katie Petrusha 25 Jul '05

25 Jul '05

Dear Colleagues, This is a proposal about changes to how the whois database software checks PGP and X.509 signatures on incoming updates. Currently the software checks that the PGP signature is valid by using Gnu Privacy Guard (GnuPG). It verifies X.509 signatures with an OpenSSL (Secure Sockets Layer) tool. We propose to change the software, so that it also checks the signature creation date. If the signature is older than one week, it will be rejected and the update will fail. This is to prevent replay attacks on database objects. We became aware of this potential threat when we designed the DNSSEC provisioning system. -- Katie Petrusha RIPE NCC

2 1

Proposed changes for object ordering
by antointhe 20 Jul '05

20 Jul '05

An ordinary user writes: This is just great! No wonder they disposed of 'Mr Post Office' (hint). Look guys, I've got ppl scanning me all over and I can't even find out who it is. I have little time for the anticipated learning curve and I don't know if some fanatic wants to turn my machine into a bot or its just windows doing its thing. I have a feeling sensible folks like yourselves have anticipated situations like this and have tools around to help. The only query engine output is duplicated at my firewall. Is it possible that some of you have interests elsewhere? Not advisable in these days of insurgency... Best Regards antointhe

1 0

Announcement Routing Registry Training Courses
by RIPE NCC Training Services 19 Jul '05

19 Jul '05

Dear Colleagues The RIPE NCC Training Services Department invites you to register for one of our upcoming Routing Registry Training Courses: Date: Friday 19 August 2005 Time: 0900 - 1700 Location: Amsterdam, the Netherlands AND: Date: Friday 21 October 2005 Time: 0900 - 1700 Location: Sofia, Bulgaria AND: Date: Friday 28 October 2005 Time: 0900 - 1700 Location: Oslo, Norway AND: Date: Friday 4 November 2005 Time: 0900 - 1700 Location: Edinburgh, United Kingdom AND: Date: Friday 25 November 2005 Time: 0900 - 1700 Location: Munich, Germany The main objective of the "Routing Registry Training Course" is to familiarise the LIRs with the features of the Routing Registry, while introducing the relevant tools and services of the RIPE NCC. The course also offers practical exercises. OVERVIEW OF TOPICS COVERED IN THE COURSE: - Routing Registry as a part of the RIPE Whois Database and the Internet Routing Registry (IRR) - Specifying routing policies using (RPSL) Routing Policy Specification Language and the RtConfig tool - IRRToolSet - Routing Information Service (RIS) - Routing Registry Consistency Check Project Please note that this is an advanced course. It will: - NOT teach the basics of routing - NOT teach the basics of RIPE Database operations - NOT describe how to receive Internet resources from the RIPE NCC - NOT describe how to operate a Local Internet Registry (LIR) The target audience of the course are technical staff of LIRs: e.g. network operators, engineers etc. This course is not intended for administrative or management staff (e.g. Hostmasters) . It is assumed that all attendees will be familiar with Border Gateway Protocol routing and with the RIPE Database (i.e. creating/modifying objects). This course is based on interactive exercises in a local network set-up. Please bring your laptops equipped with the following: - A working Ethernet card, - Three meters of Ethernet cable, - A secure connection client, - A web browser. Please be prepared to share your laptop (or at least allow another attendee to "look over your shoulder") if necessary. The course is free of charge. We provide lunch and printed training materials. We do not cover any of your travel expenses or accommodation. We give all of our training courses in English. You can find more information about the course at: http://www.ripe.net/training/rr/ How to register: --------------------- You can register up to two people from your LIR for each course. (If there are places left nearer the time of the course, you can register more people). To register for this course, you can either use the LIR Portal at: https://lirportal.ripe.net/lirportal/training/course-list.html Or the online registration form on our website: http://www.ripe.net/cgi-bin/trainingform.pl.cgi If you have any questions, send an e-mail to <training(a)ripe.net>. Kind regards Rumy Kanis Training Services Manager RIPE NCC

1 0

New Attribute in DOMAIN Object
by Olaf M. Kolkman 18 Jul '05

18 Jul '05

Dear Colleagues, You may have seen our recently announced plans to deploy DNSSEC on the reverse tree. You can read more about this at: http://www.ripe.net/ripe/maillists/archives/db-wg/2005/msg00156.html This plan contains a proposal for the new "ds-rdata:" attribute. This attribute is used to perform the public key exchange that is needed to obtain a secured delegation. It is used in addition to the delegation information stored in the "nserver:" attribute. You can find more details in the Draft Registry Procedure at: http://www.ripe.net/rs/reverse/dnssec/registry-procedure.html Kind regards, -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC

1 0

Changes for abuse
by dfoley 15 Jul '05

15 Jul '05

This document is very confusing. The section : "(3) Adding 'abuse output' Option " describes the changes to the result returned for "$ whois 10.0.0.10". However the result displayed is actually the result before the change. This is followed by a description of the result of "$ whois -b 10.0.0.10". The result includes "e-mail:" attributes but no "abuse-mailbox:" attribute. So which request do I use to obtain the "abuse-mailbox:" attibute? . In your examples it is only returned with the "$ whois -L 10.0.0.10". And yet I am supposed to use the "$ whois -b 10.0.0.10" to get the abuse contacts. Should I expect to ignore the attributes and treat any email address returned with the "whois -b" request as an abuse contact? I have tried using the "whois -b" and I have yet to get a result without ERROR appearing.

2 1

Status of 'org' attribute
by MarcoH 13 Jul '05

13 Jul '05

[appologies for cross-posting this] Hi all, Maybe I missed out on something, but accoording to various templates in the ripe-databese, the org-attribute is optional. Apparently the hostmaster mailrobot things otherwise and refuses requests with an error because of the org-attribute not being present. I just ran into it on a ASN request, but I recall having problems before with this. Can anybody tell me who is right, the database template or the robot ? In fact, the database reference (http://www.ripe.net/ripe/docs/databaseref-manual.html#1.2.3) doesn't list it all. Grtx, MarcoH

2 2

RE: [db-wg] Trouble inserting inetnum inetnum object.
by Ramarajan, Arvind, ALABS 12 Jul '05

12 Jul '05

Tobias, Yup, that was the problem. ALLOCMNT in rip.config was not pointing to the wrong mntner. Regarding allocating a /25, I had the same problem even allocating 10/8. Thanks to all who responded. Thanx --> Arvind. -----Original Message----- From: Tobias Cremer [mailto:tcremer@de.cw.net] Sent: Tuesday, July 12, 2005 4:12 AM To: Ramarajan, Arvind, ALABS; db-wg(a)ripe.net Subject: Re: [db-wg] Trouble inserting inetnum inetnum object. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Arvind, Daniel Roesen wrote: > On Mon, Jul 11, 2005 at 02:10:52PM -0500, Ramarajan, Arvind, ALABS wrote: >>***Error: ALLOCATED inetnum objects require the RIPE NCC maintainer > > Make this status "ASSIGNED PA". correct - however, if you really want to create a ALLOCATED PA object (which is rather unlikely for a /25 :-) ), you have to use the mntner that is defined in rip.config to be allowed to created allocation objects. Have a look there for the ALLOCMNT section. Regards: Tobias - -- Tobias Cremer M.A. IP Admin Engineer Cable & Wireless Telecommunication Services GmbH Landsbergerstr. 155 80687 Muenchen Germany Tel +49 89 926 99 0 -- FAX +49 89 926 99 180 -- COMNET 7 49 9169 www.cw.com/de - -- Every message GnuPG signed -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFC03tfhC6y11CNwvcRAuv4AKCO9mghpONbgXmldjcGYs3N5IA5iwCfTu3i P3rdrbFnUgkHEVx/8JnT0Qs= =2V6/ -----END PGP SIGNATURE-----

2 1