September 2004 - db-wg - mailman.ripe.net

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

16 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 07 Nov '05

07 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

Fwd: [Apnic-announce] Privacy of customer assignment records - implementation update
by leo vegoda 23 Sep '04

23 Sep '04

Hi, APNIC have announced a change in the default behaviour of their Whois server. The change will be made on 30 September. People using their Whois service from this region may be interested in the announcement. Kind regards, -- leo vegoda Registration Services Manager RIPE NCC Begin forwarded message: > From: APNIC Secretariat <secretariat(a)apnic.net> > Date: September 23, 2004 2:02:27 am BST > To: apnic-announce(a)apnic.net > Cc: Subject: [Apnic-announce] Privacy of customer assignment records - > implementation update > Reply-To: apnic-talk(a)apnic.net, secretariat(a)apnic.net > > Dear colleagues, > > This is an important announcement on the implementation of APNIC > approved proposal prop-007-v001 regarding privacy of customer > assignment records. The proposal document, presentation, minutes, and > discussion are available at: > > http://www.apnic.net/docs/policy/proposals/prop-007-v001.html > > The APNIC Secretariat will be implementing this proposal on 30 > September 2004. > > Please note that after this date, customer assignment objects will no > longer be visible in the APNIC Whois Database, unless the APNIC > account holder chooses to make public the customer records for their > allocated address range. > > A set of Frequently Asked Questions about this project is now > available at: > > http://www.apnic.net/info/faq/privacy-faq.html > > If you have any concerns or questions regarding this policy, please > contact the APNIC helpdesk at: > > E-mail: helpdesk(a)apnic.net > Phone: +617 3858 3188 > Fax: +617 3858 3199 > > Regards > > ______________________________________________________________________ > APNIC Secretariat <secretariat(a)apnic.net> > Asia Pacific Network Information Centre (APNIC) Tel: +61-7-3858-3100 > PO Box 2131 Milton, QLD 4064 Australia Fax: +61-7-3858-3199 > ______________________________________________________________________ > _______________________________________________ > Apnic-announce mailing list > Apnic-announce(a)lists.apnic.net > http://mailman.apnic.net/mailman/listinfo/apnic-announce >

2 1

Abuse contacts in RIPE database and whois
by Rodney Tillotson 22 Sep '04

22 Sep '04

In this afternoon's session of the Anti-spam WG we discussed the issue of publishing abuse contacts and I agreed to present this consensus view and request. As time is short this is not yet published in the minutes of the meeting, but it will be! Rodney Tillotson Chair, RIPE anti-spam WG =========================================================== The Anti-spam WG asks the Database WG to take some timely action to improve the availability of abuse contacts for IP addresses allocated through RIPE: 1. to publish an explicit abuse contact address where possible for every address; 2. to lower the profile of other addresses currently in the database and published through whois, which were never intended for the abuse function. While it is for the Database WG to decide the best way to implement such improvements, the Anti-spam WG noted that of the various technical changes which have been proposed or partly implemented, one combination which we would find acceptable is: A. modify the IRT object to include an explicit 'abuse-mail' attribute and to remove the mandatory requirement for PGP or similar authentication (or introduce a similar new object with those properties); and B. modify the default behaviour of the whois interfaces to find and present an abuse address if there is one and to suppress other e-mail addresses. 22nd September 2004. ===========================================================

1 0

Agenda V3
by Titley, Nigel 16 Sep '04

16 Sep '04

Gentlefolk, Following a kind offer by Shane Kerr to give a run down on CRISP please find version 3 of the DB WG agenda. Nigel -- Nigel Titley Peering Coordinator, FLAG Telecom +44 20 7478 9579 ********************************************************************** 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

RE: [db-wg] draft agenda (V1) for DB-WG meeting, RIPE 49, Manches ter, UK
by Titley, Nigel 15 Sep '04

15 Sep '04

