May 2002 - 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

Status field for inet6num objects
by Joao Luis Silva Damas 08 Jul '02

08 Jul '02

[** Mail posted to both APNIC and RIPE lists in the hopes of trying to find a solution suitable for all users of RIPE or RIPE-derived software **] Dear all, the inet6num, like the inetnum object, has a field named "status" which stores some information about the nature or position of a block of addresses in the delegation chain, from the RIR through to the end user. Currently, the status field for inet6num object is generated by the Database software based on the size of the address block and its possible values are: o TLA o SubTLA o NLA o SLA This notation has been deprecated and it is time to adapt the database. Discussions on this matter have identified the usefulness of having the capability to distinguish between allocations made by the RIR, allocations made by an LIR or their customers and assignments to end users. As such, we propose to modify the "status" attribute of the inet6num object to be: a) not-generated. This means users must assign a value to the status attribute when creating the object, just as in the inetnum object b) have the following possible values: RIR-allocated LIR-allocated Assigned to be used according to the following set of rules: The RIR-allocated status can only be used in objects representing allocations created directly by the RIR. The LIR-allocated status can be used by LIRs and their customers to represent blocks of addresses that are not assigned to specific end users. There can be several levels of objects with this status. The Assigned status must be used in objects representing assignments to end users (households, companies, enterprises, etc) We hope that with this modification the information in the Database will more accurately describe the registration of IPv6 address space. A possible transition to the new values could be: 1) RIRs modify status fields for allocations 2) Any new objects and modifications to existing ones must have a value for the status field corresponding to the ones described above. Otherwise the update will fail. 3) RIRs contact LIRs to have the status of assignments and sub-allocations updated. Best regards, Joao Damas RIPE NCC

5 4

MD5-PW auth scheme is available in the RIPE Database
by Andrei Robachevsky 17 May '02

17 May '02

Dear Colleagues, [apologies for duplicate messages] Following the request from the RIPE Community a new auth scheme based on MD5-crypt algorithm was implemented and put into production today, 16 May 2002. Implementation details can be found in the proposal circulated in the db-wg mailing list http://www.ripe.net/ripe/mail-archives/db-wg/20020401-20020701/msg00011.html. We also created another FAQ entry "How to use MD5-PW auth scheme in my mntner?" (http://www.ripe.net/ripencc/faq/database/qa5.html#13). The RIPE Database Reference Manual will be updated soon. You may use Crypt CGI interface (http://www.ripe.net/cgi-bin/cgicrypt.pl.cgi) to convert your passphrase to MD5-PW string. Regards, Andrei Robachevsky DB Group RIPE NCC

3 3

Phasing out MAIL-FROM auth scheme
by Andrei Robachevsky 16 May '02

16 May '02

