- db-wg - mailman.ripe.net

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

Planned network maintenance 3-11-2005
by Ruud de Kooter 02 Nov '05

02 Nov '05

Dear Colleagues, This is to let you know that we will carry out planned network maintenance tomorrow, Thursday, 3 November from 20:00 to 22:00 UTC. We don't expect this to disrupt any RIPE NCC services, though you may notice some small delays. This maintenance is necessary after a high load on one of our border routers caused some service disruption on 29 September 2005. Since then, we have made configuration changes to improve load balancing between the border routers. Unfortunately this has not been as beneficial as we had hoped, and the load continues to increase. The router is approaching its maximum capacity. We have decided to replace the router with a more powerful one. We apologise for inconvenience this may cause. If you have any questions, please send e-mail to <ops(a)ripe.net>. Regards, Ruud de Kooter

1 0

Proposal for Test Database Cleanup
by Can Bican 01 Nov '05

01 Nov '05

Proposal for Periodic Clean-up for the TEST RIPE Database Motivation ---------- The RIPE NCC provides a TEST RIPE Database for users to learn how to use the software and try out new updates without the risk of damaging data in the real database. This database uses the same software as the production version of the RIPE Database. The data in the TEST database is NOT a copy of that in the RIPE Database, it is not authoritative data. Therefore no value should be put on it. The RIPE NCC only carries out maintenance operations in the RIPE Database and not in the TEST database. Over time, however, outdated features in the database software may make some parts of the TEST database unusable. To ensure a clean functioning test environment, we propose a periodic clean-up of the TEST database. Objectives ---------- - To increase the availability of the TEST database with a minimum of administrator interference. - To clean up unneeded items from the TEST database. - To provide a consistent starting point for the TEST database. Implementation -------------- - Every first Tuesday of each month, the TEST database will be reloaded with a set of database objects. Downtime will be brief, and is estimated to be at most half an hour. - After the reinitialisation, the database will contain: * One PERSON, one ROLE, one ORGANISATION and one MAINTAINER object for test purposes. * One MAINTAINER object to maintain the test MAINTAINER object. * 0/0 network ranges for IPv4 and IPv6. * 0/0 ROUTE and ROUT6 objects. * One as-block containing as0 - as65535. * Three DOMAIN objects for 'in-addr.arpa', 'ip6.arpa' and 'e164.arpa'. -- Can Bican Software Engineering Department

1 1

RIPE NCC Launches E-Learning Centre
by Rumy Kanis 01 Nov '05

01 Nov '05

