Archives

PLENARY SESSION, 12 MAY, 2015, 11 A.M.:

SHANE KERR: Good morning, everyone. Benno, and I am Shane, will be chairing this session today. So please have a seat, try to get yourselves situated. We will be starting off today with a presentation by Olafur Guomundsson about DNS synchronization and I don't know if I need to add anything else to that, why don't we just get started.

OLAFUR GUOMUNDSSON: Good morning. As a matter of introduction I have been working on this thing called DNS for a long time. I talked about DNS issues once in a while at RIPE meetings, I am not a regular attend Dee, and in my new job I have ‑‑ at CloudFlare, I have been exposed to certain things that we the DNS gurus thought was non‑issue, I am going to be talking about some of the things which make DNS, which is an old protocol, work better in the world today and with the expectations that we have. I remember, well, yesterday, one of the first talks here was about Ethernet. I remember when Ethernet was three mega bits. Now, we are talking about 500 gigabits. So lots of things have changed. Many things in DNS, policy‑wise and operational settings, have not changed in that time frame. So maybe it's time to start looking at it.

So, if you take a picture of your friends or yourself and you post it on Facebook, when will all your friends see it? Well, you know, it takes no time. But if you want to make some changes in DNS, things start looking a little bit sluggish, so ‑‑ and unfortunately, you only find out about these things when you want to make the change. And where you are in urgent need to make the change. So, things take even longer because you have to learn the process and go to the right place and talk to the right party and then you have to wait.

If you are in the DNS hierarchy, well, I am going to be talking about parent and children, example of a parent could be look the root zone TLD operator and a child could be like your private domain, your company's domain, your favourite cat viewing domain, whatever it is. And in the ICANN world we have certain rules and ccTLDs, they set their own rules and when things are working everybody is happy. When things get out of ‑‑ something breaks, it's usually not the entity that made the mistakes that gets blamed. Frequently, the resolver operator gets blamed when somebody publishes wrong information. And we had a very good example of that a few weeks ago; how many of you remember the HPO now rollout? How many of you got rejected by your ISP/resolver because you tried to go there? How many of you sent messages to Twitter or Facebook about censorship by your ISP or anything like that or ineptitude of whoever? Well, almost everybody who got blamed in there was a resolver operator. But they were doing the right thing, they were validating DNSSEC, that the publisher, HPL did not check what the status of their delegation was, it's their problem, but it made lots of people look bad. There are some technical things we can do as a large DNS operator, but there is ‑‑ they are not everybody and we don't necessarily know who to talk to and. CloudFlare is very interested in making the Internet better. That is one of our missions, so when we see a problem, we are allowed to go out and talk about it and that is why I am here.

We are the largest third party DNS operator in the world. We have somewhere between one and two million domains that we are operating. Any operator that has more than ‑‑ zones operated is also a registrar. We are not a registrar; we are just ‑‑ so everybody has registrar domain somewhere, you come to us with their domain, we have thousands of customers coming to us every day, we have thousands of customers leaving us every day. The numbers keeping going up so we are getting more than we are losing so we must be doing something right.

And when ‑‑ when a customer comes to us there are certain hiccups in the systems, when they are still a customer things that go that we would like to do. One of the things that we get experience is we get lots of unpopular domains. For whatever definition of unpopular. So many of our customers gets DDoSSed all the time. We have more traffic coming to us that is attacking us than the traffic that we are actually answering. There was a very good talk that a co‑worker of mine gave at the DNS workshop on this topic.

So, a third party DNS operator is somebody who is not part of the DNS registration systems, it is only has ‑‑ has deal with the owner of the domain, and there are many of us. It could be you, as a friend of your ‑‑ a friend, you could be paying a CTN, you could be paying somebody who has given you a DNS appliance, whatever. But the thing; we are not under anywhere in the registration records. And as matter of fact, many of the more popular or important domains are operated by third party operators because of the service we provide.

This is the traditional ICANN registration model. It has been copied by most TLDs in the ccTLD space. There is a registrant who talks to another register or reseller and 99.99% of the time the registrant does not know whether the entity is talking to is a reseller or a registrar so I will conflate those two terms into one. And then the registrar sends the information up to the registry operator and then publishes it in DNS and somebody tells the registry what the policies are.

OK. As the third party DNS operator I would love to be able to change information the DNS without having to go through the registrant because the registrant is not interested in logging into the interface for its registrar at any point except two; when he is coming to me and when he is leaving me. At every other time, they are going to ignore my e‑mails. So if I want to move somebody away from ‑‑ because they are sharing a name server that is always being attacked so I want to move them to another one, I need to involve them; I can't change it for them. If I want to introduce DNSSEC this year, I can't upload the record without talking to the customer. I can do it when they sign up but for my existing customer base I have a problem. If I have to change keys I go to them all and say please, please, this is really urgent, please do it, please. And they will ignore me.

So, it is a problem for the stability of the Internet.

So, the system is not reliable. It is not timely, and I would like to change that. I would like to be able to do this for my customers without them having to be in the loop. I think many of you who might be customers of minor somebody else, would like that, too. If you don't, you can always set up and say no. When they are trying ‑‑ when I asked them to copy information, they may get cut and paste errors, whatever reason, whether it is an IDN issue or typing the wrong code or whatever, there are so many cut and paste errors we see.

Well, some of you brilliant people will say you can become a registrar that will solve your problem. Not really. Because we can't become a registrar in every ccTLD, we have registration in basically every open ccTLD, customers in every ccTLD in the world that is opening for registration. When a new one comes on within a week we have some customers there. If they give us access to their whole registration account, we can do everything, including moving the domain. We don't want to do that because it's a bad idea.

And becoming a registrar in the ccTLD space in many cases is difficult. I will leave it at that.

So, like I said, we want to be able to change information that only refers to the DNS information that is in there and this is DSes and possibly the glow access record. One of the hardest thing we have is to find out who to contact if we need to make a change. Who is absolutely useless. There are a number of TLDs that totally block our systems. We get back Whois records totally wrong. And when we get something back it has very 20th century information like phone number, fax number. There are no URLs, there is nothing that my cuteers can hook up, with thousands of customers that I need to have contact in the day, that doesn't scale. Secondly, authentication, authorisation is important. There is a proposal that we did on how to do DNSSEC Trust Anchor maintainers in band. It works fine if people work for but it's not realtime. So, but it can be used as a part of our realtime system.

So, I would like to get everybody to talk to their TLDs and tell them that, yes, you would like them to allow DNS operators, somehow, to make changes into the system, either via registries or registrars. If I am talking to the registry, it should be able to tell me what registrar I should be talking to for each domain because customer may come to me saying I am with registrar A and then they change to B without changing the DNS settings, so I don't know when that happens.

OK. This is what happens, what has to be done. It's a lot of work. But I am willing to help on getting it done.

So, start thinking about if this is something you are interested in. If you are worried about, because the last time ‑‑ do you not want to find out what is stopping you when things are going wrong. And I am looking for more ccTLDs who will participate in experiments of doing things like this, allowing me to modify the records.

