- db-wg - mailman.ripe.net

Outage report
by Denis Walker 15 Dec '06

15 Dec '06

Dear Colleagues, >From Thursday, 14 December 2006 to mid afternoon on Friday, 15 December 2006, our Test Database server was unable to send e-mail. This may have delayed acknowledgments for updates to the Test Database and data consistency reports. This problem was due to an internal DNS issue on one of our servers. It has now been resolved. All queued mails have now been sent. We apologise for any inconvenience. If you have any questions or concerns about this, please contact us at: <ripe-dbnm(a)ripe.net> Regards, Denis Walker Database Group RIPE NCC

1 0

New organisation type proposal "NON-REGISTRY" => "OTHER"
by Katie Petrusha 11 Dec '06

11 Dec '06

[Apologies for duplicate mails] Dear colleagues, This is a proposal to change the organisation type "NON-REGISTRY" to "OTHER" for ORGANISATION objects in the RIPE Database. Motivation: The RIPE ENUM Working Group needs a more general organisation type for the ORGANISATION object. Many organisations have the organisation type "NON-REGISTRY". In the context of the RIPE Database, this is correct. However, some organisations have different functions in other contexts. The RIPE ENUM Working Group proposes changing the organisation type from "NON-REGISTRY" to "OTHER". More details are available at: http://www.ripe.net/ripe/maillists/archives/enum-wg/2006/msg00100.html Implementation: The proposed change involves changing the syntax of the ORGANISATION object in the RIPE Database. It does not involve any new or changed authorisation rules or changes to any other objects. Consequences for Existing Objects: Around 20,000 ORGANISATION objects in the RIPE Database have the status of "NON-REGISTRY". The RIPE NCC will modify these objects. Before making any changes, we will tell the object holders about what will happen. If you have any questions about this, send an e-mail to <ripe-dbm(a)ripe.net> Kind Regards, -- Katie Petrusha RIPE NCC

1 0

Assignments of 32 bit AS Numbers
by Henk Uijterwaal 05 Dec '06

05 Dec '06

Dear Colleagues, From 1 January 2007, the RIPE NCC can assign 32-bit Autonomous System Numbers (ASNs). There is more information about this policy in ripe-389: http://www.ripe.net/ripe/docs/ripe-389.html Details of how to request a 32 bit ASN are in ripe-396: http://www.ripe.net/ripe/docs/asnsupport.html ASN32 objects will appear in the RIPE Database from 1 January 2007. Their format is different from the current 16-bit ASNs. The new format is described in these documents: http://www.ietf.org/internet-drafts/draft-michaelson-4byte-as-representatio… http://www.ietf.org/internet-drafts/draft-uijterwaal-rpsl-4byteas-ext-01.txt The introduction of 32-bit ASNs may have an effect on tools that query the RIPE Database or those based on RPSL. A test server is available. There is more information at: http://www.ripe.net/news/asn-test-server.html Sites using the RIPE Database software will probably have to upgrade their systems, see: http://www.ripe.net/news/asn-db-update.html For more information, please contact us at <asn32(a)ripe.net>. Answers to frequently asked questions will appear in the RIPE NCC FAQ at: http://www.ripe.net/info/faq/ Kind Regards, The RIPE NCC -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------

1 0

CRYPT-PW Deprecation Project: Phase 1
by Agoston Horvath 01 Dec '06

01 Dec '06

[Apologies for duplicate mails] Dear Colleagues, Phase 1 of the CRYPT-PW deprecation project will start today, Thursday, 30 November 2006. This project will deprecate RIPE Database passwords that use the CRYPT-PW authentication method. Notification e-mails will be sent today to over 8300 e-mail addresses, concerning a total of 3587 objects with CRYPT-PW authentication only. Another 326 objects have other authentication methods in addition to CRYPT-PW. If you receive a separate notification e-mail you will have to change your password authentication method to PGP, X.509 or MD5-PW. To change your password authentication method from CRYPT-PW to MD5-PW, use the CGI at: http://www.ripe.net/cgi-bin/crypt2md5.cgi More information about the project can be found at: http://www.ripe.net/db/support/security/crypt-pw_deprecation/ *Key dates* Thursday, 30 November 2006: Notification (Phase 1) Wednesday, 10 January 2007: Reject new CRYPT-PW (Phase 2) Wednesday, 21 February 2007: Remove CRYPT-PW from RIPE Database (Phase 3) If you have any questions, contact: ripe-dbm(a)ripe.net. Regards, Agoston Horvath Database Group RIPE NCC

