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

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

RIPE tasks and the Board
by Bovio＠aol.com 14 Aug '03

14 Aug '03

Folks, I have carefully read the various postings on the list and I think it is time for me to step forward and try to help in answer/clarify some of the less informed opinions that were expressed. The RIPE/RIPE-NCC issue. Formally Gert is right, but to some extend also the people who say RIPE and the RIPE-NCC are the same thing are somewhat right too, it all depends on how one look at it. In the early years RIPE was some 15-20 people in a room 3 times a year, (almost only from research and academic institutions) trying to coordinate the European IP networks activities and operations. Among the matters at hand it was the need to get IP address space from IANA, and also the need to perform a number of related technical activities that would allow the embryo of the European Internet to grow and function. Soon it became obvious to these people that it was not possible to do that via "volunteers" work, but some dedicated staff was necessary. Shortly thereafter the RIPE-NCC was born, its purpose to get address blocks from IANA, to be distributed locally, and to perform all the technical functions deemed necessary by the community. Back then the relationship between RIPE and the RIPE-NCC was quite obvious to everybody, also because the people participating at RIPE meetings represented pretty much 100% of the "customers" of the RIPE-NCC services: RIPE would discuss and approve the policy to be implemented by the RIPE-NCC. RIPE would also provide input, discuss and approve the activity plan of the RIPE-NCC. As of today the RIPE-NCC still implement the policies discussed and approved at RIPE meetings (yes, yes, Randy, I am aware of the criticism that the process is not altogether transparent anymore), and still seek guidelines from RIPE about technical activities. The main difference is that no longer 100% of the membership of the RIPE-NCC attend RIPE meetings (but only some 10% on average) and that the Activity plan/budget/fees are formally approved by those members who show up at the AGMs. From this point of view, for the members who do not attend either RIPE meetings or AGMs, RIPE and the RIPE-NCC are perceived as the same thing, although formally they are not. (notice that if from now on the RIPE-NCC AGM is held back to back with RIPE meetings this will probably increase this perception). Most of the organizations that joined the RIPE-NCC in the last 3-4 years (and they represent the majority of the membership now) seem to have no idea of all the above, and only joined the RIPE-NCC organization because their corporations need IP addresses and AS numbers to sell their business and make money. They could not care less about attending RIPE meetings (short or long), conservation of Ipv4 address space, and all the policies that were discussed and approved for that purpose, nor for the various technical activities that go with it, to make sure it works, or to anticipate possible future issues and make the Internet a better place, all they want is address space (and they only want to pay for that, darn!), and quick, because every customer lost represent a step toward bankruptcy or toward acquisition by some bigger fish, so for them the RIPE-NCC is only a monopolistic obstacle to their business. As it was stated on the list: nobody has objection to what the RIPE-NCC has been doing or how its being done, its more an objection of the "forced" participation through the funding of the NCC which is completely unfair. I can see very well this point of view, and having been in the research world for quite sometime I can also see very well why, IMHO, it is flawed. Mind you, I am not stating here that the RIPE-NCC is lean and mean as I would like it to be, there is definitely room for progress, but I have to say I think it seems a very non-educated idea to me to split the funding this way. The Board-has-is-head-in-the-sand-and-does-not-realize-the-situation issue. Well, I can only speak for myself of course, but putting my board hat on I can tell you that I am very well aware of the fact that the Internet boom has caused, in the last few years, a gap between RIPE/the RIPE-NCC and its membership, and it took quite sometime to wake up and get the ball rolling to fix the situation, I plead guilty as charged here. I think, however, that a number of steps have been taken in the last 12 months or so to close the gap (the new proposed billing categories, the new algorithm taking in account Ipv6 and assignment dates to compute the fees, the survey, and this list being few examples) and more will be taken following member's input once we get it. As I stated already, anybody should feel free to approach us either at meetings, via mail, or by phone, all our data is available on the web site. Btw, I also welcome any proposal anybody wants to discuss and put before the AGM (and I do not see why anybody would not be willing to be seen "above the walls", anyway, what is he concerned about?), there are various ways to reach members and try to build enough consensus for that, via mailing lists (this one for instance), or just by looking at the web site, the full list is available there. In conclusion I can assure everybody that the board is carefully listening in the discussion and has the highest interest to follow and implement the willingness of the majority of the RIPE-NCC members. Cheers Daniele

1 0

Re: [ncc-services-wg] RIPE tasks
by Axel Pawlik 14 Aug '03

14 Aug '03

Neill, all, First of all I must say that I like the fact that the new RIPE NCC Services Working Group obviously is taking off :-) With regard to the repeatedly stated opinion that the RIPE NCC management, and the RIPE NCC Executive Board are unaware of the members' opinions, and needs, I am convinced that those members of the community who have followed the events, presentations and planning discussions of the last year (from the conduct of the membership survey 2003, the move of the General Meeting to the Friday of the RIPE Meeting, and through to the proposal of the Activity Plan and other documents in preparation of that General Meeting), know full well that we are very aware of these concerns, and that actions continue to be proposed, and are taken where approved, to adjust activities to the expressed need of RIPE NCC members and stakeholders. The existence of this Working Group and mailing list in itself is just one minor outcome. The point of "Just Registration Service" is moot. As we all now, the industry has changed. Well, actually the running of a geeks' network instead of the politically correct technology has *become* the industry before that. And thus has attracted all sorts of people, politicians, lawyers, bureaucrats, the lot. We cannot go back to the old days of just registering numbers. The risk is high that one day we would awake to the ITU doing Internet Governance. "Please see your local MP to effect a change in IP allocation policy, to be discussed at the next plenipotentiary of the ITU." We need to do more, to establish the RIPE NCC in the minds of politicians, journalists, "the public" as a trustworthy place you can turn to to gain insight in the operations of the Internet. About the RIPE meetings: They are crucially important to the functioning of the RIPE NCC, and of industry self regulation. Yes, they should be self supporting, but they aren't fully. Can we raise the meeting fees? Of course. But we need to balance this very carefully, as we cannot run the risk of eating into attendance numbers too much. regards, Axel

6 8

E-mail list removeal
by Mark Brett 13 Aug '03

13 Aug '03

Please remove mark(a)brett.com from allo f your lists asap. Thanks. Mark Mark Brett Tel: 0208 529 8614 Mobile: 07720 101 733 PO Box 6733. Chingford, London. E4 8UD

2 1