DNS TTLs is a second issue of concern to us. For those who don't know about it, the meaning of it. TTL is this ‑‑ depending on your policy, resolvers honours this most of the time, sometimes they chop it on the top end or the low end, and there are some resolvers that are not. TTLs are very important to keep information close to the edges for pop la data for unpopular data it doesn't make a big difference. There are effects of it. T Ls, long TTLs have been associated with stability but they also mean that DNS is an inconsistent state, if you consider during the transition from an old value to a new value, DNS is an ‑‑ loosely coherent database system so inconsistency is expected, it's a question of how long does it take to settle on the new values. Short TTLs are used a lot. They were very unpopular at the beginning, now they are becoming extremely popular and useful for many players. The biggest reason why they are ‑‑ we had these long TTLs used to be reliability. Links went down, computers went down, the expectations today are totally different. We have how many ‑‑ how long is it since you heard about a TLD, a major TLD going down? All their serves went off‑line. It's a long time. There have been DNSSEC failures that have brought down TLDs but not the operation of the name servers per se.

Unfortunately, the cost and benefits do not line up nicely. It is easier for a DNS parent to have long TTLs because it means they have to answer fewer queries. For the consumers like many of you in this room, that is not necessarily good, like I said before it takes a long time to get the ‑‑ if the TTL long changes take a long time.

There is a myth that the TTLs only affect the zone operator. The resolvers may do more look‑ups, somebody posted on Twitter yesterday, oh, no, I changed all my TTLs and I didn't see any increase in traffic. Well, that was wonderful news but he is not a good example because he has the ‑‑ his servers are both ‑‑ also recursive for the local information on the local side and as it is a small university, it's not access that had much from the outside world.

Yes, on this one, for a long TTLs it is the time to settle that is affected and also with long TTLs it's much harder to diagnose problems because people are not aware of it and it depends on what is is in your resolver when you ask the question and you may not get answers because you are talking to different resolvers without knowing it because many ISPs have started to use Anycast DNS servers.

The records that are affected for this for me are the delegation records, the NS and DS and effectively, because of the way we have no idea how resolvers operate, we DNS operators have to assume the worst case. That means the maximum of the parent and child TTL on DS and NS record. And so, we could say that the child is a hostage, probably a little bit strong word but I want to get your attention. So what is the state in TLDs of it. T Ls today? Well, 30% have NSes that are two hours or less. Vast majority that is between two hours and a day. With almost all of those at the upper end. And there is a small ‑‑ there is a small group that is even bigger than that. OK. So you may say that is not that bad. Unfortunately, some of the biggest TLDs are in the middle box, except com is in the top. Com and net are the bottom box which is bad. Moving a service to CloudFlare takes two days. If you, on the other hand, are in .nl or dot Czech Republic, we can do it in a few hours, so if they can do it, why can't everyone else? Oh, and if you are in Russia, .ru, a week.

The way I would like to approach this discussion when you take it to your home countries and home places is, think about goals; how long would you like an operation to take if you had your choice? I would love to be able to tell all my customers that they can move their service over to me in a fixed number of hours, no matter what TLD, four hours sounds great, two hours would be good, even better, but I am realistic. DNSSEC, when we are doing DNSSEC rollovers, there are multiple operations that have be done in the right sequence. Right now for most TLDs we have to do these on multiple working days. To change the DNSSEC keys via org, when I ran that experiment it was basically a week if you started on a Monday. And you did not forget to do it before ‑‑ on any of the days you had to do action but you had to do an action every other day. So it is hard. It's much easier for operators not to mess up if they can do everything in one workday.

OK. So I am here to see if there is any interest in talking about this, pushing towards moving the DNS and its operations more in line with user expectations. OK. And the bonus, I am going to be signing every domain we have later this year. We are using an algorithm that 80% of validating resolvers today support, according to measurements by Geoff Huston, so if you are in the 20%, you have a few weeks to update, unless you are RIPE; I will go public with that one of the name servers on this does not support ECDSA today or it did not an hour ago. I am told they are going to fix it; they have fixed one and not the second one, as of this morning. It's defined three years ago. OK. I am ‑‑ I am now putting on my as best toss suit and I am ready for questions, comments.

AUDIENCE SPEAKER: Aaron Hughes. It looks like there is a bunch of different proposals in there. Updating DS records registrar I think is a great idea and would be lovely to have as standard for to allow for third party authentication and modification, require some kind of API AP ‑‑ it would be really nice to see a proposed standard for what that looks like, so many different registrars with so many different programming abilities particularly since many of them are let's say not self‑sufficient in being able to code that kind of implementation for their customers. You know, it's easy enough to go after someone very large and say could you implement an API for us, we would like to have third party access, it will be different for somebody else, if you are going to go for approaching something like that I wouldn't suggest go talk to your registrar but rather come back with a proposed standard, here are a bunch of tools we can arm with you to talk to your registrant and but I think it's a great idea.

OLAFUR GUOMUNDSSON: Yes. I have been going around talking to various players and trying to get people that are in the registry world, registrar world, DNS operator world, to start talking about what are the requirements, what they want, and then we can sit down and write a standard and we will propose it later this year. There is going to be a workshop talking in into the too distant future where a number of us are going to sit down and talk about authorisation model of it, which is the first part, specifying the APIs hope plea is going to be a trivial exercise, once we understand how to authorise the parties. Thank you. Very good comment.

JIM REID: Speaking for myself. I think this is an interesting idea and it's worth investigating further. I have some concerns, though, that this looks to be an attempt to use the DNS protocol to fix a problem in registry operations. And I think that is a problem that is not ‑‑

OLAFUR GUOMUNDSSON: I don't agree with you. This is all about operations.

JIM REID: Well you see, part of the problem is I think for a lot of the TLDs particularly ccTLDs spaces they are not updating their zone file at a fairly frequent interval. It might be happening once or twice a day or maybe every three or four hours at best. So you don't get the dotcom experience or the dot UK experience where the zone is updated almost in realtime or very close to realtime, whenever a delegation is changed. So I am not sure, in those circumstances, that fiddling warned the ability to change registry database entries, to change TTLs will have a marked effect because of the fact you are dealing with a daily generation of its own file and it pushes that out to all the name servers. Earlier on you said you would like the ccTLDs to be more involved in this and that surprised me a little because I would have thought that the gTLD space might be more amenable to be the crash test dummies because there is a uniform contract there and it's a whole bunch of of new kids on the block so they might be more amenable to new modes of working whereas more attitude of we have always done it this way particularly in some of the ccTLD land.

OLAFUR GUOMUNDSSON: In the ICANN space, there are certain politics and policies involved that I would prefer not to get involved in until I have a good solution to present to ICANN.

JIM REID: I appreciate that. But I think if you try to negotiate something between 100 or 200 ccTLDs I don't think you are going to get any hope of finding a consensus...

OLAFUR GUOMUNDSSON: I am looking for 2 or 3 that are willing to. Want to do some experiments with me, there may abfew others, if you want to talk come and find me today and tomorrow. I am only here through tomorrow, or send me e‑mail.

SHANE KERR: I am going to cut the lines here because we have already quite a few people.

Matt Pounsett: I think some way for third party DNS operators to update registry information is important. I was telling you this the other night, as much as ten years ago I was suggesting this at a ccTLD I was working for, our technical contract should be able to update technical information. It's also my problems to be able to do that. As you were saying, there are issues in the ICANN space with trying to have registrants directly or third party operators directly talking to the registries but it might be a good to try that, at least. I agree, it's a difficult political situation will, but if could you get those contracts updated to allow that it would solve a lot of problems.

