Sixth Annual Meeting of the Internet Governance Forum
27 -30 September 2011
United Nations Office in Nairobi, Nairobi, Kenya
September 30, 2011 - 14:30PM
***
The following is the output of the real-time captioning taken during the Sixth Meeting of the IGF, in Nairobi, Kenya. Although it is largely accurate, in some cases it may be incomplete or inaccurate due to inaudible passages or transcription errors. It is posted as an aid to understanding the proceedings at the session, but should not be treated as an authoritative record.
****
>> DR. JAMES GALVIN: Good afternoon. Welcome back from your lunch. It's just 2:30. I'm still missing two panelists, so I'm thinking we'll wait five more minutes and give people a few extra minutes to trickle in. Let me offer if you've been to the website and notice there's a background paper, there are hard copies of one‑page background paper over in the corner, by the far corner there, the door, it basically gives you an abstract of about ten or so SSAC documents that we think are relevant to this discussion in general.
You can also download this online. The pdf is actually available from the Internet Governance Forum website also. So we'll go about five more minutes, and then we'll get started.
(standing by).
>> DR. JAMES GALVIN: Welcome. This is the Mitigating DNS Cyberattacks workshop, brought to you by ICANN's Security and Stability Advisory Committee. My name is James Galvin. I'm Vice Chair of the Security and Stability Advisory Committee. In general our plan is to look at the kinds of activities that SSAC has been involved in and engaged in over the past year, and it's an opportunity for us to make that work visible to this particular community.
I'll start briefly with just an introduction of what SSAC is. We are an advisory committee formed in 2001, 2002, by ICANN. They provide guidance to ICANN's board, the advisory committees, organizations, supporting organizations, to the staff and general community, we write documents, reports, try to cover topics broadly and generally as possible, we provide to provide specific guidance, recommendations in the report are generally directed at specific communities.
It's pretty straightforward. If you look through it, you should be able to see whether something is applicable to you or not. The areas in which we write about are generally about ICANN's mission, DNS, anything about naming and addressing and those kinds of threats overall. This is just sort of a look at the recent publications that we've had in this past year. SSAC has commented on the registry transition process. Obviously with the new gTLD program launching, there's a much greater emphasis to deal with the registries, there's a greater expectation registries will come and go. The guidebook, we had a technical opinion. DNS analysis, I'll come back to.
We've recently commented on DNS blocking, that was a short document, very directed comment. Certainly this topic has got attention this week. We've tried to lay out structure with respect to Whois in an attempt to help move the discussions forward. Whois has been an active topic in ICANN for a long time and in other communities too. This is some of the activities that SSAC is involved in now. We have an internationalized data registration group, looking at taking registration data and what it means to internationalize that. You see the current system tends to focus on ASCII to a large extent, that's what's mandated for the gTLD s anyway, the contracted parties with ICANN, this is joint Working Group with the GNSO and SSAC.
SSAC has a membership committee that's our evolution into a much more formal organization than we've had historically. Membership was typically based on the pleasure of the Chair with advice from individuals, now we have a process we go through for folks interested, you can express an interest and we deal with that. We obviously have an ongoing collaboration within the ICANN community, SSAC makes a point of visiting the other constituency groups during ICANN meetings now in an attempt to bring our work to them, we actually try to specifically call out work that we think is relevant to those groups, call it out to their attention, and we do have a number of inward liaisons that allow some of the other communities inside of ICANN to keep a closer track of the work that's going on.
Some activities that we're still now beginning to engage in and getting ready to create some new reports are about dotless DNS. With the new TLD program you have brand names, for example, would you want to have an @ brand and so if you have inside of e‑mail address that you want to use one label instead of two, and there are issues operationally and SSAC will have an opinion and document what we see about considerations in that space.
We also want to look at non‑U.S.‑centric DNS filtering. There was recently a technical response to the United States protect IP proposal, there were quite a number of people, Steve Crocker, Paul Dixey, Dan Kaminsky, among others who had produced a nice response to operational considerations with DNS filtering. Obviously that was fairly well directed at responding to the U.S. proposal, and SSAC will take that and we're looking to abstract that out to make it more generic and more nonU.S. specific. Finally, there's more work to be done with Whois. ICANN has a review team, and we're waiting for the review team to publish its report, and then we'll look and see if there's a work item there for us to contribute and apply it to the activities that are currently ongoing and proposed activities that will come out of that review team and see if we can contribute technically to those discussions.
The other important thing to note about SSAC is we really are a technical body. We produce advice. We have no leverage in which to ensure that our advice is followed. It stands on its own merits and we don't offer ‑‑ our comments are always grounded in a technical position, so we stick to being a technical body, we don't actually create any policy and we wouldn't want to, that's not the role that we want to play in this community.
Background reference, I put this up here to remind people there is a background document on the website underneath the workshop description, this is a collection of documents in which SSAC has spoken over the years about DNS cyberattacks and a variety of attacks in a variety of places, so all these documents have something to say about DNS threats in one form or another. What we've done is create a background reference document which has these documents listed and a short abstract about them. You can find the pdf online and the one‑page piece of paper is actually up in the corner of the room there for those who are here and would like to grab that. So that's my introduction to SSAC and some of the ongoing activities.
The focus today is on mitigating DNS cyberattacks, and first I want to give a little bit of introduction just to the DNS ecosystem to get us all on the same page so we all know we're talking about the same thing, then we'll move to our panelists here, each of whom will presents an opening statement, a position with respect to DNS cyberattacks, and then in the spirit of this being a workshop, the goal here is to interact with folks in the room. This is your opportunity to ask questions, get some advice, you know, some interpretation or clarity with respect to SSAC documents if you've had a chance to look through some of those.
So the DNS name life cycle, I want to break it out into three parts, I want to talk about it in terms of registration, provisioning and resolution, I just want to look at some quick pictures here and call out the various parts that go into a DNS system. This picture is intended to represent the registration and provisioning side of the DNS ecosystem. So the red boxes here now that have been highlighted are the registration side. The registrar boxes in orange, just to represent that they're not always present, not all these parts will be present in all systems. Obviously there are some ccTLDs that don't take advantage of registrars. Registrar wants a domain name, they have to go through a process to acquire that name, get it into a registry, and the registry has to get it out into the registry side, the parent zone, TLD.
In addition, the registrant, once they have the name, they have to go through the process of creating their zone file and putting the rest of the DNS information out there and in particular, they have to put the information that's necessary to find their Internet services. The example that I use here is just a web service. So a canonical example is www.example.info. What I want to do now is take the DNS domain zone and parent zone blocks and expand that into those represent the DNS infrastructure we want to focus on here in this discussion.
And expand that out into these parts. This represents the resolution side which is the role that the DNS plays in the Internet ecosystem. If you want to get access to a service, in this particular example I chose a web browser, I want to talk to a web server and I want that particular interaction to work.
But this kind of scenario, this set of steps would apply for any kind of web service that one might need to be going for. In order for a web browser to access a web server, it has to make a query looking for how to find that name. Now, I'm going to step through these rather quickly. It's not my intent to go through this in detail. I am doing it more because I just want to make sure the people see all of the moving parts. There are two things that I would like you to take away from watching this sequence of steps as we go through them. One is just the fact that there are a lot of moving parts, there are a lot of parts that go with the DNS ecosystem, and what's important in that is there are a lot of places where there could be vulnerabilities or where you are at risk, and I think that's significant because a lot of people, the DNS side of the system here is what happens in the background. You never really see that. People see the web browser and the web server, so they see what displays, but they don't realize all the activity that goes on in the background, so I think it's helpful and useful to notice that there are a lot of parts and there are a lot of opportunity for threats and vulnerabilities. So the first step is for the browser to ask for how to find the web server, and it will ask typically something local, a resolver, and this resolver will move on and probably ask something else up in the chain, a smarter resolver, if you will, that will do the hard and heavy lifting of going through the process of finding out where that web server really exists, and it typically has to do that by starting at a root server, moving onto a TLD server, this would be the parent DNS zone, moving onto talking to the zone server until it gets back the actual response, which it then hands back to the stub, which gets it back to the web browser, which then knows how to contact the web server.
What's important to keep in mind about that whole sequence is that's a sequence for one lookup. What's interesting about websites in particular is typically there's more than one lookup that's necessary, especially if you look at news websites, for a very common example, because they'll have references to a variety of different things on the website so you have a lot of names you have to look up. This particular lookup sequence, while it looks like it's only ten steps, it's actually repeated quite a number of times. Then of course the system itself does have certain enhancements, performance improvements, you have caching activities that go on at various places, the protocol has built‑in mechanisms for ensuring that you don't have to requery each time you need an answer, you do get a certain amount of ability to store something and save it and use it again.
So with that as an introduction, ecosystem, we'll move onto our for mitigating DNS threats. Our first speaker here is going to be Stefano Trumpy.
(please stand by).
>> He also has some comments he wants to make about the importance and significance of SSAC and its work in general with respect to Internet security. So Stefano?
>> STEFANO TRUMPY: Thank you, James. So as was said in the introduction, I'm a member of the GAC since the beginning, so I'm a senior member, and I served as liaison with the SSAC for several years and quite recently I became also a member of SSAC. My background is technical initially, but now I'm much more interested in public policy and trying to intervene and speak with SSAC with the Government. Let's start with general conversation of the SSAC with ICANN, compared with stability in the broad sense. It happened that I've been one of the authors of this final declaration on the Internet in the G8 and this is a very interesting general talk about the security, and I read only a few sentences. The first one is the security of a network and services on the Internet is a multistakeholder issue, and how many times during this IGF you listen to this term, multistakeholder. In this case we intended to say that every part in the Internet community, Government from one side, private sector on the other side and the users of the Internet have to work together and this says one first important point. Work together means not only asking for solutions but also taking responsibility for whatever is done in the field of security, all the members that I mentioned before.
It requires, second sentence, coordination between Governments, regional and international organizations, the private sector, civil society, and this gives an idea of this multistakeholder participation. Special attention must be paid to all formal attacks against the integrity of the structure, networks and services, including attacks caused by professional malware and the activities through the Internet. This is just to understand that when talking about security, this field is very large, let's say, because it regards, of course, applications and attacks that are made for different purposes.
This is very important. In this regard, we recognize that promoting user awareness is of crucial importance and the international cooperation is needed in order to protect critical results, including of course DNS, but not only this.
The fact that the Internet can potentially be used for purposes that are inconsistent with the objectives of peace and security and may adversely affect the integrity of critical systems remains a matter of concern, and of course the Governments have considered nowadays the Internet as a critical infrastructure that has to be protected and has to maintain continuity and be at the service of the community. Governments have the role to play, formed by a full range of stakeholders and helping to develop norms of behavior and common approaches in the use of cyberspace. So on this issue, the Governments are determined to provide the appropriate follow‑up in all relevant fora.
These are quite general statements, but give an idea that the interest of the Governments and the problems of security is very vast and is important. Then as James said, the role of ICANN is the role to ensure the evolution of the domain name system and it is important to note here that perhaps at least for this kind of security aspects, there is one organization that is in charge of the global management of the security aspects, and this is not valid for all other aspects that required security, and then ICANN may be seen as one organization considered connected to the DNS and try to solve them.
Of course, ICANN is not alone because we work with ITF with the standard organization.
(please stand by)
>> Connected to cyberattacks in particular, and then so the prevention of fighting cyberattacks is something that the Governments would like to know in details, to have numbers, statistics, and try then to interact with ICANN and with SSAC in order that the measures taken by technicians are good enough, and if not good enough, then the Governments would say you should do more or you should do Internet something different.
So I have to say that if we look at ICANN in recent years, and ICANN is investing a lot on security. Also with stuff, there is an investment that interacts that interacts with the stability and security committee, and in order to Milt gate these attacks. The final consideration I want to say is that sometimes Governments look at the critical problems and ask for something that could be too costly, not easily implement bible and things like that, so the interaction with SSAC is always to understand these aspects and to, let's say, try to find agreements on something that is really implementable because a perfect situation on security and stability is not possible, we have to understand this and then to do our best in order to mitigate this danger, these attacks to the infrastructure. With this, I've finished my brief introduction. Thank you. James thank you, Stefano. I want to use two things that you said to.
>> DR. JAMES GALVIN: Thank you, Stefano. I want to use two things that you said to move onto our other speakers here. In the end when you were commenting about recognize that go protecting your DNS structure is not perfect, it's not possible to offer perfect protection, so you have to look for the best that you can do and you have to decide what that best is. It's most definitely a risk management problem. And you also spoke directly about the Root Scaling Study that SSAC had done jointly with the Root Server Advisory Committee, ICANN had arranged for a study to be done which SSAC and RSAC get together and manage, so our next speaker here will be Kurtis Lindqvist, who comes to us as a root server operator and will speak a bit about how the root server system protects itself from the top issues that it faces.
>> KURT ERIK LINDQVIST: Thank you. My name is Kurtis Lindqvist. I come from Netnod. I'm going to talk about us, all the root servers, stand independently, and they all talk for themselves, I will try and maybe describe a bit what I happen to know and what I think is more or less public information. In a very basic sense, the root service primary goal is to simply serve the data as published by IANA, and we see ourselves merely as publishers of that information. Currently not any different as any of the operators today, we see a few types of attacks, we see ‑‑ attacks maybe not as much as other parts of the DNS infrastructure, because it's very uninteresting to attack root servers because we don't get paid for those who use root servers, so there's no financial incentive. That doesn't mean incentives don't exist. Most of the time I know there's been attacks of the root servers and the prefixes they announce, mostly it's been people who have been trying to help the local community.
And we've also seen various issues that you've seen around the system, black hole and other issues.
These are no approximate other threat we see other part of the infrastructure, and in that situation, the root server is very unique to study, to be honest. One of our primary targets is to prove it as we see it, we use a tool to prove this and make sure our connectivity in our nodes around the world and distribution centers we have are encrypted and secure.
The use of operators doesn't necessarily really coordinate among themselves, but we do tend to share architecture, hardware, software revisions, et cetera, and I think it's always an unspoken goal, we have tried to be a bit diverse in what we do as adding to the resilience of the system and today we have a very different approach to building which hardware we use, what software we use and how we actually do cycles around this.
The root servers also have all picked very varying approaches to the connectivity to enable them to be very distributed. Many of the root servers, today we have 250, what was the number, 255 nodes around the world with a mix of V4 and V6. Somebody's local who will respond to traffic local, somebody global, again, some of the operators use both local and global, others use most local, others use multiglobal. It's a very diverse set of connectivity used, and this is more or less deliberate. We also have very mixed approaches of where we locate this. We have seen a lot of the root servers have today deployed root server copies in developing countries or countries with limited connectivity to help the local communities and help improve performance and also again to provide a robust and secure infrastructure. One experience we had with our infrastructure is that we saw that the nodes we had in Qatar, for example, a few years ago, the sea cables towards Europe, FA1 and ‑‑ (off mic).
>> That level of reporting is sharing and level of protection to not encourage people to do more of this.
And that's a hard question, I don't know the answer to that, and that's at least our belief. Again, I'm talking to us, not for the others.
I believe in the future is might be different, we had a program launched, the current rate of additions to the zone itself, the growth of the zone, as I said, is not as much of an issue, buts we don't what these strings will mean, will lead to increase instability in the system. I think my guess is as good as anyone's.
It might mean we need to do other types of coordination and mitigations, we don't know that and I think it's a bit premature to have a view of it but it's certainly worth discussing. I think that was enough. I think I'll stop there.
>> DR. JAMES GALVIN: Thank you, Kurtis, if I could just tease out a couple things you said to make sure people can correspond to these. The root server system is obviously as a whole a very large infrastructure, and one of the ways that it achieves robustness and ensures its service is partly by being very large and one of the reasons why it is so large is because there are so many organizations that actually participate and are part of that root server system. You didn't actually give the number, but the number is 12, there are 12 different organizations spread around the world who operator parts of that root server system, so it's very hard to take out the entire system, you would essentially have to mount 12 different attacks and each of those is also a large infrastructure combined making a superlarge one.
So diversity in the form of large number of organizations themselves with large operations, which brings us down to our next speaker, Ram Mohan, who is the Chief Technology Officer of Afilias. Afilias is also one of the largest service providers and has itself a very large infrastructure in support of its customers and Ram will speak to us about the issues faced by having a large infrastructure and what it means to large enterprises. Ram?
>> RAM MOHAN: Thank you, Jim. Preserving Internet security is almost an oxymoron. There is really security, there is internet, and each of the organizations that are participating in it have a role to play. And trying to work in this area is an iterative process. Defenders are aware that they must be responsive as well as proactive in order to stay ahead of both real and would be attackers. In addition, you have software developers who must respond to vulnerabilities, and there are other service providers, but the ecosystem of the folks who have to come together to respond to cyberattacks or to DNS threats, it's a large set of providers that are involved there so when you hear people talking about taking down the DNS, I often look at that and I say, well, that's a pretty big job. What's been built here is a very diverse system and a system that has multiplicity of players in there. In some cases it could be a weakness, but in most cases that weakness is actually one of the biggest successes and one of the biggest strength says in actually preserving security. Having said that, these days it's very easy for attackers to execute attacks. You look at a DDoS, Distributed Denial of Service attack, botnets are comprised of thousands of PC's, you can rent them cheaply, software able for these attacks can be obtained readily in the underground market and attacks peak understanding at tens of gigabits per second have been recorded and the size of these peak attacks have been growing every year. In 2006 the reported size of a peak attack was about 1GBPS, the last year the size of a reported attack was around 49GBPS, about 50 times in five years increase in the size, so there's a significant rampup on that side of the threat area.
The other interesting thing that seems to be happening that large enterprises as well as organizations in the business like mine, that are in the business of providing infrastructure and therefore have to protect, in addition to DDoS, if you're providing domain names, you end up working very deeply and worrying very deeply about issues such as phishing, and certainly abuse of domain names. Domain names get allocated and get provided to various individuals or organizations, and when those domain names end up being used as part of phishing attacks, there's a significant end user impact.
Often the organizations that are affected don't even know that they are the target of these phishing attacks, and there are many incidents reported all around the world of financial institutions, other places where information has been compromised by relatively simple fishing attacks. In recent times there's been more sophisticated phishing attacks, spearphishing has been a very effective way which is a kind of a phishing attack that is targeted explicitly at a particular user or a set of users, and leverages information that makes the user believe that the person sending that attack actually knows them. Very effective, and there are, again, documented instances of Governments and entire Government agencies that have been targeted that way, allegedly by others, other players, and very effectively extracted information from computers. But if you're a large organization, there are actually relatively more trivial things to worry about. They sound trivial, but the impact can be pretty significant. In my opinion, there are really three providers who basically decide whether you as a large organization or any kind of an enterprise, three providers who decide whether you will be hacked, whether you will be compromised.
A, web hosting providers. They're the most obvious example of such a service. I mean, every company, every org needs hosting ‑‑ every organization needs hosting, but if you look at especially medium scale or smaller scale organizations, they don't often have the resources or the expertise or the desire to build and manage their own world class data centers with redundant peering connections, network and structure, they outsource it to a hosting provider and compromising a hosting provider can have a massive impact all across.
The second provider who decides whether you'll be hacked is a domain name registrar. Their security practices can affect you quite significantly. Registrars in many jurisdictions around the world and in many both gTLD s as well as country code top‑level domains, these companies are the interface between your organization and the rest of the domain name system, and they have a critical function. They provision the organization or the individual with a choice of domain name and they enable you to point your domain to your name servers of choice, and those name servers could be run by you or run by a hosting organization. We've seen several instances in the last few years where credentials for registrar accounts have been compromised, and in so compromising, you know, if the attacker can actually access the registrar account, they don't actually need to do much more. They don't need to hack your website, they just have to go to your provider and compromise the provider.
The third provider who may decide whether you'll be hacked are the DNS resolution providers. They're a potential link in the chain, if only because a major attacks, cache poisoning, designed specifically to display vulnerabilities in the domain name system. For those who don't understand this, cache poisoning is an attempt to inject false addressing information into name servers and the attempt is to readdress web traffic, and including e‑mail to the attacker servers, in some cases the attacker keeps the cases n more malicious cases they are the man in the middle, they read the data and pass it on to the intended source and often both the person who has been attacked and the person who received the messages neither of them really are aware that, you know, their message stream has been compromised. And is Dan Kaminsky a while ago demonstrated a vulnerability that leverages cache poisoning.
So with all these threats that a provider like us worry about, one of the things that I've been worrying about more recently ‑‑ and before I go there, we provision very strongly for that, many other organizations that are in the same position at us, TLD operator, DNS, managed DNS operator, provision n a very strong way have good practices, et cetera. One of the things I've been worrying about recently is what I call the rise of the small botnet. There have recently been, law enforcement and other folks have taken concerted effort to shut down large botnet and is to cut off the head of the dragon, if you will, of the hydra. And in many cases they have been successful. There was a ‑‑ last year the Mariposa botnet when that got taken down, what was discovered was that it was trying to connect to 12 million unique IP addresses, and those are the number of, you know, unique IP addresses that were attempt to connect into the botnet. That's a pretty large botnet. I worry about small botnets. Today you can buy a ready made botnet for about 2,500 U.S. dollars, you can buy a cloud‑based botnet for about $60 per day and you can buy a one‑hour DDoS attack for about $10. That's about what it costs today in the underground, if you will, to buy that. And if you look at a 1R DDoS attack, it leverages a cloud and the botnet operators who are using it not only leverage the cloud, but they give you repeat customer discounts, if you come in for a second hour, you know, or a third hour, you get a bulk rate, and if you buy that along with a compromised list of credit cards, you get a bundled price, so, you know, they're using the same economic methods that regular legitimate businesses are using, but I really worry about the small botnets. These botnets, they can be brought up and turned off pretty quickly, and by the time you actually get your instrumentation ready to go and find it, they may have actually disappeared, and I worry about that probably much more than the larger botnets or larger scale DDoS attacks because these are, in my opinion, what's coming is a bit more of a guerrilla attack on systems and as we've read, much harder to defend. I'll hand it back to you, James.
>> DR. JAMES GALVIN: Thank you, Ram. I wanted to call out specifically about a lot of what you said when you went through a very detailed discussion of various kinds of threats and vulnerabilities, and I want to thank you for that. You will find that most everything that Ram had said is actually documented in these various SSAC reports over the years. Most of these things and the activities, these threats that take place, they are described, in fact, some of them have these case studies that he talked about, registrars that have been hacked, you'll find case studies documented in those reports too, so if you're looking for issues to care about and ways in which you can deal with them, you can find some specific advice in many of the documents that are already out there.
So with that, lets me move onto our last panelist, Alejandro Pisanty, who is Chair of the Stability, Security and Resiliency of the DNS Review Team, if I got that right. Let me turn it over to Alejandro, and he can tell us about that team and he'll speak to us about how they are studying the DNS threat landscape and the kind of advice and comments they hope to provide as that review team comes to the end of its work.
>> DR. ALEJANDRO PISANTY: Thank you very much, Jim, and I apologize for late arrival. It's totally my fault. I read two statements in the same e‑mail differently. One said it was the last shift of panel, the other one said it was 2:30, and I associated last with 4:00 p.m. My apologies. That's a mental state confession. Thank you.
My name is Alejandro Pisanty. I'm a professor at the National University of Mexico, UNAM, and Chair of the National Chapter of ISOC Mexico. I've been distinguished with the designation of Chair of the Stability, Security and Resilience of the DNS Review Team. A very brief precedent, when ICANN was set up initially, it had a contract agreement with the United States Government through the National Technology and Information Agency, the NTIA, which is a unit of the Department of Commerce. This went from MOU, a memo of understanding, to a joint project agreement where there was still rather tight supervisory power for the NTIA and there were a number of benchmarks and landmarks that ICANN had to go through. One very significant change that I think reflects very well on how DNS security is and has to be managed as well as on the power of the multistakeholder approach for Internet governance is that these documents have evolved into the present information of commitments which is a set of two unilateral synchronized documents where each side states a number of things it's going to do, and ICANN is not therefore any more under any kind of supervisory authority from the U.S. Government, instead it has its own benchmarks to fulfill and there is a multistakeholder way to review that these duties to the community and Internet are being fulfilled. These take the form of reviews and there's a number of statutorily defined review, the first performed was a review on how ICANN was evolving in accountability and transparency, that's been finished and reported upon and now ICANN is working on how to take up the different recommendations. This is well‑known. The next two reviews are ongoing. One of them is so Whois where there are a number of technical and policy issues and some performance questions for ICANN and the one I am chairing, which is the Stability, Security and Resilience, what it's reviewing is whether ICANN is performing well and how it can improve on its duties establishing the information of commitments to preserve and promote the stability, security and resilience, which is a newer request than security and stability, of the DNS. This team is built with representation from the ICANN CEO, direct representation from the GAC and representation which is built bottom‑up from the different supporting organizations and advisory counsels of ICANN. So it has pretty strong powers, the review will be a documented work, of course, performed and delivered with extreme care because of its significance.
The review has identified ‑‑ well, let me add one more thing, which is an observation of one of the team members. There is a kind of ‑‑ he calls it, and I accept the term, a kind of Heisenberg effect in that in measuring the thing, you change it, this is a very vague statement for a physicist but what happens is we start and continue dialogue with ICANN and other stakeholders about how they are performing and managing the stability and security and resilience, of course DNS comes to mind so we are dealing with a dynamic target, which is good.
So in parallel, we have identified, first of all, how ‑‑ well, a very stark problem that is common in ICANN, and this is the problem of scope. What exactly is ICANN in charge of in the DNS, particularly with regards to stability, security and resilience? So instead of trying to define a hard line and say, well, you know, ICANN seasonal responsible for running the L server, which is in its own facilities and run by its own staff, or ICANN has to be held responsible for whatever crazy thing someone decides to do with a server in their charge, much worse consider a Sweden in Sweden or Japan, some of them under military authority and there's pretty strong sovereign requirements, this would be a rather pointless task, so what we have done and as I said, ICANN has been doing the same, is identify three ranges for ICANN's scope. There's the range of that which ICANN runs directly, that would be its own security, its own L server, the access to files that can be damaging, all the way from record of wrong transactions, lawsuits to the organization, for the DS. That's under this direct ICANN management.
Then there's a sphere which is under ICANN influence, where ICANN can have a strong influence, this would be for example everybody who belongs to the GNSO, ccNSO and ASO, everybody who belongs there is an active participant in developing policy for ICANN and is therefore committed to the outcomes of those policies, so of course in the GNSO we have a much more binding arrangement than in the ccNSO, the GNSO is run under contractual agreements and it's pretty tight but once you develop a policy it becomes parts of a contract to which you are bound, particularly for what's called the contract participate, that term, it sounds like cramped, like the muscles are in pain, but certainly the parts under contract and the uncontracted parties which are not very relaxed, I see them very agitated, they are the parties that are not with a contract with ICANN and that would be for example the at large which encompasses users of the DNS in many ways including people who actively purchase and sell domain names and many others. Then there's a third sphere which is basically not under ICANN's management and under no ICANN influence or very, very limited ICANN influence, which then must be managed more on the contingency planning basis. That would be where the botnets are built, that Ram mentioned, that would be where people are devising the attacks that use the DNS as probably you have already mentioned, where we look at DNS security in particular, security invites the analysis of attacks or threats and there are basically two kinds of attacks that have to be dealt with, which are attacks that are directly against the DNS infrastructure, whether against the root or whether against users' DNSs, but which actually intend to damage the DNS, and the attacks which without crippling or horribly altering the content of the DNS, use the DNS actively, not only let's say for resolution, but they do things like fast flux. We would say that fast flux ‑‑ I may be wrong here, but we'll say that the fast flux is a type of example of an attack where you are mostly using the DNS without damaging it reversibly or not making it available. So it's more like a platform for another kind of attack that's not on the DNS, whose target is not the DNS. In those cases, ICANN has very little chance to influence what happens but on the other hand must be prepared on a contingency plan basis because these things could actually hurt even the L server, example, even ICANN's ability to operate or ICANN's ability to convene meetings and so forth. That's a very general framework analysis about scope. As I said, scope, I'm not surprised, I'm a founder of ICANN, came three days after the foundation, and I'm not surprised that scope is a matter that's always under definition but I wear the scars of defining the scope of ICANN for the ccNSO and that's one big question. The other big question we're looking at at this moment is how, where, and by whom the risk framework for the DNS is analyzed, established, built and worked upon and again this has a number of vague, fuzzy ‑‑ not vague, but fuzzy borders between subsets and there's a significant development which I think will be ‑‑ one can foresee will be a deserving comment in the report when it comes out in a few months, when it's finalized and out, which will be the fact that ICANN has built from the start a very, very strong awareness and operation in the security and stability space and it has grown to the resiliency space as well, which is the, which is the SSAC, Security and Stability Advisory Committee. They've performed well, this is not the SSRC's opinion, it is the published SSAC review that says so, so I can say so confidently, that the SSAC operation has been seen as good by its own reviewers, by independent reviewers who concentrate on the SSAC, however, the SSAC has not performed fully responsibility on establishing the finding and minding the evolution of the threat or risk landscape and framework for the DNS. There are many reasons this is, this is not a discussion, this is a decision vetted by the ICANN board, and the process, this responsibility is in the process of being transferred to multistakeholder cross‑constituency group called the DSSA. The DSSA is in response to some motions by ICANN in the security space which the community has identified as preferable to have more bottom‑up, more distributed approach, that's the DSSA. What we are analyzing right now are documents and other inputs, interviews and so forth, to try to find out what would be the optimal recommendation for a mechanism which can be useful for the DSSA, and on the other hand, here is another Heisenberg measurement problem which is the DSSA is doing its own work and we want to be very appreciative of what is already being provided by the DSSA. The DSSA has already provided for example a large list of threats and risks to be managed. It's not the structure, it's not the priority, it's not the segment in many necessary ways, but it's there and we believe that we have to be mindful of it.
So unless Jim and Ram who know this process closely wants me to make more specific points, I think this is a fair point to, a fair place to stop. Thank you very much.
>> DR. JAMES GALVIN: Thank you, Alejandro. So you're right, I had not intended to ‑‑ not included the DSSA in this activity, so I'm glad you mentioned that and called this out. The SSR work is about evaluating ICANN's role in protecting the DNS, security, stability and resiliency and the DSSA Working Group is actually engaged in producing that threat and risk framework that Alejandro spoke about. So it's an important distinction to make, so there's a lot of activity in that space and in that community. One question for you, Alejandro, you said a few months for the SSR output. Can you be a little more specific about your time line?
>> DR. ALEJANDRO PISANTY: Yes. Remember that the cycles of ICANN work are in part geared to a time frame that is defined by the ICANN meetings, for one reason, even if you have the ‑‑ I mean, even if we took the extreme view of holding the review, managing the review as an audit by independent auditors, we still have to make consultations to the community. We want for this to be a community auto wear process, with community feedback on what we begin to put out, so we are geared to the timings of the meetings.
For the upcoming meeting in Qatar what we are working on and will hopefully publish next week is a set of questions and discussion points where we will be well served by having community input and feedback, on questions like I've mentioned, what exactly are the concerns of the community about the scope or maybe overreaching scope or not enough scope of ICANN in each of these three spheres and things like that.
These are coming from the work that we have already done. We have started both drafting what would be the structure of a final document and finding there the gaps and holes in information or informed opinion that are needed. So we expect to have that draft by the next ICANN meeting, which unfortunately ‑‑ I mean, I think we can have a very substantial piece of work done much earlier but the next ICANN meeting after the one in Qatar at the end of October will be already in I think it's February 2012 in Costa Rica, so that will be the cycle for when we expect to put out a large comprehensive but not final in any way draft for public comment and deliver for the ICANN meeting after that. That will be what we can foresee about it. We are trying to compress time so that the next ICANN meeting, as I said, in Costa Rica will have a really pretty complete comprehensive piece of work for the communities to comment on and what we know from many of the review processes, I've run many of them before, the AOC, is at that point we'll get very substantial comment but it will also be very disparate, it will be diverging in opinions in many different directions, so it will take significant not only time and energy but courage to process in order to be aware that everybody has spoken and yet differ from some who will say that their comment is not listed in the final document and therefore it was not listened to and it's very subtle the way it actually gets shaped.
>> DR. JAMES GALVIN: Thank you, Alejandro, and thank you to all of the panelists again for being here today to talk about DNS cyberattacks. We are now up to about 15 minutes before the top of the hour, but this is the time when we would open up the discussion for questions and comments from the floor and what people think about ‑‑ and people can think about if they have a question or not. Do we have any remote participants?
>> Yes, we do have one remote participant but so far there's been no question asked.
>> DR. JAMES GALVIN: Thank you, Paul.
Let me look around the room once. Anyone want to raise their hand? Do you have a question about DNS, anything related to DNS cyberattacks security that you would like to pose to our panel?
Okay. I will choose one to put to the panel. So Ram actually took the opportunity to comment about what worries him the most with respect to, you know, DNS cyberattacks and he spoke about the rise of the small botnet. So a question that I put to all of the panelists, the others in particular or if Ram wants to speak up and offer a second choice of something significant is, what would you say in particular with respect to, you know, the root zone and the TLZ zone, that is the focus of the discussion here, although we'll take anything that you might want to offer up, what would you say is probably one of the most significant threats facing the DNS today?
>> The DNS as a system or operations?
>> DR. JAMES GALVIN: I'll leave that open for you to answer either. Your own operation or both.
>> KURT ERIK LINDQVIST: I think that for the DNS system, I think we ‑‑ as Ram was saying, I think we'll see more advanced version of the attacks we're seeing already, more phishing, more ‑‑ I don't think we'll see any in the short term at least, any new type of attacks, more IDN coming on board, we'll see more of those issues, we'll see more issues of that in maybe the gTLD space, and I don't know that I'm saying that DNS as a system after 25 years will all of a sudden show up with a new. When it comes to the actual operations I do believe, as Ram said, attacks are increasing and we see cyberattacks increasing and small botnets is a good observation, and these attacks aren't necessarily unique for the DNS, by the way, they are towards, and if you can make money off the internet, a lot of these attacks are extortion teams or people trying to make some sort of financial gains, and for the roots for us, probably post challenges we haven't thought about, we'll see a shift of attacks through the root servers, it's interesting that I think we see more attacks now than we saw five years ago, I can't really quite explain why. I suspect that part of the reason is there's a very distributed reason, there's a very good way to test your tools, to be honest, and because, you know, again as opposed to all the other services, we don't stand to gain much and we are seeing some different types of attacks in that. With the new gTLD S, all the attacks second domain, root servers, absolutely. I don't think that is necessarily an issue, I think we're well provisioned, handle fairly large attacks today but they'll increase absolutely.
>> DR. JAMES GALVIN: Stefano?
>> STEFANO TRUMPY: I would like not to propose a but the statement about threats and I was intrigued by the idea of including the work of the final making sort of an inventory of the threats, that is done by this other group, I don't remember the ‑‑ DSSA. So looking from a governmental point of view, of course, we need numbers, so evaluate, if you make a list of threats, because otherwise the danger is that they will be considered as worries, major worries without any distinction about that, among them.
And this evaluating the damage and the possibility that this happens is something that is really, really important, in order then to evaluate how to make measures, you know, in order to slow down the possible impact because then also in security you can have some small thing regarding security that would need a lot of effort, I mean, financial and also in the engagement of the private sector. In other cases you can have something that can be easily implemented with no problem, so this idea of the list of threats has to be complemented in the way I suggest.
>> DR. ALEJANDRO PISANTY: Stefano is on track in my opinion, in the group's opinion, in the review team's opinion, and it's not as if it sounds for two reasons, first because there will never be a comprehensive final list of threats to anything, much less on the Internet. There's always a zero day attack looming, there's always someone going to discover something new that's, a flaw in the system or some new way to exploit things which are not flawed, which actually become vulnerability and therefore a threat, so whoever starts work like that aiming for a comprehensive list and then you know next year we only have to work with the threats is wrong, you have to monitor constantly where the new threats are coming.
Second, the team very early found, as many others do in this field, that working from threats is a good approach but working from risks is a better approach because when you work with a risk framework instead of a threat landscape, you are already forcing yourself to factor in impact, cost, and you are doing cost/benefit analysis as well, you know its risk. This is also important because it defines what the team's mission is. The team's mission is not to create ICANN security, much less is it to create the 13 root servers security or the 200 copies of the root servers security or anything else, none of these attacks that Ram has mentioned, for example, are something that goes directly from a rocket in space from a satellite in space to a root server. It goes through other networks. So there's no way to make a comprehensive list even of what the system is under attack.
So what we're looking at is how ICANN is managing this, how ICANN is building its threat landscape, its risk framework, and how much this happens as it has to be with the way that the root server system is run with or without the cooperation of the root server approach, and an interesting finding is that everybody has claims on everyone else's transparency. So you SSAC want ICANN to be transparencies and tell you who the root servers are, what version of software they run, what bandwidth they have available and under whose authority they are and you want ICANN to tell you their threat landscape and how they plan to manage every risk. And ICANN will tell you that, they can tell you a lot, but there are a few things that they better not make completely public immediately. The root servers will tell you that they want perfect transparency from ICANN but they will not provide you even the versions of software that they're running on each root server because that would facilitate the attacks and we can spend the whole afternoon pelting them with stones against the wall for trying to management security by obscurity but the fact is you will kill them but they will not die, so yes, there's interesting and comprehensive threat management, risk management framework, the most important thing is that the mechanisms exist for its constant evolution.
>> DR. JAMES GALVIN: Let me just add one comment. We've mentioned a couple times about the DSSA, which is the DNS Security and Stability Analysis Working Group, and we've mentioned the fact that they have their threat list and they've created a ‑‑ well, I'll call it comprehensive, it's a comprehensive collection they've put together and I participate in that group on behalf of SSAC and I will only observe that they created their initial list of threats that they are now working through in an attempt to organize by reading through all of the SSAC documents, the list that you have over here and our background document as well as many others and look through there to find anything that was DNS created and that's how they create their initial threat list they wanted top put together. Question on the floor, then we'll come back away to the panelist.
>> Sabine, it's actually more a comments than a question. When Alejandro was elaborating about the stability of the DNS and responsibility from ICANN for that, I think it's very important to point out that it's not ICANN being responsible for the stability and security of the whole DNS as a whole, it's obviously ‑‑ it's like making somebody responsible for the stability and the guarantee of the traffic system on the road. So there are obviously different operators and the different operators collaborate together, so there are people within the DNS, like in the traffic system, people fly, people responsible for air traffic, there are people responsible for ship traffic, there are people responsible for building the last road to the house, and only if everything is working fine, you will come from one house to another using the taxi, the ship and the plane and on the other end the taxi.
So like with DNS, there are different operators and the operators together build up a system which together works quite well, which together has to work robust and stable. But there is not a single responsibility from one entity that the whole system works. I think that it's very important to make that very, very clear, and I think what I can facilitate is the responsibility of those collaborators being responsible for their part of the system, as I have single responsibility for millions of users that I actually maintain their DNS system within the framework worldwide and similar responsibilities as others, so I think it's very important to clarify that there is of course a responsibility with all those single operators and there is ‑‑ and I think it's important to let the responsibility by those because they can take it and not taking away the responsibility from them and say, oh, no, we tell what you to do, so we think it's very, very important to make that very clear.
>> DR. JAMES GALVIN: Thank you very much for that comments. You're right, in the beginning I talked about the DNS system having many parts and it's port to recognize that yes there are many parts and there are many players who operate all those parts so it is a very large system and no single person can control all of it. So next hand up was Kurtis.
>> KURT ERIK LINDQVIST: Yes, I want to respond about what the root service does and doesn't ‑‑ Alejandro wasn't here when I spoke and I said again I think that there's not necessarily root servers to share, I think you look at a lot of other industries where we have security, for example, financial services, they don't share data either because you don't want to encourage people ‑‑ there are certainly operational parameters to share but under very, very strict control of how this information is used and also where this information comes with understanding, for example, software versions, et cetera, I don't think they have a big question, sharing, I think you referred to a very specific incident, I think it was more a bit of how the question was actually put, but anyway, we don't have an issue with sharing, at least we don't have an issue sharing, but we want to know for what reason how this information is interpreted and under what authority and there's an interesting point that what I'm going to say now, don't take this literally, but to play devil's advocate, ICANN is very good at asking for ‑‑ to have for example a root of operators and the other communities be responsible and take, you know, the blame if nothing goes wrong, ICANN itself always backs down when someone has tried to hold them accountable, like GAC most have questions of ICANN, this being accountable is not as simple as asking the root operators, gTLDS and ccTLDS to be accountable, it's a more complex question of who and why and we have to look at a much broader perspective than just go pick on ‑‑ the root servers are very popular to pick on but that doesn't help the question.
>> DR. JAMES GALVIN: Thank you. Ram?
>> RAM MOHAN: Thank you. Sabina's intervention was very timely and certainly appreciated. It is a shared ecosystem, but the one thing that strikes me, and Alejandro, this is ‑‑ and Stefano, when you're talking about ICANN, its role, et cetera, the one thing about DNS security or working in this area is that this is a system that imposes shared risks but individual responsibility, right? And that is something that means that we require a common set of baseline, what are the baseline risks that must be managed, must be mitigated, what are the ways to go do that, and whether that is done in an open manner or among the security operators, you could debate it. I tend to fall much more in that it should be done among those who are trusted. But because there's individual responsibility and that's not held to a common minimum standards, I think there lies some of the weaker links in the DNS ecosystem, and if there is attention and effort that should be directed, it should be directed there. You look at the root server attacks that happened before, one of the things that it identified was, you know, the value of Anycast and after the first large scale attack that was publicized in 2002, look at the next one in 2006 and the 2006 attacks demonstrated in many ways the value of Anycast, so I think the minimum standard is probably what needs to be focused on and because it is a shared risk and individual responsibility model, we have to focus on what is the minimum responsibility, what is the minimum bar and making sure that those who need it have the tools and instrumentation to actually work on it.
>> DR. JAMES GALVIN: Thank you. Alejandro, you wanted to add a comment?
>> DR. ALEJANDRO PISANTY: I only wanted Chuck to come to the microphone, for all the communities that make our work lively, not to say difficult, to explain why it is so, and the reviewing or even measuring or establishing or analyzing or even describing DNS security is a fantastic challenge and I don't say this to minimize the work you have to do or as an euphemism to say guys please help us, when I started defining the problem by explaining, by expounding on the difficulty of establishing the scope of the work on DNS security, I can only thank you, Sabine, Kurtis, and Ram, and I would have thanked Chuck if you took the microphone, and of course Stefano because the CCSO, root servers community, GAC, with Chuck that will be also the gTLD operators, it would be large to define the scope, because a large system, when it works well, I am proud of the way that my laptop runs its DNS and how I keep its tabled clean and I can say I'm part of the success of the DNS, together with a couple billion users of the internet.
When it fails, its nobody's sole responsibility and it's like okay, who to blame. So I mean, this is the virtue of distributive corporative systems. It's one system, it's operated by many, it has very specific responsibilities. If you went into say a review after an attack that was successful and that was successfully recovered from, you would find a few hero and is a few losers, but that's not the point. The point is to see what is, again, what is ICANN's responsibility and how well it is performing it.
(speaker is off mic)