Archives

Closing Plenary Session
15 May 2015
11 a.m.


CHAIR: All right. Good people of the RIPE meeting, this is the last session of this great meeting, and let's start and get on with it.

So, before we move on, as, you know, as the RIPE PC ‑‑ my name is Filiz Yilmaz by the way, we are starting ‑‑ thank you for taking your seats so quickly ‑‑ so, we had elections at this meeting as, you know, the two seats were up and we had three candidates. Thanks to them all, Shane Kerr, Benno Overeinder and Joshua Sahala. We have the results. Benno and Shane got elected for those two seats and their work starts immediately, as they know, so congratulations to them.

(Applause)

So, we will continue with our agenda, and we have one last talk, and then we have one last lightning talk before the meeting technical report. Carsten and Patrik will talk about their experience with DANE. So please...

PATRICK BEN KOETTER: We're here to talk about DANE. We have been implementing DANE technology throughout last year. Probably one of the key sets of memories that DANE secure security you want to is yourself, why would you want to secure security? If you want to answer that, you have to take a look at typical encryption models, we'll be talking about SMTP and what can do for that. We can go to aspects later. Something everybody wants when they do encrypt is, they want mandatory encryption, you want it, you want reporting if something fails, you want all the alarms etc. But everybody, or at least most people out there, seem to be doing only opportunistic encryption, which does not ring any bells or come with alarms or things like that if things go wrong. So what could possibly go wrong?

First of all, encryption means you need to use certificates, certificates means you have to use certificate authorities and they are having some problems. The major problems I'll show you right now.

So, first of all, part of the problem with the certificate authorities is that any certificate, certification authority can issue a certificate for any domain and they don't seem to be cross‑checking. So, also, one or the other certification authority has been broken in a few years ago, as you probably might remember, especially here in the Netherlands. So there's a problem with the certificates you go and buy from.

Another problem we have is, there are session downgrade, which means that SMTP as it is today has no way of significant signalling beforehand. We only find out at the moment you talk to that server that the server would or might be able to offer encryption. Somebody else might intercept a connection and might take the STARTTLS away. Are others doing that? Yes, they are doing that, it's happening today. The electronic frontier foundation has written about that, that some ISPs do that and others in order to enhance security or in order to enhance their products, which is probably not something you want if you are eager to use transport security.

And then there is man‑in‑the‑middle attacks, that is if somebody built their own certificate with the same host name, you want to connect to, or if they go and, for example, breach a DigiNotar, as happened, and create certificates for a well‑known domain, they might intercept that connection and they might present themselves with a perfectly valid certificate, which is even worse with TLS and SMTP world because most servers out there will happy accept self‑sign certificates. You might turn up with the name examples.com, you want to call a different server and you are delivering the secret message to somebody else.

And one of the reasons many people don't use mandatory transport security is, it's very hard to automate it. If you really want ‑‑ if you want to take security really seriously, you probably connect to that destination, you want to encrypt to, you look for a fingerprint and you pick up the phone and start talking to somebody on the other side, try to get the post master and talk to him and verify the fingerprint, so you know who your server is talking to. This turns out to be hard and it turns out to be a real problem because you are not in control of the other side. If the receiving server switches certificates and you have a hard pin certificate on your side and you say only talk to that server, if that server comes up with a fingerprint and they change the fingerprint, then you have the problem, the thing is they have no idea that you have mandatory encryption on your side. So, they change the certificate and messages start queue up on your side because they don't know how to notify you.

How could one secure that?
Well, the plan is to add a policy channel in which you can signal a few things. For example, you can indicate the destination supports encryption. You could also indicate that the identity of the destination your server should connect to. And to have that transmitted in a secure sway, would you add a trust layer, and this is where DANE comes in.

DANE is the shorthand for DNS‑Based Authentication of Named Entities, it uses and requires DNSSEC, DNS becomes a policy channel where DNSSEC adds a trust layer, and now that you have that framework to transit policies or transit information, you start telling, connecting system, you start to tell machines that are interested what they want to know, and, for that, you start using new resource records.