2 2

New RIPE Documents 395 and 396, on AS Number Requests
by RIPE NCC Webmaster 23 Nov '06

23 Nov '06

[Apologies for duplicate e-mails] Dear Colleagues, We are pleased to announce the publication of two updated RIPE Documents. ripe-395 - Supporting Notes for the Autonomous System Number Request Form is available at: http://www.ripe.net/ripe/docs/asnsupport.html ripe-396 - AS Number Request Form is available at: http://www.ripe.net/ripe/docs/asnrequestform.html We have updated the documents to include 4-byte (32 bit) AS Numbers, which can be requested from 1 January 2007. Best Regards, Laura Cobley Registration Services RIPE NCC

1 0

Re: [db-wg] 96.0.0.0/20
by Randy Bush 16 Nov '06

16 Nov '06

> according to our logs the mail was sent: i found the problem the mail is being sent as From MAILER-DAEMON Thu Nov 16 18:01:47 2006 Return-path: <> you should not be doing this! that is reserved for mail delivery failures. randy

2 1

Re: [db-wg] 96.0.0.0/20
by Randy Bush 16 Nov '06

16 Nov '06

> Stab in the dark, so I could be completely off here, but did you try > adding a "password: RPSL" to the top of the request? (Look at the > "RIPE-NCC-RPSL-MNT" object for a possible reason to try that.) yep. still zero response to email to auto-db i have a suspicion it may be due to the database having an outdated pgp key, and i am signing with a new one (bellovin and austein made me upgrade a 12 year old one, so don't blame me:-). which leaves me with the question of how to change a key-cert: object without digging up the old key! randy

2 2

ASN32 test server
by Katie Petrusha 16 Nov '06

16 Nov '06

[Apologies for duplicate mails] Dear colleagues, As you may be aware, from 1 January 2007, it will be possible to request 32-bit ASNs (ASN32 objects). You can find the policy on these 4-byte ASNs at: http://www.ripe.net/ripe/docs/ripe-389.html Although the first of these will not appear in the RIPE Database until the start of next year, we have set up an ASN32 TEST server. This server has a copy of the RIPE Database as of 2006.11.07. It is available for queries: asn32.ripe.net port 43043 And for updates: asn32-dbm(a)ripe.net You may use this database to create your own test ASN32 object(s). You may also test against the existing "aut-num" object AS1.1 See 'whois -h asn32.ripe.net -p 43043 -rGB AS1.0 - AS1.65535' for more details. Please note that updates made to the ASN32 TEST Database will not change any data in the RIPE Database. The notifications are disabled to avoid confusion, the acknowledgements will be sent as usual. We hope it is clear that these are test messages. The following banner has been added to mails: ############################################################## # # # This is the ASN32 Test Server # # # # This update DID NOT affect any RIPE Database objects # # # # To update the live RIPE Database, mail to auto-dbm(a)ripe.net# # # ############################################################## If you have any questions, contact ripe-dbm(a)ripe.net. -- Katie Petrusha RIPE NCC

1 0

SPAM filtering at RIPE NCC
by Brian Riddle 16 Nov '06

16 Nov '06

[Apologies for duplicate e-mails] Dear Colleagues, Today, we implemented measures to combat spam on our mail servers. The measures will apply to both e-mails sent to RIPE NCC mailboxes and the mailing lists hosted on ripe.net. These measures will lead to short delivery delays for some of your e-mails to us and to the mailing lists. Regards, Brian Riddle IT Manager RIPE NCC

1 0

96.0.0.0/20
by Randy Bush 16 Nov '06

16 Nov '06

the appended disappeared into a black hole. clue bat, please randy

1 0

SSL/TLS at RIPE mail servers
by Max Tulyev 01 Nov '06

01 Nov '06

Hi! At the last meeting we had a talk about implementing TLS/SSL in RIPE mail servers to avoid sniffing clear-text passwords in RIPE DB update requests. Is there any news? ;) -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)

3 2

Announcement Routing Registry Training Courses
by RIPE NCC Training Services 31 Oct '06

31 Oct '06