Dear Colleagues, [apologies for duplicate messages] The MAIL-FROM authentication scheme is very weak. Forging RFC2822 headers can be done very easily. With the existence of more secure "auth" schemes in the RIPE Database, it does not make much sense to support it any more. The proposal to phase out the MAIL-FROM authentication scheme was presented to the to the Database Working group. You may find the original proposal at http://www.ripe.net/ripe/mail-archives/db-wg/20020101-20020401/msg00066.html The timeline for this transition presented below was discussed and approved at the RIPE 42 meeting. Please see the minutes of the DB-WG session http://www.ripe.net/ripe/wg/db/minutes/ripe-42.html. To make this transition more smooth we prepared a page with step by step instructions how to update the mntner objects to remove the MAIL-FROM auth scheme. It can be found at http://www.ripe.net/db/MD5-HOWTO.html Regards, Andrei Robachevsky DB Group Manager RIPE NCC Transition phases ================== Use of MAIL-FROM is phased out in four steps, on the following dates: Phase 1: 16 May 2002 - 12 June 2002 Notifying mntners with MAIL-FROM auth scheme -------------------------------------------- An announcement presenting this transition and encouraging the owners of the mntners to remove MAIL-FROM auth scheme from their objects will be sent on 16 May, 2002. The announcement will point to instructions how to update the mntner objects to remove the MAIL-FROM auth scheme. The distribution list will be compiled from e-mail addresses listed in "upd-to:", "mnt-nfy:" attributes of the mntners, as well as using contact information (e-mail) from "admin-c:" and "tech-c:" references. Phase 2: 13 June 2002 - 10 July 2002 Rejecting updates for mntner objects containing MAIL-FROM auth scheme --------------------------------------------------------------------- When updating maintainers the new version must not contain MAIL-FROM "auth:" attributes, otherwise this will be reported as a syntax error. This means that you cannot create any new MAIL-FROM "auth:" attributes, either in new or existing maintainers. Phase 3: 11 July 2002 - 7 August 2002 Rejecting using the MAIL-FROM auth scheme for authorisation ----------------------------------------------------------- When processing an update for an object protected by a mntner that contains MAIL-FROM auth scheme, this scheme will be ignored. That means that if mntner defines other auth schemes different from MAIL-FROM, the credentials relevant to these schemes may be used. If the only auth scheme defined is MAIL-FROM, no update can be authorised by such mntner. Phase 4: 8 August 2002 Cleanup ------- The mntners still containing "auth:" attribute with the MAIL-FROM auth scheme will be modified so that such attributes will be removed from the objects. Before this a final call will be sent to the owners of these mntners ("upd-to:", "mnt-nfy:" attributes of the mntners, as well as to the contacts from "admin-c:" and "tech-c:" references). A "remarks:" attribute will be added with clear explanation of the situation. In case a mntner contains only one "auth" scheme, which is MAIL-FROM, it will be locked and cannot be used by the owner.

2 1

Anti-spam policy for ripe-dbm@ripe.net mailbox
by Andrei Robachevsky 13 May '02

13 May '02

Dear Colleagues, Starting from Monday, 20 May 2002, an anti-spam filtering policy for ripe-dbm(a)ripe.net mailbox will be implemented. Messages not explicitly directed to ripe-dbm(a)ripe.net, that is not containing this e-mail address in "To:" or "Cc:" fields of the mail header will be filtered out and not processed. Spam messages constitute up to a half of the ripe-dbm mailbox, and it takes some of our resources to identify and delete them. If you have any questions or concerns please contact RIPE Database Administration at ripe-dbm(a)ripe.net. Regards, Andrei Robachevsky DB Group Manager RIPE NCC

2 1

Requests to the RIPE DB Administration are now ticketised
by Andrei Robachevsky 03 May '02

03 May '02

Dear colleagues, [apologies for multiple messages] As was announced at the RIPE 42 meeting starting from the next week, 6 May 2002, questions and requests directed to the RIPE Database Administration (ripe-dbm(a)ripe.net) will be processed using a ticketing system. This will allow us to track your requests more efficiently and further improve the quality of support we provide to you. No automatic acknowledgements will be sent to you. In replies from the ripe-dbm the subject line will be modified by prepending a ticket number: Re: NCC#2002044160 <original subject> Please preserve this ticket number in your further correspondence with the ripe-dbm. No other changes should be visible to you. This will not affect submissions sent to the RIPE Database at auto-dbm(a)ripe.net. If you have any more questions regarding this issue please don't hesitate to contact ripe-dbm(a)ripe.net. Regards, Andrei Robachevsky DB Group Manager RIPE NCC

1 0

FYI: [cert-coord] DRAFT 6th TF-CSIRT Agenda - 23-24 May 2002, Copenhagen
by Yuri Demchenko 02 May '02

02 May '02