I'll go over that in a minute. The current use cases that we have is you could use DANE to enhance HTTPS connections, SMTP and OpenPGP. In HTTPS, you would publish TLSA source records indicating there is a report and free over TCP, and you would tell that resource that is in TLSA resource record telling this is a public certificate bought, that is the certificate usage, then you would say, use that selector, selector says either pick the fingerprint and information or pick the whole certificate to identify the certificate, and then the matching type, what kind of algorithm was used to publish the information.

If you do a query, this is what you get. And if you have the correct plug‑in, right now it's a plug‑in, you might find a signal telling you that there is a DNSSEC‑enabled server that's the key and that the server also has been identified through DANE. That is the browser connects, the brother makes a look‑up, finds out over DNS, I could identify that server over there by this fingerprint, this is something it gets beforehand over DNSSEC, this is something it uses when it connects to the server, the server announces it's able to encrypt the session, the server shows its certificate and fingerprint, you compare the fingerprints, say okay, they match so I must be talking to right instance.

But, this is user land and user land has a few issues. We did a survey for an ISP in Germany, and we checked their cable node for the DNS capabilities and this is something that Carsten did, and we found out that all of them had more or less major issues when it comes to DNSSEC, so, there is still something we need to do, the reason why those products are not as DNSSEC‑enabled as we would like to have them, is that they probably built them a few years ago and you have just been adding new features but they did not change the software in there but this is something that's taking place especially in Germany, where they try ‑‑ where the Government itself is talking to the ISPs and urges them to improve the cable mode items out there for end users.

It's a little different on the side of SMTP, I'm talking about machine to machine communications over wide area networks. Just to remind you what that resource records looks like, it supports 25, which you probably know is a mail server. And the client should be talking to. There is an RFC which is right now in the Working Group's last call, it's been drafted and written and the first limitations to show up on the market were Postfix, OpenSMTPD and Exim. One of the authors is one of the two major authors with Postfix, so what you have right now if you look at RFC, you have a very well written and also in practice proven RFC, many things that he implemented, he worked with while he implemented DANE capability in Postfix and many experiences he learned went back in the RFC.

We have been using DANE and DNSSEC since the end of 2013. It's about Christmas time when you get time to do other things. And it's only, it's a small difference but it makes all the difference. Usually, you would have a trusted TLS connection when you connect to a certain destination. That means, in this case, the client was able to look up the certificate and was able to verify the certification chain in the, in its own certificate store. Very identified TLS makes a difference, this means I have been able to talk to find out that there is a DNSSEC‑enabled do. I was able to look up a TLSA resource record, I took the fingerprint from via DNS and then compared it to the server when it started to talk to the server and they matched so I know I'm really talking to the right instance.

There is not too many domains out there right now supporting DANE, but the impression is probably does it have to be many, many domains or does it have to be the one that makes a difference ‑ for example, large ISPs, large providers, or certain governmental institutions. In Germany, it's bund.de, which is the made portal for governmental information, they are DNSSEC and DANE enabled, so this is I think a good sign to say that the important ones are adopting DNS and DANE.

This is where Carsten takes over.

CARSTEN STROFMANN: The IETF, after working on HTP and SMTP, are also working on securing other protocols and I will point out here a PGP and how that works. There is now a way, or it's been discussed it's not an RFC, it's currently an Internet draft, a way to store PGP keys in DNS secured by DANE. And the benefits here are that the keys are more in control by the actual user, especially the removal of keys is then possible which is not possible in the collector key servers, one you have it on its key servers there is no way to get the keys out there any more. With DNS, it's possible to just remove the resource record and here is how that would work.