Dear Colleagues The RIPE NCC Training Services Department invites you to register for one of our upcoming Routing Registry Training Courses: Date: Friday 3 November 2006 Time: 09:00 - 17:00 Location: Amsterdam, Netherlands AND Date: Tuesday 6 February 2007 Time: 09:00 - 17:00 Location: Tel Aviv, Israel AND Date: Friday 23 February 2007 Time: 09:00 - 17:00 Location: Vienna, Austria AND Date: Thursday 8 March 2007 Time: 09:00 - 17:00 Location: Edinburgh, United Kingdom ND Date: Friday 23 March 2007 Time: 09:00 - 17:00 Location: Prague, Czech Republic The main objective of the "Routing Registry Training Course" is to familiarise the LIRs with the features of the Routing Registry, while introducing the relevant tools and services of the RIPE NCC. The course also offers practical exercises. OVERVIEW OF TOPICS COVERED IN THE COURSE: - Routing Registry as a part of the RIPE Whois Database and the Internet Routing Registry (IRR) - Specifying routing policies using (RPSL) Routing Policy Specification Language and the RtConfig tool - IRRToolSet - Routing Information Service (RIS) - Routing Registry Consistency Check Project Please note that this is an advanced course. It will: - NOT teach the basics of routing - NOT teach the basics of RIPE Database operations - NOT describe how to receive Internet resources from the RIPE NCC - NOT describe how to operate a Local Internet Registry (LIR) The target audience of the course are technical staff of LIRs: e.g. network operators, engineers etc. This course is not intended for administrative or management staff (e.g. Hostmasters) . It is assumed that all attendees will be familiar with Border Gateway Protocol routing and with the RIPE Database (i.e. creating/modifying objects). This course is based on interactive exercises in a local network set-up. Please bring your laptops equipped with the following: - A working Ethernet card, - Three meters of Ethernet cable, - A secure connection client, - A web browser. Please be prepared to share your laptop (or at least allow another attendee to "look over your shoulder") if necessary. The course is free of charge. We provide lunch and printed training materials. We do not cover any of your travel expenses or accommodation. We give all of our training courses in English. You can find more information about the course at: http://www.ripe.net/training/rr/ How to register: --------------------- You can register up to two people from your LIR for each course. (If there are places left nearer the time of the course, you can register more people). To register for this course, you can either use the LIR Portal at: https://lirportal.ripe.net/lirportal/training/course-list.html Or the online registration form on our website: http://www.ripe.net/cgi-bin/trainingform.pl.cgi If you have any questions, send an e-mail to <training(a)ripe.net>. Kind regards, Rumy Kanis Training Services Manager RIPE NCC

1 0

ISO Country Code Change
by Katie Petrusha 27 Oct '06

27 Oct '06

[Apologies for duplicate e-mails] Dear Colleagues, The ISO 3166 country codes list has been changed. The previous country code for Serbia and Montenegro (CS) has been replaced with two new country codes: RS - Serbia ME - Montenegro On Friday, 27 October 2006, the RIPE Database software and the LIR Portal will be altered to accept all three codes. The old CS country code will be deprecated at a later date. The full ISO 3166 country code list is available at: ftp://ftp.ripe.net/iso3166-countrycodes.txt http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/li… If you have any questions e-mail us at: ripe-dbm(a)ripe.net Kind regards, -- Katie Petrusha Software Engineer RIPE NCC

2 2

ASn32-compliant RIPE Database software available
by Katie Petrusha 25 Oct '06

25 Oct '06

[Apologies for duplicates] Dear Colleagues, The RIPE NCC has updated its database software to support the new ASN32 objects. As you may be aware, studies of Autonomous System Number (ASN) consumption rates show that the existing pool of unallocated 2-byte ASNs will run out somewhere between 2010 and 2014. >From 1 January 2007, it will be possible to request 32-bit ASNs (ASN32 objects). You can find the policy on these 4-byte ASNs at: http://www.ripe.net/ripe/docs/ripe-389.html Although the first of these will not appear in the RIPE Database until the start of next year, the revised code is available to download for testing purposes from: http://www.ripe.net/db/cvs-bugzilla.html (CVS branch name: asn32_changes_fixed) You can also find the list of modified files at the end of this mail. If you have any questions about this, please e-mail sw-bugs(a)ripe.net Regards, -- Katie Petrusha Software Engineer RIPE NCC List of changed files in RIPE whois software: ----------------------- src/defs/variants/RIPE/syntax.xml src/defs/variants/RIPE/classes.xml defs/variants/RIPE/attributes.xml all the lex/yacc parser files wk/which_keytypes.c wk/which_keytypes.h src/modules/ln/lu_whois.c src/modules/qi/query_instructions.c src/modules/qc/query_command.c conf/rip.config.sample.in src/modules/ca/ca_dictionary.h src/modules/ca/ca_macros.h src/modules/ca/dictGen.m4 src/modules/ud/ud_core.c src/SQL/create.tables.in src/SQL/create_asn32.patch.in dbupdate test-data files in tests/dbupdate/test-data src/modules/qc/query_command.h src/modules/ud/ud.h src/modules/ud/ud_command.c -------------------------

