April 2002 - db-wg - mailman.ripe.net

<auto-dbm@ripe.net> is slow this afternoon.
by RIPE Database Administration 17 May '18

17 May '18

Dear Colleagues, Because of a very high level of use this afternoon, the response time of <auto-dbm(a)ripe.net> is longer than normal. I have made contact with those who are responsible and I expect the situation to improve as the machine works through the queue. Please be patient. Obviously we at the RIPE NCC Database Group are continuously working to make the performance of the database as good as possible. However, we cannot make improvements in zero time. We thank you for your co-operation up to now and we ask for your continued co-operation so that everyone receives the best possible service. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

2 2

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

26 Apr '02

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

6 6

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

25 Apr '02

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

1 0

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