OLAFUR GUOMUNDSSON: Yes.

AUDIENCE SPEAKER: Cz.nic. We have created about maybe nine years ago OpenSource registry called Fred which is used in about eight other countries and I think that we have similar thought when we were designing it because we created specific objects for name server sets and key sets that have different access rights for APP clients so it's possible to have APP client which is able to modify just those objects, which may be something what you are calling for, so we are happy to cooperate with you with this issue.

AUDIENCE SPEAKER: George speaking as a domain name holder. I have a lot of sympathy with what you are trying to achieve because there are interactions I have with my registrar/registry combination that I find intensely frustrating and these are not easy transactions and the timing components are frustrating. I am drawn to observe that when I interact in other spaces such as web hosting or with other providers it is quite routine to say here is a hash I made, prove that you have ownership of what you are trying to do by lodging that in the resource, the web or the DNS and if do you that, I can talk to you better because I have here and now, evidence of your intent. And whilst I can understand why Jim is saying in band signalling in DNS for operation is scary, there are drafts on the table about intense signalling for DS from the child up to the parent. So, the idea of saying, here is a token that I am going to give you, prove you have got control and make a change and I will respect that, I could understand that process providing live in‑band changes. But I would also observe, although this is very hard for me to say, I have some sympathy with the registrars because their economic model is predicated on keeping me as a customer for at least a year and doing as little as humanly possible at cost for me, and since what we are talking about is trying to improve the ability for me to make ram done changes on the fly, that is very bad for their model. So you could expect some push back.

OLAFUR GUOMUNDSSON: I am expecting push back from basically everybody involved.

AUDIENCE SPEAKER: Steffann. There is not only an RFC draft, there is an RFC that you wrote together with Warren and some other folks, 7344, that describes how this is being done so there is no technical problem here so what you are trying to solve light right now is more of the political problems, how to get ‑‑

OLAFUR GUOMUNDSSON: There are two issues we omitted in that RFC: One initial trust; number two, timeliness. That is what I am trying to address here.

AUDIENCE SPEAKER: Right, but I don't know if you can solve the initial trust. You can't solve that witness the DNS protocol itself, right?

OLAFUR GUOMUNDSSON: No, I can't, that is why I need access to the registry system to put the DS for the first time up there.

SHANE KERR: I don't know who was next.

GEOFF HUSTON: APNIC. I was actually responding to your TTL comment, and I must admit, it sort of seems to me that the DNS is one of those things where the current set of provisioning, because of attacks, is up to the second but the lies we tell ourselves about how to configure zones, is somewhere back in the stone age. And this idea that you set your TTL to 48 hours or a year or three years, because it's never going to change, is just nonsense, and, you know, I kind of like the idea that the entire named resolving system is actually provisioned to attack volumes, set your TTLs down and you won't notice the difference but you will be meeting expectations that I want to change, it can happen quickly, rather than waiting until next week. So, you know, ECDSA, good idea, short TTLs, good idea, putting some of the provisioning back in the DNS in line with DNSSEC, you know, get with it, good idea.

OLAFUR GUOMUNDSSON: Thank you.

PATRIK FALSTROM: Also speaking for myself like everyone else here. A few comments first of all regarding TTL, I completely agree with you from my own experience on thousand do transfers ‑‑ there is a reason why someone would like to make those kind of changes in DNS and that is most normally the donating party don't want to cooperate, they have screwed up, they don't do their job so you just want to sort of do the change so the TTL must be lower. What that should be to a proper balance, I don't know, but it must be lower.

The second thing that I think you should be aware of is that you said we don't want to become a registrar. So here, you would like to interfere with the distributed database model and synchronization between registry and registrars, to communicate directly and take over the job from the registrars and of course they will lie to you, they will probably do push back, OK. So I think honestly that the registrars, I don't know what kind of data you have, that registrars you talk to, I think registrars must rather at least sort of the same ones work on having you talk to the registrars instead of the registries because we have to remember that the database model that is used in EPP is based upon changes made in the registrar and be pushed to the registry. Every time you have changes made in the registry that have to be syncronised back to the registrar is quite really complicated operations.

OLAFUR GUOMUNDSSON: Yes.

PATRIK FALSTROM: And we also have to remember that the registrar is the one that has a contractual agreement with the domain name holder on the actual functionality. So I think you are working towards pretty tricky situations here which is not only the fact that people are not cooperating. Thank you.

OLAFUR GUOMUNDSSON: I agree with you, Patrik. I don't really care whether I am talking to the registry or the registrar but in many cases I will need the registry to tell me how to find the registrar.

SHANE KERR: All right. Thank you. I hope you got what you wanted out of this session.

OLAFUR GUOMUNDSSON: Hopefully, yes, it was very positive.

(Applause)

BENNO OVEREINDER: Next up Job Snijders, a plenary regular in the many time, with interest but and very entertaining presentation.

JOB SNIJDERS: Good morning. Today I would like to talk to you about an idea I have been floating around in N N Ts engineering called IRR Lockdown. My name is Job Snijders, I work for NTT, a small ISP predominantly based on this planet and I busy myself on a daily basis with tools, automation and routing security and this talk is about the latter.

Today we will cover very briefly what IRR is, what kind of issues we are facing on a daily basis and new method of protecting at least part of the IP space that is out there called IRR Lockdown, and the launch of a debugging tool with which you can assess whether you would be impacted by an IRR Lockdown, or not.

IRR and RPSL were created in a time with the Netherlands still had a queen, I was walking in diapers and it's a technology that is really old and only now 15 years later one or two percent of the features are actually used and the purpose of the IRR is that you, somehow indicate to your up‑streams or your peering partners what you intend to announce in the BGP routing table. But there are some issues. There is absolutely no incentive for people to clean up old entries because they never break anything, unless there is a small route leak. Most IRRs do a very poor job at verifying whether they are actually allowed to admit the route object into their database. An RPSL itself is really hard to parse, it is not even a real language, I would consider it a modern piece of art.

IRR has been abused over the last few years, a very recent example was documented by Andre from BGP MON and we found out that spamers would register /24s in RIDB and those /24s had not been in the BGP routing tables for the last four or five years and by registering these routes in the IRR, transit providers would pick them up and put them on the allow list in their prefix filters. The spammers then would announce those prefixes for eight hours, spam the be Jesus out of it and withdraw the prefix and continue with new stolen IRR hijacked prefixes.

And there is, at least a partial solution to this style of abuse. And I call it IRR Lockdown. The trick is, that you only honour a route object that comes from the appropriate RIR IRR's database and has been properly authenticated. It also means that we would ignore route objects that cover, for instance, RIPE‑managed space but do not come from the RIPE registry itself.

Let's have a small overview. IANA handed out blocks of IP space to the various RIRs or I am ignoring legacy stuff at the moment, and those RIRs have a job, which is to give the IP space to their member base or participant base or whatever they call it, and different RIRs have different policies when it comes to IRR; some RIRs have no IRR database at all; some IRRs are allow anybody to create anything in their IRR database so it's not very trustworthy, and then there is RIPE, our bright light on the Horizon, that one hopeful beacon.

