- db-wg - mailman.ripe.net

Re: Deprecation of the MAIL-FROM auth scheme
by Janos Zsako 01 Apr '02

01 Apr '02

> From owner-db-wg(a)ripe.net Mon Mar 25 13:58:43 2002 > From: Andrei Robachevsky <andrei(a)ripe.net> Andrei, > In case a mntner contains only one "auth" scheme, which is MAIL-FROM, it > will be replaced with a CRYPT-PW scheme with a DES string that cannot be > matched. Why don't you add "CRYPT-PW azsLXaNunJ9Rs", which is the auth of RIPE-NCC-HM-MNT? This way the hostmaster team could easily update a mntner object when the "authorized and authenticated" maintainer shows up and asks you to perform the update ("authorized and authenticated" above refers to the procedure you have in place for dealing with such cases.) Best regards, Janos PS. Otherwise, I guess you need a special mechanism to update such "orphaned" maintainers...

1 0

Re: MD5 proposal
by Janos Zsako 01 Apr '02

01 Apr '02

> From owner-db-wg(a)ripe.net Mon Mar 25 14:29:46 2002 > From: Engin Gunduz <engin(a)ripe.net> > > Let's suppose I send in a message with > > password: Hello > > (note the three spaces). > > > > It is not clear to me where the passphrase would start. I can think of > > two valid approaches: > > 1. At the first character after the first white space (space or tab) > > following the colon (":") (in my example the passphrase would be then > > " Hello"). > > 2. At the first non-whitespace character after the colon (in which case > > the passphrase would be "Hello"). > > > > I think I would vote for the second approach which is more intuitive > > to me. BTW: how does this work with CRYPT-PW? I would think it is the > > second approach. > > Yes, the current approach is the second one. This implicitely > prohibits the use of white space as the first characters of the > password but probably this is less confusing for the users then > having the behaviour you defined in 1. > I don't think this is documented. We'll make sure it will > be in the user manual, and in reference document if > necessary. Great! Thanks. Best regards, Janos

1 0

Re: MD5 proposal
by Engin Gunduz 01 Apr '02

01 Apr '02

Hi Janos, On Mon, 25 Mar 2002, Janos Zsako wrote: > > From owner-db-wg(a)ripe.net Mon Mar 25 13:26:38 2002 > > Dear Andrei, > > > Please find enclosed the MD5 proposal for your comments and suggestions. > > Great! > > One small comment, probably need for clarification. > > > When submitting an update to the database that needs to be authorised using > > this scheme, a "password:" pseudo-attribute must be used to submit a key > > (passphrase). Line continuation is not allowed for this attribute, so the > > whole key should fit on one line. > > Let's suppose I send in a message with > password: Hello > (note the three spaces). > > It is not clear to me where the passphrase would start. I can think of > two valid approaches: > 1. At the first character after the first white space (space or tab) > following the colon (":") (in my example the passphrase would be then > " Hello"). > 2. At the first non-whitespace character after the colon (in which case > the passphrase would be "Hello"). > > I think I would vote for the second approach which is more intuitive > to me. BTW: how does this work with CRYPT-PW? I would think it is the > second approach. Yes, the current approach is the second one. This implicitely prohibits the use of white space as the first characters of the password but probably this is less confusing for the users then having the behaviour you defined in 1. > > Best regards, > Janos > > PS: I apologize if this is specified somewhere. I don't think this is documented. We'll make sure it will be in the user manual, and in reference document if necessary. Best regards, Engin Gunduz RIPE NCC Database Group

1 0

Re: MD5 proposal
by Janos Zsako 01 Apr '02

01 Apr '02

> From owner-db-wg(a)ripe.net Mon Mar 25 13:26:38 2002 Dear Andrei, > Please find enclosed the MD5 proposal for your comments and suggestions. Great! One small comment, probably need for clarification. > When submitting an update to the database that needs to be authorised using > this scheme, a "password:" pseudo-attribute must be used to submit a key > (passphrase). Line continuation is not allowed for this attribute, so the > whole key should fit on one line. Let's suppose I send in a message with password: Hello (note the three spaces). It is not clear to me where the passphrase would start. I can think of two valid approaches: 1. At the first character after the first white space (space or tab) following the colon (":") (in my example the passphrase would be then " Hello"). 2. At the first non-whitespace character after the colon (in which case the passphrase would be "Hello"). I think I would vote for the second approach which is more intuitive to me. BTW: how does this work with CRYPT-PW? I would think it is the second approach. Best regards, Janos PS: I apologize if this is specified somewhere.