[Apologies for duplicate e-mails] Dear Colleagues, The RIPE NCC is proud to announce the launch of its E-Learning Centre (http://e-learning.ripe.net). The E-Learning Centre is a free resource available to both members of the RIPE NCC and non-members. The E-Learning Centre will: - Enable users to learn in their own space and at their own pace - Supplement the training courses provided by the RIPE NCC - Allow users to contact the RIPE NCC trainers for additional help and support The E-Learning Centre launched on 1 November 2005 with an introduction to creating and updating basic RIPE Database objects. In January 2006, the RIPE NCC is planning to add a second module, covering the RIPE Policy Development Process. The RIPE NCC plans to develop further modules for the E-Learning Centre based on feedback from users. Plans are already underway for additional modules covering subjects such as DNS for LIRs, Advanced Database Objects and IRRToolset. The E-Learning Centre is available at: http://e-learning.ripe.net If you have any questions or feedback about the RIPE NCC E-Learning Centre, please e-mail: <e-learning(a)ripe.net> Regards, Rumy Kanis Training Services Manager RIPE NCC -- RIPE NCC Online learning... at your pace in your space http://e-learning.ripe.net

1 0

RE: [db-wg] New RIPE Whois Database Manual
by Koepp, Karsten 28 Oct '05

28 Oct '05

> Same here, it was very effective indeed, > but I think the -B alert in the answers could be removed by now? > > Wilfried. > Which implies all object maintainers update the database as frequent as we all do here. I estimate there is a large number of people doing updates so rarely they haven't even tried since this change. I am in favor of leaving the comment for a longer period (>= 2 years). Karsten

2 1

New RIPE Whois Database Manual
by Denis Walker 28 Oct '05

28 Oct '05

Dear Colleagues, We are pleased to announce the publication of an updated RIPE Whois Database Document. ripe-358 RIPE Whois Database Query Reference Manual Previously, this was part of ripe-252, The RIPE Database Reference Manual. The content has been thoroughly revised and updated. We have also improved the wording to make it clearer. We are now working on producing a RIPE Whois Database Update Reference Manual. The two new manuals together will obsolete ripe-252. You can find the document at: http://www.ripe.net/ripe/docs/db-query-manual.html Regards Denis Walker Software Enginerring Department RIPE NCC

9 9

yet another irrtoolset replacement
by md＠Linux.IT 19 Oct '05

19 Oct '05

This may be a good time to advertise the first public release of my routers configuration generator. It can generate the complete BGP configuration (neighbor statements, route maps, prefix and as-path lists) of peering or customer-facing routers using RPSL data, a local configuration file and a configuration template based on the popular Template::Toolkit perl package. Currently I only provide an IOS configuration template, but it should be easy to write one for JUNOS (patches are welcome!). It can be downloaded from http://www.linux.it/~md/software/rpsltool-0.1.tgz and is free software released under the terms of the GPL. (From the same directory you can also download cisco-tools-0.1.tgz, which contains some programs to monitor what is being announced and leaked by peers.) -- ciao, Marco

1 0

DB WG draft minutes RIPE 51
by Titley, Nigel 14 Oct '05

14 Oct '05

Gentlefolk, In an effort to make up for the lateness of last time, here are the draft minutes for the meeting that finished 30 minutes ago. Please could I have comments on *both* sets of minutes please. After 2 weeks I will move the RIPE 50 minutes to non-draft status and update the web site. The RIPE 51 minutes will remain at draft status until next meeting, as usual. Best regards Nigel -- Nigel Titley Peering Coordinator, FLAG Telecom +44 20 8564 5812 ********************************************************************** This e-mail message is confidential and is intended only for the use of the individual or entity named above and contains information which is or may be confidential, non-public or legally privileged. Any dissemination or distribution of this message other than to its intended recipient is strictly prohibited. You should not copy it or use it for any purpose nor disclose the contents to any other person. If you have received this message in error, please notify us by email to postmaster(a)flagtelecom.com immediately and delete the original message and all copies from all locations in your computer systems. This e-mail has been swept by Mailsweeper TM for viruses. However, FLAG Telecom cannot accept liability for any damage which you may sustain as a result of software viruses. ********************************************************************** This message has been scanned for viruses by MailControl - www.mailcontrol.com

1 0

Update Draft DB-WG minutes from RIPE 50
by Titley, Nigel 13 Oct '05

13 Oct '05

Gentlefolk, It has been pointed out that AP48.7 has actually been completed. Please see attached updated minutes. Nigel -- Nigel Titley Peering Coordinator, FLAG Telecom +44 20 8564 5812 ********************************************************************** This e-mail message is confidential and is intended only for the use of the individual or entity named above and contains information which is or may be confidential, non-public or legally privileged. Any dissemination or distribution of this message other than to its intended recipient is strictly prohibited. You should not copy it or use it for any purpose nor disclose the contents to any other person. If you have received this message in error, please notify us by email to postmaster(a)flagtelecom.com immediately and delete the original message and all copies from all locations in your computer systems. This e-mail has been swept by Mailsweeper TM for viruses. However, FLAG Telecom cannot accept liability for any damage which you may sustain as a result of software viruses. ********************************************************************** This message has been scanned for viruses by MailControl - www.mailcontrol.com

1 0

[Fwd: Re: [Fwd: [db-wg] RIPE51 DB-WG Draft Agenda V1]]
by Wilfried Woeber, UniVie/ACOnet 12 Oct '05

12 Oct '05

Thanks to Andre for reminding me about that item! I am a tad puzzled, because a DB-WG Action on this reads: 48.6 RIPE NCC To change DB behaviour to return IRT object [Complete] However, neither the web interface nor the RIPE whois client does return the irt information. Rather I get a route object under the heading of % Information related to 'prefix/length ASinfo' Any insight on that? Thanks, Wilfried. -------- Original Message -------- Subject: Re: [Fwd: [db-wg] RIPE51 DB-WG Draft Agenda V1] Date: Tue, 11 Oct 2005 15:28:57 +0200 From: Andre Koopal <andre.koopal(a)nld.mci.com> To: Wilfried Woeber, UniVie/ACOnet <woeber(a)cc.univie.ac.at> CC: db-wg(a)ripe.net, RIPE NCC Meeting Registration <meeting(a)ripe.net>, wg-chairs(a)ripe.net References: <434BB603.4050409(a)cc.univie.ac.at> On Tue, Oct 11, 2005 at 01:54:27PM +0100, Wilfried Woeber, UniVie/ACOnet wrote: > > Dear DB-WG folks, Chairs, Meeting! > > Here is the 2nd draft of an agenda for the DB-WG next week at RIPE51 > in Amsterdam. > > For time slot allocation please refer to the most up-to-date meeting > plan at http://www.ripe.net/ripe/meetings/ripe-51/meeting-plan.html Hi Wilfried, A while ago I mailed the db working group to request a changed behavour when you lookup inetnum's. In principle what I would like to see is that when an inetnum is returned, that the IRT object that is relevant to this inetnum is returned as well. For example, if you lookup inetnum '193.78.240' you get that inetnum returned, and the irt-object 'IRT-MCI-NL', as that is specified in the inetnum above: '193.78/15'. Note that this is different then the current -c behavour as that would, in this example' return the inetnum for '193.78/15' instead. Can you add this discussion on the agenda as well? Unfortunately I won't be able to visit the WG session myself, I hope the proposal is clear this way. Regards, Andre Koopal > > Best regards, > Wilfried. > ________________________________________________________________________ > > A. Administrative Matters > - scribe > - list of participants > - agenda > - minutes > - "remote participation" coordination (if needed) > > B. DB Update (N.N., RIPE NCC) [~15 min] > > C. Review of security mechanisms in the DB (Peter K., denic.de) [~15 min] > . quality of CRYPT-PW, CRYPT-MD5, X.509 > . level of vulnerabilty in current dataset > > D. State of whois services, developments? (WW144, N.N., RIPE NCC) [~15 min] > > E. IRIS pilot frontend to whois (N.N., RIPE NCC) [~10 min] > > F. Fact finding: RoutingReg facilities at RIRs (Gert D, SpaceNet) [~15 min] > > X. Impact of "PDP" on how the DB-WG operates (WW144) [~15 min] > . ref: https://www.ripe.net/ripe/docs/ripe-350.html > > Y. Input from other WGs > . DNS: secureDNS requirements for the DB > > Z. AOB > > >

7 8