- db-wg - mailman.ripe.net

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

05 Oct '06

Hi, (I'm adding db-wg(a)ripe.net back into the CC: list) On Thu, Oct 05, 2006 at 01:50:09PM +0400, Potapov Vladislav wrote: > > 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"? In the day-to-day operation ("sending in mails to change objects to the RIPE DB") going from CRYPT-PW to MD5-PW *will* *not* *change* *anything*. The mail will still contain a "password: <something>" block, just the way this password is hashed in the maintainer object is different. > Let's look at the plan to get an image that it's not so "problemless". So where exactly *do* you see "problems"? In your mail you speak about "crypto" - which is NOT involved here (except hashing the password) - this proposal is not forcing anybody to go to PGP, just to a different password storing scheme. > 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. Please get a reality check on what is proposed, and what is proposed as replacement. > > 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. *Good* security is fixing problems *before* they happen. Like "lock your front door when you leave your house, even if you have never been burglared yet". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 98999 SpaceNet AG Mail: netmaster(a)Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234

1 0

Proposal to deprecate CRYPT-PW authorisation in the RIPE Database
by Katie Petrusha 05 Oct '06

05 Oct '06

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. -- Katie Petrusha RIPE NCC

7 9

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

05 Oct '06

Hi, Personally I don't agree with the proposal. It's wrong from several points of view. First of all, "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." I think the number of the objects in the DB with only CRYPT-PW authorisation shows that the method is useful and handy. Speaking about weakness... I remember the previous global deprecation of no-authorisation-at-all. The main argument was a case which involved several hundreds objects changing by an MISTAKE. I think then the deprecation was the right thing. Are there cases which involves cracking objects with CRYPT-PW authorisation? Maybe we should compare the gravity of the consequencies of leaving the authorisation scheme with complexity of mainteinance mostly informational resource? Then: "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." means for me: all users of the DB are right, but the WG is more important. Am I right? Maybe we should leave the resolution of the problem to the maintainers? There are several methods of authorisation: if someone want to severe the protection of his/her objects he/she can do it right now without any modifications! I should say about one more point. For several types of organisations in Russia (for example) there are some restrictions about using encryption and keys of some sort (for example in the e-mail messages). I think the news will bring additional concerns and problems for the organisation (I think not only in Russia). Conclusion: the proposal is rather early, unreasoned and unnessesary. Kind regards, Vladislav Potapov Ru.iiat It seems that 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. -- Katie Petrusha RIPE NCC

2 1

RE: [enum-wg] Proposal for new org-type
by Antoin Verschuren 05 Oct '06

05 Oct '06

Marco d'Itri wrote: > On Oct 03, leo vegoda <leo(a)ripe.net> wrote: > >> Do people find org-type values like IANA, RIR, LIR and so on useful? >> No. What would be the point? As Leo pointed out: Looking back into the mail archives for 2003 and 2004 I think the original purpose was to let people know how close to the End User the registration on a block of IP addresses was. If my memory is correct, the org-type was introduced after it was felt that status attribute values like "ALLOCATED-BY-IANA" or "ALLOCATED-BY-RIR" would overburden the status attribute syntax unnecessarily. One of the possible functionality could be that you'd not like to contact certain organisations holding numberblocks when abuse comes from them since you will know these numbers are distributed in a specific fashon, and you'll probably be not reaching an end user. Don't know if such routines are used. Antoin Verschuren Technical Advisor Policy & Business Development SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands T +31 26 3525510 F +31 26 3525505 M +31 6 23368970 E antoin.verschuren(a)sidn.nl W http://www.sidn.nl/

1 0

RE: [enum-wg] Proposal for new org-type
by Antoin Verschuren 04 Oct '06

04 Oct '06

Niall O'Reilly wrote: > 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. To let there be no misunderstanding, the final proposal with most consensus so far is: >> 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. Regards, Antoin Verschuren Technical Advisor Policy & Business Development SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands T +31 26 3525510 F +31 26 3525505 M +31 6 23368970 E antoin.verschuren(a)sidn.nl W http://www.sidn.nl/

1 0

Re: [enum-wg] Proposal for new org-type
by leo vegoda 04 Oct '06

04 Oct '06

Hi, I cc'd the Database WG list for input on object syntax. On 3 Oct 2006, at 4:52GMT+02:00, Ondřej Surý wrote: [...] > My point was that not only ENUM registries exists in current internet. > We are .cz domain registry and while I don't have problem with > whatever > label we have in RIPE database (we do have LIR atm), we don't exactly > fall into LIR category (in it's original meaning - ie. ISP). Hence I > could easily imagine that our org-type: would be changed to > REGISTRY to > match reality a bit more. One legal entity might run an LIR, a ccTLD registry and an ENUM registry. Whether you want to identify them as a REGISTRY, a DOMAIN- REGISTRY or something else is dependent on what you want to use the org-type to tell people. Looking back into the mail archives for 2003 and 2004 I think the original purpose was to let people know how close to the End User the registration on a block of IP addresses was. If my memory is correct, the org-type was introduced after it was felt that status attribute values like "ALLOCATED-BY-IANA" or "ALLOCATED-BY-RIR" would overburden the status attribute syntax unnecessarily. Do people find org-type values like IANA, RIR, LIR and so on useful? If not, maybe we just need two values: REGISTRY for IANA, RIRs, LIRs, TLDs and Tier 1 ENUM operators and NON-REGISTRY for everyone else. However, if people really find the hierarchical distinctions in the current org-type values useful, maybe we need some additional granularity for the different kinds of domain registries? If the extra granularity is useful, perhaps we need to allow organisations to have multiple org-type values? That's probably preferable to having multiple objects for a single organisation. Thoughts? -- leo vegoda Registration Services Manager RIPE NCC