If you compare the RIRs with each other, one very important question is, does the RIR validate whether the guy that wants to create a route object is actually authorised to create that route object. RIPE, in their implementation, does this verification, and even better, if multiple organisations need to approve the creation of a route object, and you have not yet gathered all the approvals, RIPE will cube that on to on to everybody that has a say in it, press "OK" and then it will be submitted into the database. So this makes it very end user‑friendly.

So, knowing these differents between RIRs, knowing that RIPE stands out, as an Internet service provider I can trust that any route object in the RIPE database that covers RIPE‑managed space, is actually there with approval of the owner of the IP block. And this is a super useful feature which I will elaborate on how we can use that.

So, knowing that RIPE administrates roughly 35 /8, give or take some change, NTT is considering to only allow route objects if they cover RIPE space from the RIPE registry itself and ignore route objects that cover RIPE space if they come from a different registry like ARIN, RDB NTTCOM itself, any of them. And this will make much, much harder to do the IRR hijack trick that I mentioned earlier that the spammers used in this case, because even though they can register route objects covering route space in any database, N T there. Just ignore those entries and not consider them in the prefix filter generation.

So, if you look at it more technically, we have an instance called RR dot NTT .net which is an IRD D instance and that instance mirrors quite a bunch of registries around the globe. Those registries submit updates or new objects over a protocol called NRTM, towards RR dot NTT .net, and if those updates come from a registry which is not RIPE but the route object covers RIPE space, we will treat it differently compared to what we do today.

Benefits to this are that the hijacking of space becomes harder because you can no longer create unauthorised route objects. It also means that a lot of still data that is currently in the routing registries, which is no longer valid, no longer in use, will be ignored, so our filters will be smaller. In general, you could say that anybody that uses rr.ntt.net to generate filters will have more trustworthy filters and we will use that instance of course ourselves, as well. And because of the size of our network this will actually have impact on a global scale, which is nice, so this is no longer an academic exercise, this is actually mean something for your address space if you register it in the proper IRR.

Now, the big question, of course, is, how much of the Internet will break if we deploy this? And it will only break a little bit, so that's good. In November, I ransom statistics, I ran them as well two weeks ago, there was very little difference between the two, so I am using the November data point. There are currently 1,000 prefixes for which there is no route object in the RIPE database but there is a matching route object in a non‑RIPE database. So those prefixes potentially could be dropped if we apply this style of filtering.

Fortunately, only 500 of those prefixes are within NTT's customer code, so that already reduces that issue to half the size of what it was. And out of those 500 that remain and are within our customer code, half of those belong to a single organisation, so if they fix their stuff, then only 250 prefixes could be in jeopardy. So this is why I am flying around and giving talks like this, to inform people, please check where are your route objects.

So, that much of, say, 250 prefixes out of the 165,000 customer prefixes that we have at this moment, it's a very small percentage and it's so small that I can just get on the phone and call each individual and encourage them to move their route object to the appropriate place. There is a very detailed statistical break down on this URL, which you should visit after the break.

So now, let's go over a solid example. IANA, here at the top, gave 193 /8 to RIPE NCC, therefore it's RIPE‑managed space, and RIPE's job is to give that space to its LIRs. On the left side, we see a proper route object. It falls within the RIPE‑managed space, it's stored in the RIPE registry. This means that it has to be ‑‑ has to have been authenticated when it was created, perfect. However, on the right side, we see the same prefix, different origin, ASN, in a different database, and this was created without any approval of the Inetnum owner, the RIPE NCC office. So the question really is, why would we ever honour objects like that when we have no knowledge or no assurances that they were created with approval of the IP block owner?

So, in our new strategy, this object will be something that we just flat out ignore. The way we would implement this change is we add 200 lines of code to the IRR D code base, that validates whether this is within RIPE managed space or without. If it's outside RIPE‑managed space or legacy space, it will be just business as usual. But if it's inside RIPE‑managed space, the IRD instance will rewrite portions of the object, so you can still query it but it will no longer be considered in our prefix filter generators.

And I build a tool to figure out whether you are in trouble or not. I have done the hard part, I came up with a name, I got the logo designed so that was all beautiful, until last week I realised that I should actually write some code and, you know, launch it here. So the last 100 hours I have been typing like a madman.

The purpose of IRR explorer is to make it easy whether IRR Lockdown will affect you but also to give you a general sense of where are route objects and what is the global view on a given prefix. I have noticed that quite some people that have large blocks and have had them for 10, 15 years, over the course of years, they never realise that had their customers created all kinds of route objects and all kinds of databases, or even worse, all kinds of networks started generating proxy route objects for them, and they never had the incentive to go look in this different databases and see what is going on. So for a lot of people, it was quite a surprise, if I told them that aside from the /16 in the RIPE database that there was also /24 in RDB and some /29s in NTTCOM, what is this stuff doing there? I never approved that and it was never easily visible. So enter IRR explorer. I was also tired of typing gigantic one liners on the comment line to go over this data. I wanted a pretty web interface. This is 2015 after all.

And this is the URL where you can go and type a prefix. It will give you results, it takes about 10, 15 seconds for the results to come back. That is very long but it is realtime. Also, the site can only handle one visitor at a time so if all of you go to the site at this very instance, you might have to wait a little bit longer. Even worse, during the talk before this one, I discovered a Mann leak so I had to add a terabyte of swap space so we can survive this session. The good news, all of this is OpenSourced and licensed under the BSD style licence so you can use it for any purpose you want in your commercial applications or not, and feel free to submit issues or send me pool requests that offer contributions.

What IRR explorer does, it's this Daemon here in the middle I have drawn it, and when it boots it will fetch the latest full database dump from roughly 10 IRRs. It will parse that dump and then open a TCP session to the NRTM host and start mirroring the database in realtime or near realtime. Then, in a separate process, it takes in BGP feeds, so it can correlate the data between what is an IRR and what is in the default free zone and the BGP feeds come from the NLNOG ring looking glass which gets about 50 full tables so there should be quite good visibility in terms of what is in the BGP tables.

And then you go to that website and type in a prefix. And it will query all these data sources and compile a report for you.

I need to thank Nat Morris and Peter Vandyke, you made it possible to launch today. Without you, I would have been here with the cone of shame. So thank you, guys.

Now, this is an example of an NTT /16 that I put in, the /16 is very old, and you can cannot really read it but what you see here is various IRRs, you can see which original ASNs registered for which prefixes and it will tell you whether it's visible in BGP or not. And it ‑‑ on the right side, it will give you advice ‑‑ it is advice, and advice could be something like perfect, you registered your prefix in the RIPE database and there are no more specifics in any other database and you are visible in BGP. Or it might be, yes, you have a route object in RIPE with a given origin and we see the same origin AS in BGP, but you should be aware that there are different registries which also have a route object that you might not be aware of and that advice could be try and see if you can clean up some of those proxy registrations. And if it's red, then you are in trouble, that means that either there is no route object at all anywhere or that your route object is in the wrong database if it's RIPE‑managed space.

