**
(A few minutes missing from start of this session............our apologies.)
SPEAKER: You have seen the presentation probably that Philliz gave yesterday, we have been dealing over the last few months with I think 14 policy proposals, it was 25 slides or something of that order. I won't go into any details here apart from apologising, I thought for a long time, oh policy support is policy development support is easy, we do that 30 minutes within the week or so, or maybe even 30 minutes a day. Oh, it's more work. And I think it actually works quite well, and Philliz and I are doing a fairly good job. So apologise. You do work more than 30 minutes a day.
Training. Lots of courses out there, different courses in different countries going to these countries soon. We have started to also do little media clips and one of them is running at the end of the corridor there. Basically to support training. We /PAO*EUT piloted that in house for ourselves but also we make that public available where appropriate. For the rest of us. We have been around quite a bit, and I think not just this year that sort of over the past would be right. And we are quite proud to have been to by far the most untrees in the region and there are some left and we would be happy to go. (Countries)
Right. Speaking of training, we have been going around quite a bit. We have been talking to many different people, our members. As, you know, we do regional meetings in Moscow and also in the Middle East. We have been going to IGPs, we have been talking to lots of governments, we do round tables and there is a question that we here frequently: What are you doing with regard to IPv6 training? You are the RIRs, basically goes to all of us of course, but RIPE NCC you are talking about the exhaustion of IPv4 and what are you doing in helping us and helping the operators and whatever to do IPv6� to do IPv6 deployment. Do you do any training? And then we say, yeah. So my question to you is, is today, what are you doing if you are our members here? Are you doing any significant training for anybody in IPv6? Because the question, obviously, is or the issue, obviously, is that yes, of course we would like to do some sort of IPv6 training here but we fear, again, to tread on our members' toes because I am quite sure that some of them might be doing something like that. So, we can't get away from this. There is obvious need for this, certainly in some regions, in some areas. So the question is what should we be doing and I would like to get some feedback from you on this question either at the end of this or maybe in the general meeting or doing during the rest of the week. We have been looking at this and said yes we can do something that doesn't embarrass us and get in the waive our members. IPv6 resource repository where we link and list quite a number of resources. For instance, trainers training activities, by various parties in our service region or should we go and do extra training ourselves, should we do that all of ourselves region or go to places where our members don't do things like that, for instance maybe in Russia. So, that is an open question and we are very interested in getting some feedback.
Going through the operational departments, again, business applications; basically, we have done some updates of software, of interfaces that you are using, application for ourselves (URL) also we want to neighbouring easier for ourselves to bill you properly and to have it all in a nice packet. Certification is the smallest on this slide but probably the biggest in the group in terms of priorities. We need to get this out and properly done and it works quite well. You will see after this talk here. Plans for next year: Continued certification, LIR Portal is now relatively old and well established but we want to put it up a bit and add some functionality and make it nice and make it work. Software for running RIPE meetings and invoicing there and stuff like that needs to be done. And in general, improvements for registration services, that is always also high on the request list so we need to get that done as well. Switching to database, quite a number of action points from various RIPE meetings. We have done quite a lot of that. The happy news here is that our services here are pretty much available all of the time, which is something of course that we strive to� we have occasional power fails our here and there. We try get around this and have services nicely redundant but it looks good as it is now.
Whois queries in terms of statistics: Yes, it's rising, it's good.
There is more. I am not sure that this slide gives actually that much information apart from being very colourful, and of course yes the number of or the number of requests from various countries over time changes between May and September, Germany was very� becoming very curious, you know, the US dropped down a bit, I don't know. It looks pretty good. K root, DNS services we are running one of the, how do we say that, one of the 13 root server clusters and we do that in 17 incidences for K. The peaks that we see in queries about 20,000 Q /1 and some of that provide service over IPv6 and you see if you can read that, if you can read it, that the peaks that we see there peak out at 200 Q /S per second, that is not much compared with v4, well no surprise well. Secondly service for ccTLDs, we have been asked to be careful and not again tread on the toes of some of our members who provide a similar service commercially. We still do this and we commit to continue to do this where it is necessary on a best effort basis free of charge for developing ccTLDs, basically. We have phased out quite a number of bigger more developed and, let's say, commercially viable is is a funny Word in this area, but people who could pay for the services there. And we will continue with this as long as we are not hitting any really small developing ones. Give us feedback if you think it's enough now or give us feedback if you think we should continue until we got rid of most of them.
ENUM, it's slowing down, no new requests there since last RIPE meeting is available in the ENUM tree now, it's all stable and good.
Information services, we said in Berlin that we would implement a new alarms framework. We have done that. Single sign on, basically what we are trying to do here is to combine all those services into one big, big package of services, so that you don't have to go� it's more intuitive to use and that goes into that. House count, we have presentation about that later on, basically we strip the old stuff and new Hostcount only. TTM, test traffic, we have talked to APNIC also in an attempt to widen our probe base there somewhat and they are interested in doing similar things, so we have one new probe in Brisbane and they are developing our partnership with APNIC.
Comes into coms and regional� membership here, well, I have said so earlier, we have we were hoping to get 6,000 members or still hoping, 6,000 members by the end of the year. Many of those new members especially are coming from the greater Russian region and also here from the Middle East so we continue to go with regional meetings, basically giving updates from the RIPE meetings (Russian) to the regional communities and that is received very well.
Membership survey: You might have seen or you should have seen a mail that went out a few hours ago, a reminder to fill in our membership survey. That thing has started to two weeks ago it was announced two weeks ago. Within the first week, we got 275 responses and the up date I received also a few minutes ago, it's now by 280 something responses, I must say within two weeks that is a bit sad. We have nearly 6,000 members. I want to get 10 percent feedback, please give us some more. If you haven't filled it in, do it� maybe do it here, while you are here. While you are waiting for the social to start this evening. And you will find it there. And of course, it's not us doing it, it's an external company so everything is all anonymous and gives us good information about who filled in what. As your service organisation we rely on this so please, please do that.
PR, public relations, we hired eventually a PR agency which is based in London, I mentioned that earlier, I think I D it's going very well (London). We did lots of� quite some campaigns, actually on Monday, Sunday, whenever we started, Sunday here, Blaise was quizzing me every five minutes for the afternoon and had another journalist for me to talk to, which is interesting, different. And we do see quite a bit of uptake in the media on things we are doing, v6, long ASNs in general the RIRs and state of the world there. There was support also with the for us for the OECD together with the other RIRs, press releases for the ITU events in Asia and Africa and now we are moving into information services, also to package that stuff better so that it's an idea that is out there, information service of the RIPE NCC, yes, that is something that we can use.
Governments and enhanced cooperation and the like;, you know, we have the cooperation Working Group now which is brilliant, and that will happen later, this week, and this is a very good thing, we mentioned that at the round table that we did recently and we are talking about this where we are going, governmental people are around. This has the potential to really help the community, of course it's a mutual thing to help the governments as well to understand us better. It's lovely. OECD, I am pleased to say that they discovered that we are just around the corner, not in Paris but in Amsterdam and they started asking us interesting questions in preparation for their ministerial and that has been picked up, basically, the activity of supporting the OECD and getting together with those kind of economists also and other parts of governments, so that was a great success and there was a move to bring in something that involves the Internet technical community on a formal level with the OECD and for some years already they have the business advisory group there, committee, I think, so we formulated a proposal, together with the Internet technical community partners that we have, ISOC and ICANN and the like, saying that (ISOC) we think that we should have and� we think an Internet technical advisory committee there formally established at the OECD which will be discussed in the WPICP, what does that mean? He didn't know, he went there and he had forgotten already. Working party information computer and communication policy, which we went to last December I think and we will go again this December. It's communication, it's great for us, it's interesting for them. Round table for governments, we had another one in Amsterdam last September, just a few weeks ago really, and we did a bit of form there to fill in and give some feedback and basically, the people that came by majority found it so useful that they want two of them per year, and Paul is very exhausted and looking forward to doing another one, as is.
Internet governance forum, it's going to happen, it's gelling quite nicely in terms of what is going to happen in the big sessions and also in the working groups. We will go there. It is in December and we will do some more talking to our friends in the governance. And not only to our friends.
Preparing for the future. Yes, we did have quite a number of workshops internally and also with our board in strategic areas, basically looking at or trying to look at the future, what we can see from here, and obviously, yes, there is an issue with IPv4 and that is interesting because much of our let's say business model in the RIPE NCC is based for years on allocation of IPv4 addresses, so if he don't do that any more, what else would we do or how do we deal with that situation? Yes, for the preparedness of possibly and likely changes in the environment, I say. Basically, we have identified three main areas of attention� three strategic areas that we need to work on to� to have this organisation, the service organisation for you continue its work. One is the role of the RIPE NCC and we look at this in terms of community building, outreach, doing more PR and what we had originally there, the title was defending the role of the RIPE NCC but then we thought that looks very defensive about, we want to be more educating and out reaching. Now, the other term that we sometimes use is evolving the role of the NCC and I didn't put this on the slide, I am just talking about it becausy involving might mission /KRAO*EP that is not what we mean. It's talking about the role, getting feedback from you, what should we be doing and� should we not be doing. Trusted source of data. Right, we are supposedly the authorities on allocation of numbering resources. We have a registry, we have the registry, and we need to make sure that that is and� Daniel talked quite a bit this morning already, that that is correct, we want to build new better reporting tools that use that registry. Not only for us and not only are you also for oh law enforcement comes into action there. Actually, there was quite a big number of law enforcement agencies, basically police of course, at the round table for governments and regulators, so that was a first, a specific user group from that area turned up there.
OK, third main strategic area, number resource life cycle management, of course includes certification in a big way, but basically it completes cycle of allocation, auditing reclamation where it's useful and certification.
Right. Speak being that, yes, we will have a demo here. We still want to role this out next year on a production level. If you have an interest in this and I hope you do, please consider joining our testing group.
Right. And then we had some extra items and this is more or less general meeting stuff, from the last RIPE meeting from the coffee breaks but also from members at the general meeting and also of course from the policy Address Policy Working Group, the PI space holder agreement we should write up which we have done and we will talk about this in a few moments in that room. Charging scheme that includes those PI holdings in some way, yes we have done that, next room. And RIPE NCC associate member scheme that was talked about, yes we have done something like that. And again, associate members� we call them supporters, basically people who want to give us some money because they like what we are doing without being a member. Well. And should change the articles of association. We have thought about that, also. We have worked with the board on that and also expect to us talk about that in the next room. And I think that brings me to the end. If you have any questions, now, please you are welcome.
Kurtis: Thank you Axel. Any questions on the presentation? Or any other questions?
Rudger: Axel, for your V /# what should we be doing, question, question back; do you have kind of some data about what education resources are available. Your question, what should we be doing, will it be sufficient to set up a repository of stuff or do we need to do something prompted for me. The idea if doing a repository, doing� giving pointers to people, would be obviously kind of a first step and doing that would actually provide an information basis for you and others to decide whether something needs to be added.
SPEAKER: Of course. That is a good point, yes, that is of course something that we have just will do. That makes sense. That doesn't get in the way of anybody actually that promotes possibly services that our members are already offering in some areas. With regard to manpower and resources, I think we have some available that would take this on. Of course, the question is how much is the demand, should we have to add there or not. I do know that womby is not getting on our nerves for quite some time, there are people out there talking to our members and other training courses and they get the question all the time, and we have said� that is� no we don't want to do that but seeing we do get the question in other areas, yes, we will do something. And it's up to you to tell us not do too much or not to do it in your own yard.
AUDIENCE: Government, it's not just our members, Axel.
SPEAKER: Yes, yes.
AUDIENCE: Who are you.
SPEAKER: That was Paul.
AUDIENCE: Training manager at RIPE NCC we did do indeed some research in the region and we found that especially in the Netherlands, the UK, Scandinavia, Germany, there are indeed quite a lot of IPv6 courses, but in, for example, the Eastern European Countries there are none and my trainers travel around the region a lot and as Axel mentioned they get the question all the time: Why haven't you been doing any training yet? And we get really conflicting input and feedback about this from the community, some people tell us no you shouldn't do it because you will be competing with us us and others tell us you should be ashamed you are not. So this is why indeed we would like to hear your opinion and also I would be very interested in hearing your thoughts about if you think we should be doing training, what type of information do you want us to cover in there because obviously we wouldn't be doing it too technical, we think that is up the hardware providers or vendors to do proper technical courses. So anyway, if you have strong opinions about it I would really welcome your thoughts about it and you can send e mails to Rumy @ripe.net myself, imR U M Y @ripe.net. You can send to to training @ripe.net. It's easier to remember.
CHAIR: All right, thank you Axel. So next on the agenda we had Tim.
Tim: OK. I am here to give you an update on the certification beta programme that we did in the RIPE NCC, I am one of the people in the development team. And I just want to start with some background on this whole thing. So these are the topics I will be addressing: Driving forces behind all of this; introduction on some of the concepts because you may not all be familiar with that; something about what is in it for you, how would you use it; a demo of what we have done; and a look into the future, and there will be some room for questions.
First of all the driving force, this has been discussed in the IETF, in one of the working groups, this is where all the concepts are really defined and agreed on and written down. Within the RIPE region, we have the certificates authority task force that looks at how this can be applied in the RIPE region. Coming out of that are discussions, ideas, policy proposals, some of which you have seen already. And this beta programme is also done by request and endorsed at least by the CA TF.
Development for this started about a year ago. The focus is very much on those fields where agreement has been reached in the IETF and CA TF task force because there is a lot of discussion still ongoing about a lot of stuff that we could also be doing but we are looking at the stuff where we have� yes, the services like I said already, and also where we believe there may be immediate benefit for our members. I want to start simple, if you look at functionality, we want to start with simple functionality that you can use and evolve at an early stage and keep extending that.
A little background: Resource certificates, what are they? Well I don't want to go into the PKI world too deeply, but, in general, you can see them there. It contains some information, a public key, resources, IPv4, IPv6 and AS numbers, and the signature. What they essentially say is consider the owner of the corresponding private key to this public key. The holder of this is resources, because, well, in this case the RIPE NCC said so, because they signed it. When you look at that, it's foreign notice that the certificates only contain public information, so if you have a certificate which with your resources on it it doesn't really say well, I could show you a certificate and say it's mine, I mean there is no way for to you tell, really. It doesn't really attach to the� attest to the identity of the certificate holder. But it's not entirely useless either because you can do stuff with the certificate and that is where it's powerful. The private key is the real thing here. That you can use to sign specific types of objects and people that look at those objects can validate them, they can verify that the party that signed this is an actual holder of these resources. The resources mentioned on this object. And right now there is one such object where consensus has been reached that we have also implemented. And that is called a route origin authorisation object. This contains, well, the following items: An AS number, a number of IP prefixes and a signature. And what it's actually saying is, allow this AS number to originate the IP prefixes as mentioned here because the signer, in this case the legitimate holder of the resources, said so, because a relying party can look at this object and follow the pointer to the certificate that was used to sign it with, that would be your certificate, and they can follow the pointer there until they reach up to the chain a trust anchor. So I hope that was clear enough as a background and otherwise we can make address it in the questions.
Right, what do we think is in it for you? Well, automated provisioning and global standard are nice buzz words here. I will go into that in a minute. Possible future applications may include resource transfers and secure routing.
Automated provisioning. Well, imaginary company, I hope it doesn't exist, megacore and blue site ISP are dealing with each other. Megacore wants to ask blue light to route some of their network. OK, this isn't really network but as an example it should be OK. Well, blue light will have to do is figure out whether actually the real holder of those resources because they don't want to be doing stuff that, you know, is not normal. Right now that means blue light would have to go through quite a bit of detective work, OK maybe trust each other but essentially (detective) there will be quite specific knowledge here and manpower needed to verify this request. And a solution could be to use ROAs. Same start, please route my network, same question, are they really the holder. With ROAs, blue light ISP could say please sign me a ROA, this is my AS number, sign it with your resources, megacore can do that. It's published and blue light can just look at it and validate it. So and then they know that the request was actually valid.
About the global standards: A comparison is made often with whois like databases but we are talking about a different thing, I think. It's quite restricted to specific problems here. But it is using global standards, so (databases) APNIC, ARIN, LACNIC, AfriNIC who is working on this is using the same standards and if you look at a certificate that was signed by the RIPE NCC it should be of exactly the same format as one that is signed by one of the others. And as such, also it's important to note it doesn't replace the database in any way; it complements it with secure information.
Time for the demo. If I full screen this. To use the example, blue light ISP ask megacore to make roll out to start using certification. First thing they would have to do is ask, well, in this example ask to certify their resources. A key is used for this, I don't really want to go into too much detail here but it's used by the cryptographic engine. (Key pair) sorry. This was too small to see. I can increase the font size a bit. OK. So, the initial step has been taken, a key has been generated, it's been used to make a certificate with and resources have been certified. Now, using the ROA specifications, well, there is a lot of text here, essentially what you can do is make a configuration item if you will. You don't have to deal with all these signed objects directly but the system takes care of all the hard work for you there, at least that is the idea. So how you make one, you make� give it a name, that makes sense to you. I believe this is and I specify a prefix. Maximum length is optional; if I leave it, it will default to allow this prefix to be routed as is. If I give a bigger number, for instance 16 it means that nothing more specific than a 16 may be announced. Validity times can be specified and in that case the system will ensure that already no valid objects before and after that time, but if you don't do it it will just keep regenerating the objects as needed so there is always valid. OK. So we need to do a little work on the validator there. Now I have generated the ROA specification and a ROA object has been made as well. You can view it. This is a representation on screen of the thing itself, you can download it, but clear text, it doesn't really make sense, it's not intended to be looked at by you and I. What it lists is an AS number, prefix, in this case a validity time that is now tied in with your certificate of authority validity time, but as I mentioned, when it is renewed you will get a new ROA object as well. If you look at the details, well, you can see that it was issued by some certificate, which was you, and you can see that that certificate has been issued by a trust anchor. What else can I show you in this stage? OK, there will be a public repository. For now, we have made it, lists all valid ROA objects in the system, but in the real world these things are published and behind an R sync repository where they may be downloaded, not just ROA objects are published there, but certificates, revocation and lists what have you. Another thing we have been working on is the keys. You can see it still has an ALT key here because it's good practice to perform a roll over once in a while. It may well be we all the irNate this for the system at some point because maybe you don't want to worry about this kind of thing. On the other hand if you do, we don't know, we have to see what people come back with in the test group. In any case what, could do is key pair roll over. You have to make a new key then. And what happens is your ALT key is� gets statusality and new is current. The current key is the one used to make new certificates with, new ROA objects with. There is a revoke link here, that can be used if you suspect that a key bearer has been compromised, if someone has access to your private key then that wouldn't be very safe because they could sign your objects, right? And that is why you can revoke an ALT key. When you do, everything that has been signed with it will be revoked, will be invalidated (ROA key). Ideally, of course, your key pair doesn't get compromised and you shouldn't have to do this yourself. Also maybe you shouldn't have to do this key pair roll overs yourself but at least we have to show this functionality is in place so that is why you see it in the demo now. One final thing is this link, updates certificate. You can also for updates for your certificates, the certificates are continual resources. If I click it now then it will� this is what it should say "certificates have been updated." If I click it again "no updates were necessary." Why is this, because of the validity time in this case, I think. Yes. It will only update if validity time for your issued certificates or if the resource that you get certified are changed, otherwise it will just keep using old one. One last thing about the demo application is the welcome screen I suppose. We make, do a release every couple of weeks, four to six weeks I would think, and we list all the new things here. There is normally a screen cast that highlights all these things. There is a mailing list that people that are using a test system are on, where they can discuss matters. And yes, that is it, really, what I wanted to show here.
So let me get back to the presentation. How we got here; quite a bit of work went into this. We had an initial release at end of June that had basic key and certificate management, so what you could do is generate keys and make certificates with it but it wasn't really useful, didn't present any value other than it worked.
At the second release was introduce ROAs and it had a web based ROA repository where you could view these things and this release had quite some major changes it, introduced the new key pair management where you could have one link to do a key roll over, you had proper certificate and roll over repository, or well a repository and that has been validated with an independently developed tool. And it all works, so that is really happy with that. (ROA)
Look into the near feature, we want to go to a production system but as you have seen, what I did now was a user name password based log in and that is� that would be quite a weak step in what should be a very secure system, so we want to improve that with� using stronger user authentication. The first bullet is more about key management. Right now, we are using keys that are software generated keys and stored in a database and that is all good for working out a functionality but it's not good for a production system, that has to be much safer. This is specialised hardware for this, hardware signing modules, they called, generally, and we want to use one of those, so your keys would be safe in that. Integration with having our portal or at least some kind of portal that provides this strong authentication is important to us and we hope to be able to go live (strong) with this in 2009. We will keep keep extending the functionality but we have to see what the priorities are, whether we can do it before going live in the current functionality or we add something more first. There is some room to manoeuvre there, also dependent on the feedback we get from the testers. One thing that we will very likely add in the short term, though, is a web UI to validate objects because when you just look at one of those objects it's really hard to tell but we can very likely provide you something that at least gives you some web UI to do this. It's very early stage all this stuff, so there is no existing on line tools really for this yet.
More, well we want to look at interoperability with other RIRs, we should also look at� right now we have this one trust anchor but in the real world we will end up with something where we have trust anchors for all RIRs and some mechanisms are needed there. Resource transfers, something to look at, maybe new types of objects will be needed for it, maybe not. This has to be worked out. Non hosted solutions, this example, well, it's a web application where� that we host, with do all your management and you get an interface to do the actual management. It's also possible to host this /KWR*UR yourselves and there is a protocol being defined for this on how to do this and we want to look into implementing that as well and then you could choose to make your own application to do this, make the command line or whatever, it's up to you really. Recursive model, that means well, right now it's only one level so you can manage your ROA object, but you cannot really do anything for your clients and your clients cannot do anything and we want to look at how we can make this recursive so your clients could do this and their clients and so on. Now types of signed objects, that is continuously being discussed and when consensus is reached we can look into implementing this (consensus is).
And finally, well, what I wanted to drive home here is really, we really want people to become active as testers and if you are interested, then yes, you can talk to me, I am around, or you can go to the web page and there is a sign up for. When you do an e mail is sent to my colleagues or me and we can patch you in.
Advantages: Well, you can help shape the application if we are doing something that you don't like or if you think this could be much nicer in some way, then yeah, please do tell us. And we can see what we can do. Also, report issues before we think, OK, we test everything but yeah you know you never know, if something happens then it's best to know before you go live.
So, that is really my story. I would be happy to answer some questions.
AUDIENCE: Now, I am still� Russian because I have a critical issues after this system will be deployed, not I only but all Russian ISPs because if you broke all our national laws, any ISPs will be in principle under the potential court, it's a personal risk for guys because it's broke telecommunication law, it will be broke regarding� we have specific national law regarding cryptographic tools and so on, and this is as a result� you will have to do and it's not easy to do. Our role repository, our role certificates and build more complex system, national system which will, should be synchronised with total RIPE system. Anyway, we will have problems on using some specific crypto tools, and for us it will be big problem to prove that we will use non Russian cryptographic algorithms in any place and totally unprepared, it's to use any crypto hardware, it will be very problematic. If I can imagine how to build it's for Russian because I don't believe that we can change a set of laws, not one law, not one position. I talked before to guys who was involved in certificate process and also some that, it will be problematic. That as a result, we should build practical is something kind as national IP registry. Please, a lot of� I see a lot of change where during last two months new modifications because if initially it was� more human based system and now it's system including a lot of cryptography, now more hardware based, so there is� it's a real problem for us. We simply can't follow this way by law. I don't think that you are ready to break your own national laws if it's forbidden. I am ready to discuss this issue now in details because before it was� yes, it was task force, it's fine but it seems that you will get the result in deployment very soon. Thank you.
SPEAKER: I am not sure if that is� well, I would say that is a statement but
AUDIENCE: RIPE NCC. We have this task force and I think we have to take your comments very seriously and we will meet on a regular basis, us being the task force so what I think would be very valuable if we can have you during one of those task force meetings to discuss this further and to see how we can deal with this.
AUDIENCE: Steve Kent BBN Technologies. As chair of the P CIX Working Group which deals with Internet standards for infrastructure I dealt with folks from Russia before and have never encored with the kind of cryptography we are talking about here since we are not talking about encryption per�se. I don't believe the algorithms we have describing and the way they have to be used violate any of those laws that you are alluding to but if you can provide specific reference we can look into that in more detail. Is it case that nobody in Russia uses any of the standard browsers to access any protect sites.
AUDIENCE: In the law is not so strict but we mentioned about the algorithms. It can be used between enterprises but not for any government or government related entity, which are also among . Please remember, second point, yes, in some cases, for example for� new buy metric passports now we use global algorithms, we started from this point. Yes it's a time. The problem will be with repository with automated deployment of policies in future because it's key position in government in, law.
AUDIENCE: Do you mind if I interrupt�
AUDIENCE: May I explain because government will also require the guarantees of stabilities that country infrastructure will never� will never depend from third party.
Randy Bush IIJ, 937: The specification for this includes protocol that allows you to run all your own stuff and I believe that satisfies your needs, OK? So, this is not really a problem; the problem is if there is a problem, is that RIPE is slowly developing this and if could you back up a couple of foils, please� you know what I am looking for, it's a little forward. Man this guy is fast, I wish you coded as fast. It's somewhere up there. What is known as the up down protocol, you can run all your own stuff. I didn't realise you weren't listening any more.
AUDIENCE: Sorry got lost. Well, before Steve� before we launched into this discussion I actually had some questions for the speaker as opposed to comments. It wasn't clear in the demo that you were giving if as part of my generating a ROA you checked to make sure that the prefix that I put in was one that is contained in my certificate. Is that something that is done automatically?
SPEAKER: Yes
AUDIENCE: And the validity dates similarly need to be bounded by, well, you are generated an indenty certificate to validate the ROA at the same time and you are going to make those match, correct.
SPEAKER: Yes
AUDIENCE: Is there a way to click on something to have a default filled in for that rather than having to pick dates and run the risk of people putting things into a couple of millenia in the future by accident?
SPEAKER: What you fill in is the configuration specification really, so you don't make the object itself and, right now, we have implemented is that the maximum lifetime of it will be the� the lifetime of your CA certificate.
AUDIENCE: OK. One final thing is that when you look into the possibility, as you said, of having a user interface for people to submit objects for validation, there is at least now, two relying party software implementations that are available and are being updated to track the CIDR Working Group specs and you may be able to use those as a back end to plug requests into.
SPEAKER: Yes, that would be pretty good. We have been looking at our cynic user tool that can be used to point out the top of a repository and validate everything, what we are looking for is is a bottom up validation tool as well.
AUDIENCE: OK. Thanks very much.
CHAIR: From J.P. Nick. We have similar mechanism for authorisation of IP resources to specific S number measurement groups and we have experimental service for our members, then we have two comments about the applications, one is when they input their IP addresses they don't know what IP addresses are allocated to themselves; then we need to up the guide� develop up the guide for IP addresses, which addresses are allocated, or in this case, which addresses are the� the certificates are issued, and the second comment is the management of certificates themselves. They often lose the memory of insurance of certificates and often forget the entry of the entered, one year before, two years before, so we need to notify users before the certificate will expire, or some problems, so two comments.
SPEAKER: OK. Yes, the way we have set it up now is like I said, the key role /KWROFRS will probably be alternated. We could also automate certificate renewal. Right now that is a manual step, we want to make sure that it's it works and that is why it's there but I think in a real production system, that is one thing you would also want to automate so. People wouldn't really are� normal user wouldn't have to deal with this; you configure objects and leave it to the system. That is really what we want to do.
CHAIR: Malcolm was next.
Malcolm: Hi, I don't have any comments about the technical implementation period, again more about the architecture and what that means in a broad context and I think this is probably going to scare our Russian friend even more than just the problems about using a particular cryptographic stack. As I understand it, correct me if I am misunderstanding the basic aims of this project, this project is look forward to a world in which a, when someone makes a route announcement, that announcement will be treated with suspicion if they are unable to provide an NCC signed certificate or NCC validated signed certificate for the net block for which they are announcing a route to, is that right, broadly speaking?
AUDIENCE: Approximately.
AUDIENCE: Approximately correct OK. In principle that would give the NCC the practical capability pretty much pour the first time to revoke address allocations. That is going to be attractive� that is going to be attractive� I have been raising this in a number of cases� I think that is concern because I think that is going to be attractive to certain types of people that like to come along with Court Order and please say knock this website or whatever off the Internet and what we are going to do about that, if the NCC have that capability and it's locate in under Dutch law and the NCC is covering net blocks that go well beyond the European Union, I mean my speaking entirely off the record here, but my strong expectation is that first time this will be used it will be a Russian net block that will be attacked because it's got some content on it that is not acceptable at all under European law and how you are going to treat that, respond to that request to revoke that certificate as the NCC, I think it's something we as a community need to look at at in some considerable seriousness. (Community).
CHAIR: I see Daniel waiving.
AUDIENCE: I have a separate issue.
Daniel: There is a number of responses to that that are actually (responses to). This is a valid concern, it's a broad issue. This concerns being brought forward by not only ISPs but also by people close to governments. I am afraid it's going to be about a three minute speech to actually address all this. Number one: When way of looking at it is that it's no different� it's only technicalities different from the current situation, because it's not the RIPE NCC that actually does the action of maybe blocking something or putting something off the net, it's the ISP. And it's just more effective mechanism, if it's ever deployed in that way. So far, the RIPE NCC has had such requests to actually delete stuff from the RIPE database or otherwise revoke address space and we have always said to those requests, like you know we can't do that, it's the ISPs that actually make the decision whether to route or not and by the way if you want something from us you have to go to a Dutch judge to tell us to do certain things. So it only changes the mechanism, it doesn't change� well, you can come next, it only changes the mechanism. The other thing is, it� I believe the concerns I have been hearing, including yours, are based on the assumption that there will be what is called secure inter domain protocols deployed that do this in near realtime. What I have heard so far from my ISPs is that they are not really enthusiastic about this. What I heard from some governments, from the motherland security part is that they really like this, and from some governments they say "no we don't really like somebody to be able to turn off our Internet." So it's a concern that lives. The question really comes back again to the fact is will ISPs actually deploy this stuff in realtime or will they not deploy it at all or will they deploy it in a much less realtime manner which does not do it via the secure routing protocol but via the configuration and provisioning systems? And I think the one thing that we cannot do as a� the RIPE community as the RIR, say that we won't develop the tools. It's up to the ISPs to actually decide whether they want to do this, and quote put themselves in our hand. And I am very sceptic that this will actually happen. So that would be my� but the sort of formal� the more sort of formal reply to it is like so far the NCC has resisted and successfully resisted any attempts to do this but of course we will be bigger targets if our methods are more effective or considered to be more effective. Sorry for taking so long.
Randy Bush: 938. I disagree with you Daniel. Today the ISPs have the power (today) but what you� if, as you say /S RBG the routing is deployed, then you also have power that you don't have today, IE the revocation and the certificate, you being NCC.
Daniel: RIPE NCC yes.
Randy: I believe you are correct but there is a basic trade off here, and we are� our remembrance of history attenuates quickly, there was be another YouTube incident next week and your management is going to say to you, how do we keep this from happening? And you have got the classic trade off of security V ease of use and that is what you are dealing with here and so you are going to decide whether you are going to be willing to accept a system where, you know, there is rigidity and a hierarchic certification or something like that to gain the security of not having routing� accidental routing incidents, or worse. And by the way, people should look at the death come attack which Tony and Alex demonstrated what has actually happened but nobody talks about ways very serious routing attack where routing was diverted, you couldn't detect it, etc., etc., if might be is interested send e mail or something. It's the first time we have had a public demonstration of a serious routing attack and I don't mean a hijacked announcement, I mean traffic diversion through routing.
CHAIR: I am going to agree with both Randy and something Daniel said which was that comparing implementing this towards today's status quo is not true because we will end up in more complex regulation going forward, governments worried about having another YouTube accident and I think Daniel was also saying that governments in the world are today going both ways which will make our life really hard to interpret what is� what is good path forward, and to be honest I myself haven't decided yet, it's just an oaks. Then it was Malcolm and then Daniel and then Rudger.
AUDIENCE: /SEPB seconds too to the same topic.
Daniel: Just to Randy it's not between security and ease of use; between security and possibility of abuse the security mechanisms. Malcolm is worried about it I am as well.
AUDIENCE: That is certainly what I am concerned about. Daniel in response to your thing that it's just DISPs that I have that, I have to say I agree with Randy here. When you say at the moment to someone that requests to you deallocate some address space because they don't like how it's being used, and you say, no, no it's not us, go to DISP what you are saying to the requester there there is no point in us changing our database, nobody will take any notice. The ISPs have to change their routing tables to get the result you want so don't bother us with this. Under the new mechanism this the� take notice of it some kind of definition of success what you said there, when people will start being suspicious of routing announcements that don't have an appropriate accompanying certificate so I think there is a significant change here, but Randy, I don't think this is just a dichotomy, do we go ahead with this and solve one class of problems like the YouTube Pakistan problem or not go ahead with this and not face the kind of concerns that I am having but solve certain different class of problems. I think we could go ahead with something like this but look for other options as to how we could deal with the concerns that I am raising here. And I think there are other options that could be done that could be looked at and I think there are four principal strategies available to deal with requesters coming along for to you revoke certificates to hopefully get a proportion of the ISPs, a significant proportion of the ISPs to no longer make routing announcements, whether in realtime or not, I don't think that is the issue. But if people won't accept routing announcements for not blocks that don't have certificates then that will achieve what the requester wants. So there is four options: One, comply. Just somebody comes along lace a Court Order from the judge and says revoke this certificate and you do it. That is one option. Another one is essentially what you are doing essentially at the moment, trying to persuade the authorities not to issue such certificate, such notices to you, such instructions to you. The third one is to try and base yourself or the� or a crucial portion of yourself somewhere where out there in a jurisdiction where you are unlikely to receive that� such certificates.
AUDIENCE: Let's go to Russia.
AUDIENCE: Maybe Geneva who knows. Reengineer the database that in order to have, it be compromised in that way and compromised in a technical sense, the integrity be compromised, you would have to have multiple jurisdictions each cooperating to compel you, one portion could comply with the legal demand but as far as the world at large is concerned there were three other portions out there that weren't because they are in separate jurisdictions. Now, if you choose that last� if we as a community choose that last approach we are saying we are going to design a databases to be resistent to legal attack at this forum, which would be a politically controversial thing to do. On the other hand, if we succumb because of the failure of any other strategies we have employed to try and persuade the authorities not to issue these demands, if we succumb to a demand because we are subject to a jurisdiction, to a demand to revoke a certificate, resulting in the loss of route to go a certain net block that is outside your own jurisdiction, then that in itself will pose a serious threat to the confidence that have jurisdiction in the RIR supporting its needs. I think� Randy: Then propose how to go forward on other paths. It's not� there is nothing we can do if you just sit here saying there is this problem, what is the solution, what is the forward path?
AUDIENCE: Personally, my preference would be to investigate seriously where whether splitting the database into multiple jurisdictions was the appropriate thing to do. I am not going to stand here right now and say this is the right thing to do but I think we should consider it seriously, and we should think very seriously about the ex threat threat to RIPE as RIR of future prospect of being ask to revoke allocations based on the usage for jurisdictions� under compulsion of the jurisdiction it happens to be in when it's talking about revoking the allocations and jurisdictions that it's not in. I think I would tend to verge towards looking at preventing that happening by the technical design. I think that we should look at it carefully.
CHAIR: OK. Rudger has waited long and patiently.
Steve BBN. I am not sure how I understand that the database solutions that you are suggesting really apply here because revocation is done by the issuer of the certificate, period. Splitting this among multiple databases� that is how it actually works. We are way down this path, we have put lots of effort into it and it doesn't really work that way. So, I think one would have to go back and rethink just what it is one could do. Secondly, any RIR who choose toss do this, and all of them have said yes we are going to do it is not affecting routing. They are providing data that ISPs can choose to employ or not in deciding how to do routing. But you are not dictating anything; you are merely making available in another forum, in a highly integrity protected forum information consistent with your databases period. It's up to every ISP in the world to decide what to do with that data just like ISPs either choose to go to the IRR database that you help support, or not. So one can argue if you are worried about the legal defence here, provided information consistent with your database. What people choose to do with that information is up to them because you cannot compel ISP anywhere in the world to make use of that information any more than you can compel them to make use of the IRR data today, correct? I think�
AUDIENCE: On one level you are right but in practical terms we are talking about what the likelihood of receiving one of these demands and what the consequences are likely to be.
Rudger: Well two points: One is, yes, from some formal point of view, things not changing by implementing this. From a more practical point of view, we hope things change a lot because the current system means effectively that at least for parties who are having lots of routing relations, securing that routing information they receive is somewhat authorised and authentic is essentially impossible because, well OK, in many cases, in many cases there are actually no trustworthy databases or even the databases that have some security mechanism behind, still, still, still, are subject to keeping garbage around and not being maintained right. With the RPKI system, we are getting to a situation where, well, OK, if people actually decide to feed the system, ISPs can actually take the data and have a single home genius solution for evaluating routing requests from regardless what region and if the system is fed right, the routing situation can change a lot and the question, well, OK, is something registered or not, may be relevant and if things work the way that some people envision it's designed for, well revoking, revoking some certificate will have immediate and direct effect and whether the immediate I can't say see is by the microsecond, by the day or by a week, doesn't matter a lot, but again, I think whatever, whatever problems there are around, we actually need to do something of this kind to get to more stable and more trustworthy routing and that is quite certainly also a requirement that is of higher importance when the use of address space becomes more agile when things are getting tight. So well, OK, I welcome remarks and constructive suggestions on how to deal with issues that are out there, but I do not think, I do not think that we have any other reasonable way; if someone comes in today and says "well OK, I know how to do it completely differently, we know it will take so long to actually agree on this that, it is not feasible. For the question for the particular system that has been demonstrated, I would� I would actually add the remark that, well, OK, a completely hosted centralised database and operation like it's /HAOE, of course is more susceptible to concerns that haven't been raised than one that gets distributed and actually does a delegation. Of course. If we do a highly distributed and delegated system of course authorities may go for the highest hierarchy and try to attack there and well OK, depending on the particular circumstance there may be more or less effective that way. But well OK, going for distribution and delegation quite certainly, quite certainly kind of makes things a little bit harder for attacks like Malcolm was concerned about.
CHAIR: Thank you Rudger.
AUDIENCE: I will file a short comment on this. I don't buy into the argument that we only mike the tool, the ISPs use them because that argumentation along the same line as you find weapons industry, we only make the guns we don't use them. It's the same principle. This is not a bad tool, that is good, so I am actually supporting the efforts but my different issue was how do I submit my own key. Let's say that I don't trust your key generator, I want to submit my key because I have a much better key generator?
SPEAKER: Well, the bullet here about the non hosted solutions could be your friend in this case, because then you can implement your own engine and do it the way that you think is secure. Right now, we don't envision a way where we have hosted system that you can plug into your back end key generator in some way. If there was a need for such a thing but I don't see it, really. How that would work. (How that).
AUDIENCE: Thanks.
Randy: 939 I think. The entire architecture which they have not implemented and have in their future stuff has and has you able to run your own system that talks to them over the net, you have your own key, you don't want to upload your private key to them.
AUDIENCE: I wasn't talking about private key, public key.
Randy: Right but if you want to sipe the object you don't want the signer to be at their side either, so it's not just you want to upload your public key; you have to do the whole thing, and all the protocols handle that, the architecture hand else that, that is all a done deal; they just have to finish rolling out the implementation. This is the first step and it's a good step.
CHAIR: I think Daniel was first.
Daniel: The architecture supports what he wants, we had to make some choices in order to get any progress and we chose the way that we thought would be immediately useful to most people and of course we will, you know, if more stand up and say they want to do that, we will do that. It's not a failure of the architecture; it's just a choice of first implementation.
CHAIR: I think that was the last person. There is a gathering of people at that microphone but I think they are just chitchatting. All right. Thank you, Tim. (Applause).
Next is the host conduct
CHAIR: While we are waiting, the people in administration says they have quite a few unpicked up packages and for the general meeting so if you haven't yet picked up your voting card and papers and badges for general meeting, you might want to do so because as soon as we are done here we will head over for the general meeting.
Mark: Thank you. Good afternoon I am the information services manager at the RIPE NCC, this is a very quick update. Hostcount is an old service, got a new face and there is no crypto issues associated with it. Just a bit of history for you. The original mission statement for the Hostcount service was /O to enumerate the number of hosts in the RIPE NCC service region, to estimate the size and growth of the Internet and to reflect the distribution of the hosts on a per country basis.
Hostcount was first published in 1990. That is actually makes it older than the RIPE NCC, and ever so slightly younger than me. In 199 we were counting 19 different countries, you can see them on the map there, mostly in Western Europe. We found at that point in time in the very first one which is still published on our website, 31724 hosts, by 1992 that had increased to 271,000, that is 8 or 9 times increase. The report since that time has been run every month with stats presented on our website at the address mentioned.
By September this year, that service was seeing 25 million different hosts on the Internet in the NCC service region.
So the methodology behind the service itself; it use the DNS query tool host or used, which did a recursive AXFL applied to each CTLD in NCC service region e when our� there is archive /TKA*EU data for those in the website. And we count the unique A records from collected zones. Just quick little picture there to give you a rough idea of what it does or did. We would take the list of ccTLDs in NCC service region, try to transfer each of those, take what we found, transfer those and see what we found in them. There is a few examples there, as you can see a couple would be blocked and from some or one or two or three or more, we would get actual statistics, transferred across, a snippet of which might look like this. You will notice the obvious mistake, these were all 1918 address so is we obviously don't count or report on those and never have and never will. So what we would count in this instance are the ones in the green box, three unique A records relating to live host in the DNS, beneath them the ones that we would discard, the top one NS1 is duplicate of the one BoF it so we don't count them, we are only looking for unique and wwwrecord isn't a host so we wouldn't count that.
So the old Hostcount running since 1990 hit quite a few problems, the software although updated was quite old, prone to failure, would he get problems, there are more and more domains to query, more and more data coming out so we hit on scaleability issues. We had a zone cache to try and result but that skewed the results which made things mad. AXFR in the security conscious feature was increasingly blocked so we couldn't get data and there was no v6 support and the results weren't presented in a particularly friendly manner.
So we came up with the idea to rewrite this, we were asked to rewrite this and we called this while it was happening Hostcount ++ it's not Hostcount because it's live. That is a complete rewrite. We use similar methodology, use more data source to make the accuracy a little bit Bert. Still take forward DNS by grabbing all ccTLDs in the region and reverse IPv6 stuff and in addr.arpa and we also then with the IP address that is we find we look in BGP to see the addresses we are finding in DNS are routed and announced and visible on the Internet just to add a bit of accuracy to the data we are presenting. What we also did to help the scapability problems is create a DIY kit for ccTLD operators. That addresses privacy concerns, if.UK don't want to give us the.UK zone in all contents they don't have to, they can run locally and give us the anonymised stats that come out of it. .UK and.ie participate /PAEUT in this for us and what we did to ensure data continuity was have both of the services running overlapping since June last year until just last month. So to look at the stats that came out of that, the blue line at the bottom are the stats from the original service which were running, this goes up to, I think the scale is probably quite tiny there, but comes up to August this year. The red line at the top are the stats from the new Hostcount S as you can see initially going back to June last year when we first turned it on there was a bit of fine tuning happening and we have got to the point now where we consider it to be stable and it's live and it's active and the old one has been turned off. The other obvious thing you can see we are actually obviously collecting a hell of a lot more data than we ever were in the past, previously 25 million and now something in the region of 110 million unique hosts visible. So looking more closely at the new data, we see around 15,000 unique IPv6 hosts of which we say looking at BGP actually 100 percent of those are visible in BGP. We are seeing around 107, 110, it fluctuates, unique IPv4 hosts of which 99.87 percent are visible in BGP, that is 250,000 approximately which we don't see being routed anywhere but they do exist as A records or PTR records somewhere. Just to check that we are on track with with this, we have actually compared the data that we are gathering to a similar project run by ISC, their Internet domain survey which is run by ISC twice a year in January and July and there is a link there to that data which we have used for comparison. In July were measuring 133 million and we around 120 million most hosts so pretty close to each other. I have put some that have on a photograph here so you can see the comparison between the two different services that we are running. The blue is the ISC data, the green is the NCC data. If you look at them side by side, I have taken all of the ccTLDs across our region with more than 1,000 hosts and put them on there. (100,000) that is 36 out of cc� you can see the big peaks with Germany, France, Italy and moving rights, Netherlands, Poland, Russia Sweden and the UK. So we thought if we are going to rewrite this service and make it a bit more sensible and make the data a bit more accurate, we would create a new website in a slightly nicer manner. The website is live as of today, I think yesterday, but it's officially live today (today). Off summary for the whole region, for each country beneath that you can see the size of the zone or the� number of hosts discovered by the relative size of the country code of the country, at the bottom there. And you can click through on each of those to most specific data for each country. We have all of this lovely graphical representation, pie charts of the zone summaries, region wide across the whole of the NCC service region and per ccTLD. There is interesting stats you can find in here. The red blob shows 12 percent of zones which don't have any NS records, we are considering those lame delegation so is 12 percent of the zones that we are finding appear to be lame. We have not looked any closer at that. And the green chunk is actually 53 percent which are ones we are trying to transfer and are being blocked when we try to get of those.
On top of that there is more detail, you can click through, we have these little barometers showing the real hosts and duplicate so that is ones where we are seeing the same name or IP with different labels. We obviously drop those and only count the real ones that we only see once, comparisons there. The duplicate stuff is coming up at 15 percent for v6 and 10 percent for v4, that is what the stats say what, that means don't ask me. So the beta site is now live, please go and have a look. We are always interested in feedback, anything you have got say, any comments, any questions, please send them over to us. Just to finish off to, put the Hostcount into context, it's one services run under auspices of information services and we are presenting some more of our stuff at RIPE 57 this week. There is a new MyASN service going to be presented in the Routing Working Group, Wednesday, tomorrow, at 1:30. Stuff we are doing with TTM will be on Thursday at 11. I have included some Linx too to the services that we run the routing information service, test traffic and also we are very lucky this week we have the IS demonstration stand which you can find outside in the hallway to the side of the registration desk being manned by Frans and that will be over Thursday after the test traffic Working Group to go along and have a look at some of the stuff we run. Are there any questions, please?
CHAIR: No. All right. Thank you, Mark.
(Applause)
CHAIR: So, just basically only open microphone left on agenda. I guess you could say to sum up the discussion on the previous topic, I guess the input was to the certification resource task� certificate resource task force and the offer from them to actually go and discuss more what the country implications are and to look at this more, I guess is the message from here today. On that, any items that open microphone session? If not, thank you all. See you at the next RIPE meeting. I know you can't wait, it's only six months to the next meeting, I know I will be sad. But in the meantime, you can go and pick up your packages or go to the general meeting which is next door.
(Applause)
Conclusion of session