DB-WG: Please find attached the DRAFT Agenda of the next TF-CSIRT meeting in Copenhagen that contains item on RIPE NCC IRT Object: Implementation status and further deployment. In case you are interested to attend please contact me. > > Dear TF-CSIRT members, > > This is to inform you that the final DRAFT Agenda of the next TF-CSIRT > meeting on > 23-24 May 2002 in Copenhagen is on the web > > http://www.terena.nl/task-forces/tf-csirt/tf-csirt6th020525agenda-draft.html. > > Those of you who still plan to attend the meeting please register at > http://scripts.terena.nl/meetings/6thtfcsirt/ > > Best Regard, > > Yuri Demchenko > Draft AGENDA 6th TF-CSIRT MEETING A TF-CSIRT Seminar will be held on Thursday 23 May 2002, 9:30 - 17:00 (tentatively) The 6th TF-CSIRT meeting will be held on Friday 24 May 2002, 9:00-15:30 (tentatively) Venue for both events: TU campus, the Technical University of Denmark (look for the logistics information at https://www.cert.dk/conference/) Thursday 23 May 2002 TF-CSIRT Seminar 09:30 - Welcome. Overview of the programme. Logistics 09:45 announcements. Network configuration. Apologies. Introduction of those present. Seminar Session 1 Current Practice in CSIRTs Organisation, structure, working methods among CSIRTs 09:45-10:15 Europol's position in relation to IT-crimes - Chief Inspector Mr. Mogens Lund, Europol 10:15-10:45 Vulnerability database developed in schools and universities here in Denmark - DK-CERT 10:45-11:15 CERT-Polska 11:15 - Refreshment break 11:45 11:45-12:15 SUNet CERT - Torbjorn Wictorin 12:15-13:00 CAIF - Common Advisory Interchange Format, a proposal for a standard for writing, interchanging, processing, storing, and presenting security advisories - Oliver Goebel, RUS-CERT, Stuttgart University 13:00 - Lunch break 14:30 Seminar Session 2 RIPE NCC IRT Object: Implementation status and further deployment 14:30 - IRT Object implementation by RIPE NCC - Andrei Robachevsky, 15:00 RIPE NCC 15:00 - Discussion - how to proceed 15:30 15:30 - Refreshment break 16:00 16:00 - Reserved for Discussions 16:30 Friday 24 May 2002 6th TF-CSIRT meeting 09:00 - 1. Welcome and Apologies 09:05 09:05 - 2. Round of Introductions 09:10 09:10 - 3. Minutes of Last Meeting (Stockholm 25 January 2002) 09:25 * Status report on actions from last meeting 09:25 - 4. "Trusted Introducer" Pilot Service 09:55 * Status Report * Presentation of the TI Board 09:55 - 5. EC funded/accepted projects: Presentations and issues 11:15 for cooperation 5.1. TRANSITS: Training (new) staff of (new) CSIRTs - Andrew Cormack 5.2. EISPP - Michel Miqueu, CERT-IST 5.3. eCSIRT - Olaf Gellert, PreSecure 5.4. Overview of other known related projects and activities in EC 11:15 - Refreshment break 11:45 11:45 - 7. Update on FIRST 12:00 * FIRST14 Conference Information * Other FIRST Developments 12:00 - 8. Results of yesterday's Seminar Sessions 12:30 * Summary conclusions and follow-up actions * Summary of the RIPE NCC IRT Object Implementation status 12:30 - Lunch break 14:00 14:00 - 9. IODEF development 14:30 * INCH BOF report - Jan Meijer, CERT-NL * IODEF pilot implementation and related issues 14:30 - 10. Summary of the TF-CSIRT Charter Discussion 15:00 15:00 - 11. Other Work Items 15:30 * Assistance to establishment of new CSIRTs 15:30 - 12. Date and Venue of Next Meetings 15:35 15:35- 15:45 13. Any Other Business Accompanying events: To be announced later Additional information: Registration and list of registered participants - http://scripts.terena.nl/meetings/6thtfcsirt/ Logistics information - https://www.cert.dk/conference/

1 0

Draft Minutes of DB-wg minutes for RIPE 42
by Nigel Titley 02 May '02

02 May '02

Gentlefolk, Here is the first cut of the minutes for the DB working group. Corrections to me please, within 2 weeks, after which the final version will be posted to the group. RIPE webmaster, please post these to the web site as the first draft version Best regards Nigel

1 0