These are unedited transcripts and may contain errors.
DNS Working Group session:
CHAIR: Yes? Okay. Well, after all this, we're going on with the second session. I'm one of the other Working Group chairs. First we're going to do ?? Wolfgang is going to tell about all this traffic K?root server, and hazing ?? it was interesting stuff.
Anyway, Wolfgang, the floor is yours.
WOLFGANG NÄGELE: Good afternoon again. Good morning again. I'm going to give you an event that we had back in June of this year at K?root. Let's start off with a few little or a little bit of background. This happened in June and we didn't make the front of +the New York Times or even the business section. The event was going on but there was no impact on users. For those of you who use DNSMON you know this is a quite sensitive tool so any drops you can notice there quite quickly but remember what the actual impact of this is.
Which was going on? It was another day in the office until we started to see this on our monitor, and we were like, wow, we see events like that but it's usually 10,000 queries, we saw 55,000 queries a second, so a direct traffic increase of 40,000 queries a second. That obviously meant that we had to look into this. How was this going on? On the 28th of June we first confirmed this going on at about 5 p.m. UTC and a couple of hours later there was a report that some of the roots seem to have degraded service, so they were dropping some queries, so we looked into this because K?root was mentioned and until then we hadn't seen much of a problem on our end. Yes, we had a lot of traffic going on, but other than that. What we noticed then was that our interface ?? so if I go back here, you see that this traffic started to appear and this was the counter action we took after the report. What we noticed, back then we still had fast eitherer net so we had full but towards our service we had fast Ethernet while we had plans to upgrade it we didn't. Those interfaces started to max out. We decided to shift this traffic over to London with some BGP magic and that's when in DNSMON the drops started to disappear and people were generally happen.
A day later this was still going on, this is getting a little annoying, we connected CN.nic and to see what contacts we could get into the region and those ISPs. After preliminary analysis back then and remember in my first presentation I said we had issues looking in depth, we saw the bulk of traffic was coming from large autonomous systems in China. Keep in mind it wasn't all traffic coming from there, wasn't wasn't a state attack or anything like that. Later on we found out what the root cause was, those autonomous systems are huge. China Telecom has released they have six million mobile subscribers on their mobile network now. Those massive numbers translated in one system is you're going to see all of their traffic in one location. So we just, in our preliminary analysis, we didn't see the other ASs because they were so small so back then we started to understand that this didn't actually look like this was targeted against K?root. There were a number of reasons for that. But it was just an observation and our first thought. Since it was going on more than 24 hours we thought we should publish this to the community. So on RIPE Labs we have an article with our early findings. There were a couple of wrong assumptions in there, a couple of correct one. Later we published a more detailed report. That was just to give the community a heads up. Later that we looked more closely, the TTLs are similar, this could be a spoofing attack. A day later we had the time to disprove our theory on that because we ran echos from the nodes and we could establish that the majority of those sources seem to be legit because they had the same TTL when we sent them traffic. So we elevated the pressure on those ISPs in China and later that day the traffic started to subside.
Now, the initial findings, those were random queries for a Chinese gaming site. This is interesting to note because when we saw reflection attacks and stuff like that, they were quite simple so randomization wasn't even in there. We had a very steady high pace, so that suggests it was not just a Botnet but other things runing in there as well keeping that high pace. What we did as the counteraction I mentioned, moving it from Amsterdam to London to use some spare capacity there.
Some other observations, the communication towards the Chinese ISPs was really, really slow and mind you, there are language barriers here so because of language barriers, so responsiveness and so on and so forth it gets into a long drag. We are kind of spoiled in that because in Europe, north America, we're used to having response time on the network operator level of less than half an hour, here it took five days for them to send a confirmation, yes, we did something about this. We never figured out what they did about it. It was essential during that event that we had close coordination between the different root server operators, who is impacted, only K?root, others as well. That was very important, very useful. Conclusions, already mentioned the part of Europe north America communications versus Asia Pacific. We think this needs to improve. This is going to get more and more of a problem as we go along. By now, we don't have a definite answer what it was, so there's a more detailed RIPE Labs article on this with a lot of technical background, if you have any better ideas. We came to believe that we probably were the collateral damage of a DOS attack going against the gaming and we were not the target, probably somebody did not implement their attack properly. The other part in the conclusions, for us there are several things coming out of that but for you as an Anycast operator, because those autonomous systems are becoming huge you might reconsider your deployment strategy and target those major systems to localize impact.
The direct result of this was that we moved forward with our plans, full gig capacity and we run three query service there. Our overall aim is to have five times as much capacity at any given global note that we have as a total capacity need right now, 250,000 queries per global instance, five of them we have achieved that again and we're's can have the that we're going for the coming cum of years. At the end of this, still remember, you still got to facebook that day so things were not that day. I have a link to the RIPE Labs article here. If you want all of the gory details you can find them there. Happy to take you there.
CHAIR: Are there questions? No? I've got one. You said you work better with other group operated on this, and they saw exactly the same pattern or difference in traffic?
WOLFGANG NÄGELE: We got confirmation they saw it going on but they couldn't do as much indepth analysis, we could look into this massive data quickly. We were used to taking this data, going away for a month or two and making conclusions out of that. Not everybody had the opportunity to do such in?depth analysis, but some of them did, and I think Dwaine Wessels promised to do a report like this sometime.
CHAIR: Well, thank you.
(Applause.)
CHAIR: And now for something completely different, it's DNSSEC trigger.
Olaf Kolkmann: This is for the DNS geeks among us. Definitely not a production tool, but an attempt to see what happens if you bring DNSSEC to the local machine. In the deployment of DNSSEC and utility of DNSSEC, the last mile problem is one that very many people are looking at, solutions of stapling DNS KEYs to certificates, putting things in DNS streams, and so on and so forth, but but, ideally, you would like to have the local machine do the resolution, do the DNSSEC validation and provide the information to all applications that make use of the DNS. So not only a bolt on the web browser, but somebody that is available to all your applications. So the local interface here denoted byc column 1. The executive summary, how do you get this done to the local machine without much of a headache? We came up with something called DNSSEC trigger. It's essentially simple. Running in bound locally that catches rebound events of your interfaces and local circumstances. It will do some probing and will try to penetrate the DNS infrastructure in order to get DNSSEC working. If all else fails it will call the user. How does that look in detail? Essentially what you can see here on the left?hand side for you too is unbound, install it from scratch using your local package installer, what have you, with initial configuration, which means a pre?configured route key and DNS unbound will be able to do roll overs based on 5011 and all the good stuff. Install DNS trigger and that will also to incoming or that change the key address or ID of the local revolver and it will use unbound control mechanism to reconfigure unbound on the flag. And it will, at the same time, when it's successful in probing, set a little piece of eye candy to indicate everything is okay and will provide from feedback when DNSSEC is virtually impossible.
Probing strategy, what we try to do is use local cache ?? the local recursive name servers as much as possible. The first thing the trigger does is try to talk to the recursive name server that's handed by DHCP, for instance, and it will try to do DNSSEC resolution using that channel. If it succeeds, suppose you have a recursive name server running BIND which does not have DNSSEC validation turned on itself but is able to do the DNSSEC special processing because it has a DNSSEC compiled and sets the do bit and all that magic, you're in business. If the local cache, however, doesn't do the special processing, and also means the special processing doesn't come through the transparent proxy that you're in, then what it will do is try to recurse itself. It will go out to the authoritative name servers and try to do resolution there. If that fails, then as final back?up mechanism, we end over port 80 and 443 because in most infrastructures those are the only possibility left to get any traffic out. So these are the real environment. There are some out there like the Swiss network in the hotel.
Little piece of eye candy, little anchor, you can reprobe and show the probe results. This is the type of thing you try, it will ?? that was okay, the cache didn't give any feedback, so it will be fetched direct from the authorities. So that's the normal operation. The probing, will see if there's EDNS suppose, whether lengthy packets are supported over the wire, if the transparent proxy is actually transparent to DNSSEC. And it will continue to probe until successful with an exponential back off. If there's trouble, doesn't get through, I really couldn't get through. You are now in a new environment, you've seen this update coming in, new environment, I'm in a new environment, I'm trying to probe through this thing and I really cannot get any DNSSEC information through. That might be true in the case of a captive portal where you have to log into the hotel network to get through. In that case, only probing time, can basically have a choice, go insecure or disconnect from the network. Those are the two choices. If you disconnect there's no service at all. You can close your laptop and go home. If you go insecure you have normal DNS resolution and you talk to the local recursive name server. However, once the probing has done and you are runing in a secure operation, then DNSSEC failures will not give you a pop?up. So you're protected from that.
Implementations: Network manager, we integrate with network manager and NETCONF figure nthose environments the eye candy is available, window management systems, unit interface available, we work with Vista and we work with Apple. And I said, this is not for the ordinary mortal yet, we want to expose this to as many broken environment as week. This week for us was a very nice learning curve. The thing we noticed here, is that sending DNS queries over port 443 just doesn't work if there's depacket inspection going on. You really have to put this stuff in a TLS transport. So we're reworking this so that that can be done as well.
Anyway, there is ?? this is a call for the DNS geeks in the room that would like to try recursive DNS validation and in travelling around the world. There's a mailing list to share your experiences if you're in an environment where things don't work which will help us to improve the tool. The web page is on the page and also on the QR code. Currently there's an installer which we released lack week for Mac OS. I'm going to tell you if you use the installer it will throw an error but the package will have installed and it will reboot everything. That will be fixed on the next release. So please get on it. It will help to get DNSSEC to the last mile and that is what we intend.
Thank you.
CHAIR: Thank you. Any questions?
AUDIENCE SPEAKER: Roy Adams. With a tiny bit of help from Olaf and Yap, I installed it on Monday evening, I'm not not a power user. It works fantastic. It works in the hotel room, it figures this thing out. I think it's really, really clever. Currently I'm trying to make it work with open VPN. We at Nominet, when we open VPN it overwrites the se resolve.com. That's a small detail. Once I have that figured out I'm going to push it at Nominet as well. I really, really like it.
Olaf Kolkmann: Gaining experience if you find ways to get to this VPN and special things are needed let us know, post it to the mailing list. I should say we try to present as little information to the users. It is ?? in the end it will be intended as an end?user tool. Currently if you run into problems, you probably should be able to find the log files of the unbound process and see what's happening there and be able to do a little bit of digging and drilling and what have you in order to troubleshoot, but that's why I ask you all.
AUDIENCE SPEAKER: One of the things I think immediately is there's several websites out there that are broken solely for the purposes of testing DNSSEC and it did exactly that. Thank you.
CHAIR: Any more questions?
AUDIENCE SPEAKER: Richard Barnes. Clearly your presentation, this tool does a lot of really interesting stuff in terms of determining DNSSECs supporting local network. What wasn't clear to me is how applications get access to this stuff.
Olaf Kolkmann: The tool reconfigures the set up of a machine so the recursive name server lives on the local interface. That means that if the tools that use DNSSEC and they want to know DNSSEC status they only have to look at DID bid this of course is an assumption that on the local machine you're not compromised.
And if there's a failure case and DNSSEC is triggered to understand that something is bogus, then you just plainly don't get an answer. It's not a good user experience but that's what it's for.
CHAIR: Last question?
AUDIENCE SPEAKER: Randy Bush said that it's bowing because it works we know it's not the case with the here at the it is bowing, DNSSEC has no problem but for Zeus the overflow it is much more interesting. So the bow is broken, interesting way, be sure you have the last version of DNS trigger because version before didn't work with this hotel.
Olaf Kolkmann: And the Swiscom network doesn't work with 07.
CHAIR: Anyway, thanks Olaf.
(Applause.)
CHAIR: Now we move to another side of DNS and we have to deal with that international, that's why we have ?? Joe will give us some information.
JOE ABLEY: Hello. So the first thing I should mention, which is not related to IDN variants at all is the management of the whiskey key BoF have never again will be held the day before the DNS Working Group.
So the title of the slide is IDN TLD variants issues project which is a project active at ICANN. What is a variants? And that's right, that's what this project is for. There's lots of different interpretations what variants might mean, none of them are consistent. At loosest, we could say this is an attempt to provide e85 lense between different strings in the DNS which will help people use scripts other than Latin, but also including Latin.
We have variants, what happens, what causes them, and what happens if we do or don't do them? Trying to clarify this whole space.
This is an overview of the entire project. So the project is being if he had by six reports on individual scripts attempting to try to tackle that problem for that individual script. Where we are right now is the first grey arrow on the left, the first six scripts have been publish and had we're in a public comment period asking for feedback and we'll get to how you feedback a little later. We understand that these are not the only six scripts in the world. Part of that project also is trying to identify how new scripts that are not reports here that have their own unique issues can be incorporate the into the project. The integrated issues report, which is the blue arrow in the middle, is drafting, that won't finish until after the public comment period has finished. And the output of this finally is some sort of decision of how to go forward. We're only talking about the root zone, TLD labels, this is not a DNS?wide statement of anything, but just for the root zone. The idea is to come up with proposals that might be policy, protocol, impact on the DNS, and that we hope that that will drop out of this analysis.
So I mentioned we have six scripts those are the six scripts there, six corresponding reports. The reports have been largely made by teams of experts who are linguistic experts, also subject matter experts, including DNS it's Andrew Sullivan, co?chair of the DNSSEC working group. There is a basic level, balance protocol expertise, there are no decisions being made that are going to break the DNS in any ridiculous way. The focus is the effect on users and user in this context means, as you would expect, people who are going to use these names, people who type things browsers and send email, also taking into account the system administrator, people have to configure name or mail or web servers, because there are potential implications here that for what used to be a single name stands in an Apache configuration might turn into 64,000 names and the outcome on the people who configure those servers is important.
So the six reports have been delivered. As I mention the public comment period is open until the 14th of November. The length of the reports varies, the issues brought up vary. Some of the reports have made recommendations jumping ahead to possible solutions to the DNS in other reports they haven't. Because of the nature of the different scripts, some of the reports focus on different areas because they're more relevant to those particular scripts.
So the reason for being here is not to discuss any of the issues that have been identified so far or to talk about the draft integrated report but really to ask people in the room who have an interest in this, who are concerned about the impact of administration of the DNS, of other services and of end users, to read the reports and give some feedback. This is a standard ICANN consultation, so the web form is for providing feedback. Also a public mailing list where you can join discussions, there's a reasonable amount of traffic on there. That's open to the world, anybody is invited and encouraged to participate there. The working group involved on the six teams are actually closed, but they're closed in the sense we're trying to get work done and not have too wide an argument. It's not secret or anything and all the work is published.
The draft integrated report can be found there.
And that's all, if there's any questions, I can answer them all or more likely pass them on.
Thanks very much.
(Applause)
CHAIR: And last week was conference and some workshop about DNS stability and Stephane is going to tell us about this.
STEPHANE BORTZMEYER: I did some instruction on his how to move from one side to the other because I don't have the keyboard. Do I have to press something? Okay.
Okay. So a few days ago in Rome there were two meetings, DNS easy on stability and reliability, for those member of center you received one hour ago the information about the center report on DNS easy it was only on the first part. The the report is public. Even if you're not a member you can down load it.
So two meetings, DNS easy was public, SSR was closed invitation only. So it was a meeting of the leading security ?? top security experts, something like that. So the meeting was organized by GC SEC. I didn't know this organization before. But we discover every day a new organization working on security of the internet. So DNS easy was basically conference with technical papers. I don't plan to summary for you all of the papers, just a few personal choices. Paul was invited to talk about the future of the DNS and he insisted it was something that evolves, it should not be kept as always been but try to find now views new problems, one person said is DNS used the way you plan it had and he replied: I would be disappointed if so. He tell a lot of nice sentence like this. I didn't put everything on the slide. There was a technical talk about the detection of IP over DNS, people try to use hot spots for free. And this was a technical talk about how to detect them and how to stop them. There was also a talk by people about the propagation of DNSSEC blunders. When you make a mistake when something is broken, like a lot of domains, it is not seen immediately by the resolvers because it depends what's on the cache so they merge ?? the actual traffic with the description of the DNSSEC problems that we have on the ?? show that unfortunately mistakes in DNSSEC prop gates quite fast but when you fix the problem, the fix does not prop gate so fast.
So personal opinion about this: It seems that you can spend your entire professional life going to conference about internet security, everyone wants one, in the case of it was not very clear who should attend this conference, some of the talks were academic, some very technical, some tutorial for beginners, interesting but not for the public. The other part of the meeting was an SSR event. It's a third SSR event, the first two were in Atlanta and Kyoto, on the format, more or less the same, a few dozen leading security top experts meet in a room, they work under the Chatham House Rule, for those of you that don't know, we can say publicly what was said but not who said it. So I can mention everything I want but not attribute it to Smith or Jones or anyone. There were around 40 top leading security experts. There have been several workshops actually. I didn't attend all of the workshops. In my opinion the most interesting was about DNS filtering because it's a new topic and hot topic. So a lot of people want to filter the DNS to protect us against all the evils that can go on the internet. It was not about solving the problem, it's impossible, but about at least getting a common understanding of the issues. So we discuss first the political, legal, ethical, non?technical aspects. For instance, we agreed that things like self?inflicted filtering, if you want DNS triggering and you can't see a lot of domains, you have no one to complain against except yourself. Efficiency, is DNS filtering efficient? Does it stop people accessing the domains? We agreed maybe it's not the point because maybe you can see it's not important because politicians, for example, don't want efficiency, they want security theatre, they want to show something is done. Object to go DNS filtering on the basis that it's not efficient, may not be an efficient argument because many people don't care about efficiencies, they just want to show off. Filtering with DNSSEC, it's complicated because if you've seen the press release about DNS filtering which opposed the filtering, basically that it broke DNSSEC, it's more complicated than that. It depends when DNSSEC validation is done. DNSSEC wants you to know filtering is going on, but not to access tole real data. So if you just want to block access to domains, if there's DNSSEC it's not a problem because an X domain fell in both cases so the domain will be blocked.
We discussed technical consequences and on the non?technical consequences, people switching to some sort of other resolving system, for instance a lot of people switch ?? a lot ?? I don't have the actual figures, but apparently a lot of people switch to tell con I can because filtered, there's a sort of consequences being faced now. Because obviously DNS filtering won't disappear even if we probably all hope that it will, but it won't, so we will have to face the consequences.
Other workshop, there was a workshop about statistics, problems, issues of pcap files abroad or other personal data issues, about the user for DNS to fight against Botnet, for instance, taking down domains to prevent Botnet for talking to it's common control center, as it was done in the Conficker case, also another workshop about the take?downs or basically some people asked to have a faster, easier way to take down domains, typically a web service, send a list of domains and then it takes down everything in a few minutes. There have been discussions about it, but my personal view about this two last workshops, it was not really a discussion, because there are clearly two opposite sides, typically located on different sides of the Atlantic, some put on the emphasis on take down and others put the emphasis you on process this sort of boring stuff. There was no one from the countries like Brazil or China or Japan that could have put different perspective of these issues. I wasn't there on the future use of the DNS, if someone was they could talk about T I was not there on how to improve the deployment of DNSSEC, but could be done now to improve the deployment of DNSSEC. Personal opinion, nothing really new, it's the third, it's always nice to meet people, to discuss, to ?? but we don't really advance, there is not something new. We don't ?? we didn't create a new break?through in internet security. So I recognise in the room other top?leading experts that were there, so if someone wants to add something or correct something, you're welcome.
CHAIR: Thank you for that. Any questions? I always like Chatham House Rules, you can't attribute anything to yourself either.
AUDIENCE SPEAKER: Peter Koch, I won't name my name. Esteemed world?leading ?? I like that. So the title of this SSR thing was ?? it was about the security stability, resilience of the DNS, and in ICANN circles the people with the ties usually means something different than the people that wear the polo shirts, so looking at your agenda, and I think was very interesting and to the point, we see that this take?down industry is kind of having a very heavy weight there. And could you maybe elaborate a bit on the relation, how much was really dealing with the DNS and the infrastructure itself and how much is addressing things that would happen with the DNS instead of to the DNS and what's your stance on that? Are we probably missing the focus or losing site of the stability of the infrastructure because a couple of these world?leading security experts appreciate the DNS as the hammer for the nails they want to address?
STEPHANE BORTZMEYER: If I understand the issue, the problem ?? for a long time all the issues about take?down were directed to the registries like it was in the Conficker case, registries were asked to act, otherwise they are not good citizens of the internet, with the sort of thing if you delete the domain at the registry it will disappear from the face of the earth. Now, more and more towards are directed other as we have seen in France. Also it is like the regulator of on?line game is gone asking ISP to filter illegal gambling sites on the DNS resolvers. So it could be the same when you fight against Botnet or anything, instead of asking the registries to remove some, they may not want to do so, you could do it on the revolver. On the second ?? that's the only one. So, typically, take?down is now a new aspect, it's not only a problem between the take?down industry as you said on the registries it can also be directed to the ISP which is a different population, less represented in things like DNS Working Group at RIPE. There were not many of them at the SSR. I can not say who was there, because it would be against Chatham House Rule but they were from the registry, most of them. We don't really know what ISP would think about it, but in most countries now, if you want an ISP and you want a DNS resolving service, which is a typical case of the ISP, then you have to do some sort of filtering, because you have mandates coming from many different organisations to fight against porn, et cetera. So for the people who work in the registry, something we have to be prepared, they will no longer bother us with the take?down requests, they will now directly go to the ISPs, that will probably be the next big change. Was it what you were asking for?
Peter Koch: Perfect. Thank you.
CHAIR: Thank you. Interesting.
(Applause.)
CHAIR: Now we're going to the last part which we'll run to the lunch or later, depending on how much food fight. It seems to be mandatory to have a panel now, adays at RIPE. We're going to have one and we volunteered some people. Basic idea is to have some discussion about ?? Stephane already kind of talked about, DNS blocking and how it impacts the ISPs, the operators and whether it's a good idea or not. So we volunteered Joao Damas as being ?? the company has a new interesting way of policy to DNS queries, from the operation point of view, we have Matthew from... we also managed to volunteer Patrick, we'll put the hat as SEC on him now and for the ?? mandatory CCTOD, the monitor will be Peter Koch.
Gentlemen, take your seats.
Peter Koch: They made me the operator so I'm blocked from using the microphone, except for the introductions. I would like to suggest that we start the round on that side with Joao. Could you give a short instruction of yourself and what your relation to this topic is and maybe some ideas, do the round and then open the floor to the audience and maybe inject some interesting site questions.
JOAO DAMAS: My relation to the issue is that I work with ISC and we write BIND and it's been implemented to policy, how it behaves when answering DNS queries. I'm a not going to say much more. I would rather that people bring up the points that are of their concern and we can address them then.
Matt Pounsett: I'm with Affilias, we are a domain for info and moby and we do registry services for other registries as well, for Org and several others.
I guess as an authoritative server operator affiliates with like people to see the answers that we send, but beyond that, I guess we don't have much of an opinion. Personally, I guess, I don't know, I think the idea of rewriting answer is his sort of a complicated one. There's some cases I think it makes sense and a lot more cases I think it doesn't. But I guess that's kind of it generally speaking.
PATRIK FÄLTSTRÖM: I'm we have been ?? we got a question early spring 2011 regarding ?? from the government advisory committee on our view of blocking. Our response was documented in our document number 50, which is a two?page documented translateed to all six languages, I encourage you to read that document. It's basically saying that regarding blocking, that's not a black and white issue, it's more a question on what harm a certain action on the DNS flow is creating. And it encourages everyone that is trying to do or interested in doing something like blocking or sin they sizing or changing responses, to calculate the balance between benefit and harm, because any kind of ?? any kind of touching of the flow of responses, which we just heard mat talking about, does havability to access services and whatever you want to do on the internet. We also say that the impact is greater, if it is the case that the impact of the blocking ?? that the blocking has impact outside of that motor I have domain, the one that wants to do the operation operates, because we do know, for example, that a lot of the blocking is happening in local firewalls, anti?virus software that you have and in such things but the further away from the administrate tiff domain that the blocking is happening the more the harm. After publishing that document we've continue to look at various kind of reputation systems and that's something we're investigating, who can we impact and general implementations regarding blocking. Thank you.
PETER KOCH: Thank you. Thank you for broad enning the focus a bit. The tile of the panel session is not referring to blocking for security purposes but back to rewriting of different flavors that would extend maybe even to the site?finder example of ages ago.
So Stephane seeded the ground referring to the filtering discussion in Rome and one of the issues was brought up this self?inflicted filtering or third?party inflicted filtering might be looked at differently. Some of the statements that we've read so far on blocking rewriting and filtering strong sense that all this is challenging the stability of the internet or setting this at stake, and it might be a bit schizophrenic to see some party holding warning signs in one hand and actually supporting blocking for like Botnet fighting purpose on his the other hand. Joao, can you say something about that?
JOAO DAMAS: Sure. I guess you're referring to the fact that IFC has a very public position on government interference for whatever reason as a means of blocking internet?wide access to a given set of names, and at the same time that we have implemented things like support for NX domain reaction in bank
Peter Koch: Or RPZ for that matter.
JOAO DAMAS: I think they have nothing in common those two things. It's not the same to block things, for instance, at the registry level which affects everyone, whether consenting or not, than to enable things at a local level where there is a clear policy for the network you are in or should be at least. In that sense, for instance, RPZ is applied at the revolver level. It's mainly intended for use at enterprise level because that's where the demand for that kind of functionality is. The people who operate those resolvers claim time and again that they have the right to implement whatever policy they feel like for the users they serve, and the rest of the internet can obviously do whatever they want.
The idea of implementing ... to use it as a security measure, people might think that we are trying to use the DNSSEC in the fight against evil. It's more a reactive than a proper active movement. The fact is DNS is used by the bad guys. And we could look elsewhere, but that's not going to change, the fact fact that DNS is used by the bad guys and some of these uses can be mitigated by things like RBZ. So the two things together explain why there is a difference in these two completely different environments.
MATT POUNSETT: To add to that a little bit: Even for people who answer the two things to be very similar, there's a way you can look at it, that can help to kind of lead to an answer for why people have very different opinions about them both. I think when you start rewriting DNS answers or blocking answers or ?? you're reducing the coherence of the DNS and the stability, and I think in order to justify doing that, you have to be doing it in order to increase stability in some other way. And if you ?? what you're doing is balancing that out somehow, then I think it can justify it. So, for example, using RPZ to locally block mal domains, you're helping to keep people from having their computers compromised. So particularly if they're in control of how that's done, then I think you can justify it. It's much harder to justify blocking further away from the user just because it has such a much wider ranging effect. It's not under the control of the user, and in some cases, has no benefit anyway. For example, you know, commercial rewriting for advertising and things like that.
PETER KOCH: Do you want to comment first or I'll give the microphone to the audience.
Speaker: It's a complicated issue. We have to remember, for example, if year we're doing blocking or rewriting, we have to remember that a country is the administrative domain of the country, there are laws and legislation within that area where decisions can be made based on local legislation. The internet is, though, global which means even though it is the case that that decision has been taken according to the local legislation that exists, for example, to removal of a domain name from a registry that do impact users outside that administrate tiff domain, so that is where you can see the difference between inside and outside, if you see a decision in another country. Regarding ?? I think it is very important to view registries and public resolvers and other kind of mechanics like that, as one of the categories of intermediaries for the people in the room that follow the ESD discussions and the current trend among governments and regulators, for example, the discussion in the Commission early this week says that intermediaries are not allowed to touch the packets whatsoever when they were's flowing through the network and this is search engines, et cetera. If it is the case there should be exceptions to the basic rule, that needs to be based on legislation and that is what several member states and several countries between the RIPE region do have that view pretty strongly. That is something that all of you that are thinking about ISPs, for example, that you will implement RPC for your users, think you should look at what the countries are saying where you are operating, because it might be the case that to use the terms of the previous speaker, it might be the case that US and ISP are too far away from the user to make these kind of decisions without infringing or breaking the legislation. The last thing I would like to point out, there's a discussion, specifically ?? there is a big difference between interest of blocking a domain name because of this string itself in the domain name, for example, that a TLD is registered where the TLD name is telephone is a string that is illegal, for example, in a country, and interest of doing blocking because the domain name is used to access services and information, that the end user doesn't want or that is not wanted, and we also need to very clearly help the discussion that is going on to separate these two cases. Thank you.
PETER KOCH: Thanks Patrick.
AUDIENCE SPEAKER: Jim Reid representing myself. A flip comment, discussions about the idea of legislation where no one is going to mess with any packets at all, does that include changing
PATRIK FÄLTSTRÖM: I didn't hear what you said.
AUDIENCE SPEAKER: Does that include changing the hop count? It was just a flip comment.
PATRIK FÄLTSTRÖM: I would say from a general point of view, yes. On the other hand we do have exceptions to that rule in the telecom registration, for example, the directive in Europe that says that someone that is providing these services also must guarantee that, must protect the network and the services themselves from various incidents. For example, if user A is doing something it should not have impact on user B. Also the case the services they're providing should be according to whatever kind of service level regarding user experience as what was actually advertised. So some of the these changes end of being technical changes we detect but are things not only tell co?intermediaries are allowed to do but some of these things they must do because they need to protect the network. It is a grey zone. In general, absolutely, any kind of change, the basic rule is you're not allowed to change anything.
AUDIENCE SPEAKER: Thank you, Patrik. Just a flip comment.
JOAO DAMAS: Patrik mentioned something about this, not change packet ??
PATRIK FÄLTSTRÖM: That is only if the intermediary moves, according there's five different classes, for example, search engines. Or for example hosting providers that provide where end users up load information, that's also an intermediary, not only ISPs.
JOAO DAMAS: In the DNS, if you look at it closely enough, you will realise that interference with DNS traffic at the level of revolver is not rewriting
PATRIK FÄLTSTRÖM: I think people in this room should be very very happy if we get an agreement that intermediaries is not allowed to touch the information that is flowing. So, yes, I think it's very very good that we do have these technical discussions and we should have that, of course, to understand where the grey level is. But I just want to tell you all at the same time, that there are many parties that do not want to have a rule like that, that people absolutely want to do things that people are asking for legislation that where ?? where, for example, hosting providers are legally responsible for the content that is flowing in the network. That is the alternative. And I think if we only have to choose between those two, I hope we in this room have agreement on which one is the solution we want.
AUDIENCE SPEAKER: Jim Reid: Okay, I have to say that I'm rather saddened by the RFC has gone about this rewriting feature in the latest version of BIND. We know these kind of things go on, and I suppose if there's a need for doing this, a lot of people demanding it, obviously the features need to be implemented. But you made the point earlier, we know the bad guys use DNS for bad thing but I think in this case we're giving them tools and reducing the barrier for entry for doing doing these bad practices and also sends a rather nasty message that it's saying it's okay to do this kind of thing. And I think that's regrettable.
JOAO DAMAS: I think you're wrong. You can be sad, it's your right.
AUDIENCE SPEAKER: I'm always sad.
JOAO DAMAS: Let me explain why. You mentioned two things that I think are quite different. We debated this for a long time. It is, strictly speaking, outside how the protocol is supposed to work. You have to remember, though, that there is this gap. When you hit the revolver, you are not hitting the authoritive server, the distinct thing. The answer you get back is never or not necessarily the same thing that the authoritative server provided to begin with. The information that you have in the cache is a composition of what you just got if you ask a question together with what was already there, and things that expire and had so on. So there is already that manipulation going on. Now, I don't personally like an X domain reduction. I don't like it applied at any level. What has made us go this way is the long discussion about the fact that there are people out there that deploy software that does this. And that not having that functionality in BIND, which by the way is turned off by default, it's not like we're going to start bobbing the whole internet ?? would ?? causing these people to go away from BIND into software that we have found to be at a level of compliance between the S protocol at a much lower level.
SPEAKER: That one doesn't take its effect then.
JOAO DAMAS: The logic behind this is the people who want to do it are going to do it anyway, if we don't provide them with a way that ?? in a way that limits damage, they're going to be picking software that is going to generate additional collateral damage. Okay? It's a fact. There are companies out there that have their own software or hack BIND to provide this software to others and they're selling it. Rather than having solutions that leave much to be desired in the functionality and what users get in exchange for ?? even the responses that do exist, the ones that you hope would be not be affected at all, may take this decision.
With regard to the second part, RPZ, we're not providing tools for the bad guys, the bad guys already have them. This is a typical case where it is the good guys that get the second stick, because the bad guys are in need for the money or other political goals, and they are going to do it whatever it takes. And you have no defense.
AUDIENCE SPEAKER: Okay. I give up the mike.
Olaf Kolkmann: I am in line, but I was just thinking whether I was asking a different question than Jim just did. Because if it comes to blocking, I can go a long way with, you know, taking into account locality of the effect and so forth, and I wanted to ask an open question to all the panel i have thes, if it comes to blocking versus rewriting, what ?? and as open as possible, what are the trade?offs with respect to blocking and rewriting in the light of commercial pressures, in the light of not all protocols are visible to the user, not everything is web? What are the trade?offs there? I'm trying to rack my mind about it because as the open software vendor trying to do the good thing, we notice the same sort of pressures and I'm really wrapping my head around it because I like the idea of being able to block, as long as it's in the administrative domain that gets the impact. So I think that is a line of thought that I really like to pursue. But if the policy to do that implies rewriting, I'm not sure if we're doing the good thing. And, so, commence please. I'm not trying to say that the wrong decision was made, that's your internal thing, your choice, but as an implementer, I need to do the trade?offs and I want to make sure I do everything.
PATRIK FÄLTSTRÖM: I have an extremely strong opinion and that is that blocking is the only alternative, rewrite is an absolute no no. If you look at an application layer, regardless of who is looking up things, if you apply apolicy no we don't think this is something you should access, it's so much better to not give back a response at all. Personally, like the default ?? the default result of validation in the DNSSEC deployment of today which is if it is the case that a validator cannot validate the response it will not give back a result and I think that's really, really good.
MATT POUNSETT: I think I agree with that, that doing ?? you know, there are probably cases where rewriting can be done without causing too much trouble, but it's going to be a small number of cases, enterprises, things like that, where the administrative domain is so small that when something does go weird because, you know, you've rewritten the IP address of a mail server or something, that the people ?? the people controlling the rewriting and the people having experience are very orgainisationally close together and can deal with it. That's such a small population of the internet that in the general case, I agree that, I think, if it needs to be done at all, blocking is really the only option that's going to work widely enough to keep us from having serious problems.
JOAO DAMAS: I agree that blocking has many less side effects than redirection. Most people talk about redirection, pointing people to a mal wear page, they're already assuming that what you're doing is web browsing and that may not be the case. And when an application that is not a web browser comes across this stuff, who knows what might happen next. We'll see how effective blocking is. As you saw when you presented the DNS trigger, the first response you got is you're providing a way for user to circumvent the policy out of their realm because you're an allowing DNS traffic to write on port that are usually open to other policy. You're giving a user a means to violate a policy. Having said that, it doesn't take a very smart virus writer to do the same. So we'll see.
PATRIK FÄLTSTRÖM: Let me add something, one thing that was said in L?SEC is people that want to do blocking, another additional thing that I didn't mention, people that want to do blocking want to solve some sort of problem, they have a problem and want to implement a policy, using the DNS blocking to solve a problem is probably not the right tool. Olaf Kolkmann: And the response that we got is taken to heart because that's something you don't want to do. You want to allow people to adhere to their local policies.
MATT POUNSETT: I think there's still a benefit there, too, because you're essentially giving more control to the user about over what blocking they see and what blocking they don't, which ?? so, yeah, it's a difficult one.
AUDIENCE SPEAKER: My name is Maria hall and I'm working for the Swedish government and I'm one of the for the advisory committee of ICANN. I don't really have so many questions. Actually I have many many questions but I'm not going to take them now. But I really want to make a statement. To start with I really appreciate the discussion right now and I appreciate that I can listen to all the ideas and questions and answers. And as a government advisory committee member, I very much appreciate dialogue with have with aSEC group with pat I can and the rest of the experts, because the ?? the issues we are facing now, we're talking a lot about blocking, but apparently it's not black and white and we're talking about top?level domain blocking but we end up in talking about other types of blocking. Our discussion that we have right now, in Jan the whole new program is going to be launched we're going to have these issues and we as a government advisory committee, come with some kind of advice or statements. So the best thing we could do right now, standing here and listen to go you, is having even more dialogue with you guys that now that it's not really black and white. Redirecting and rewriting. A lot of other things and we need to know the difference, so we as governments when we take our decisions, not only in the GEC but the local decision, when we have legislation we have to take into account why we do certain things. We need to increase our knowledge. I think it's important. Thank you.
PATRIK FÄLTSTRÖM: I would like the people in the audience to think about about something, not giving a response but think about it, if someone in the new DTL process is applying for a string or top level domain that is illegal, and really illegal, what should ICANN do approve or not? If it is approved what would the result be and what should we as the internet community do?
JOAO DAMAS: It's kind of a hard problem. And the thing is when registry level blocking is implemented at the TLD level, with the.dotcomplicated, for instance, you can always choose a different TLD to put your domain name, but if it's at the root level we only have one of those and hopefully that's the way it would stay. If they break that, if the root starts being incoherent, then the scale of the problem is quite quite different.
PATRIK FÄLTSTRÖM: It might even be the case that this domain is registered, happens to be illegal somewhere, blocked there, you launch your business in that domain, that's quite a lot on business cards and whatnot, and then you travel or detect that some of your customers that you might get lots of money on is in the legislation or jurisdiction where that top?level domain is blocked. What kind of responsibility is on the applicant for top?level domain to investigate the legislation or the restrictions around the world? It has already, Olaf whispered here, it creates a lot of sleepless nights and some of us have already have sleepless nights, we still don't have a real answer and the process is launching on Jan 12. Jan 12, and the year 2012.
Olaf Kolkmann: That's the end of the world.
AUDIENCE SPEAKER: Jim reed. I want to move the discussion to a slightly different topic in this area. And I heard this on the internet, so it's got to be true, one fairly large ISP has been for a few years now, doing rewriting, essentially a site?finder thing to direct people to a website where they can be sent targeted adds and off to a search page to get where they want to. I understand this ISP has decided to stop that practical and one of the reasons they decided to stop that is to deploy secure DNS throughout the network. And I think it would be very interesting if we get some of this company to come here and explain the business drivers and dynamics for that justification. I understand the BIND count has made a calculation that the rewriting stuff didn't bring enough revenue to justify the costs, for them it was a no brainer, but I think an interesting thing also is an argument was made if we continue doing this we can't supply secure DNS.
JOAO DAMAS: I understand they reached the conclusion. Maybe we should bring them here and explain why they did. The financial guys always trump the technical ones. If the financial guys are sold into the idea by some DNS vendor that they're going to make money from these, DNSSEC which so far only costs money is not seen in the best of light.
PATRIK FÄLTSTRÖM: I think we do have ?? let me put on my Cisco hat for a moment. One technology we are advocating is Nat 64 and... and remember that we are doing synthesis of DNS responses so the nodes that only have IPv6 access.
AUDIENCE SPEAKER: To say a little more about what Joao was saying. Part of the technical counter argument there is in figuring out the costs of doing the rewriting, you know, operational time it's required and the cost of using specialized equipment to do it, and, you know, loss of customer service time when customers complain about the ?? I think the part of the problem there as engineers most of us aren't used to writing business cases, that's quite a lot of work.
JOAO DAMAS: Overrule it's a sad state of affairs because the problem is you still get spam because there are people out there that click on it. That's the sort of thing that these financial people see. It doesn't matter what percentage of user are going to click up on the page that you put in front of them. If they make a buck, they make a buck. And usually this thing gets thrown in with software they already have. They don't see the initial cost. If this ISP would be willing to come forth and explain exactly what the cost of this doing was, it might be some useful information.
AUDIENCE SPEAKER: Maria from Sweden again. I want to add one dimension, what we're discussing, in the EU system and of course inside the government, is actually the difference between blocking something and the harm it does for the internet infrastructure on the global level and that's something that's been of our concern specially in Europe and specially in Sweden. But the other perspective is the harm it is for the customer or to reach information, whether you're at home or another country or whatever, the fragmentation of internet. I think these two dimensions, whether it's the infrastructure itself or the freedom of information, it's two very very important dimensions. But still you have to kind of sort it out, rather than these kind of blockings, whatever it is, how it's going to make impact on these dimensions and that's something we need to sort out before the 12th of Jan. We don't have much time here.
PETER KOCH: Thank you. I think we're almost at the end of the discussion. I would like to pose one final remark. We've heard about various motives for doing blocking or rewriting, government?induced or spam fighting, and the likes. One topic I haven't heard so far is in the terms of private or industry initiatives what is the aspect of governance of these efforts? So when we talk about a near realtime facility that would enable certain groups to influence resolvers to block or rewrite resolution data, that is kind of interfering with the business model of a registry and I'm looking to mat in particular, because as registry you have a liability to your customers and they expect the name they register with you is revolver and even in the Conficker case which was mostly manually addressed we see there were like collateral damages because people were unfortunate enough to have one of these names that were on the list. Do you have any idea about that?
MATT POUNSETT: Yeah, like I said during my introduction, that we obviously like people to see the answers that we send, but we ?? but there are cases where even we participate in things like that, particularly domain take?down, there's a lot of stuff like that that happens that ultimately come from his the registry, that we get requests from registrars or, you know, find out that a particular domain is being used in a way that violates acceptable use and away it goes. So ?? so I guess what I'm saying is it's not always an easy answer as to how we feel about it, I guess. It's very much case by case.
PATRIK FÄLTSTRÖM: This is one of the reasons why I support and quite work a lot together with people with human rights and look at the human rights aspect out of this and I also looking at what intermediaries actually can do. One of the things that is really important, whatever is done, including the take?down orders that are sent today to the registries, many of those take?down orders that are done and the action on including various different kind of filters that implement in different countries around the world are not based on legislation. That is the number one biggest problem. The process and the decision?making process that is used for take?down at registries or registrars, just like you, is not based on any kind of legislation that had been scrutinized according to the jurisdiction where the service operates. That's the number one thing we need to do so we get clear rule on his when these kind of things can happen or not.
JOAO DAMAS: Furthermore, there's the question of which legislation. I can remember a case not many months ago of a website in Spain that got blocked just because under the US administration it was deemed to be illegal even though it had been challenged in court in Spain which is where they actually operate, twice, and they have won the case. So it's like another state imposing their judicial system on another
PATRIK FÄLTSTRÖM: You're absolutely right but before we have legislation ?? before we have legislation we can not even start to look at the non?harmonisation, because you have a dispute about where this service operates that the domain name is referred to and the legislation that the registry or registrar operates in. If those two legislations are in conflict that, of course, you have a problem. But today the biggest problem is there's too many things happening not based on legislation.
MATT POUNSETT: I'm not sure I completely agree with that because a lot of ?? particularly in terms of security and mal wear, I think that actually is covered in certainly legislation because it's covered by contractual obligation, a lot of the take down is violation of acceptable use.
PATRIK FÄLTSTRÖM: No, human right issues are something that you're not allowed to write away in contractual obligations. Where you are correct though, according to law you are as an operator of an intermediary or a service, you are obliged to do whatever you request to protect your service. That is where I claim it's covered. But to use a contract to override human rights aspect.
JOAO DAMAS: Hold on a second. What would be the answer when ?? if the Spanish judicial system were to tell the operator of the .com registry that the two the metres of their service servers that are located inside Spain should have the information corrected, back to the original parties
PATRIK FÄLTSTRÖM: Good question.
PETER KOCH: I think with that rhetorical question, we have a marvellous end for this session because it shows it needs further addressing and so on and so forth. So I will take the liberty to not only close the panel, not without think thanking the panelists very much and also the audience, thank you so much for this intense participation. I would also like to thank RIPE NCC staff and thanks to our stenographer for doing a good job once again. Please give us feedback on this kind of panel that we do. So if you have suggestions for other panels for next time, please approach the working group chairs and see all of you in Slovenia.