If we zoom in on a prefix from Nat Morris, his Anycast DNS services he is originating this from his RIPE ASN, perfect, we see that in BGP. However, we also see a different route object with an entirely different origin AS in the ARIN database. NAT doesn't know why and he did not know until I showed him the tool. If we scroll to the right we see that level 3 has yet a different origin AS, and NTTCOM is apparently also participating in this weird game, this is the only entry that NAT purposefully made, the only one that he was aware of, the one in the RIPE database. And apparently some of these are proxy registrations, if you are a transit customer they will put in proxy registrations with their own origin AS, I don't know why. One of these is a DDoS mitigator although he didn't pay for a mitigation service. It's also interesting. There might be a lot of still data covering your prefixes out there in different databases that you were never aware of and this tool should help you discover those resources and then you can contact people and say, get rid of this, I did not approve this.

So, looking at the time line of IRR Lockdown, I recommend that you start using IRR explorer or a different means if you have already tools in this area, to see what the current state of your IRR data is and whether there is improvement possible. IRR explorer will soon get support so you can input an ought numb and it will just do an inverse query and show you everything instead of going per prefix. And yes that support will come. And deploying IRR Lockdown tentatively, I would say this is in the first quarter of 2016. That is still far away and it allows me plenty of time to call everybody and get them to fix their IRR data.

One small thing I would like to remark in this overview: If you input a sing IP address or a prefix, it will search in the databases for the largest covering aggregate either in BGP or in IRR, and it will then show you any more specifics of the largest aggregate it could find. So even though you input a single /24, if that /24 is part of a larger cluster it will show you everything, and this should make it easier to put your information in perspective.

There are some networks that already committed to doing a similar style of filtering. One I like to highlight, opt max, I smoke with ‑‑ a few months ago and pitched this idea, and then we parted, he went home, I went home and apparently he secretly, he already starting implementing this without telling me so this is the only network I know of that is actually doing this policy today in production. ECIX will do it sometime later. And in 2016, anybody that uses rr.ntt.net to generate their filters will automatically benefit from these changes and this includes NTT itself. And I recommend that others will follow this strategy as well because it's nice if one network does it but if a ton of networks do it, then the effect will be even bigger.

This concludes my presentation. I will now be taking questions. We have about five minutes left.

BENNO OVEREINDER: I think your was trending topic on Twitter.

AUDIENCE SPEAKER: Sam Weiler. Is your view of RIPE's address space static, how often do you think that might be updated?

JOB SNIJDERS: RIPE has multiple ways of publishing what address space they manage at a given time. They have a FTP server, there is RPKI route certificate which contains a list of what they manage. And in our implementation we will fetch those publications on a daily basis and on a daily basis refresh.

AUDIENCE SPEAKER: How do you imagine this will interact with transfers, inter IRR transfers?

JOB SNIJDERS: At the moment, somebody with transfer space from, say, ARIN to RIPE, RIPE will add that block of space to their RPKI suit certificate, and from that moment on, I consider it RIPE managed space and the route object should be in the RIPE database. Transfers should not be issue. Same for legacy space, it is not considered in this at all so that is just business as usual. Yes it supports IPv6.

JEN LINKOVA: That was my first question, the whole talk was about legacy protocol. Good. Second question was ‑‑ you mentioned like you checked number of prefixes which you might probably reject, right? I don't think that all prefixes are equal, some prefixes are more equal than others. Have you checked the traffic level, for example? How much traffic would be affected?

JOB SNIJDERS: No. I am a networker, you know, payload is /PRO*E overhead.

JEN LINKOVA: OK. And the last question; so you say, like not a lot of prefixes actually going to be affected. What if you look at prefixes which are not using RPKI? And let's say, what percentage of, if you basically exclude all proper assigned prefixes and look only of number of prefixes which are not properly assigned how many of them actually are ‑‑ will be rejected, I am just curious if RPKI is solving the problem

JOB SNIJDERS: I have made no comparison whatsoever with RPKI data but we could definitely research that.

GERT DORING: Just a random networking guy from the street who has been affected by garbage in the RADB a couple of times in the past.

JOB SNIJDERS: There is a self‑help group for that now, for people that got affected.

GERT DORING: Anyway, my point is thanks for actually undertaking this because, well, there is authenticated data but it's spread around the place so having it all in one place but authenticate what can be authenticated is a helpful thing. And I would hope for a deployment earlier than 2016 so I can point my other up‑streams to actually use that and stop ‑‑

JOB SNIJDERS: Can I mention a company the size of NTT won't move as fast as ‑‑

GERT DORING: I just want to voice the sentiment. Thank you.

AUDIENCE SPEAKER: George from APNIC. I could be really short and really blunt and say if you sign your intention to cryptographically provable and a lot of these problems go away so just sign what you want to have in routing and this problem goes away. But to go a bit further: Your slide, where you showed an entry in the right routing database from one AS that was correct, and another entry in RADB that was red and evil, you were essentially, I think, saying two things: The first is, you had a priory knowledge, you had outside knowledge for AS 666 is evil; you need that to paint it red. And the second is, you seem implicitly to be saying that you now believe only the inetnum needs to state the authority over the original AS. That seems implicit in what you are saying.

JOB SNIJDERS: Absolutely.

AUDIENCE SPEAKER: A ROA is one to one synonymous with this and if it's not legal for AS 666, a ROA will say this, so you could make a route object in the presence of the ROA and ignore all other route objects, no?

JOB SNIJDERS: I could agree that ROAs could fulfil a similar role. However we have some legal concerns when it comes to obtaining all required route certificates and with this methodology we do not have that. Also I mentioned, this is 200 lines of code, so it's like, it's low hanging fruit

AUDIENCE SPEAKER: I do see a lot of significance could you not regard the control by the ‑‑ as material to this specific information because current state code, RIPE code, the AS holder must authorise.

JOB SNIJDERS: Correct

AUDIENCE SPEAKER: And you have moved quite a way beyond that and for me that is significant. You are saying what the AS holder thinks isn't material, it's the inetnum holder.

JOB SNIJDERS: I am not saying that. I am only saying the route object should exist in the same database as where the inetnum is hosted and in the case of RIPE I know that both INET mum and aut‑num holder approve this and I am happy with the assurance

AUDIENCE SPEAKER: In Asia quite a number of people have address space but not AS because routing practice is different.

JOB SNIJDERS: This is precisely the reason I am starting with RIPE managed space and not Asia.

AUDIENCE SPEAKER: It's applicable in the footprint of interest in the community you are talking to.

JOB SNIJDERS: If this demonstrates to be successful I can extend to different RIRs and I would be happy to discuss that with you.

AUDIENCE SPEAKER: The BoF tonight to talk about cross reg ‑‑

JOB SNIJDERS: Absolutely.

AUDIENCE SPEAKER: I think neither of us can be brief. Martin Levy from CloudFlare. I want to talk about two things, very quickly on the subject that you mentioned, you believed you had a small number of players that you could contact manually to update their records, and I invite you back at the next RIPE meeting to tell us how well that process went because I think you are fooling yourself if you think that will go anywhere, from past experience.

JOB SNIJDERS: Optimistic

