Security and Stability Committee Workshop Wednesday 13 February 2008 ICANN Meeting New Delhi, India >>STEVE CROCKER: I am Steve Crocker. I am chair of the ICANN Security and Stability Advisory Committee. We make a practice of having a public session at each of the ICANN meetings to present the work a that we have done over the past few months. I usually do an introduction. I am going to skip this at this time. And if anybody is interested more than happy to ask questions. I am asking questions, too. We have a number of different things to take up today. This is slightly revised from the public agenda, but close enough. And the first few are going to go quickly, and then they get meatier and meatier, and then it will sort of tail off toward the end. We also, in parallel, as kind of an allied part of SSAC's activities, there is a DNSsec deployment activity, is and they regularly run a full DNSsec workshop or session. We had one month, and of particular interest for this session is that SSAC has made a statement about DNSsec and about its deployment. We covered that in some depth in the DNSsec session, and we accomplished SAC 026. And I don't want to say more about it here in the interest of not being duplicative except to say that's one of our outputs and I recommend that you read. Another group that operates on security matters is Lyman Chapin's R step process, and Lyman, just give a quick update or overview, rather. >>LYMAN CHAPIN: Well, I don't need very much time. RSTEP is the Registry Services Technical Evaluation Panel. At the moment, we do the process that ICANN operates to deal with requests from registries for the introduction of new services or changing services that would require contract amendments is one that has two steps to it. There's a step in which ICANN takes a look at the proposal, and there's a possible second step in which my group would convene a panel, a working group of people or task group of people to go off and investigate it more carefully. The two registry service requests that are currently in the pipeline, one from Afilias and one from NeuStar, are both -- have both been determined by ICANN staff to not require an RSTEP review. In other words, they don't represent issues of security or stability that would require an in-depth investigation. At the moment, there's no RSTEP activity, there is a possibility of future requests, you know, coming along. But at the moment, the two that have been filed with ICANN are not going to result in an RSTEP review. So that's pretty much it. >>STEVE CROCKER: Thank you. Any questions so far? I'm trying to set a good pace here. So I'll just move on. Good. Okay. We'll turn attention to the WHOIS process. We've been, from our perspective, watching the rather protracted and extended and convoluted discussions about WHOIS for a long period of time and trying to find a way to say something useful. I don't know whether we succeeded, but here's our comment for the day. This is published as SAC 027 for anyone who wants to read it. And our reports are directly accessible on the ICANN Web site. So the observation is that the WHOIS process, the WHOIS service, is a -- has grown in a kind of rickety way. And it was a kind of directory service one upon a time. But there isn't really a first-class directory service on the Internet. And so what's emerged is kind of an awkward fit. Lots of organizations use the WHOIS and make do it with the way it is. And it has a lot of technical shortcomings if one sat down to design it from scratch. There's no authentication, there's very little control over the data accuracy, there's very little control over who can use it and modification of the data and so forth. These sort of intrinsic difficulties contribute to a couple of different ills. One is, the quality of the data is variable all over the place. And a lot of contentions about how to evolve things how to put bandages around the process a lot of policy groups, GNSO, in particular, trying to say, okay, what should we do in terms of adjusting the policies about the WHOIS. So our point of view is to step back a bit and say, let's take a fresh look. So we offer advice in three directions. To the GNSO to continue the current and proposed work to resolve the legal and privacy issues within the existing WHOIS framework. Yes, do continue. No way to stop that. Two, ICANN, as an overall organization, to take much more aggressive measures with respect to improving the registration data accuracy and integrity. And then the most important comment that we make is to the community as a whole, is to adopt an Internet standard directory service as an initial step toward deprecating or phasing out the WHOIS protocol and switching over to a much more robust and manageable and supporting a wider variety of controls kind of protocol. The CRISP Working Group has developed the IRIS protocol, documents RFCs 3707 and -- 3981 to 83, that appear to satisfy the anticipated needs. So what we're doing here is we're saying, the technical work over in the IETF is worth paying attention to. Let's consider strongly adopting that, or if not that, then we should have a reason why not, but adopt some protocol, that or something else, and work a path toward that as opposed to just letting the current situation fester indefinitely and then trying to stir the pot with weak spoons, if you will. So that's the essence of our comment on that. And I imagine at some future time, we'll come back and measure and see whether or not this had any impact or whether there's been any improvement. Any questions? Good. The next talk is on DNS Fast Flux. We've been working with the Antiphishing Working Group. And I'm pleased to have here today Rod Rasmussen from the Antiphishing Working Group. And he will be giving this talk instead of me, which is much better, much, much better. >>ROD RASMUSSEN: Okay. Good afternoon, everybody. And thank you for having that (inaudible) here and doing this today. This is a presentation based on an SSAC paper that was just released. What was the date? About two weeks ago. >>STEVE CROCKER: Something like that. SAC027, I think. >>ROD RASMUSSEN: Very excellent paper, (inaudible) primary architect on that. He worked with a lot of the Antiphishing Working Group members, gathering data and information about Fast Flux, and presenting, I think, a very approachable manner for not just technical, but also, I think, the layman as well. Just basically run through the paper and give you some ideas of what it is and how you might be able to mitigate and what is Fast Flux, why it's there, just to keep sites alive on the Internet that are undesirable and to allow criminal enterprises the ability to prolong and obfuscate where they are. It's using a technique in DNS where you're just rapidly changing the addresses that the sites are resolving to and/or the name servers themselves. And we'll go into the various levels of that. But the idea is that if it's jumping around a whole lot, it's really hard to grab ahold of the content that you're trying to remove from the Net, whether that's a phishing site or some other undesirable content. The basic Fast Flux involves just the I.P. address of the Web site, we have name server, where name servers are being moved around from one spot to another, and then double flux, where we're actually seeing both of them, where the Web site resolves to and the name servers are supporting that domain name that are hosting that are moving rapidly as well. So how does it work? The bad guy there, he uses a botnet. Botnet is a large number of machines that are effected by bot herders, the term we use in the industry for it, who gets a lot of machines under his control by virus infections and that has those in a single network that he can control. The customer of the bot herder, the criminal who's going to make the attack, leases that out. He can lease out the (inaudible) botnets to all kinds of operations, whether it's phishing or DDOS attacks or various other things. Also, the person who wants to launch an attack can go somewhere else or (inaudible) same bazaar on the Net and buy a kit for establishing a phishing site or what have you. Then the -- our central character here goes to a registrar and registers domain names, typically lots of domain names, with a, typically, stolen credit card of a victim of a phishing attack. And then the registrar can also flux the name themselves that are typically based on the same domain name registered, but it can also be other name servers through other TLDs. Just a combination factor there. Next step, use the command and control system of the botnet to load DNS information into your various name server bots. And then have that command and control system rapidly rotate the actual "A" records of the domain names onto the various places where you're hosting content. What's interesting here is where the domain name resolves to on those bots, oftentimes, there's actually no content there at all. All that is is a port redirector to yet another content server that's somewhere else, which is, again, an attempt to hide from law enforcement. The FBI and various law enforcement people throughout the world have gotten ahold of a lot of bots. Typically, there's not much there to work with, because there's a piece of software running on that that takes that inbound query across from the Web site and then pulls the content from somewhere else, and then presents it out. Some of them are very clever, they don't actually even have a file on the hard drive. It's just once the bot is infected, they run a piece of software, and it's just in memory. So as soon as you turn it off to scrub the -- or to pull the hard drive for law enforcement to be able to look at it, there's nothing there, which makes it very hard to deal with that. See if we can get this to it's frozen up on me, Steve. There we go. So once he's got his botnet in place, then they send spam, lots and lots and lots of spam, typically, in these Fast Flux type of attacks. And often, because they're using Fast Flux they can change the host name record as well and send the customized host name record to every victim. So you can use that to get past filters. You can also use that as a direct marketing technique. So you can know which victims you sent an e-mail to who came and clicked on your site and entered their information in. So you kind of know who the suckers are out there, so you can go after them again. So they're taking classic techniques from all sorts of industry, and applying it to their own criminal industry. So -- and then the steps -- the next steps, basically, repeat as often as possible, moving it around, so that when law enforcement is going after these things or it's trying to -- somebody is trying to shut it down, it just keeps moving. It's whack a mole with millions of moles out there. So the mitigation alternatives were presented as alternatives. You can shut down the bots, the botnets, host the flux, you can shut down the actual hosts themselves, or you can remove the domain names that are at the root of the actual Fast Flux setup. So show the options here. Challenges. There's hundreds of thousands of these, or at least thousands, that rotate through a single domain name in a typical attack. You can always use things to try and keep the bots from showing up in the first place. We know that's a continuous struggle. And the virus writers keep creating new ones even faster every day. That's an uphill curve, unfortunately, as far as numbers of vulnerabilities out there. And then other things you can do are try and do white listing and process execution within the host itself, so that you, you know -- all these various antivirus techniques, basically. The -- not quite sure what Dave meant by the last point there, so I'm going to skip that for now. I'll come back to that if there's a question on that. The host -- That's, typically, just a shutdown type of situation, where you're trying to get after those. There are various ways of going after individual hosts. ISPs are fairly cognizant of how the problem exists on their networks. But, you know, there are still some -- I think a learning curve and a response curve, how -- from a policy perspective, how ISPs are dealing with botnets in general. So, typically, today we still have a very reactive situation where you've got to, as law enforcement or as a shutdown team, get ahold of somebody, tell them to take this thing off the net. They respond. And the process can take from a few minutes to a couple of days, depending on the ISP and the time, you know, is it a weekend, holiday type of situation. So it's not all that effective. And, again, it's on a scale where you've got thousands of these things. And, really, by the time you get a lot of these shut down, the damage is mostly done. Additional measures that are -- have been proposed in the paper include accelerating the process to remove domain names and better data sharing between ISPs, CERTs, law enforcement agencies, so we know where these problems are. Speaking of removing the domain names, that really is the key to most of these Fast Flux attacks, because that is the piece of information that is a single point of failure for an attack. There are certainly several techniques you can use to mitigate or prevent these Fast Fluxers from utilizing your registrar service. And there's a wide variety of them out there. And that's part of what the Antiphishing Working Group is trying to work with registrars to do on best practices, is to address just this situation. This -- the paper was put out prior to finding out that there were some actual legitimate uses for Fast Flux. So we have a situation where some of these recommendations here may not work for some legitimate purposes. So we're taking a look at how we can quantify and have those legitimate uses still be able to be done, typically, for protecting against DDOS attacks, while we're still being able to detect and mitigate against these Fast Flux attacks. But the techniques here are fairly straightforward, I think, as far as, you know, taking a look at the behavior, which is rapidly changing the sites and the name servers, and taking a look at direct attempts to end that behavior. The -- basically, you can go everything from technical to policy options. Some other options, quarantining domain names, rate limiting changes to name servers. There are certainly a wide variety of options available. The problem I think that we're seeing is not -- they're not really being utilized very much at this point. I think the registrars are fairly cognizant that this issue is out here. And, obviously, the domains that are put up in this fashion aren't being paid for. The registries are also noticing these and can actually help in this. And we've had very good cooperation from the registry operators in looking into the problem and potential solutions as well. So there is good work going forward on this. And we're to the point now where I think we're trying to develop good policy that can be rolled out to the community as a whole so that we can all attack this problem on a unified front. The findings of the paper, you know, are pretty straightforward. They're taking advantage of the way you can move a domain name around rapidly to have their sites stay up and do all their illegal activities. I think the bottom two things here are pretty interesting in that you have the ability as law enforcement or a registry or registrar, somebody on the good guys side, to be able to monitor this stuff. It's really obvious most of the time what's going on. So its behavior, by its nature, is very detectable. So there are mitigation steps we can do against it. It's just a matter of putting the policy in place and then actually doing it. And so that's what we're on to now. And I think I already mentioned that. >>STEVE CROCKER: Leave that there. >>ROD RASMUSSEN: Okay. >>STEVE CROCKER: So, Rod, thank you very much. Before you step away, I want to ask you to say a bit more. We have been trying to make a practice when the opportunity -- sorry, Rod -- that as we encounter specific topics that cross different areas, to work with other groups that are also working in the same area. So we had, for example, very successful partnership with the Root Server System Advisory Committee to work on IPv6 addresses in the root zone, and now we're working with the Antiphishing Working Group on Fast Flux. Would you just say very briefly a bit about what the Antiphishing Working Group is just for this audience, brief introduction. >>ROD RASMUSSEN: Yeah, the Antiphishing Working Group is really a pan-industrial, nonprofit, industry organization that involves people from industry, from the victim companies, from law enforcement, from academia. We meet twice a year to bring the community together to talk about the latest phishing techniques and what can be done as a group to bring resources together to bear on the problem and then to how we can influence policy and stakeholders in the community, like the ICANN community, with -- to be able to mitigate these things and prevent them from happening in the first place. Our next meeting is in Tokyo in late May, and we invite participation. >>STEVE CROCKER: How many are members? >>ROD RASMUSSEN: There's about -- just shy of 3,000 members. >>STEVE CROCKER: Wow. >>ROD RASMUSSEN: And representing about 1500 to 1600 different organizations and companies. There are -- I'm co-chair of the -- what's called the DNS policy working group within the working group. And we are doing -- we actually have several members that are within this community here as well, they're assisting actually doing work and creating policy and working with the outreach efforts. >>STEVE CROCKER: Right. We -- in addition to this public session, we take the opportunity when we're at ICANN's meeting to have an internal SSAC meeting. And we met with Rod yesterday, I guess -- I'm losing track of time -- and went into things in depth. And Ron's been working very closely with Dave Piscitello, who isn't at this meeting, as the primary participants in putting this work together. So thank you very much. Appreciate it. >>ROD RASMUSSEN: Thank you. >>STEVE CROCKER: Yeah. >> Is the time for questions right now or at the end of the session? >>STEVE CROCKER: Yeah, we can take a question or two. I'll keep it kind of constrained so we don't intrude. >> Microphone. >> CARSTEN SCHIEFNER: Is there a microphone? Thank you, this is Carsten Schiefner, for DENIC this time. My question is whether, if you would only have considered technical implications as laid out in your presentation, or whether the Antiphishing Working Group has also considered legal implications, in particular, when it comes to taking down a domain name. >>ROD RASMUSSEN: Well, taking down domain names is something that the community has been doing four years now. So that -- whether it's Fast Flux or it's some other technique they're using, that's still something that's a fairly common tactic at this point. Now, by taking down, that means working with the registrar or registry involved in -- depending on the country that it's located in, and working through their process, whatever that process is. That has changed over time. It used to be a very slow process with -- involving law enforcement in various forms and things like that. The volume of attacks -- and it's a large volume, thousands of domain names a month that are being used for this, or more -- has, you know, kind of led to an infrastructure, if you will, where the responders are able to get most registrars to work very quickly on that. ccTLDs are a challenge, because when new ones are taken on, there's an education process involved. But, typically, they, too, will change policies and procedures to make it far quicker to mitigate these things. So it's an education policy process throughout. >> CARSTEN SCHIEFNER: Okay. The reason why I'm asking is that, for example, DENIC and there are many other ccTLDs within Europe which have more or less the same contractual model, is that you will have a direct contract between the registry and the registrant. So -- and by this contract, DENIC is just not able to terminate the domain name, only if there are some special circumstances. But just because a third party tells DENIC or any other registry that, yeah, this domain name is being used for fraudulent activities or anything, this is just not enough. That is possibly part of your education part, to some extent. >>ROD RASMUSSEN: You work through a registrar model with DENIC. .DE domain names are not too much of a problem to get taken down. >> CARSTEN SCHIEFNER: Okay. Thank you. >>STEVE CROCKER: Dennis. >>DENNIS JENNINGS: Dennis Jennings, board member. I understood some of that, so it's going to be sort of a high-level question. What, if anything, should the board be doing to stimulate activity within the ICANN structure to address these problems? >>ROD RASMUSSEN: Well, not being an expert on the ICANN board, I can give you my opinion. But -- and, actually, that's one of the reasons I'm here. And I've been attending the ICANN meetings over the past couple of years now, is really to raise awareness of the issues that are completely dependent upon the domain name community to address. Fast Flux, I think, is one of the most extreme of those. The only way to really mitigate a Fast Flux attack is to remove the domain names themselves. And policy around that really needs to be developed in order to both mitigate, but also to prevent them from happening in the first place. And that's -- you've got to come here to do that. So it comes under the auspices of ICANN in that regard. Other than, of course, the ccTLDs. But even there, there's influence. >>BRUCE TONKIN: Hi, Rod. It's Bruce Tonkin from Melbourne I.T. What would be an example of a policy, in your mind, to address Fast Flux? I want to understand a possible policy that could be worked towards. >>ROD RASMUSSEN: That was covered in the paper and a little bit in the presentation. I didn't put the presentation together, because I had to kind of figure that out as we went. But the -- I think there are some really good ones there to look at as far as TTLs on domain names, looking at, in particular, name servers, because double Fast Flux is required. That goes through the registrars. The only way you can change a domain name is to go to you a registrar and do that. You can put policy on how often name servers are changed. You can put policy around the distribution of name servers. >>BRUCE TONKIN: That's not generally double flux that we're seeing; is that right. >>ROD RASMUSSEN: You're seeing a pretty good amount of double flux, too. It varies. It depends on the criminal gang and how they're set up in their infrastructure. Single flux, that's -- it gets outside of the purveyance of the registrars. There's not an ISP that's responsible when you think about the fact that they're using bots that are hosting malware that -- or running DNS on them. Where does the responsibility lie there? That's complicated policy at that point, because there's not an ISP or a hosting company that you can go to and say, "Turn this DNS off." It comes back to the domain names that they're set up on. And those don't necessarily -- the domain names that are bad aren't necessarily on the same as the name server domain that are being used. They could be in different TLDs. >>BRUCE TONKIN: The only way you can deal with that is have authenticated name servers that you don't delegate to a name server list that's an authenticated name server. >>ROD RASMUSSEN: There's a policy right there. >>BRUCE TONKIN: That's pretty drastic, but that is one way of doing that. >>STEVE CROCKER: The thing I am finding interesting here, is I was about to call on you, Bruce, even if you hadn't raised your hand because the question is what should the board do. You introduced yourself as from Melbourne I.T, but of course you are also on the ICANN board, and not incidentally, past chair of the GNSO council. So I thought you were in the best position to answer questions, as opposed to ask questions. >>RON ANDRUFF: Ron Andruff, RNA partners. Rod, you mentioned what can the board do, and I wanted to capitalize on what we spoke about last night because we do have board members present they can bring this to bear within the board discussions and with discussion with staff, and that is financing. You mentioned if you had some funding coming from ICANN to assist -- because as I understand it, this is a volunteer organization. If this is a critical factor, and I think Steve would agree this is a very important issue, it would be very good if, in fact, you could get some funding to really make sure this is -- that we have got the watchdogs on the parapet, so to speak. >>ROD RASMUSSEN: I'm sure the rest of the folks at APWG would love that. Certainly I think that as an organization, a volunteer organization that's funded by members, because it's really towards education and the conferences, we're trying to develop resources to provide shared informing and intelligence, not only to law enforcement but also to ISPs and registrars and the like, where we can see where the fast flux -- for example, for fast flux, where that kind of activity is occurring, how it is occurring, get that information to registries and registrars so that they can then prevent the same bad guys from coming in and doing the same thing. That takes, you know, resources to be able to build that kind of infrastructure. So that would certainly be an option that would be interesting. >>STEVE CROCKER: Let me -- oh, okay. One more question, but let me make this the last. >>ERIC BRUNNER-WILLIAMS: Thank you, Steve. Eric Brunner Williams from CORE. You asked about policy. Would it affect the behavior that you are attempting to modify if modifications to name server records were charged for? If registrars charged for it as opposed to getting it by time. >>ROD RASMUSSEN: Dot DK does that, for example. >>ERIC BRUNNER-WILLIAMS: So then when you asked for what policies could ICANN make that would modify this behavior, making it part of the contractual obligation of registrars to charge for this would have an effect on the behavior you are looking for. >>ROD RASMUSSEN: Certainly. I'm sure the registrars would love that, too. >>ERIC BRUNNER-WILLIAMS: I am a registrar so I wouldn't mind making some revenue off of that. >>ROD RASMUSSEN: That certainly is an option for the behavior. Another option I am seeing is just doing a charge. >>GREG AARON: I would note every registry has to do that. >>ROD RASMUSSEN: And the registries would be involved, too. >>GREG AARON: And different (inaudible). >>STEVE CROCKER: I have to say that's one of the more charming ideas I have heard and I like. It's interesting. I can see some rebuttals to it but it opens up an interesting one. So with that, let me draw this part to a close. We have a couple of other meaty things to dive into here. So thank you very much, appreciate it, and thank you. [ Applause ] >>STEVE CROCKER: We are powerless. Yet another thing strikes us. Everybody should stand up and stretch for just a second. That doesn't require any electricity. >>DENNIS JENNINGS: Oh, Dennis Jennings kicks the plug. >>SUZANNE WOOLF: That's pretty benign. >>STEVE CROCKER: Excellent. Thank you. I am going to switch to the broad topic that includes front running and -- whoops. That is not good. Other possible misuses of information. Does anybody have a kleenex or soft cloth or something handy? >>DENNIS JENNINGS: A handkerchief. >>STEVE CROCKER: Macs and water don't mix here. Thank you. We're going to do a pair of things. A while ago, we were challenged to look into the notion of front running. And front running is the name given to the following idea. A user goes to register a name or test whether a name is available, and somebody jumps in front of him, hence the term front running, and grabs hold of that information and registers it in place of him. So it's kind of like claim jumping, in a way, from old-time land rush and gold mining days. There are a lot of rumors around as to whether this does or doesn't happen, and we found ourselves with a lack of clarity as to whether this was real or just worried about. So we opened the door for anecdotes to be reported, gathered some information, and tried to make sense out of that. And what I'm going to present here is the results of that activity. Very recently, Network Solutions, Incorporated -- it's not incorporated; right? >>JON NEVETT: LLC. >>STEVE CROCKER: But it is NSI? It used to be. Network Solutions LLC modified its registration practice and created a certain amount of interest in the process, and there's questions raised about whether or not that was also or another form of this. So what I am going to do here is present, briefly, the results of the survey that we did. And then I am going to turn the floor over to Jon Nevett from NSI. Do you no longer use NSI at? Whatever. Okay. Just not late for dinner; right? >>JON NEVETT: Exactly. >>STEVE CROCKER: All right. So, we issued -- am I live? We issued an advisory in October. We offered some preliminary findings that some users claim that parties associated with the domain name registration process participate in front running, but no Internet user actually presented detailed sufficient information to support or disprove those claims. So we asked for some community input. We reviewed quite a few claims that came in. And the majority of the claimants were contacted back by e-mail for additional information and were informed of our interpretation of the chronology. This nice piece of artwork represents the transliteration of an ordinary pie chart from one piece of software to another. [ Laughter ] >>STEVE CROCKER: But the numbers are the same, and proportions are the same. And the results are as unsatisfying and uninformative as you could hope for. 19% we were unable to study. 10% we failed down as a failure to renew the domain name on time. 25% we judged to be highly sought-after names, and so while somebody thought that just because they asked for it, somebody must have jumped in front of them, it was the kind of name that one could predict from regular traffic that it would be caught up very rapidly. Tasting and typo squatting. And we encountered zero cases that were clear cases of front running. I don't know if any of you have contrary data. If so, we are eager to hear it. It's the kind of thing that puts a bad taste in the industry, and from a consumer confidence point of view, if you will, would rather there not be the perception of this. So if we can find a way to bring perceptions in line with facts, or facts in line with perceptions, whichever, we would like to do that. No smoking gun. So these are the statistics. 120 incidents reported to it. 38% were live with host advertising. 27% registered using private or proxy services. And so forth. You can read the statistics here. A very small number looked like they were candidates for dispute resolution process. All of this is published in a report which I commend to your attention. Three-quarters of what were claimed to be front-running incidents are directly attributable to tasting and secondary market activities. It does not look like there is an active front-running activity or a lot of going on. A lot of things going on and a lot of reasons why one might jump to that conclusion. So we can't confirm. Many users do not approve of domain name cutting, front running, hijacking, tasting, and conclude that the registration process is not trustworthy. I will say personally, I think this is shared, that there is some issue of the level of trust and confidence in the marketplace, and that's worthy of examining over a period of time. There is a broader question of what is the responsibility or obligations for any party that is in the chain that is taking information from a user and how they use that. And there are analogies in other industries. For example, in financial services or in health-care industries, what about the privacy and proper use of information that a customer or a patient or a client turns over to their stockbroker or to his attorney or to his doctor and so forth. Are registrars and registries and resellers in the same category as doctors and lawyers? That depends on what you think of doctors and lawyers, I suppose. But anyway, there's a maturation process in the industry, and I think that we are in the early phase of that and trying to work out all of that. There's an education process to go through. We also recommend that registrars should make a point of saying how they do and don't treat information. And that registrants should appreciate that domain names are heavily speculated and that, under some circumstances, an availability check may disclose that they have an interest in it and they may want to take steps to protect that. For example, registering it on the spot. That's the majority of what we have to say. As I say, the details are in the report. And as I said quite recently, Network Solutions has modified its registration practices and raised a related, but somewhat different, set of questions, and so I would like to turn the floor over to Jon Nevett from Network Solutions. >>JON NEVETT: Okay, great. Sorry about that. Does this work? >>STEVE CROCKER: Yes. No, apparently not. >>JON NEVETT: Can everyone hear me? Sorry about that. First I would like to just thank Steve for inviting me. We have had a very interesting dialogue over the last few weeks about front running. Actually, it's been a few months. We have raised and other registrars have raised front-running issues for many months, probably over a year now, so I was surprised to Steve's report. We, on the registrars' list, have talked about domain name front running for a while. And I suspect that there's a misinterpretation of some of the data that we see in the SSAC report. But we can talk about that. >>STEVE CROCKER: Yep. >>JON NEVETT: Essentially, domain name front running, as Steve said, is essentially where a party goes out and finds out search information from a customer, and then proceeds to register the name if the customer couldn't do it right away. In other words, a customer checks for a name, they haven't decided whether they want to did it or not, and they go back hours or a number of days later and the name is already taken. -- to protect our customers from, essentially, domain name front-running. So we implemented in January '08, last month, in response to these customer complaints, domain protection, customer protection measure. Essentially, what I think Steve is looking at in the report is the line item that talks about tasting is, in many instances, domain name front-running. So what's been happening -- and we have information about this -- is domain name tasters register names in vast bulk and then they taste the names and only keep a very small percentage of the names that warrant purchasing because of traffic or pay per click. So the domain name tasters are looking for various sources of data. They look for bulk data wherever they can find it. The theory is that there were certain ccTLD registries that because when a customer comes to almost all registrars Web sites and asks for a name, if you ask look for Steve, will look at various dozens of different TLDs and see if the name is available. So one of the ccTLDs, for example, or maybe a gTLD, will be selling the data to front runners and tasters. So the tasting line is probably synonymous with the front-runner line. So what happens is they register these names in advance of customers, and then they taste it. So if we look at the customer complaints that we received and then we looked to see who was the registrar when they were reserved, and they were always the same one or two registrars where they are known big taster as. We also had some complaints where the customer said they looked at a name, they didn't purchase it, and then they got a phone call a day later. Asking if they want to purchase the name at a highly inflated price. Someone found out that information somehow. And it could be ISPs, and there are other sources that the initial SSAC report mentioned as potential sources for this data. So essentially what we are doing is for our customer benefit we are protecting the customer by when they search for a name, we will reserve the name in a client hold status. It doesn't go in a zone file, it doesn't go in the DNS, and then it's available for registration at Network Solutions. And why that's important is that Network Solutions, A, obviously doesn't engage in tasting, but, B, tasting companies cannot register names in Network Solutions. They cannot come in and register our names because we will not provide the bulk refunds to tasters that they need under their business models. So we don't keep the names, sell them back to our customers at above retail prices, we don't sell them on the secondary market. They are simply available in our regular retail Web site. We have never kept the names after the four-day period. We have never looked at traffic sites or monetized the domain names in any way. So if they don't resolve, they are there for that customer at Network Solutions. Obviously, it wasn't a very popular decision. I fully recognize that and understand that, and got a lot of good feedback from this community. And based on the feedback from Steve and from others, we made some enhanced two days after we rolled it out. We provided additional notification and explanations to our customer base. It's essentially on about 18% of our front home page right now. And if you log into your account, if you are a customer of ours, you will see it there, too. We made sure that the names don't appear in the zone file, so no one could see them. And we removed the process from WHOIS searching. It's just searching on our storefront, on our home page. And then importantly, we provided our customer service reps, we have 24 by 7, 365 days a year customer service. So if a customer wants -- doesn't want to buy the name at Network Solutions, wants to buy it somewhere else, they can call it up, we will delete it immediately, or they can wait the four days. It's totally up to the customer. Again, we prevented the names from resolving to any Web page and don't, obviously, use any PPC ads or anything like that. There has been a lot of discussion, a lot of confusion in a lot of lists, I have seen a lot of blogs. The first point I want to make is we are absolutely not front running domain names. We are protecting our customers from front running. The measure was implemented for the benefit of our customers and, as it turns out, our customers are appreciating that. Again, we don't keep the names. We don't do anything with the names. We just hold them there. They never resolve, they are never monetized, and if you don't want to buy it from us, you could call us up and we will delete it immediately or you can just wait the four days. It doesn't expose names to front runners because, one, they are not in the zone file. Essentially one criticism that we received is that we are not, at this point, reserving it specifically for the customer who searched on that name. And I understand that being a concern, and we are addressing that in a number of ways. One, we are looking at a future enhancement, but, two, it would be a huge coincidence at this point for a customer to search for a name, not buy it, and then essentially another customer comes and looks for the same name, without any inside information, in the same four-day period at the same registrar. But I wanted to make sure, because we heard that criticism. So we did a study of all the names that were reserved and then purchased during that four-day period, and over 90% of the searched names were purchased by the same customer. And we looked at I.P. addresses. So we know the same customer is coming back and buying those names, and the other 10%, some subset of that, at least, are people who search at one computer and buy it at another. So you may search in your office and buy it at home, because it's a different I.P. address. Also, another concern that some people raised was what happens when the names are deleted, if they are not purchased. Do they get into that tasting flow. And we looked at the names that we reserved and subsequently deleted. 98% of them are still deleted. They are not in the zone. They hadn't been picked up. And of the 2% that were left, they were reserved by registrars that don't engage in tasting. So it's the Go Daddys and the other large registrars that you would expect. We have our systems, our engineers put systems in place to make sure that it's limited, so there's no malicious abuse that could happen through bad actors. There's rating systems. There's a limit on the number of times it could be reserved. The measure, we have been informed, the measure is absolutely consistent with the Registrar Accreditation Agreement. We informed our customers about the measures, they provided positive feedback. And in a competitive marketplace, we have to provide service for our customers as a way to build trust. An important point and the final point I want to make is that we are absolutely supportive of the ICANN board's decision to assess the domain name transaction fee during the names deleted above a reasonable threshold in the AGP. And, essentially, we agree with the board that that should do away with domain name tasting. When that happens, our customers will no longer need protection from front running, we believe, because we think the front running and the tasting will go away, and we will no longer need to provide this service for our customers. With that, we will just open it up for questions. >>STEVE CROCKER: Anybody want to ask -- hands are shooting up. >>THOMAS NARTEN: So I have just one question I will ask, and that is do you have any hard evidence that front running is going on? Clearly, as Steve reported earlier from the SSAC report, there is a perception that front running is going on, and the question is whether -- it calls to mind, do you guys have any hard evidence as opposed to just it's happening? >>JON NEVETT: We do. We have enough customer information that we researched, and we have had conversations that were done under confidentiality agreements that I can't specifically talk about. But yes, we were comfortable enough that the front running existed and comfortable enough to take this action. As you know, it wasn't incredibly popular in this community. But we did it anyway as a protection service for our customers because we knew it was happening. >>THOMAS NARTEN: And have you shared any of that information with, like, SSAC for example? >>JON NEVETT: No. As I said -- >>THOMAS NARTEN: Because the question I really have is, if there is evidence it's going on, the next obvious question is are there ways you can actually stomp that out or is it basically inherent with the system you have? >>JON NEVETT: No, I think you can stomp it out by doing what the board did, which is take action against tasting. We discussed it with SSAC, we discussed it as generally as I can -- as specifically as I can, rather, based on the commitment of confidentiality. But I think tasting will go away. There are now three different options of how to address the tasting issue. There's the GNSO option, the ICANN board option, and then there's the registry services option. And I think the board one cite way to go at this point, and I think it will do the trick. >>THOMAS NARTEN: Okay. Thanks. >> Hi, I am (saying name). I want to ask, (inaudible) and we are getting the cases in which the bank domain in India, for that somebody is requesting from other ccTLDs, like dot (inaudible), dot CN, different combination of name. So how do you stop this kind of domain registrations? In which people from different ccTLDs are requesting for the registration of that particular domain? >>STEVE CROCKER: If I understand what you are saying is, there's an attempt to register a bank's name in other country codes. And if they succeed, then they use that for phishing or something like that. >> Yes, yes. >>STEVE CROCKER: That's a somewhat different but also important topic. Any comments on that? >>JON NEVETT: Yeah. You could look to your left and there's a gentleman that I'm sure would be happy to help you out, file a UDRP claim or something like that. >>STEVE CROCKER: Questions over here. >>ERIC BRUNNER-WILLIAMS: Steve, you and John have come to two different conclusions. And I don't assume it's based on the same evidence, but it's probably using different methodologies. So can you reconcile your two methodologies without necessarily commingling your data? Basically I would like to know why it is we have two different methodologies arriving at two different conclusions on the same or similar data sets? We must be making a mistake somewhere. >>STEVE CROCKER: Yeah, it's a good question. I don't think we're looking at the same data, frankly. So I think it's not as simple as two different interpretations of the same data. I think that all the data is fragmentary and we're seeing different pieces of a large puzzle. I've learned something in the dialogue with Jon over the past day or so which I'm about to engage in a kind of direct back and forth here a little bit, but I wanted to -- so hold that and we'll come back. There's another question to your right. >> Hello. Jay Daley. There are two things here, Jon. One is not a question. But if you don't share the data, nobody's going to believe you. I mean, if you have that data there of provable front-running, if you have a video, CCTV, a man sitting there, that man is front-running, great. We need to see it. Because we have done extensive searches through our registry, through every single complaint, and there is not a single case of front-running we can prove. My view on it is that the world is just much smaller than people believe that the world is and that the same stimuli affect all of us, and there are so many people looking for good names, there's just too many coincidences. But, anyway, that's a separate matter. The question I had for you, though, is how, by what mechanism do you think that changing the add grace period is going to eliminate domain name front-running if it does actually exist? >>JON NEVETT: I think it's the tasters that are engaging -- I think it's the tasting folks that are engaging in this front-running. It's another data source for the tasters. So, essentially, once you assess a fee during the AGP, you will do away with the business model of the bulk tasters, and therefore they won't be looking for these kinds of data sources. >>JAY DALEY: But surely the point about front running is to identify a high-value name which somebody else has identified which you haven't before, and then register it and keep it. >>JON NEVETT: No. I don't think that's right. What we think is that the tasting business model is not looking for a high-value name. So the tasting business model is looking for a name that is worth more than $6.42, essentially. >> JAY DALEY: But the whole point about the tasting model is, you don't need external inputting to do it. You just generate it. You can generate whatever list of names from anywhere, from anything. >>JON NEVETT: But they're searching from data sources, as I said. So this is one perfect example of a data source that would be attractive to a taster. You're looking at bulk names, you're looking at a list of names that you could push through the system and see if they're worth more than $6.42. >> JAY DALEY: Are you saying that that list of bulk names comes from people doing WHOIS checks or from search terms in search engines that people haven't yet registered? >>JON NEVETT: It could be a number of sources. But the ones that I'm focused on is, as I mentioned, it would be a registry source, not a WHOIS search, but a name availability search. >>STEVE CROCKER: Let me -- I've been following that you will very closely, and the question about looking at different sources, I think, is very apt here. For the benefit of everybody else, Jay is CTO of Nominet -- is that correct -- and has done extensive work on this and has been one of the people who has taken the position that this does not really -- front-running is not really happening, he's looked at a lot of data and gave us advice very strongly that we'd be wasting our time to look at it. And we plowed ahead anyway, and what we got so far confirmed what he said. But we are still not happy is where we are. So here's the intriguing thing that, to me, has popped up from the discussion. And you said this, but I want to raise it up to very high visibility. When you take in a name, let's say cool -- nextcoolidea.com and somebody says, I want to register it. You check, of course, VeriSign's registry to see if that exists. But if I understood what you said, you also, as a matter of form, also check that name in multiple other registries, including a number of ccTLDs. >>JON NEVETT: Actually, let me clarify that. The way the search -- our search works -- and I think most -- or many registrars -- you don't search for something dot com. You put in "nextcoolidea" in the box and then it searches, as you said, various gTLDs and ccTLDs that we support. And I think that's consistent with most registrars. >>STEVE CROCKER: Okay. Now, the part that's delicate to talk about, because it moves into undocumented and sometimes things that are protected by confidentiality, but I've heard from multiple sources now the possibility that some registries, and most likely, they're ccTLDs instead of gTLDs, are taking those searches that they're on the receiving end of and feeding them out the back side and selling those to tasters who are interested in that stream. And you're shaking your head "yes," so you say that is the syndrome? And what we don't have is the documentation of that. Dan. >>DAN HALLORAN: I just wanted to ask -- I guess Jon could tell us which ones, 'cause you could just do 100 searches and see the data and send that search data to your ccTLD partners and tell us which ones are doing the -- >>JON NEVETT: We talked about this before. And I don't see that, because we won't know who -- we couldn't tell who it is. >>DAN HALLORAN: But you can make up a unique string and send it straight to that ccTLD and see if it's front-run. >> You can design an experiment. Anyone could. >>STEVE CROCKER: It's an easy experiment. But if you need help, we'll be happy to help you. Steve. >> STEVE MIHOLOVICH: I'm Steve Miholovich. I work with Jon Nevett at Network Solutions. Just one point of clarification. I think this goes to Eric's point. I believe the problem here is that the conclusions that SSAC made that domain names are not being front-run because they are being sold in the secondary market and also being tasted for monetization did not mean they were being front-run. Domain name front-running is simply a vehicle for domain name tasters to acquire domain names. It's one of many vehicles. So I think the conclusion that was made that they weren't being front-run because they were being monetized or they were being sold in the aftermarket is incorrect. And I think that's one of the main reasons where the problem does lie. >>STEVE CROCKER: Appreciate that. More than happy to revisit this and to probe in more deeply. Got no embarrassment about -- in fact, in my past life, I often engaged in what I call provocative research, the whole point being to stimulate a response. Couple of responses. >> MARGIE MILAM: Margie Milam with MarkMonitor. We agree with Network Solutions that we've seen instances of front-running. And I think it would be ideal for you to actually run these experiments to see how it works. We -- I'm not sure -- I'm just a lawyer. I'm not sure how it happens, but we receive enough anecdotal evidence that it is happening that makes our customers a little concerned. And I know my colleague Matt is here as well. He could probably comment on it. I don't agree, though, that if you solve the domain tasting problem, you'll get rid of front running, because I think a lot of times what's happening is they are trying to find valuable names. And even if there's no domain name tasting associated, if they can go ahead and sell it to the person who did the initial search, you know, that's certainly going to be worth more than $7, even if there's no tasting. I don't necessarily see the link. And I do think that it needs a little further, you know, review, and perhaps, you know, you can run an experiment to see how -- whether if you just search the dot com or you do dot net, org, and all the ccTLDs, there's all kinds of different ways of doing it, you might be able to get a little more information that supports at least our observation that it's actually happening. >>STEVE CROCKER: Yeah. >>ERIC BRUNNER-WILLIAMS: Thanks, Steve. There is a question of method here. The list of names which exist more or less atemporally, the list of all trademarks, the list of all patents, the list of all those exist in a vastly different time frame than any list that's being accumulated momentarily from search strings in the last several minutes of, you know -- as we progress into the future. Excuse me. The point is, the search strings themselves gathered as ephemera of the present, they may be only one of several sources of strings in order for domainers to do tasting on, but it's unlikely that they -- such an ephemeral phenomenon is a first-order of magnitude contributor to the phenomenon that we see as tasting, when we know that there are these large, atemporal lists of available names, because they've already been registered as trademarks and so forth. For each of these names, there's very large Hamming spaces around them to be explored by tasting. We know only a few hundred million domain names have been tasted thus far in this Hamming space of valuable strings around the valuable strings already. So the likelihood that search strings gathered in the almost ephemeral present are contributing to front-run -- to domain tasting seems unlikely to me. Have I made myself approximately clear? >>STEVE CROCKER: This is actually something that we worried about when we started to think about this from first principles, that there's, to put it another way, there's enough background noise that if there is front-running, it might be hard to sort that out from the other effects which are taking place anyway. I think that's your point. And another aspect of that is, even if there is some front-running and you killed it off, it wouldn't change the background level of noise. And so people might still think that they are being taken advantage of when, in fact, they're just seeing a lot of this tasting process. Have I got the essence of what you were trying to get at? >>ERIC BRUNNER-WILLIAMS: Yeah, I suppose. >>STEVE CROCKER: Okay. Jay, and then Dan, and then Dennis, and then we've got two other short things to wrap up, and we're pushing time here. >> Thanks, I think you need to look at what the psychology is behind this. Basically, someone tries to get a domain name they think is unique, an idea they think no one else has had. They look at it once, they leave it for a day or two and they look at it and somebody else has got it. Because they have an overwhelming belief that was unique, they think something naughty has happened, somebody must have done something wrong to get that. The problem is that ideas are not unique. We have so many people looking for so many domain names using exactly the same stimuli all the same time that you get a huge number of coincidences. That's all it is. >>JON NEVETT: How do you explain the customer who said they did a search and they got called -- >> Tell me the customer and tell me the domain. >> I'd like to respond to that. It has been the same group of registrars that was doing this. So it's not a mere coincidence that it was random people all over the world registering the same domain name. It was a group of registrars. >>STEVE CROCKER: It seems to me the clear takeaway is that we've been a little indistinct in our methods, and we're going to need to be more precise and ferret this out and do precise experiments to nail this Juan way or the other. Dan. >>DAN HALLORAN: Thank you, Steve. Dan Halloran, ICANN staff. Just speaking of precision, one thing I wanted to clear up, I think Jon and Steve might have gotten a misimpression from the slides, if you look at the report, I think it's clearer. That pie chart that showed pay per click advertising, that just meant, by -- they looked at the case, got a report, they looked at it, didn't find evidence of front-running and by the way, it has pay per click advertising. They weren't saying that was proof that it wasn't front-running. It's just statistical -- >>JON NEVETT: They had zero percent under DNFR and then 38% under tasting. And that's the inaccuracy that we were pointing out, Dan. >>DAN HALLORAN: But it's with the slides. They didn't say there's pay per click advertising or tasting, therefore there was no DNFR. >>JON NEVETT: When they say zero percent for DNFR they do exactly say what you just said. >>DAN HALLORAN: But they weren't saying the fact that it was tasted was proof there was DNFR. >>JON NEVETT: If you're dividing a chart and saying zero, zero DNFR and saying 38% tasting, that's the -- obviously, you make the cognitive leap that's what they're saying. >> (inaudible). >> All right, we'll -- >>STEVE CROCKER: We'll have to sort this out later. >> But they weren't saying that because it was DNFR, it was not -- because it was tasting, it was not DNFR. They did not find that. >>STEVE CROCKER: I'll have to agree, at the very least, there's presentation issues, if not more serious. You want to say something quickly. >>THOMAS NARTEN: Hello, hello. Is this on? >> No. >>THOMAS NARTEN: Microphone. >>STEVE CROCKER: Talk loudly. >>THOMAS NARTEN: The -- simple question I had. Just to clarify, because there's been confusion based on what's being said -- >> Hello. >>THOMAS NARTEN: Just to clarify, my recollection is that the SSAC report does not conclude front running is not taking place. It concludes that it has no evidence that it's taking place. >>STEVE CROCKER: Right. >>THOMAS NARTEN: Is that correct? >>STEVE CROCKER: Correct. >>THOMAS NARTEN: And there's been a little bit of back and forth about that. I think we need to be clear about that. >>STEVE CROCKER: I can tell you, we're going to have to go revisit this. Let me move quickly over to -- >>THOMAS NARTEN: And I'd also encourage SSAC to consider doing some more detailed experimentation. >>STEVE CROCKER: Yes. Yes. >>DENNIS JENNINGS: Dennis Jennings again. As you know, I'm a simple soul, and I'd like to inquire about your customer service. Do I understand that you base this on I.P. address? So that you recognize when I make an inquiry that this comes -- how does it work? >>JON NEVETT: I'd like to get there, where you're going. But the way it works right now is, essentially, if you do a search on our Web site -- remember, this is our storefront. So you're choosing to come to our storefront. We've got a couple of calls when we first rolled this out that said, I like your functionality, you have a great Web site, I like using it, but then I wanted to go buy it somewhere else. I want to go buy it at Go Daddy. So, you know, there are consumers that may have some concerns with that because they used our service and then bought somewhere else. Our customers, however, were happy with it. So, essentially, we will, like I said, reserve the name, and if you come back in the four-day period, you can purchase the name. >>DENNIS JENNINGS: How do you identify me when I come back? >>JON NEVETT: We don't. Again, it would have to be a huge coincidence at this point -- >>DENNIS JENNINGS: If you don't identify me, how do I get the name that I looked at two days ago? >>JON NEVETT: Because you would know what name you searched and you would be the only one who knew to come back and search for the same name. >>DENNIS JENNINGS: But it's not there. >>JON NEVETT: No, it's available at our Web site. >>THOMAS NARTEN: It's available to anyone who goes to their Web site. >>DENNIS JENNINGS: Anyone. Okay. >>JON NEVETT: Again, if you look at the data, it's the people who say (inaudible). >>DENNIS JENNINGS: Now I'm clear. It's available to anybody who comes exclusively to NSI. >>JON NEVETT: Yes. >>DENNIS JENNINGS: So you reserve it for your customers. >>JON NEVETT: Yes. And then our data shows, again, that over 90% it's the same I.P. address purchasing the name that search on the name, and the other 10% or some subset of that, we believe is in a different -- >>DENNIS JENNINGS: Okay. At least I'm clear. I don't like it, but I'm clear. >>JON NEVETT: Thanks, Dennis. >>STEVE CROCKER: All right, Jay. I really need to get this off. >> JAY DALEY: Sorry. Just one last little thing. I didn't answer your question properly, Jon. We get regular examples of somebody being phoned up and being offered a domain name that they have just searched for that they did not think anybody knew about. And the reason we get that is because we have people who monitor Companies House, which is in the U.K., where you register companies. Every time a new company is registered, they register domain names, they look at the directors' names, they phone them up and offer them their domain name back. It took a long time to track that one down. But we found the source for it. And as Eric was saying, it's sources of good names that are from other regions that are driving this type of behavior. >>STEVE CROCKER: All right. Thank you. One thing that is very clear is that there is a certain amount of complexity to all of this. It is not a single factor. We are over time. I want to make a brief adjustment here, RAM, with apologies, I'm going to just summarily decide that we're not going to touch on -- I can see you're very disappointed. [ Laughter ] >>STEVE CROCKER: We have Patrick Jones. Are you willing to squeeze in here a few minutes? Okay. Talking about register failover and recent experiments. So come on up. Thank you very much. Appreciate it. Very helpful. No slides? >>PATRICK JONES: Is this on? Thank you, Steve. >>STEVE CROCKER: Introduce yourself. >>PATRICK JONES: I'm Patrick Jones, registry liaison manager, ICANN staff. I'm just going to take a few minutes to talk about the gTLD registry failover project and the test exercise that, internal exercise, that ICANN staff conducted two weeks ago. We put out a draft registry failover plan in November of last year. And the plan is intended to provide protection for registrants and define ICANN's role in the event of a gTLD registry failure. It's a key project of the current operational plan. And the test exercise was conducted on January 24th and 25th. The exercise was scenario-based using tabletop exercise procedures developed and used in other cyber exercises. ICANN had a consultant come in that's experienced in conducting cyber exercises. And we're finalizing an after-action report that we'll be sure to provide to SSAC and I'll provide a few slides to SSAC as well, so that you know the methodology that we used and get some more detail into the scenarios that were, you know, used in the exercise. The exercise had four objectives. Real quick, it was to validate and improve aspects of the draft plan from November, train staff for crisis response to specific failure situations, assess maturity of ICANN's technical decision-making, and, again, work towards completion of the key project that's in the operational plan. There were five scenarios that were covered. Looked at a number of things, including escalation of temporary failures at a registry, issues involving IDNs, a natural disaster, a scenario involving government or regulatory action on a gTLD, what happens when there's a DDOS attack or a terrorist attack on a gTLD registry, issues related to a backend registry operator, and overall bad acts of a registry. And those were, really, the five scenarios that were covered. Following the exercise, we've done another version of the plan that a few people have seen. We've provided to the registry constituency and a few other members, including a small group of ccTLD managers that have been working with us on the failover plan development, and I'll make sure that I circulate that new version that's dated February 5th for wider distribution. >>STEVE CROCKER: Thank you. Any questions for Patrick? Yes. >>ERIC BRUNNER-WILLIAMS: Is this on? Good. Patrick, the approach taken, forward-looking though it is, misses the opportunity for us to look at registry failures that have existed in the past. When the Asian tsunami took place on boxing day several years ago, it came to my attention that following that, medical services were not being delivered to the inhabitants -- the indigenous people of the Andaman and Nicobar Islands. I wrote to Vint Cerf, who happened to be right here at the time, here in Delhi, and Paul Twomey. And within 48 hours, through their intersession with the president of India, that embargo was lifted and medical services were delivered to the Adaman Island and Nicobar Island indigenous peoples. But that night also I took a look at the registries that were in south Asia, and I noticed that Burma was dark. So we have an example of Burma going out that we haven't ever talked about as a registry failure. Also, in September of 2001, the registry in -- for the -- for dot IQ became problematic. And I perhaps know more about the specifics than many people. But the point is, it was a registry that was caused to go dark as a consequence of actions which were forced by one nation state against another, or something along those lines. And, again, we haven't talked about what our process was, whether or not there was a failure of process for ICANN in the redelegation of the TLD to decline to send an attorney to go and talk to the (saying name) brothers, who were being held in the United States around Richardson, Texas. We haven't talked about whether our process after the registry went dark was good, bad, or indifferent or if there was anything we would do different the next time. Then, finally, we have an example of a natural disaster, like when Jamaica or Haiti, I've forgotten which, lost all of its external connectivity and because all of the name servers for that zone were located within that island, the entire zone, of course, disappeared within a few hours. So we have at least three examples that I know of where we can talk about registry failures that are specific and concrete rather than hypothetical and where we have to sort of invent the details. I'd encourage you to look at our past so that we can find out what a reasonable question is to ask about the future. Thank you. >>PATRICK JONES: We specifically looked at examples in the CC space in developing the registry failover plan that we have now. But definitely happy to look at other examples. I think that those examples are covered in the latest version, or at least in the development of the plan, and continue to look at those examples. >>STEVE CROCKER: Thank you. Any other questions? Good. Patrick, again, let me thank you very much for bringing that. You have some material that you -- do you have any material on slides or report? Will you send them to me, and we'll include them. We'll package up all of the presentations from this session, including the one that ram didn't give on IDNs, and we'll make those available and post those. Thank you all, thank you all who are here for hanging in the extra time. Much appreciated. And we'll see you next time. Thanks. [ Applause ]