[ncc-services-wg] Fwd: DRAFT Services WG minutes

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



	All,

please find attached the minutes from the last RIPE NCC Services WG  
meeting. Please send any comments or corrections.
Best regards,

- - kurtis -

> *********************************************************************** 
> ********************************
>
> RIPE NCC Services Working Group Summary (RIPE 48)
>
> Date:   Tuesday 4 May 2004
> Time:   14.00 - 15.30
> Location: Grand Ballroom
>
> Date:   Thursday 6 May 2004
> Time:   11.00 - 12.30
> Location: Grand Ballroom
>
> AGENDA:
>
> A. Administrative Matters
> B. Axel - RIPE NCC Update / 2005 Activity Plan
> C. RIPE NCC - LIR Portal Update
> E. Kurtis Lindqvist - WG input for the 2005 Activity Plan
> F. Filiz Yilmaz - Authentication for Hostmaster Robot
> G. Daniel Karrenberg - De-Bogonising New Address Blocks
> Y. Open Microphone
> Z. AOB
>
> http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48- 
> nccserv-agenda.pdf
> ********************************************************************
>
> A. Kurtis Lindqvist - Administrative Matters
> **********************************
> Chair: Kurtis Lindqvist - Netnod Internet Exchange
> Co-Chair: Bijal Sanghani - Flag Telecom
> Scribes:  Eamonn McGuinness, Nathalie Dougall
>
> Minutes from RIPE 47 approved:
> http://www.ripe.net/ripe/wg/ncc-services/r47-minutes.html
>
> B. RIPE NCC Update / 2005 Activity Plan
> Presented by: Axel Pawlik - RIPE NCC Managing Director
> http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48- 
> nccserv-ncc-update.pdf
> ***********************************************************************
> Axel spoke about the 2004 and 2005 Activity Plans.  Members were asked  
> to think about their input for the 2005 Activity Plan.  The agenda  
> point at the 2nd session of this working group (Thursday morning) is  
> where people can provide input and/or raise any issues of concern.  
> People are also encouraged to approach Axel, and/or other member of  
> the RIPE NCC staff, and/or any of the attending RIPE NCC Board members  
> to speak privately should they be hesitant to do in the public arena.
>
> Within Registration Services (RS), the RIPE NCC Hostmasters are trying  
> to improve how they interact with customers. The Local Internet  
> Registry (LIR) Portal has many useful features such as new request  
> forms, wizards and so on. Reverse Delegation is in the process of  
> becoming more automated and straightforward.
>
> The RIPE NCC is unhappy with IANA at the moment as it is still waiting  
> for a new block of IPv6 addresses. They were notified in February to  
> expect a large request from the RIPE NCC as requests from members are  
> being received.  Feedback received from IANA was positive. However  
> when the RIPE NCC requested an additional IPv6 block at the end of  
> March, IANA responded that they had issues with the request and needed  
> to discuss it with the IAB (Internet Architecture Board) first. It was  
> made clear that the IAB are not at fault.
>
> Kurtis Lindqvist (Chair) asked what exactly is the problem?
>
> Axel (RIPE NCC Managing Director) said in the past it was decided that  
> IANA give /23 blocks of IPv6 to each RIR which was fine so far. But  
> now the RIPE NCC are receiving requests which justify larger  
> allocations, hence the request for a larger allocation than a /23.
>
> Gert Doering (SpaceNet) wanted to clarify a small point, that the  
> community were actually not so happy that only /23s were allocated to  
> the RIR's. Larger blocks should have been given.
>
> - -Back to the presentation-
>
> Axel highlighted that the RIPE NCC are being proactive in scheduling  
> member training courses alongside related conferences in the RIPE  
> service region.
>
> AfriNIC should become the next established RIR at the end of 2004, or  
> in early 2005. The 1st AfriNIC open policy meeting will be held in  
> Dakar in May - http://www.afrinic.net.
>
> The Membership Liaison Officers (MLOs) are responsible for improving  
> co-ordination and to provide further outreach to the RIPE NCC  
> community. There are two more Regional Meetings planned in 2004:  
> Moscow and Nairobi.
>
> The RIPE NCC Communications department are co-ordinating with the  
> other RIRs to report consistent and accurate data to news agencies and  
> media when necessary.
>
> Axel reported that the RIPE NCC is planning another Membership Survey  
> in 2005 as the previous one (2002) was very useful. Many suggestions  
> from the previous survey were implemented as can be seen from this
>
> year's Annual Report and Activity Plan.
>
> Wilfried Woeber (UniVie / ACOnet asked why these regional meetings are  
> free of charge and why they weren't self-sufficient, like the RIPE  
> Meetings.
>
> Axel explained that the Regional Meetings are RIPE NCC meetings, not  
> RIPE meetings.  The difference is that the RIPE NCC goes out into a  
> specific region, meeting directly with the membership, according to  
> needs of that region.  This is a different focus than the open process  
> of RIPE meetings.
>
> The 2002 Membership Survey and other sources expressed the opinion  
> that some parts of the RIPE region were unaware or unfamiliar with the  
> RIPE NCC and with general policies and procedures. Regional desks were  
> suggested, thus the MLO role was created within the RIPE NCC.  The  
> first obvious region to meet was the Middle East, followed by Russia.   
> The goals of these meetings are to educate, increase knowledge and  
> allow the RIPE NCC to be more accessible to members in remote regions.  
>  These meetings also afford us the opportunity to speak with  
> government agencies and so forth.
>
> C. RIPE NCC / LIR Portal Update
> Presented by: Vesna Manojlovic - RIPE NCC Advanced Courses Trainer
> http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48- 
> nccserv-lirportal.pdf
> ********************************************************************
> Vesna began by asking how many of the present audience uses the LIR  
> Portal. Nearly everyone put their hand up.
>
> During the presentation Wilfried Woeber (UniVie / ACOnet) asked what  
> 'RSS' stands for?
>
> Vesna explained that RSS stands for 'Really Simple Syndication'. It is  
> a web syndication protocol used primarily by news websites and web  
> logs.
>
> Vesna reported how the tools on the LIR Portal are helping the RIPE  
> NCC's members acquire IP address resources quickly. This in turn  
> allows the RIPE NCC to concentrate more time assisting new and  
> inexperienced LIRs.  Vesna concluded by saying that all feedback and  
> input from the membership is welcome and does make a difference.
>
> Andre Koopal (MCI) would like to be able to have access to the  
> messages in the Hostmaster tickets his LIR has with the RIPE NCC.
>
> Kurtis Lindqvist (Chair) ended the discussion reiterating the fact  
> that the original intention was for an LIR to give this presentation  
> but there were no volunteers. He would like to get a volunteer for the  
> next RIPE meeting in Manchester in September 2004.
>
> E. Kurtis Lindqvist (Chair) - WG input for the 2005 Activity Plan
> ***************************************************
> Kurtis reminded everyone why this working group was set up - to  
> provide input and dialogue to the Activity Plan of the RIPE NCC. The  
> work the RIPE NCC does should reflect the wishes and needs of the  
> community.
>
> When there was no response from the audience when asked if anyone gave  
> any feedback to the RIPE NCC about the Activity Plan for 2005, Kurtis  
> asked if everyone were happy for the RIPE NCC to take care of  
> compiling the Activity Plan on their own. Again there was no response.
>
> Axel Pawlik (RIPE NCC Managing Director) was not surprised, but still  
> a little disappointed at not receiving any feedback on this topic. He  
> will give a similar presentation (Agenda item B.) on Friday afternoon  
> during the RIPE NCC General Meeting (GM) where members will be  
> present. This therefore presents another formal opportunity for RIPE  
> NCC members to give input and thoughts on the AP. If Axel or the RIPE  
> NCC Board do not receive any feedback they will take this as approval  
> to go ahead with the plan. Axel reminded everyone that the Activity  
> Plan would be published to the RIPE NCC membership in August 2004, a  
> few weeks before the General Meeting at RIPE 49 in Manchester in  
> September 2004.
>
> Kurtis pleaded to the community to give input and feedback with  
> respect to the Activity Plan.  If it is difficult to speak up at the  
> meeting, then emails to Axel and/or the RIPE NCC Board Members are  
> also an option.  It is worrying that there appears to be silence on  
> this issue.
>
> F. Authentication for Hostmaster Robot
> Presented by:  Filiz Yilmaz - RIPE NCC Senior Hostmaster
> http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48- 
> nccserv-hm-robot.pdf
> **********************************************************************
> After Filiz gave her presentation, Gert Doering (SpaceNet) said that  
> in his opinion the problem with PGP is the key management (user keys,  
> Hostmaster key etc.) and the RIPE NCC have solved this now. He  
> suggested a script could be added to the LIR Portal for users who can  
> choose to have their e-mails encrypted or not. Then the RIPE NCC  
> Hostmasters can accept the e-mails as encrypted or not.
>
> Shane Kerr (RIPE NCC Software Manager) was more cautious as this  
> change would not come without complications. He explained how many LIR  
> Portal users lose their keys but the RIPE NCC cannot suddenly stop  
> communicating with LIRs in those cases.  Signing is easier, as the  
> e-mail is visible and the user knows what the RIPE NCC is trying to  
> send them and vice versa. The RIPE NCC can look at their mail logs and  
> see what is going on there. There is already an infrastructure for key  
> management and recovery in place.
>
> Another problem Shane reported is that some communication is not only  
> "one-to-one", but also sometimes "one-to-many". This complicates the  
> picture quite a bit. All of the recipients have to read the e-mail and  
> if some do not have a PGP key or X.509 there is simply no way to  
> encrypt it for them. It was decided not to pursue the effort of going  
> into this issue in great detail before the last RIPE Meeting, because  
> of the complications it poses, therefore the RIPE NCC decided to focus  
> on verifying the correctness of the e-mail before starting to encrypt  
> it.
>
> Once this is done, the RIPE community will have to be asked if it is  
> worth the effort for the RIPE NCC to go over all of these issues and  
> put together a plan.
>
> Randy Bush (IIJ) asked, regarding automated software signing of  
> messages with PGP and X.509, how those keys are maintained and revoked  
> and so on.  This is in light of the fact that if this process is being  
> done automatically, are there keys on a hard disk which may pose a  
> security risk?
>
> Shane (RIPE NCC Software Manager) responded by saying it is RIPE NCC's  
> policy to have extra secure hosts. These include CA and the RIPE NCC's  
> PGP signing box. There are two or three hosts, which have a limited  
> access and are connected directly to a single box, which is not on the  
> fabric of the RIPE NCC's network. The Operations Department of the  
> RIPE NCC can access most of the machines in the RIPE NCC. These boxes  
> have a smaller set of Administrators with access. The hosts are secure  
> so the keys are not generally available.
>
> The RIPE NCC takes security seriously. For PGP there is a key-signing  
> box and a set of procedures where the keys are changed regularly. Even  
> so, Shane admits the RIPE NCC has not published their old keys  
> recently and he promises to get that fixed shortly.
>
> Randy Bush (IIJ) asserted that presuming hosts are secure is a rather  
> weak assumption.
>
> Kurtis Lindqvist (Chair) asked Shane if there has there been any more  
> co-ordination work done with the other RIR's regarding X.509?
>
> Shane (RIPE NCC Software Manager) said the RIPE NCC is willing to make  
> a more detailed presentation on the underlining issues of PGP  
> encryption if the community wishes. The RIPE NCC put together this  
> presentation because they would like to start building it. Shane asked  
> the audience if the community were supportive of the proposal. There  
> were no objections to the proposal.
>
> ACTIONS
> ********
> 48.1 RIPE NCC - To make a more detailed presentation on PGP encryption.
> 48.2 RIPE NCC - To start implementing the key-signing proposal.
>
> G. De-Bogonising New Address Blocks
> Presented by:  Daniel Karrenberg - RIPE NCC Chief Scientist
> http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48- 
> nccserv-debogon.pdf
> *********************************************************************
> This presentation highlights the connectivity problems of LIR's who  
> receive address space out of very new /8's the RIPE NCC receive from  
> the IANA. The problem is that it takes too much time for all operators  
> to update their bogon filters.
>
> Geoff Huston (TELSTRA) pointed out that the address prefixes stated in  
> the presentation are taken from the RIPE whois database and not from  
> the delegated zone files of the RIPE NCC. The address prefixes stored  
> in the RIPE NCC's delegated files are more reliable as (a) handed out  
> officially by the RIPE NCC, (b) are in use and (c) can be routed.
>
> Geoff expressed his opinion regarding the necessity of using the  
> delegated files as authority if the community wants to be serious  
> about using correct bogon information. The Whois Databases should not  
> be relied upon, as they are problematic for all kinds of reasons. He  
> would not advise anyone doing real-live packet filtering to rely on a  
> Whois Database.
>
> Daniel Karrenberg (RIPE NCC Chief Scientist) agreed and said the RIPE  
> NCC will amend this procedure.
>
> The final slide of the presentation called for input from the audience  
> about this pilot. Would people like to see this make into a RIPE  
> document with the intention of becoming a regular RIPE NCC service?
>
> Geoff Huston (TELSTRA) asked for more granularity when producing  
> information on bogons.  Addresses that have been allocated or assigned  
> but are in an "active" /8 make ideal bogons for miscreants.  The RIPE  
> NCC should publish this information.
>
> Ruediger Volk (Deutsche Telecom) was next to say he would like the  
> RIRs to clarify what address space each has given out so far. This  
> would allow an understanding of what address space is in use and what  
> is not.
>
> Ruediger believes only the RIRs and IANA can and should do this.
>
> Andre Koopal (MCI) thinks the RIPE NCC should take the responsibility  
> of clarifying what they have allocated and what shouldn't be in the  
> bogon list.  Additionally, he thinks that IANA should define the list  
> of where the real bogons are, not the RIPE NCC.
>
> Daniel Karrenberg (RIPE NCC Chief Scientist) reminded the audience  
> that the RIPE NCC started this de-bogonising pilot because of the many  
> complaints they received from LIRs. There was pressure for the RIPE  
> NCC to provide some relief, to be seen to do something to tackle the  
> problem. There have been mostly positive reactions to the pilot  
> although at this stage it is more ad hoc relief than an actual  
> solution.
>
> Andre Koopal (MCI) wishes to see the pilot become a permanent RIPE NCC  
> service.
>
> Randy Bush (IIJ) would like an effort made to look at the problems  
> from the front rather than using ad hoc relief. He agrees with Geoff  
> Huston that the underlying data is weak, not well defined and lacks  
> proper signed distribution.
>
> Geoff Huston (TELSTRA) specifies there are approximately 2,000 entries  
> (out of approximately 210,000) whose data are unclear, most of which  
> are /24 networks. It is not clear if those records have been allocated  
> or not. This kind of data needs to be accurate in order to have a  
> trustful bogon filter.
>
> Kurtis Lindqvist (Chair) asked if something is being done to prevent  
> similar problems happening in IPv6?
>
> According to Daniel Karrenberg (RIPE NCC Chief Scientist) and Gert  
> Doering (SpaceNet), these issues with IPv6 have not risen yet. It was  
> not specified as a requirement for this pilot. Gert stated people are  
> filtering far too loosely with IPv6 and the problem is not the  
> prefixes not propagating, but garbage propagating everywhere. There  
> does not appear to be a problem with non-reachability due to bogon  
> filters. He asserts the problems discussed here are not evident in  
> IPv6. IPv6 has other problems.
>
> Gert thinks there may be scientific interest to measure propagation,  
> especially to counter mistakes made in the past with IPv4.
>
> Kurtis Lindqvist (Chair) posed the question to the audience: Would  
> there be interest to give the RIPE NCC a task to go to IANA to try to  
> clean up the data?
>
> Daniel Karrenberg answered that all the RIR's have this task already.
>
> Geoff Huston (TELSTRA) spoke that as a customer of RIR data and as an  
> operator he needs to rely on accurate data. The IANA and the RIR's  
> need to fixed the current inconsistencies. Currently within the RIR  
> communities information is published about address space in a number  
> of different formats; delegated files, Whois, RIPE NCC documents. They  
> are not all drawn from the same underlining database, they cannot be  
> because there is inconsistency, he said.
>
> Geoff believes it is worth the RIR's effort to have an accurate and  
> consistent listing of what address space is in use and what is not, on  
> at least a 24-hour cycle. Then people will know what to expect in  
> their routers. IPv6 or IPv4 makes no difference.
>
> Shane Kerr (RIPE NCC Software Manager) addressed the WG to say the  
> RIPE NCC are aware and have foundation plans to improve consistency of  
> registration data across the RIR's and IANA. However the current plan  
> is to wait until the ERX (Early Registration Transfer Project:   
> http://www.ripe.net/ripencc/pub-services/db/erx.html) is finished.  
> This would allow the RIPE NCC to clean up the data it currently holds  
> first before addressing the inconsistency problem.
>
> Nevertheless the RIPE NCC wanted to use this pilot to gauge from this  
> working group about how much effort should be spend on this because it  
> will be expensive in terms of cost and time to pursue it further. It  
> will take time away from answering requests for new IP resources for  
> example and Shane does not have a good feeling yet how much time the  
> community wishes the RIPE NCC spend on addressing this data  
> consistency issue.
>
> Kurtis Lindqvist (Chair) asked Shane if the RIPE NCC is waiting for  
> the ERX to finish, and if anything was being done right now to clean  
> the data?
>
> Shane Kerr (RIPE NCC Software Manager) explained how historically it  
> used to be the case that anyone could register anything in the RIPE  
> Whois Database at any time. There was never an effort to clean up or  
> make the data consistent in the past in a systematic way. Right now,  
> as the ERX proceeds the RIPE NCC are cleaning up the data within each  
> /8 systematically and once the ERX is complete the RIPE NCC will be  
> able to know that at least the data from those /8 blocks is good.  
> Shane confirmed that most of the garbage left resides in the 192/8  
> block. Historically this block is quite a mess.
>
> When the ERX project finishes the RIPE NCC would like to go back and  
> start looking at the data in the oldest blocks, 193/8, 194/8 & 195/8.  
> These are of the vintage 1993 - 1995 era. In order to do this however  
> it will take human beings going through old mail logs and files and so  
> forth.
>
> Geoff Huston (TELSTRA) felt it was worth the effort if the community  
> wants a secure routing system that is robust against determined and  
> professional attempts to abuse it. Filtering will not help. The data  
> must be trusted from the beginning. The people who can clarify what  
> address blocks have been allocated are the RIR's.
>
> Geoff went on to say the price of a secure routing system is  
> ultimately cleaning up the data first so reliable and trusted  
> attestations can be made about address space.
>
> Kurtis Lindqvist (Chair) agrees and sees this task as important as  
> making new delegations. The Bogon issue is important. It already  
> causes a lot of havoc, which amounts to cost to the LIRs. Kurtis  
> suggested it might be cheaper to clean the data up in the long run  
> than to leave it as it is at the moment.
>
> Leo Vegoda (RIPE NCC Registration Services Manager) explained that  
> some old last resort registries had passed their allocations to the  
> RIPE NCC.  However, not all of them had passed the documentation for  
> the assignments they had made.  This means that the RIPE NCC cannot  
> easily validate database entries.  Cleaning things up will take  
> considerable input from the operator community as well as the RIPE  
> NCC.
>
> Daniel Karrenberg (RIPE NCC Chief Scientist) agrees with Leo and  
> although he is RIPE NCC staff he also agrees with Geoff Huston that  
> this is the RIR's core business and time should be spent on this task.
>
> Ruediger Volk (Deutsche Telecom) agrees the data needs to be cleaned  
> and recommended to quickly setup RS set names or something similar  
> without delay.
>
> Kurtis Lindqvist (Chair) asked the audience if they do NOT think the  
> RIPE NCC should spend time and effort to try to clean up the bogus  
> data?
>
> - -Silence from the audience-
>
> As there were no comments, Kurtis said that this is clear consensus.   
> The message (apparently) is that the community wants the RIPE NCC to  
> spend time and effort pursuing the goal to clean up the registration  
> data. He acknowledges it is probably going to cost some money so he  
> suggested to possibly making a standard reporting item on the RIPE NCC  
> to report on the progress of this task and then cost and plans can  
> come from there.
>
> 48.3 Chair - Add standard agenda item to report on progress of data  
> quality.
>
> Y. Open Microphone
>
> - -There were no Open Microphone discussions-
>
> Z. AOB
>

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3

iQA/AwUBQMC/3KarNKXTPFCVEQLNFACdGfVf5KT9P7sAUQdQDOa1GQsu1HcAoOrb
2txNFr61R2YAVI7WImSZHVX/
=3ujt
-----END PGP SIGNATURE-----