This mail client wants to send encrypted e‑mail to someone else and the mail client does an DNS lookup for an OpenPGP key. That comes back, it's verified it is DNSSEC secured and that gets then the PGP public key into the mail client, mail list being encrypted. Very similar for S/MIME. There's the S/MIME A resource record that stores either the full certificate recollect the public certificate of a mail user or a hash of that certificate. And here there is an example how a hash could be verified. Bob is sending an e‑mail to Alice which is unencrypted but contains the S/MIME public certificate from Bob in at attachment. So Alice gets this e‑mail and now is able to encrypt the response back to Bob. But Alice wants to be sure that it's really, really the right certificate, so the mail client of Alice will do one DNS lookup asking for S/MIME A record getting the data back which is either the full certificate or the hash of the certificate, compare that with the certificate received from Bob, and if that matches, Alice can be sure that she is in position of the correct certificate from Bob and can send encrypted e‑mails. That be automated. We at SIS4 created a filter that can automatically do that, it's not the mail client, the mail user that does this, it's in the mail server once a mail is being sent out to the mail server, the mail server will look up the certificate and do automatic encryption. The same is also available for OpenPGP key written by Paul [Vouters].

There are next steps, the DANE Working Group is working on securing even more protocols. Work is done on storing raw certificates in DNS, and on UTL authentication, currently it's possible to authenticate the receiving server, but also the sending server should be identified, so that both sides can be sure that they talk to the right end point on the other side. And there is a payment association record discussion currently in the IETF, that what authenticate a payment information like account information found on some website and link that to a domain and the owner of the domain.

PATRICK BEN KOETTER: Well, who will benefit from DANE? Over the year we have been talking to different people. What we found out is what people think about DANE is security service providers, that is any of course e‑mail providers or anyone who provides secure e‑mails, also specifically some of the companies who work in Germany. Also, e‑mail users with defined security requirements. When people start talking about security, they are usual ask for the full scale, they want to start until everything is secure as possible, we'd rather talk about defined security, people know how secure things need to be and when you can stop dealing with securing things more secure.

On payment insurance banks ‑‑ subcontractors ‑‑ situation in Germany is right now, 55% of all .de domains offer start TLS. There is 1% of them who is offering DNSSEC. And this is a growth we have been experiences over the last while ‑‑ I have to talk to Peter, get new figures. This is not as I said, it's not widespread in Germany but again you have to figure out what are the important domains you want to talk to.

It's completely different here in the Netherlands because, in the Netherlands, I have been told it's kind of sponsored if you go for a DNSSEC domain so it's cheaper so people start to use DNSSEC. So it's outnumbered by a big figure.

What are the typical DANE road blocks? Well, people, they at the moment ‑‑ when they talk about registrar, they have their problems because they have problems finding one that supports DNSSEC. DNSSEC doesn't seem to be the big market yet, so they don't offer it. Also, what we get to hear is people say DNSSEC is a technology but it's not a use case, what should we do with it? DANE might be the one use case that people really go for because it helps them to secure their infrastructure and automate, which means they will start saving money when they do it more secure.

CARSTEN STROFMANN: What we see is people don't implement DNSSEC because of DNSSEC but they hear an about DANE, they hear about the possibilities to secure the other protocols so they want to have DANE and then they recognise I have to do DNSSEC in order to do that and then all of a sudden implementing DNSSEC is not so much a question any more, because they want to reach the goal of having the digs will al security of DANE. So then there is money to implement DNSSEC and that way what we have found.

PATRICK BEN KOETTER: We find out also that you want to monitor it and apply good alarming to it because DNS itself is mission critical, but if you get something wrong with DNSSEC, DNSSEC itself will not tell ‑‑ give information away so really you are kind of away from the Internet if you do something wrong with DNSSEC.

And missing tool chains for automatic management, that is something they are looking to also.

CARSTEN STROFMANN: If more and more data is in the DNS and DNS becomes more and more important, a coordination is also important between all the certificates and BGP keys and S/MIME certificates being used and the data in DNS, so if now someone has DANE and the certificates being exchanged, care must taken to also changes the fingerprints in DNS, otherwise everyone who does DANE validation will get a failure. What's currently not existing in the market is proper management tools and monitoring tools and we're working on that to make that open both on the Open Source commercial side, but yeah, we see first small tools appear that do that.

PATRICK BEN KOETTER: This is a typical slide. We have produced a DANE validator and put it up at dane.sis4.de, feel free to use it to validate your DNSSEC status or to validate if you have DANE. What we typically find out is that many domains do have DNSSEC but they miss that little but all important step, for example, for SMTP, to add TLSA records. One you have that you are fully compliant DANE website ‑‑ DANE domain.

