- db-wg - mailman.ripe.net

draft agenda (v1), for DB-WG meeting, RIPE 46, Amsterdam, NL
by Wilfried Woeber, UniVie/ACOnet 22 Aug '03

22 Aug '03

Dear WG list members, dear "Meeting Role" @ the NCC, dear WG-Chairs! Attached please find the 1st draft: Proposed Agenda for the DB-WG Meeting at RIPE 46 in Amsterdam, NL. As usual, if you have any comments, corrections or additions please get back to me directly and asap. As we do have 2 slots this time - which are _not_ adjacent (on different days!) Verion 2 will try to sort the items into the bins for day 1 (Wed., 14:00 - 15:30) and day 2 (Thursday 9:00 - 10:30) NOTE: I have seen some discussion about the ERX, so I'm trying to offer the opportunity for the community affected to give short (if possible ;-) presentations about - experience, - expectation, - suggestiosn for improvement, after an intro provided by the RIPE NCC (from their point of view). If you intend to do that, pls. let me know before the start of the session! Looking forward to see many of you in Amsterdam, Wilfried. ______________________________________________________________________ Proposed Agenda for the Database Working Group Meeting 1. Draft approx. A. Administrative stuff (WW, chair) 10 min . scribe: N.N. B. Action Items 15 min C. WG mandate and charter, part I (WW, chair) 10 min . splitting the load between DB, Services, and? D. DB operational update (RIPE NCC, Shane K.) 20 min E. ERX status 30 min . status as from the point of view of the NCC 5 min . short reports about experience 20 min . proposals for improvements? 5 min F. The "status:" attribute (RIPE NCC, N.N.) 15 min G. The org: Object proposal revised (RIPE NCC, Engin G.) 15 min H. Revised PKI proposal (RIPE NCC, Shane K.) 30 min I. WG mandate and charter, part II (WW, chair) 10 min . review of alignement with other WGs . summary . editorial finalisation Y. Input from other WGs . Z. AOB: . tent.: review of DB Architecture and Assumptions . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WW, 22-AUG-2003 10:40:44 UTC _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Only one thing in life is certain: init is Process #1"

1 0

call for agenda items, DB-WG meeting, RIPE 46 @ AMS, NL
by Wilfried Woeber, UniVie/ACOnet 21 Aug '03

21 Aug '03

"Somewhat" urgent: Call for agenda items! >Date: Tue, 12 Aug 2003 12:01:21 +0200 > >Dear WG Chair, > >We are less than three weeks away from the RIPE Meeting. To make sure >that we have all Working Group Agendas published and printed on time, I >kindly ask you to send us your agenda. > >The deadline is Wednesday 20 August. Although the deadline has passed already (and I am wading through and sorting and trashing a mail backlog of 5K+), we need an agenda for the WG meeting. I am going to include the "usual stuff" from my end, plus an item for discussion on WG mandate. And I have (during my absence for vacation - which I dearly needed ;-) received a couple of requests already which will make it into the 1st draft. Everything alse has to come from the community, so submit your input and ideas, please!! Thanks, see you in AMS, Wilfried.

1 0

Fwd: [db-wg] X.509 authentication in the RIPE Database, take II
by Joao Luis Silva Damas 20 Aug '03

20 Aug '03

On Friday, August 15, 2003, at 04:23 PM, Shane Kerr wrote: > Joao, > > Joao Luis Silva Damas wrote: >> adding a new strong authentication method to the Database, is in my >> own personal opinion, a good thing(tm), particularly if the same >> credential can be used for other interactions with the RIPE NCC, make >> user's life easier. >> I wonder however about a few questions: >> - will this auth method be available only to RIPE NCC members? Is it >> not seen as a valuable general addition for non-member users of the >> IRR part of the RIPE DB? > > Initially it will only be available for RIPE NCC members. Another interesting change in the model? When you say initially, does this mean it will be extended or not? Shall on read the current proposal as implicitly stating this? > There are three ways we could extend the service to non-LIRs: > > 1. Accept certificates from certain "well-known" CAs, for example > Thawte, Verisign, etc. > > 2. Issue certificates from a RIPE NCC CA established for this purpose, > and accept them. > > 3. Accept all certificates, including self-signed certificates. > > #1 is relatively easy - the main overhead would be maintaining the > Certificate Revokation Lists from the CAs. Deciding which CAs to > support may also be tricky. #2 is also relatively easy, since we > already have the technology. #3 is more difficult, and would require > a slight change of the design, and administration issues (see below). For DB authentication purposes, why do you need to verify the certificate? As with the PGP model[1], the only assumption one needs to make is that the message issuer is the holder of the private part of the certificate. If the RIPE DB is going to start making assertions about the real identity of the message sender, rather than just authorise or refuse updates, this seems to be a change in the model that warrants discussion in the working group. Is this so, or am I misinterpreting your description of the mechanism? > >> - Why the choice of not publishing the pulic part of the certificated >> in the DB? The choice to have a key-cert for the PGP method was not >> to do with issues of web of trust but rather for purposes of helping >> the users with their data maintenance. As a matter of fact the >> recommendation regarding the use of PGP in the RIPE DB, as described >> in the RFC and the minutes of the DBSEC TF, was to use a PGP key for >> this purpose that was not used elsewhere. > > When you receive a PGP-signed message, you need the public key of the > signer to verify the signature. The program that updates the Database > needs this information, and it is stored in the key-cert objects(*). > > With S/MIME, the certificate is sent with the message, and this > certificate is signed by the CA. Since the database is configured to > know how to verify certificates issued by specific CAs, we can verify > the signature. No key-cert is necessary. > > But if we decide to allow any certficate, including self-signed, then > we need some way to allow users to store this information in the > database, for example key-cert objects. Unfortunately, this may cause > problems, because (for instance) someone could create a key-cert > object for a CA run by another organisation with bogus data, > preventing users from using certificates *actually* issued by that CA. > > We could possibly require these sort of key-cert objects be reviewed > by some method, for example RIPE DBM. However, if the RIPE NCC has no > relationship with the CA, we have no real way to know the validity of > any one request. Why do you need to verify the certificate. Also, part of the idea of having a key-cert object was to allow users to check, not the DB, and to maintain DB self-consistency. Are these no longer desired features? Joao [1] RFC 2726

