- db-wg - mailman.ripe.net

Final Minutes for DB WG at RIPE 41
by Nigel Titley 19 Jul '02

19 Jul '02

Folks, As I have had no comments following the posting of the minutes in draft form to this list and to the Ripe web site, I am publishing the minutes in final form (see below) Best regards Nigel Minutes for the Database Working Group Meeting RIPE-42, Apr. 29 - May 3, 2002, Amsterdam, NL Thursday, May 2nd, 2002 09:00-12:30 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A. Administrative stuff (WW, chair) . scribe (offer from Nigel received) . circulate list of participants . agenda bashing . status of minutes Minutes have been circulated to the list in both draft and final form and are posted to the web site. B. Action Items . status of actions [AP-41.1 WW] To send list of proposed updates to IRRToolSet to mailing list for WG members to vote on. Deadline 3 weeks. Ongoing, no action yet [AP-41.2 C&W] To send their proposal to allow referencing external objects in the DB to the mailing list for discussion. Ongoing, no action yet [AP-41.3 RIPE-NCC] Create Documentation and BCP for IRT object. Ongoing, some work done. [AP-41.4 ALL] Create IRT object and tag inetnum for all appropriate objects. Ongoing, some objects created [AP-41.5 WW] To put together a group to put together a short guidance document to guide reference document writers. This team to include Ruediger. Ongoing, no action yet, nothing from Ruediger. [AP-41.6 RIPE-NCC] Put up a mailing list for the above purpose and advertise to the db-wg list. Ongoing, no action yet [AP-41.7 RIPE-NCC] To investigate soluton for mirroring "stickiness". Complete, a solution is now available. [AP-41.8 C&W] To formulate their proposals on the list for discussion. Complete. No response from C&W. [AP-41.9 RIPE-NCC] To document the mirroring protocol and the operational requirements of using it. Ongoing. Some work done. [AP-41.10 RIPE-NCC] Provide nag message to maintainer owners Ongoing. See presentation below. [AP-41.11 RIPE-NCC] Look at implementing MD5 password authentication Complete. [AP-41.12 RIPE-NCC] Look at general password authentication methods Ongoing. No action yet. C. DB update (RIPE NCC, Andrei R.) Usual DB update. Presentation available on the www.ripe.net web site. . Operational update 70% of queries are for IP addresses, 10% are domain references. The rest are various, including person. System is scaling well and average response time is less than 1s, despite a doubling of load over the past year. 50% of messages to ripe-dbm are spam. It is suggested that a simple spam filter (To: or Cc: ripe-dbm) may reduce this. Ticketing system to be introduced in the next few weeks. . Database developments MD5-PW scheme introduced, based on md5-crypt. Available on test database, soon to move into production. MAIL-FROM now to be deprecated. Notification to go out soon. 4 weeks later updates will be rejected (except for maintainer object updates). 4 weeks later submission will be rejected. Finally 4 weeks later the MAIL-FROM attribute will be removed from all maintainer objects. There is a suggestion that the same thing should be done with NONE. The meeting formally approved the MAIL-FROM timeline. The process to start before the end of May. IRT object has been available since Jan 2002. Two IRT objects have been created. Creation procedure still needs some development. DB Consistency and Statistics project 113 reports displaying 34000 inconsistences were produced. Please act on these and fix data. [AP-42.1 ALL] To check own data and correct inconsistencies if possible. SYNCUPDATES prototype Available in test as a syntax checker only so far. RRCC full prototype is ready IRRToolset is being managed. Update requests are very welcome. APNIC will be using the RIPE database code. The procedural changes needed will be rolled into the main database code. DB Documentation Structure and parts of several chapters are ready. Should be consistent with LIR training. D. Complex authentication scenarios (Alex G. SWITCH) . Background There are some scenarios which require multiple signatures. This has revealed a small bug in the database which has been worked around. It is better to sign a clear text update rather than using mime encapsulation. In the event of multiple signatures being required the clear text should be signed by the first maintainer, then the entire email signed again by the second maintainer. [AP-42.2 RIPE-NCC] To send instructions on multiple credentials to the DB working group mailing list. E. Discussion on "hiding" credentials (RIPE NCC, N.N.) . "shadow password" concept The idea is to not include the encrypted credential in the whois response. This prevents "brute force" attacks. However, this breaks with DB tradition of returning all attributes of all objects when requested and means that the DB can be the primary repository of the data. A proposal for a two level authentication scheme was received with full access for the DBA, but no password access from the general public. It was pointed out that this was a wider issue than just the RIPE community, but was also being discussed in the RPSLng working groups. It was also pointed out that packages are available which can attack digested passwords. The very valid point was raised that those who have problems with weak authentication methods, should use strong ones (eg PGP). Objects to this were that Windows users had problems with PGP and its "complex" interface. [AP-42.3 RIPE-NCC] To investigate the issues involved in shadow passwords and multiple level authentication schemes. [AP-42.3 Larry Blunk] To investigate the problems of multiple hashed passwords and the possibilies of embedding an ID within the hash and to submit a proposal to the working group. A proposal came from Janos to embed such information in the remarks field. F. IRT Object creation process The technical implementation is in place. Procedures need some work. Two IRT objects are registered so far. Objects need some authentication, to give them some cedibility. A "trusted introducer" currently provides authentication and labelling when an object is created. This may need updating. There is a meeting on the 23 - 24th May in Copenhagen on Computer Security IRT coordination. Attend if appropriate. G. Org object? This has been discussed in the past. Were people still interested in creating this object? APNIC and ARIN also carry these objects. This might be used in the registration of inet-nums. The role object partially answers this need, but cannot be used for an admin-contact. An org object could also be used to make a LIR object more visible and allow remote updating. The question also arises as to whether the owners of PI space could create org objects. H. Migration of objects between registries This is affecting legacy address space which pre-dates RIRs. This is currently in the ARIN database. It is proposed to migrate this data to the appropriate geographic RIR database. A great deal of inter-RIR liasison has already taken place. A number of approaches are possible, ranging from moving the data completely, using the referral mechanism, carrying all data in all databases etc. The thing that mustn't happen is to delete more up to to date data in the non-authoritative database in favour of old data in the authoritative database. It has been suggested that the "delegated" attribute be used to implement. This would only be used for inet-num and as-set objects. The issue was raised that one of the top level domain servers is in the 192.0.0.0/8 block, and deletion of the route objects for this would be disastrous. The response to this is that there was no intention to move route objects, just inet-num objects. I. Input from other WGs No other input J. AOB: No other business.