1 0

Deprecation of the MAIL-FROM auth scheme
by Andrei Robachevsky 25 Mar '02

25 Mar '02

Dear Colleagues, Another issues that was discussed at the RIPE-41 meeting is deprecation of a MAIL-FROM authentication scheme. It was agreed that the weakness of this auth form does not allow to provide real protection to the database objects and it should be deprecated. As a matter of fact recently we had to deal with several incidents when objects were hijacked using the flaw of the MAIL-FROM. It took time and resources from the ripe-dbm to investigate the matter and restore the objects, to say nothing about possible damage to the owners of such objects should the incident has gone unnoticed. Please find enclosed the migration plan to a more secure database. Your comments are welcome. Regards, Andrei Robachevsky DB Group Manager RIPE NCC Deprecation of MAIL-FROM authentication and authorisation scheme (auth scheme) ============================================================================== Motivation ========== This authentication method checks the content of the RFC2822 From: header of an update request against the regular expression specified as <auth-info> field of the "auth:" attribute. If the regular expression matches the content of the From: header the update request is authenticated successfully. The matching is applied to the whole content of the From: header including comments if present. No attempt is made to isolate the mailbox part. This 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. Currently 41% (~2700) of all mntner objects in the RIPE Database are using this weak "auth" scheme. Though NONE "auth" scheme is even weaker it is not supposed to be consciously used for object protection, but rather as notification facility. Therefore NONE "auth" scheme is outside the scope of this proposal. Transition phases ================== I Notifying mntners with MAIL-FROM auth scheme ----------------------------------------------- An announcement presenting this proposal and encouraging the owners of the mntners to remove MAIL-FROM auth scheme from their objects will be send. 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. II Rejecting updates for mntner objects containing MAIL-FROM auth scheme ------------------------------------------------------------------------- An update of a mntner object will be rejected if the new version of the mntner contains MAIL-FROM auth scheme. This will be reported as a syntax error in the "auth:" attribute. III 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. In case of failure the acknowledgement will indicate that MAIL-FROM "auth" scheme is not valid any more. IV 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:" attrubute 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 replaced with a CRYPT-PW scheme with a DES string that cannot be matched.

2 1

Re: Deprecation of the MAIL-FROM auth scheme
by Janos Zsako 25 Mar '02

25 Mar '02

> From owner-db-wg(a)ripe.net Mon Mar 25 13:58:43 2002 > From: Andrei Robachevsky <andrei(a)ripe.net> Andrei, > In case a mntner contains only one "auth" scheme, which is MAIL-FROM, it > will be replaced with a CRYPT-PW scheme with a DES string that cannot be > matched. Why don't you add "CRYPT-PW azsLXaNunJ9Rs", which is the auth of RIPE-NCC-HM-MNT? This way the hostmaster team could easily update a mntner object when the "authorized and authenticated" maintainer shows up and asks you to perform the update ("authorized and authenticated" above refers to the procedure you have in place for dealing with such cases.) Best regards, Janos PS. Otherwise, I guess you need a special mechanism to update such "orphaned" maintainers...

1 0

Re: MD5 proposal
by Janos Zsako 25 Mar '02

25 Mar '02

> From owner-db-wg(a)ripe.net Mon Mar 25 14:29:46 2002 > From: Engin Gunduz <engin(a)ripe.net> > > Let's suppose I send in a message with > > password: Hello > > (note the three spaces). > > > > It is not clear to me where the passphrase would start. I can think of > > two valid approaches: > > 1. At the first character after the first white space (space or tab) > > following the colon (":") (in my example the passphrase would be then > > " Hello"). > > 2. At the first non-whitespace character after the colon (in which case > > the passphrase would be "Hello"). > > > > I think I would vote for the second approach which is more intuitive > > to me. BTW: how does this work with CRYPT-PW? I would think it is the > > second approach. > > Yes, the current approach is the second one. This implicitely > prohibits the use of white space as the first characters of the > password but probably this is less confusing for the users then > having the behaviour you defined in 1. > I don't think this is documented. We'll make sure it will > be in the user manual, and in reference document if > necessary. Great! Thanks. Best regards, Janos