2 1

Data Protection Task Force - Ref: RIPE53 DB-WG Draft Agenda V3. item C
by Wilfried Woeber, UniVie/ACOnet 04 Oct '06

04 Oct '06

Dear Community, the logistical infrastructure for the Data Protection Task Force has been set up by the NCC. It is available at http://www.ripe.net/ripe/tf/index.html We are trying to get together a reasonably diverse mix of people for this task force, representing the various roles, activities and types of interest. The TF will be presented and discussed on Fr. morning in the DB-WG session where we will try to collect the initial population. If you can't make it to the DB-WG meeting, please indicate your interest by personal mail to Jochem de Ruig and myself. Please read up on the TF's mandate, the goals and logistics, and consider stepping forward to *actively* contribute! Thank you. See you Friday morning, Wilfried.

2 1

Re: [address-policy-wg] 2006-04 Draft Document will be produced (Contact e-mail Address Requirements)
by Denis Walker 27 Sep '06

27 Sep '06

Wilfried Woeber, UniVie/ACOnet wrote: > Denis Walker wrote: > > [...] > >> ... If you feel this >> should have a higher priority then you may raise the issue on the Database >> Working Group or Antispam Working Group or Address Policy Working Group >> mailing lists." >> > > My feeling is that the only appropriate one is the AP-WG - if at all. > we can easily change this if the AP-WG is considered to be the best place to raise such issues. > Anti-Spam seems to be a niche market, looking at the number of different > abusive behaviour patterns, and DB-WG usually looks at issues regarding > the tools and the registration machinery. > > In particular, DB-WG is very reluctant to get drawn into (human) resource > allocation (i.e. money :-) ) discussions... > > Wilfried. > > PS: I know I am not making new friends with the following text, but still: > Spam is not a network or addressing problem - it is an application and > socio-economic problem. Now shoot - you know where to find me :-) > I think we are confusing two seperate issues here. Spam itself is a socio-economic-political problem. How to stop spam is outside the scope of network operations and addressing policy issues. But the issue here is if I can identify an individual spammer who is causing me problems who should I contact to try to have this person/organisation disconnected? This ties into the whole discussion on the irt object and abuse-mailbox: attributes. Even if we get this part exactly right, if the final email address we present to someone is invalid then the whole system breaks down. This brings us back to the question of how to enforce a policy that says everyone should keep their contact details up to date. I know it is a difficult question, but until it is addressed the whole policy on abuse handling fails. regards Denis Walker Software Engineering Department RIPE NCC

1 0

org-type: NON-REGISTRY (was: New Documents available: RIPE-384, RIPE-385)
by Niall O'Reilly 18 Sep '06

18 Sep '06