3 2

Re: [address-policy-wg] IP Addressing policy on personal contact info (kf)
by Shane Kerr 20 Aug '03

20 Aug '03

Pascale Julienne, Pascal Julienne wrote: > In France there is such a thing as unlisted phone numbers which > remain private and unknown. Further, the RIPE DB is becoming the > best spam list in the world. So yes, responsability lays with LIR, > yes let's clean the DB, yes respect privacy. I think there are two sides to this issue. One is what the RIPE NCC can and has done to increase the privacy of people who have contact information in the Database. We have been trying to increase the privacy protections in the Database over time: - person/role objects removed from public FTP site - DB automatically rate limits access to person/role objects - mntner/irt objects removed from public FTP site - .DE person object deletion - automatic cleanup of unreferenced person/role objects The Allocation Editor on the LIR Portal should allow LIRs to keep their contact data up-to-date. We have talked with the Dutch Data Protection Authority about the Database as well, to make sure that we don't run afoul of the EU privacy directives. There has been some discussion at the last RIPE meeting about how the Database both aids and hinders spammers. Suggestions such as checking validity of contact information, as well as possibly putting fake entries in the Database and tracking spam they receive were mentioned. The second issue is deciding on what contact data *should* be in the Database. This is the job of the address-policy-wg, and perhaps the db-wg. A related issue is how the data should be accessed, which is also something that can be decided by the same groups. Katri Forsberg did a service by raising the issue. As a final issue, I am curious why you say the RIPE Database is becoming the best spam list in the world! I think that it probably generates a lot of spam for LIRs, because they have their contact information on many objects in the Database. I don't know any way to avoid this if the Database is public. I hope that for the end users who's information is in the Database for only a small number of addresses that they do not get much spam originating from the publication in the Database. The RIPE NCC is certainly interested in mechanisms that we can set up to prevent such use, as it is explicitly *not* allowed by the license that we provide for the Database. -- Shane Kerr RIPE NCC

5 4

X.509 authentication in the RIPE Database, take II
by Shane Kerr 18 Aug '03

18 Aug '03

All, [Apologies for duplicate e-mails] Attached please find a proposal for X.509 authentication in the RIPE Database. From the Database point of view (that is, syntax and semantics), it is the same as the one sent 3 July 2003. The difference is that it contains only the specific details of the change, in a straightforward fashion. I hope that we have addressed questions about the use of X.509 that arose in earlier discussions. -- Shane Kerr RIPE NCC Addition of X.509 authentication to the Database Proposal: To add an X509 authentication type to the "auth:" attribute. Attributes with this type will use the Distinguished Name (DN) of the certificate to identify it. Motivation: X.509 allows a single authentication method to work for both e-mail and the web. LIRs can receive an X.509 certificate through the LIR Portal, and should be able to use this to update records they control in the Database. X.509 is "strong", like PGP, although a different trust model is used. Details: The "auth:" attribute of the mntner class will have a new authentication scheme, X509. The DN, as defined in RFC 2253, will be used to identify the specific certificate used. Note that there is no key-cert object for the X509 scheme. Instead, the certificate must be signed by a trusted authority. The trusted authority will be the RIPE NCC Certificate Authority (CA) that is currently only available to LIRs. It is possible to configure additional CAs in future, should this become desirable. For instance, existing commercial CAs could be allowed, or the RIPE NCC could create a CA to issue certificates to non-LIRs for this purpose only. Below is an example of a maintainer with X.509 authentication: mntner: EXAMPLE-MNT descr: Sample maintainer for example. admin-c: SWK1-RIPE tech-c: RD132-RIPE tech-c: HOHO-RIPE upd-to: ripe-dbm(a)ripe.net mnt-nfy: ripe-dbm(a)ripe.net auth: X509 C=NL, O=RIPE NCC, OU=Members, CN=zz.example.user1 auth: X509 C=NL, O=RIPE NCC, OU=Members, CN=zz.example.user2 notify: ripe-dbm(a)ripe.net mnt-by: EXAMPLE-MNT referral-by: RIPE-DBM-MNT changed: ripe-dbm(a)ripe.net 20030813 source: RIPE Usage: E-mail updates for objects maintained by a maintainer with X509 authentication must be sent in S/MIME format and signed (not encrypted) using the private key associated with the issued certificate. Synchronous updates for objects maintained by a maintainer with X509 authentication must use an SSL connection using the private key from the issued certificate on the client side. Web updates for objects maintained by a maintainer with X509 authentication can use a browser with the certificate loaded. The web updates screens will allow users to specify that they want to identify themselves using the client-side private key, over an SSL connection.