1 0

Re: MD5 proposal
by Janos Zsako 25 Mar '02

25 Mar '02

> From owner-db-wg(a)ripe.net Mon Mar 25 13:26:38 2002 Dear Andrei, > Please find enclosed the MD5 proposal for your comments and suggestions. Great! One small comment, probably need for clarification. > When submitting an update to the database that needs to be authorised using > this scheme, a "password:" pseudo-attribute must be used to submit a key > (passphrase). Line continuation is not allowed for this attribute, so the > whole key should fit on one line. Let's suppose I send in a message with password: Hello (note the three spaces). It is not clear to me where the passphrase would start. I can think of two valid approaches: 1. At the first character after the first white space (space or tab) following the colon (":") (in my example the passphrase would be then " Hello"). 2. At the first non-whitespace character after the colon (in which case the passphrase would be "Hello"). I think I would vote for the second approach which is more intuitive to me. BTW: how does this work with CRYPT-PW? I would think it is the second approach. Best regards, Janos PS: I apologize if this is specified somewhere.

2 1

RE: NRTM proposal
by Lu, Ping 14 Mar '02

14 Mar '02

I believed we are talking about two different things: In your scenario: Your client has a different serial number than RIPE's one. let's say it goes like this, RIPE:123 YOURS:111 RIPE:124 YOURS:111 (filter out) RIPE:125 YOURS:112 RIPE:126 YOURS:112 (filter out) RIPE:127 YOURS:112 (filter out) RIPE:128 YOURS:113 RIPE:129(for some reason it is lost) YOURS:113 RIPE:130 YOURS:113 (filter out) RIPE:131 YOURS:114 How can you tell there is something missing ? Also next time the client restart which serial number is it going to use ? Our scenario: The client maintain the same serial number as RIPE's. RIPE:123 OURS:123 RIPE:124 OURS:124 (dummy update) RIPE:125 OURS:125 RIPE:126 OURS:126 (dummy update) RIPE:127 OURS:127 (dummy update) RIPE:128 OURS:128 RIPE:129(for some reason it is lost) OURS:128 (client detect mismatch stop here) I want to stop discussion about different scenarios and just limit this to the current NRTM practice: NRTM server and client maintain the same serial numbers. Best Regards. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net > -----Original Message----- > From: Arnd Vehling [mailto:av@nethead.de] > Sent: Tuesday, March 12, 2002 10:35 AM > To: Lu, Ping > Cc: 'Andrei Robachevsky'; Bjorn Danielsson; db-beta(a)ripe.net; > 'db-wg(a)ripe.net'; Dieken, Chris; Beaumont, Dave; Resh, Stephanie; Phil > Syskes > Subject: Re: NRTM proposal > > > "Lu, Ping" wrote: > > > me wrote.. > > > To be more precise. The data is up to date if the highest > > > serial number > > > on the mirror server matches the highest serial number on > the client. > > > > > Exactly. That's why the client can't just ignore any > private object. It will > > need to do a dummy update to advance the serial numbers. > > Nope. The only thing which the client really needs to know is > the highest > serial > number _he_, the client, did process. > > If the highest serial number internal to the datastructure of > the client > matches the one of the mirror source is of no concern. > > Please keep in mind that i can write a mirror client which > doesnt needs to > have the same structure as the ripe-db and therefore may very > well miss > a "serial" number like the ripe-server has. > > best regards, > > Arnd > -- > > NetHead Network Design and Security > Arnd Vehling av(a)nethead.De > Gummersbacherstr. 27 Phone: +49 221 8809210 > 50679 Cologne, Germany Fax : +49 221 8809212 >

2 2

RE: NRTM proposal
by Lu, Ping 12 Mar '02

12 Mar '02

> > Hi, > > "Lu, Ping" wrote: > > As I said before if the client can do whatever they want > without maintaining > > > > the correct serial-numbers then how can you tell the data > is up-to-date ? > > To be more precise. The data is up to date if the highest > serial number > on the mirror server matches the highest serial number on the client. > > -- Arnd > Exactly. That's why the client can't just ignore any private object. It will need to do a dummy update to advance the serial numbers. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net

2 1

RE: NRTM proposal
by Lu, Ping 11 Mar '02