[ WG Co-Chair hat on ] On 4 Sep 2006, at 13:26, Antoin Verschuren wrote: > I have some sentimental issues with the new ENUM request forms as I > found out when I had to use them last week. I'm pretty sure that, in English, "sentimental" is the wrong word and is likely to lead to confusion. I think I know what you mean. > The new ENUM registrations ask to register an Organisation holding the > registration. > > This "Organisation" template, has a "org-type:" field. > RIPE tells me to fill in "NON-REGISTRY" in this field. > > I'm aware that we are not an RIR, LIR or NIR as in the RIR world, > but I > do feel the term "NON-REGISTRY" a bit degrading as we are the registry > for .nl and soon hopefully for ENUM. > > Can we invent a new term to use for official ENUM tier-1 registries > here > ? The "optics" do indeed seem non-intuitive. 8-) If some ENUM tier-1 registry would take the initiative to put a proposal on the table, and a few sister organizations gave support, we could have consensus in the ENUM-WG in time to feed into the DB-WG agenda item: Y. Input from other WGs I think we have "all the ducks lined up", as the saying goes; we just need a proposal. Best regards, Niall O'Reilly Co-Chair, RIPE ENUM Working Group

1 0

RIPE53 DB-WG Draft Agenda V3
by Wilfried Woeber, UniVie/ACOnet 18 Sep '06

18 Sep '06

Dear DB-WG folks, Chairpersons, Meeting-Role! This is the 3rd draft of an agenda for the DB-WG at RIPE52 in Amsterdam - 1st week of October 2006. Changes since V12: item Y, iinput from ENUM-WG (t.b.c.) For time slot allocations please refer to the most up-to-date meeting plan at http://www.ripe.net/ripe/meetings/ripe-53/meeting-plan.html Please note that, for our convenience, the time slot map becomes clickable for those sessions which have already submitted a (draft) agenda. Best regards, Wilfried. ________________________________________________________________________ A. Administrative Matters - scribe (Nigel T.) - list of participants - agenda - approval of minutes - review of action list - "remote participation" coordination (if needed) B. Data Base Update (N.N., RIPE NCC) [~30 min] . major developments like the IRT changes,... . DB support for glue records and ENUM delegations . ASN32, etc. C. Task-Force on Data Protection Issues (Jochen d. R. RIPE NCC) [~15 min] D. Proposal to retire CRYPT-PW (Peter K., denic.de + WW144) [~15 min] E. Review irt: e-mail/abuse-mailbox (Philippe B., CyberAbuse) [~15 min] F. Update on the Poetry Object (Nigel T.) [~10 min] . Processes for updating Poetic forms Y. Input from other WGs . ENUM-WG: on (new?) organisation type for Database Object [t.b.c.] Z. AOB

1 0

Call for agenda items, DB-WG Meeting during RIPE53, Amsterdam
by Wilfried Woeber, UniVie/ACOnet 15 Sep '06

15 Sep '06

Dear DB-WG folks, the RIPE NCC has asked us to submit the draft agendas for the WGs within the next few days. Thus, please submit (to the WG list or to me personally) your item requests or suggest topics for discussion to be included in the draft agenda. The DataBase-WG meeting is scheduled for Friday morning, October 6, 2006. The overall RIPE meeting outline is available at http://www.ripe.net/ripe/meetings/ripe-53/meeting-plan.html The list of plenary presentations scheduled may become available at http://www.ripe.net/ripe/meetings/ripe-53/presentations/ (empty right now) See you in Amsterdam, Wilfried.

4 4

RIPE53 DB-WG Draft Agenda V2
by Wilfried Woeber, UniVie/ACOnet 15 Sep '06

15 Sep '06

Dear DB-WG folks, Chairpersons, Meeting-Role! This is the 2nd draft of an agenda for the DB-WG at RIPE52 in Amsterdam - 1st week of October 2006. Changes since V1: item E, irt stuff, E in V1 becoming F For time slot allocations please refer to the most up-to-date meeting plan at http://www.ripe.net/ripe/meetings/ripe-53/meeting-plan.html Please note that, for our convenience, the time slot map becomes clickable for those sessions which have already submitted a (draft) agenda. Best regards, Wilfried. ________________________________________________________________________ A. Administrative Matters - scribe (Nigel T.) - list of participants - agenda - approval of minutes - review of action list - "remote participation" coordination (if needed) B. Data Base Update (N.N., RIPE NCC) [~30 min] . major developments like the IRT changes,... . DB support for glue records and ENUM delegations . ASN32, etc. C. Task-Force on Data Protection Issues (Jochen d. R. RIPE NCC) [~15 min] D. Proposal to retire CRYPT-PW (Peter K., denic.de + WW144) [~15 min] E. Review irt: e-mail/abuse-mailbox (Philippe B., CyberAbuse) [~15 min] F. Update on the Poetry Object (Nigel T.) [~10 min] . Processes for updating Poetic forms Y. Input from other WGs Z. AOB