3 3

Draft: "status:" re-evaluation
by Shane Kerr 15 Aug '03

15 Aug '03

All, We recently proposed changes to the "status:" attribute values in the RIPE Database: http://www.ripe.net/ripe/draft-documents/status-attributes.html We have received input from APNIC on the subject. They proposed a simpler layout, and we think their suggestion makes sense. However, we would like to go forward with a slightly modified version that incorporates the "organisation" object we are working on. In the meantime, we do not want to delay the implementation of the Sub-Allocation policy. For that reason we'd like to have an interim status attribute value for that. Proposal: Add "SUB-ALLOCATED PA" to the allowed "status:" values. "SUB-ALLOCATED PA" inetnum object may have an "ALLOCATED PA" or an "LIR-PARTITIONED PA" less specific inetnum object. A range of IP's can only have a single "SUB-ALLOCATED PA" in it. That is, you cannot sub-allocate twice. -- Shane Kerr RIPE NCC

6 9

RIPE Whois Server version 3.2.0
by DB-News 14 Aug '03

14 Aug '03

Dear Colleagues, [ Apologies for multiple messages. ] The RIPE NCC is pleased to announce the release of version 3.2.0 of the RIPE Whois server. This software is compliant with both RPSL (RFC-2622) and RPS-Security (RFC-2725). This release adds several user-visible improvements: - dbupdate has been rewritten almost from scratch - the server now limits the number of concurrent connections per IP - transaction support is added on MySQL side - query parsing is revised Detailed release notes can be found at the following URL: ftp://ftp.ripe.net/ripe/dbase/software/RELEASE-NOTES-3.2.0 You can download this release by anonymous FTP from the following URL: ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-3.2.0.tar.gz If you have any questions, please don't hesitate to contact <ripe-dbm(a)ripe.net>. Best regards, Engin Gunduz RIPE NCC Database Group

5 6

Announcement Routing Registry Training Course
by RIPE NCC Training 13 Aug '03

13 Aug '03

------- Apologies for the previous mail as there was an error in mentioned dates. Please find the correct dates in this mail. **** Dear Colleagues, [apologies for duplicate postings] As a service to its members the RIPE NCC offers the "Routing Registry Training Course". The main objective of the "Routing Registry Training Course" is to familiarise the LIRs with the features of the Routing Registry, while introducing the relevant tools and services of the RIPE NCC. The course also offers practical exercises. OVERVIEW OF TOPICS COVERED IN THE COURSE: - Routing Registry as a part of the RIPE Whois Database and the Internet Routing Registry (IRR) - Specifying routing policies using (RPSL) Routing Policy Specification Language and the RtConfig tool - IRRToolSet - Routing Information Service (RIS) - Routing Registry Consistency Check Project Please note that this is an advanced course. It will: - NOT teach the basics of routing - NOT teach the basics of RIPE Database operations, - NOT describe how to receive Internet resources from the RIPE NCC - NOT describe how to operate a Local Internet Registry (LIR) The target audience of the course are technical staff of LIRs: e.g. network operators, engineers etc. This course is not intended for administrative or management staff (e.g. Hostmasters) . It is assumed that all attendees will be familiar with Border Gateway Protocol routing and with the RIPE Database (i.e. creating/modifying objects). This course is based on interactive exercises in a local network set-up. Please bring your laptops equipped with the following: - A working Ethernet card, - Three meters of Ethernet cable, - A secure connection client, - A web browser. Please be prepared to share your laptop (or at least allow another attendee to "look over your shoulder") if necessary. The Routing Registry Training Course is conducted in the English language and is free of charge, since it is covered by the membership fee. More information about the Routing Registry Training Course can be found at: http://www.ripe.net/training/rr/ REGISTRATION: You can register for a Routing Registry Training Course at the following URL: http://www.ripe.net/cgi-bin/trainingform.pl.cgi Or by completing the registration form at the end of this e-mail and replying to <training(a)ripe.net> . In order to register for a Routing Registry Training Course you must be an employee of an LIR and either: - be an LIR contact - be confirmed by an LIR contact LIR contacts are those employees of an LIR who are registered with RIPE NCC as authoritative contact persons. It is expected that most of those interested in the Routing Registry Training Course will not be an authoritative contact person for their LIR, and therefore will be, refused by the course registration "robot". In order to be admitted to the course, a confirmation e-mail must be sent to <training(a)ripe.net>. Please approach the LIR contacts from your organisation personally, since the identity of LIR contacts is confidential, and the RIPE NCC is unable to divulge contact persons for any given LIR. Kind Regards, The RIPE NCC Training Team ************************************************************************* COURSE DATES AND VENUES ======================== Date: Friday 29 Augustus 2003 Time: 0900 - 1700 Location: Helsinki, Finland AND: Date: Monday 8 September 2003 Time: 0930 - 1700 Location: Amsterdam, The Netherlands AND: Date: Tuesday 21 October 2003 Time: 0900 - 1700 Location: Geneva, Switzerland AND: Date: Friday 14 November 2003 Time: 0900 - 1700 Location: Paris, France AND: Date: Friday 28 November 2003 Time: 0900 - 1700 Location: Moscow, Russia AND: Date: Friday 12 December 2003 Time: 0900 - 1700 Location: Lisbon, Portugal ************************************************************************* REGISTRATION FORM ================= %START PART 1 - Registration 1) Your name Enter First name, Last name in full e.g. John Doe Mary-Beth Walton # NAME [ ] 2) Your Registry ID (format: country-code.<name of registry>) # REG [ ] 3) Your e-mail address # EMAIL [ ] 4) Your NIC handle (optional) # NICHANDLE [ ] 5) The course you plan to attend (date and location) # COURSE [ ] %END