11 Mar '02

> -----Original Message----- > From: Andrei Robachevsky [mailto:andrei@ripe.net] > Sent: Monday, March 11, 2002 11:00 AM > To: Lu, Ping > Cc: Bjorn Danielsson; db-beta(a)ripe.net; 'db-wg(a)ripe.net' > Subject: Re: NRTM proposal > > > Hi Ping, > [snip] > > > In fact, with both RIPEv3 and iRRd you can ADD twice (or rather many > times in a row), as this is considered as an update. > > So in our setup we use the approach you decribed below, but > with "ADD" > action. We put a mirror reflector in front of all mirrored > sources, and > every time it sees a non-compliant object mirror reflector > substitutes > it with "ADD + dummy object" without losing track of serials. > That sounds resaonable. If the client side wrapper see a [ADD|UPD|DEL]/unknown_object action then it should translate it to ADD/dummy_object and send it to the database. Should we consider this as the standard way to filter out object or a work-around ? Also can we all agree on a standard dummy_object like "limerick" (no side effect) ? [snip again] Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net

2 1

NRTM proposal
by Lu, Ping 11 Mar '02

11 Mar '02

Since we are talking about NRTM, I would like to raise a question on how to filter out some objects for privacy or other reasons. 1. There are two different cases: NRTM ingress( client mirroring from server) and NRTM egress ( server mirroring into client ) 2. For NRTM egress: Usually want to filter out PERSON object for privacy. 3. For NRTM ingress: Sometime other RR may have polluted route objects or other non-standard RPSL extension. 4. Other than modified the server we can put a wrapper to filter out unwanted object then send a dummy object to the server. 5. The problem is how do you specify action ? Because you can not ADD or DEL twice the same dummy object. So the wrapper have to TRACK the action sequence. This is problematic and sometimes won't work at all. 6. The solution I am proposed is: a DUMMY action for both NRTM ingress and egress. Whenever there is a need to filter some objects, the server will send a dummy object with DUMMY action. Then the NRTM client will accept the DUMMY/dummy stream and increase the serial number without any real action. Any comment ? Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net > -----Original Message----- > From: Andrei Robachevsky [mailto:andrei@ripe.net] > Sent: Wednesday, March 06, 2002 5:40 AM > To: Bjorn Danielsson > Cc: db-beta(a)ripe.net > Subject: Re: NRTM policy > > > Dear Bjorn Danielsson, > > Bjorn Danielsson wrote: > > > Is anyone on this list using Near-Real-Time Mirroring to > run a mirror > > of the RIPE database? If so, I would like to contact you to find out > > what procedure you went through to become accepted by RIPE > as a client? > > (I tried asking ripe-dbm(a)ripe.net about this but got no > sensible answer.) > > Please reply via private mail to me. > > > > > I am not sure what question you are referring to that got no sensible > answer from the ripe-dbm(a)ripe.net. As far as I know the process of > approving you as a NRTM client has been completed and the address you > requested has been given access to the server. I also believe you > received our standard "NRTM HOWTO" containing necessary information. > > If you need any more assistance in this matter, please don't > hesitate to > contact ripe-dbm(a)ripe.net. In such case I would appreciate > you indicate > more clearly what kind of problem you experience. > > Regards, > > Andrei Robachevsky > Database Group Manager > RIPE NCC >

3 2

Re: Database development plans
by Arnd Vehling 11 Mar '02

11 Mar '02

> > Dear colleagues, > > Please find below a list of the projects that we included in our > development plan. We would appreciate if you could indicate importance > and usefullness of specific projects so we can adjust their priorities. > 2. Real-time (interactive) updates > > Currently only e-mail updates are supported by the RIPE Database which > complicates automation of the update process at the clients side. The > facility that will allow connection oriented interactive, or real-time > updates, will simplify development of the client tools and make > synchronising of LIR's address management database an easier task. > > Once implemented this project will present a facility for other tools, such > as web-based update interface, or a standalone syntax checker. Ral-Time updates would be number one on my personal wish-list! BTW.: There is already a set of php-functions available to interact via. webinterface with ARIN. Perhaps those could be of use to you. best regards, Arnd -- NetHead Network Design and Security Arnd Vehling av(a)nethead.De Gummersbacherstr. 27 Phone: +49 221 8809210 50679 Cologne, Germany Fax : +49 221 8809212

