- ncc-services-wg - mailman.ripe.net

Re: [ncc-services-wg] RIPE tasks
by Bovio＠aol.com 25 Aug '03

25 Aug '03

In a message dated 22/08/03 18:44:28 W. Europe Daylight Time, woeber(a)cc.univie.ac.at writes: I am working from the assumption that the bigger community (RIPE - which includes the rep.s of the Members!) develops and agrees to the activity plan, the NCC Members approve and agree to paid the bills, and the managing director is expected to make it happen, with whatever it takes. Operationally, I always saw the Board as a "background" group, which focuses on keeping the safety belts in good working condition, and to take care of formal responsibilities of the Association, as well as providing guidance to the MD. At the time when I was on the Board, we were very reluctant to interfere with the day-to-day management of the NCC. As this is a memory of the past, things might have changed. Probably something the Board should comment on. Wilfried, A quite good summary, and yes, this is still the case: the board does not interfere with the day to day management of the NCC. Daniele

1 0

Request Forms: updated and available on LIR Portal
by Dominic Spratley 25 Aug '03

25 Aug '03

Dear Colleagues, The RIPE NCC is pleased to announce the release of new request forms for IPv4, IPv6 and AS requests. To make the request process easier, requests can be completed and submitted directly from the Tools section of the LIR Portal. This also provides real-time syntax checking and help. https://lirportal.ripe.net/ Text versions of the new forms and their supporting notes (with examples of completed requests) are available for download from the Document Store found at: http://www.ripe.net/ripe/docs/internet-registries.html#request The new forms can be used immediately. The old forms can still be submitted during the three month transition period ending on 19 November, 2003. If you have any questions on the new forms, please contact <lir-help(a)ripe.net>. Suggestions for improvements to the new forms on the LIR Portal are welcome at <lirportal-feedback(a)ripe.net>. Improved and new functionality is planned for future versions. Kind regards, Dominic Spratley Registration Services Manager RIPE NCC

4 5

Re: [ncc-services-wg] RIPE tasks
by Wilfried Woeber, UniVie/ACOnet 22 Aug '03

22 Aug '03

Kurtis, >To some extend this worries me a bit tough. We are actually taking >power away from the board members that are actually elected to >represent us. this is an interesting line of thought! I am working from the assumption that the bigger community (RIPE - which includes the rep.s of the Members!) develops and agrees to the activity plan, the NCC Members approve and agree to paid the bills, and the managing director is expected to make it happen, with whatever it takes. Operationally, I always saw the Board as a "background" group, which focuses on keeping the safety belts in good working condition, and to take care of formal responsibilities of the Association, as well as providing guidance to the MD. At the time when I was on the Board, we were very reluctant to interfere with the day-to-day management of the NCC. As this is a memory of the past, things might have changed. Probably something the Board should comment on. This would still be "representing us", but it might be slightly differnt from what you read into "represent us". It might indicate that you expect the Board to interfere on a more regular basis with day-to-day management? Otoh, we might still be completely in synch! >At the same time, with the numbers of attendants that >Axel posted, I am still worried over the lack of interest from the >community... Well, even a decision for a country to join the EU - or not - has problems to attract the interest of >50% of the electorate. And, the cost of attending an AGM in person, or to do it via remote participation (keeping in touch with meetings, minutes, discussions, manpower-wise throughout the whole year...) might be just as costly as the annual membership fee (or at least as the percentage of that which might get cut off, if you object to some issues)? >- kurtis - For me _one_ major (but maybe not _the_ only) problem is feature creep _in the address distribution policy_, and it's implementation by the NCC. Some of you might recall my comments about the cost of micro-management of /29s, resource reclamation discussions, and the like... Btw, I am glad that we (again just a small minority! And it would just cost a bag of recycled electrons for an email ;-0) have started to actually discuss things! Cheers, Wilfried.

1 0

Re: [ncc-services-wg] RIPE tasks
by Wilfried Woeber, UniVie/ACOnet 22 Aug '03

22 Aug '03

>I think a more often KPMG like survey is more of value than forcing the >RIPE NCC management and staff live under quarterly stability. . putting the NCC into instability mode is going to hurt all of us eventually (but may be beneficial for a small minority for whatever reason) . may _I_ then, in the interest of preventing waste of _MY_ LIR's money, voice a strong objection against _that_ waste of money _and_ human resources at the NCC!? >That is >how large listed companies operates. I think the NCC have a bit to >before being there... Yes, and we all have seen the results for the well-being of quite a few companies in quite a few sectors of teh industry ;-) >- kurtis - Wilfried.

1 0

Re: [ncc-services-wg] RIPE tasks
by Wilfried Woeber, UniVie/ACOnet 22 Aug '03

22 Aug '03

