- db-wg - mailman.ripe.net

synchronous updates
by Can Bican 25 Apr '02

25 Apr '02

Dear colleagues, A prototype for synchronous updates on the RIPE Database has been released. In this initial implementation, the following requirements have been implemented: 1. Adding the ability to interactively update the database through a TCP port. 2. Using a well known protocol to provide an easy way for developing third party clients. 3. Compatibility with the mail updates, so the same submission produces the same result in both ways. 4. To be scalable, to address possible performance problems. The released prototype now acts as a syntax checker. It doesn't really process the updates, but rather checks it against an empty database, and returns as if the update has been processed, after the initial syntax checks from dbupdate have been performed. You can reach the prototype from: http://www.ripe.net/ripencc/pub-services/db/syncupdates/index.html Please communicate with us about ideas, comments and suggestions. Regards, -- Can Bican DB Group RIPE NCC

1 0

draft agenda (v1), for DB-WG meeting, RIPE 42, Amsterdam
by Wilfried Woeber, UniVie/ACOnet 25 Apr '02

25 Apr '02

Dear WG list members, attached please find the 1st draft: Proposed Agenda for the DB-WG Meeting at RIPE 42 in Amsterdam, NL. Looking forward to see many of you in Amsterdam a few days from now, Wilfried. ______________________________________________________________________ Proposed Agenda for the Database Working Group Meeting RIPE-42, Apr. 29 - May 3, 2002, Amsterdam, NL 1. Draft Thursday, May 2nd, 2002 09:00-12:30 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A. Administrative stuff (WW, chair) . scribe (offer from Nigel received) . circulate list of participants . agenda bashing . status of minutes B. Action Items . status of actions C. DB update (RIPE NCC, Andrei R.) 15..20 min . operations report . development activities D. Complex authentication scenarios (Alex G. SWITCH) 20 min . irt: object, how to "package" signatures? . other open issues? E. Discussion on "hiding" credentials (RIPE NCC, N.N.) 20 min . "shadow password" concept . interaction with maintainers . interaction with shadowing Y. Input from other WGs . Z. AOB: . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WW, 25-APR-2002 08:52:07 _________________________________:_____________________________________ 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

2 1

Re: Multiple signatures to create a reference to an irt object
by Wilfried Woeber, UniVie/ACOnet 25 Apr '02

25 Apr '02