1 0

RE: NRTM proposal
by Lu, Ping 11 Mar '02

11 Mar '02

comments followed. > -----Original Message----- > From: Arnd Vehling [mailto:av@nethead.de] > Sent: Monday, March 11, 2002 4:01 AM > To: Lu, Ping > Cc: 'Andrei Robachevsky'; Bjorn Danielsson; db-beta(a)ripe.net; > 'db-wg(a)ripe.net'; Dieken, Chris; Beaumont, Dave; Resh, Stephanie; > phil(a)nethead.de > Subject: Re: NRTM proposal > > [snip] > > If receiving a stream with objects considered "non-standard", > or private, all the nrtm client (or the server) has to do > is to filter out objects (and maybe attributes) which are > considered of private nature. The client doesnt need to know > anything about which serial number relates to which object. > (i.e. The serial-numbers must not be in sync between a source > server and the mirror) If you don't care whether the serial-numbers match or not then how can you tell the mirrored data is up-to-date ? > > This can easily be accomplished by creating a perl script > which filters the NRTM ascii stream. > > Actually we are using such a script for synchronizing our > local ip-management ripe-database with the RIPE amsterdam. > > Could you therefore please elaborate on where you are seeing a > problem with the serial-numbers while mirroring? > As I said before if the client can do whatever they want without maintaining the correct serial-numbers then how can you tell the data is up-to-date ? Best Regards. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net

2 2

RE: NRTM proposal
by Lu, Ping 11 Mar '02

11 Mar '02

Hi, Arnd, comments followed. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net > -----Original Message----- > From: Arnd Vehling [mailto:av@nethead.de] > Sent: Thursday, March 07, 2002 12:45 PM > To: Lu, Ping > Cc: 'Andrei Robachevsky'; Bjorn Danielsson; db-beta(a)ripe.net; > 'db-wg(a)ripe.net' > Subject: Re: NRTM proposal > [snip] > > How about setting up an instance for private objects and one with > standard-objetcs. > Let the one with the private objects synchronize with the standard one > (i.e. per e-mail-script) > As far as RIPE-DB vs. IRRD, RIPE-DB implements IRT object (considered private) but IRRD doesn't. There is always a situation where the standard one need to synchronize with the one with private objects but need to filter out private objects (like RADB mirror from RIPE ). Then internally RIPE NCC will need to mirror the data with IRT to keep the data integrity. > Only standard objects gets exported to the standard-objects > DB. Then let > others mirror > only the instance with the standard objects. The problem is the serial number will increase when you update a private object then when other mirrors get only the standard object the serial number mismatched each other. As regarding to the PERSON object, this is a situation for STANDARD mirroring STANDARD but needs to filter it out also. > > This has also the advantage you dont mix ip-management only data with > routing-registry > relevant data. As you might know Cable&Wireless Europe has modified > version of > the RIPE-DB running which contains only IP-Management data > but no route > objetcs etc. > We choose RIPE-DB software because it does both together while ARIN region use two different databases for Route and IP-Management. And it is a disadvantage for us constantly trying to merge both data together. One thing is RIPE-DB cross-checking between the inetnum object (IP-Management) and the route (routing) object makes it very consistent for the RIPE region. And I considered that an advantage rather than a disadvantage. PS. CW Europe is on a different AS number now but it will merge into AS3561 eventually. > This isnt an ideal solution but it works. The right solution > would be to > establish > distributed route registries and not to mirror each other. > > There is already a RFC out which describes how distributed registries > could work > but i cant find it at the moment, sorry. (Anyone know which > RFC it is?) > Even for a distributed system (like DNS) there is a need for caching (mirrored data) and you still have to put them together at some point.

2 1

RIPE Whois Server version 3.1.0
by RIPE Database Administration 26 Feb '02

26 Feb '02

