From thomas.lauener at glattnet.ch Fri Feb 6 17:10:41 2004 From: thomas.lauener at glattnet.ch (Thomas Lauener) Date: Fri, 06 Feb 2004 17:10:41 +0100 Subject: [ncc-services-wg] Local version of Assigment Request Form for LIR Message-ID: <000501c3eccb$c45fba30$3302a8c0@glattwerk.local> Dear all I set up a website with the European Request Form for our customer to make a request for IP-Addresses below our AW (/26). As i saw the forms changed in August last year! RIPE have plans to make a "public" version of either robot or web forms or both, but it is not a high priority task. The functionality cold be exacly the same as at the LIR portal. The finaly Submit Button sends data to a spezified email address. It would be helpfully if one could select a language at the beginnig. All the Texts including the Help could be translated in separate Templates. A attached Diagram may be attached to the mail. The hold thing should running independently on the LIR's Webserver. It could be running as PHP or Perlscript. If there is a need for such service, RIPE will make it more prioritive. The public discussion will also help to determine what is needed first and how exactly should it work. Best Regards Thomas Lauener -------------- next part -------------- An HTML attachment was scrubbed... URL: From BSanghani at flagtelecom.com Wed Feb 11 13:16:54 2004 From: BSanghani at flagtelecom.com (Sanghani, Bijal) Date: Wed, 11 Feb 2004 12:16:54 -0000 Subject: [ncc-services-wg] Minutes from RIPE NCC Services WG - RIPE 47 Message-ID: <4106B6924F60D311B8530008C709FEC402994F6E@lhr-email.flagtelecom.com> Hi All, Attached are the draft minutes for the RIPE NCC Services WG session for RIPE 47 last month, please send details of any errors, corrections or clarifications to Kurtis, myself or to this list. The theme for our session at RIPE 48 will be the RIPE NCC Activity Plan, Axel Pawlik has agreed to give us an update on the progress made on the 2004 plan and input into the 2005 Activity Plan is also welcome. If anyone would like to make a presentation or raise a topic for discussion please let Kurtis and myself know and we'll arrange a spot in the agenda. Best regards, Bijal Sanghani FLAG Telecom <> ********************************************************************** This e-mail message is confidential and is intended only for the use of the individual or entity named above and contains information which is or may be confidential, non-public or legally privileged. Any dissemination or distribution of this message other than to its intended recipient is strictly prohibited. If you have received this message in error, please notify us by email to postmaster at flagtelecom.com immediately and delete the original message and all copies from all locations in your computer systems. This e-mail has been swept by Mailsweeper TM for viruses. However, FLAG Telecom cannot accept liability for any damage which you may sustain as a result of software viruses. ********************************************************************** This message has been scanned for viruses by MailControl - www.mailcontrol.com -------------- next part -------------- A non-text attachment was scrubbed... Name: RIPE NCC Service WG minutes RIPE 47.doc Type: application/msword Size: 47104 bytes Desc: not available URL: From denesh at cyberstrider.net Wed Feb 11 16:04:01 2004 From: denesh at cyberstrider.net (Denesh Bhabuta) Date: Wed, 11 Feb 2004 15:04:01 +0000 Subject: [ncc-services-wg] Minutes from RIPE NCC Services WG - RIPE 47 In-Reply-To: <4106B6924F60D311B8530008C709FEC402994F6E@lhr-email.flagtelecom.com> References: <4106B6924F60D311B8530008C709FEC402994F6E@lhr-email.flagtelecom. com> Message-ID: <756910000.1076511841@dhcppc2> Hi Bijal Would it be possible to have the minutes in plain text rather than in MS Word? pretty please... :-) Regards Denesh --On Wednesday, February 11, 2004 12:16:54 +0000 "Sanghani, Bijal" wrote: > Hi All, > > Attached are the draft minutes for the RIPE NCC Services WG session for > RIPE 47 last month, please send details of any errors, corrections or > clarifications to Kurtis, myself or to this list. > > The theme for our session at RIPE 48 will be the RIPE NCC Activity Plan, > Axel Pawlik has agreed to give us an update on the progress made on the > 2004 plan and input into the 2005 Activity Plan is also welcome. > > If anyone would like to make a presentation or raise a topic for > discussion please let Kurtis and myself know and we'll arrange a spot in > the agenda. > > Best regards, > Bijal Sanghani > FLAG Telecom > > <> > > > ********************************************************************** > This e-mail message is confidential and is intended only for the use of > the individual or entity named above and contains information which is or > may be confidential, non-public or legally privileged. Any dissemination > or distribution of this message other than to its intended recipient is > strictly prohibited. If you have received this message in error, please > notify us by email to postmaster at flagtelecom.com immediately and delete > the original message and all copies from all locations in your computer > systems. > > > This e-mail has been swept by Mailsweeper TM for viruses. However, FLAG > Telecom cannot accept liability for any damage which you may sustain as a > result of software viruses. > ********************************************************************** > > > > > > This message has been scanned for viruses by MailControl - > www.mailcontrol.com From BSanghani at flagtelecom.com Wed Feb 11 16:22:49 2004 From: BSanghani at flagtelecom.com (Sanghani, Bijal) Date: Wed, 11 Feb 2004 15:22:49 -0000 Subject: [ncc-services-wg] Minutes from RIPE NCC Services WG - RIPE 47 Message-ID: <4106B6924F60D311B8530008C709FEC402994F74@lhr-email.flagtelecom.com> Sure, please see attached :o) -----Original Message----- From: Denesh Bhabuta [mailto:denesh at cyberstrider.net] Sent: Wednesday, February 11, 2004 3:04 PM To: Sanghani, Bijal; 'ncc-services-wg at ripe.net' Subject: Re: [ncc-services-wg] Minutes from RIPE NCC Services WG - RIPE 47 Hi Bijal Would it be possible to have the minutes in plain text rather than in MS Word? pretty please... :-) Regards Denesh --On Wednesday, February 11, 2004 12:16:54 +0000 "Sanghani, Bijal" wrote: > Hi All, > > Attached are the draft minutes for the RIPE NCC Services WG session for > RIPE 47 last month, please send details of any errors, corrections or > clarifications to Kurtis, myself or to this list. > > The theme for our session at RIPE 48 will be the RIPE NCC Activity Plan, > Axel Pawlik has agreed to give us an update on the progress made on the > 2004 plan and input into the 2005 Activity Plan is also welcome. > > If anyone would like to make a presentation or raise a topic for > discussion please let Kurtis and myself know and we'll arrange a spot in > the agenda. > > Best regards, > Bijal Sanghani > FLAG Telecom > > <> > > > ********************************************************************** > This e-mail message is confidential and is intended only for the use of > the individual or entity named above and contains information which is or > may be confidential, non-public or legally privileged. Any dissemination > or distribution of this message other than to its intended recipient is > strictly prohibited. If you have received this message in error, please > notify us by email to postmaster at flagtelecom.com immediately and delete > the original message and all copies from all locations in your computer > systems. > > > This e-mail has been swept by Mailsweeper TM for viruses. However, FLAG > Telecom cannot accept liability for any damage which you may sustain as a > result of software viruses. > ********************************************************************** > > > > > > This message has been scanned for viruses by MailControl - > www.mailcontrol.com This message has been scanned for viruses by MailControl - www.mailcontrol.com -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: RIPE NCC Service WG minutes RIPE 47.txt URL: From ncc at ripe.net Tue Feb 17 15:46:40 2004 From: ncc at ripe.net (Axel Pawlik) Date: Tue, 17 Feb 2004 15:46:40 +0100 Subject: [ncc-services-wg] Membership Growth Survey 2004 Message-ID: <5.2.1.1.2.20040217153607.00af2f20@mailhost.ripe.net> Dear Colleagues, For member activities and budgeting purposes, the RIPE NCC relies on annual membership growth estimates. This is particularly important when setting membership fees. The RIPE NCC is dedicated to making sure we answer to the expectations and needs of our membership. With this in mind, we are currently looking at predictions for growth over the coming two years. Starting Tuesday 18 February, we will carry out a survey to estimate how many members we will have in your country over the next two years. We already look at past trends and our industry knowledge, but these figures can be significantly improved by using your knowledge of the market and local conditions. You know the local IT business and conditions far better than we do. The survey, which you can access through the LIR Portal, will be short and simple to complete and should take no more than a few minutes of your time. It will be available for six weeks. We are not asking you for exact predictions, but we would like you to give us your best estimate. Individual estimates provided will be held in strict confidence by the RIPE NCC and used only in connection with this survey. After the survey has ended, we will provide a report on how your estimates compare with the average in your country. To encourage members to give their input, the RIPE NCC will send each survey participant a small gift. To make sure that you receive this gift and it is not sent to the wrong address, we will ask you to ensure that the contact details we currently hold for you are correct. To take part, you will need to log into the LIR Portal. Once there you will find a link to the survey from Tuesday 18 February 2004 for six weeks: https://lirportal.ripe.net Regards Axel Pawlik Managing Director RIPE NCC From engin at ripe.net Wed Feb 18 18:03:41 2004 From: engin at ripe.net (Engin Gunduz) Date: Wed, 18 Feb 2004 18:03:41 +0100 Subject: [ncc-services-wg] Organisation object timeline Message-ID: <20040218170341.GA21011@x47.ripe.net> Dear Colleagues, [apologies for duplicate mails] Please find below the timeline for deployment of organisation object in the RIPE Whois Database. You can find the latest organisation object proposal at http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00689.html For questions and comments please contact me at . Best regards, -- Engin Gunduz RIPE NCC Software Engineering Department ================================ Timeline for Organisation Object ================================ 11 March 2004 Thursday : Pre-release of whois software with organisation object capability. (for tests by external parties, LIRs) 17 April 2004 Saturday : Deployment of whois software with organisation object capability. Creation of organisation objects for existing LIRs, update of existing allocation inetnums and inet6nums. 19 April 2004 Monday : The RIPE NCC starts using the new request forms updated for organisation object. From ncc at ripe.net Mon Feb 23 11:55:30 2004 From: ncc at ripe.net (Nick Hyrka) Date: Mon, 23 Feb 2004 11:55:30 +0100 Subject: [ncc-services-wg] RIPE 47 Meeting Report Message-ID: <5.2.1.1.2.20040223114431.03dd5eb0@mailhost.ripe.net> (Apologies for any duplicate mails.) RIPE 47 Meeting Report Dear Colleagues, The RIPE 47 Meeting was held from 26 - 30 January 2004 at the Grand Hotel Krasnapolsky, Amsterdam, the Netherlands. There were a total of 253 attendees comprised of the RIPE NCC membership, the RIPE community and government representatives. Attendees also included representatives from APNIC, ARIN, AfriNIC, LACNIC, ICANN and IANA. HIGHLIGHTS ========== - Highlights of RIPE 47 included the open discussion on the services of the RIPE NCC during the RIPE NCC Services Working Group; updates on the World Summit on the Information Society from Mirjam Khne, ISOC, and Axel Pawlik, Managing Director, RIPE NCC; an AfriNIC update; the proposal by the RIPE community to make RIPE 152 ( 'Charging by Local Internet Registries') a historical document. - As announced by Rob Blokzijl, RIPE Chair, two RIPE Meetings will be held in 2005. Based on the feedback from the community, this schedule will continue in 2006. The RIPE NCC will offer additional support to RIPE Working Groups to facilitate discussion and progress between RIPE Meetings. - Robin Tasker (CCLRC) gave a presentation on the European Commission-sponsored DataTAG project. - The European Operators Forum (EOF) featured an NSP Security BoF, a presentation on which types of SMTP flows should be blocked to prevent spam, a case study on the migration of AOL's backbone network from OSPF to IS-IS and discussion on the use of XML in network configuration. EOF presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-47/presentations/index.html#eof - The RIPE NCC, Afilias, Cisco, NIKHEF, NOKIA, Riverhead and SURFnet are thanked for the support they provided to the meeting. Global Voice Networks are thanked for the provision of excellent Internet connectivity. SUMMARY ======== ADDRESS POLICY - It was proposed that RIPE 152 ('Charging by Local Internet Registries') should be made a historical document and that the RIPE NCC should make a clear statement on www.ripe.net that it does not charge for IP addresses. - Hans Petter Holen, Chair, will form a task force to write a policy development process proposal. - Consensus is needed on the mailing list on the AfriNIC proposal regarding /22 minimum allocation size. - Hans Petter Holen, Chair, will start a discussion on the mailing list on changing the 80% rule for IPv4 allocations. Address Policy Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-47/presentations/#ap DATABASE - The issue of CRISP versus joint Whois was discussed. - The proposal to introduce new attribute "abuse-c" in the inet(6)num objects was discussed. - A detailed proposal about "abuse-c" will be sent to Database Working Group mailing list. Database Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-47/presentations/#db TEST TRAFFIC MEASUREMENT (TTM) - It was noted that as of 1/1/2004 changes were made to the TTM service contract: Fees were lowered (from 3000 EUR per year to 1000 EUR per year) and all data has been made public as specified in RIPE 300 ('Test Traffic Measurement Service Data Disclosure Policy'). - Two presentations made use of TTM delay data: a presentation on delay tomography used traceroute data from the TTM project; a presentation on the reordering of IP packets used delay data. TTM Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-47/presentations/#tt ANTI-SPAM - A proposal has been sent to the Database Working Group mailing list regarding the inclusion of an abuse-c attribute/object in the RIPE Database to help solve the problem of misdirected/multiple spam complaints. - It was noted that the European Commission Directive is now widely implemented and that in the United States CAN-SPAM is the first federal legislation. IPv6 - The anycast policy discussion was sent to the Address Policy Working Group. - There was discussion on how 6 to 4 is being used to spoof IPv4 origin addresses to make Distributed Denial of Service (DDoS) attacks anonymous. - There was a presentation on the security implications of IPv6 on IPv4 networks. IPv6 Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-47/presentations/#ipv6 EIX - An editorial group will be set up to revise the exchange point operator wish list for switches. - Operator-member charters for exchange points were discussed. - DE-CIX presented their experience migrating to new hardware and adding new premises. EIX Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-47/presentations/#eix DN* - The DNR Forum and the DNS Working Group were combined under the DNS Working Group heading. - It was noted that the ENUM RFC 2916bis has been approved by the IETF Working Group and is in the queue of the RFC editor. - It was noted that Internationalized Domain Names (IDN) are being deployed in more new regions. DN* Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-47/presentations/#dn ROUTING - There was a presentation on RISwhois, a tool that allows IP address to origin ASN mapping. - Case studies about convergence of IGP protocols were presented and discussed. Routing Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-47/presentations/#routing RIPE NCC SERVICES - Bijal Sanghani, FLAG Telecom, was appointed as the co-chair of the Working Group. - The RIPE NCC will explore the possibility of providing a service giving test statistics on the routability of new blocks. - The RIPE NCC will give a status update on the Activity Plan 2004 and request input for the Activity Plan 2005 during the RIPE NCC Services Working Group at RIPE 48. RIPE NCC Services Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-47/presentations/#ncc-services TUTORIALS ========= The RIPE NCC staff presented the RIPE NCC IP Request Tutorial. It explained address space assignment and allocation procedures in the RIPE NCC region: http://www.ripe.net/ripe/meetings/ripe-47/tutorials/ip-request/ RIPE 47 WEBCASTING AND ARCHIVES ============================== During RIPE 47, the RIPE NCC held trials in collecting feedback from participants watching the webcast. The mediums used for this were IRC and Jabber. Archives of presentations, webcasts and IRC/Jabber feedback from RIPE 47 are available at: http://www.ripe.net/ripe/meetings/ripe-47/sessions-archive.html HOSTMASTER CONSULTATION CENTRE (HCC) ==================================== The RIPE NCC Hostmaster Consultation Centre was open at RIPE 47, allowing RIPE NCC Members to discuss issues relating to their business directly with RIPE NCC Hostmasters. RIPE 47 REFERENCE PAGE ====================== A complete list of RIPE 47 sessions, tutorials and presentations can be found at: http://www.ripe.net/ripe/meetings/ripe-47/index.html "MEET & GREET" ============= The RIPE NCC's "Meet & Greet" was available for first-time RIPE Meeting attendees at RIPE 47. "Meet & Greet" introduces newcomers to the meetings, to key attendees from the RIPE community and to social events throughout the week. More information can be obtained by contacting: . RIPE 48 ====== RIPE 48 will be held in Amsterdam, the Netherlands, from 3 - 7 May 2004. Information on RIPE 48 will soon be made available at: http://www.ripe.net/ripe/meetings/ripe-48/ New Local Internet Registries (LIRs) ========================== Please note: New LIRs are entitled to two (2) free tickets to attend a RIPE Meeting. The tickets cover the meeting fee only and do not apply to the RIPE dinner, travel or hotel accommodation. More information on the new LIR tickets can be found at: http://www.ripe.net/ripe/meetings/new-lir.html For more information, contact . -- end -- From lists at complx.LF.net Mon Feb 23 20:58:42 2004 From: lists at complx.LF.net (Kurt Jaeger) Date: Mon, 23 Feb 2004 20:58:42 +0100 Subject: [ncc-services-wg] Improved Secure Communication for Registration Services (RS) Mailboxes In-Reply-To: <400FEC71.2020101@ripe.net> References: <400FEC71.2020101@ripe.net> Message-ID: <20040223195842.GG7109@complx.LF.net> Hi! > The attached document presents our ideas regarding this, and also raises > some questions for the membership. Please have a look, and comment. > There will also be a presentation and discussion at the NCC Services > Working Group next week at RIPE 47, for those interested in voicing their > opinions in person. [...] > http://www.ripe.net/ripe/draft-documents/archive/pki-20030429.html I object on making x.509 the sole method of authenticated communication with RIPE. There's GPG, and it works, now. X.509 is not the way to go. It's just a (needless) duplication of effort. And wading forever in the mess of "do we use this protocol/format or that" and so on. -- MfG/Best regards, Kurt Jaeger 16 years to go ! LF.net GmbH fon +49 711 90074-23 pi at LF.net Ruppmannstr. 27 fax +49 711 90074-33 D-70565 Stuttgart mob +49 171 3101372 From Michael.Dillon at radianz.com Tue Feb 24 11:08:30 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Tue, 24 Feb 2004 10:08:30 +0000 Subject: [ncc-services-wg] Improved Secure Communication for Registration Services (RS) Mailboxes Message-ID: >I object on making x.509 the sole method of authenticated >communication with RIPE. >There's GPG, and it works, now. I think this is an exageration. The only form of authenticated communication which works now over the Internet is SSL combined with HTTP. The choice of which secure technology is irrelevant. The security features of the technology are irrelevant. The only thing that matters is how easy will it be to use the new technology and how will RIPE teach people to use the technology and what tools will RIPE make available to people to run on their Windows machines, Macintosh machines and UNIX workstations so that they can use this new technology as easily as they use the web or email today. GPG isn't necessarily any easier to learn and use than X.509 is. Remember, the audience for this is the LIR staff who administer IP address allocations. They are not necessarily engineers or technical people. They probably don't use UNIX workstations and they probably don't know how to write scripts or use a command line. --Michael Dillon From prt at prtsystems.ltd.uk Mon Feb 23 18:35:30 2004 From: prt at prtsystems.ltd.uk (Paul Thornton) Date: Mon, 23 Feb 2004 17:35:30 +0000 Subject: [ncc-services-wg] Re: [local-ir@ripe.net]RIPE 47 Meeting Report In-Reply-To: <5.2.1.1.2.20040223114431.03dd5eb0@mailhost.ripe.net> References: <5.2.1.1.2.20040223114431.03dd5eb0@mailhost.ripe.net> Message-ID: <165372923.1077557730@EMMA.prt.org> Folks, (distribution list trimmed - but not certain if this is a local-ir or ncc-services issue) --On 23 February 2004 11:55 +0100 Nick Hyrka wrote: > ... > HIGHLIGHTS > ========== > ... > - As announced by Rob Blokzijl, RIPE Chair, two RIPE Meetings will be > held in 2005. Based on the feedback from the community, this schedule > will continue in 2006. The RIPE NCC will offer additional support to RIPE > Working Groups to facilitate discussion and progress between RIPE > Meetings. I remember being at the RIPE47 meeting where this was announced as a fait accompli. What I don't remember was the RIPE47 meeting where there was any real debate or discussion about it. If we leave aside the number of meetings per year for a moment, what I find most concerning about this is that a reasonably substantive change to the way that we operate as a policy-making community has been slipped in without any chance to express reservations or concerns, or hear reasoning one way or another. This is a dangerous path to tread as I am sure all will agree. On the subject of meetings, it is accepted that mailing list discussions are moved forwards rapidly at the meetings, as we have a chance to discuss things face to face in working groups which in general leads to more rapid conclusion of policy decisions. If we have a new operating method where there are two 'major' RIPE meetings a year, and some 'lesser' committee meetings for the working groups, do we end up with people who have an interest now having to travel to all of the meetings rather than just the current RIPE meetings to ensure that something they care about is not being discussed without them present? I'm not certain that having interim meetings works well anyway - from past experience I have seen much momentum at industry meetings where different groups then go off with the best intentions of having several sub-committee meetings before the next major meeting. For a variety of reasons, this does not then happen - and my experience was with the meetings held in London - for people working in and around London. In the RIPE case, there would be the added necessity to potentially travel around Europe or from further away to participate. The current meetings are worthwhile for those flying in from the USA or far east as there is much taking place - would the attraction still be there for any interim cut-down meeting? So in short, I'm not at all convinced that two meetings a year is a Good Thing, nor am I particularly happy about the way it has been introduced. Regards, Paul. -- Paul Thornton, PRT Systems Ltd Tel: +44 1825 740756 Fax: +44 1825 740136 GSM: +44 7885 373379 From neil at COLT.NET Tue Feb 24 12:52:41 2004 From: neil at COLT.NET (Neil J. McRae) Date: Tue, 24 Feb 2004 11:52:41 -0000 Subject: [ncc-services-wg] Re: [local-ir@ripe.net]RIPE 47 Meeting Report In-Reply-To: <165372923.1077557730@EMMA.prt.org> Message-ID: <084301c3facc$b570b240$0100a8c0@doom> Paul, > I remember being at the RIPE47 meeting where this was > announced as a fait > accompli. What I don't remember was the RIPE47 meeting where > there was any > real debate or discussion about it. Hence why we have this issue! > On the subject of meetings, it is accepted that mailing list > discussions > are moved forwards rapidly at the meetings, as we have a > chance to discuss > things face to face in working groups which in general leads > to more rapid > conclusion of policy decisions. > If we have a new operating method where there are two 'major' > RIPE meetings > a year, and some 'lesser' committee meetings for the working > groups, do we > end up with people who have an interest now having to travel > to all of the > meetings rather than just the current RIPE meetings to ensure that > something they care about is not being discussed without them present? I don't think this is always the case. Travel isn't always required for meetings, conference calls could be used to deal with many of the issues that are resolved face to face. > > So in short, I'm not at all convinced that two meetings a > year is a Good > Thing, nor am I particularly happy about the way it has been > introduced. Well to me this sounds like a fudge also. I think 1 meeting per quarter is more than adequate but the length of the current RIPE meeting is frankly insane and there is absolutely no reason for the meeting to be as long as it is. The fundemental issue still remains. There are still too many random projects with questionable value going on within the "RIPE". Regards, Neil. From webmaster at ripe.net Tue Feb 24 16:48:38 2004 From: webmaster at ripe.net (RIPE NCC WebMaster) Date: Tue, 24 Feb 2004 16:48:38 +0100 Subject: [ncc-services-wg] New Draft Document: De-boganising New Address Blocks Message-ID: <200402241548.i1OFmce2005266@birch.ripe.net> (Apologies for duplicate mails) Dear Colleagues, The RIPE NCC has prepared a draft document titled "De-Bogonising New Address Blocks": Abstract "This document describes an improvement in the notification process about new blocks of address space being distributed by the RIRs. It is a draft at this stage and your comments are solicited. However to gain experience before finalising the procedures, the RIPE NCC will shortly start announcing the routes from 84/8 described in the document under "pilot"." This document is published as a draft document in order to give RIPE NCC members time to read it and provide feedback. This draft document can be discussed on the RIPE NCC Services Working Group mailing list at . Regards, Webmaster RIPE NCC From Michael.Dillon at radianz.com Tue Feb 24 17:17:28 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Tue, 24 Feb 2004 16:17:28 +0000 Subject: [ncc-services-wg] Re: [address-policy-wg] New Draft Document: De-boganising New Address Blocks Message-ID: >The RIPE NCC has prepared a draft document titled "De-Bogonising New >Address Blocks": That is a misleading title. The problem is that ISPs cannot react quickly enough to open filters when new ranges are allocated. The proposed solution is to provide advance notification. I suppose this could allow ISPs to open filters before the new addresses are actually in use officially. However, it will also allow spammers to announce this space and get it through bogon filters. The real solution to this problem is to make it possible for ISPs to closely track RIR allocations in their filters in a semi-automated way. There may still be a few days of delay before a new allocation is fully routable but ISPs can compensate for that with internal processes. Why can't ISPs subscribe to a feed of all new RIPE allocations in near real-time? --Michael Dillon From daniel.karrenberg at ripe.net Tue Feb 24 17:29:42 2004 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 24 Feb 2004 17:29:42 +0100 Subject: [ncc-services-wg] Re: [address-policy-wg] New Draft Document: De-boganising New Address Blocks In-Reply-To: References: Message-ID: <20040224162942.GO1508@reifa-wave.karrenberg.net> On 24.02 16:17, Michael.Dillon at radianz.com wrote: > >The RIPE NCC has prepared a draft document titled "De-Bogonising New > >Address Blocks": > > That is a misleading title. I thought it was to the point and rather cute ;-). > > The problem is that ISPs cannot react quickly enough > to open filters when new ranges are allocated. The proposed > solution is to provide advance notification. I suppose this > could allow ISPs to open filters before the new addresses > are actually in use officially. This is the status quo, aka best *current* practise. > However, it will also allow spammers to announce this > space and get it through bogon filters. Correct, but only in the absence of more specific filtering. the problem this proposal aims to correct is the increasing number of false positives caused by the apparent *serious* lag in relatively static bogon filtering. > The real solution to this problem is to make it > possible for ISPs to closely track RIR allocations > in their filters in a semi-automated way. There may > still be a few days of delay before a new allocation > is fully routable but ISPs can compensate for that > with internal processes. > > Why can't ISPs subscribe to a feed of all new > RIPE allocations in near real-time? Personally I think this is a great idea and if we hear from a lot of operators actually willing to take such feeds it may become reality. However there are a number of serious issues with something like this, not the least of which are the liability issues in case this goes wrong very dynamically and semi-automatdly. It is certainly something to progress if there is enough interest. However I think the current proposal shold go ahead too because the false positives are a real problem now Daniel From oppermann at pipeline.ch Tue Feb 24 17:36:03 2004 From: oppermann at pipeline.ch (Andre Oppermann) Date: Tue, 24 Feb 2004 17:36:03 +0100 Subject: [ncc-services-wg] Re: [address-policy-wg] New Draft Document: De-boganising New AddressBlocks References: Message-ID: <403B7D73.7363498D@pipeline.ch> Michael.Dillon at radianz.com wrote: > > >The RIPE NCC has prepared a draft document titled "De-Bogonising New > >Address Blocks": > > That is a misleading title. > > The problem is that ISPs cannot react quickly enough > to open filters when new ranges are allocated. The proposed > solution is to provide advance notification. I suppose this > could allow ISPs to open filters before the new addresses > are actually in use officially. ISPs should not filter the IANA reserved IP ranges but only the Martians stuff that is defined to be unrouteable. Everything else is causing more problems than it solves. Otherwise we wouldn't have this discussion over and over again each time a RIR opens a fresh /8. > However, it will also allow spammers to announce this > space and get it through bogon filters. There is no way you can block spammers by filtering the IANA reserved ranges. There are many other ways spammers can set up bogon netblocks. For example there are many netblocks which are assigned/allocated by the RIRs but never announced in the global routing system. Just walk the prefix table of current /8s used by the RIRs and use the holes to send your spam. Again, the cure of filtering is worse than the desease of not filtering. > The real solution to this problem is to make it > possible for ISPs to closely track RIR allocations > in their filters in a semi-automated way. There may > still be a few days of delay before a new allocation > is fully routable but ISPs can compensate for that > with internal processes. There is no way every ISP is going to follow that and adjust his filters within "a few days". > Why can't ISPs subscribe to a feed of all new > RIPE allocations in near real-time? Just don't filter IANA reserved space. It's that easy. -- Andre From slz at baycix.de Tue Feb 24 17:39:53 2004 From: slz at baycix.de (Sascha Lenz) Date: Tue, 24 Feb 2004 17:39:53 +0100 Subject: [ncc-services-wg] Re: [address-policy-wg] New Draft Document: De-boganising New Address Blocks In-Reply-To: References: Message-ID: <403B7E59.2080902@baycix.de> Hay, Michael.Dillon at radianz.com wrote: >>The RIPE NCC has prepared a draft document titled "De-Bogonising New >>Address Blocks": > > > That is a misleading title. [...] > The real solution to this problem is to make it > possible for ISPs to closely track RIR allocations > in their filters in a semi-automated way. There may > still be a few days of delay before a new allocation > is fully routable but ISPs can compensate for that > with internal processes. > > Why can't ISPs subscribe to a feed of all new > RIPE allocations in near real-time? the problem never were the ISPs which do their job and follow the new RIR Allocation and Smallest Prefix Size Announcements. The problem always are those ISPs with dummy admins who just took some bogon template from some cool looking BGP configuration website and never update them at all, don't read RIR-mailinglists or things like NANOG-list and/or just don't care. (...and so on). I don't think a technical solution helps against this problem at all since only those ISPs who already care about their filters would use it, and there certainly will be some ISPs who don't want to pass the control about their filters to some 3rd party. ==> The only reasonable solution for now is just what's RIPE trying to do, look into the routability itself and kick all those who haven't updated their filters in time. That's a bit unfortunate since RIPE usually shouldn't have to do much with routing-issues in the first place, but actually i like that idea of THEM doing that. It's a benefit for all LIRs so it's a nice idea in my eyes. I'm currently quite amused watching some collegues of a customer of us trying to track down all unreachable sites and reach their admins for about two months now, especially since they already started putting end-user el-cheapo-DSL customers in their nice new 83.x.x.x IP-block which are the worst of all customer-types you can possibly get. I don't really want to experience that myself some day. Fortunately i could avoid playing early-adoption betatester for newly Allocated /8s up to now :) . o O(and then there was this big(?) european Telco/ISP still filtering AS-numbers >30000 up to some weeks ago :-) ) -- ======================================================================== = Sascha 'master' Lenz SLZ-RIPE slz at baycix.de = = NOC BayCIX GmbH = = http://www.noc.baycix.de/ * PGP public Key on demand * = ======================================================================== From kurtis at kurtis.pp.se Tue Feb 24 17:48:45 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Tue, 24 Feb 2004 17:48:45 +0100 Subject: [ncc-services-wg] Re: [local-ir@ripe.net]RIPE 47 Meeting Report In-Reply-To: <084301c3facc$b570b240$0100a8c0@doom> References: <084301c3facc$b570b240$0100a8c0@doom> Message-ID: <4FACC6FF-66E9-11D8-B86A-000A95928574@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [chair hat off] >> I remember being at the RIPE47 meeting where this was >> announced as a fait >> accompli. What I don't remember was the RIPE47 meeting where >> there was any >> real debate or discussion about it. > > Hence why we have this issue! Although I am not sure I would call it fait accompli, there wasn't much discussion around it. I can agree with that. >> On the subject of meetings, it is accepted that mailing list >> discussions >> are moved forwards rapidly at the meetings, as we have a >> chance to discuss >> things face to face in working groups which in general leads >> to more rapid >> conclusion of policy decisions. >> If we have a new operating method where there are two 'major' >> RIPE meetings >> a year, and some 'lesser' committee meetings for the working >> groups, do we >> end up with people who have an interest now having to travel >> to all of the >> meetings rather than just the current RIPE meetings to ensure that >> something they care about is not being discussed without them present? > > I don't think this is always the case. Travel isn't always required > for meetings, conference calls could be used to deal with many of > the issues that are resolved face to face. I think the face to face meetings provide a great value. And I am also not very happy with two meetings per year. I think three would be better. >> So in short, I'm not at all convinced that two meetings a >> year is a Good >> Thing, nor am I particularly happy about the way it has been >> introduced. > > Well to me this sounds like a fudge also. I think 1 > meeting per quarter is more than adequate but the length > of the current RIPE meeting is frankly insane and there > is absolutely no reason for the meeting to be as long as > it is. But these are two different issues. I kind of agree that having meetings more frequent, but shorter is a good idea - where "more frequent" might equal to three times a year. > The fundemental issue still remains. There are still > too many random projects with questionable value going > on within the "RIPE". I have no idea what this has to do with meeting frequency. There is a well defined process to handle project of the RIPE NCC. Frequency of RIPE meetings, no. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQDuAcqarNKXTPFCVEQJWUACgi51x9HN0dQS7bGQBO+EHCMapEo0AoJKl CXWO4KToOwrz3BP5jj/C1u4b =3wNR -----END PGP SIGNATURE----- From lists at complx.LF.net Wed Feb 25 08:23:09 2004 From: lists at complx.LF.net (Kurt Jaeger) Date: Wed, 25 Feb 2004 08:23:09 +0100 Subject: [ncc-services-wg] Improved Secure Communication for Registration Services (RS) Mailboxes In-Reply-To: References: Message-ID: <20040225072309.GH7109@complx.LF.net> Hi! > >I object on making x.509 the sole method of authenticated > >communication with RIPE. > > >There's GPG, and it works, now. > > I think this is an exageration. The only form of > authenticated communication which works now over the > Internet is SSL combined with HTTP. Why, then, do I read so much about failed key mgmt, bugs in openssl and the like all the time, which shows that it is an major operational PITA ? > The choice of which secure technology is irrelevant. Fine, then we can concentrate on GPG and we do not need x.509 based systems ? > The security features of the technology are irrelevant. I do not argue about whether one is more secure than the other, I argue about the operational it requires now and in the future. It looks to me like a major time-burner. Especially now that RIPE is suggesting "hey, we have GPG and X.509, choose". I thought we all learned from Tanenbaum that having multiple concurrent standards does not really solve any problems. > The only thing that matters is how easy will it > be to use the new technology and how will RIPE > teach people to use the technology and what tools > will RIPE make available to people to run on their > Windows machines, Macintosh machines and UNIX workstations > so that they can use this new technology as easily as > they use the web or email today. > > GPG isn't necessarily any easier to learn and use > than X.509 is. Maybe, thats what http://www.gnupg.org/(en)/related_software/frontends.html is for. > Remember, the audience for this is the > LIR staff who administer IP address allocations. They > are not necessarily engineers or technical people. > They probably don't use UNIX workstations and they > probably don't know how to write scripts or use a > command line. They don't need to, see above. -- MfG/Best regards, Kurt Jaeger 16 years to go ! LF.net GmbH fon +49 711 90074-23 pi at LF.net Ruppmannstr. 27 fax +49 711 90074-33 D-70565 Stuttgart mob +49 171 3101372 From jerome.fleury at fr.tiscali.com Tue Feb 24 17:56:13 2004 From: jerome.fleury at fr.tiscali.com (Jerome Fleury) Date: Tue, 24 Feb 2004 17:56:13 +0100 Subject: [ncc-services-wg] Re: [address-policy-wg] New Draft Document: De-boganising New AddressBlocks In-Reply-To: <403B7D73.7363498D@pipeline.ch> References: <403B7D73.7363498D@pipeline.ch> Message-ID: <443271380.1077645373@[10.33.50.16]> I fully agree with that. Most of all, the problem of filters is not located at ISP borders, but mostly at customers borders (e.g. small hosting companies) who do not update their filters, and who often have no idea what they are useful for. Andre is right, the best solution is definitely not to filter bogons. We have recently been allocated a /13 in 83/8, and now we have to deal with many many many customers complaining not to be able to reach many sites (expsecially in US). I'm very angry about RIPE and IANA allocating those blocks too quickly, without any vision of consequences for LIRs, and without any communications going down from Tier1 to the smallest company. --On mardi 24 f?vrier 2004 17:36 +0100 Andre Oppermann wrote: > Michael.Dillon at radianz.com wrote: >> >> > The RIPE NCC has prepared a draft document titled "De-Bogonising New >> > Address Blocks": >> >> That is a misleading title. >> >> The problem is that ISPs cannot react quickly enough >> to open filters when new ranges are allocated. The proposed >> solution is to provide advance notification. I suppose this >> could allow ISPs to open filters before the new addresses >> are actually in use officially. > > ISPs should not filter the IANA reserved IP ranges but only the > Martians stuff that is defined to be unrouteable. Everything > else is causing more problems than it solves. Otherwise we > wouldn't have this discussion over and over again each time > a RIR opens a fresh /8. > >> However, it will also allow spammers to announce this >> space and get it through bogon filters. > > There is no way you can block spammers by filtering the IANA > reserved ranges. There are many other ways spammers can set > up bogon netblocks. For example there are many netblocks which > are assigned/allocated by the RIRs but never announced in the > global routing system. Just walk the prefix table of current > /8s used by the RIRs and use the holes to send your spam. > > Again, the cure of filtering is worse than the desease of not > filtering. > >> The real solution to this problem is to make it >> possible for ISPs to closely track RIR allocations >> in their filters in a semi-automated way. There may >> still be a few days of delay before a new allocation >> is fully routable but ISPs can compensate for that >> with internal processes. > > There is no way every ISP is going to follow that and adjust > his filters within "a few days". > >> Why can't ISPs subscribe to a feed of all new >> RIPE allocations in near real-time? > > Just don't filter IANA reserved space. It's that easy. > > -- > Andre > -- Jerome Fleury Tiscali France Network Engineer Tel: +33 1 45082314 From mansaxel at sunet.se Tue Feb 24 23:19:18 2004 From: mansaxel at sunet.se (=?ISO-8859-1?Q?M=E5ns_Nilsson_KTHNOC?=) Date: Tue, 24 Feb 2004 23:19:18 +0100 Subject: [ncc-services-wg] Improved Secure Communication for Registration Services (RS) Mailboxes In-Reply-To: <20040223195842.GG7109@complx.LF.net> References: <400FEC71.2020101@ripe.net> <20040223195842.GG7109@complx.LF.net> Message-ID: <934650000.1077661158@slimsixten.pilsnet.sunet.se> --On Monday, February 23, 2004 20:58:42 +0100 Kurt Jaeger wrote: > I object on making x.509 the sole method of authenticated > communication with RIPE. > > There's GPG, and it works, now. > > X.509 is not the way to go. It's just a (needless) duplication of effort. > And wading forever in the mess of "do we use this protocol/format or that" > and so on. I would have to concur with this objection. PGP/GPG works, it is well suited to workflow, requires few special tools (bar pgp software) on the client side, and is an established method. Forcing certificate handling onto the LIR community is NOT good service, it is IMNSHO overcomplication. PKIen have their uses, but this is not one. I say NO to X.509. -- M?ns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From jwkckid1 at ix.netcom.com Wed Feb 25 02:47:59 2004 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Tue, 24 Feb 2004 17:47:59 -0800 Subject: [ncc-services-wg] Re: [address-policy-wg] New Draft Document: De-boganising New Address Blocks References: <200402241548.i1OFmce2005266@birch.ripe.net> Message-ID: <403BFECE.7948921C@ix.netcom.com> All Colleagues, I for one along with many of our members are glad to see that RIPE has decided to address this long standing and increasingly irritating issue. It is a shame that ICANN could not have addressed this some 3 years ago... Now if ARIN and other RIR's can start addressing this issue... RIPE NCC WebMaster wrote: > (Apologies for duplicate mails) > > Dear Colleagues, > > The RIPE NCC has prepared a draft document titled "De-Bogonising New > Address Blocks": > > > > Abstract > "This document describes an improvement in the notification process > about new blocks of address space being distributed by the RIRs. It is > a draft at this stage and your comments are solicited. However to gain > experience before finalising the procedures, the RIPE NCC will shortly > start announcing the routes from 84/8 described in the document under > "pilot"." > > This document is published as a draft document in order to give RIPE > NCC members time to read it and provide feedback. > > This draft document can be discussed on the RIPE NCC Services Working > Group mailing list at . > > Regards, > > Webmaster > RIPE NCC Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From jwkckid1 at ix.netcom.com Wed Feb 25 02:53:59 2004 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Tue, 24 Feb 2004 17:53:59 -0800 Subject: [ncc-services-wg] Re: [address-policy-wg] New Draft Document: De-boganising New Address Blocks References: <20040224162942.GO1508@reifa-wave.karrenberg.net> Message-ID: <403C0033.96153217@ix.netcom.com> Daniel and all, Daniel Karrenberg wrote: > On 24.02 16:17, Michael.Dillon at radianz.com wrote: > > >The RIPE NCC has prepared a draft document titled "De-Bogonising New > > >Address Blocks": > > > > That is a misleading title. > > I thought it was to the point and rather cute ;-). > - snip- > > > Why can't ISPs subscribe to a feed of all new > > RIPE allocations in near real-time? > > Personally I think this is a great idea and if we hear > from a lot of operators actually willing to take such feeds > it may become reality. However there are a number of serious issues > with something like this, not the least of which are the liability > issues in case this goes wrong very dynamically and semi-automatdly. I also agree this is a really good idea as well. But also share the concerns that many ISP's cannot or will not assume. > > > It is certainly something to progress if there is enough interest. > > However I think the current proposal shold go ahead too because the false > positives are a real problem now > > Daniel Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From neil at COLT.NET Wed Feb 25 09:40:20 2004 From: neil at COLT.NET (Neil J. McRae) Date: Wed, 25 Feb 2004 08:40:20 -0000 Subject: [ncc-services-wg] Improved Secure Communication for Registration Services (RS) Mailboxes In-Reply-To: <934650000.1077661158@slimsixten.pilsnet.sunet.se> Message-ID: <004301c3fb7b$00cbeee0$0100a8c0@doom> > --On Monday, February 23, 2004 20:58:42 +0100 Kurt Jaeger > wrote: > > > I object on making x.509 the sole method of authenticated > > communication with RIPE. > > > > There's GPG, and it works, now. > > > > X.509 is not the way to go. It's just a (needless) duplication of > > effort. And wading forever in the mess of "do we use this > > protocol/format or that" and so on. > > I would have to concur with this objection. PGP/GPG works, it > is well suited to workflow, requires few special tools (bar > pgp software) on the client side, and is an established method. > > Forcing certificate handling onto the LIR community is NOT > good service, it is IMNSHO overcomplication. PKIen have their > uses, but this is not one. > > I say NO to X.509. I completely disagree. You can say no all you like but frankly for many organisations PGP/GPG is simply not an option because there are a number of issues related to management of keys and users. I suspect an audit of many organisations using PGP/GPG would find alarming issues with the way these are deployed and used. X.509 maybe somewhat overcomplicated [and I don't agree with that fully anyway] for this specific application but if you already have a platform and many organisations do, then its a trivial expansion. Rolling out GPG/PGP across large organisations is just as much of an issue as deploying a PKI system. Whether you like or not X.509 is here and its likely to be here to stay and it works pretty well in my experience. So I welcome the RIPE NCC's direction on this. Regards, Neil. From randy at psg.com Wed Feb 25 10:01:00 2004 From: randy at psg.com (Randy Bush) Date: Wed, 25 Feb 2004 17:01:00 +0800 Subject: [ncc-services-wg] Improved Secure Communication for Registration Services (RS) Mailboxes References: <400FEC71.2020101@ripe.net> <20040223195842.GG7109@complx.LF.net> <934650000.1077661158@slimsixten.pilsnet.sunet.se> Message-ID: <20040225094019.977F84E207@postman.ripe.net> >> X.509 is not the way to go. It's just a (needless) duplication of effort. >> And wading forever in the mess of "do we use this protocol/format or that" >> and so on. > > I would have to concur with this objection. PGP/GPG works, it is well > suited to workflow, requires few special tools (bar pgp software) on the > client side, and is an established method. > > Forcing certificate handling onto the LIR community is NOT good service, it > is IMNSHO overcomplication. PKIen have their uses, but this is not one. > > I say NO to X.509. i would ammend slightly. the rirs provide us service. some of us find pgp easier to deploy and use. some will provide x.509 easier. so the rirs accepting *both* would be good. randy, a pgp kinda guy who also uses x.509 occasionally From woeber at cc.univie.ac.at Wed Feb 25 10:50:10 2004 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 25 Feb 2004 10:50:10 +0100 Subject: [ncc-services-wg] Re: [address-policy-wg] New Draft Document: De-boganising New Address Blocks Message-ID: <00A2DF15.9A69D6A6.1@cc.univie.ac.at> [ cc: list trimmed ] >However, it will also allow spammers to announce this >space and get it through bogon filters. [ ... ] >Why can't ISPs subscribe to a feed of all new >RIPE allocations in near real-time? Do you have any simple and concise definition of "ISP" for this context which would solve your "hide the info from spammers" issue? >--Michael Dillon Wilfried. _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber at 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From woeber at cc.univie.ac.at Wed Feb 25 11:06:08 2004 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 25 Feb 2004 11:06:08 +0100 Subject: [ncc-services-wg] RE: Improved Secure Communication for Registration Services (RS) Mailboxes Message-ID: <00A2DF17.D5C3DC36.29@cc.univie.ac.at> > I object on making x.509 the sole method of authenticated > communication with RIPE. I would certainly object against the PGP technology _which is in place now_ being phased out (soon). However, the NCC has reported that for _some_ applications/interfaces the integration of PGP into the server environment and with scripts is cumbersome. Although I do not have first hand experience of my own, I do not have any reason to question that. If one/some of the document(s) needs re-wording to make that clear, then we should put our effort into that. And yes, I still have to find the spare time to read the text this is referring to. [ taking off my DB-WG hat ;-] On a more private side, I still think that PKI technology is not mature enough, and stable enough, to be used in a production environment which is NOT based on a "point and click on demand" interface. OTOH, unless we start trying to do that, this will never change. Wilfried. _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber at 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ the street finds its own use for technology... From kurtis at kurtis.pp.se Wed Feb 25 11:08:06 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Wed, 25 Feb 2004 11:08:06 +0100 Subject: [ncc-services-wg] Improved Secure Communication for Registration Services (RS) Mailboxes In-Reply-To: <20040225094019.977F84E207@postman.ripe.net> References: <400FEC71.2020101@ripe.net> <20040223195842.GG7109@complx.LF.net> <934650000.1077661158@slimsixten.pilsnet.sunet.se> <20040225094019.977F84E207@postman.ripe.net> Message-ID: <81C90728-677A-11D8-970C-000A95928574@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All, On 2004-02-25, at 10.01, Randy Bush wrote: >>> X.509 is not the way to go. It's just a (needless) duplication of >>> effort. >>> And wading forever in the mess of "do we use this protocol/format or >>> that" >>> and so on. >> >> I would have to concur with this objection. PGP/GPG works, it is well >> suited to workflow, requires few special tools (bar pgp software) on >> the >> client side, and is an established method. >> >> Forcing certificate handling onto the LIR community is NOT good >> service, it >> is IMNSHO overcomplication. PKIen have their uses, but this is not >> one. >> >> I say NO to X.509. > > i would ammend slightly. the rirs provide us service. some of us > find pgp easier to deploy and use. some will provide x.509 easier. > so the rirs accepting *both* would be good. > > randy, a pgp kinda guy who also uses x.509 occasionally I am kind of puzzled here. The X.509 scheme was proposed there way before two RIPE meetings ago, when the NCC Services WG was new. I was also then voicing criticism, as was a few others. Not much discussion was raised though. Shawn then made a good presentation at the NCC Services WG meeting two RIPE meetings ago. We also had Dirk-Wilhelm van Gulik come in and explain X.509 and certificates in general. After the presentation, from what I remember most people thought this was a good idea, and a good add-on. So the NCC proceeded. So, I am bit surprised that people are start having views -now-. But I must agree with Randy, I have a hard time seeing what the problem is catering for multiple needs. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQDx0CqarNKXTPFCVEQJP9wCg/Fry0R1u6CcjJKVhBJd7hZUCb60AoMOj 2FyShsugqEROrYTrg8ZFsBSN =jzi+ -----END PGP SIGNATURE----- From neil at COLT.NET Wed Feb 25 11:13:33 2004 From: neil at COLT.NET (Neil J. McRae) Date: Wed, 25 Feb 2004 10:13:33 -0000 Subject: [ncc-services-wg] RE: Improved Secure Communication for Registration Services (RS) Mailboxes In-Reply-To: <00A2DF17.D5C3DC36.29@cc.univie.ac.at> Message-ID: <013901c3fb88$068a0b20$0100a8c0@doom> > > On a more private side, I still think that PKI technology > is not mature > enough, and stable enough, to be used in a production > environment which > is NOT based on a "point and click on demand" interface. > > OTOH, unless we start trying to do that, this will never change. Don't agree with this. A large number of big organisations use it routinely now in lots of applications. Agree on the dual options sentiment. Neil. From lists at complx.LF.net Wed Feb 25 13:34:57 2004 From: lists at complx.LF.net (Kurt Jaeger) Date: Wed, 25 Feb 2004 13:34:57 +0100 Subject: [ncc-services-wg] Improved Secure Communication for Registration Services (RS) Mailboxes In-Reply-To: <81C90728-677A-11D8-970C-000A95928574@kurtis.pp.se> References: <400FEC71.2020101@ripe.net> <20040223195842.GG7109@complx.LF.net> <934650000.1077661158@slimsixten.pilsnet.sunet.se> <20040225094019.977F84E207@postman.ripe.net> <81C90728-677A-11D8-970C-000A95928574@kurtis.pp.se> Message-ID: <20040225123457.GK7109@complx.LF.net> Hi! > >>> X.509 is not the way to go. [...] > > find pgp easier to deploy and use. some will provide x.509 easier. > > so the rirs accepting *both* would be good. > > randy, a pgp kinda guy who also uses x.509 occasionally > I am kind of puzzled here. [...] > So, I am bit surprised that people are start having views -now-. Sorry for this. It's just that there are so many discussions to have in parallel that it's difficult to follow up in time to some of them. I already raised my voice the last time x.509 came up, that's why I raised it again. We're only a small LIR, and we already see the burden of having to many "standards" to chose from. As of know, RIPE was steering the course with a clean (sub-)set, and it was OK for us. We do not have the time to attend RIPE meetings more than once every few years, if at all. -- MfG/Best regards, Kurt Jaeger 16 years to go ! LF.net GmbH fon +49 711 90074-23 pi at LF.net Ruppmannstr. 27 fax +49 711 90074-33 D-70565 Stuttgart mob +49 171 3101372 From webmaster at ripe.net Wed Feb 25 14:44:28 2004 From: webmaster at ripe.net (RIPE NCC Document Announcement Service) Date: Wed, 25 Feb 2004 14:44:28 +0100 Subject: [ncc-services-wg] New Document available: RIPE-301 Message-ID: <200402251344.i1PDiSe2023222@birch.ripe.net> New RIPE Document Announcement -------------------------------------- A new document is available from the RIPE document store. Ref: ripe-301 Title: Mergers, Acquisitions, Takeovers and Closures of Organisations Operating an LIR Author: Kamran Khalid Nurani Nimpuno Sabrina Wilmot Date: February 2004 Format: PDF=195891 TXT=13941 Obsoletes: ripe-185, ripe-241 Obsoleted by: Updates: Updated by: Short content description ------------------------- This document provides guidelines to Local Internet Registries (LIRs) on the steps to take when the organisation operating an LIR changes ownership (due to a merger, sale or takeover) or stops serving entirely as an LIR. Accessing the RIPE document store --------------------------------- You can access the RIPE documents in HTML format via our website at the following URL:. http://www.ripe.net/docs/mergers.html The RIPE Document Store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-301.pdf PDF Version ftp://ftp.ripe.net/ripe/docs/ripe-301.txt plain text version From webmaster at ripe.net Wed Feb 25 14:46:29 2004 From: webmaster at ripe.net (RIPE NCC Document Announcement Service) Date: Wed, 25 Feb 2004 14:46:29 +0100 Subject: [ncc-services-wg] New Document available: RIPE-303 Message-ID: <200402251346.i1PDkTe2024258@birch.ripe.net> New RIPE Document Announcement -------------------------------------- A new document is available from the RIPE document store. Ref: ripe-303 Title: Procedure for Becoming a Member of the RIPE NCC Author: Olivia Ruimwijk Ingrid Wijte Agata Peszkowska Emma Bretherick Leo Vegoda Dominic Spratley Date: February 2004 Format: PDF=142723 TXT=14811 Obsoletes: ripe-212, ripe-230, ripe-257 Obsoleted by: Updates: Updated by: Short content description ------------------------- This document aims to provide the necessary information for those who wish to become a member of the RIPE NCC by setting up a Local Internet Registry (LIR). In this document initial guidelines are given to organisations that are planning to set up an LIR. Further, the necessary steps to set up an LIR are described. Accessing the RIPE document store --------------------------------- You can access the RIPE documents in HTML format via our website at the following URL:. http://www.ripe.net/docs/new-lir.html The RIPE Document Store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-303.pdf PDF version ftp://ftp.ripe.net/ripe/docs/ripe-303.txt plain text version From daniel.karrenberg at ripe.net Wed Feb 25 15:20:04 2004 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 25 Feb 2004 15:20:04 +0100 Subject: [ncc-services-wg] Re: [address-policy-wg] New Draft Document: De-boganising New AddressBlocks In-Reply-To: <443271380.1077645373@[10.33.50.16]> References: <403B7D73.7363498D@pipeline.ch> <443271380.1077645373@[10.33.50.16]> Message-ID: <20040225142004.GG824@dhcp-17.karrenberg.net> On 24.02 17:56, Jerome Fleury wrote: > ... > I'm very angry > about RIPE and IANA allocating those blocks too quickly, without any vision of consequences for > LIRs, and without any communications going down from Tier1 to the smallest company. What would be an appropriate timing in your opinion? Daniel From cfriacas at fccn.pt Wed Feb 25 16:41:04 2004 From: cfriacas at fccn.pt (Carlos Friacas) Date: Wed, 25 Feb 2004 15:41:04 +0000 (WET) Subject: [ncc-services-wg] New Document available: RIPE-301 In-Reply-To: <200402251344.i1PDiSe2023222@birch.ripe.net> References: <200402251344.i1PDiSe2023222@birch.ripe.net> Message-ID: Hi all, Some Comments: ====================== 2.7 Takeover Fee A takeover fee *doesnt* encourage anyone to report takeovers to RIPE-NCC. This "rule" doesnt help the RIPE-NCC improve the quality of the data regarding LIRs! 3.0 Closing a LIR Nice "wish-list", are closing LIRs going to waste any time doing it? 3.8 Database "inetnum, aut-num and domain objects": still thinking/writing only v4-ish... [add inet6num or inetnum(-type)] 4.0 "may decide": dont really like the wording. it needs objective boundaries! "significant period of time": which is? 1 year/2 years/3 years ??? "multiple warnings": boundaries again... "the LIR must then provide": i find this unbelievable -- people dont pay, or cant be reached, and even that way you state they have do provide data? :-) The last paragraph makes a LOT more sense! :-) ==================== Regards, ./Carlos -------------- IPv6 -> http://www.ip6.fccn.pt Wide Area Network Workgroup, CMF8-RIPE, CF596-ARIN FCCN - Fundacao para a Computacao Cientifica Nacional http://www.fccn.pt "Internet is just routes (131586/456), naming (millions) and... people!" On Wed, 25 Feb 2004, RIPE NCC Document Announcement Service wrote: > New RIPE Document Announcement > -------------------------------------- > A new document is available from the RIPE document store. > > > > Ref: ripe-301 > Title: Mergers, Acquisitions, Takeovers and > Closures of Organisations Operating an LIR > Author: Kamran Khalid > Nurani Nimpuno > Sabrina Wilmot > Date: February 2004 > Format: PDF=195891 TXT=13941 > Obsoletes: ripe-185, ripe-241 > Obsoleted by: > Updates: > Updated by: > > Short content description > ------------------------- > > This document provides guidelines to Local Internet Registries (LIRs) > on the steps to take when the organisation operating an LIR changes > ownership (due to a merger, sale or takeover) or stops serving > entirely as an LIR. > > > > Accessing the RIPE document store > --------------------------------- > > You can access the RIPE documents in HTML format via our website at > the following URL:. > > > > http://www.ripe.net/docs/mergers.html > > > The RIPE Document Store is also available via anonymous FTP to > ftp.ripe.net, in the directory ripe/docs. > The URLs for the new documents on the FTP-server are: > > ftp://ftp.ripe.net/ripe/docs/ripe-301.pdf PDF Version > ftp://ftp.ripe.net/ripe/docs/ripe-301.txt plain text version From oppermann at pipeline.ch Wed Feb 25 16:43:05 2004 From: oppermann at pipeline.ch (Andre Oppermann) Date: Wed, 25 Feb 2004 16:43:05 +0100 Subject: [ncc-services-wg] Re: [address-policy-wg] New Draft Document: De-boganising New AddressBlocks References: <00d501c3fbb5$6bc04180$4513180a@amer.cisco.com> Message-ID: <403CC289.985554E4@pipeline.ch> "Barry Greene (bgreene)" wrote: > > > > Andre is right, the best solution is definitely not to filter bogons. > > It does not seem people are getting at the core of the problem. Prefix > filtering the IANA reserved space was a reactionary consequence - not > something ISPs did on a whim. All I'm seeing is people being upset over > the consequence of the reactionary consequence of IANA Reserved with out > getting to the crux of the problem. Ok, it seems like a) filtering of IANA reserved prefixes creates more problems than it solves. b) noboby has named the "crux" of the problem yet. -- Andre From he at uninett.no Wed Feb 25 16:45:48 2004 From: he at uninett.no (Havard Eidnes) Date: Wed, 25 Feb 2004 16:45:48 +0100 (CET) Subject: [ncc-services-wg] Improved Secure Communication for Registration Services (RS) Mailboxes In-Reply-To: <934650000.1077661158@slimsixten.pilsnet.sunet.se> References: <400FEC71.2020101@ripe.net> <20040223195842.GG7109@complx.LF.net> <934650000.1077661158@slimsixten.pilsnet.sunet.se> Message-ID: <20040225.164548.103094935.he@uninett.no> Hi, I'll have to agree with M?ns; forcing X.509 handling and software as the only option for securing e-mail with the registration services mailboxes onto the LIR community is not something I see as particularly welcome. Today the LIRs have the option of securing communication with auto-dbm using PGP. This means that there is some deployment in the LIR community for using PGP already. Thus, I'm puzzled why the option of continuing to use PGP with the registration services mailboxes (hostmaster at ripe.net etc.) is not on the table as options. Yes, I can see there would be problems, but I have not seen any discussion which makes it clear why these problems are insurmountable (and I doubt they are). I'll admit that I'm not familiar with usage of S/MIME in e-mail, so I don't know how invasive usage of that is going to be. However, it seems clear to me that if introduction of S/MIME and X.509 will impose restrictions on what e-mail clients can be used, one is intruding on an area where there may be emotional reactions, and the proposal as it stands does not really address those issues. I'll concede, though, that on the WEB, it would seem that X.509 usage in the form of https is the only viable option, but then again, that's not what we're discussing here, right? Regards, - H?vard From gert at space.net Wed Feb 25 16:51:42 2004 From: gert at space.net (Gert Doering) Date: Wed, 25 Feb 2004 16:51:42 +0100 Subject: [ncc-services-wg] New Document available: RIPE-301 In-Reply-To: References: <200402251344.i1PDiSe2023222@birch.ripe.net> Message-ID: <20040225155142.GC8040@Space.Net> Hi, On Wed, Feb 25, 2004 at 03:41:04PM +0000, Carlos Friacas wrote: > Some Comments: > > ====================== > 2.7 Takeover Fee > > A takeover fee *doesnt* encourage anyone to report takeovers to RIPE-NCC. > This "rule" doesnt help the RIPE-NCC improve the quality of the data > regarding LIRs! Well - unless the takeover is reported, the "merged" LIR has to pay two times the yearly LIR fee. If they don't do that, allocations and eventually the reverse DNS delegation will be frozen... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 58081 (57882) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From neil at COLT.NET Wed Feb 25 16:53:50 2004 From: neil at COLT.NET (Neil J. McRae) Date: Wed, 25 Feb 2004 15:53:50 -0000 Subject: [ncc-services-wg] Improved Secure Communication for Registration Services (RS) Mailboxes In-Reply-To: <20040225.164548.103094935.he@uninett.no> Message-ID: <00a901c3fbb7$8fadb9e0$0100a8c0@doom> > I'll admit that I'm not familiar with usage of S/MIME in > e-mail, so I don't know how invasive usage of that is going > to be. However, it seems clear to me that if introduction of > S/MIME and X.509 will impose restrictions on what e-mail > clients can be used, one is intruding on an area where there > may be emotional reactions, and the proposal as it stands > does not really address those issues. How useful that emotions are used to define what the best solution might be rather than carefully thought out analysis of what the best option rather is :-) You don't add any weight to the argument with this point. > I'll concede, though, that on the WEB, it would seem that > X.509 usage in the form of https is the only viable option, > but then again, that's not what we're discussing here, right? No but it highlights one of the reasons why X.509 might be the better choice. Neil. From shane at ripe.net Wed Feb 25 18:03:04 2004 From: shane at ripe.net (Shane Kerr) Date: Wed, 25 Feb 2004 18:03:04 +0100 Subject: [ncc-services-wg] Improved Secure Communication for Registration Services (RS) Mailboxes In-Reply-To: <20040225.164548.103094935.he@uninett.no> References: <400FEC71.2020101@ripe.net> <20040223195842.GG7109@complx.LF.net> <934650000.1077661158@slimsixten.pilsnet.sunet.se> <20040225.164548.103094935.he@uninett.no> Message-ID: <403CD548.3010800@ripe.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 For the record: The RIPE NCC has no plans to stop supporting existing use of PGP. Havard Eidnes wrote: | | I'll have to agree with M?ns; forcing X.509 handling and software | as the only option for securing e-mail with the registration | services mailboxes onto the LIR community is not something I see | as particularly welcome. | | Today the LIRs have the option of securing communication with | auto-dbm using PGP. This means that there is some deployment in | the LIR community for using PGP already. Thus, I'm puzzled why | the option of continuing to use PGP with the registration | services mailboxes (hostmaster at ripe.net etc.) is not on the table | as options. Yes, I can see there would be problems, but I have | not seen any discussion which makes it clear why these problems | are insurmountable (and I doubt they are). The basic reasons to choose X.509 for e-mail are: 1. We don't have to develop key management tools. Such technology isn't rocket science - a public key upload form on the LIR Portal for instance - but security is hard to get right, and people who are experts in it have done the hard work for us if we use X.509. 2. Having the same authentication for all communication would be nice. This is not (easily) possible with PGP. You'd need a password for the LIR Portal and a PGP key for e-mail communication. | I'll admit that I'm not familiar with usage of S/MIME in e-mail, | so I don't know how invasive usage of that is going to be. | However, it seems clear to me that if introduction of S/MIME and | X.509 will impose restrictions on what e-mail clients can be | used, one is intruding on an area where there may be emotional | reactions, and the proposal as it stands does not really address | those issues. Any technology for securing e-mail restricts client choice. Among the e-mail clients that members use, there is superior "out of the box" support for X.509 than PGP. I say this based on the research that we did in response to concerns about S/MIME compatibility. As others have noted, we can support both X.509 and PGP. We can also support *only* PGP, although I think because of #2, above, this is not a good solution. Although the basic question of "do we need this at all" still seems open to me. In some ways, security is like insurance: it is only a problem if you don't have it after you should have. Ignoring the "PGP versus X.509" question, does the membership want us to support signed e-mail at all? What about encrypted e-mail? - -- Shane Kerr RIPE NCC -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAPNVHAO5deE6kXkcRAn74AKCZ3RM/r1Qw+6/lwK7vnNVVgnlNTACdEox/ OlOQcmhwJD1Zqql0aJ5gtdU= =wWNp -----END PGP SIGNATURE----- From woeber at cc.univie.ac.at Wed Feb 25 18:49:44 2004 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 25 Feb 2004 18:49:44 +0100 Subject: [ncc-services-wg] Improved Secure Communication for Registration Services (RS) Mailboxes Message-ID: <00A2DF58.98E780F6.3@cc.univie.ac.at> Hi Shane! >Ignoring the "PGP versus X.509" question, does the membership want us to >support signed e-mail at all? What about encrypted e-mail? Of course I cannot speak for the membership, I can only do so for our LIR: Yes, signed email communication should be supported. In particular with the current situation that "from" and "to" lines are just "random text" in a "subset" of messages being sent on the net these days ;-) I think that encryption almost comes for free when we've got signatures, and should be offered as well, _but not be required_. >- -- >Shane Kerr >RIPE NCC Wilfried (at.aconet) From marck at rinet.ru Wed Feb 25 19:34:13 2004 From: marck at rinet.ru (Dmitry Morozovsky) Date: Wed, 25 Feb 2004 21:34:13 +0300 (MSK) Subject: [ncc-services-wg] Improved Secure Communication for Registration Services (RS) Mailboxes In-Reply-To: <20040225094019.977F84E207@postman.ripe.net> References: <400FEC71.2020101@ripe.net> <20040223195842.GG7109@complx.LF.net> <934650000.1077661158@slimsixten.pilsnet.sunet.se> <20040225094019.977F84E207@postman.ripe.net> Message-ID: <20040225213311.L98871@woozle.rinet.ru> On Wed, 25 Feb 2004, Randy Bush wrote: [snip] RB> > I say NO to X.509. RB> RB> i would ammend slightly. the rirs provide us service. some of us RB> find pgp easier to deploy and use. some will provide x.509 easier. RB> so the rirs accepting *both* would be good. RB> RB> randy, a pgp kinda guy who also uses x.509 occasionally I could not agree more! ;-) /me, biased the same ;-) Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck at rinet.ru *** ------------------------------------------------------------------------ From he at uninett.no Wed Feb 25 20:23:37 2004 From: he at uninett.no (Havard Eidnes) Date: Wed, 25 Feb 2004 20:23:37 +0100 (CET) Subject: [ncc-services-wg] Improved Secure Communication for Registration Services (RS) Mailboxes In-Reply-To: <81C90728-677A-11D8-970C-000A95928574@kurtis.pp.se> References: <934650000.1077661158@slimsixten.pilsnet.sunet.se> <20040225094019.977F84E207@postman.ripe.net> <81C90728-677A-11D8-970C-000A95928574@kurtis.pp.se> Message-ID: <20040225.202337.06829587.he@uninett.no> > I am kind of puzzled here. > > The X.509 scheme was proposed there way before two RIPE > meetings ago, when the NCC Services WG was new. I was also then > voicing criticism, as was a few others. Not much discussion was > raised though. Shawn then made a good presentation at the NCC > Services WG meeting two RIPE meetings ago. We also had > Dirk-Wilhelm van Gulik come in and explain X.509 and > certificates in general. After the presentation, from what I > remember most people thought this was a good idea, and a good > add-on. So the NCC proceeded. > > So, I am bit surprised that people are start having views -now-. Some of us were not at the RIPE meeting two RIPE meetings ago, so if this was the only venue where the "design discussion" was held and where justification for the intended choices were presented, it's perhaps no surprise that some of us react when a baked proposal arrives with no further background information. BTW, I'm not certain if this is really something to make a big fuzz about... Regards, - H?vard -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 248 bytes Desc: not available URL: From oppermann at pipeline.ch Wed Feb 25 21:30:28 2004 From: oppermann at pipeline.ch (Andre Oppermann) Date: Wed, 25 Feb 2004 21:30:28 +0100 Subject: [ncc-services-wg] Re: [address-policy-wg] New Draft Document: De-boganising New AddressBlocks References: <00d501c3fbb5$6bc04180$4513180a@amer.cisco.com> Message-ID: <403D05E4.FEF46DF6@pipeline.ch> Rob Thomas wrote: > > Hi, team. > > ] Andre is right, the best solution is definitely not to filter bogons. > > Best solution for what problem, exactly? :) That is the biggest question. It seems to be a moving target. The first problem mentioned was nasty spammers announcing prefixes from IANA reserved netblocks. Now you open a second one with stating that address spoofing from bogon ranges is a problem. > Bogon filtering does help, though it can be accomplished in a variety > of ways (e.g. bogon route-servers, ACLs, uRPF with prefix filtering). Positive bogon filtering is exactly the wrong thing to do. It simply doesn't scale. You don't want to get packets with non-routed source addresses. This again is very much different from bogons. There are many prefixes out of the allocated netblocks which are not routed in the global routing system. The only real fix you apply here is to check the source address of a packet if it is routeable. If not, just drop it. That alone is saving you any traffic from any kind of bogus prefix or netblock. And the best of it is it automagically takes care of adjusting to new netblocks without any operator invention! Summary: Bogon filtering based on the IANA reserved listings is very much bogus in itself. > Take a peek at my study entitled "60 Days of Basic Naughtiness" for > some data points on bogon address usage. > > > > > Others see more or less of this depending on what they host or > transit. One thing we have seen in our darknet monitoring is a > decrease in the use of bogon source addresses. Why? Because they > are less effective (thankfully). Ah, but read on! I'd say you see less bogon source addresses because there are less... The RIRs have been opening a couple of fresh /8s recently. > Does this *solve* the problems of DDoS, hacking, scanning? No, of > course not. The miscreants have multiple methods in their toolkits, > with spoofing being only one. In fact spoofing applies to allocated > and routed space as much as it applies to unallocated (aka bogon) > space. What we are attempting to do is to reduce the effectiveness > of one particular set of badness. Your and some others problem is using/promoting the wrong solution to the [right]* problem. []* depending on what the problem de jour is. > Defense in depth works, and every little bit helps. Just as many > folks do not rely on a single provider for Internet access, we > shouldn't rely on a single method to mitigate or block malevolent > flows. Yes, I fully agree. But do it really right. Two wrongs don't make a right. > I love the idea of the RIRs and IANA providing the service! We at > Team Cymru are happy to help them in any way towards that goal. > Once those mechanisms are in place and tested, we're happy to turn > down our service in deference to their authoritative service. That > is a ways off, I suspect, so don't take that as a formal statement > or plan. :) There is absolutely no service for the RIRs or IANA to provide. You have got all tools you need already. If the source address is not routed, then don't route it. Very easy, very fast, very stable, no maintainance overhead, nothing that can go wrong. Just perfect. -- Andre From jorgen at hovland.cx Wed Feb 25 22:23:48 2004 From: jorgen at hovland.cx (=?ISO-8859-1?Q?J=F8rgen_Hovland?=) Date: Wed, 25 Feb 2004 22:23:48 +0100 (CET) Subject: [ncc-services-wg] Re: [address-policy-wg] New Draft Document: De-boganising New AddressBlocks In-Reply-To: <403D05E4.FEF46DF6@pipeline.ch> References: <00d501c3fbb5$6bc04180$4513180a@amer.cisco.com> <403D05E4.FEF46DF6@pipeline.ch> Message-ID: Hi On Wed, 25 Feb 2004, Andre Oppermann wrote: > Rob Thomas wrote: > > > > Hi, team. > > > > ] Andre is right, the best solution is definitely not to filter bogons. > > > > Best solution for what problem, exactly? :) > > That is the biggest question. It seems to be a moving target. The > first problem mentioned was nasty spammers announcing prefixes from > IANA reserved netblocks. Now you open a second one with stating that > address spoofing from bogon ranges is a problem. > > > Bogon filtering does help, though it can be accomplished in a variety > > of ways (e.g. bogon route-servers, ACLs, uRPF with prefix filtering). > > Positive bogon filtering is exactly the wrong thing to do. It simply > doesn't scale. You don't want to get packets with non-routed source > addresses. This again is very much different from bogons. There are > many prefixes out of the allocated netblocks which are not routed in > the global routing system. The only real fix you apply here is to > check the source address of a packet if it is routeable. If not, just > drop it. That alone is saving you any traffic from any kind of bogus > prefix or netblock. And the best of it is it automagically takes care > of adjusting to new netblocks without any operator invention! > There are actually some people here doing exactly that: Sending packets with an unroutable source-ip - with totally "legit" reasons. It's bad enough that people actually use bogon-filters for reserved blocks when it after my oppinion should be limited to unallocated blocks (for traffic blocking, not routes). You simply don't block anyones ip-range just because it isn't routable. Blocking traffic is a security concern (still after my oppinion). Internet was probably designed for bi-directional communication, but it doesn't mean you should ban one-way communication. > Summary: Bogon filtering based on the IANA reserved listings is very > much bogus in itself. > The problem with any list is that you have to maintain it. Many people don't do that. The general solution could be to stop using bogon filters at all? I have seen it too, spammers advertising unallocated prefixes. Don't have a routing-based solution to that. Spammers could might as well announce an allocated block already routed or not. That's something to think about! Joergen Hovland ENK From gert at space.net Wed Feb 25 23:11:53 2004 From: gert at space.net (Gert Doering) Date: Wed, 25 Feb 2004 23:11:53 +0100 Subject: [ncc-services-wg] Re: [address-policy-wg] New Draft Document: De-boganising New AddressBlocks In-Reply-To: References: <00d501c3fbb5$6bc04180$4513180a@amer.cisco.com> <403D05E4.FEF46DF6@pipeline.ch> Message-ID: <20040225221153.GK8040@Space.Net> Hi, On Wed, Feb 25, 2004 at 10:23:48PM +0100, J?rgen Hovland wrote: > There are actually some people here doing exactly that: Sending packets > with an unroutable source-ip - with totally "legit" reasons. Could you be somewhat more specific about these "legit" reasons? [..] > Internet was probably designed for bi-directional communication, but it > doesn't mean you should ban one-way communication. One-Way communication works quite well with legit (read: assigned to the sender) source addresses. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 58081 (57882) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From randy at psg.com Wed Feb 25 23:52:51 2004 From: randy at psg.com (Randy Bush) Date: Thu, 26 Feb 2004 06:52:51 +0800 Subject: [ncc-services-wg] Improved Secure Communication for Registration Services (RS) Mailboxes References: <20040225.164548.103094935.he@uninett.no> <00a901c3fbb7$8fadb9e0$0100a8c0@doom> Message-ID: <20040225225255.B80A24EF06@postman.ripe.net> > No but it highlights one of the reasons why X.509 might be the > better choice. to repeat myself, why is there a choice at all? why one xor the other, as opposed to one or the other? From jorgen at hovland.cx Thu Feb 26 06:20:01 2004 From: jorgen at hovland.cx (=?ISO-8859-1?Q?J=F8rgen_Hovland?=) Date: Thu, 26 Feb 2004 06:20:01 +0100 (CET) Subject: [ncc-services-wg] [routing-wg] Re: New Draft Document: De-boganising New AddressBlocks In-Reply-To: <20040225221153.GK8040@Space.Net> References: <00d501c3fbb5$6bc04180$4513180a@amer.cisco.com> <403D05E4.FEF46DF6@pipeline.ch> <20040225221153.GK8040@Space.Net> Message-ID: On Wed, 25 Feb 2004, Gert Doering wrote: > Hi, > > On Wed, Feb 25, 2004 at 10:23:48PM +0100, J?rgen Hovland wrote: > > There are actually some people here doing exactly that: Sending packets > > with an unroutable source-ip - with totally "legit" reasons. > > Could you be somewhat more specific about these "legit" reasons? Well.. Generally any device that would like to send messages without the need of a reply, or not in need of a reply through the same transport method/layer or ip (kind of asynchronous communication). I could name some, but I think what you are looking for is this: Routers with a non-routed ip-address by choice or by nature. IX-prefix for instance. IPv6 applies here specially. Besides from that there are software taking advantage of it like our own little project AP2P, truly anonymous P2P. Joergen Hovland ENK From kurtis at kurtis.pp.se Thu Feb 26 07:46:11 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Thu, 26 Feb 2004 07:46:11 +0100 Subject: [ncc-services-wg] Improved Secure Communication for Registration Services (RS) Mailboxes In-Reply-To: <20040225123457.GK7109@complx.LF.net> References: <400FEC71.2020101@ripe.net> <20040223195842.GG7109@complx.LF.net> <934650000.1077661158@slimsixten.pilsnet.sunet.se> <20040225094019.977F84E207@postman.ripe.net> <81C90728-677A-11D8-970C-000A95928574@kurtis.pp.se> <20040225123457.GK7109@complx.LF.net> Message-ID: <76A2C5E0-6827-11D8-970C-000A95928574@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-02-25, at 13.34, Kurt Jaeger wrote: > Hi! > >>>>> X.509 is not the way to go. [...] > >>> find pgp easier to deploy and use. some will provide x.509 easier. >>> so the rirs accepting *both* would be good. > >>> randy, a pgp kinda guy who also uses x.509 occasionally > >> I am kind of puzzled here. > [...] >> So, I am bit surprised that people are start having views -now-. > > Sorry for this. It's just that there are so many discussions > to have in parallel that it's difficult to follow up in time > to some of them. I already raised my voice the last time > x.509 came up, that's why I raised it again. > > We're only a small LIR, and we already see the burden of > having to many "standards" to chose from. As of know, RIPE > was steering the course with a clean (sub-)set, and it > was OK for us. I am not really following you here. What is the problem for you with the option of either using PGP or X.509? Some of the LIRs want X.509, some PGP. Isn't it good that the NCC tried to cater for both needs? As Shawn pointed out, the proposal is not to remove the PGP option. > We do not have the time to attend RIPE meetings more than > once every few years, if at all. this is why we have this WG and why this WG have a mailinglist. That is why this WG publishes minutes of the meetings that take place in person. I understand that a big issue with the RIRs (not only RIPE NCC) is that a minority of the members decide the policy for the majority. Problem is that I don't see a way around this. The "we all have day jobs" argument doesn't really apply. Life must still go on as well. Best regards, - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQD2WNqarNKXTPFCVEQJfvQCfZ1nRQVhU6yhaGbcb3HCsOqOXfUsAoObu eGFtj6u+8aH0dnY0SsZukoiq =paO/ -----END PGP SIGNATURE----- From lists at complx.LF.net Thu Feb 26 08:57:04 2004 From: lists at complx.LF.net (Kurt Jaeger) Date: Thu, 26 Feb 2004 08:57:04 +0100 Subject: [ncc-services-wg] Improved Secure Communication for Registration Services (RS) Mailboxes In-Reply-To: <76A2C5E0-6827-11D8-970C-000A95928574@kurtis.pp.se> References: <400FEC71.2020101@ripe.net> <20040223195842.GG7109@complx.LF.net> <934650000.1077661158@slimsixten.pilsnet.sunet.se> <20040225094019.977F84E207@postman.ripe.net> <81C90728-677A-11D8-970C-000A95928574@kurtis.pp.se> <20040225123457.GK7109@complx.LF.net> <76A2C5E0-6827-11D8-970C-000A95928574@kurtis.pp.se> Message-ID: <20040226075704.GP7109@complx.LF.net> Hi! > > We're only a small LIR, and we already see the burden of > > having to many "standards" to chose from. As of know, RIPE > > was steering the course with a clean (sub-)set, and it > > was OK for us. > I am not really following you here. What is the problem for you with > the option of either using PGP or X.509? >From what I understand, some RIPE things can already only be done using lir-portal. Is that correct ? So, for the foreseeable future, we have to train the staff using the right tool for the right matter, which is just additional workload. > Some of the LIRs want X.509, > some PGP. Isn't it good that the NCC tried to cater for both needs? As > Shawn pointed out, the proposal is not to remove the PGP option. I've seen too many such "Oh, we cover both" schemes in the past to know where it's heading, shortterm gain, longterm pain 8-} > > We do not have the time to attend RIPE meetings more than > > once every few years, if at all. > this is why we have this WG and why this WG have a mailinglist. That is > why this WG publishes minutes of the meetings that take place in > person. Yes, and as I already mentioned, I questioned the x.509 way when the last paper was published. Our LIR was just not also present to question it at the meeting, as well. -- MfG/Best regards, Kurt Jaeger 16 years to go ! LF.net GmbH fon +49 711 90074-23 pi at LF.net Ruppmannstr. 27 fax +49 711 90074-33 D-70565 Stuttgart mob +49 171 3101372 From lists at complx.LF.net Thu Feb 26 08:59:38 2004 From: lists at complx.LF.net (Kurt Jaeger) Date: Thu, 26 Feb 2004 08:59:38 +0100 Subject: [ncc-services-wg] Improved Secure Communication for Registration Services (RS) Mailboxes In-Reply-To: <20040225225255.B80A24EF06@postman.ripe.net> References: <20040225.164548.103094935.he@uninett.no> <00a901c3fbb7$8fadb9e0$0100a8c0@doom> <20040225225255.B80A24EF06@postman.ripe.net> Message-ID: <20040226075938.GQ7109@complx.LF.net> HI! > > No but it highlights one of the reasons why X.509 might be the > > better choice. > to repeat myself, why is there a choice at all? why one xor the > other, as opposed to one or the other? Because in the long run, providing both ways will cost more than consolidating into one. So, sometime in the future, we will be asked: Does someone still use the GPG way ? Aha, only a minority. So: We will close that down, to save costs. Frankly, if the cost in implementing the x.509 way had been invested in the GPG way, we would have exactly one and better solution than having now to run/use both. -- MfG/Best regards, Kurt Jaeger 16 years to go ! LF.net GmbH fon +49 711 90074-23 pi at LF.net Ruppmannstr. 27 fax +49 711 90074-33 D-70565 Stuttgart mob +49 171 3101372 From bgreene at cisco.com Wed Feb 25 16:38:29 2004 From: bgreene at cisco.com (Barry Greene (bgreene)) Date: Wed, 25 Feb 2004 07:38:29 -0800 Subject: [ncc-services-wg] RE: [address-policy-wg] New Draft Document: De-boganising New AddressBlocks In-Reply-To: <443271380.1077645373@[10.33.50.16]> Message-ID: <00d501c3fbb5$6bc04180$4513180a@amer.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > Andre is right, the best solution is definitely not to filter bogons. It does not seem people are getting at the core of the problem. Prefix filtering the IANA reserved space was a reactionary consequence - not something ISPs did on a whim. All I'm seeing is people being upset over the consequence of the reactionary consequence of IANA Reserved with out getting to the crux of the problem. -----BEGIN PGP SIGNATURE----- Version: PGP 8.0 iQA/AwUBQDzBLb/UEA/xivvmEQLLJQCg4UWIcbpLBAliAXNo7K088o1dKhAAoIL9 Fn0qKvv5+whsAc1+AID31cqc =yH2U -----END PGP SIGNATURE----- From robt at cymru.com Wed Feb 25 21:00:18 2004 From: robt at cymru.com (Rob Thomas) Date: Wed, 25 Feb 2004 14:00:18 -0600 (CST) Subject: [ncc-services-wg] RE: [address-policy-wg] New Draft Document: De-boganising New AddressBlocks In-Reply-To: <00d501c3fbb5$6bc04180$4513180a@amer.cisco.com> References: <00d501c3fbb5$6bc04180$4513180a@amer.cisco.com> Message-ID: Hi, team. ] Andre is right, the best solution is definitely not to filter bogons. Best solution for what problem, exactly? :) Bogon filtering does help, though it can be accomplished in a variety of ways (e.g. bogon route-servers, ACLs, uRPF with prefix filtering). Take a peek at my study entitled "60 Days of Basic Naughtiness" for some data points on bogon address usage. Others see more or less of this depending on what they host or transit. One thing we have seen in our darknet monitoring is a decrease in the use of bogon source addresses. Why? Because they are less effective (thankfully). Ah, but read on! Does this *solve* the problems of DDoS, hacking, scanning? No, of course not. The miscreants have multiple methods in their toolkits, with spoofing being only one. In fact spoofing applies to allocated and routed space as much as it applies to unallocated (aka bogon) space. What we are attempting to do is to reduce the effectiveness of one particular set of badness. Defense in depth works, and every little bit helps. Just as many folks do not rely on a single provider for Internet access, we shouldn't rely on a single method to mitigate or block malevolent flows. I love the idea of the RIRs and IANA providing the service! We at Team Cymru are happy to help them in any way towards that goal. Once those mechanisms are in place and tested, we're happy to turn down our service in deference to their authoritative service. That is a ways off, I suspect, so don't take that as a formal statement or plan. :) Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty); From robt at cymru.com Wed Feb 25 21:44:21 2004 From: robt at cymru.com (Rob Thomas) Date: Wed, 25 Feb 2004 14:44:21 -0600 (CST) Subject: [ncc-services-wg] Re: [address-policy-wg] New Draft Document: De-boganising New AddressBlocks In-Reply-To: <403D05E4.FEF46DF6@pipeline.ch> References: <00d501c3fbb5$6bc04180$4513180a@amer.cisco.com> <403D05E4.FEF46DF6@pipeline.ch> Message-ID: Hi, Andre. There are presently 95 bogon prefixes advertised by the bogon route-servers. That is plenty of space from which to generate spoofed source addresses. The reality is that the miscreants are seeing a lower return on the investment when spoofing from bogon prefixes. Thus they are more inclined to use routed space as the source of spoofed addresses. You can see this in much of the more popular spoofed packet generating malware. A lot of this malware specifically checks to ensure that the source addresses are not bogons, or ensures that the source addresses are in the same /16 as where the infected host resides. If the malware spoofs within its own /16, or has blocks to ensure that bogon prefixes are not used in the spoofing, suddenly "perfection" isn't so perfect. These addresses most certainly will be in the routing tables of most routers. This is why we never state that bogon filtering is the perfect answer to the problem of spoofing. ] There is absolutely no service for the RIRs or IANA to provide. You ] have got all tools you need already. If the source address is not ] routed, then don't route it. Very easy, very fast, very stable, no ] maintainance overhead, nothing that can go wrong. Just perfect. Ah, but that isn't perfect if the source address is routed when it shouldn't be. :) What if a bogon gets into the FIB of a router? One must filter to ensure that the routing table only includes legitimate prefixes. This is why I mentioned uRPF with prefix filtering in my previous note, and also why I suggested that there is more than one way to solve the problem. :) Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty); From gert at space.net Thu Feb 26 09:33:14 2004 From: gert at space.net (Gert Doering) Date: Thu, 26 Feb 2004 09:33:14 +0100 Subject: [ncc-services-wg] [routing-wg] Re: New Draft Document: De-boganising New AddressBlocks In-Reply-To: References: <00d501c3fbb5$6bc04180$4513180a@amer.cisco.com> <403D05E4.FEF46DF6@pipeline.ch> <20040225221153.GK8040@Space.Net> Message-ID: <20040226083313.GM8040@Space.Net> Hi, On Thu, Feb 26, 2004 at 06:20:01AM +0100, J?rgen Hovland wrote: > > On Wed, Feb 25, 2004 at 10:23:48PM +0100, J?rgen Hovland wrote: > > > There are actually some people here doing exactly that: Sending packets > > > with an unroutable source-ip - with totally "legit" reasons. > > > > Could you be somewhat more specific about these "legit" reasons? > > Well.. > Generally any device that would like to send > messages without the need of a reply, or not in need of a reply through > the same transport method/layer or ip (kind of asynchronous > communication). No specific reason why these applications couldn't use "proper" source-IPs, even if not expecting a reply. > I could name some, but I think what you are looking for is this: > Routers with a non-routed ip-address by choice or by nature. IX-prefix > for instance. IPv6 applies here specially. IXP prefixes can be non-routed, but *are* well-known and properly assigned. So bogon source filtering will (usually) NOT blackhole IXP prefixes (while excessive uRPF on upstream lines will). > Besides from that there are software taking advantage of it like our > own little project AP2P, truly anonymous P2P. Now this is an interesting problem indeed. You need to weigh the benefits of this (in comparision to things like encrypted P2P clouds that claim to bring anonymity as well) against the chances of non-trackable abuse. This is a tricky question. I have made my decision on that: our customers can do whatever they like - as long as they do it from IP addresses that are well-assigned to them (even if temporary). If they commit abuse, in whatever form, be it a virus infection or intentional hacking, they can be traced back, and can be made legally liable for any damage they cause (if necessary). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 58081 (57882) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From neil at COLT.NET Thu Feb 26 09:54:55 2004 From: neil at COLT.NET (Neil J. McRae) Date: Thu, 26 Feb 2004 08:54:55 -0000 Subject: [ncc-services-wg] Improved Secure Communication for Registration Services (RS) Mailboxes In-Reply-To: <20040225225255.B80A24EF06@postman.ripe.net> Message-ID: <075001c3fc46$34a4ed40$0100a8c0@doom> > to repeat myself, why is there a choice at all? why one xor > the other, as opposed to one or the other? Agreed, both could be supported easily. From hank at att.net.il Thu Feb 26 10:47:12 2004 From: hank at att.net.il (Hank Nussbacher) Date: Thu, 26 Feb 2004 11:47:12 +0200 Subject: [ncc-services-wg] New Document available: RIPE-301 In-Reply-To: References: <200402251344.i1PDiSe2023222@birch.ripe.net> <200402251344.i1PDiSe2023222@birch.ripe.net> Message-ID: <5.1.0.14.2.20040226113339.00ac5990@max.att.net.il> At 03:41 PM 25-02-04 +0000, Carlos Friacas wrote: >3.0 Closing a LIR >Nice "wish-list", are closing LIRs going to waste any time doing it? From my experience - not one will *ever* inform RIPE. It is the last thing on their mind when closing shop. >4.0 > >"may decide": dont really like the wording. it needs objective boundaries! >"significant period of time": which is? 1 year/2 years/3 years ??? >"multiple warnings": boundaries again... >"the LIR must then provide": i find this unbelievable -- people dont pay, >or cant be reached, and even that way you state they have do provide >data? :-) >The last paragraph makes a LOT more sense! :-) I won't discuss takeovers since they probably only constitute 5% of the defunct LIRs but rather LIRs that no longer exist (95%) which should be covered by this document (it states the word "closure" in the title). In section 3.0 it states "In the case of a closure of an LIR, the RIPE NCC should be contacted at least three months prior to the required closure date at lir-help at ripe.net. Only registered LIR contact person(s) can discuss a closure of an LIR with the RIPE NCC. In case of bankruptcy, the court-appointed administrator may take over these responsibilities." Real world example: In April 2001 (yup!) I informed RIPE to reclaim 212.77.128.0/23 since that Israeli LIR went bankrupt and no longer existed. No luck. In June 2002 I tried again and pointed out that Doarnet no longer even appears as a LIR at: http://www.ripe.net/ripencc/mem-services/general/indices/IL.html The answer I got back in June 2002 was "This IP range is a part of DoarNet Ltd's allocation. DoarNet Ltd's LIR is closed and we are going to take the whole allocation back in near future." (Ticket NCC#2002056720). Till today that IP range is still listed in whois. I have therefore not bothered to try to inform RIPE NCC of further "dead" IP ranges since it is a waste of my time as well as theirs. -Hank Nussbacher LIR: il.isoc and il.iucc >==================== > >Regards, > >./Carlos >-------------- IPv6 -> http://www.ip6.fccn.pt > Wide Area Network Workgroup, CMF8-RIPE, CF596-ARIN >FCCN - Fundacao para a Computacao Cientifica Nacional http://www.fccn.pt > > "Internet is just routes (131586/456), naming (millions) and... people!" > > > >On Wed, 25 Feb 2004, RIPE NCC Document Announcement Service wrote: > > > New RIPE Document Announcement > > -------------------------------------- > > A new document is available from the RIPE document store. > > > > > > > > Ref: ripe-301 > > Title: Mergers, Acquisitions, Takeovers and > > Closures of Organisations Operating an LIR > > Author: Kamran Khalid > > Nurani Nimpuno > > Sabrina Wilmot > > Date: February 2004 > > Format: PDF=195891 TXT=13941 > > Obsoletes: ripe-185, ripe-241 > > Obsoleted by: > > Updates: > > Updated by: > > > > Short content description > > ------------------------- > > > > This document provides guidelines to Local Internet Registries (LIRs) > > on the steps to take when the organisation operating an LIR changes > > ownership (due to a merger, sale or takeover) or stops serving > > entirely as an LIR. > > > > > > > > Accessing the RIPE document store > > --------------------------------- > > > > You can access the RIPE documents in HTML format via our website at > > the following URL:. > > > > > > > > http://www.ripe.net/docs/mergers.html > > > > > > The RIPE Document Store is also available via anonymous FTP to > > ftp.ripe.net, in the directory ripe/docs. > > The URLs for the new documents on the FTP-server are: > > > > ftp://ftp.ripe.net/ripe/docs/ripe-301.pdf PDF Version > > ftp://ftp.ripe.net/ripe/docs/ripe-301.txt plain text version From randy at psg.com Thu Feb 26 11:09:32 2004 From: randy at psg.com (Randy Bush) Date: Thu, 26 Feb 2004 18:09:32 +0800 Subject: [ncc-services-wg] Improved Secure Communication for Registration Services (RS) Mailboxes References: <20040225.164548.103094935.he@uninett.no> <00a901c3fbb7$8fadb9e0$0100a8c0@doom> <20040225225255.B80A24EF06@postman.ripe.net> <20040226075938.GQ7109@complx.LF.net> Message-ID: <20040226100934.E8F904E530@postman.ripe.net> >> to repeat myself, why is there a choice at all? why one xor the >> other, as opposed to one or the other? > Because in the long run, providing both ways will cost more than > consolidating into one. thank you henry ford ("you can have any color you want, as long as it is black") :-). it will cost the ncc a bit more. not doing both will cost many of us a bit more. who is the customer and what are we optimizing? randy From neil at COLT.NET Thu Feb 26 11:11:14 2004 From: neil at COLT.NET (Neil J. McRae) Date: Thu, 26 Feb 2004 10:11:14 -0000 Subject: [ncc-services-wg] Improved Secure Communication for Registration Services (RS) Mailboxes In-Reply-To: <20040226100934.E8F904E530@postman.ripe.net> Message-ID: <005801c3fc50$dda38410$0100a8c0@doom> > thank you henry ford ("you can have any color you want, as > long as it is black") :-). > > it will cost the ncc a bit more. not doing both will cost > many of us a bit more. who is the customer and what are > we optimizing? how very mutual of you Randy :-) Neil. From kurtis at kurtis.pp.se Thu Feb 26 15:51:20 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Thu, 26 Feb 2004 15:51:20 +0100 Subject: [ncc-services-wg] Improved Secure Communication for Registration Services (RS) Mailboxes In-Reply-To: <20040226075704.GP7109@complx.LF.net> References: <400FEC71.2020101@ripe.net> <20040223195842.GG7109@complx.LF.net> <934650000.1077661158@slimsixten.pilsnet.sunet.se> <20040225094019.977F84E207@postman.ripe.net> <81C90728-677A-11D8-970C-000A95928574@kurtis.pp.se> <20040225123457.GK7109@complx.LF.net> <76A2C5E0-6827-11D8-970C-000A95928574@kurtis.pp.se> <20040226075704.GP7109@complx.LF.net> Message-ID: <3D06028C-686B-11D8-970C-000A95928574@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > >>> We're only a small LIR, and we already see the burden of >>> having to many "standards" to chose from. As of know, RIPE >>> was steering the course with a clean (sub-)set, and it >>> was OK for us. > >> I am not really following you here. What is the problem for you with >> the option of either using PGP or X.509? > > From what I understand, some RIPE things can already only be > done using lir-portal. Is that correct ? Yes....but for all I know, all that can be done with PGP and email to hostmaster at ripe.net or equivalent mail address as well. > > So, for the foreseeable future, we have to train the staff using > the right tool for the right matter, which is just additional > workload. Well, you will have to train them to use ANY tool. Be it email+PGP or LIR-portal+X.509... >> Some of the LIRs want X.509, >> some PGP. Isn't it good that the NCC tried to cater for both needs? As >> Shawn pointed out, the proposal is not to remove the PGP option. > > I've seen too many such "Oh, we cover both" schemes in the past > to know where it's heading, shortterm gain, longterm pain 8-} I would be really interested in examples here... I will admit that I have concerns about the X.509 stuff, like the authorization chain to the mirrors (that I did a poor job of explaining in Amsterdam). but I am not sure there is that much issue with using both systems. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQD4H7KarNKXTPFCVEQLKCgCeMWrmQaopyJacVnFQEsTdjthz/aAAmgK6 JUAuPU+SBgD6e2ggsJMFMSv4 =Uzze -----END PGP SIGNATURE----- From michel at arneill-py.sacramento.ca.us Fri Feb 27 05:28:04 2004 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Thu, 26 Feb 2004 20:28:04 -0800 Subject: [ncc-services-wg] RE: [address-policy-wg] New Draft Document: De-boganising New AddressBlocks Message-ID: > Rob Thomas wrote: > The reality is that the miscreants are seeing a lower > return on the investment when spoofing from bogon prefixes. Because they are being filtered :-) If more people filtered bogons, the "ROI" would be even lower. Although it is clear that bogon filtering is not a complete cure for spoofing, it does help and it also helps for some spammers. The only negative effect of bogon filtering is not-up-to-date filters, which is why we have written this draft that will expand the applicability domain of bogon route servers and other filtering schemes. Michel. From mansaxel at sunet.se Fri Feb 27 11:22:37 2004 From: mansaxel at sunet.se (=?ISO-8859-1?Q?M=E5ns_Nilsson_KTHNOC?=) Date: Fri, 27 Feb 2004 11:22:37 +0100 Subject: [ncc-services-wg] Improved Secure Communication for Registration Services (RS) Mailboxes In-Reply-To: <403CD548.3010800@ripe.net> References: <400FEC71.2020101@ripe.net> <20040223195842.GG7109@complx.LF.net> <934650000.1077661158@slimsixten.pilsnet.sunet.se> <20040225.164548.103094935.he@uninett.no> <403CD548.3010800@ripe.net> Message-ID: <422890000.1077877357@slimsixten.pilsnet.sunet.se> --On Wednesday, February 25, 2004 18:03:04 +0100 Shane Kerr wrote: > Any technology for securing e-mail restricts client choice. Among the > e-mail clients that members use, there is superior "out of the box" > support for X.509 than PGP. I say this based on the research that we did > in response to concerns about S/MIME compatibility. Please elaborate, because I have a hard time to find an email client not supporting an ASCII-armored PGP message, but there are tons of them frowning on x.509 attachments. Some of us actually do the equivalent of: $EDITOR ripe-template.txt gpg --clearsign ripe-template.txt | /bin/mail for our RIPE communications. > As others have noted, we can support both X.509 and PGP. We can also > support *only* PGP, although I think because of #2, above, this is not a > good solution. I would argue that it is the other way around; given the forced choice of "only one" the broadest support exists for PGP. > Although the basic question of "do we need this at all" still seems open > to me. In some ways, security is like insurance: it is only a problem if > you don't have it after you should have. > > Ignoring the "PGP versus X.509" question, does the membership want us to > support signed e-mail at all? What about encrypted e-mail? Given the mess an evil person can do by creatively adjusting records in the routing database, I suggest that RIRen must actively promote the use of technologies that protect our infrastructure; thus, signing should be more or less mandatory, and encryption should be available for secure out-of-band communications -- this then more human-to-human, to solve strange issues, send sensitive data, and so forth. rgds, -- M?ns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From gert at space.net Fri Feb 27 13:15:40 2004 From: gert at space.net (Gert Doering) Date: Fri, 27 Feb 2004 13:15:40 +0100 Subject: [ncc-services-wg] Improved Secure Communication for Registration Services (RS) Mailboxes In-Reply-To: <422890000.1077877357@slimsixten.pilsnet.sunet.se> References: <400FEC71.2020101@ripe.net> <20040223195842.GG7109@complx.LF.net> <934650000.1077661158@slimsixten.pilsnet.sunet.se> <20040225.164548.103094935.he@uninett.no> <403CD548.3010800@ripe.net> <422890000.1077877357@slimsixten.pilsnet.sunet.se> Message-ID: <20040227121540.GS8040@Space.Net> Hi, On Fri, Feb 27, 2004 at 11:22:37AM +0100, M?ns Nilsson KTHNOC wrote: > > As others have noted, we can support both X.509 and PGP. We can also > > support *only* PGP, although I think because of #2, above, this is not a > > good solution. > > I would argue that it is the other way around; given the forced choice of > "only one" the broadest support exists for PGP. I don't see anyone talking about "only one". Why are you worried? (If someone proposed abandoning PGP, I would be one of the loudest voices opposing it) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 58081 (57882) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From he at uninett.no Fri Feb 27 13:32:51 2004 From: he at uninett.no (Havard Eidnes) Date: Fri, 27 Feb 2004 13:32:51 +0100 (CET) Subject: [ncc-services-wg] Improved Secure Communication for Registration Services (RS) Mailboxes In-Reply-To: <20040227121540.GS8040@Space.Net> References: <403CD548.3010800@ripe.net> <422890000.1077877357@slimsixten.pilsnet.sunet.se> <20040227121540.GS8040@Space.Net> Message-ID: <20040227.133251.76500646.he@uninett.no> > > I would argue that it is the other way around; given the forced > > choice of "only one" the broadest support exists for PGP. > > I don't see anyone talking about "only one". Why are you worried? Well, that's not quite precise. The document under discussion talks about securing communication to and from RIPE NCC registration services mailboxes, e.g. hostmaster at ripe.net etc. -- typically functions where humans at the RIPE NCC are involved in resolving the matter (yes?). Therefore, I perceive this as explicitly excluding auto-dbm at ripe.net. Add to that that Shane Kerr has explicitly said in this discussion that none of the current PGP support will be removed. However, the document under discussion appears to offer X.509 as the only method for securing communication with RS mailboxes, the alternative is continue as today, where this communication is going unsigned and in the clear in both directions. Regards, - H?vard From woeber at cc.univie.ac.at Fri Feb 27 13:46:33 2004 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 27 Feb 2004 13:46:33 +0100 Subject: [ncc-services-wg] Improved Secure Communication for Registration Services (RS) Mailboxes Message-ID: <00A2E0C0.9382A2C6.9@cc.univie.ac.at> >However, the document under discussion appears to offer X.509 as the >only method for securing communication with RS mailboxes, If this is the case then I strongly suggest to amend the wording! >the >alternative is continue as today, where this communication is going >unsigned and in the clear in both directions. Not really, the Reg.Serv Dept. obviously applies PGP signatures to outgoing mail by default (see below). And I really appreciate that!! >Regards, > >- H?vard Regards, Wilfried. ______________________________________________________________________ To: Woeber at CC.UniVie.ac.at Subject: NCC#2004xxxxxx AW raise From: RIPE NCC Hostmaster Date: Fri, 30 Jan 2004 15:18:10 +0100 This is a cryptographically signed message in MIME format. ------------=_1075472293-11892-0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-length: 280 Dear Wilfried, Thank you for approaching us this morning. We have decided to raise your Assignment Window from /xx to /xx (you will receive an official approval message within a few moments). If you have any question please let us know. Kind regards, Andrea Cima RIPE NCC - ------------=_1075472293-11892-0 Content-Type: application/pgp-signature Content-Disposition: inline Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Comment: For info see https://www.ripe.net/rs/pgp/ iD8DBQFAGmelaF6b6AtxYiURAmMIAJ4kseNxvU+D7NoFdPpe8ikAY2EYRwCfW8pm Ww6xtXPHUtuKACSDvWMq0Q8= =eCb7 -----END PGP SIGNATURE----- ------------=_1075472293-11892-0-- -------------------------------------------------------------------------------- From woeber at cc.univie.ac.at Fri Feb 27 13:59:01 2004 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 27 Feb 2004 13:59:01 +0100 Subject: [ncc-services-wg] Improved Secure Communication for Registration Services (RS) Mailboxes Message-ID: <00A2E0C2.50D8D4B6.3@cc.univie.ac.at> Hi Gert! >> I would argue that it is the other way around; given the forced choice of >> "only one" the broadest support exists for PGP. > >I don't see anyone talking about "only one". Why are you worried? Well, the "only one" may come from the wording in the document, and it was suggested already during this discussion (although _in favour_ of PGP!!): ______________________________________________________________________ From: Kurt Jaeger To: ncc-services-wg at ripe.net Subject: Re: [ncc-services-wg] Improved Secure Communication for Registration Services (RS) Mailboxes Date: Thu, 26 Feb 2004 08:59:38 +0100 HI! > > No but it highlights one of the reasons why X.509 might be the > > better choice. > to repeat myself, why is there a choice at all? why one xor the > other, as opposed to one or the other? Because in the long run, providing both ways will cost more than consolidating into one. So, sometime in the future, we will be asked: Does someone still use the GPG way ? Aha, only a minority. So: We will close that down, to save costs. [ .... ] Frankly, if the cost in implementing the x.509 way had been invested in the GPG way, we would have exactly one and better solution than having now to run/use both. -- MfG/Best regards, Kurt Jaeger 16 years to go ! LF.net GmbH fon +49 711 90074-23 pi at LF.net Ruppmannstr. 27 fax +49 711 90074-33 D-70565 Stuttgart mob +49 171 3101372 ______________________________________________________________________ >(If someone proposed abandoning PGP, I would be one of the loudest voices >opposing it) So I guess you should voice your opinion :-) >Gert Doering > -- NetMaster >-- >Total number of prefixes smaller than registry allocations: 58081 (57882) > >SpaceNet AG Mail: netmaster at Space.Net >Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 >80807 Muenchen Fax : +49-89-32356-299 Wilfried. From matthew at ripe.net Fri Feb 27 15:36:25 2004 From: matthew at ripe.net (Matthew Williams) Date: Fri, 27 Feb 2004 15:36:25 +0100 Subject: [ncc-services-wg] REMINDER: Inter-Domain Routing Workshop, RIPE NCC, Amsterdam (May 1-2, 2004) Message-ID: <004c01c3fd3f$13cb8da0$300200c1@rockstar> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [Apologies for duplicate mails] Dear All, The Inter-Domain Routing Workshop will take place at the RIPE NCC in Amsterdam during the weekend before RIPE 48 (May 1-2, 2004). This RIPE meeting will also be held in Amsterdam. The goal of the workshop is to bring together a focused group of operators, vendors, and researchers to discuss important mid- and long-term operational problems, as well as new academic ideas, in an OPEN forum. The wide scope for topics was intended on our part. The organisers are: * Intel Research * Universit?t Karlsruhe Institut f?r Telematik * Technische Universit?t M?nchen, Computer Science Department * RIPE NCC * Schlund+Partner AG, Karlsruhe See URL for more information: http://www.tm.uka.de/idrws/ We are hoping that these discussions will become an invigorating and lively affair. Please feel free to drop us a line at idrws at ripe.net. Kind regards, Matthew Williams --- > Matthew Williams (MW243-RIPE) > Customer Liaison Engineer > RIPE NCC - http://www.ripe.net/np/ -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.4 iQA/AwUBQD9V5sHkFbJe+GdoEQJM9ACfYr/r7uErUN7VG8As7AFszid7LS0AnRzB /ieShHagijt6tCx7Q4wvA/O2 =NAT1 -----END PGP SIGNATURE----- From woeber at cc.univie.ac.at Fri Feb 27 21:49:23 2004 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 27 Feb 2004 21:49:23 +0100 Subject: [ncc-services-wg] struct. differences in PI vs. PA request forms & use of role: Message-ID: <00A2E104.068DF296.19@cc.univie.ac.at> Dear community and NCC, while talking with one of my colleagues (who very recently attended a LIR training), and processing a request submitted by one of our customers to change their inetnum: contact details I started to wonder: As far as I can remember there was a rule (strong recommendation?) to use a "real" person as the contact in admin-c:, while a role: could be used for tech-c: and zone-c: (But maybe I am mixing [legacy] domain object requirements or some TLD admin's requirements with the address registry...) I was told that the LIR training course _does_ mention the role: object, but _does not_ offer guidance about the use. So, I started digging for documentation about the use of, and linkage to, person: and role: objects for inet[6]num. No success. I probably missed some section where it is described. Then I had a look at the PI and PA request forms and accomp. notes. Again, no guidance as to where a role c/should be used (or not). At the same time I became aware again, that the _new_ PI and PA address request forms are different: the PI form still has the database object section, but that was dropped from the PA form! I am left with 2 questions now: A) why is there a difference between PI and PA forms regarding DB information? B) is there still a recommendation or requirement to use a "real" person: as the reference for an admin-c:? Thanks for any help. Wilfried. _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber at 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~