1 0

Webquery and Webupdates services were unavailable
by Trudy Prins 24 Oct '06

24 Oct '06

[Apologies for duplicate mails] Dear Colleagues, Between 14:30 - 14:50 (UTC) on Tuesday, 24 October 2006 our Webquery and Webupdates services were unavailable. This problem was due to performance issues on one of our servers and has now been resolved. We apologise for any inconvenience. If you have any questions or concerns regarding this issue, please contact us at: <ripe-dbm(a)ripe.net> Regards, -- Trudy Prins User Support Coordinator

1 0

Re: [enum-wg] Proposal for new org-type
by Niall O'Reilly 19 Oct '06

19 Oct '06

This message has two purposes. It is addressed to the ENUM WG with the purpose of determining consensus in this WG on the proposal from Antoin Verschuren. It is addressed to the DB and NCC-Services WGs as an inter-WG communication to alert these WG's to expect a consensus in the ENUM WG and a request from ENUM WG for related changes to the RIPE database. On 3 Oct 2006, at 10:35, Antoin Verschuren wrote: > In order for ENUM registries to be correctly distinguished in the RIPE > NCC database, I want to propose a new organization type to be used in > the organization object. > > Current organization types are: > IANA > RIR > NIR > LIR > NON-REGISTRY > > I would like this list to be extended with the term REGISTRY. > > I will note the issue tomorow in the ENUM WG, but need consensus to > take > place here, so please comment either here or tomorrow in the ENUM WG > session. On 4 Oct 2006, at 09:47, Antoin Verschuren wrote: > I can live with ENUM-REGISTRY, REGISTRY, OTHER or no org-type at all. > I cannot live with the org-type NON-REGISTRY. During his presentation in the ENUM WG, Antoin Verschuren made the following proposal. > In order for ENUM registries to not be misinterpreted in the RIPE > NCC database, I want to propose to change an organization type to be > used in the organization object. > Current organization types are: > > IANA > > RIR > > NIR > > LIR > > NON-REGISTRY > I would like this NON-REGISTRY to be changed to OTHER. I will declare consensus in the ENUM WG unless objections to Antoin's proposal are posted on the ENUM WG mailing list before 12:00 UTC on Thursday, 18 October 2006. Best regards, Niall O'Reilly Co-Chair, RIPE ENUM Working Group

2 3

org: question
by Max Tulyev 18 Oct '06

18 Oct '06

Hi! As a LIR, I have org: object (with org-type: LIR). But I can't use it in my objects, because of there is mnt-ref: RIPE-NCC-HM-MNT. The question is why? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)

1 0

Deprecation of CRYPT-PW authorisation from the RIPE Database
by Agoston Horvath 16 Oct '06

16 Oct '06