Dear Colleagues, [Apologies for multiple messages]. The RIPE NCC is pleased to announce the release of Version 3.1.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: - New status type for inetnum objects: LIR-PARTITIONED. - New object type, irt, and associated new attributes: "irt:", "mnt-irt:", "irt-nfy:", "signature:", and "encryption:". The RPSL parsing has been totally rewritten. The new mechanism makes adding new classes and attributes much easier. Additionally, many, many bugs have been fixed. Detailed release notes can be found at the following URL: ftp://ftp.ripe.net/ripe/dbase/software/RELEASE-NOTES-3.1.0 You can download this release by anonymous FTP from the following URL: ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-3.1.0.tar.gz If you do not intend to use the cross-reference files or prefer to build them yourself via "make docs", you can download the source without these files by anonymous FTP from the following URL: ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-3.1.0-nocxref.tar.gz A diff for the 3.1.0 "nocxref" version is also available, if you already have 3.0.2 and would prefer to patch that version instead, at the following URL: ftp://ftp.ripe.net/ripe/dbase/software/patch-ripe-dbase-3.0.2-nocxref-3.1.0… If you have any more questions, please don't hesitate to contact <ripe-dbm(a)ripe.net>. -- Shane Kerr RIPE NCC

2 1

New Document available: RIPE-238
by RIPE NCC Document Announcement Service 13 Feb '02

13 Feb '02

[Apologies for duplicate mails] New/Revised RIPE Document Announcement -------------------------------------- A revised/new document is available from the RIPE document store. Ref: ripe-238 Title: RIPE Database Reference Manual Author: Joao Luis Silva Damas, Andrei Robachevsky Date: 6 February 2002 Format: PS=277479 TXT=124400 Obsoletes: ripe-223 Obsoleted by: Updates: Updated by: Short content description ------------------------- This document is an updated version of the "RIPE Database reference manual" (ripe-223). It describes the functionality of version 3.0 of the RIPE Database that uses the Routing Policy Specification Language to represent all Database objects. It also implements the Routing Policy System Security (RPSS) to provide authorisation mechanisms to enable a higher level of security for Internet Routing Registries (IRR). Accessing the RIPE document store --------------------------------- The RIPE document store is 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-238.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-238.txt plain text version You can also access the RIPE documents in HTML format via WWW. The RIPE Database reference manual is available from the WWW at the following URL: http://www.ripe.net/ripe/docs/databaseref-manual.html

1 0

Re: Missing mnt-routes in ALLOCATED PA objects
by RIPE Database Administration 12 Feb '02

12 Feb '02

Dear Karsten, Please see Sabrina Waschke's message regarding the issue: http://www.ripe.net/ripe/mail-archives/db-wg/20010701-20020101/msg00099.html If you have any more questions, please don't hesitate to contact <ripe-dbm(a)ripe.net>. Regards, Engin Gunduz ____________________________ RIPE Database Administration. Karsten Koepp wrote: >Hi all, > >already twice customers of us were not able to update route >records, because RIPE had not included mnt-routes (and mnt-lower) >lines into the inetnum object when allocating a block. >The blocks where we experienced the problem were allocated >in 1996: inetnum: 193.203.96.0 - 193.203.127.255 >and 1999: inetnum: 212.95.64.0 - 212.95.95.255 > >This is not an easy to understand problem for small ISPs dealing >with route objects only now and then. To solve this problem it is >necessary that LIRs send the inetnum object to be updated to >hostmaster(a)ripe.net and RIPE update the object with RIPE-NCC-HM-MNT. >Only then the ISP can update their route records. > >Question: >- Is there a reason for not existing mnt-lower and mnt-routes lines? >- If not, can RIPE update all affected inetnums in an automatic manner? > >This would really help a lot, because manual updates create a lot of >consultancy need from upstream providers (us in this case) and, I guess, >a considerable workload on the RIPE hostmaster team. > >Regards Karsten > >------------------------------------------------------------- >Karsten Koepp >IP Network Planning

1 0

Missing mnt-routes in ALLOCATED PA objects
by Koepp, Karsten 11 Feb '02

11 Feb '02