1 0

mnt-routes attribute in aut-num objects
by Frank Bohnsack 07 Aug '03

07 Aug '03

Dear Colleagues, how exactly is this meaning of MNT-ROUTES in AUT-NUM objects in case of routes object creation/modification ? RFC2725 is not realy detailed here. Means the existance of an MNT-ROUTES attribute in an AUT-NUM object that ONLY this/these referenced maintainer(s) will be able to authorized route creation/modification and the referenced MNT-BY maintainer(s) will not be used? Or should not the MNT-BY maintainer(s) checked if all MNT-ROUTES maintainer(s) authorisation fails? The current RIPE software checks MNT-ROUTES maintainers only. Thanks Frank > > From: "Frank Bohnsack" <Frank.Bohnsack(a)deu.mci.com> > > Subject: LONGACK > > Date: Mon, 4 Aug 2003 23:42:06 +0200 > > Reply-To: Frank.Bohnsack(a)deu.mci.com > > Message-ID: <FAEKJBKGENGFILMMECELOEHICAAA.Frank.Bohnsack(a)deu.mci.com> > > ... > > DETAILED EXPLANATION: > > > ***Warning: Invalid keyword(s) found: LONGACK > ***Warning: All keywords were ignored > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > The following object(s) were found to have ERRORS: > > > --- > Create FAILED: [route] 139.8.32.0/24AS702 > ***Error: Authorisation failed > ***Info: Syntax check passed > > route: 139.8.32.0/24 > descr: DE PI route > origin: AS702 > member-of: AS702:RS-DE, > AS702:RS-DE-PI, > AS702:RS-DE-PULLUP > mnt-by: WCOM-EMEA-RICE-MNT > changed: rice(a)lists.mci.com 20030804 > source: RIPE > > ***Info: Authorisation for parent [route] 139.8.0.0/16AS702 > using mnt-by: > authenticated by: WCOM-EMEA-RICE-MNT > > ***Info: Authorisation for origin [aut-num] AS702 > using mnt-routes: > not authenticated by: UUNETDK-MNT, AS1270-MNT, AS1849-MNT, > AS1890-MNT, IWAY-NOC, AS702-MNT, SE-UUNET-MNT, UUNETDE-I > > ***Info: Authorisation for [route] 139.8.32.0/24AS702 > using mnt-by: > authenticated by: WCOM-EMEA-RICE-MNT > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > For assistance or clarification please contact: > RIPE Database Administration <ripe-dbm(a)ripe.net> > > > >

2 1

Announcement on parent notifications
by Denis Walker 05 Aug '03

05 Aug '03

Colleagues, Notification on more-specific object creation authorisation ----------------------------------------------------------- The latest dbupdate binary to be put into production has implemented the change regarding parent notifications that was proposed to the Database Working Group in March 2003. This will cause some users to receive additional notifications. A summary of the change is outlined below. When the creation of an object requires authorisation by a less-specific object, normal notification rules apply to the mntner(s) in the less-specific object. In other words, "upd-to:" is notified of failure, and "mnt-nfy:" is notified of success. Where there are multiple maintainers, only one is needed to successfully authorise the creation, but all the maintainers in the list will be notified. For example: inetnum: 192.168.0.0 - 192.168.255.255 . . . mnt-by: EXAMPLE-MNT mnt-lower: ANOTHER-MNT mnt-lower: YET-ANOTHER-MNT If the successful creation of the more specific inetnum: inetnum: 192.168.201.0 - 192.168.201.255 . . . mnt-by: SOME-MNT Is authorised by YET-ANOTHER-MNT in the less specific inetnum, notifications will be sent to the "mnt-nfy:" listed in both ANOTHER-MNT and YET-ANOTHER-MNT in addition to the "mnt-nfy:" listed in SOME-MNT. In the case of route creation, the parent may be a route or an inetnum, and it may also be an exact match. Also notifications will also be sent to the mntner(s) listed in the origin aut-num of the route object being created. The original proposal can be found here: http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00034.html Regards Denis Walker Database Engineer RIPE NCC

1 0

Re: mnt-routes attribute in aut-num objects
by RIPE Database Administration 05 Aug '03

05 Aug '03