1 0

Suggestions to improve the IRT object
by Philippe Bourcier 15 Sep '06

15 Sep '06

Hi, The -c flag which is going to be implemented soon for any standard IP query to the RIPE whois is a good thing. But since most IRT objects returned don't have an abuse-mailbox field, the result is pretty useless (no e-mail will be returned). Developers will keep using -B in their tools so that they can send their abuse reports somewhere... Facts ===== The e-mail field of an IRT object is hidden until you use the -B flag. Most IRT objects have been created without an abuse-mailbox field. For the IRT object, the e-mail field is mandatory, but the abuse-mailbox is optional. The e-mail field of an IRT object is by definition an abuse-mailbox. Proposal ======== One of the easiest way to make the -c flag really useful without -B is to have all IRT objects return an abuse-mailbox. Thus, the abuse-mailbox field should be mandatory and for all IRT objects which don't have one, the e-mail field should be copied to it. (To be logical, the e-mail attribute should be set to optional.) More Thoughts ============= Another issue is to deploy the IRT object (or even the abuse-mailbox...) on a huge number of inetnum's. If we wait for people to modify all their inetnum objects so that they have an abuse-mailbox or irt-mnt attribute, it will take ages. A standard IP query to the RIPE whois now gives one "origin" attribute (or more). Maybe the mnt-irt of that aut-num could be displayed in the default output... A company not owning the AS announcing their prefix, and willing to use its own IRT object (or abuse-mailbox) could use the mnt-irt in their inetnum('s) to specify a "more specific" one. RFD === What do people think about these 2 ideas ? Sincerely, Philippe Bourcier

2 1

RIPE53 DB-WG Draft Agenda V1
by Wilfried Woeber, UniVie/ACOnet 14 Sep '06

14 Sep '06

Dear DB-WG folks, Chairpersons, Meeting-Role! This is the 1st draft of an agenda for the DB-WG at RIPE52 in Amsterdam - 1st week of October 2006. Changes since V.: ---. For time slot allocations please refer to the most up-to-date meeting plan at http://www.ripe.net/ripe/meetings/ripe-53/meeting-plan.html Please note that, for our convenience, the time slot map becomes clickable for those sessions which have already submitted a (draft) agenda. Best regards, Wilfried. ________________________________________________________________________ A. Administrative Matters - scribe (Nigel T.) - list of participants - agenda - approval of minutes - review of action list - "remote participation" coordination (if needed) B. Data Base Update (N.N., RIPE NCC) [~30 min] . major developments like the IRT changes,... . DB support for glue records and ENUM delegations . ASN32, etc. C. Task-Force on Data Protection Issues (Jochen d. R. RIPE NCC) [~15 min] D. Proposal to retire CRYPT-PW (Peter K., denic.de + WW144) [~15 min] E. Update on the Poetry Object (Nigel T.) [~10 min] . Processes for updating Poetic forms Y. Input from other WGs Z. AOB

1 0

Announcement Routing Registry Training Courses
by RIPE NCC Training Services 29 Aug '06

29 Aug '06

Dear Colleagues The RIPE NCC Training Services Department invites you to register for one of our upcoming Routing Registry Training Courses: Date: Friday 1 September 2006 Time: 0900 - 1700 Location: Reykjavik, Iceland AND Date: Thursday 26 October 2006 Time: 0900 - 1700 Location: London, United Kingdom AND Date: Friday 4 November 2006 Time: 0900 - 1700 Location: Amsterdam, Netherlands AND Date: Monday 27 November 2006 Time: 0900 - 1700 Location: Rome, Italy Hosted by: CASPUR http://www.caspur.it/ Hosted by: NAMEX http://www.namex.it/ 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

re: Proposal for returning IRT objects
by Denis Walker 17 Aug '06

17 Aug '06