Hi Alex! >So far, the response to my query has been, well, nil :-( Maybe I'm asking >this question on the wrong list? This must have been tested before... > >Cheers, >Alex Well, I guess the answers are: NO (wrong list) and WELL... (tested for all situations) Do you want it on the WG agenda for next week? Wilfried. ___________ SWITCH - The Swiss Academic and Research Network ___________ Alexander Gall, SWITCH, Limmatquai 138, CH-8001 Zurich, Switzerland gall(a)switch.ch Tel: +41 1 268 1522 Fax: +41 1 268 1568 > Hello > > I've been playing around with PGP authentication and irt objects in the > test database and ran into the following problem. > > The relevant objects are > > mntner: SWITCH-MNT > irt: IRT-SWITCH > inetnum: 130.59.0.0 - 130.59.255.255 > key-cert: PGPKEY-C3BA4795 > key-cert: PGPKEY-82146071 > > They are all protected by SWITCH-MNT, which has a single auth attribute > pointing to PGPKEY-C3BA4795. Updates signed with this key work fine. > > IRT-SWITCH has the attribute auth: PGPKEY-82146071. > > What I would like to do is to add mnt-irt: IRT-SWITCH to the inetnum > object. If I understood correctly, I have to sign that update with two keys: > with key C3BA4795 because the inetnum is protected by SWITCH-MNT and with > 82146071 because a new reference to an irt object needs to be signed by > the key referenced in the irt's auth attribute. > > The question is, which MIME message sent to test-dbm(a)ripe.net > does this for me? > > My interpretation of the (rather brief) section "3.3.2 PGP support" in the > handbook is that I need to create a MIME message with nested signatures. > So, I created such a beast by hand because my mailer can't do that (see > first attachment). Apparently, the robot checks the outer signature but > does not recognize the inner multipart/signed content-type (see second > attachment). > > Unless my MIME encoding is wrong (which may well be the case :-) I must > have misunderstood the mechanism. > > Any help is appreciated. > -- > Alex > ___________ SWITCH - The Swiss Academic and Research Network ___________ > Alexander Gall, SWITCH, Limmatquai 138, CH-8001 Zurich, Switzerland > gall(a)switch.ch Tel: +41 1 268 1522 Fax: +41 1 268 1568 --------------------------------------------------------------------------------

3 2

Multiple signatures to create a reference to an irt object
by Alexander Gall 24 Apr '02

24 Apr '02

Hello I've been playing around with PGP authentication and irt objects in the test database and ran into the following problem. The relevant objects are mntner: SWITCH-MNT irt: IRT-SWITCH inetnum: 130.59.0.0 - 130.59.255.255 key-cert: PGPKEY-C3BA4795 key-cert: PGPKEY-82146071 They are all protected by SWITCH-MNT, which has a single auth attribute pointing to PGPKEY-C3BA4795. Updates signed with this key work fine. IRT-SWITCH has the attribute auth: PGPKEY-82146071. What I would like to do is to add mnt-irt: IRT-SWITCH to the inetnum object. If I understood correctly, I have to sign that update with two keys: with key C3BA4795 because the inetnum is protected by SWITCH-MNT and with 82146071 because a new reference to an irt object needs to be signed by the key referenced in the irt's auth attribute. The question is, which MIME message sent to test-dbm(a)ripe.net does this for me? My interpretation of the (rather brief) section "3.3.2 PGP support" in the handbook is that I need to create a MIME message with nested signatures. So, I created such a beast by hand because my mailer can't do that (see first attachment). Apparently, the robot checks the outer signature but does not recognize the inner multipart/signed content-type (see second attachment). Unless my MIME encoding is wrong (which may well be the case :-) I must have misunderstood the mechanism. Any help is appreciated. -- Alex ___________ SWITCH - The Swiss Academic and Research Network ___________ Alexander Gall, SWITCH, Limmatquai 138, CH-8001 Zurich, Switzerland gall(a)switch.ch Tel: +41 1 268 1522 Fax: +41 1 268 1568

1 1

working on the draft agenda for DB-WG, call for input
by Wilfried Woeber, UniVie/ACOnet 24 Apr '02

24 Apr '02

Dear Working Group folks, I am working on the draft agenda for the DataBase Working Group meeting during RIPE 42 next week... So this is my call for input to the draft agenda. Thanks, Wilfried.

1 0

Minutes from RIPE-41
by Nigel Titley 10 Apr '02

10 Apr '02

Gentlefolks, Please find enclosed the final minutes of the DB-WG at RIPE-41. These are essentially the same as the draft minutes, as no comments were received on the draft. Webmaster, please could you replace the draft minutes with this final version Nigel

1 0

MD5 proposal
by Andrei Robachevsky 10 Apr '02

10 Apr '02

Dear Colleagues, You may remember that at the RIPE-41 it was agreed to improve the security of password(passphrase) based auth-schemes by introducing the MD5 hash algorithm for password encryption. Please find enclosed the MD5 proposal for your comments and suggestions. Regards, Andrei Robachevsky DB Group Manager RIPE NCC Improving security of password (passphrase) based auth schemes (MD5 proposal) -============================================================================- Introduction ------------ Currently the RIPE Database implements the only password based "auth" scheme, which is "CRYPT-PW" scheme. This scheme uses an encryption process which is similar to that used to make and check login passwords in UNIX. A password is chosen by the user; this is encrypted using DEC crypt(3) and put in the database. The encrypted password can be seen by everyone. The user sends the clear password in the same mail as the request to change an object using "password:" pseudo-attribute. Motivation ---------- The main flaw of the CRYPT-PW scheme is that password is limited to 8 characters, which makes exhaustive searches of the key space possible given that crypted password is publicly available. Also the DES algorithm itself has a few quirks which lower the security of the scheme. Allowing longer keys and using more secure encryption algorithm could improve security of password-based auth scheme. Proposal -------- A new "auth:" scheme is introduced based on MD5 hash algorithm. The format of the new "auth" scheme is: auth: MD5-PW <digest> where <digest> is a 128-bit MD5 digest. For example: auth: MD5-PW 4aabd3dbc0746c8a4b5467f99a4f8524 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. If the key gets split across multiple lines this will be treated as syntax error. If the mntner that defines authorisation information for the submission has CRYPT-PW and MD5-PW "auth" schemes, the key specified by "password:" will be checked for both types.

8 14

Re: MD5 proposal
by Poul-Henning Kamp 02 Apr '02

02 Apr '02

In message <20020325130131.T20936(a)isnic.is>, Olafur Osvaldsson writes: >> auth: MD5-PW 4aabd3dbc0746c8a4b5467f99a4f8524 >> > >Why not use md5 crypt wich is already used on many operating systems for >passwords? > >auth: MD5-PW $1$sD9e4pQn$1832L4.BxsZHusy0plg8i0 The source can be found here: http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libcrypt/crypt-md5.c -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk(a)FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.

1 0

Re: MD5 proposal
by Olafur Osvaldsson 02 Apr '02

02 Apr '02

Hi, On Mon, 25 Mar 2002, Andrei Robachevsky wrote: > Proposal > -------- > > A new "auth:" scheme is introduced based on MD5 hash algorithm. The format > of the new "auth" scheme is: > > auth: MD5-PW <digest> > > where <digest> is a 128-bit MD5 digest. > > For example: > > auth: MD5-PW 4aabd3dbc0746c8a4b5467f99a4f8524 > Why not use md5 crypt wich is already used on many operating systems for passwords? auth: MD5-PW $1$sD9e4pQn$1832L4.BxsZHusy0plg8i0 /Oli -- Olafur Osvaldsson Systems Administrator Internet a Islandi hf. Tel: +354 525-5291 Email: oli(a)isnic.is

1 0

Flap Viewer
by Fabrizio Lombardozzi 02 Apr '02

02 Apr '02

Hi ris-users, my name is Fabrizio Lombardozzi, I've developed a system to monitor inter-AS routing instabilities (route flaps) at the Computer Networks Research Group, of the Roma III University, Italy. The system retrieves BGP data from RIS, and produces interactive graphs and animations using a graph drawing engine and intuitive morphing animations, with a reasonably friendly web graphic user interface (it's an applet). I will be grateful if you could give me some comments and hopefully suggestions. At the url http://www.dia.uniroma3.it/~compunet/ you will find detailed instructions to start the applet and also a gallery with screenshots and animations. Thanks in Advance Fabrizio