Dear Frank, As RFC2725 says on page 18: Having found the AS and either a route object or inetnum, the authorization is taken from these two objects. The applicable maintainer object is any referenced by the mnt-routes attributes. If one or more mnt-routes attributes are present in an object, the mnt- by attributes are not considered. In the absence of a mnt-routes attribute in a given object, the mnt-by attributes are used for that object. The authentication must match one of the authorizations in each of the two objects. I.e. if "mnt-routes" attribute is present, then at least one of mainatiners from "mnt-routes" should pass the authorisation. If none of them passes, the creation is refused - no further check is done with "mnt-by" attribute in case of "mnt-routes" failure. "mnt-by" attribute is used only if "mnt-routes" is not present. This applies only to route object creation. For route object modification only "mnt-by" of the object itself is used to check the authorisation. If you have any more questions, please contact <ripe-dbm(a)ripe.net>. Regards, Katie Petrusha ____________________________ RIPE Database Administration. Original message follows: ------------------------ Dear Colleagues, how exactly is this meaning of MNT-ROUTES in AUT-NUM objects in case of routes object creation/modification ? RFC2725 is not realy detailed here. Means the existance of an MNT-ROUTES attribute in an AUT-NUM object that ONLY this/these referenced maintainer(s) will be able to authorized route creation/modification and the referenced MNT-BY maintainer(s) will not be used? Or should not the MNT-BY maintainer(s) checked if all MNT-ROUTES maintainer(s) authorisation fails? The current RIPE software checks MNT-ROUTES maintainers only. Thanks Frank > > From: "Frank Bohnsack" <Frank.Bohnsack(a)deu.mci.com> > > Subject: LONGACK > > Date: Mon, 4 Aug 2003 23:42:06 +0200 > > Reply-To: Frank.Bohnsack(a)deu.mci.com > > Message-ID: <FAEKJBKGENGFILMMECELOEHICAAA.Frank.Bohnsack(a)deu.mci.com> > > ... > > DETAILED EXPLANATION: > > > ***Warning: Invalid keyword(s) found: LONGACK > ***Warning: All keywords were ignored > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > The following object(s) were found to have ERRORS: > > > --- > Create FAILED: [route] 139.8.32.0/24AS702 > ***Error: Authorisation failed > ***Info: Syntax check passed > > route: 139.8.32.0/24 > descr: DE PI route > origin: AS702 > member-of: AS702:RS-DE, > AS702:RS-DE-PI, > AS702:RS-DE-PULLUP > mnt-by: WCOM-EMEA-RICE-MNT > changed: rice(a)lists.mci.com 20030804 > source: RIPE > > ***Info: Authorisation for parent [route] 139.8.0.0/16AS702 > using mnt-by: > authenticated by: WCOM-EMEA-RICE-MNT > > ***Info: Authorisation for origin [aut-num] AS702 > using mnt-routes: > not authenticated by: UUNETDK-MNT, AS1270-MNT, AS1849-MNT, > AS1890-MNT, IWAY-NOC, AS702-MNT, SE-UUNET-MNT, UUNETDE-I > > ***Info: Authorisation for [route] 139.8.32.0/24AS702 > using mnt-by: > authenticated by: WCOM-EMEA-RICE-MNT > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > For assistance or clarification please contact: > RIPE Database Administration <ripe-dbm(a)ripe.net> > > > >

1 0

Release of prototypes of RPSLng IRRToolSet and Whois Server
by DB-News 30 Jul '03

30 Jul '03