1 0

configuring ripe-dbase-3.1.0
by Sun Guonian 18 Jul '02

18 Jul '02

Dear Madam/Sir, I want to upgrade our whois server from ripe-dbase-2.3 to the new version ripe-dbase-3.1.0. in the last version(2.3), I can modify two files, conf/ripedb.config and lib/syntax.pl, to add new objects/attributes to offer chinese information to our clients. But in the new version, I can't find the proper mothed to do it. would you mind to help me to solve this problem ? Thanks very much ! Best regards, Sun Guonian China Internet Network Information Center (CNNIC)

2 1

Draft document "New Values of the 'status:' attribute for inet6num Objects" is available
by Andrei Robachevsky 17 Jul '02

17 Jul '02

Dear Colleagues, [apologies for duplicate messages] The draft document "New Values of the 'status:' attribute for inet6num Objects" is available on the RIPE NCC website at: http://www.ripe.net/ripencc/draft-documents/ This document describes the new values of the "status:" attribute for inet6num objects and their impact on database operation. The deadline for comments and suggestions is Wednesday, 24th July. After incorporating any suggested changes to the document the final document will be published as a RIPE Document. On Thursday, 25th July, subject to any additional comments, the described Database functionality will be put in to practice. Please send your comments and suggestions to <lir-wg(a)ripe.net>. Regards, Andrei Robachevsky RIPE NCC

1 0

RE: [lir-wg] Discussion Summary: Status field for inet6num object s
by Guy Davies 08 Jul '02

