DNSsec Workshop
 Monday 11 February 2008
 ICANN Meeting
 New Delhi, India
 
 >>STEVE CROCKER:  So thank you very much.  I'm told that the president's report ran over, and I'm not sure whether or not this is the set of people who are going to be here or whether we should wait a little bit longer.
 Does anybody have a sense as to whether there is a trickle of people coming here or -- but I don't really want to hold up any longer if this is the appropriate to start.
 Good morning, Alexa.
 Do you have a sense of whether there's more people headed this way?
 [Speaker is off microphone]
 >>STEVE CROCKER:  Aha.
 [Speaker is off microphone]
 >>STEVE CROCKER:  I'm going to hold this just about a minute or so, but not long, and then we'll get going.
 Let me ask for Mr. Gupta, Mr. Sagar and Mr. Gupta to join me up here, if you would.
 Okay.  Welcome, everybody.  This is a session on DNS security on the DNSsec protocol.  My name is Steve Crocker.  I am chair of ICANN's Security and Stability Advisory Committee.
 Over the last several years, SSAC has been a very strong advocate and supporter of DNSsec, and a few years ago we realized that the amount of energy that it would take to facilitate and push DNSsec forward needed a somewhat strat structure and we started a coordinated set of working groups.  I cochair a DNSsec deployment working group and we have held a series of DNSsec workshops like this within the ICANN week almost every ICANN session for the past several years.
 And there are additionally many other DNSsec deployment working group activities scheduled, regular conference calls, a mailing list and so forth.
 In your program, there is a description of today's session.  We have made a couple of significant changes, greatly improving.  What we had said there was good.  This will be even better.
 I'm going to start with -- let me tell you what the agenda is.
 I'm going to start with a brief statement that SSAC has published regard to DNSsec and then we're privileged to have three speakers from the local environment on the plans and perspective for DNSsec in India.
 And then -- and so this will be -- I'll introduce them when we do it.
 And then we will move in the latter part of the session to a talk by Ken Silva from VeriSign who will join us.  He's currently in another session.  Staffan Hagnell from the Swedish registry on a year's worth of experience on DNSsec.  And Suzanne Woolf from Internet Systems Consortium on the DLV activity that they have been involved in.
 So with that, let me move immediately to a statement that SSAC has published.
 SSAC publishes reports and advisories and comments, and these are all posted on the ICANN Web site, and we -- in the last several days -- published a short report in which we looked at the status of DNSsec and we made a series of recommendations.  The recommendation that we directed toward ICANN itself is that the ARPA and INT top-level domains should be signed; that the systems -- the IANA systems should be expanded to accept top-level domainkeys from the top-level domain registries, and that the mechanisms on the back side should be adjusted to publish those keys out through the root operators; and that work should progress on actually getting the root signed.
 In the direction of the gTLDs and the ccTLDs and the registrars, in slightly different ways our advice was roughly the same, that it's time to begin paying attention to DNSsec, if you haven't already, and without setting any hard and fast deadlines or requirements, a request to study the deployment issues and establish time lines, where possible.
 We also recognized that there are a number of open questions which are in pretty good shape but which deserve a fresh look and description to the community about the status of where we are with respect to how complete the protocol is, what the key roll-over processes are, how to deal with Trust Anchor Repositories, testing, performance and error analysis, end user application, and general availability of software on common platforms.
 All of this is published as SSAC report 26, which is, as I said, available on the ICANN Web site and there's a URL listed at the bottom of this page.
 We will also post all these slides as fast as we can and get them up.
 So with that, let me go back and introduce the all-star team that we have from India here on what is happening and what the prospects are, and what the point of view is, the perspective, on DNSsec.
 We have Mr. Anil -- Sagar?  
 >>ANIL SAGAR:  Sagar.
 >>STEVE CROCKER:  Sagar.  Thank you.  
 -- from the Indian CERT, from CERT-In, on DNSsec:  A Vision, followed by Mr. HS Gupta from IBM, an overview of DNSsec, and then Internet security and DNSsec and implementation perspective, Mr. Shailesh Gupta.  And I apologize for not putting the "mister" there.
 >>SHAILESH GUPTA:  Shailesh.
 >>STEVE CROCKER:  Sorry?
 >>SHAILESH GUPTA:  Shailesh Gupta from Tata.
 >>STEVE CROCKER:  Shailesh.  Apologies.  
 -- from Tata Communications.  Thank you.  
 So with that, let's get started with Mr. Sagar.  And you need this.
 >>ANIL SAGAR:  Good morning.  And thank you, Mr. Steve.
 I'll be covering my session on DNSsec:  A vision.  Firstly, I will be covering what is the current state of DNS, what are the various types of acts on DNS structure, and what is DNSsec.
 Then I will also be discussing the defense mechanisms for countering DNS attacks.
 So if you see the current state of DNS, DNS is a distributed database application with a hierarchical structure offering a dependable service.
 So DNS works as a query/response mechanism.  The client or the resolver asks for a query.  It asks that -- for the IP address of www.microsoft.com.
 So it generates a query, and it gets a response.  That is the IP address of Microsoft.com.
 Now, in the current structure, this is all hierarchical structure, and root-level domains are there, then sub-domains are there.  Other host domains are there.  And the response is given to the client.
 In between, some malicious users can manipulate with the response, so that is one type of attack which could happen.
 In the response mechanism, it is a result which is coming to the client and the client is trusting on the result and accessing that system where it is being redirected.
 So in case somebody is manipulating with that response, the client can go to some malicious Web site or to the server the hacker has put in as server, and he can mislead the client.
 So the major components, DNS is a client resolver, the server, nameserver, and the namespace, DNS tree.
 This is the hierarchical structure.  We are all aware of this.  These are root-level domains and then top-level domains, second-level domains, sub-domains and the post down below.
 These are some of the DNS attacks which happened in the last few years.  The early attack happened in June 1997 in which Eugene Kashpureff redirected the traffic of Internic.net to Alternic.net by caching bogus information on the Internic nameserver.  So all the clients who were accessing Internic.net were redirected to Alternic.net.  
 Then recently, we observed the denial-of-service attacks in February 2006 in which the top-level domain zones received very heavy traffic.  
 And in 2007 also, there was a distributed denial-of-service attack on 6th of February, and this attack was very heavy and it was of the volume of up to 4 GVPS.  At that time, the root-level servers were receiving the traffic of up to 4 GVPS at that time, and it lasted for about 5 hours.
 So these DNS infrastructures are attacked for denial-of-service DNS attacks and there is a manipulation attacks to redirect the users to different Web sites.
 The main objective is attacking DNS server data, whatever resource records are there in the DNS, and compromising the DNS server, so that they can do manipulation in the records.
 The potential problems of today's DNS structure is originally DNS was not designed with a security perspective.  There is no authentication between a client and a nameserver, resolver or a nameserver.
 The DNS protocol does not allow to check the validity of DNS data.  If a client or resolver is requesting for a query, whatever response he's getting, there is no validation for that data.
 DNS data can be spoofed and corrupted between master server and resolver or a forwarder.
 How we can secure the DNS.  Firstly, we can build in security mechanism into the DNS system, in the architecture itself.  Then we can incorporate TSIG transactions.  That is a channel of authentication mechanism, which provides you the authentication between hop-by-hop transaction, so this is between server-to-server communication.  And we can implement DNS security extensions or DNSsec.  This provides for an end-to-end solution, end-to-end authentication.  I will explain on DNSsec.
 DNSsec adds security to the domain name system through a query/response mechanism.  It protects against the unauthorized DNS data corruption and DNS spoofing.
 Largely it provides that if I'm calling for a record, it tells me that the response which is coming to me is from an authenticated server, authenticated nameserver.  This is the origin of authentication of DNS data.
 Then it also tells me that whether somebody has in between manipulated with that response or not.  That is data integrity but not the confidentiality.  That means if somebody has manipulated, it cannot stop it.  It can tell you that -- whether somebody has done a manipulation or not.
 Then authenticated denial of existence.  Whether the record exists or not, it provides with an authenticated response of whether that record exists or not.
 It is designed to be interoperable with non-security aware implementations.  Back in DNS or non-security environment also, it has interoperability.
 In the DNS protocol, it adds some resource records.  So firstly -- first record is KEYRR or DNSkey.  Which specifies a type of zone, zone, host, or user type of protocol, the algorithm used for signing, then SIGRR provides an RR type record, algorithm, inception and expiration date, and signer key footprint, and it gives me the delegation signer.
 And it also tells me if that record doesn't exist with that nameserver, that NSEC record server, it provides me.
 The private key is kept off-line and is used to sign the RR sets of the zone file, and the public key is published in the KEY resource record.
 The public key of a zone is signed by the parent zone private key, and the parent zone signature on the zone's public key is added to the zone file.
 DNSsec does not cover the confidentiality of DNS responses.  It does not protect against denial of source attacks.  And it does not protect against IP spoofing.  That means somebody can spoof that response, but it can tell you only whether it has been altered or not.
 And it is not about the privacy, and this is not related -- this is not the PKI.  I mean this is not related to the PKI infrastructure.  It means that C authority or like that.
 It has its own hierarchy of PKI.  This is all related to the general PKI, public key and private key infrastructure.  This is a separate infrastructure.
 Now, we'll see how it works.  A client sends a request for a domain.  Www.cnn.com to the DNS server.
 The server goes through the root nameserver, and gives a reply with a record signed by the private key of the root server.
 Then it gets the top-level domain address, and it gets the SIGRR signed by the private key of the top-level domain server, and then it goes to the second-level authority server for which the client is requesting.
 Now, after getting the reply the client has to verify whether he has got the response from the correct name server, one thing.  Second thing, he has to verify whether the response which he has got is manipulated in between or not.  For that, it verifies the domainkey of that name server with the parent server, and secondly, it verifies the record whether it has been correctly signed by the nameserver or not.
 For that, it does a validation process, and in the validation process it matches the private key signature of the RR record.  Does this match with the RR data or not?
 And at the high level, it validates for the public key validation.  Further, delegation signer.
 So if my record is www.cnn.com, so it will go one level higher.  So it will go to the dot com server and it will verify whether this is a record from the correct authoritative server or not.  This will do it by accompanying the hash of the response it has got from the reply, and the response from the top-level server.
 Then it will go to the -- till it points it gets the trust anchor, so trust anchor is a key for validating that request whether it has got correct response from the nameserver or not.  So in this mechanism, if you see the trust anchor is a root level server from which it gets the reply from the dot com server, for which the CNN.com is an authoritative server, so the client will go one step higher till it gets the validation from the trust anchor, which says that this response is authoritative from -- for that nameserver.
 So DNSsec is built on the chain of trust.  There is a root level server which has got the private key and it's signed, so down below, the nameserver, top-level server.  Below that there is a nameserver for which it is mentioning the record.  So that record key has to be verified, so in between, if somebody is manipulating with the response, it can be validated whether it has come from the genuine nameserver or not, whether this is authoritative response or not, whether that response it is getting from the nameserver, whether it is an authoritative server or not.  So it verifies till it gets the response from the trusted point, so that trust anchor then validates that this reply is a correct reply.
 After that only, the client makes sure that this reply is a correct reply from the trusted source.
 Now, these are the DNS defenses.  The protocol based acts like a DNS reconnaissance in which hackers find the information of the DNS record from the nameserver.  This we can handle by putting the architectural wheels, like putting the split-level DNS topologies.  For my internal network, I have a separate nameserver and for the external, I have put in a separate nameserver and in between I have put in a forwarder.  And I can also do the network and nameserver monitoring for any reconnaissance attack onto my nameserver.
 DNSsec provides a defense because it gives me the verification of digital signature for that resource record and I can put other defenses like server side access controls and configuration audit and verification tools.
 For the protocol based denial of service attacks, DNS cannot help because somebody is launching from denial of service attacks, so in that, it's not effective.
 In the dynamic DNS hacking, DNSsec provides me the authentication of dynamic DNS request, whether that request has come from the genuine nameserver or not.  So that validation gives me, for the validation of denial of service request.
 In the buffer overflow, these attacks, we need to put in other generic defense mechanisms like system and service hardening so that those (inaudible) are passed and the buffer overflow level doesn't get exploration of the system, monitoring of the system, stateful firewalling and implementing the split-level DNS topologies and applying those tools.
 Under the trust-based exploits, somebody's putting -- doing manipulation by this DNS spoofing so DNSsec validation can tell me whether that response which I have got is correct response or manipulated response.  If somebody's in between injecting some response into the packet, it will not be matching with the public key of that name server because whoever is manipulating that record will have the private people sign the (inaudible), if that the private key is kept separately.  If I am making any changes to my zone file, my record in that zone file, that signature is put into the DNS record.  If somebody is manipulating with that record, it will not be matching with the signature.
 And, similarly, we can protect the cache poisoning attacks.  Again, if that response is manipulating, that validation process will fail.
 In DNS hijacking, if somebody is hijacking a name server and he is putting in some records or redirecting the traffic, so that name server will not be having authentication at the high level.  There will not be a delegation record signer.  They will not be able to validate that record.
 These are the DNS test deployments at IANA.  Some of the DNS deployments, this is running for the last one year in dot ru, you can see the different domains we have implemented, Mexico, Puerto Rico, Netherlands, Bulgaria, Brazil and Malaysia also.  And VeriSign has managed that.
 Why do we feel DNSsec is important?  Is this a return of investment or return on risk?
 Directly, I'm not getting the return on investment because DNSsec deployment is giving a trust level to the clients.  If I am at client level, I am getting a response from the trusted source.  That trust is built up at the client level.  If I am going to that particular (inaudible), it is coming from a authenticated source.  So if I am accessing some financial Web site, it is going to the correct Web site.  Somebody is not in between injecting a malicious response and redirecting to some other location.
 To have the mechanisms in a trusted environment, all the responses from the client are coming from the trusted source and they are not being redirected to the malicious servers -- name servers.
 The total dependence on DNS for functioning of Internet, we need to make sure of that in various places.  This is not I just need to implement at one name server.  I need to have step-by-step implementation at the hierarchical level.  We need to build up DNS.  The next speakers will be talking more on the deployment issues.
 And we need to think how costly is the exploitation if we don't have this kind of protection?  Like, we are seeing that these days DNS servers are very easily being compromised and they are redirecting the clients to different Web sites.  So if a client is going to a general Web site, he is being redirected to some malicious Web site or the Web site of a bank or financial sector.
 If we build up DNSsec implementation, then it will give a trust level to the user community and it will reduce financial frauds and other spoofing and packet insertion and data manipulation attacks.  These are my references.  Thank you.
 [ applause ]
 >>STEVE CROCKER:  Thank you very much.  Thank you very much.  Is this live?  Yeah?
 So I would like to move on to Mr. Harry Gupta, presenting an overview of DNSsec and he informs me that although he is with IBM, he is not representing IBM for this talk.  This is work based on earlier work that he's done and his personal view, yes?
 >>HS GUPTA:  Good morning.  I'm going to present an overview on DNSsec.  Just to introduce, earlier I was working with VSNL, India's largest telecom operator.  Recently I have moved to a different role.  In my earlier role, I used to manage the ISP operations of VSNL, the country's largest ISP operator.
 Domain name system, as you know, basically, provides mappings for name to I.P. and vice versa.  Like, for any name we get the I.P. address and the mappings are also possible.  It also provides other things like mail exchanges, and even for IPv6, we can now get IPv6 to do name mapping.  It is critical for Internet operations.  There is no doubt about it, without DNS, Internet won't function.
 It is a globally distributed database, and it is organized like a free structure having the root at the top and the different top-level domains, ccTLDs and generic top-level domains.
 The problem with the present domain name system is that it is while not able to do spoofing attack as was very lucidly pointed out by earlier speaker anil.
 There is no authentication available.  The resolver -- the end user, whatever he gets, he thinks that whatever I.P. he has got is the correct I.P.  So there is no authentication or validation which is available, so end user just doesn't know whether the response which he has got is the correct one, spoofed one or is the incorrect one.
 It doesn't distinguish between valid and invalid data.
 So here it is a potential gap in the critical Internet infrastructure where there is a possibility like where a user can get an I.P. address off a site where he doesn't want to go.  So it is a serious problem in the Internet.
 Now, just to say a typical -- how that thing will happen, a user computer wants the address of a site, abc.com.  It will just check the local server and local server, if -- in case there is in between somebody else a response to that query and gives some other I.P., so what will happen, whatever the first response the end user of the end computer gets, that will be taken.  And the second response which is coming -- which is the correct response is not taken by the end user resolver.
 And if the site which he wants to go to and the I.P -- let's say the user goes to the first site and that site is exactly identical to whatever was the previous site, then there is a potential problem -- potential security flaw there.
 The DNSsec security extensions, protocols have been developed.  It is, basically, a digital signature framework.  It uses concepts of public key cryptography.  It is not public key as was pointed out earlier.  It adds data origin authentication.  That is whatever data the DNS user receives came from correct originator.  Using DNSsec framework.
 So the user -- this authentication of the data is -- the originator is the correct originator.  The data integrity, that is whatever data received is the data the originator wanted to put into the DNS so there is no forged data in that.
 Finally, it makes spoofing detectable by the end user.  So if some spoofing has been done, it can be detected by the end user.  So end user will be aware that something has happened.
 And each DNS zone signs their data with the private key.  And query for a particular record returns the requested RRSet and the signature of the requested RRSet.  Then users authenticate responses with trusted keys.  At least one public key should be configured there.
 And this key hierarchy in DNSsec is built within DNS itself.  And as mentioned earlier, it is not about -- it is not about encryption or confidentiality.  It is more about authentication.  DNSsec is about authentication.
 And it does not address attacks like DDOS attacks.  In a simplified way, the DNS query response with DNSsec results, like was shown earlier, for abc.com, here what the local server gives the I.P. address with the signature from the abc.com server.  So here there is no chance of any other server which is an attacker sort of thing to give other data because signature is very -- is there from abc.com server.
 Now it's good protocol.  It has been developed over a long period of time but still it has not been applied widely.  Very few pockets of DNSsec deployments are there, and it has yet to see wide-scale deployment in this.  
 So various hurdles which I see are it's complex in nature, so complexity of DNSsec makes its deployment difficult.
 There is an additional burden on name servers and resolvers to make them DNSsec aware.  So name server capacity may have to be increased, the same for name servers.
 And then there is an additional task of key management, record signing and managing zone updates with the root servers.  So these are the additional tasks to be carried out.
 There is a lack of knowledge about DNSsec.  And as I said, very little adoption has happened, so there is no critical mass, as such, which is available with which things will move forward.
 Another hurdle is the signing of the root zone, which is one of the issues, which is, I think, not yet resolved, like who will hold the private key of the zone and things like that.  So that is one of the hurdles.
 Then it has taken a considerable amount of time and still it has to see the wide-scale deployment.
 So what do we do in the interim because that infrastructure -- one of the critical Internet infrastructure is prone to attacks.  So in the interim, one has to increase the awareness and knowledge of DNSsec so that you will become aware that there is a way to strengthen the DNS infrastructure.
 Then maybe in certain parts of the world, some testing has happened.  As in the morning, it was mentioned that in Sweden it has already been implemented in the ccTLD.  So here in a country like India, some pilot testing of DNSsec is required with users and it should also include various hardware also because a lot of deployment of broadband is going to happen.  So whether there are any issues with hardware, like equipment (inaudible) are faced with that.  One has to study the various business and technical issues in this.
 The issues like signing of the root zone and who holds the private key of the root zone, alternative's approaches like DNSsec DLV should be looked. Definitely there is a need to move forward to make the Internet secure.  So that's what I wanted to say.  Thank you.
 >>STEVE CROCKER:  Thank you very much.
 [Applause]
 >>STEVE CROCKER:  Next, we have Mr. Shailesh Gupta.  And at the conclusion of this talk, we'll pause for questions on any of these three talks.
 >>SHAILESH GUPTA:  Yeah.  Good morning.  I am Shailesh Gupta.  I'm coming from Tata Communications.  Till now, it was a company called VSNL [inaudible].  
 Since the previous two speakers have already spoken about [inaudible] part of the DNS security, I will try to cover that from the what have the things that have already been implemented when the ISP services [inaudible] network.
 This talk is divided into two parts, one on Internet security, what are the different security implementations that are already in place, and some few examples of previous [inaudible].
 There are two slides I would like to share with you from Tata Communications.  It's India's largest business group.  It's divided into seven sectors.  3.2% of India's GDP industrial revenues is equivalent to.  38% of that revenue comes from overseas.  We are operating in 80 countries.  85 countries [inaudible] export is being done by this group.  Largest employer.  289,500 employees [inaudible] and the total revenue of 28.8 billion, with a group profit of 2.8 billion [inaudible] 2007.  We are in these seven sectors.  We are in communications.  We are in hotels.  We are in [inaudible], Tata chemicals, like [inaudible] companies.
 Coming back to that when the network security, why network is important for the VSNL network.  We are [inaudible] IP -- MPLS core is common.  We don't have separate MPLS network and separate IP network, so this makes more sense when applying security features in the network.
 We have got [inaudible] network that is [inaudible] across eight cities.  We have got 100POP networks that is across 116 cities and towns of India.  We have got an international network that is spread across 14 international pops, which is getting expanded to 50 pops in this [inaudible] these are the pops, international pops.  They are spread from U.S. east, U.S. West, then Europe is there, then Asia Pac and then within India we are having this one.  These are the pops within India.  We have [inaudible] these pops are on the [inaudible] in case of metro Internet, it's a three tier structure.  It's comprising of dual core DSRs.  Then we have got making pops that is [inaudible] then we have got micro pops that is based on [inaudible] Cisco.  [inaudible] services out there for business services.  We have got business [inaudible] for broadband services, we have broadband ring.  And that when [inaudible] we have got SMA ring.  So [inaudible] service level [inaudible] is being done at the micro pop level, while code is common for all.
 This is how it presents all across India [inaudible] north to south, east to west.  Everywhere the pop is there.
 This is [inaudible] connectivity.  We have got connectivity with all the cables [inaudible] made with [inaudible] on cable.  These are [inaudible] different connectivities are there.  We have got [inaudible] with 30-plus partners, and [inaudible] most [inaudible] teleglobe.  Now is it is called CSL international.  So that when all the bandwidth is going teleglobe [inaudible] ISP.  We have got seven gateways, three within India [inaudible] and the four [inaudible] New York, Palo Alto, Santa Clara, and London.  We have got data [inaudible] on all the cable, around 33% [inaudible] and safe.  Core network, we have got DSR, dual GSR as a tool, and the provider edge routers, we have got 7606 in case in metro Internet and 7206 in case of 100 pop MPLS network.  These are the services we are running on this network.  ILL, Internet lead line, L2 and L3 services.  Different topologies we support.  We support full mesh, hub and spoke, complex.  [inaudible] Ethernet link and [inaudible] WiMax around 600 WiMax [inaudible] working in India.  Last mile we use to support for MMDS, 3.3 [inaudible] CP routing, [inaudible] BGP.  Remote dial-up we've got [inaudible] multicast is being supported by this network.  This network is supporting for five classes of service.  IPv6 and IPv4 [inaudible] for this conference, that is IPv6 enabled that is from Tata Communications.
 We have got NNI [inaudible] with various partners all across the globe.  [inaudible] from the customers will get seamless multi-locus [inaudible] VPN connectivity.  Some part will [inaudible] VSN network, some part will be on the partners' network.
 Coming back to the security part of that network, these are the top 10 list recommended by Cisco and other vendors.  Prepare your NOC.  [inaudible] mitigation communities.  They play a very well -- I mean good role to mitigate from attacks nowadays.
 Point protection [inaudible] entry device.  Edge protection on edge routers has to be protected very well because the customers are [inaudible] getting terminated on the edge routers [inaudible] remote triggered black hole filtering is required [inaudible] data attacks.  Sinkholes are required.  Source address validation for all the customer traffic [inaudible] you need to validate -- where the traffic is coming [inaudible] traffic or not.  Control plane protection and total visibility from the data mining tools.
 [inaudible] security [inaudible] supposed to do.  They are supposed to have the security policy in place.  Then the security resources, firewall edge to be there in place, encryption tools has to be there, authentication tools, audit has to be carried out periodically.  Monitoring and response, some [inaudible] test and practice and drill has to be there [inaudible] keeping that when the tools are in place but there has to be some periodic drill also.
 Manage and improve.  It's ongoing security, then ongoing process.  It's not the one-time implementation, so one has to [inaudible] review and what were the things are required to improve upon that.  One has to consider and incorporate in that.
 These are the six phases of incident response.  Preparation, identification, classification, traceback [inaudible], reaction [inaudible] mitigation that situation and later on the postmortem attack.
 These are the important points.  The service providers should have implemented [inaudible] from the network.  Create your own computer emergency cert team.  Of course cert India is working very well, apart from the cert [inaudible] in place.  Know your PS.  May be in the form of [inaudible] they should [inaudible] Cisco they provided INOC phones to all the major ISPs by -- by using that when the INOC form.  I mean [inaudible] one AS can call -- can communicate to another AS by knowing INOC phone.  This initiative was taken by Cisco last year, after [inaudible] know [inaudible] supported [inaudible] vendors.  I mean you should have [inaudible] from the team.  And these are the few examples of the security, like security alert Cisco.com, PSIR Cisco.com [inaudible] are available on their sites.  Be prepared.  What to do, whom to contact on various incidents.
 Now, coming back to that [inaudible] in case of any DOS attack or DDOS attack, like when the -- the communities play a very good role [inaudible] Cisco guy.  Never underestimate the power of human communications as a tool to solve security problems.  Our history demonstrates that since the Morris worm, peer communication has been the most effective security tool.
 Coming back to the VSN network, its core is carrying both IP traffic as well as the MPLS traffic, so what we have implemented.  We implemented the security protection in two forms [inaudible] plane attacks and the [inaudible] I'll go through what are the mitigation techniques have already been implemented in the network.
 We have got that when the -- that when the [inaudible] access for each and every component, we are having [inaudible] roughly 2,000 networking improvements are there, starting from the high end [inaudible] to lower end 2611 kind of routers.  We have got each and every user has got that when [inaudible] account and before creating the [inaudible] account, proper approval is required.  We have got the proper policy, password policy in place.  All the users are supposed to send their password every fourth night.  Every occasion [inaudible] holidays and [inaudible] password because that is the [inaudible] major festivals, it protects [inaudible] out there.
 We have already [inaudible] and protocols like no IP finger, no services pad, no service UDP small servers, [inaudible] TCP small servers.  These already have been turned off from the core as well as from the edge routers.
 Control plane security.  Again we have got that when the interface specific features, like no IP redirects, no IP broadcast, no proxy Arp, no IP [inaudible] mitigated DDOS attacks.
 We have already put the rate limiting on ICMP.  That one [inaudible] more than 100KBPS on the traffic [inaudible] on interfaces.  Dedicated bandwidth for control traffic [inaudible] also the control traffic should flow, so 2% [inaudible] has already been done.
 One local username in case [inaudible] remotely through attacks [inaudible] then one user has been created locally with the privilege 15.
 This is the TACACS [inaudible] we have got [inaudible] then we have got SS servers, and the third level again we have got the firewall.  [inaudible] has to cross the firewall, he has to cross the SS servers 91 each and every activity which is [inaudible] and the TACACS username and password also has to be [inaudible]
 I mean, that one that we have got 2,000 plus network elements and they are being managed centralized from the Bombay NOC itself.  And the different various teams are there, apart from this [inaudible] data network who require that when access of those elements, so what we have done, we have created them in the different category of access, and [inaudible] access of access, L1 L2, L3 level.  What are the devices they are supposed to access.  And within the devices also, what are the commands they are supposed to run on those devices.  So [inaudible] level of security has been put in place.  This is the -- a snapshot of that TACACS server, it has the login name and the password.  Once you go on to that one, you can see the log.  This is the log.  [inaudible] what are the access, what are the devices that have been accessed by various groups from various IP addresses, not [inaudible] what are the commands that have been run on those devices during that period.
 So in case of any issue -- in case of any security, I mean, that when the attack -- immediately [inaudible] mitigate those attacks.
 Authentication for the protocol.  I mean for the customers.  Those who are running [inaudible] MD5 authentication is taking place.
 We have got AC L in place.  Maximum route limits has been put in place that it has been restricted to 500 until and unless there is some requirement from a specific customer that they want the full load.
 By implementing this one, we are [inaudible] in the network.
 BGP dampening [inaudible] for IPv4, not IPv6.  [inaudible] implemented, and RFC1918 addresses has not been being announced and they're being blocked at the gateway level.
 These are the L 2 security.  We have got the mega-attacks security, port level security we are having.  [inaudible] VLAN hopping [inaudible] we have got careful configuring [inaudible] user port.  V [inaudible] hijack management access [inaudible] part of example and band management we are having in our network.
 These are the interface configs [inaudible] L 2 communication [inaudible] blocking state.  10DHCP message per second has been implemented if any user wants more than that, then case-to-case [inaudible] is getting allowed.  We have access list to mitigate when the data plane security threats.  We have got access list control.  We have got black holing traffic from the [inaudible] providers.
 Coming back to DOS and DDOS attacks, how we are mitigating that one.  We have implemented ARPA in place and the [inaudible] for each and every interface.  In case of any traffic is increasing, I mean, that when the -- from the well-defined already profile, then we are getting a lot from that [inaudible] once we get that alert, immediately we define that [inaudible] black holing and the traffic is being sent to [inaudible] sinkholes.  These are the different snapshots of how we are getting the alerts from the [inaudible]
 This security, I mean, that when the [inaudible] three parts, low security, high security, and medium security, so depending on the severity level, one has to act on that.
 We have got sys log in place [inaudible] already there, and each and every activity is being logged in that one sys log.  Routine logging is being [inaudible] is being done every day [inaudible] is being done and any command is being [inaudible] sys log server [inaudible] when he has tried two or three times, that immediately that will come to the knowledge of the NOC [inaudible] who is logging the sys log server.  Then we have got the well-defined change management process, TACACS authentication and -- I would like to [inaudible] some of the DDOS attacks has happened in past in the VSN network and how we have mitigated them in those DDOS attacks.
 >>STEVE CROCKER:  Let me ask two things.  We're short on time, so to keep it short.
 >>SHAILESH GUPTA:  Yeah, I'm just coming to.
 >>STEVE CROCKER:  And the other is, I'm getting a signal that you're talking a little faster than our translators -- our transcribers can copy down, so I'm enjoying your rapid speech, but I think that it's exceeding --
 >>SHAILESH GUPTA:  Because of the time limit, I thought I --
 >>STEVE CROCKER:  Yeah.  Well, I have very mixed feelings about this, yes.
 >>SHAILESH GUPTA:  Anyway, what I will do, I'll skip some of the -- I mean, some of the slides which have already been discussed by the previous speakers.
 There are two attacks has happened [inaudible] 475 [inaudible], I mean, in past.  One was in the [inaudible] the impact with that [inaudible] CPU [inaudible] hundred percent and that when the [inaudible] 59.165 [inaudible] that was the IP address and that we came to through the ARPA [inaudible] source of attack, and again that remote [inaudible] black holing filter was created.  I mean to mitigate that DOS attack, and immediately the CPU reduced to [inaudible] 25 to 30%.  And [inaudible] the first [inaudible] black hole -- I mean [inaudible] causing that CPU [inaudible]
 Second, I mean that attack was there, again, in that one of the [inaudible] here also [inaudible] link was there.  I mean, the entire link got choked [inaudible] that is Bombay [inaudible] and the services to that particular pop was degraded, and the cause of our attack again we found from [inaudible] when this IP 59.165.154.195, which was IP, source IP from where the attack was originated.  Again, we created the remote [inaudible] and the attack was mitigated and the replacement of that [inaudible] dropped to normal.  So I mean that -- after implementing this [inaudible] 2 immediately we come to know where from the attack is there, and once you come to know that source of attack, immediately you can take mitigation activities.
 I will not cover much on the DNS security, only how we have implemented that [inaudible] I mean the security aspect we have implemented in the VSN network, since most of the [inaudible] by the two previous speakers.
 We have got a number of DNS servers in India.  Prior to that, what are the DNS best practices.  We have got redundant DNS services.  That is one of the recommendations.  If one DNS is not working, I mean, the users will be able to access.  So we have got [inaudible] total number of DNS services deployed all across India.  Some are working [inaudible] some are working [inaudible] transfer.  We are having that when the separate advertising and resolving.  And all the original [inaudible] they are spread across India.  We have got the original servers they are doing the resolving function.  We have got servers located at headquarters.  They are doing the advertising as well as resolving.
 We have got limited DNS interface [inaudible] in place.  IP pool based ACLs are there.  [inaudible] allowed for this one advertisement.
 Restricting and securing zone replication we have got that from master and slave.  I mean, that application is taking place, and [inaudible] known slaves can replicate from the master.  That security aspect has been implemented.  Dynamic update.  We have not implemented the dynamic update.  We have restricted the dynamic update.
 Cache corruption.  I mean that one we have limited the clients number from 3,000 to 5,000.  With that, the [inaudible] disable recursion.  Reoccurs we have allowed but the number of recursive queries from the clients are restricted so with this limit, we are able to mitigate the situation.  Filter traffic to nameserver.  [inaudible] we are not running any unwanted application on that one, and only port 53 is open.
 Servers with the least privileges are being run on this one, the DNS services.  We have got [inaudible] authentication is in place.
 Then we have got source address validation [inaudible] that we are validating by putting the ACL, the source [inaudible] belong to only one address.
 We have eliminated a single point of failure since we have got multiple DNS and all the customers are being done the primary and secondary so in case the one server feels that means the services will not get affected.  [inaudible] DNS servers.
 And protected against spoofing by restricting the addresses to only a few clients.  That means when the master [inaudible] able to download.
 These are the details of the servers we are having.  12 servers.  And these servers are being divided to different categories for broadband customers they're having different DNS customers.  For corporate customers, they have got different DNS servers.  For [inaudible] customers, they are having a different DNS servers.
 I would like to -- [inaudible] one of the attack on the DNS server that has happened on 15th December 2006.  It was found one of the IP address is mentioned over there [inaudible] of Japan NIC that was doing continuous [inaudible] entry and it was 1,000 [inaudible] per minute, so that when the [inaudible] in that process has increased, I mean, it -- almost that stopped responding, name D process.  So that going through the log we came to know -- I mean, this IP address of JAPNIC is creating the issue [inaudible] to 35%.
 And we have taken it up with that one there, Japanese, what was the reason, why [inaudible] hertz per minute what's coming out to be.
 After that, again [inaudible] mitigating techniques we have planned.  We have upgraded the [inaudible] [inaudible] security features in place.  We are having RNDC services.  [inaudible] we used to stop and start in case the [inaudible] was not responding but after this one the RNDC services implementation [inaudible] establish services.  On the fly [inaudible] from the [inaudible].  By [inaudible] we come to know if any [inaudible] named processes increased from that [inaudible] limit.
 These are the references that Cisco.com/security, VSN L metro Ethernet [inaudible] any questions?  And I would like to conclude with that one coat of Mr. Ratan Tata.  We must be bold in our actions.  We must always lead, we must never follow.  He's the group chairman of Tata Communications.
 >>STEVE CROCKER:  Thank you very much.
 [Applause]
 >>STEVE CROCKER:  Yes.  Thank you.
 >>SHAILESH GUPTA:  Thank you.
 >>STEVE CROCKER:  Let me ask for questions.  Let me ask one lead-off question.
 What are the plans, if any, for implementing the DNSsec protection for --
 >>SHAILESH GUPTA:  DNSsec, I'm in that one.  We have not implemented but in the process of that.  And as we discussed in the morning, that we are planning to have some workshop with the user groups with that when the other service providers and we have not implemented them in those -- that stuff.
 >>STEVE CROCKER:  Any other questions?  Good.  Can I ask for a copy of your slides?  
 Thank you very much.  Let me thank each of our speakers here and move rapidly on to the next phase.  
 Pat, are you in a position to -- I got a note from Ken that he is not coming but he says you're going to answer questions.
 >> PATRICK KANE:  Okay.
 >>STEVE CROCKER:  Are you in a position to talk in his stead?
 >> PATRICK KANE:  I can share some of the things I think he would talk about, if that's what you're asking me.
 >>STEVE CROCKER:  I am.  So if you don't mind, Staffan, let me invite Pat up here to move forward with that affect.  I just have a quick e-mail that this will be relatively contained.
 >> PATRICK KANE:  Yes, it would.
 >>STEVE CROCKER:  Let me introduce Pat Kane from VeriSign.  I was going to do a switch.
 >> Pat Kane:  What Steve is referring to is VeriSign is going to deploy a test bed that is going to focus on enabling DNSsec in the root zone.  As you are aware, VeriSign cuts the root zone today, and one of the things we want to be prepared to is to move forward with that so there's other implementations with other top-level domain operators that can take advantage of a root zone that is enabled with DNSsec today.  We intend to do that in two phases.  The first phase being that of actually signing the root zone, working with top-level domain operators who have signed zones today as well as those that have them in pilot mode to go ahead and do that.  And we expect to do that in the first quarter -- sorry, the second quarter of this year.
 The second phase of the project really takes advantage of a project that we currently have going on with IANA to where we have deployed an operational test environment for the management of records within the root zone.  We have EPP implementation in place such that IANA can come and test that soon to where we will actually be able to manage the root records directly.  It won't change the policy in the approval process but it will certainly improve the notification process to the different parties as well as to eliminate some of the manual steps.
 So the phase two would be to take advantage of that and move forward with actually developing or extending the EPP implementation to handle the management of DNSsec records.  So we expect to have that available in the third quarter of this year as well.
 That's what Ken was going to talk about but we just wanted to make sure that everybody understands that it is a test bed around DNSsec enablement in the root.  Steve?
 >> Barbara Roseman:  Pat, if I may, how do you see this test bed interacting with IANA's test bed for root signing?
 >> Patrick Kane:  I don't see them implementing together.  I see them as two different test beds.  I can't stand there right there because I can't see.  Now I can't see at all anyway.  
 I see them being -- having the same goals and objectives.  But with two different test beds, you can certainly drive out two sets of issues, questions, provide extra data for policy development as well.  While I think we'll be working together on, that the test beds themselves, I don't see them as working together except to share information that comes out of the test beds.
 Yes?
 >>OLIVIER GUILLARD:  Thank you.  Thank you very much for this presentation.  My name is Olivier Guillard.  I chair the IANA working group for the ccNSO.  We are already -- and as Barbara mentioned, there is an IANA test bed already online and we are working with IANA to test what's up.
 And I was wondering who this test bed was for?  Who would participate to -- who is it aimed to be for?  What's the public you want to address, and how the community would work with you?
 >> Patrick Kane:  There's two thing.  There is two ways that focuses.  One focus would be since we are doing the cutting of the zone file today, we have a learning process as to what it takes and what we need to do as well as drive out some of the questions that we have from a deployment standpoint in managing that root zone.
 The second would be to provide for other people that have pilots, other people that want to do other implementations, and other signs of the root zone that they can use as part of their pilots or their reference implementations.
 >>OLIVIER GUILLARD:  Okay.  There would be many questions, but my understanding is that there is an EPP connection between IANA and VeriSign to deal with the root zone management?  Would you see -- in your test bed, will it be VeriSign that will sign the root zone?
 >> Patrick Kane:  In the test bed, I see us signing the root zone.  And I apologize, Ken has the details on how all that process would happen.  It is my understanding we would be part of that signing process.  But as far as the EPP that you talk about, it currently is in an operational testing market.  IANA has the ability to come in and actually modify root zone records today from a testing standpoint.  It is not in production.  And once they go through that testing point, we will add the DNSsec capability to manage the keys that way as the phase 2 of our test bed implementation.
 >>OLIVIER GUILLARD:  Just my last question.  Do you have a pointer or a place where we can have information about these test beds, or will it be launched later?
 >> Patrick Kane:  It will be launched later.
 >>OLIVIER GUILLARD:  Thank you.
 >> Thank you, Olivier.
 >>STEVE CROCKER:  Other questions?  
 Apologize if this puts you on the spot in terms of technical details, but today -- well, there's no signing -- the root zone isn't signed today.  The portion of the process that VeriSign has is generating the root zone from the data in the database that is -- that you update from messages that come from IANA.
 >>PATRICK KANE:  That is correct.  
 And then in the signing process, these is the so-called key signing key and the zone signing key.  In the test bed you are putting together, are you generating both keys or just the zone signing key? 
 >>STEVE CROCKER:  Are you generating both keys or just the zone signing key?
 >>PATRICK KANE:  I apologize, Steve, but I don't have the answer to that question.
 >>STEVE CROCKER:  Yeah.  And I apologize because I sensed that that might be getting into a little bit too much detail but that's, of course, an interesting question that would come up.
 The technical aspects, there's no question that VeriSign knows how to do this, and I mean, learning how to put the pieces together and so forth in this particular case.  The more interesting question, of course, will be the organizational arrangements and contractual arrangements to nit all of this, the interorganizational aspects full.
 >>PATRICK KANE:  Certainly, that's one of the position that test beds do certainly is to help out drive out those policies questions, so that the policy can be developed for a production implementation of that as well.
 >>STEVE CROCKER:  Yeah.  As Olivier alluded to, there's a connection on the front side of getting the data in from the TLD operators through the IANA.  On the back side, I don't mean pushing these records out to the root server operators.
 Have you not about or talked to the root server operators about expectation about getting these new records and whether their systems will be ready for that?
 >>PATRICK KANE:  I don't believe that communication has taken place yet, Steve, but it is intended to.
 >>STEVE CROCKER:  Uh-huh.  Good.  Any other questions?  I gather all of this is sort of breaking news on your part, on VeriSign's part.
 >>PATRICK KANE:  Yes.
 >>STEVE CROCKER:  Yeah.  Thank you very much.  Appreciate the accommodation in coming -- oh, sorry.  Dennis Jennings.
 >>DENNIS JENNINGS:  Dennis Jennings, member of the ICANN board.  Now, I'm not a technical person, so when people talk about two test beds for root signing, I get thoroughly confused.  Can anybody clarify for me what the IANA test bed is and what the difference is between that and the VeriSign test bed?
 >>STEVE CROCKER:  I can offer a guess, but I think Barbara is springing forth to say something about the IANA test bed.
 >>BARBARA ROSEMAN:  The IANA test bed has been in place for almost -- well, about six months now, fully operational.  We've been doing a signing of the root where we've been figuring out the operational aspects of having both the key signing key and the zone signing key and what needs to happen to support that operationally, but also where it makes sense to divide responsibilities versus keep them all in the same group.
 We've never advertised the zone as being an authoritative zone.  It's just a signed zone.  It gets broken occasionally, as we experiment with expiring the keys and things like that.
 I actually am a little confused myself as to how the community will deal with two different versions of a signed zone, neither of which is authoritative.  And so it's -- I think there may be some things that need to be worked out here a little bit, but, you know, we'll talk about it.
 >>STEVE CROCKER:  Let me ask both of you, since -- as you pass the microphone between yourselves, if the following description would be comfortable for both of you:
 What comes to mind when I listen to the two test zones -- two test beds that you have is that it's something akin to what we call unit testing in software development, where you're testing each of your components and there remains, logically, in the future -- not that it's been discussed or planned in detail -- an integrated test which would have perhaps either one of these test beds or some new and different test bed that would address the issue.  And so this is as much as anything inward directed, to see whether from your point of view the parts are working as opposed to outward directed -- although it is outward directed some but the first and foremost purpose is to get the parts working to the satisfaction of the people who are developing it and so I liken that to unit testing in a sense.
 >>PATRICK KANE:  Yes.  Steve, I think you're right there.  But the next step as far as the Phase 2 would be akin to a string test.
 >>STEVE CROCKER:  Aha.
 >>PATRICK KANE:  Because, you know, at that point in time we would actually be integrating with IANA so they could send us EPP records that would do the management of DNSsec records, you know, from that perspective.
 >>STEVE CROCKER:  Uh-huh.
 >>PATRICK KANE:  So to extend your analogy one step further --
 >>STEVE CROCKER:  Yeah.
 >>PATRICK KANE:  -- that's where we would actually be working together.
 >>STEVE CROCKER:  And I guess the communication has now begun.
 >>PATRICK KANE:  I believe so.
 [Laughter]
 >>STEVE CROCKER:  Thank you.  Any other -- we may have gotten all that there is to get at this particular moment.  I assume that there will be more detailed information forthcoming.
 >>PATRICK KANE:  Yes.
 >>STEVE CROCKER:  Great.  Thank you very much.
 With that, let me now turn to Staffan Hagnell.  We have a major anniversary.  The DNSsec full commercial operation was February 16th of last year, so we are a few days away from that.  I assume that there will be a major celebration that's planned and you'll be home just barely in time for that.
 >>STAFFAN HAGNELL:  Yeah.
 >>STEVE CROCKER:  So with that, let me turn things over to you and let's hear the excellent Progress.
 >>STAFFAN HAGNELL:  Okay.  Thank you very much.  I'm Staffan Hagnell from dot SE and I shall talk about our experience with DNSsec.  We have been running this for one year as a commercial service but before that we are also some practical experience with DNSsec but I could add why does dot SE want to have DNSsec.  And I would say it is quite easy to motivate actually.  It is our responsibility to provide a good DNS service.  It should be available, and it should be correct.  This is our way to bring it out of correct DNS data.  It is simply our service that we are providing this way.
 In the future, I hope that this DNSsec will also bring in new possibilities for having DNS as a repository for other security information.  We are not really there yet, but that's something I really hope will happen.
 So our history is quite long now.  To just make the headlines, we had a couple of years where the standard had to be made.  Actually, we start -- we went into operation -- DNSsec operation, not a test bed, in September 2005 when we signed the dot SE zone and sent it out on to the Internet.  At that time we didn't have any users because we would like to check what would happen with the zone if we had to put back the zone or whatever.
 But everything works fine.  During 2006, we decided we could have test users bought in the dot SE zone.  And, of course, the stability was very important but we had no problem that there would be any stability problem with DNSsec in our service.
 So in 2007, we decided to make this into commercial service with special problem that comes with a commercial service.  After we had launched a commercial service, we saw that we had to make some additional automation service and we had to make some additional marketing efforts.  So that's the basic stuff for this.
 Some background, when we started this project, we had first say that, okay, who is the players?  Who should we actually deal with?  What do we have to do to get this market going.  And we said if this is the value chain, we start with the registrants and we end with the Internet user.  We can't have all of them running DNSsec at once.  It would be very nice to have ICANN/IANA running DNSsec but it won't do it, at least it would not like to do it last year.  Hopefully soon.
 We don't have DNSsec support at the applications yet.  Hopefully, we will have it in the future but we don't care about that right now.  We will have DNSsec deployed at the ISPs' resolvers.  That's a good start.  We will shall see to our registry, the dot SE registry, that we actually provide service and we should try to get DNS name service providers to start to run DNSsec.  Then we could have a slow start of this market.
 So this was really our plan.  If you just look, what is the status today, have we succeeded with this?  If you look at the different parties, we have the registrants.  If you ask do they want to have DNSsec?  Yeah, they would like to have DNSsec.  It's not a problem that they don't want to have DNSsec.  The problem is that nobody provides DNSsec to them.  And the ones that have to provide DNSsec for the registrants is really the DNS name service provider, because most registrants they don't run their own DNS name server.  So this has been a typical problem.  It is easy to argue for DNSsec, why you should have it.  When it comes to practical operation, very often we find that they can't have the service from the domain name service provider.  We have been talking to major finance institutes who see that, that, well, maybe DNSsec won't solve any of our five top priority problems right now like Trojan horses and those things.  But this is a good thing and, of course, we should have it.
 So, I mean -- well, I don't believe that this is a problem to actually sell DNSsec.  It is more a problem to provide DNSsec.  If you look at the registrars, those are the ones that actually should sell DNSsec.  It has taken us some time to convince them that they should do it?  Now I see the possibility that we actually will have some of the largest registrars going into this business and provide DNSsec as part of greater offer, whether they provide (inaudible) and everything, and different packages with DNSsec included in those packages.  I expect to see competition along with the major registrars this year to take place where they provide DNSsec and are competing with each other.
 The largest problem as I said is that so many DNS name service providers don't provide DNSsec today.  And why?  Well, the reason is the lack of tools, actually, the lack of knowledge.  Of course, it takes some time to learn this but then you must have some tools in place and it takes some time to get those tools in place.
 Whoops.
 >>STEVE CROCKER:  Whoops.
 >>STAFFAN HAGNELL:  When it comes to our serve, dot SE registry, we could notice that this DNSsec stuff is quite special because it is an additional service and we haven't had it -- an additional service before.  What the problem of having an additional service, if you haven't had it before, well, for instance, accounting, we haven't had any accounting for additional service and that has to be implemented and all of that administrative handling takes a while to get in place, actually.
 I shall come back to the automation that we think we should improve so we get more and more of the DNSsec handling organized, actually.  And we still feel that we have to be very active with the registrars and others to get this market up and running.
 The real fun stuff is that we have been so successful with the resolver operator.  They have switched on DNSsec and are actually running DNSsec validation in the resolvers, mayor ISPs in Sweden.  Major Internet user, we are not there yet.  I hope we do some activities this year but we have not done so much yet for them.
 We started with this as an additional service.  We said that this should really be the choice of the registrant, whether they would like to have DNSsec or not.  We also said to the ISPs that we should start with pretty small volumes so you can adapt your resolvers or increase your volume.  We promised them actually that we should have a really high price at the beginning.
 Now we'll lower the price and I expect that we will continue lowering our price, so this is a way to steer the market and have slow growth of the market.
 When it comes to our particular service, we have different interfaces.  We have an end user interface Web based and we have an e-mail interface for the registrars.
 The Web-based interface is our usually Web-based interface we are using for all of customers -- direct customers, I should say.  Other than doing other administrative stuff, they could administrate their DNSsec key, just point at which key you would like to be the active KSK for the domain for the moment.
 This is a good interface if you have a few domains.  If you have a lot of domains, it doesn't work, of course.  And for those who have the e-mail interface.
 In the future, we should open up an EPP interface.  We haven't opened that up yet, so we can't provide DNSsec that way.  But once we will, it will, of course, be a major interface for the registrars to update DNSsec information.
 And if you look at our internal life, yes, we had to implement our routines for our key handling and (inaudible) data.  This is the solution we are using and have been using since 2005.  We have the KSK private keys on the memory sticks.  We have special authentication, not a single person can do this themselves.  There has to be two persons in the company to do this and so on and so on.
 More simplified portion of this pictures that, okay, we have our normal system with our database.  We make an extract for the zone file.  We distribute the zone file to hidden masters and it is distributed later to the name servers for the public.
 This chain has to be -- has to be complemented with a key signing.  So we have two different machines for the key signing.  One machine that handles the keys and it's normal off line.  The KSK private key is off line and only used when we are actually making new key bundle.
 So the difference is that from the zone generation, the zone signer will take the zone and sign it send it back and then it is distributed out to our hidden masters.
 So one more thing about the background.  As I said, we have had this key management system up and running since 2005 and this has been a good solution for dot SE.  But then we have a lot of our own domains like IIS.SE and so on.
 This is actually handled by our local I.T. support.  The thing we run into is that, okay, the local I.T. support must have their tools also.  We will not let the local I.T. support run the same tool because it's not really optimized to handle 50 different domains.
 So they must have their special tools.  And then we sort of happened to get in the same situation -- the typical situation as every name holder gets.  How do I sign my zone?  I need some sort of tools.
 In spring 2007, we put some graduate students on this work and said get us some good tools and then they looked into the market at that time and found a number of different choices and decided that they should run the ZKT tool which they used and we are not used for signing our own domain.
 So now there are some more interesting tools around.  This revelation was true at that time and I guess it's changed for the moment right now.
 So if you look a little bit further, what we feel we had to do is that we had to look into the key automization.  We should look over signing the dot SE zone.  We should add new features to that.  It should be fully automatic.  Now we have to do some manual interference once a month and we would like to get rid of them so it is fully automatic.
 We have an interesting thing called RFC 5011, I will get back to that.
 So we will start this project and hopefully we will have some joint project with other ccTLDs on this stuff.
 So if you are going to the operational experience from this one year of a commercial service, we have had two problems.  If you look at the period from 2005 when you started tests, we didn't really have any problems in the beginning but now we've had two major -- one major, one minor incident I would say.
 The major one was that BIND was upgraded and BIND behaved a little bit strange.  And BIND was upgraded at the ISPs' resolvers.  On Friday evening we get some reports that a lot of customers, there were too many to ignore, could not reach the service of the municipal -- the citizen service from some towns that are running DNSsec.  And this wasn't all of the DNSsec users.  This was some of the DNSsec users.  It was quite hard to find out what is the problem.
 But what was done was that during Saturday, we deactivated DNSsec or removed the DS records for those domains.  Monday we started a test and quite fast we found out that, hey, this is a problem with BIND and the thing is that the major ISP has just upgraded to a new version of BIND.  Whether this was a bug or feature, they were discussed but things didn't work, so we were very glad that the ISP very fast had a new version of BIND that could be distributed very fast.  So the ISPs were upgraded and the DNSsec service for the cities were put back in place.
 And the reason for this was quite amazing.
 The reason was that in real life we have a lot of low entry routers out at the customers' premises, not a -- I mean, Internet is not just expensive Cisco routers these days.  There are a lot of consumer products out there you buy.
 And unfortunately, they are running very old software.  So we found that some of the low entry routers, not all of them but some, have strange handling and we look at the software and saw that, well, this software -- in that case it was actually Open Source, commercial product using Open Source software.
 And it was very old and what happened was their router sent a DNS query.  This new version of BIND, when it was answering back, it signaled -- it was signaling with authenticated data and said this is DNSsec validated data.  That could be good information to know.  But the thing was that this router hadn't asked for this authenticated data.  Saw this new flag and said, hey, this is something I don't know and it crashed.
 Amazing but a real problem because there is a lot of those routers out there.
 So as I said, the Internet software consortium was very good and put out a new version of BIND without this special feature in it and the problem went away.
 However, this is a problem in the next step when we would like to see applications actually validating DNSsec data.  Then we will have this flag back again.  So this has been the toughest problem we've had.  It's gone.  It's not nothing we see today.
 If there would be a problem, we would definitely be aware because we have signed all of our important domains, like our primary domain IS.SE.  We have a very popular service where you could measure your broadband connectivity.  We have about 1 million broadband connection message each month so we will get notice when this doesn't work anymore.
 It works but it will be a problem for those products in the future.
 The second problem we have had was when we -- when we changed the key the last time, and then I am talking about the primary, the KSK key.  We have had three keys in total and what you were supposed to do when the (inaudible) shifted from 2007 to 2008 was to get rid of the oldest key and put in the newest key.  One of our ISP didn't make this.  I mean, if you look at its pictures, it looks really easy.  You have three keys, two of them are correct, one should be thrown away.
 For some reason, they thrown away the two correct keys and kept the wrong key, which resulted in traffic and we saw the problem immediately and discussed with them so an hour later the problem was fixed.  But, anyway, the conclusion is that, yes, it would have been nice if this key rollover is also automized.  That's why this RFC 5011 could be one solution for that that we will test during this year.
 So that's the experience.  And if you look in the future, this is what we shall continue with our project.  We shall do some development, technical development and we shall do some marketing development.  When it comes to the technical development, we should have this automatic key management system -- I mean, new software for key handling.  We should try this key rollover with the resolver operators, the RFC 5011.  We shall continue testing this low entry routers and see what we could definite.  Definitely we should report faults and try to get rid of them from the market.
 This is not only interesting from DNSsec, it is interesting for every new application that has some sort of new DNS feature, like IPv6, for instance.
 And I think it's very important to also promote the use of this administrative tools for DNSsec.  We show them for our DNS operators and actually help them to get started with these tools.
 Monitoring, of course.  When it comes to marketing activities, we should get more involved with the registrars.  And as I said, I'm very glad to see that they are now actually seeing this as an interesting service to sell.  I am pretty sure that will result in fast spread.
 And, finally, after 2008, what shall we do?  Well, if you look a little bit further, I would say that when we started this, I thought there were a lot of things to do.  But now I sort of feel that I really think this vision for 2011 will get through; that, DNSsec, while, it is an extension to DNS and it is used for having correct DNS data, it is not so particular amazing.
 The reason is this is a natural part and while the spread is that you have actually made automatization, you have better tools than you have today and you have spread those tools.
 I don't think that everybody will run DNSsec in 2011, but I think that most major domains in dot SE will have DNSsec and I hopefully -- I hope to see that some application have DNSsec support in the future.
 Okay.  Thank you.
 >>STEVE CROCKER:  Thank you very much.  Are there any questions?  I have one, if nobody else has any.  Dennis?
 >>DENNIS JENNINGS:  
 One of the things I hear is that there's a lot of paranoia about signing the zone files, particularly the root, and the fear that -- is this working?
 [Speaker is off microphone] testing.  Oh.  My apologies.  And the fear that the key, the master key, would be compromised.
 Did you run into any of those fears in Sweden?  How did you deal with them?  What is the level of risk, in your opinion?
 >>STAFFAN HAGNELL:  We haven't had that problem with our master key being compromised.  I think this is not a particular problem for DNSsec.  It's a general problem with public key systems, so every system that are using public key has to be very careful about their public key.
 Just so -- whether it should be paranoia or not, you should be very careful about your private key, definitely.
 >>STEVE CROCKER:  Let me ask you -- go back over this small system router problem that you had.
 So my understanding is that there was a short period of time when signed responses were coming back even if they were not asked for.
 >>STAFFAN HAGNELL:  Yeah.
 >>STEVE CROCKER:  And that this was exercising pathways in these small routers and they were not implemented properly.
 >>STAFFAN HAGNELL:  Well, those -- this ISP -- or actually validating all of the DNS answers, whether you asked for it or not, and it will throw away faulty DNS answer that is not signed correctly.
 The thing was that it started to inform the end router, "I have done this.  This is actually DNSsec validated data.  I can tell that you this is correct data."  And that was the only difference.  It's just signed -- just signaled with this little flag telling the router, "You could trust this data."
 And they were -- the software didn't understand the flag.
 >>STEVE CROCKER:  Aha.  So it was a router problem, as opposed to the validator?
 >>STAFFAN HAGNELL:  Yeah.  I mean it was a router problem.  It was because of -- yeah.  Sure.
 >>STEVE CROCKER:  But the question that I want to ask is:  In fixing the situation so that a signed responses no longer came back when they were asked for, does that mask what will be a later problem or how much exercising of the -- of this is actually taking place?
 >>STAFFAN HAGNELL:  Yeah.  Would you like to --
 >>SUZANNE WOOLF:  I think the hard part here, I think this sort of illustrates why interoperability is hard, because it's not necessarily a bug in either the router or the name software, the validator.  It's a specific set of circumstances that hadn't been foreseen until they were encountered in the field.
 >>STAFFAN HAGNELL:  Yeah.
 >>STEVE CROCKER:  I'm not so happy with that answer.
 >>SUZANNE WOOLF:  Believe me, I'm not either.
 >>STAFFAN HAGNELL:  I mean, it will be possible to upgrade the firmware in those old routers so you get rid of this problem, but for the ordinary user, who will do that?  So the problem is, they will have to change the routers.  I mean this is very cheap stuff and if I would guess, I would say that you are changing the routers not because of -- you would like to have DNSsec but because of you would like to have a new BB L AN standard in place, for instance or some other features that your old router doesn't support.  But it's a problem because there's a lot of numbers of those out there.
 >>STEVE CROCKER:  Right, right.  Any other questions?  Yes, Ram.
 >>RAM MOHAN:  This is Ram Mohan.  First of all, congratulations on coming up on a year.  This is a really -- a lot of good examples to go from here.
 A quick question.  If I remember right, you've implemented NSEC.
 What are your thoughts about -- actually, two questions.  First, have you actually seen any zone walking, tree walking, actually happen, first question.
 The second question is:  What are your thoughts about NSEC3 given that there is not a clear migration path.  In fact, there's this -- no migration path, as far as I know, between NSEC and NSEC3.  What are your thoughts in terms of implementing NSEC3?
 >>STAFFAN HAGNELL:  Yeah.  The first question, have you seen any zone walking?  Well, I would say that we have seen a lot of strange stuff when people are accessing our DNS servers.  We see brute force attack when they try to ask for every name, just to get out the zone file.  So maybe we should say to them please use zone walking so you don't bother us so much.
 [Laughter]
 >>STAFFAN HAGNELL:  Well, I think it's important that you protect your customers' identity, so it's -- for us, we don't show so much of the WHOIS information, actually.  Not for private persons.  We just show the name.  We don't have any contact information, and that's because the local law says that we are not allowed to publish information for local -- for private persons.
 So it's that part also.  Yes, it's possible to have zone walking, theoretically and practically.  You could have the whole zone file.  We can see who is actually making the zone file.  Yes, we have seen some.  We have contacted them.  We know who they are.  We happen to know them very well.
 But we haven't seen so much zone walking, no.  It's more like a technical venture.  The real bad guys are using brute force attacks on our DNS.
 The second question, I forgot -- no, it was about NSEC3.
 Yes, I think that's very interesting, and it was not -- we did not plan for 2008 because I don't expect it to end up before late 2008, but once it ends up, we should definitely look at NSEC3.  The migration plan, I don't have it today, but we should look at it, definitely.
 >>RAM MOHAN:  Thank you.
 >>STEVE CROCKER:  Mr. Gupta.
 >> Just one query.  What is your experience about the changing of the private key?  Like?
 >>STAFFAN HAGNELL:  The experience of dealing with the private key.  We have a special routine for that.  We have a special responsible person for who is Anne Marie, who is sitting over there, so I guess you should ask her later.
 >>STEVE CROCKER:  Thank you very much.  This is -- you know, again, I think each of us expresses the same thought, a great appreciation for the leadership and for the experience that you're able to share.
 So with that, let me move on to Suzanne Woolf, from Internet Systems Consortium.
 >>SUZANNE WOOLF:  Yeah.  Good afternoon, and, yeah, I'm -- I'm from ISC.  We actually maintain bind.  We're the bind people.  But Steve actually asked me here to talk about our DLV initiative.
 You know, for those -- you know, for anyone who doesn't know, ISC is a U.S. nonprofit.  We build infrastructure software like bind and services for the Internet, including a root nameserver.
 My colleagues have already covered in very good detail why DNSsec, but just briefly to go over it, just that DNS is increasingly critical, but as originally designed there's not really any way to prove that data wasn't altered in transit.
 DNSsec retrofits authentication onto DNS data.  The important technical parameter for DNSsec is that the security data, the signatures for the data, are handed out with the data that it authenticates, so there's -- these things have to travel together, and have certain operational constraints that I'll go into.
 If we're talking about DLV, it's important to look at the operation of conventional DNSsec so I'll go over it very quickly.
 DNS resolution, just the process of getting an answer to a DNS query, follows the naming hierarchy.  Root servers hand out [inaudible] TLD services, [inaudible] with names in their zone.  At the third or fourth level, the response finally includes the data originally requested, but there's been a chain of referrals up until that point.
 DNSsec validation follows the same path.  It was designed to track the delegation hierarchy, so the child -- the signed zone maintains a trust anchor, which is the keying data, but the parent, the zone that provides the referral into the signed zone, also has to provide signature data with the referral so that a client trying to use the DNSsec data can check it for consistency.  This need to chain data together persists.
 So we have the trust anchor problem.  The important thing is that for a DNS client that wants to use DNSsec information, there needs to be an entry point into the DNS hierarchy.
 There can be -- you know, there's going to be a trust anchor per signed domain.  Any trust anchor can be used as part of the chain to validate data lower in the hierarchy, but there needs to be an unbroken string of signed referrals.
 This is only manageable if trust anchors can be aggregated somehow.
 As soon as there's more than a few of them, they need to be aggregated.  They -- nobody wants to maintain that kind of data individually.
 So as originally envisioned, this would start with a trust anchor at the root zone which would be used to validate referrals.  It was originally envisioned that more TLDs would act as dot SE has done, and that the need to maintain the chain of referrals would be managed that way.
 Those assumptions have been problematic, again for reasons that may be already familiar to many of us.  You know, I'm kind of thinking of writing the DNSsec blues because we've heard the song before.  You know, first there's kind of a chicken and egg problem.  You know, as a practitioner, as operators, the way we look at this, there's the chicken and egg problem.  Applications don't validate DNS data because nothing is signed.  While DNS operators don't sign their data because the demand isn't there because no one's checking validations.
 There's also kind of an all-or-nothing or scaling issue that the spec didn't really provide for incremental deployment.  It's not really easy to have signed zones or clusters of zones in isolation.  The implicit deployment scenario assumed that the -- the most politically, operationally, and economically risky zones would have to be signed first.
 There was not a scenario envisioned where we would have what would -- are usually called "islands of trust."  The assumption was that the referral chain would support DNSsec data.
 So in a world with no incremental deployment path, some techies got together and invented one which they called DNS lookaside validation.  It's a locally oriented policy mechanism.  It works wherever you are in the hierarchy.  It's fully compatible with the DNSsec standard and has been envisioned as an early deployment aid.  It supports the market -- it supports a market growth from 0% signed data and 0% validators that care about signed data up towards critical mass where these capabilities are commonly found through the whole referral chain for DNS resolution.  It's intended to go away when the root and the key TLDs are signed.  It's intended as leverage.
 Just briefly to go over how it works, DLV, an administrator who wants to use available DNSsec information configures a trust anchor for a DLV domain.  Whenever normal DNSsec data can't be found, the validator looks in the DLV zone.  If there's an applicable trust anchor it can be validated by normal DNSsec validation from there.
 What this provides is a way to step over a gap in the hierarchy.  If ISC dot example wants to be signed and dot example isn't, there's a way to maintain a secured chain that doesn't necessarily map the resolution chain exactly but it still allows for the security relationship to be maintained.
 The data is provided by the zone owner to the DLV -- provided by the zone owner to the DLV registry operator just as it would be provided to the parent zone for conventional DNSsec.
 So how is this incremental deployment mechanism working out?
 Well, we put the functionality in bind.  It's been there for a while.  Which means anyone who wants to use this functionality can.  Either in validators -- it's a configurable option -- or to run a registry.  The code is freely available.
 And ISC itself operates a DLV registry.
 There is no technical requirement that there be only one, but the underlying functionality is to aggregate trust anchors.
 So we hope that the functionality makes sense as soon as you know what the pieces are for DNSsec to work.
 The DLV registry accepts public keys for signed zones from verified zone owners.  The DLV registrant publishes zone keys to registry -- to the registry over a secure channel.  Validator operators can retrieve and configure the DLV trust anchor from the registry, and thereby maintain the trust referral chain into the DLV zone and aggregate those signed -- the trust anchors for those signed zones.
 So we've been doing this for a while and we have a few observations.
 First, we've gained some real operational experience with DNSsec, which is still very rare.
 We have developed tools for the secure exchange of keying information.
 We've got processes in place for verifying domain name holders.  Obviously, those are -- those are an interesting set of -- there's an interesting set of issues there that are tied very closely to scalability problems.  You know, we have a different set of problems now as we begin to deploy DNSsec in the Internet than we will with very large zones.
 We've also found that uptake has been limited so far.  We committed resources to DLV because we thought there was pent-up demand, and that not having the root and TLDs signed -- prominent TLDs signed -- was a major portion of the barrier to DNSsec deployment further down the hierarchy.  We're not sure that's true, but it may just be that islands of trust are enough for now, for early adopters.
 And the -- sort of the profile of what people are willing to do and need to do is going to change over time.
 We do think that DLV constitutes a credible incremental deployment model.  It allows for aggregation of islands of trust.  You don't have to know all of the trust anchors to all of the zones you might want to communicate with and authenticate data from.
 It also skips some of the large-scale policy issues around signing the root, and high-value TLDs.
 We remain committed to operating and growing the registry.  We -- we do remain committed to that and to providing the registry service as needed.  We think we may be ahead of our time, but if you're interested in either how it works or participating, please see me and I can give you contact data for our project manager, and we look forward to learning more about what -- about DNSsec deployment and what people want out of DNSsec.
 >>STEVE CROCKER:  Thank you very much.  How many entries are in the DLV these days?
 >>SUZANNE WOOLF:  You know, I meant to look this morning and I did not.  It's not enormous.
 >>STEVE CROCKER:  We had a conversation in a conference call a week or two weeks or somewhere -- recently, and it was in conjunction with what we were going to talk about when I -- before I revised the schedule here, which was the survey processes that are also underway.  There's two -- there's at least two surveys of signed zones that take place regularly.  One out of Germany and one out of UCLA in California, and the question -- and there's a large number of signed zones, but if we ask the question how many of those signed zones are the tops of the chain -- that is, don't have a signed parent -- we got two different estimates out of the two surveys, but they were within a factor of two of each other.
 They were, if I recall, in the 800 range on the low end and the 1500 range on the upper end.  Then we asked how many of those -- well, that isn't even precisely the right question, but how many entries are there in the DLV.  I think the answer was around 40.
 >>SUZANNE WOOLF:  That sounds about right.
 >>STEVE CROCKER:  So -- and the very detailed kind of question is:  Are all 40 of those in the survey or is there -- but let's just assume that they are.
 Then that's a factor of 20 difference between what's in the DLV and what the lower estimate is of the number of signed tops of chains there are that don't have parents.  And that's a -- so that's a factual statement.
 What does that mean, what does that imply, does that suggest something, is where a discussion might begin.
 >>SUZANNE WOOLF:  Right.  I've wondered about that.  I've sort of guessed about that.  And one of the things that will be interesting to see, if whether that's due to the fact that, you know, there -- there's a question in my mind as to how many of the signed zones are operating in environments where they need to securely -- where people -- where they need a wide variety of validators to be able to manage their zones.
 >>STEVE CROCKER:  Right.
 >>SUZANNE WOOLF:  Because the scaling problem of aggregate -- of having to aggregate keys doesn't really kick in until you want to talk to signed zones -- you know, you want authenticated data and you want authenticated data from enough zones that you don't want to hand-maintain the keying information.
 >>STEVE CROCKER:  Right.
 >>SUZANNE WOOLF:  The trust anchors.  And I personally tend to think there's a very large area between so few trust anchors out there in the wild that it's not worth the trouble of figuring out how to deal with an aggregator --
 >>STEVE CROCKER:  Right.
 >>SUZANNE WOOLF:  -- and enough that you wouldn't need an intermediate or criminal kind of measure.
 >>STEVE CROCKER:  Yeah.
 >>SUZANNE WOOLF:  Which is one of the things I'm looking forward to seeing developed.
 >>STEVE CROCKER:  For what it's worth, I think that it is on the early side, one.
 >>SUZANNE WOOLF:  Yeah.
 >>STEVE CROCKER:  And there may be other aspects of the aggregation process that are worth examining.  Longer discussion for a different time.
 >>SUZANNE WOOLF:  Absolutely.
 >>STEVE CROCKER:  Any other questions along this line?
 Well, Suzanne, thank you very much.  Appreciate this.
 >>SUZANNE WOOLF:  Uh-huh.
 >>STEVE CROCKER:  And Staffan.  And Pat, thank you.  And with that, let me bring this session to a close.  Let me thank all of you who hung in here for this extended session, and we will almost certainly have a rather vigorous session in the -- at the Paris ICANN meeting, because I have the sense that a number of balls are in the air and things are going to come together here and it's going to be -- there's going to be some interesting times.  Thank you.
 [Applause]