[ Apologies for multiple messages ] Dear Colleagues, The RIPE NCC is pleased to announce version 4.8.0 prototype release of IRRToolSet, and version 0.1 prototype release of RIPE Whois Server Software containing RPSLng extensions. RPSLng is an effort to extend RPSL language, enabling the language to document routing policies for the IPv6 and multicast address families currently used on the Internet. The prototype of IRRToolSet implements the Internet Draf Document draft-blunk-rpslng-01 (http://www.ietf.org/internet-drafts/draft-blunk-rpslng-01.txt). The prototype release contains peval and rpslcheck that already work with a new dictionary (you can also try the Web prototype for peval). Currently work is in progess to make other tools RPSLng compatible. More details can be found at: http://www.ripe.net/db/irrtoolset The source code of version 0.1 prototype release of RIPE Whois Server Software can be found at ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-RPSLNG.0.1.tar.gz More details can be found at http://www.ripe.net/db/rpslng . Please contact dbtools(a)ripe.net for any comments. -- Best regards, Engin Gunduz Katie Petrusha RIPE NCC

1 0

X.509 authentication in the RIPE Database
by Tiago Antao 22 Jul '03

22 Jul '03

Dear Colleagues, [Apologies for duplicate e-mails] As previously discussed in RIPE 44 and 45, please find below the proposal to add X.509 authentication to the RIPE Database. ******************************************************************** X.509 Certificate Authentication in the RIPE Database 0. Objective To make a new method of authentication available using X.509 certificates. 1. Motivation The RIPE Database currently has 5 methods of authentication, none of these are completely satisfactory with regard to security, standards support (de facto and de jure), pervasiveness and integration. The X.509 authentication mechanism would satisfy all of these factors: 1. Security: X.509 allows for the use of digital signatures, making it unnecessary to send clear passwords via e-mail. The current PGP authentication also provides this feature. 2. Standards support: X.509 is an ISO standard and is the only mechanism supported by mailers and clients used in more than 90% of communications with the RIPE NCC. 3. Pervasiveness: X.509 can be utilised with several communication mechanisms, not only mail. A common example is SSL/HTTPS. No other authentication mechanism is as strong and easily available with the web. 4. Integration: This authentication method will integrate seamlessly with the general framework of security in use at the RIPE NCC. It is also important to note that, the general trend among the other Regional Internet Registries (RIRs) is the use of X.509 as a main authentication method. 2. User visible changes a. Requirements To be able to the X.509 authentication method the user requires a certificate issued through the RIPE NCC LIR portal. Information on how to obtain a certificate can be found at: http://lirportal.ripe.net/lirportal/faq/pki.html Therefore the X.509 method would only be available to LIRs. This can be changed if the community so desires. b. Maintainers The auth: attribute of the mntner object will have a new authentication scheme, X509. The parameter will be a Distinguished Name (DN) according to RFC 2253. There is an important fundamental difference between PGP authentication and X.509; the database does not need a key-cert object for X.509 certificates, the DN has to be trusted. This means the certificate must be signed by a trusted authority and that self-signed certificates will not be accepted. The trusted authority will be the RIPE NCC Certificate Authority that is currently only available to LIRs. Following is an example of a maintainer with X.509 authentication: mntner: RIPE-DBM-MNT descr: Mntner for RIPE DBM objects. admin-c: AMR68-RIPE tech-c: RD132-RIPE upd-to: ripe-dbm(a)ripe.net mnt-nfy: ripe-dbm(a)ripe.net auth: X509 C=NL, O=RIPE NCC, OU=Members, CN=eu.ripe.dbm notify: ripe-dbm(a)ripe.net mnt-by: RIPE-DBM-MNT referral-by: RIPE-DBM-MNT changed: ripe-dbm(a)ripe.net 20030617 source: RIPE For users the only variable part within the new auth: attribute is the CN (Common Name). c. Submitting updates via e-mail Updates for objects maintained by a maintainer with X509 authentication must be sent in S/MIME format and signed (not encrypted) using the private key associated with the issued certificate. This key must also be made available to the mailer. Users that have a mail user agent that does not support S/MIME might consider using OpenSSL S/MIME facilities to prepare their mails. d. Submitting updates via webupdates Webupdates will accept client-side certificates. This means that the strongest type of authentication possible will be easily available for users using the web. For this to be possible the certificate and private key have to be loaded in the user browser.

4 4

New Draft Documents for review: IPv4 Policy & Status Attribute in Inetnum objects
by leo vegoda 21 Jul '03

21 Jul '03

Dear Colleagues, The RIPE NCC is pleased to announce the publication of a draft of the updated RIPE IPv4 policy document, “IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region” (currently ripe-234). We have also published a draft document detailing proposed changes to the “status:" attribute in inetnum objects. Both documents can be downloaded from the "Drafts" section in the RIPE Document Store, found at: <http://www.ripe.net/ripe/draft-documents/> The major updates to the draft IPv4 policy document include the following: - Recent policy changes have been incorporated, including the policy allowing assignments for Internet experiments and the sub-allocation policy. - Wording has been improved to make it easier to read. - The explanation of how to use the database has been removed as a separate "RIPE Database User Manual: Getting Started" was published in September last year. - The document now incorporates the text from "Provider Independent vs Provider Aggregatable Address Space" (ripe-127). - The document now specifies database registration requirements. If the community accepts this document it will replace the existing IPv4 Policy document (ripe-234) and the "Provider Independent vs Provider Aggregatable Address Space" document (ripe-127). The draft document on “status:" attributes proposes changes to the values of “status:" attributes. There is a new “status:" attribute value to support the sub-allocation policy, approved by the RIPE LIR Working Group. New wording is suggested, too. This should make the meaning of “status:" attributes more clear to the majority of Whois users. Feedback on both documents should be sent to the <address-policy-wg(a)ripe.net> mailing list for a period of five weeks. This review period will end on 28 August 2003. Kind regards, -- leo vegoda RIPE NCC Registration Services Manager

1 0

Re: [db-wg] Re: [ncc-services-wg] X.509 authentication in the RIPE Database
by Wilfried Woeber, UniVie/ACOnet 16 Jul '03

16 Jul '03

Randy, >let the RIRs spend a few of the bucks they have getting their certs >signed by a well-trusted root CA. is there any? Or to be more precise, why (as an RIR customer) should I trust a commercial CA more than a RIR? >randy I think what is happening here is a misunderstanding and/or an attempt to mix and match advantages, capabilities and technology of a hierarchical 3rd party trust system vs. a (PGP-like) web of trust approach. Wilfried.

1 0

Re: [ncc-services-wg] X.509 authentication in the RIPE Database
by Tim Christensen 11 Jul '03

11 Jul '03

> when you say that the trend among the other RIRs is to go for X.509 > certificates, could you please elaborate on what they are > doing and how > far they are? Greetings all, Currently, ARIN is working toward deployment of X.509 as a strong authentication method for securing email template submissions. We expect implementation to occur later this year. After X.509 deployment for templates, ARIN will explore both the expansion of X.509 into other methods of interfacing with ARIN, as well as other strong authentication mechanisms. Regards, Tim Christensen Database Administrator American Registry for Internet Numbers (ARIN) (703) 227 9876

1 0

X-NCC-RegID : cm.intelcam deleting objects
by Local Internet Register 30 Jun '03

30 Jun '03

Date: Wed, 25 Jun 2003 14:09:01 -0100 (GMT) From: Local Internet Register <registry(a)intelcam.cm> Subject: X-NCC-RegID : cm.intelcam deleting objects To: lir-help(a)ripe.net Cc: registry(a)intelcam.cm MIME-Version: 1.0 Content-MD5: ZpkYzRVbqYcHSqym9KzPtA== Hello! This is LIR Cameroon. We would like to know how to delete the following objects from the RIPE database. Best regards TONYE Antoine Joseph Junior inetnum: 195.24.204.128 - 195.24.205.63 netname: NEWTECH descr: Internet Service Provider descr: BP 6269 Yaounde Cameroon country: CM admin-c: EAA11-RIPE tech-c: DM5338-RIPE rev-srv: ns.ripe.net rev-srv: fw.itu.ch rev-srv: sanaga.camnet.cm rev-srv: lom.camnet.cm status: Assigned PA notify: registry(a)intelcam.cm mnt-by: RIPE-NCC-NONE-MNT change: registry(a)intelcam.cm 20000412 source: RIPE person: David MABVOURI address: BP 6269 Yaounde Cameroon phone: +237 22 19 82 fax-no: +237 22 19 81 e-mail: david.mabvouri(a)wipo.int nic-hdl: DM5338-RIPE notify: registry(a)intelcam.cm changed: registry(a)intelcam.cm 20000411 source: RIPE

2 1

New "status" tag of REVOKED requested
by Hank Nussbacher 25 Jun '03

25 Jun '03

The following was posted to APNIC without much comment. Since RIPErs are more outspoken, I'd like to raise it here as a possible idea for implementation. >I am part of a volunteer team along with Barry Greene and Terry Baranski >that contact Internet users (ISPs and corporates) when they start >announcing something wrong on the Internet. Recently, Geoff Huston updated >his CIDR report - http://bgp.potaroo.net/cidr/#Bogons and up popped a >number of APNIC customers that were announcing prefixes that were not >allocated in APNIC. > >Turns out that the customers membership was "closed" and APNIC tried >contacting them with no success. APNIC waits about 90-120 days before >closing a member for non-payment. APNIC then sends an email informing the >upstream to stop announcing the IP range that has been reclaimed from the >closed member. Then they remove all the database objects which are related >to this organisation from the WHOIS database. After a one year period, >APNIC will start to reallocate/reassign that particular IP range to other >organisations. > >The problem is that the upstream or even the customer themselves continue >to use the prefix and announce it to the Internet, thereby falling into the >Bogon category. > >I think 90-120 days is too little before removing the inetnum object. I >also think that a better a tactic would be to add a "remarks" to the >inetnum or perhaps create a new "status" tag such as REVOKED. I also think >such a policy should be uniform between RIRs. > >Comments? -Hank

2 1

Hi to the group
by A. Hakan ASKAR 05 Jun '03

05 Jun '03

Dear all ! We are an ISP operating in Turkey called Gediknet. We got some problems about managing our IP blocks. As Gediknet A.S. these ip blocks ( 195.244.32.0 - 195.244.63.255 ) are belong to us and if you look to the whois db you can see that these ip's are mnt-by your RIPE. We are trying to get an AS Number but as you can imagine we are not the mnt !. To correct this problem, what can we do ? Regards ; A. Hakan ASKAR Gediknet A.S. Manager

1 0

Re: Improvements to database update software
by DB-News 04 Jun '03

04 Jun '03

Dear Colleagues, [apologies for duplicate messages] This is to announce that the transition period for the introduction of new database update software is over. This means that the mail boxes auto-dbm-old(a)ripe.net and auto-dbm-new(a)ripe.net are not available any more and all update messages to auto-dbm(a)ripe.net will be processed by the new database update software. Best regards, -- Engin Gunduz RIPE NCC Database Group -- DB News wrote 23 Apr 2003: > > [apologies for duplicate messages] > > Dear Colleagues, > > The Database Group at the RIPE NCC has been working on restructuring > the dbupdate program. This is the part of the RIPE Whois server that > processes update requests from users. > > The main goal has been to improve the acknowledgement messages that > users receive from the RIPE Whois Database and provide clearer error > reporting and authorisation information. We have also been able to > make the software easier to maintain and modify. This will reduce the > time spent fixing bugs and adding new features. > > Details may be found here: > > http://www.ripe.net/db/dbupdate/ > > A page further explaining the new acknowledgements can be found here: > > http://www.ripe.net/db/dbupdate/acknowledgments.html > > The new dbupdate messages have a different format. Therefore a phased > approach to introducing the new server has been taken. For a period we > will use the new dbupdate in parallel with the old one. This will > allow people using automated tools time to update their software. > > PRE-MIGRATION > Before the new dbupdate was available. > > auto-dbm-old(a)ripe.net DOES NOT EXIST > auto-dbm(a)ripe.net --> old dbupdate > auto-dbm-new(a)ripe.net DOES NOT EXIST > > DAY-X, Wednesday, 23 April, 2003 > The new dbupdate is available but must be requested specifically. > > auto-dbm-old(a)ripe.net --> old dbupdate > auto-dbm(a)ripe.net --> old dbupdate > auto-dbm-new(a)ripe.net --> new dbupdate > > DAY-Y, Wednesday, 7 May, 2003 > The new dbupdate is the default but the old dbupdate may be requested > specifically. > > auto-dbm-old(a)ripe.net --> old dbupdate > auto-dbm(a)ripe.net --> new dbupdate > auto-dbm-new(a)ripe.net --> new dbupdate > > DAY-Z (POST-MIGRATION), Wednesday, 4 June, 2003 > The old dbupdate is no longer available. > > auto-dbm-old(a)ripe.net DOES NOT EXIST > auto-dbm(a)ripe.net --> new dbupdate > auto-dbm-new(a)ripe.net DOES NOT EXIST > > > Best regards, > > -- > Shane Kerr > Database Group > RIPE NCC

1 0

changed-lines in objects.
by Fredrik Widell 26 May '03

26 May '03

Hi db-wg, I have a suggestion which maybe is good or bad :) A thought occured to me (as I for the xxxx'th time was accused of hacking somebody who has a firewall). The changed-line in every object simply refers to a mail-adress and a timestamp. Whould'nt it be more accurate to have a nic-hdl instead of just a mailadress there? managers of objects move, and mailadresses gets obsolete, and the only thing they are used for is to send abuse-matters, which of course are the wrong recipient in 99.9% of the cases, but if there was a nic-hdl, one could give information via that nic-hdl on how to get in contact with 'good' recipients, or the users would have to actually think and maybe realize that the other names that occur in an answer from ripe-db possibly could be the right recipients for abuse-matters. an example, instead of this: inetnum: 194.68.1.0 - 194.68.1.255 netname: SE-GEFLE descr: Gefle Dagblad country: SE admin-c: MAEK2-RIPE tech-c: MAEK2-RIPE status: ASSIGNED PI mnt-by: SUNET-MNT changed: ber(a)sunet.se 19940420 changed: fredrik(a)sunet.se 19990211 changed: fredrik(a)sunet.se 19991105 source: RIPE there would be inetnum: 194.68.1.0 - 194.68.1.255 netname: SE-GEFLE descr: Gefle Dagblad country: SE admin-c: MAEK2-RIPE tech-c: MAEK2-RIPE status: ASSIGNED PI mnt-by: SUNET-MNT changed: BE10 19940420 changed: FW526-RIPE 19990211 changed: FW526-RIPE 19991105 source: RIPE Comments are welcome. -- Best regards /Fredrik ------------------------------------------------------- KTHNOC, KTH, S-100 44 Stockholm, Sweden +46 8 790 65 17 -------------------------------------------------------

4 4

Problems with route object update
by Marcus.Ruchti＠colt.de 22 May '03

22 May '03

Hi all, I've recognized that we have massive problems in the last weeks with RIPE database updates by other ISP's. e.g. a new customer wants that we will announce a PI network used by him but it is maintained by another LIR. I've asked for creating a route object with our maintainer several times without success. I think all this happens with intention to constrain the business activity of the competitor ! Is there a possibility to insert the RIPE-NONE Maintainer in the whole PI blocks (e.g. /16). In this step I won't mention the names of those ISP's... regards, Marcus Ruchti COLT Telecom GmbH

1 0

Re: [db-wg] Slash notation
by Janos Zsako 22 May '03

22 May '03

> From db-wg-admin(a)ripe.net Thu May 22 14:59:10 2003 Dear all, > > ... Just another suggestion (from what I experienced in my environment): > > > >Would it be possible to treat/convert > > > >inetnum: 193.0.0.221 > > > >to > > > >inetnum: 193.0.0.221 - 193.0.0.221 > > > >(the 'single host') > >? > > is there a possibilty for ambiguity? I guess there is, especially if the last element is 0 (e.g. 194.152.133.0, which probably can be confused with 194.152.133.0/24). It cannot be ambiguous, however, if the last element of the dotted quad is an odd number. > Probably not if we have all 4 fields of the dotted quad included. > > Maybe we c/should require 193.0.0.221/32 here to be on the safe side? I would prefer this latter (i.e. requiring the /32). Janos

2 1

Re: [db-wg] Slash notation
by Wilfried Woeber, UniVie/ACOnet 22 May '03

22 May '03

Hi Ulrich, Shane, > ... Just another suggestion (from what I experienced in my environment): > >Would it be possible to treat/convert > >inetnum: 193.0.0.221 > >to > >inetnum: 193.0.0.221 - 193.0.0.221 > >(the 'single host') >? is there a possibilty for ambiguity? Probably not if we have all 4 fields of the dotted quad included. Maybe we c/should require 193.0.0.221/32 here to be on the safe side? Wilfried.

1 0

Re: [db-wg] Slash notation
by Wilfried Woeber, UniVie/ACOnet 22 May '03

22 May '03

Hi Shane! >Short answer: > >When version 3 of the Database software was designed, one of the >principles used was to not change user data as it was submitted. >This included the transformation you defined. Still a reasonable guideline, I'd say.... >The easiest solution would be to convert the CIDR to ranges, as you >suggest, so: > >inetnum: 193.0.0.0/20 > >Would become: > >***Warning: inetnum '193.0.0.0/20' converted to '193.0.0.0 - 193.0.7.255' > >inetnum: 193.0.0.0 - 193.0.7.255 > . > . > . > >If this makes sense, we'll include this change shortly. Yes, please! [ and still: yes, please - even after reading your in-depth explanation... ] Regards, Wilfried.

1 0