AUDIENCE SPEAKER: You are, you are young and optimistic and I commend you for that intensely and I will not be old and cynical. Second point, and I was going to mention something very similar to George but he eloquently hit it; I think you cannot ignore the signed RPKI information, I think that is a little foolish to do that. Independent of a very small statement that you made, which I am going to call you on, which is you said that you may have contract or legal issues at getting at some of that data, which I fully understand. I would remind that you essentially your AS is from NTT America, and I ‑‑ and I know that you are in Holland but there is an entity in your organisation that can quite happily deal with the contractual problem you have at getting at one of the five certificates that you need to continue that work and I recommend that you go after that, such that you can take the RPKI side of the data and actually do something useful with it. It's far more valuable that this IRR data, I talked to but this in the past. I was as brief as I could be.

RUEDIGER VOLK: I am tempted to follow up the RPKI stuff with marte, but I spare you that right now. Well, as we have come to expect from you, nice and good ideas. Maybe a few details need a little bit more drilling down. One of the ‑‑ overall, I think seeing someone to really operationalise the idea of filtering a single IRR to the part of it that is more reliable than others, other parts, is a nice thing. I would have liked to do that for quite some time for quite some databases, and didn't find a reasonable way. I certainly, I certainly would like to see the RPKI data included, and the legal problems are there and I think cannot easily be resolved on this continent. For the filtering of the RIPE data set, I have to report that our practice of using RIPE database is, we are also taking care of the few customers that, for whatever the reasons are, are using resources from several RIRs, and the interesting thing is, how to resolve that when the AS number and the IP address pool come from different RIRs. And the way ‑‑

JOB SNIJDERS: I will answer you quickly. If you have, say, ARIN space but you registered in a RIPE database, this is technically possible, that space will not be affected because I only look upright‑managed space. There is a BoF today at 5 that covers cross registry authentication and this is precisely the place to talk about what if the aut‑num is from ARIN and the prefix from RIPE or vice versa, such scenarios, today, are messy, but we should work on a solution. So come to the BoF, please.

RUEDIGER VOLK: OK. One more important things is people who are creating that kind of problem usually don't find good advice at the moment. Some people have their way to deal with it and as we move forward here, it would be a good idea to ‑‑ not to crush established practice that has been there for some time.

ROB SNIJDERS: Thank you for your comments.

BENNO OVEREINDER: The BoF is at 6:00. In the side room. Thank you very much, Job.

JOB SNIJDERS: Thank you for your time.

(Applause)

BENNO OVEREINDER: Next up, Chris Grundemann. And he is on a mission, getting operators to the IETF. And he is running a table so there is no excuse to come over to the table and get some information about the IETF.

CHRIS GRUNDEMANN: I am going to talk about operators and the IETF, I want to talk about what I mean. So operators, today is mostly ‑‑ most of you but it's not just ISPs, this is content providers, enterprise networks, really anyone who is operating a network is a network operator is an operator for at least my use of the word. The IETF, hopefully most of you are familiar with it. The mission is to produce high quality relevant technical and engineering documents. They are trying to make the Internet better, they are the standards organisation for the Internet. And the operators in the IETF, the dream of the two together is they work together, we all work together and everything comes outright, operational requirements and realities are reflected in standards and in best practices and so that the things ‑‑ standards and documents, the protocols that are developed by the IETF are usable, day one, right out of the gate and everything cycles and flows and works perfectly. Obviously we are not quite there, there is perception that a lot of operators aren't engaged enough in the process, a significant number of operators, especially smaller ones, medium‑sized ones and from developing parts of the world aren't represented at the IETF, they don't show up and come and join that conversation. Academics and vendors have the whole floor and tend to lead the charge of standardised and what gets pumped out by the testify and that leads to sometimes not everything always lining up. So if operators aren't involved in developing the standards that they are going to deploy, they may not be deployable. Obviously this, whole things works pretty well, we wouldn't be here if it didn't, the Internet seems to function. But maybe it could do a little better streamline and become more efficient.

So, we came up with a plan, kind of three phases here, the first one was a survey of the operator community. You may remember I was in Warsaw talking to you, asking to you take this survey. The first six months of last year we brought together all of that information and collected all the data. We had about 369 folks respond to the survey and on of that we talked to a lot of people. Jan and myself flew around the world, went to network meetings all over the global and talked to people in hallways and bars and restaurants and collected all this data back together. Phase Two, what we have been doing since then is pulling all of that together and looking at it and trying to see where the problems actually lie and maybe suss out some solutions as well. And the third phase is going to be from here on, basically having this discussion and trying to find solutions, things that we can do to make the world a better place.

So, first I want to look at the the baseline, the results of the survey. And then go from there. On these graphs, I think the legend is probably too small but the red and blue, the red is agree and the blue is strongly agree so you can see here that the vast majority of folks who answered the survey self identified as operators, and even more said that they had a technical role. Within those roles, a huge percentage said they are engineers, and slightly less said architects, which is a little interesting that they have said, you have said you are both, engineers and architects at the same time. Not quite half said they were developers and just a hair over half said they were managers. So that is the feel of who entered the survey. The big question of course, are you participating in the IETF. The blue one there exactly half said no. No participation in the IETF at all currently. The red one is just on mailing lists, that is about 30%, 2% said they only go to meetings and don't participate in mailing lists. That is probably a very ineffectual way to participate. And 1% said they are actually actively engaged, on mailing lists and go to the meetings. They are active IETF participants.

So maybe we can confirm this. If you are, consider yourself a consider participant in the IETF, raise your hand. So maybe a little bit lower than 18% today or people are tired. So within this, this is a big wall, if you look at the small numbers first, I never heard of the IETF, only 4%; I don't know what the IETF does, only 8%. I don't believe IETF documents are relevant, 14%; and I don't need to participate, 27%. So what this says to me, most of you know what the IETF is, understand what it does, find it relevant to your job, and feel like you need to participate. So why are half of you not participating? Well 58% said they don't know how. And I think that is a big one. And then 44% said they don't feel their input is welcomed. Which is probably another big indicator.

Similar questions but just focused on mailing lists and again, only 17% said had he don't find content relevant, only 16% not interested. List noise is only 34% so it's not really list noise but still 54% don't know what happens on the mailing list. 44% don't even know how to join a mailing list. 72% said they don't have enough time. And so to that, I think hopefully everyone knows how to sign up for a mailing list. I think probably don't know where to go, how to do it which Working Group to join and a process there of finding a mailing list and knowing what is going on in that mailing list and then joining it.

These I am not going to go into as much, don't participate in the meetings and a big part what I would like to say is two things: One, remote participation is available; and two, most of the work of the IETF is done on mailing lists so if you don't know that before, know that now. You don't necessarily have to show up to the meetings so obviously here the big one is, I don't have enough trouble budget, 82%, that is not an issue with remote participation and mailing lists, that may be a bit of red herring and awareness issue rather than a problem of getting to meetings. And two that point, we took a couple of the questions to look at this, so half of you said you don't participate in IETF and about about half said you didn't know ‑‑ between meetings, and about half said they didn't know that there was remote participation for meetings. So there is all kind of line ups there, interestingly.