CARSTEN STROFMANN: If you already have DNSSEC, using DANE, that step is an a very little step compared to the step of implementing DNSSEC.

PATRICK BEN KOETTER: The hard part is DNSSEC.

So, to take away. DNSSEC, you need DNSSEC as a one time cost. What you get is an open standard with DANE. It makes your security management far easier, because you can distribute all the policies beforehand. Machines can talk to each other, and simply deal with that and you don't have to deal with that. It even ought mates the rollover, the situation I have been talking about that if the destination domain switches over their certificate and all may starts queue up on your side, you don't have that with DANE because you simply bring in certificates and the client says, well, I'll pick one of them as long as it verifies and then you fed out the other one, the old one, and you're done.

Thank you.

(Applause)

CHAIR: Already, questions...

AUDIENCE SPEAKER: Warren Kumari, Google, and one of the co‑chairs of DANE. Can you go back to the slide about the draft with Victor and [Wess].

Just a quick update. We called Working Group consensus on that I think on Wednesday, and it looks like we have consensus to proceed. So, that should be moving along.

PATRICK BEN KOETTER: Thank you.

AUDIENCE SPEAKER: Ondrej Caletka from CESNET. I have a question and maybe then a comment. Since you deployed TLAS validation for your mail servers a long time ago, I would like to ask how many domains failed to deliver mail due to the proceedings with TLSA records.

PATRICK BEN KOETTER: My own. I exchanged certificates and I forgot to update to the A record, and actually it proved to work, because the certificates wouldn't match and I wouldn't deliver from our company's domain to my private domain. This is something I found out. Besides that, we hardly have any interpretability problems, which might be contributed to the by the fact that DANE out there isn't that wide spread yet.

AUDIENCE SPEAKER: Okay. So it's about the same with me, I actually observed four issues with delivering mails to such domains, and there were two of them were operational work flow issues connected with exchanging SHA 1 certificates to SHA 256 and usually the people that had the TLS records to DNS to people who are exchanging the certificate and they are not communicating together.

PATRICK BEN KOETTER: That's one of the experience we also had, he simplify have to rewrite your work sheet if you work with DNS, you say okay there is something new, there is a new task I need to take care of. Check that. As for the DANE validator, I just told you, we are working on a monitoring version of that, so, somewhere between now and we have time to do that, we'll be offering a monitoring service where you will be able to register and have our side monitor your TLSA resource records and they will alarm you.

AUDIENCE SPEAKER: And the rest two cases were actually connected to one, especially one DNSSEC hosting provider in Czech Republic that used some kind of historic software making DNSSEC, and this software have this bug that request for nonexistent records actually cannot validate. So, more most protocols so far it's not a problem because if you have got an X domain or surf fail, nobody cares the result for most application is just fail, but for the TLSA violation is a crucial difference because if you have got server fail you just suppose somebody is doing something with DNS and you just queue the mail until it fixes.

PATRICK BEN KOETTER: I believe that has been dealt with too. Victor De Kovni, really was after those domains and that caused problems and wrote to them and told them what they should fix. So that we improved a lot.

AUDIENCE SPEAKER: Let's hope it will not expand to other providers, because I know about this one. Thanks.

AUDIENCE SPEAKER: Chris, RIPE NCC. Question from the chat. Lutz Don Hata asks: With DANE the registry registry reseller chain becomes the weakest link. How can this chain be supported to support such values at TLS certificates?

CARSTEN STROFMANN: We are not experts in securing the reseller registry model. We see the same problem, yes. It's true, that becomes the the weakest link, and I think that is the RIPE community is a good place to discuss that, what can be done to strengthen that communication and that link between resellers registries, registrars.

PATRICK BEN KOETTER: Probably not the right answer. Or not the kind of answer Luts would like to hear, but in DANE you are able to roll the RDR certification authority and also indicate that in your TLSA policy. So you might be able to work around that, that is the way you would like to go forward.

AUDIENCE SPEAKER: Thank you.