Hi all, already twice customers of us were not able to update route records, because RIPE had not included mnt-routes (and mnt-lower) lines into the inetnum object when allocating a block. The blocks where we experienced the problem were allocated in 1996: inetnum: 193.203.96.0 - 193.203.127.255 and 1999: inetnum: 212.95.64.0 - 212.95.95.255 This is not an easy to understand problem for small ISPs dealing with route objects only now and then. To solve this problem it is necessary that LIRs send the inetnum object to be updated to hostmaster(a)ripe.net and RIPE update the object with RIPE-NCC-HM-MNT. Only then the ISP can update their route records. Question: - Is there a reason for not existing mnt-lower and mnt-routes lines? - If not, can RIPE update all affected inetnums in an automatic manner? This would really help a lot, because manual updates create a lot of consultancy need from upstream providers (us in this case) and, I guess, a considerable workload on the RIPE hostmaster team. Regards Karsten ------------------------------------------------------------- Karsten Koepp IP Network Planning Lambdanet Communications GmbH (AS13237) Guenther-Wagner-Allee 13 D-30177 Hannover (Germany) Phone +49 (0)511 / 84 88 - 12 55 Fax +49 (0)511 / 84 88 - 12 59 Mobile +49 (0)178 / 3 62 - 12 55 mailto:Karsten.Koepp@lambdanet.net News & Facts on our Website: www.lambdanet.net -------------------------------------------------------------

2 1

RIPE DB down for updates?
by Daniel Roesen 10 Feb '02

10 Feb '02

Hi, http://www.ripe.net/ripencc/pub-services/db/mrtg/whois.html it looks like the update processing is halted since yesterday evening... Best regards, Daniel

2 1

New RIPE Database features
by Andrei Robachevsky 07 Feb '02

07 Feb '02