08 Jul '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I would prefer RIR-LIR-ALLOCATED, LIR-SUB-ALLOCATED and LIR-USER-ASSIGNED (or similar) if we must keep ALLOCATED and ASSIGNED in the descriptions. I don't think that it is immediately clear from the proposals below whether LIR-ALLOCATED is allocated by an LIR or to an LIR. Regards, Guy > -----Original Message----- > From: Gert Doering [mailto:gert@space.net] > Sent: Monday, July 08, 2002 1:42 PM > To: leo vegoda > Cc: ipv6-wg(a)ripe.net; lir-wg(a)ripe.net; db-wg(a)ripe.net; > sig-db(a)apnic.net; > policy-db(a)apnic.net; apnic-talk(a)apnic.net > Subject: Re: [lir-wg] Discussion Summary: Status field for inet6num > objects > > > Hi, > > On Mon, Jul 01, 2002 at 06:21:24PM +0200, leo vegoda wrote: > > The RIPE NCC needs to implement a new status attribute for the > > inet6num object to reflect the new policy agreed by the RIPE, > > ARIN and APNIC communities. > > > > The RIPE NCC suggested the following new status attributes for > > the inet6num objects: > > > > - RIR-ALLOCATED > > (For allocations made by an RIR to an LIR) > > > > - LIR-ALLOCATED > > (For allocations made by an LIR or an LIR's downstream > > customer > > to another downstream organisation) > > > > - ASSIGNED > > (For assignments made to End User sites) > > I haven't seen any replies to this so far. > > I want to express that I like this proposal. It doesn't introduce > any new and yet-undefined terms, but makes clear what the status of > a given network is. > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: > 45809 (45931) > > SpaceNet AG Mail: netmaster(a)Space.Net > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > 80807 Muenchen Fax : +49-89-32356-299 > -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.1 iQA/AwUBPSmLLo3dwu/Ss2PCEQIJdQCeOKDqqTLKCuB+o3pWMj/XJ41QJMQAnROW EWRBiRI4rPpF9DRbhrxYcK0S =Rab7 -----END PGP SIGNATURE----- This e-mail is private and may be confidential and is for the intended recipient only. If misdirected, please notify us by telephone and confirm that it has been deleted from your system and any copies destroyed. If you are not the intended recipient you are strictly prohibited from using, printing, copying, distributing or disseminating this e-mail or any information contained in it. We use reasonable endeavors to virus scan all e-mails leaving the Company but no warranty is given that this e-mail and any attachments are virus free. You should undertake your own virus checking. The right to monitor e-mail communications through our network is reserved by us.

2 1

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

RPSL Object Parsing Library version 3.1.0
by RIPE Database Administration 08 Jul '02

08 Jul '02

Dear Colleagues, [Apologies for multiple messages]. The RPSL Object Parsing library version 3.1.0 is now available for download in source format. This is the library that the RIPE Whois server uses to parse and manipulate RPSL objects. It implements the same syntax as the RIPE Whois server version 3.1.0, and provides both C and Perl API's. In future, we will release this library simultaneously with new versions of the server software. You can download this release by anonymous FTP from the following URL: ftp://ftp.ripe.net/ripe/dbase/software/RPSL-OL-3.1.0.tar.gz If you have any questions, problems, or suggestions, please e-mail the database development team at <dbrip(a)ripe.net>. -- Shane Kerr RIPE NCC

1 0

as-set: question
by Marco Davids 05 Jul '02

05 Jul '02

Listmembers, I have a question concerning chapter '1.2.2 as-set' of document ripe-251. I believe that I found an as-set record that is not right, but I am not exactly sure (allright, our maxpand-script found the strange record, because it choked on it). It concerns AS-KQES: marco@achilles:~$ whois AS-KQES | more % This is the RIPE Whois server. % The objects are in RPSL format. % Please visit http://www.ripe.net/rpsl for more information. % Rights restricted by copyright. % See http://www.ripe.net/ripencc/pub-services/db/copyright.html as-set: AS-KQES descr: Macro for KPNQwest Spain members: AS2134 # KPNQwest Spain members: AS8318 # Valenciana de Cementos members: AS-JAZZTRANS # Jazz Telecom - JazzNet announces members: AS12430 # AIRTEL members: AS12479 # Uni2 Are these #-remarks in compliance with the RIPE-documents? And if not, should such input be refused by the check? Greetings, -- Marco Davids SARA / High Performance Networking - Amsterdam "A cynic is a person who knows the price of everything and the value of nothing."

2 1

New Document available: RIPE-251
by RIPE NCC Document Announcement Service 04 Jul '02

04 Jul '02

New/Revised RIPE Document Announcement -------------------------------------- A revised document is available from the RIPE document store. Ref: ripe-251 Title: RIPE Database Reference Manual Author: Joao Luis Silva Damas, Andrei Robachevsky Date: 4 July 2002 Format: PS=280763 TXT=126186 Obsoletes: ripe-238 Obsoleted by: Updates: Updated by: Short content description ------------------------- The latest version of the RIPE Database reference manual. This document includes information about the MD5-PW Authentication method. Accessing the RIPE document store --------------------------------- You can access the RIPE Database Reference Manual in HTML format via WWW at the following URL: http://www.ripe.net/ripe/docs/databaseref-manual.html The RIPE document store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-251.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-251.txt plain text version Kind Regards, RIPE NCC Document Announcement Service

1 0

Draft document "IRT Object in the RIPE Database" is available
by Andrei Robachevsky 04 Jul '02

04 Jul '02

Dear Colleagues, The draft document "IRT Object in the RIPE Database" is available on the RIPE NCC website at: http://www.ripe.net/ripencc/draft-documents/irt-object.html This document describes the irt object and related functionality in the RIPE Database. The irt object is used to provide information about a Computer Security Incident Response Team (CSIRT). This document also describes the creation procedure for the irt object. The deadline for comments and suggestions is Thursday, 18 July 2002. After incorporating any suggested changes to the document the final document will be published as a RIPE Document. Regards, Andrei Robachevsky RIPE NCC

1 0

RE: [apnic-talk] Status field for inet6num objects
by Guy Davies 20 Jun '02

20 Jun '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > -----Original Message----- > From: Nigel Titley [mailto:nigel@titley.com] > > On Wed, 2002-06-12 at 07:11, Daniel Karrenberg wrote: > > At 06:00 AM 6/12/2002, Geoff Huston wrote: > > >However, the distinction between "ALLOCATED" and > "ASSIGNED" is perhaps a bit subtle. > > > > When these attributes were created, those particular words > were in deemed both descriptive and clear. > > Maybe the language concerned has shifted underneath in the > meantime ;-). > > As a native speaker of one of its dialects, would you make > a suggestion for improvement? > > Well actually as a native speaker of (another) of its dialects, > I've never considered the distinction of ALLOCATED and ASSIGNED to > be other than subtle. I'd much prefer DELEGATED and ASSIGNED or > some such. This may be a matter of taste however. I tend to agree with Nigel, although I'd go for something even plainer like DELEGATED-TO-LIR and ASSIGNED-TO-END-USER (I know they're a bit verbose but they're absolutely clear ;-) It also makes clear that addresses assigned to an LIR in the role of END-USER are exactly that. That way, an individual who is struggling with English as a second language (or even their first language ;-) can be absolutely clear of the status of a range of addresses. Just my two pence... Regards, Guy -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.1 iQA/AwUBPQca4I3dwu/Ss2PCEQJv6ACeMa1ZbnoN3P7r6VaBANGPa1yXN9UAoMLQ cJpgKn6FvDPmyD1X02WLXJF3 =yl1x -----END PGP SIGNATURE----- This e-mail is private and may be confidential and is for the intended recipient only. If misdirected, please notify us by telephone and confirm that it has been deleted from your system and any copies destroyed. If you are not the intended recipient you are strictly prohibited from using, printing, copying, distributing or disseminating this e-mail or any information contained in it. We use reasonable endeavors to virus scan all e-mails leaving the Company but no warranty is given that this e-mail and any attachments are virus free. You should undertake your own virus checking. The right to monitor e-mail communications through our network is reserved by us.

8 7

New Document available: RIPE-239
by RIPE NCC Document Announcement Service 14 Jun '02

14 Jun '02

New/Revised RIPE Document Announcement -------------------------------------- A revised/new document is available from the RIPE document store. "New Values of the "status:" Attribute for Inetnum Objects (LIR-PARTITIONED) (ripe-239)" Short content description ------------------------- This document describes the new value of the "status:" attribute for inetnum objects and its impact on the RIPE Database operation. Accessing the RIPE document store --------------------------------- The document is on-line at the following URL: http://www.ripe.net/ripe/docs/lir-partitioned.html The RIPE document store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs/. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-239.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-239.txt plain text version Kind Regards, RIPE NCC Document Announcement Service

1 0

RE: [apnic-talk] Status field for inet6num objects
by Michael.Dillon＠radianz.com 13 Jun '02

13 Jun '02

>For me these two phrases, DELEGATED-TO-LIR and >ASSIGNED-TO-END-USER, hit the spot precisely! >excellent suggestion Guy! >Is it appropriate to request consideration of these terms as replacements >for ASSIGNED and ALLOCATED? Wouldn't it be a good idea to standardize the terminology with ARIN and others? In that case, the term LIR would be considered obscure and meaningless. Since all LIRs are service providers of some sort, either ISPs or an internal network service provider, I think that a standard terminology should try to use generic terms. That would mean either DELEGATED-TO-SVC-PROVIDER or DELEGATED-TO-NSP if you like acronyms (Network Service Provider). In any case, because the distinction between "allocated" and "assigned" has been unclear in the past and because there is a significant shift in terminology from "allocated" to "delegated" this change should be incorporated in an informational RFC. This document would help in clarifying that there is indeed a difference between the two states of an address block and would also help in promoting the use of this terminology amongst the community that deal with IP address delegations and assignments. DELEGATED-TO-NSP and ASSIGNED-TO-USER are two terms that would be clear worldwide. Michael Dillon Network Product Engineering Radianz

2 1

Re: [apnic-talk] Status field for inet6num objects
by Geoff Huston 13 Jun '02

13 Jun '02

>To clarify, the values that APNIC would prefer to use are: > >ALLOCATED PORTABLE >ALLOCATED NON-PORTABLE >ASSIGNED PORTABLE >ASSIGNED NON-PORTABLE > >As I mentioned before, these values would be consistent with those in >IPv4 (which take effect in August when the migration to version 3 of the >RIPE database is complete). > >Comments? I would be in favour of this clarity in the field regarding PORTABLE and NON_PORTABLE. However, the distinction between "ALLOCATED" and "ASSIGNED" is perhaps a bit subtle. regards, Geoff

6 5

Re: [hostmaster-staff] Re: [apnic-talk] Status field for inet6num objects
by Michael.Dillon＠radianz.com 13 Jun '02

13 Jun '02

>Allocation and assign do have definitions - could these be improved >to clarify the meaning? Or does 'delegate' simply convey a much >clearer intention with the address space? Delegation is clearer for two reasons. Firstly, it implies that the the delegator is passing on some responsibility for the address space. The organization receiving a delegation is responsible for managing and administering the addresses. In the case of an assignment, this is less true. For instance, ISPs regularly reassign addresses after a customer disconnects and everyone seems to understand that addresses assignments are controlled by the assigner and can be withdrawn. The second reason has more to do with psychology. Because the terms "allocation" and "assignment" are similar in meaning and visually similar, they are easily confused by a lot of people. They both begin with "a" followed by a double consonant and end with a latin suffix. Of course, clear definitions are always a good thing as well. Michael Dillon Network Product Engineering Radianz

1 0

RE: [apnic-talk] Status field for inet6num objects
by kevin.bates＠bt.com 12 Jun '02

12 Jun '02

seems better but not perfect - the important thing is to get all databases looking the same and using the same terms? strictly speaking it is not "ASSIGNED-TO-END-USER" its "ASSIGNED-TO-SUBNET-USER" for example it could be part of a DHCP dial up pool and thus only " leased" for the duration of that connexion. > At 11:56 AM 6/12/2002, Guy Davies wrote: > >I tend to agree with Nigel, although I'd go for something even > >plainer like DELEGATED-TO-LIR and ASSIGNED-TO-END-USER (I know > >they're a bit verbose but they're absolutely clear ;-) It also makes > >clear that addresses assigned to an LIR in the role of END-USER are > >exactly that. That way, an individual who is struggling with English > >as a second language (or even their first language ;-) can be > >absolutely clear of the status of a range of addresses. > > This is an excellent idea. However I would use > ALLOCATED_TO_LIR and ASSIGNED_TO_END_USER. > That way we clarify the subtle difference while > maintaining consistency with existing documentation. > > (If I remember correctly the term DELEGATED was suggested at the time, > but not used because of its usage in the DNS context as well as > the connotation of total transfer of authority over the resource which > is not quite the case.) > > Daniel

2 1

RE: [apnic-talk] Status field for inet6num objects
by Geoff Huston 12 Jun '02

12 Jun '02

> > This is an excellent idea. However I would use > > ALLOCATED_TO_LIR and ASSIGNED_TO_END_USER. > > That way we clarify the subtle difference while > > maintaining consistency with existing documentation. > > > > (If I remember correctly the term DELEGATED was suggested at the time, > > but not used because of its usage in the DNS context as well as > > the connotation of total transfer of authority over the resource which > > is not quite the case.) To me "DELEGATED-TO-LIR" makes sense, as it infers that the process of further delegation can be used with sub-blocks and/or atomic units can be "ASSIGNED-TO-END-USERs with the inference that no further sub assignments are anticipated. Geoff

1 0

RE: [apnic-talk] Status field for inet6num objects
by Michel Py 11 Jun '02

11 Jun '02

> Anne Lord wrote: > There is no PI in IPv6. > This can't be said often enough. We are working on two new types of v6 addresses that are neither PA nor PI for multihoming. Please keep in mind that PA does not provide enough functionality; if no multihoming protocol is released in a timely manner you will inevitably have PI, or whatever you want to call everyone becoming a LIR. Michel.

1 0

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

Transferring InterNIC space from ARIN Database to other RIR databases
by Joao Luis Silva Damas 26 Apr '02

26 Apr '02

Dear all, Sometime ago we started a thread about distributing address space issued prior to the existence of the RIRs, which is currently registered at the ARIN database (imported from the InterNIC's database), to the RIR that now operates in the region where the address space is registered as used. Doing this would simplify processes such as modifying the name servers for in-addr.arpa for those addresses, changing contact information, etc as the user will issue requests for change to the RIR in their region, the one with which they will normally be more familiar. Both ARIN and the RIPE NCC are now ready to proceed with this. There are some aspects, however, where community input is required and I would like to ask you to comment on the proposal below. Note: the examples at the bottom are just examples. We do not want to imply there is anything wrong with the objects mentioned. Best regards, Joao Damas RIPE NCC -------------------------------------------- Proposed procedure for migration of legacy objects from ARIN Database When moving data from the ARIN database into the RIPE Database the situation is not, unfortunately, always without conflicts. Some data that is in the ARIN database also has an entry in the RIPE database. While the ARIN database is the one which contains the authoritative information for the set of name servers used in in-addr.arpa resolution for the addresses in question (the in-addr.arpa zone file is generated from that data), sometimes the administrative contacts seem to be more up to date in the RIPE database. Below are a set of proposals for actions when transferring the data: I. inetnum objects 1. There are several types of conflicts with the data in the RIPE Database: 1.1 Exact matches with RIPE networks (4325) *Proposal: to override data in the RIPE Database with ARIN's. If the object in the RIPE database has a "changed" date more recent than the object in the ARIN database, contact information from the RIPE database is kept and the nameservers are the ones in the ARIN database. 1.2 ARIN network contains a RIPE network(s) (169) 1.2.1. ARIN's allocation, while multiple assignments are registered in the RIPE Database *Proposal: to keep RIPE's and ARIN's data 1.2.2. Minor Mismatch *Proposal: to override data in the RIPE Database with ARIN's 1.3 ARIN network is contained in a RIPE network (3060) *Proposal: to keep ARIN's data and delete RIPE network 1.4. Objects in the ARIN database only *Proposal: to put ARIN's data in the RIPE Database 2. Protection of the transferred inetnums *Proposal: To create a mntner object for each ARIN's 'coordinator'. Syntax could be: mntner: <coord hic hdl>-MNT mnt-by: <coord hic hdl>-MNT auth: MAIL-FROM <coord e-mail address> ... Then we protect inetnums 'owned' by the coordinator with this maintainer. Should be the same level of security as currently at ARIN. Note: it could be different if the POC is merged/replaced by existing RIPE person object (see further discussion). II. POC objects 1. Try to match POCs from ARIN DB to the existing person objects in the RIPE DB (762) The implication is that we use the person's e-mail address as authorization (see proposal above) * Proposal: to contact all affected persons in advance and have a more clear picture before the transfer. Questions to ask: - Do both records represent the same person? - Would (s)he like to merge the contact data, in what manner? After an answer to these questions is received: - Discuss protection issue (existing maintainer, coordinator's maintainer, auth). Needs human work. 2. Protection of the transferred POCs * Proposal: to add mnt-by referencing a respective coordinator's maintainer. ---------------- Examples I.1.2.1 inetnum: 130.242.0.0 - 130.243.255.255 netname: SUNETREGAB-RIPE descr: European Regional Internet Registry/RIPE NCC descr: These addresses have been further assigned descr: to European users. Contact information can descr: be found in the RIPE database at whois.ripe.net country: NL admin-c: RIPE-NCC-ARIN rev-srv: sunic.sunet.se rev-srv: falun.dns.swip.net rev-srv: ns.ripe.net status: ALLOCATION changed: hostmaster(a)arin.net 20000329 source: ARIN ... inetnum: 130.242.43.0 - 130.242.43.255 netname: SE-TEKNISKAMUSEET descr: Tekniska Museet country: SE admin-c: HALI1-RIPE tech-c: HALI1-RIPE status: ASSIGNED PA mnt-by: SUNET-MNT changed: fredrik(a)sunet.se 19981022 source: RIPE inetnum: 130.242.48.0 - 130.242.48.255 netname: SE-ARMEMUSEUM descr: Statens Forsvarshistoriska Museer country: SE admin-c: BOMI1-RIPE tech-c: LEPE1-RIPE status: ASSIGNED PA mnt-by: SUNET-MNT changed: fredrik(a)sunet.se 19981022 source: RIPE ... I.1.2.2 inetnum: 131.117.0.0 - 131.117.128.255 netname: ZUERI descr: Municipality of Zuerich descr: Wilhelmstr. 10 descr: Zurich, 8021 descr: CH country: CH admin-c: BM153-ARIN status: ASSIGNMENT changed: hostmaster(a)arin.net 19980824 source: ARIN inetnum: 131.117.0.0 - 131.117.127.255 netname: ZUERI-NET descr: Municipality of Zuerich descr: Zuerich, Switzerland country: CH admin-c: BM16-RIPE tech-c: BM16-RIPE changed: huber(a)switch.ch 19950412 source: RIPE I.1.3 inetnum: 130.138.0.0 - 130.140.255.255 netname: PHILIPS descr: Philips C&P/NBS descr: Eindhoven country: NL admin-c: HS6189-RIPE tech-c: HS6189-RIPE notify: H.Sanders(a)mpn.cp.philips.com changed: geertj(a)ripe.net 19940106 changed: H.Sanders(a)mpn.cp.philips.com 19960131 changed: ripe-dbm(a)ripe.net 19990706 changed: ripe-dbm(a)ripe.net 20000225 source: RIPE inetnum: 130.138.0.0 - 130.138.255.255 netname: PHILIPS-SERI-1 descr: Philips Components BV descr: Building BC136 descr: Hurkesestraat 9 descr: 5600 MD Eindhoven descr: THE NETHERLANDS country: NL admin-c: OK6-ARIN status: REASSIGNMENT changed: hostmaster(a)arin.net 19930413 source: ARIN II.1 person: Antonio_Blasco Bonito address: Rodinet S.a.s. address: Via Cavour 6 address: I-54033 Carrara address: Italy phone: +39 0585 779435 fax-no: +39 0585 757385 e-mail: Antonio-Blasco.Bonito(a)rodinet.com nic-hdl: ABB2 changed: blasco(a)rodinet.com 19990310 source: RIPE person: A. Blasco Bonito address: GARR-NIS address: c/o CNR-Istituto CNUCE address: via Santa Maria 36 phone: +39 50 593246 fax-no: +39 50 904052 e-mail: bonito(a)NIS.GARR.IT nic-hdl: ABB2-ARIN changed: hostmaster(a)arin.net 19931201 source: ARIN

6 6

Announcement: IRRToolSet version 4.7.2 released.
by Katie Petrusha 25 Apr '02

25 Apr '02

[ Apologies for duplicate mails ] Dear collegues, We are pleased to announce the release of Version 4.7.2 of the IRRToolSet, formerly known as RAToolSet. Changes: - aoe is back and working, RPSL compliant - several bugfixes in roe/RtConfig/prpath have been made You can download this release by anonymous FTP from the following URL: ftp://ftp.ripe.net/tools/IRRToolSet/IRRToolSet-4.7.2.tar.gz You may also want to check IRRToolSet page: http://www.ripe.net/ripencc/pub-services/db/irrtoolset/index.html The mailing list archive is available here: http://www.ripe.net/ripencc/mail-archives/irrtoolset/index.html We want to thank everyone participated in testing and sending us suggestions and bug reports. We appreciate your help and feedback. If you have any questions, please don't hesitate to contact katie(a)ripe.net. -- Kind regards, Katie Petrusha RIPE NCC

1 0