AUDIENCE SPEAKER: Peter Hessler from Hostserver. You mentioned that like, general home DNS resolver implementations wills have problems with DNSSEC. Have you run into any issues with a DANE record as you are trying to send e‑mails or receive e‑mail?

CARSTEN STROFMANN: Not that I'm aware of, that we have seen any DNS‑related, DNSSEC‑related issues, when sending mail. Despite from the known DNSSEC issues that there are like too large answer packages and IPv6 fragmentation and what can happen with DNSSEC, but I say normal DNSSEC, not TLSA DANE related issues. But nothing TLSA DANE specific.

CHAIR: Warren, do you want to follow up? Your body language seems to be... we have a couple of more minutes.

AUDIENCE SPEAKER: Warren Kumari, DANE co‑chair. I just want to follow up to the previous, previous question. You are already trusting your registrar/registry that entire chain, because if that gets hacked, somebody could redirect MX server they control and go to one of a whole bunch of certificate authorities and apply for, you know, a CA signed certificate, get the certificate and start using that. So, you know, the registrar/registry link is already something that you have to worry about, they already have full control to make your life sad. Thank you.

AUDIENCE SPEAKER: Peter Koch, I think that statement was probably a bid broad, but...

So, the link isn't really becoming weaker, right, it's just that we have the strength put on what we used to sell DNSSEC with, naming cache poisoning, what we have indeed done here is on a formal path, making the DNS protocol more secure, that we have the check‑box there, so that's the part of DNSSEC that gives you the use case. Actually I was getting up for the other question regarding the home use and not having issues there. I think one of the important things and the interesting things about starting with MX records and SMTP is actually you don't have to worry about the last mile in the first place, because usually the home user doesn't have their own SMTP system, so you act in kind of a closed club with hopefully people who are tech savvy and can operate a validator and signing engines decoupled from their customer infrastructure. So one important point is that this, part can deploy DNSSEC without worrying to like the subject base to all these rumoured or existing difficulties with packet sizes and so son and so forth. You can do that kind of in a lab environment except that's production.

CARSTEN STROFMANN: Yeah, same applies to the PGP, OpenPGP and S/MIME stuff. Of course that can be done in the client's mail client programme, but maybe it's even better to move that to the mail servers, have this programmes do automatic opportunistic encryption and then we can maybe bump up the level encrypted e‑mail worldwide to a reasonable level without requiring all the e‑mail users to understand how keys works, how certificates work.

PATRICK BEN KOETTER: It simply works.

CARSTEN STROFMANN: That's a hope.

CHAIR: Thank you, Carsten and Patrik.

(Applause)

Now we have a lightning talk from Sander Steffann about the latest developments in Saudi Arabia in regards to version 6.

SANDER STEFFANN: Good morning. So, I want to show you an example of an IPv6 deployment that had some very interesting results namely the one in Saudi Arabia.

So, this was a project whereby CITC, the telecom regulator of Saudi Arabia, and they decided to hire some external experts, people you might have heard about. The project started in the beginning with three or four meetings a year, they continued to have two meetings a year, and as you can see on the next slide, it was quite a long project. It started in July 2008 with a kick‑off meeting and then over the years, there was a strategy for the ISPs, there was meeting with the vendors, the first route server, L‑root came to Saudi Arabia, and basically in all this time, all these years there was a lot of work done. You know, Saudi Arabia has its own international filters, so, they filter all kinds of traffic, they don't want into the their country. So those had to be taken care of. And a lot of things happened, but from the outside, it was hardly noticeable.

Also, the RIPE NCC and MENOG did a lot of work, there were eight IPv6 road shows were given there, some by me, some by others between 2011 and 2014. So basically, two road shows or two trainings per year.

And what we saw there was that in the beginning, there was a lot of focus on the ISPs and how to deploy IPv6 and give it to your customers. Later, they already started focusing on enterprises, which was basically last year they started doing trials with pilot projects with enterprises, with national research networks and things like that. So, I think they are on a very good track, they are looking at the important points as we saw also during the IPv6 Working Group yesterday, the enterprise bit is still a difficult one.