Dear colleagues, [ Apologies for multiple messages ] The new features of the RIPE Database requested by the community are now available in "beta version" on our TEST whois server (http://www.ripe.net/ripencc/pub-services/db/testdb.html). The new features are: - the "irt" object (please see my previous announcement at http://www/ripe/mail-archives/db-wg/current/msg00012.html) - the new "status:" value of the inetnum object "LIR-PARTITIONED PA/PI" (please see the original proposal at http://www/ripe/mail-archives/db-wg/20010701-20020101/msg00090.html). You may try these features by - sending your updates to test-dbm(a)ripe.net; - querying the test-whois.ripe.net, port 43. The new version of the software is under heavy testing now and will be put into production shortly after the RIPE meeting. Your comments are appreciated. You may contact the development team directly at dbrip(a)ripe.net. Best regards, Andrei Robachevsky DB Group Manager RIPE NCC

2 4

RE: Database development plans
by Lu, Ping 31 Jan '02

31 Jan '02

> -----Original Message----- > From: David Kessens [mailto:david@IPRG.nokia.com] > Sent: Wednesday, January 30, 2002 11:22 PM > To: Lu, Ping > Cc: 'Larry J. Blunk'; db-wg(a)ripe.net > Subject: Re: Database development plans > > > > Ping, > > On Wed, Jan 30, 2002 at 07:20:47PM -0500, Lu, Ping wrote: > > > > If the mail can be intercepted then a cookie confirmation > > won't make a difference. > > You can forge a mail header without being able to intercept the mail. > > > If the mail can be intercepted then a clear-text password scheme > > won't make a difference. > > You can guess the password without being able to intercept the mail. > > David K. > --- > And CRYPT-PW now is no better than the MAIL-FROM. Both are easy to get thru. But my point is "If the email is not secure then the new proposals (cookie, MD5 or even shadow password) won't achieve their goals". However let's focus on "If the email is secure ..." case now. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net

1 0

RE: Database development plans
by Lu, Ping 31 Jan '02

31 Jan '02

> > I still feel that MAIL-FROM with cookie confirmation is > considerably > better than "no authentication". I don't see how a cookie is really > any easier to intercept than a password or secret string sent in the > clear. It also doesn't suffer from potential dictionary cracking > attacks. While it is clear that user's will find it more complicated > than the current MAIL-FROM, I could still envisage some > preferring it over passwords/PGP-KEYs. > > I checked out majordomo's cookie confirmation code and found that > the cookie generation uses a hash of a secret string, the user's > email address, and the requested command. Thus the server does not > need to keep any cookie state. One could include a timestamp in the > cookie hash generation and confirmation message to help guard against > replay's. > > Finally, I would imagine that those who are using automatic scripts > would migrate to passwords or (preferably) PGP. > > If the mail can be intercepted then a cookie confirmation won't make a difference. If the mail can be intercepted then a clear-text password scheme won't make a difference. Only if the mail is secure then a cookie or password makes sense. Also a cookie confirmation increases the chance to start a mail storm. >> In my ISI/RPSL/6bone version of the perl server (=not the >> official RIPE version of the perl software) the crypt-pw is indeed not shown upon >> query or in the downloadable database files. This is not a bad idea to shadow the crypted string (then MD5 is not really necessary ). But I think the RIPE-DB server needs some structure changes to support this. >> >> This is clearly a community decision. I would suggest that if MD5 is > > implemented as an additional method, strings bigger than 8 > characters > > are a necessity (and it is really easy to do so with MD5). > The extra > > length makes it really difficult to have dictionary attacks if > > properly used (I mean you can use a file with the complete works of > > shakespeare when generating the MD5 hash) > > If RIPE-DB are going to support different auth functions, why not using PAM to support any kind of PAM modules then ? Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net

2 1

Database development plans
by Andrei Robachevsky 30 Jan '02

30 Jan '02

Dear colleagues, Please find below a list of the projects that we included in our development plan. We would appreciate if you could indicate importance and usefullness of specific projects so we can adjust their priorities. Several more detailed proposals will follow. Here I just included brief description of the projects not to enter premature implementation discussion. Regards, Andrei Robachevsky DB Group Manager RIPE NCC 1. Authorisation checks across multiple databases Migration to v3/RPSL made creating objects in the routing registry a much more complex process due to the introduction of the Routing Policy System Security (RFC 2725). The real problem was with so called "foreign" route objects that either announce non-RIPE address space or are originated from non-RIPE ASN. As there were no corresponding objects in the RIPE database such transactions failed. A workaround is in place now that requires duplication of objects in the RIPE RR and as a result - low security level. The proposed solution is to get this information from sources that contain authoritative information about network objects that are supposed to authorise the transaction. For example, when creating a route from APNIC's address space, but originated from a RIPE ASN, authorisation information will be requested from both RIPE and APNIC sources. 2. Real-time (interactive) updates Currently only e-mail updates are supported by the RIPE Database which complicates automation of the update process at the clients side. The facility that will allow connection oriented interactive, or real-time updates, will simplify development of the client tools and make synchronising of LIR's address management database an easier task. Once implemented this project will present a facility for other tools, such as web-based update interface, or a standalone syntax checker. 3. Automatic cleanup of unreferenced person objects You may find the initial proposals: http://www.ripe.net/ripe/mail-archives/db-wg/20010701-20020101/msg00079.html http://www.ripe.net/ripe/mail-archives/db-wg/20010701-20020101/msg00092.html The problem statement and the solution remains almost the same, with some modifications: - cleanup process is based on internal DB data, rather than object attributes or meta-attributes - "holders" of the objects to be deleted are notified n days before using standard DB notification mechanisms. 4. Further development of the database software - Improving error reporting - Improving server performance - Software portability and configuration 5. Improve database security These ideas were discussed at the RIPE-41, the detailed proposals will follow - Deprecate MAIL-FROM as a weak auth scheme that doesn't serve todays's security requirements. This will be done in several phases starting form not allowing updating mntner objects containing this scheme, and ending with not allowing updates to be authorised with MAIL-FROM. - Implement authentication scheme using MD5 as a more secure mechanism compared to crypt. Passphrases can be used instead of 8 character passwords and MD5 fingerprint will be presented in the auth value. - Implement inverse queries on auth, encryption, signature for PGP keys only (key-cert's).

4 4

Re: Database development plans
by Wilfried Woeber, UniVie/ACOnet 30 Jan '02

30 Jan '02

> In regards to the MD5 fingerprint, would this be a straight MD5 hash, or >something like the FreeBSD MD5-based password hash (which I believe supports >passwords longer than 8 chars)? I would certainly expect support for more than 8 characters, like in newer versions of Linux. >Also, would the hash continue to be openly published? I guess so. Hiding something in the response (by default) has the potential of confusing people while trying to update and/or delete objects. We've been through that already ;-) >It would seem you would still have to deal with potential dictionary attacks. Correct. >I understand the Perl-based RIPE server would use a "*" in place of >the actual crypt-pw and I've been considering adding support for this in IRRd. >Also, I would suggest reading the following paper regarding the strength >of traditional Unix crypt, FreeBSD's MD5-based crypt, and OpenBSD's Blowfish- >based bcrypt -- http://www.usenix.org/events/usenix99/provos.html Thanks for the pointer! > Regards, > Larry Blunk > Merit Regards, Wilfried.

2 1