[Apologies for duplicate mails] Dear Colleagues, The RIPE NCC has re-implemented the way IRT objects are returned in RIPE Database query results. The proposal can be found at: http://www.ripe.net/ripe/maillists/archives/db-wg/2006/msg00087.html The first stage of this implementation as described in the proposal is now complete. The main objectives were to: - Increase the availability of the IRT information to users - Promote the use of the IRT object - Make it easier for third party tool writers to find the correct contacts New Behaviour ------------------------ The behaviour of the "-c" flag and the "-rc" flag is as follows: A standard query for address space including the "-c" query flag returns the queried INETNUM and related objects. This also includes an IRT object referenced by the queried INETNUM object or the closest, less specific INETNUM object, if one exists. It will also still include any ROUTE objects. By using the "-rc" flags, the related personal objects are filtered out. The IRT object will still be returned together with any ROUTE objects. An additional consequence of this change is the way the "-b" flag works. The "-b" flag will always return the primary key of any address space object queried. It also returns the "abuse-mailbox:" attributes from the address space object and any related IRT objects. The RIPE Database Query webpage has also been updated: http://www.ripe.net/fcgi-bin/whois For all address space queries made via this webpage, the "-c" flag will be added, making it the default. This only occurs if no other address space query flags (lLmMxbc) are present. A link has also been added to enable users to switch between the test and production databases. This makes it easier to query the RIPE Test Database. Regards Denis Walker Software Engineering Department RIPE NCC

1 0

The RIPE Database and DNS management system has been updated
by Katie Petrusha 03 Aug '06

03 Aug '06

Dear Colleagues, We have updated the RIPE Database and DNS management system to implement several new features. The change in the RIPE Database: - There is a new syntax for the "nserver:" attribute in the DOMAIN object to support IPv4 and IPv6 glue name servers. The changes in the DNS management system: - The management of DNS delegation in the e164.arpa (ENUM) zone has been brought under the same provisioning system as reverse DNS management. - The Delegation Checker has been updated to support glue name servers for IPv4 and IPv6 - The Web Zone Delegation Checker has also been updated You can find more details about the proposal for implementation at: http://www.ripe.net/ripe/maillists/archives/dns-wg/2006/msg00128.html -- Katie Petrusha RIPE NCC

1 0

RIPE Database maintenance
by Denis Walker 03 Aug '06

03 Aug '06

Dear Colleagues, We will carry out maintenance work on the RIPE Database update server, cello.ripe.net, on Friday, 4 August 2006 between 09:00-10:00 (UTC). During this period, you may experience outages when trying to use the following services: - RIPE Database updates (including the web interface and synchronous interface) - Queries to our mirrored databases (using -a query flag) Any updates sent to the mail interface will be queued and processed later. We apologise for any inconvenience. If you have any questions, please contact: ripe-dbm(a)ripe.net. Regards, Denis Walker Software Engineering Department RIPE NCC

1 0

Re: [db-wg] crypted password
by Max Tulyev 25 Jul '06

25 Jul '06

Markus Werner wrote: > Migration steps. > > - Move all auth: MD5-PW to a new md5-pw object and reference them. > > - At some day it is possible to say that md5-pw are obsolet and deny > creation of new objects. So new users get forced to use a other method. > > - After time you can force users to update the auth method everytime > they need to edit an object. Nice. But seems too soft, and it takes a long time to migrate... My view: - Implement md5-pw object in database - Autocreate md5-pw objects for all existing md5 passwords - Autochange hashed passwords with md5-pw objects - Include "remark: see http://... for what's happened" in chaned objects Like it was in person/org objects when russian area phone codes was changed. -- WBR, Maxim V. Tulyev (MT6561-RIPE, 2:463/253@FIDO)

3 2

crypted password
by Max Tulyev 25 Jul '06

25 Jul '06

Hi! Why not to hide crypted password in mntner objects from public queries? It is so easy to crack now. -- WBR, Maxim V. Tulyev (MT6561-RIPE, 2:463/253@FIDO)

6 10

Proposal to change the syntax of "nserver:" attribute
by Katie Petrusha 11 Jul '06

11 Jul '06