2 2

Re: MD5 proposal
by Lutz Donnerhacke 02 Apr '02

02 Apr '02

On Mon, Apr 01, 2002 at 01:32:24AM +0300, Andrei Robachevsky wrote: > Allowing longer keys and using more secure encryption algorithm could > improve security of password-based auth scheme. > > A new "auth:" scheme is introduced based on MD5 hash algorithm. The format > of the new "auth" scheme is: > > auth: MD5-PW <digest> > > where <digest> is a 128-bit MD5 digest. > > For example: > > auth: MD5-PW 4aabd3dbc0746c8a4b5467f99a4f8524 Please allow me to disturb your discussion. Using only a hash of a secret does protect the structure of the secret, but does not increase the security itself. The security risk a password protection scheme protects against is unauthorised access. This scheme is obviously vulnerable against eyesdropping. Replacing the secret by a hash of the secret does change nothing of this scheme. The hash does protect against attackers seeking for structured secrets (i.e. Customer-ID || "-" || Service), which allow them to guess other secrets correctly. So a hash does only protect customers with correlated, easy guessable passwords. Futhermore this protection is weak, because those secrets can be determined by a simple dictionary attack. In order to really increase security there are two easy to implement variants: Descending Hashes (transaction hashes) Store a hash in your database as usual. A message is valid, if they HASH in the message can be hashed in a limited number of steps to the stored one. Then (with a time window for disordered messages) replace the stored hash by the new one. To reset the hash, allow a new syntax: SET-HASH authorised by this scheme itself to set this new value instead of the hash used for authentification. Example: Hash Generation: Choose a secret => [h(=@X&Z Genereate a number of hashes => 0cad040d8049d9b612009821981ea1be (shorten to demonstrate) => 9b7a384557c7b80d321ae00e3ac40c79 => 980982910baed9b8642b5254b2ca495b => c1322fe1ea006cbc265e4efde666724d => b1b7a8a865734a4d4042f99441bda01e Store the initial hash "b1b7a8....da01e" in the DB. Send a authenticated message with the hash "c1322f...724d". Verification "echo -n 'c1322f...724d' | md5sum -b" successful and therefore the hash in the database is replaced by "c1322f...724d". Keyed Hashes Store a secret in your database as usual. A message is valid, if some header lines, followed by the whole body of the message (but without the hash line itself), and followed by the line: "Password: >>secret<<" hashes to the same result as provided in the HASH line. Pro and Cons: Transaction hashes are easy to compute even on Windows systems. Keyed hashes are difficult to compute on integrated mail systems. Transaction hashes are convertion independed. Keyed hashes should be taken the MIME way to be robust (software required). Transaction hashes require organisational prerequisites to be multiuser able. Keyed hashes can be computed indiviually. Transaction hashes require a sort of ordered message processing. Keyed hashes can be verified in any order. Transaction hashes provide an autoaging. Keyed hashes (without header processing) allow replay attacks. Enough?

1 0

Re: MD5 proposal
by Andrei Robachevsky 02 Apr '02

02 Apr '02

Ulf Kieber wrote: > Andrei Robachevsky writes: > >>>At the first character after the first white space (space or tab) >>> >>>>following the colon (":") >>>> >> >>>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. If the key gets split across multiple >>>lines this will be treated as syntax error. >>> >> >>The value of the key starts at the first character after the first white >>space following the colon (":"). >> > > If I understand you and Engin's previous comment correctly, this would > change current behaviour, which is according to Engin's comment > > ``key starts after the first non-white space character after the colon'' > > Don't! This would most probably break people's scripts. > Sorry, I wasn't clear. ``Key starts at the first non-white space character after the colon''. That's how it works now. -- Andrei

1 0

Re: Deprecation of the MAIL-FROM auth scheme
by Christoph Kuhles / Aquatix RIPE services 31 Mar '02

31 Mar '02

Dear Andrei & list, talking about a secure database, I wonder why the crypted password is shown when using CRYPT-PW as authentication scheme? While it might take long to get the clear-text password using brute force or dictionary attacks, it is still possible. Why not patch the whois server so it doesn't show the crypted password and hence make hijacking of objects impossible by bruteforcing a maintainer password? Best regards Christoph Kuhles Managing Director Aquatix IT-Services e.K. Monday, March 25, 2002, 1:58:10 PM, you wrote: AR> Please find enclosed the migration plan to a more secure database.

1 0

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

31 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 31 Mar '02

31 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 Engin Gunduz 31 Mar '02

31 Mar '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 31 Mar '02

31 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.

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