>I don't to objections preceding the discussions of the budget >decisions, on the contrary - that is the idea with this WG. This is not only the idea with _one_ WG, this is a general concept which we (many chairs) tried to put to work for a while throuighout the _differnt_ WGs. I have to admit that _I_ have ceased eventually to put it onto my WGs agenda again and again, because I usually saw a few heads nodding approval when an activity (or it's continuation) was proposed, and no dissent. Maybe we should put it again onto our agenda(s) as a standing item... >However, >the decision needs to be taken by the NCC membership alone, and not in >a public forum. The public forum is there to work on general consensus, and to gather up all the input from the community at large. The final decision - which usually is to simply agree on the proposed workplan AND TO FOOT THE BILL - rests with the LIRs who are going to see the invoices coming. >This is the AGM. Exactly. >Best regards, > >- kurtis - And I am still pretty convinced that this is a good structure and the proper way to do it! Wilfried. (for at.aconet's EUR, and the DB-WG)

1 0

Re: [ncc-services-wg] Unneeded RIPE tasks
by Hank Nussbacher 22 Aug '03

22 Aug '03

http://www.ripe.net/ripe/draft-documents/ap2004.html Section 5: "Incident Response Service (IRS) Procedures will be set up to quickly provide RIPE NCC members, the Internet community and the general public with authoritative data about unusual events on the Internet, such as DDoS on the RIPE NCC." Yet another unwanted and unneeded service that is handled quite well by many other organizations whether they be FIRST or nsp-sec or INOC-dba or Terena's CSIRT: http://www.first.org/ https://puck.nether.net/mailman/listinfo/nsp-security http://www.pch.net/inoc-dba/ http://www.terena.nl/tech/task-forces/tf-csirt/ No e-voting. No informal poll of what services are needed. RIPE NCC just keeps rolling along. Based on: http://www.ripe.net/ripe/draft-documents/budget2004-aoa97.html 2004 2003 2002 Total Expenses 10,263 9,811 10,442 I see no major cost reductions. Poll any of the 3500 LIR members and ask them what their budgets look like in 2004 as compared to 2002 and 2003. The problem is (and I know other NGOs in similar situations) that NGOs lose track of what is going on out in the real world and therefore feel that they have cut the budget if it is reduced 2-4%. The other problem is the apathy of the LIR members. 3500 LIR members and 95% are silent on the RIPE lists. Their employer doesn't pay them to sit on these lists. They pay them to get IPs and ASNs. A 10% reduction in membership fees - which would save perhaps 250-500Euro per year, is not worth fighting about, their employers didn't ask them to save them the money and such a small savings is noise to most budgets and not worth the manpower needed to argue and fight to get it changed. Looks like we are stuck with the status quo for a long time to come :-( -Hank

1 0

Fwd: [db-wg] X.509 authentication in the RIPE Database, take II
by Joao Luis Silva Damas 20 Aug '03

20 Aug '03

On Friday, August 15, 2003, at 04:23 PM, Shane Kerr wrote: > Joao, > > Joao Luis Silva Damas wrote: >> adding a new strong authentication method to the Database, is in my >> own personal opinion, a good thing(tm), particularly if the same >> credential can be used for other interactions with the RIPE NCC, make >> user's life easier. >> I wonder however about a few questions: >> - will this auth method be available only to RIPE NCC members? Is it >> not seen as a valuable general addition for non-member users of the >> IRR part of the RIPE DB? > > Initially it will only be available for RIPE NCC members. Another interesting change in the model? When you say initially, does this mean it will be extended or not? Shall on read the current proposal as implicitly stating this? > There are three ways we could extend the service to non-LIRs: > > 1. Accept certificates from certain "well-known" CAs, for example > Thawte, Verisign, etc. > > 2. Issue certificates from a RIPE NCC CA established for this purpose, > and accept them. > > 3. Accept all certificates, including self-signed certificates. > > #1 is relatively easy - the main overhead would be maintaining the > Certificate Revokation Lists from the CAs. Deciding which CAs to > support may also be tricky. #2 is also relatively easy, since we > already have the technology. #3 is more difficult, and would require > a slight change of the design, and administration issues (see below). For DB authentication purposes, why do you need to verify the certificate? As with the PGP model[1], the only assumption one needs to make is that the message issuer is the holder of the private part of the certificate. If the RIPE DB is going to start making assertions about the real identity of the message sender, rather than just authorise or refuse updates, this seems to be a change in the model that warrants discussion in the working group. Is this so, or am I misinterpreting your description of the mechanism? > >> - Why the choice of not publishing the pulic part of the certificated >> in the DB? The choice to have a key-cert for the PGP method was not >> to do with issues of web of trust but rather for purposes of helping >> the users with their data maintenance. As a matter of fact the >> recommendation regarding the use of PGP in the RIPE DB, as described >> in the RFC and the minutes of the DBSEC TF, was to use a PGP key for >> this purpose that was not used elsewhere. > > When you receive a PGP-signed message, you need the public key of the > signer to verify the signature. The program that updates the Database > needs this information, and it is stored in the key-cert objects(*). > > With S/MIME, the certificate is sent with the message, and this > certificate is signed by the CA. Since the database is configured to > know how to verify certificates issued by specific CAs, we can verify > the signature. No key-cert is necessary. > > But if we decide to allow any certficate, including self-signed, then > we need some way to allow users to store this information in the > database, for example key-cert objects. Unfortunately, this may cause > problems, because (for instance) someone could create a key-cert > object for a CA run by another organisation with bogus data, > preventing users from using certificates *actually* issued by that CA. > > We could possibly require these sort of key-cert objects be reviewed > by some method, for example RIPE DBM. However, if the RIPE NCC has no > relationship with the CA, we have no real way to know the validity of > any one request. Why do you need to verify the certificate. Also, part of the idea of having a key-cert object was to allow users to check, not the DB, and to maintain DB self-consistency. Are these no longer desired features? Joao [1] RFC 2726

3 2

Charter
by Kurt Erik Lindqvist 20 Aug '03

20 Aug '03

All, I called for volunteers to help me write the proposal of the charter some weeks ago. My plan was to get this done while I was on vacation, and once back take it to the list. Unfortunately the laptop-gods where against me and my laptop crashed. So in order to save some time, I will take the charter directly to the list. My apologies to all those that volunteered, and many thanks for offering to help out. Attached is my rudimentary proposal. Please feel free to comment! Best regards, - kurtis -

1 0

Proposal: Reduction of RIPE-NCC Actvities
by Peter Galbavy 20 Aug '03

20 Aug '03

OK, I have had off list support from people who are maybe not quite willing to be seen above the walls (yet). I would like to put a proposal before the annual meeting - which I will NOT be able to attend personally. Is anyone else willing to carry this in my absence ? Let me guess, too late for this year... The core of the proposal is: -- It is proposed that the RIPE-NCC (a) immediately cease all activities not directly required for the management of those registry functions necessary to the continued well being of the Internet in Europe and other related territories, and (b) undertakes a program of rationalisation that reflects the ongoing commercial consolidation of it's membership while maintaining an efficient and adequate level of service. -- I want help with rewording (b) above. It is not quite right. i.e. "feel the pain" instead of "gravy train". rgds, -- Peter Galbavy Knowtion Ltd. uk.kml

6 8

X.509 authentication in the RIPE Database, take II
by Shane Kerr 15 Aug '03

15 Aug '03

All, [Apologies for duplicate e-mails] Attached please find a proposal for X.509 authentication in the RIPE Database. From the Database point of view (that is, syntax and semantics), it is the same as the one sent 3 July 2003. The difference is that it contains only the specific details of the change, in a straightforward fashion. I hope that we have addressed questions about the use of X.509 that arose in earlier discussions. -- Shane Kerr RIPE NCC Addition of X.509 authentication to the Database Proposal: To add an X509 authentication type to the "auth:" attribute. Attributes with this type will use the Distinguished Name (DN) of the certificate to identify it. Motivation: X.509 allows a single authentication method to work for both e-mail and the web. LIRs can receive an X.509 certificate through the LIR Portal, and should be able to use this to update records they control in the Database. X.509 is "strong", like PGP, although a different trust model is used. Details: The "auth:" attribute of the mntner class will have a new authentication scheme, X509. The DN, as defined in RFC 2253, will be used to identify the specific certificate used. Note that there is no key-cert object for the X509 scheme. Instead, the certificate must be signed by a trusted authority. The trusted authority will be the RIPE NCC Certificate Authority (CA) that is currently only available to LIRs. It is possible to configure additional CAs in future, should this become desirable. For instance, existing commercial CAs could be allowed, or the RIPE NCC could create a CA to issue certificates to non-LIRs for this purpose only. Below is an example of a maintainer with X.509 authentication: mntner: EXAMPLE-MNT descr: Sample maintainer for example. admin-c: SWK1-RIPE tech-c: RD132-RIPE tech-c: HOHO-RIPE upd-to: ripe-dbm(a)ripe.net mnt-nfy: ripe-dbm(a)ripe.net auth: X509 C=NL, O=RIPE NCC, OU=Members, CN=zz.example.user1 auth: X509 C=NL, O=RIPE NCC, OU=Members, CN=zz.example.user2 notify: ripe-dbm(a)ripe.net mnt-by: EXAMPLE-MNT referral-by: RIPE-DBM-MNT changed: ripe-dbm(a)ripe.net 20030813 source: RIPE Usage: E-mail updates for objects maintained by a maintainer with X509 authentication must be sent in S/MIME format and signed (not encrypted) using the private key associated with the issued certificate. Synchronous updates for objects maintained by a maintainer with X509 authentication must use an SSL connection using the private key from the issued certificate on the client side. Web updates for objects maintained by a maintainer with X509 authentication can use a browser with the certificate loaded. The web updates screens will allow users to specify that they want to identify themselves using the client-side private key, over an SSL connection.

3 3