And like I said, in the beginning, and up to last year, nothing was really visible. And then at the beginning of this year, this is the graph of the IPv6 traffic coming from Saudi Arabia. Thanks to APNIC for providing the data on this.

As you can see it's like 0, 0, 0, 0, and then, in one go, it jumps all the way up to 6%. And zooming in a little bit, this basically happened within one month. All the traffic came up in a couple of weeks.

So, we have seen countries like Switzerland grow fast, Belgium grow fast, but now you can see what Saudi Arabia suddenly coming up. And I'm pretty convinced that this is not the end of the line going up.

So, a bit on the timing of this. First active user on the 7th April and on the 7th May they had a big conference, and this is pretty much what triggered this deployment. There was a big conference, the regulator gave it a lot of attention, so, it was the final part of this deployment project, it was widely announced and, of course, a place for the telco STC, the national Saudi telco, to show off what they had done.

So, basically, completely invisible, and lots of stuff happening behind the scenes, and then you see that this good preparation basically just makes them, gives them the ability to just turn on v6 like it should happen. I know the other operators will follow soon, and because of this, Saudi Arabia is already in the top 20 worldwide now of IPv6 countries.

So, what effects did we see from this quick deployment in one of them was the content, and everybody was like oh, there are no users on IPv6 at all, we don't need to do anything, even if we would enable v6 for our website, nobody would be able to see it. And then within three weeks, it goes up to a significant level. So, this was a really shock for content providers that thought they had a couple of years to deploy, because it turned out they didn't.

The other one is that this of course cost a bit of competition between the ISPs, so now the other ISPs can't wait for too long before they start deploying, otherwise it would make them look bad.

So this actually had a lot of effect.

So, what I wanted to show you with this is that IPv6 can come up really quickly, if good preparation is done, in this case it was a good taskforce, there was a national strategy for IPv6, the operator was supporting it and in this ‑‑ people think of Saudi Arabia as strictly top down, with you I must say that CATC handled this with very gentle nudges in the right direction. They were not forcing anything, just guiding people in the right direction. I think this is a good example. Lots and lots of training was provided, mostly by the NCC and MENOG. And the last bit we learned from the enterprise part is that there is a lot of stuff to be done in that area, it hasn't gotten enough attention. And I noticed that the RIPE policies, especially for people whose language is not English, are very hard to understand. It took me two months to guide the national computing centre into becoming an LIR because they had no idea what all the terms meant, what PA and PI was and this was actually very hard for them. So, it was also a wakeup call for me that this is, for us it's really simple, but for people who are not regularly involved, it was really hard and really difficult to understand.

They were confused about the charging scheme, they said this 2,000 year sign‑up and then the next year I have to pay 1,600. No, the first year you have to pay the sign‑up and the membership fee, and this caused a lot of confusion, so that should be something we should remember that for us, this stuff is easy; for outsiders, it's hard.


Apart from that, Saudi Arabia, basically showed that a couple of years of very good preparation makes it possible to turn IPv6 on in three weeks time.

So, thank you.

(Applause)

CHAIR: Any questions?
Thank you, and with that we'd like to hear from the RIPE NCC.

MENNO SCHEPERS: Good morning. My name is Menno. I am part of the technical team who set up the RIPE meeting in the weekend before Monday.

We're a team of seven people. We have been setting up the, all the equipment and the wifi and everything on Friday, Saturday and the Sunday, together with the ACS people, the audio vision people who set up the projectors and do the audio over there and in the other room. We have also set up the uplink together with NLix, it's ‑‑ we are AS2121 and they gave us transit, also they gave us peering, the open peering AS and they also gave us access to the route service of the NLix.

The access points that you have been using throughout the week, they have been installed throughout the conference area, most of them are here in this room, and next door, they were there. You see that's all red now over there because we took them out last night.

The wifi, yeah, as usual, people who know 2.4 gigahertz is three channels that we use, very, very busy. The 5 gigahertz as you can see is a bit there's more space there for us to use so it's a bit more quiet.