[Apologies for duplicate mails] Motivation: We plan to automate management of DNS delegation in the e164.arpa zone (ENUM). The provisioning system, with the RIPE Database as a front end, must support IPv6 glue records. It must also implement complete and consistent IPv4 glue record support. This will mean making changes to the RIPE Database syntax so that it specifies the glue record and update the delegation checks. This proposal covers that syntax. Proposal: We suggest changing the syntax of the "nserver:" attribute in DOMAIN objects as follows: nserver: [domain_name] /or/ nserver: [domain_name] [ipv4_address] /or/ nserver: [domain_name] [ipv6_address] where [domain_name] is the fully qualified DNS name of the name server without a trailing "." [ipv4_address] is an IPv4 address of the name server [ipv6_address] is an IPv6 address of the name server If [domain_name] is followed by an IP address, it must be inside the zone that is being delegated. Any level of a glue name is supported within the valid domain name syntax. Multiple name server lines will need to be used to specify multiple IP addresses for the same hostname. Examples: The following values would be allowed: domain: example.com nserver: ns1.test.net 168.0.0.1 nserver: ns1.test.net 0::0 nserver: ns1.example.com nserver: ns1.d1.example.com All other variants of the values will be rejected. End-of-line comments starting with '#' will be still allowed. Consequences for existing objects: We will not automatically modify any existing objects. Instead we suggest notifying the maintainers of objects that do not comply with the proposed syntax. This will cover around 150 objects. Consequences for the delegation checks: DNS checks applicable to glue records will be added to the Zone Delegation Checker (http://www.ripe.net/rs/reverse/delcheck/delcheck_descr.html) -- Katie Petrusha RIPE NCC

10 16

Re: Need help with ripe-dbase-2.3
by Denis Walker 10 Jul '06

10 Jul '06

Dear Alex Unfortunately version 2 of the RIPE Database code was taken out of production more than 5 years ago. We have archives of the code but no one at the RIPE NCC works on it now. I am sorry but we are unable to assist you with this problem. I have copied this email to the Database Working Group in case some one in the community can assist you. Maybe there are others still running this version of the code. Regards Denis Walker Software Engineering Department RIPE NCC Alex Moura wrote: > Hello, > > We have been using the ripe-dbase-2.3 sucessfully on a server with > perl-5.00503, but now we are having problems to make it run on a new > server with perl-5.8.8. > The server runs, but dies after sucessfully replying a query, > recording only this error message: > > File: (...)/db-root/log/err/errlog > Fatal error: accept failed: No child processes PID: 98560 > > I'd like to know if this code would work with perl-5.8. I will try to > run it with perl-5.6.2, as it seem to be the oldest version od perl > available at the FreeBSD ports. > > We know this code is old, but I'm hopeful to have some answer about > this issue, once we have made some customizations to fufill our > organization needs, and we'd like to avoid - at least for now - having > to port these customizations to the most recent ripe-dbase code. > > Thank you in advance, > > Alex

1 0

2006-03 Policy Proposal Withdrawn (LIR-PARTITIONED status for IPv6)
by Filiz Yilmaz 06 Jul '06

06 Jul '06

PDP Number: 2006-03 LIR-PARTITIONED status for IPv6 Dear Colleagues The proposal 2006-03, LIR-PARTITIONED status for IPv6 has been withdrawn. The proposer decided that the proposal was no longer necessary. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/archive/ Regards Filiz Yilmaz RIPE NCC Policy Development Officer

1 0

Yet another ipv6 bug ;)
by Max Tulyev 03 Jul '06

03 Jul '06

Hi! If I go to www.ripe.net right now and ask for ORG-RL14-RIPE in whois from IP 2a01:d8:0:99:211:11ff:fe1f:bfc9 - I get %ERROR:208: connection refused From IP 195.209.61.241 everything seems to be fine. What is it? -- WBR, Maxim V. Tulyev (MT6561-RIPE, 2:463/253@FIDO)

2 1

Network Upgrade
by Brian Riddle 27 Jun '06

27 Jun '06

[Apologies for duplicate e-mails] Dear Colleagues, I am pleased to announce that the network is now stable following the recent problems we experienced during last week's network upgrade. We have identified two key issues responsible for the instability. 1. Our current firewalls have been chosen to generously accommodate all previously experienced traffic levels. This is an IPv6 related issue which does not affect the stability of the network. 2. We have agreed with Juniper that this high CPU utilisation is an abnormal state which must be addressed. We have open tickets with our suppliers concerning these issues. The network upgrade has been a long-term project with many carefully planned and implemented steps. It is great to see the end of the tunnel appearing and we thank you for your patience and support in this matter. Regards, Brian Riddle IT Manager RIPE NCC

1 0