Dear colleagues, I would like to inform you that the project to deprecate CRYPT-PW authorisation in mntner objects in the RIPE Database is scheduled to start this week. Regards, Agoston Horvath Software Engineering Department RIPE NCC -------- Original Message -------- Subject: [db-wg] Proposal to deprecate CRYPT-PW authorisation in the RIPE Database Date: Wed, 4 Oct 2006 15:48:12 +0200 From: Katie Petrusha <katie(a)ripe.net> To: db-wg(a)ripe.net Dear colleagues, Here follows the proposal to deprecate CRYPT-PW authorisation in mntner objects in the RIPE Database. Comments would be appreciated. Background and motivation ------------------------- In the RIPE Database there are several authorisation types currently supported: CRYPT-PW, MD5-PW, PGPKEY and X509. These authorisation types define what kind of authorisation tokens can be used in "mntner" objects. CRYPT-PW authorisation type is based on UNIX crypt() functionality and is vulnerable to both dictionary and brute force attacks given the fixed password length and lack of cryptographic strength given today's computing power. While maintaining and protecting objects in the RIPE Database is the responsibility of the respective maintainer, the RIPE DB WG agreed that it's the responsibility of the community to ensure that only appropriate tools and algortihms are used and maintained. Since CRYPT-PW does no longer fulfill this requirements with the reasons given above, the WG also agreed to phase out CRYPT-PW. PGPKEY and X.509 have been the recommended authentication schemes for some time (http://www.ripe.net/db/support/security/security.html) MD5-PW shares two weaknesses with CRYPT-PW: passwords are sent in clear together with update requests and MD5 is vulnerable to dictionary attacks,as well. Still, MD5-PW will not be phased out together with CRYPT-PW, since at least the dictionary attack can be prevented by chosing passwords or pass phrases of appropriate length and entropy. MD5 offers a short path of migration away from CRYPT-PW without major change in processes. LIRs should, however, seriously consider a migration towards a public key based authentication scheme (PGPKEY or X.509). The MD5-PW method will be addressed separately. We propose to deprecate the CRYPT-PW authorisation step-by-step. Affected objects ---------------- There are currently ~3500 mntner objects in the RIPE Database that have only CRYPT-PW authorisation. There are about 300 mntner objects that have mixed authorisation of CRYPT-PW and some other authorisation types. Plan ---- 1. Gather mntner objects: group A: only CRYPT-PW authorisation group B: CRYPT-PW and (PGP or X509 or MD5) authorisation 1a. E-mail the contacts of those mntner objects (notify, admin-c, tech-c, mnt-nfy) to notify them about the coming change. 1b. notify the DB-WG mailing list 1 month later: 2. Modify the RIPE Database software: 1) reject any change to mntner object that adds new CRYPT-PW. 2) show a warning if CRYPT-PW was used during authorisation. 3) show a warning if object being updated still contains (existing) CRYPT-PW. 2a. E-mail the contacts of the mntner objects (notify, admin-c, tech-c, mnt-nfy) notifying them about the change and the next steps. 2b. notify the DB-WG mailing list 1 month later: 3. Modify the RIPE Database software: 1) disable CRYPT-PW in the syntax 2) disable CRYPT-PW in authorisation 3a. Modify mntner objects. group A: auth: is changed to MD5-PW, new password generated. group B: auth: CRYPT-PW is changed into "remarks" line "remarks: "your object was modified due to CRYPT-PW deprecation" is added 3b. Notify the contacts of the mntner objects: group A: explanation about the changes done, and URL with details on how to 'recover' the locked mntner object (similar to NONE deprecation process) group B: explanation about the changes done 3c. notify the DB-WG mailing list 4. Finished.

1 0

First draft of RIPE53 minutes
by Nigel Titley 06 Oct '06

06 Oct '06

Folks, Please find first rough draft of minutes of this morning's meeting. Comments welcome. Nigel <<Minutes.txt>>

1 0

FW: FW: FW: FW: FW: [db-wg] Proposal to deprecate CRYPT-PW authorisation in the RIPE Database
by Potapov Vladislav 06 Oct '06

06 Oct '06

Hi, ---Gert Doering--- The information in the RIPE DB, especially the route: and aut-num: objects, are very closely tied to operational issues. A number of large networks (specific example: Cable & Wireless, AS1273, our upstream provider) are using this data to build their BGP filters. This is very much "hard tied to operational issues". ------------------ Gert, you know very well that the RIPE DB is not the only DB in the world. It is inaccurate at the moment in many cases. There are several networks which are not in any DB. "The large networks" may use SOME DB records, yes, but they use other ways to build their configuration too. They HAVE TO live in the real world. It's their "operational issues". Then they can live with it further. I think that sort of global changes for so many users of the DB (not "lookers" but a sort of "data administrators") should be done with their opinions and their "operational issues" taking into account but not the only "big fish players. Vladislav Potapov Ru.iiat P.S. To Max Tulyev:"I will be so thankful if you will point me to the law ;)" I won't do that for many reasons. In the Internet there are many answers to your questions.

1 0

FW: FW: [db-wg] Proposal to deprecate CRYPT-PW authorisation in the RIPE Database
by Potapov Vladislav 05 Oct '06

05 Oct '06

Hi! ---Max Tulyev--- In Russia ALL uncertified by goverment cryptographic system is illegal. So SSL (lirportal) is illegal. But PGP/MD5/CRYPT is NOT illegal, because it don't do encryption and not interfere with SORM (SORM - a mandatory part of any ISP in Russia, that do hidden analysis and mirroring some of traffic to FSB), but only do signatures. ---- I can say that you are wrong. There are many proves of that. ---Max Tulyev--- Also, unlike PGP, lirportal can't do safr multiply persons authorization (i.e. owner of PI space creates route object with his upstream's AS, signs it, sent to upstream, upstream signs it too and send to RIPE). ---- Are we going to discuss a new proposal already instead of existing? :) The way you have mentioned works just so ONLY because the method (e-mail) used for the problem resolution. You himself (I don't even mean the community) can suggest much more easy and preferrable method of multiply person authorisation by a web-site (lirportal). Vladislav Potapov Ru.iiat

2 1

RE: FW: [db-wg] Proposal to deprecate CRYPT-PW authorisation in the RIPE Database
by Potapov Vladislav 05 Oct '06

05 Oct '06

Hi! > Vladislav! If you wish to be really constructive - do policy > proposal for shutting down MD5-PW - personally I will vote > for that too. Max, I'm not a reactionary as you may think. I'm not against changes to the better. But it should be adequate, effective and universal for the region it serves. I don't know why you start to think on behalf (and propose against) of the 3500 other members using the scheme. If we got to the stage of a new proposal then maybe we should drop e-mail as a way to change the objects in the DB? It will be more constructive than shutting down both "password" ways. At least this way solves the "crypting mail prohibited" problem together with crypting ALL conversation (not only password part) and many more (and much more productive that the halved currently proposed "step"). The mechanism for that is already here - lirportal. Vladislav Potapov Ru.iiat > -----Original Message----- > From: db-wg-admin(a)ripe.net [mailto:db-wg-admin@ripe.net] On > Behalf Of Max Tulyev > Sent: Thursday, October 05, 2006 9:13 PM > To: db-wg(a)ripe.net > Subject: Re: FW: [db-wg] Proposal to deprecate CRYPT-PW > authorisation in the RIPE Database > > > Hi! > > My official +1. We need to shut it out as mail-from was. > > Vladislav! If you wish to be really constructive - do policy > proposal for shutting down MD5-PW - personally I will vote > for that too. > > Sascha Lenz wrote: > > Hi, > > > > Potapov Vladislav wrote: > > > >> Hi, > >> -Hank > >> > >>> I think a number of people have pointed out why they wish to > >>> deprecate > >>> > >> crypt-pw. > >> No, I'm not convinced. And a number of people - only Gert Doering? > >> The point of view they propagate - it should increase security (in > >> reality - not). But, we all know: false sense of security is worse > >> than knowledge of a problem. > >> > > > > actually i don't care much about this issue, but since you > raise the > > question - i have show my support for Gert/the proposal in general > > here, that is, i'm IN FAVOR of the depreciation of CRYPT-PW. > > > > It's not needed, it's more than a litte more insecure than > MD5-PW, it > > doesn't change anything operational. > > > > ..and no i'm not going to comment any other side-arguments > here, gets > > too personal. > > > > I support the original proposal - full stop. > > > > > > > -- > WBR, > Max Tulyev (MT6561-RIPE, 2:463/253@FIDO) > >

2 1

FW: FW: FW: [db-wg] Proposal to deprecate CRYPT-PW authorisation in the RIPE Database
by Potapov Vladislav 05 Oct '06

05 Oct '06

Hi! I don't understand WHAT IT'S PROVES? Or you decided to say something only to be shown? -----Original Message----- From: db-wg-admin(a)ripe.net [mailto:db-wg-admin@ripe.net] On Behalf Of Max Tulyev Sent: Thursday, October 05, 2006 2:16 PM To: db-wg(a)ripe.net Subject: Re: FW: FW: [db-wg] Proposal to deprecate CRYPT-PW authorisation in the RIPE Database Hi! Come on, begin your education career from your FSB (ex-KGB if somebody don't know) colleagues: inetnum: 213.24.76.0 - 213.24.77.255 netname: RT-CLNT-FSB-RF descr: Federal Security Service of Russian Federation descr: 3/6 Lubyansky Proezd Moscow 103045 country: RU admin-c: DIP2-RIPE admin-c: ANH8-RIPE tech-c: ANH8-RIPE tech-c: DIP2-RIPE status: ASSIGNED PA mnt-by: AS8342-MNT source: RIPE # Filtered person: Dmitry Pravikov address: FSB RF address: 3/6 Lubyansky Proezd Moscow 103045 remarks: phone: +7 095 2248374 phone: +7 495 2248374 remarks: fax-no: +7 095 2244441 fax-no: +7 495 2244441 e-mail: pravikov(a)fsb.ru nic-hdl: DIP2-RIPE source: RIPE # Filtered remarks: modified for Russian phone area changes person: Alexander Holushco address: FSB RF address: 3/6 Lubyansky Proezd Moscow 103045 remarks: phone: +7 095 2244441 phone: +7 495 2244441 remarks: fax-no: +7 095 2244441 fax-no: +7 495 2244441 e-mail: root(a)fsb.ru nic-hdl: ANH8-RIPE source: RIPE # Filtered remarks: modified for Russian phone area changes % Information related to '213.24.0.0/16AS8342' route: 213.24.0.0/16 descr: RTCOMM-RU origin: AS8342 mnt-by: AS8342-MNT source: RIPE # Filtered As we can see - there is *NO* mntner at all at *-c: objects! ;-) Potapov Vladislav wrote: > Hi, > > >> From: Gert Doering [mailto:gert@space.net] >> Changing from CRYPT-PW to MD5-PW doesn't incur any >> operational changes, and doesn't require key management and >> crypto of any sort, but *will* improve security. >> > No "operational changes"? Let's look at the plan to get an image that > it's not so "problemless". I don't speak about RIPE resources which > should support this change. About security: there was several > opponents of your view already. I'm adding myself to them. > > >> From: Gert Doering [mailto:gert@space.net] >> Security issues in the IRR DB impact all of us (like "fake objects, >> use that to leverage a routing attack"). >> > Let's not say fairy tales about that. I have asked about REAL LIFE > problems with the scheme. Nobody has answered. As for security > issues... I think the better way to do this things is to educate > people, convince them to have better way of security. Up to now it is > only "small group words" and 3500 usages... > > I'm against the proposal. > > Vladislav Potapov > Ru.iiat > > -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)

2 1

FW: FW: FW: FW: [db-wg] Proposal to deprecate CRYPT-PW authorisation in the RIPE Database
by Potapov Vladislav 05 Oct '06

05 Oct '06

Hi, ---- From: db-wg-admin(a)ripe.net [mailto:db-wg-admin@ripe.net] On Behalf Of Max Tulyev If to be seriously, I'm showing until weak schemes will be exist, people (even so serious) *WILL* use it. Education will *NOT* helps to solve the problem (so, try ;) ). ---- Then it's better to start banning people who do not agree with you? It's much more simplier than discuss, educate... ---- From: db-wg-admin(a)ripe.net [mailto:db-wg-admin@ripe.net] On Behalf Of Max Tulyev I agree better is set off ANY password authorization. We can do it at least step-by-step, but leave it alone is the worst thing we can do. ---- I don't think that the matter even worst speaking about, because still nobody has answered that there has been any problem with existing schemes even for no-maintainer objects (it's one more way to ignore your attempts to strengten maintainer object). So "the worst thing we can do" is only words. The information in the DB is not accurate, representative or hard tied to operational issues, so the world will be there if it disappears completely (maybe slightly annoying for some players, not more). Potapov Vladislav Ru.iiat

2 1

FW: [db-wg] Proposal to deprecate CRYPT-PW authorisation in the RIPE Database
by Potapov Vladislav 05 Oct '06

05 Oct '06

Hi, -Hank >I think a number of people have pointed out why they wish to deprecate crypt-pw. No, I'm not convinced. And a number of people - only Gert Doering? The point of view they propagate - it should increase security (in reality - not). But, we all know: false sense of security is worse than knowledge of a problem. -Hank >To answer your latest points - data in the DB should be accurate and it does show who is allowed or not allowed to use a range of IPs, and if the data does 'disappear' as you say, it will have operational impact on a number of ISPs that build their access lists from the data in the RIPE-DB. "Should be" != "is" And to now this inaccuracy has NO operational impact on nobody. -Hank >It would appear that you might be enjoying the ability to abuse certain RIPE objects with weak security and by deprecating crypt-pw we will be impacting your playground. Hank, I think it is very cheap accusation at first hand; you are not eligible to accuse me of something - the second; it (abusing) hasn't happened before to speak about it - the third. Speaking your way I can think that RIPE doesn't know where to put money and want us to allow spend them on the projects not well-thinked and useles. Please be more constructive! Let's not allow to go to personal accusation. Vladislav Potapov Ru.iiat

5 4