Wifi usage per OS, there is, as you can see, the blue is Apple products, so Apple is over 50% here, it was the same as in London I think, but it's a bit growing, it's growing a bit. So...

DHCP leases, there's been, compared to London, many, many more, like over 100 more devices have been on the wifi concurrent devices, you can see for example on Tuesday, I think the peak was on Wednesday, just before the AMS‑IX issue, and then it's interesting, that after, say, around midnight, there were also around 100 devices on the network, the little bump over there between Wednesday night and Thursday night, so, who knows what happened there? Maybe some Secret Working Group or... no idea.

This is the client count on the network, also is shows the same peak. It's been around 720, 724 I think it was.

The traffic IPv4 and IPv6 on one graph, we can see that I can't really read it well, but on the screen, it's ‑‑ you should actually see it in the presentation, I can't really see it properly here, on the screen but it's been a good mix of v4 and v6 traffic.

On Wednesday, there's not really much visible, you see the lunch dip, but that's not the AMS‑IX outage dip, it's just people going for lunch or maybe trying to fix their network that's on the AMS‑IX.

About the AMS‑IX outage, there is a very nice Labs article written about that, so, I won't say much about it, you can check it out on labs.ripe.net. I think it was perfectly timed almost, it could have been you know, ten minutes later and we would have all been having lunch and wouldn't have noticed anything.

These are some numbers compared to previous RIPE meetings. You see there is quite an increase of numbers here, later on we'll probably hear exactly how many attendees were here at this RIPE meeting, but it's, it most likely was the biggest RIPE meeting ever.

Here are some other things that we have been doing, the webcast that's being done from over there, and we have a server in the data centre that's been serving the webcast. The webcast statistics here shown, show around a peak of 250 people, and that drops throughout the week as if people lose interest, but I don't know why, but everyone was enthusiastic on Monday.

There are ‑‑ what else do we do? We do the presentation system, so the presentations that the presenters have uploaded, we load them over there on two different computers, so that while the presenter is presenting, the next presenter can check his presentation over there and we can smoothly transition between presentations. There has also been the stenography, that has been very ‑‑ that's very handy for us, because it's helping us a lot, if there is any issues with accents or understanding people and it's all written down immediately. And there is also support for remote participation, that's in the form of RFC, and then we have staff from the RIPE NCC repeating those questions on the microphone.

And that's what I wanted to say about the ops team here at the RIPE meeting. Any questions? Thank you very much.

(Applause)

CHAIR: With that, we'd like to get Hans Petter to the stage.

HANS PETTER HOLEN: So, the week is over and we have come to the end of RIPE meeting number 70. So, it's time for the normal stats.

This has been the largest RIPE meeting ever, any guesses?

HANS PETTER HOLEN: 678 attendees checked in. And as you see, as with IPv4 addresses ‑‑ that's the number of citizens in Norway where I come from.

If you look at the growth there, you will see that this is just as with v4 addresses, it's increasing the growth. It's going to be interesting to see if we do this ten years ahead, what kind of venues we need to do these meetings?

71% of you are recurring visitors to RIPE meetings, that's very good that we're able to keep so many interested in coming again and again, but it's I think a real good sign that we have almost 30% newcomers at this meeting as well, so a big hand to those.

(Applause)

Now, as usual, with the registration, so, we draw some prices for the first ones to register, and the rules are that you need to be the first one to register and you need to be present here at the very end to receive your prize. So Raymond Jetten; Sergey Myasoedov; and the next one, Daniel Stolpe... it's great to see that you are still hanging in here, registering first and staying to the end. That's very good, that's the way we want it.

So, in order to make this meeting as good as we did, there is a lot of effort put into this, but we need your help to make the next meetings even better, so, if you go to the agenda, you can go and rate each individual talks, so if you think that this presenter was awesome, please give him your support, if you want feedback on improvements, or consent, or whatever, you can do that, and those presenters that request this, they will give this feedback but more importantly the Programme Committee will use this when putting together future programmes. In addition to that the meeting organisers and I would like the feedback on the whole meeting, so there is a feedback forum up here, please go and fill in that one and we actually draw some prices, some Amazon gift vouchers, so if you want something more to read, this is also a good incentive to fill in this form. But it's really to improve the future meetings.