MarcoH wrote: > Hate to come up with it again, but there are various actions points > open > on the abuse-c stuff. One of them lists the 'implement whatever > concensus there is on the mailinglist'. > > These should already be on the agenda as open action points, but it > might > be worth planning some time for discussion or at least an overview of > what > the outcome of the mail discussion was. Sounds like a good idea. Do we have any volunteers to do a short presentation on where we got to? > It's hard to say there is consensus on this subject, although in they > end there weren't much comments posted and everybody seems to be > happy (or > tired of it). I think it just fizzled out. I'm not sure that we got to any consensus. Nigel -- Nigel Titley Peering Coordinator, FLAG Telecom +44 20 7478 9579 ********************************************************************** 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

draft agenda (V1) for DB-WG meeting, RIPE 49, Manchester, UK
by Wilfried Woeber, UniVie/ACOnet 13 Sep '04

13 Sep '04

Dear DB-WG community, attached please find the draft agenda V1 for the DB-WG meeting during RIPE49 in Manchester, UK. As some of us have still been on vacation recently, we may have to update the draft agenda as we get closer to the meeting date. Please feel free to propose additional topics by either replying to the WG mailing list or in private mail to Nigel (who has volunteered to manage the meeting in Manchester - thank you very much!) and myself. Have a nice and successful meeting in Manchester! Wilfried. ++++++++ A. Administrative Matters - scribe - list of participants - agenda - minutes - "remote participation" coordination (if needed) - meeting schedule for 2005 B. DB Operational Update (N.N., RIPE NCC) tbc [~20 min] C. ERX Report [196/8, 198/8] (Leo V., RIPE NCC) [~15 min] D. RAToolSet software maintenance (N.N., RIPE NCC) tbc [~10 min] E. Routing Registry Courses (Vesna M., RIPE NCC) [~05 min] Y. Input from other WGs Z. AOB -------------------------------------------------------------------------------- 7-SEP-2004 12:55:00 UTC

7 12

Re: [db-wg] domain: object normalization
by Wilfried Woeber, UniVie/ACOnet 13 Sep '04

13 Sep '04

I'd like to come back to the *original* question or suggestion: to teach the DB software to accept FQDN notation (trailing ".") for lookup keys that denote domain names. Pro / Con? As a dumb user of the DB I definitely stumble into that one myself, sometimes, so I am in favour of this (hopefully simple?) change. Btw, if this gets implemented, it should also work for the referral domain objects! Wilfried.

2 1

Draft Agenda V2
by Titley, Nigel 13 Sep '04

13 Sep '04

Folks, Following the discussion about abuse, Marco has agreed to give a short round up. This gives us version 2 of the Agenda Nigel +++++++ A. Administrative Matters - scribe - list of participants - agenda - minutes - "remote participation" coordination (if needed) - meeting schedule for 2005 B. DB Operational Update (N.N., RIPE NCC) tbc [~20 min] C. ERX Report [196/8, 198/8] (Leo V., RIPE NCC) [~15 min] D. RAToolSet software maintenance (N.N., RIPE NCC) tbc [~10 min] E. Routing Registry Courses (Vesna M., RIPE NCC) [~05 min] F. IRT/Abuse roundup (MarcoH) [~15 min] Y. Input from other WGs Z. AOB -- Nigel Titley Peering Coordinator, FLAG Telecom +44 20 7478 9579 ********************************************************************** 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

Draft Minutes of the DB WG, version 2
by Titley, Nigel 13 Sep '04

13 Sep '04

Folks, This is the second draft of the minutes from the DB-WG RIPE 48. A very minor change has been made to item C. All actions are unchanged. Please check for your actions and try and report back. For reference I have open actions against RIPE NCC Wilfried Woeber Randy Bush + Niall O'Reilly Shane Kerr Nigel Titley Best regards Nigel -- Nigel Titley Peering Coordinator, FLAG Telecom +44 20 7478 9579 ********************************************************************** 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