- db-wg - mailman.ripe.net

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