Looking at the attendees, we still see that one of the bigger European countries is the United States of America, and there were some questions earlier on on out of reach and use of addresses, so it's clear here that US is within our region...

Well they are actually beaten by the Netherlands with a couple of attendees, so they are not the biggest participants here, but I think that's a healthy sign that we are producing such a good meeting that we attract participants from all over the world.

Looking at who is coming here. Well a fair share of commercials, associations, education, even governments, we have 4% of you said you come from some kind of Government agency, I think that's very good that we also engage with not only commercial and RIR colleagues but also Government colleagues.

So, some changes on the Working Group Chairs. I said in my opening speech that Nina Bargisen, my Danish pronunciation is not good, was appointed the new co‑chair of the measurement Working Group, together with Christian. Gert Döring was reappointed as Address Policy Working Group Chair, and Maria Hall stepped down as co‑chair of the Cooperation Working Group. So I expect there will be opportunities if you want to move into leadership of that Working Group.

So, one of the things that's been going on in this community for a long time is this CRISP process. So we presented this had a couple of meetings ago with this timeline. Now we are beginning to come to the end of this, there is end of month and so on, so there is really good work produced here already. We had a presentation on Tuesday and a discussion there, there is no SLA on the table and what I want all of you to go home and do and look at this and give feedback on I know this is in very good hands on RIR stuff but we want to show there is community support behind this. As usual, we are based on consensus, if nobody screams this is not good or I want to change this, we think that this is the a way the community wants this, and that's what we're hearing on the mailing lists and on the meetings. Deadline for comments, 15th June.

I want to give a special thanks here to the CRISP team members, Nurani, Andrei and Paul.

(Applause)

They volunteered at the last meeting to work a couple of weeks, two to four weeks, be finished before Christmas with the CRISP proposal, they are do a lot more than that and they are still hanging in in order to shepherd this SLA along and answer questions from other parts, so, I think therefore, a week turned into four months or a year, so I think that's really good and they have received tremendous support from both Chris and Athina, so I think they deserve hand as well.
(Applause)

This programme hadn't been possible without the Programme Committee. So, I would like to ask Filiz to come up ‑‑ I warned you ‑‑ and Filiz has been Chair of the Programme Committee for three‑and‑a‑half years, and really been pushing both the Programme Committee and the staff and the rest of us in order to make sure that these meetings are getting better and better. She has now unfortunately decided to step down, OSI wanted to sort of give you gift for this, thank you. And then you are still on the ICANN Address Council for us so we will see you, you are still on the PC until the next meeting. So, we will see a lot of you in the future. So thank you very much.

(Applause)

Now we also have a gift for the other Programme Committee members, but those will be, you can meet afterwards and she will hand you the gifts. Gergana is sitting down at the left.

But this ‑‑ well, my left. Your right.

This meeting would not have been possible without the RIPE NCC staff. So, I really want to say thank you very much for a very well organised meeting. I'm really amazed to what level we have been able to take these meetings. It's really a huge production. We are now growing in numbers, and you are able to expand the technical stuff and make this meeting a good technical experience, and an excellent social experience with all the socials and all the coffee breaks and all the arrangements. So a big hand to the RIPE NCC staff as well.

(Applause)

And, of course, without the stenographers, we wouldn't know what we're saying, so, without you, thank you.

HANS PETTER HOLEN: Of course we have other hosts and sponsors, much appreciated, the coffee and the socials and the support, connectivity support and so on.

So that brings us to the very end of this ‑‑ oh... this was not in my presentation.

HANS PETTER HOLEN: Thank you. The owning thing remaining for me to say thank you very much for the time here, and...

And welcome you all to the next RIPE meeting in Bucharest in Romania in November, so with that, the RIPE meeting is over and maybe there will even be some lunch. So thank you very much.

(Applause)

LIVE CAPTIONING BY MARY McKEON RMR, CRR, CBC

DOYLE COURT REPORTERS LTD, DUBLIN, IRELAND.

WWW.DCR.IE