So beyond that, in addition to asking those multiple choice questions we asked a free form questions and talked to a lot of people and within those, as we looked, as I read through all of the answers that we got and talked to folks, these themes kind of emerged. I think, whether they are perceived or not, I kind of ignored because if you perceive it to be a problem it probably is, at least in your own perception. So, there is themes here which are time, culture, money and awareness. I will talk about what those are. I think this sums up the time issue, the IETF has grown so large and it is a full‑time job to participate. It wasn't a survey response, this was written by Randy Bush in a paper about ten years ago so this problem may not be a new one. And these are the kind of big numbers 72% said that they don't participate in mailing list because they don't have enough time and 64% said they don't come to meetings because they don't have the time. This makes sense; operators, you are actually running networks and doing things where you need to be there, be on call, be paying attention and spending time in the meta, may not be your type priority when there is fires burning in the network, right.

The next one is culture. And I think this quote sums it up "the IETF is not really focused towards operations and historically operator input has not been well received." Not everyone believes that but enough believe it that may be a barrier to folks, probably operator community participating.

This one I added "I perceive it to be full of pompous, self‑serving out of touch with reality technology actors." I added this not necessarily because I agree with it but I think it points to the cultural issue which is not just one way. So the IETF, may as a body may not be as responsive to operator input but we need to make sure we are approaching it with an open mind as well. I think this goes both ways, stones can be thrown in either direction and neither is right in that case.

Money is the next one and I think that is a red herring, even though it came up as a big issue for meeting participation, I think that probably falls back to the awareness of issue of you don't need have to be there. So awareness, 58% of those who do not participate in the IETF at all reported they don't know how to. So people, the mailing list questions and meeting questions, I think this is a big issue here as I said.

So, those are the problems. As we started discussing these problems with people, some solutions started to emerge and many of those came out of the survey. What I did is pulled quotes from the survey, and put them here as kind of basically ways of start discussion and things to start talking about. I do not condone any of these ideas. Some of them may be good and some probably very horrible but I think they are worth talking about and thinking about to kind of get those gears turning and have us try and find solutions.

The themes I found within the solutions that we have heard about are communication, outreach, and inclusion. And as I said, in Warsaw at the RIPE meeting there, 68, I think that there is probably three different places where these solutions can be implemented. The IETF itself can do some things to make participation easier. I think operators, ourselves and operator groups can probably do some things to make it easier for operators to participate in the IETF. And then there is potentially Internet society could step in if it's needed.

So the first area, communication. Within communication I think this really boils down to two ideas: One was mailing list digests, everybody said they didn't have enough time to keep up with mailing list, if we can digest. And then doing stuff other than mail. So is a few ideas that came up, quarterly summaries, having a can you remember rating services making it really simple, and again the last one, single, daily, weekly monthly digest with updates and headlines from each of the Working Groups, which may be useful.

Here is a twist which talks about highlighting the information that is relevant to operators. I think one of the things to remember to implement these solutions, what is the workload and the pay‑off. So does it make a lot of sense to do this? Maybe. Beyond just digesting the mailing list, do things other than e‑mail and the first quote is obviously that. Make it easier and less time consuming, determine the questions to ask of operators and distribute those. This says social media read it, but having those questions that are needed and having to place to go to ask operators is probably a good idea. Surveys like this are a good start. That respondent went on to talk about the fact that perhaps when a draft has been written could you send a survey out to operators and ask them questions so it's really simple for an operator to respond, it's a good or bad idea, this will work, this won't, I can deploy this or not and be done. A podcast was another idea kind of interesting. I don't know who is going to record it but a good idea.


Harking back to the importance issue. Maybe ‑‑ there is a link to the Adam feeds, they have a recent RFC feed, documents in last call and several other feeds there that you can subscribe to, if you want to get headlines from the IETF that is available already.

So the second thing, aside from communication the next was outreach and this falls into two ideas within this umbrella: Direct outreach to operator communities and one is generating publicity. Direct outreach, demystifying participation, having more liaisence between the IETF and operator forums, smaller events like ARIN roadshows. Co‑row late sessions. Had this is another one has happened before, I know the society Working Group has done some interim meetings alongside RIPE and NANOG. So this is happening but maybe more of that. Post and relevant worldwide mailing lists when you have information that wouldn't be spam like. This I have a hard time with personally. Maybe more list on more other mailing lists isn't really the solution. I don't know.

As Benno said, we have the IETF help desk here this week, you can come and check us out and and one idea I believe probably was brought up by Warren when we looked through some of these survey results and basically it's a place where there is an IETF help desk you can go it's between the registration desk. And the idea is just go ask your questions. If you want to know about the IETF, come. It's a bunch of volunteers, folks who happen to be both RIPE attendees as well as IETF participants who will answer your questions as best they can and point you to people who can answer them better when needed. If it's a good idea maybe it will keep living or bad idea, it will die off. Additional publicity is another interesting one to me. Finding ways for people to know about these RFCs and the IETF through side channels, not necessarily direct outreach but being published and talk about in trade publications, you know, you need a hot RFC so this is kind of the card ash Jan approach to IETF participation. Inclusion, Mike operators feel more welcome, great but how? Perhaps making participation at meetings easier, maybe making the process more operator friendly, requiring operational input and potentially multi lingual, that gets tricky. Making participation at meetings easier. Perhaps the meeting could be organised differently so operator relevant content is grouped together and operators don't have to spend the entire week there, get in and out, on the webcast as well. Having more operator relevant side meetings and then I think that probably goes in the reverse, having more IETF relevant site meetings at operators. A lot of this is kind of been done, the IETF is looking at this, I see this as all input to the process already ongoing to make this thing easier and lower that barrier to entry. Another idea of making the the process more operator friendly. One idea here is to making a Working Group for operators to establish business needs or operational requirements Working Group. Better steward ship of the drafts, kind of keeping the extra drafts out of the process, having an operator council rather than just having co‑chairs to determine what is a bad idea filter. More open leadership. And accept that operator requests may be valid even if they are not in agreement with existing opinions. I think that is a big one as far as that culture battle between the two groups. Another idea was requiring operational input, requiring standards to ‑‑ I don't know if this always makes sense but there may be a place where it does, if there is a point where there is a specific document, that it needs to go through operators or at least have operators be told that it's happening ahead of time. Related to that, and we had that BCOP track last night, one of the things having a BCOP would be what attract more operators and we talked yesterday about having BCOP documents perhaps published as RFCs, as an idea. That is not definitely happening yet. Perhaps that would be a way to tie the two communities together. All that have, now what?

Here is what I came up. The light green is hard to see. I tried to line up the problems we saw with the solutions that came out. I think so the communication ideas really kind of solved the time problem a or at least looked to solve it the time problem. Outreach is about awareness, making folks away it's there. We did the help desk at nan nothing, I have been reading them for 20 years, I had no idea that I could write them or fix them. And then inclusion I think is kind of what I am calling the ideas that come up that solve the culture problem, bring the two communities together. And the money problem is there and some things that could help but it's really about attending meetings which I don't think you need to do.

So, our next steps, from my side. Hosting discussions and gathering feedback. This, right here. Update the Internet draft as we get more ideas and information to have this all documented. And then potentially lobby for specific solutions, go out and do what we are doing here, repeat back to you what you have told us and if there is good ideas hopefully they will continue to rise up. Of course, this can't be done alone, this is a community effort and something that has to be happen through and through, so please, get up to the mic known a moment here and tell me which one are bad and good drafts. You can e‑mail us, find us on social media, and this is like I said, a conversation, I don't know that anything is set in stone or ever will be, it's a process that will continue for some time, we are trying to make the process easier to bring together. With that, I would love to hear any new ideas or pulling out some of these new ideas.

SHANE KERR: Great, thank you.

(Applause)

AUDIENCE SPEAKER: Hi. My name is Ilijitsch van Beijnum, I became an LIR for the first time, I did did a few more times later, in 1996, I went to the IETF for the first time in 2002, so I think I know both sides. I think it's great what you are trying to do although obviously we have to realise that IETF is the IETF, it's not going to change all that much. But one thing, I had an experience recently, the first time I went to the IETF in 2002 we were talking about S BGP, secure BGP. Now, 12 years later, wefiablely have the BGP drafts which may be published this draft this year, if we are lucky and I reviewed it a few weeks ago and I realised I was too late, I should have done it a year ago. The trouble is I have been on the SIDR mailing list for a decade and it's gist too much. I don't have all the time in the world to follow this stuff, it's not a main focus for my work. But it's interesting and important. So the trouble; finding the right moment to participate, I can't go on for a decade reviewing every document, every 45 versions, so whether I really need is some kind of signal that say, OK, we are ‑‑ 90%, 85%, what are percentage makes sense done. This is the time that we have something that is mature enough to be reviewed by operators but we also still have room to make some decent changes, which doesn't seem to be there today so the BGP Sec is going to be very hard to deploy in the real world I am afraid

CHRIS GRUNDEMANN: If you think the document is ready and it's for change that, should be last call, the Working Group last call and the IETF last call and of course if someone says this whole hinge is wrong and you have to change everything it may not have been the right moment because you have to review the next draft. So yes, it's a hard problem. I agree.

AUDIENCE SPEAKER: Well, we do have IANA requirements and security considerations, maybe we need deployment or operational considerations as well in RFCs.

JEN LINKOVA: An operator who is coming to IETF. I think your presentation miss one slide, just to make sure we are not discussing how before should. What is actual percentage of operators coming to IETF? I don't know. Is there any ‑‑ I mean, how percentage of people attending IETF as actual operators.

CHRIS GRUNDEMANN: I don't have a hard answer. Going on the survey, we saw of operators about 18% of operators participate. As far as in the room or on the mailing list, what percentage are operators, that becomes a very difficult question to answer. There are people who based on their organisation you may not know they are an operator. I don't know how to answer that exactly. It is fairly low, I don't know where it's at, my guess somewhere around 20% of people but that is totally me sitting in a room and looking around and seeing faces. I don't know, it's a good question. I think with things like this, if there are undeployable protocols coming out of the IETF there is a problem, is my stance.

JEN LINKOVA: And one comment, I have not read your draft but I have an opinion.

SHANE KERR: You are ready for the IETF, yes.

JEN LINKOVA: So I believe that big problem is that people, as mentioned, it takes a long time between people start discussing some draft and then between operator actually seeing an effect. Might have start do some work and six years later operator sees something happening in their network, right, and some of the proposed solution on your slide might actually make this time even longer. So I think we should avoid introducing more like bureaucracy which might increase the time between work being started and work being finished.

CHRIS GRUNDEMANN: I agree with that.

JEN LINKOVA: I actually quite shocked by number of people who could ‑‑ who don't know how to sign up to mailing lists. And I am really concerned about people participating in technical discussions without being able because I have seen people not being able to remove themselves from mailing list and keep saying stop sending me all this stuff, I did not know people don't know how to ‑‑ have you sent those people instructions

CHRIS GRUNDEMANN: I think not. Lynn Flynn now they could participate.

AUDIENCE SPEAKER: Corinne from the Oxford Internet institute. I was very interested in what you have been doing because I am doing similar research but not focusing on operators but on civil society organisations trying to participate at the IETF and one of the things I am interested in, what has been the reception of your efforts at the IETF to doing this?

CHRIS GRUNDEMANN: Mostly really positive. There is already a lot of changes underway on the IETF side. They are trying to solve a lot of these problems already. So I see this as input to a process that is already ongoing. For the most part and most participants in the IETF are interested in making workable protocols and this whole thing work right. So, like I said, I think a lot of culture issues that I talk about and a lot of people talk about are mostly perception at this point. There has been a good of bad experience they got spread around, for the most part my experience has been really, really positive. I haven't got anyone flow Apples on me.

AUDIENCE SPEAKER: I would love to compare and contrast, I have looked at some of the barriers to access there so I would love to see what you guys have done and then compare it to what I am working on. Thanks.

Al stair wood man: Net Def so I would like to echo the comments that have already been made earlier. I don't think you fixed the problem at the IETF by making an end squared problem bigger. So, somehow, it's already sort of suffering from congestion overload of itself so adding more people to the problem is not going to fix the issue and it just leads to those, it takes 12 years to get a draft out, type of problem. It will turn it into a 15 year‑process. So, somehow, I think if you care about it, I think RIPE and other organisations, somehow have to have a stack rank list of what you care about and then you have to make that very clear to the IETF that these things are the ones that you want to get fixed or drive through the process or something like that because there is a whole bunch of stuff going on at the IETF which is very leading edge stuff, right? There are 15 different answers to one particular problem and you are not going to fix that. And that is the nature of ‑‑ I mean that is why the IETF is useful and creative, but you guys have got to say OK, these things are the problem and we are going to go focus on some of these operational issues and drive that because I think just randomly adding more people to the meetings is not going to fix it; it's going to make it worse.

CHRIS GRUNDEMANN: That is fair.

AUDIENCE SPEAKER: Quick point to the 12 years because I don't want to suggest that IETF works on one document for 12 years. This SBGP, it's completely ‑‑ it's a very long process with very complex with lots of things that didn't work out, so it's not one thing that got started and just took very long; it's a whole bunch of different things that were tried and proposed and evolved over time. Don't think everything takes 12 years.

Sam Weiler: Active IETF participant. I don't think that throwing more voices in would hurt at all. We actually need more depth of operator participation not just hit and run but people showing up early in the process. And more voices will not hurt. I think most of the Working Groups get stuck for lack of attention, things just sit around doing nothing. The voice also actually help.

CHRIS GRUNDEMANN: To that, the one thing what I have been struck by every time I go to the IETF is how many times people call for a review of a draft, and can't find anyone to do it so. There is definitely work to be done and I think maybe not necessarily voices don't add to the voice but there is valuable work that can be done and maybe if operators were doing it may be beneficial to all of us.

SHANE KERR: Great. Thank you very much.

(Applause)

I know people are hungry and it's lunchtime. I have two short announcements: First of all, as we have said all throughout, please rate the talks, go to the plan ‑‑ or the page with the schema, the agenda. You have to login and it will give you an option to rate the talks. The ‑‑ and prizes ‑‑ the final thing is that we are ‑‑ there is two open seats on the RIPE PC, there is still a little bit of time to nominate someone or yourself, please do that if you are interested. And I will see you all back here at 2 o'clock.

LIVE CAPTIONING BY AOIFE DOWNES RPR

DOYLE COURT REPORTERS LTD, DUBLIN IRELAND.

WWW.DCR.IE