Internet security: don't panic yet says new ICANN security chief

The software that runs the Internet's addressing system is among the world's most vulnerable systems to hacker attack.

The software that runs the Internet's addressing system is among the world's most vulnerable systems to hacker attack.

In the aftermath of last year's 11 September terrorist attacks, the Internet Corporation for Assigned Names and Numbers (ICANN), the non-profit group overseeing many of the Internet's technical issues, has focused on improving security.

The group recently formed a security committee headed by Stephen Crocker, who helped develop protocols for Arpanet, the original network that became the basis for the Internet. Here he discusses some of the issues facing his committee.

ICANN is responsible for ensuring the stability of the Internet's Domain Name System (DNS). From a security perspective, what does that entail?

ICANN has a fair amount of responsibility, but there are other players as well. It's a cooperative business with other parties. It has direct relationships with the registries who control the .com, .biz., .org, [top-level domains].

One area is to work closely with those parties to set the rules and procedures to ensure operations are smooth, reliable and resistant to being penetrated. There are also the root servers, the top-level machines that point to the .com, .biz, .org and .net machines. There are 13 of these root servers around the world, and they are somewhat independent.

It's not terribly important who is in charge so much as whether or not everybody has the same, shared picture of what to do. In general, we are concerned with both the availability of the domain name servers and the preservation of the integrity of the information provided by the servers.

Virtually all the DNS servers operate from a single code base, the Internet Software Consortium's Berkeley Internet Name Domain (BIND), which was recently cited by the CERT (the authoritative security coordination centre) as its top vulnerability concern. How susceptible is BIND to attack, and what can be done about it?

It clearly is one of the areas to look at. Actually, not all of the servers are running BIND these days. Some diversity has developed, and I expect this trend will continue. That said, BIND is clearly the dominant implementation and deserves particular attention.

It is worth knowing that the two most recent versions of BIND, versions 8 and 9, are actually distinct implementations. This was done at least in part to provide some diversity. That's the good news. The bad news is that older versions of BIND are still in use.

This is not generally true at the servers for the root level or the top-level domains, but it is a problem at many of the lower-level servers. In general, the root servers and the top-level domain servers are more secure than many of the lower-level servers, partly because the code is more up to date and partly because the operators are more attentive to configuration and operation.

There has also been in preparation for several years the DNS Security Protocol, but it is not yet deployed. There are questions about how soon it can be deployed. Those are two areas that our committee will be examining.

What are your options in terms of BIND? Should there be diversification to other codes?

It is too early to know completely. Diversification has obvious benefits, and as already noted, there has actually been some diversification. There are also equally obvious benefits to having a really good solid piece of code that has been examined by a bunch of people. Paul Vixie [the primary author of the early versions of BIND up to and including Version 8] has done enormously good work over the years and continues to oversee the release of later versions of BIND.

Others at Nominum [a DNS vendor] have been involved in BIND Version 9. This is definitely an area that will command considerable attention, and I frankly don't know the answer. Paul Vixie, among many others, will be heavily involved in these discussions.

How vulnerable is the DNS?

I don't know yet. I do know if you were to take down all the root servers ... the impact would only be incremental for a couple of days before real trouble set in.

When you type in a name (www.icann.org, for instance), that has to be translated to an IP numeric address. Your machine has the address of local domain name server, usually run by your ISP. If it doesn't know what that translation is, then it passes it up the line. If it's a top-level domain that it's never seen, then it would go up to a root server. You can think of a root server as a machine whose name is simply "." [dot].

The root servers have pointers to all of the top-level domains, .com, .us, .uk. If you took out even all of the root servers, what would happen is that brand-new attempts to resolve a name would be unanswered. That would be disturbing. But there are copies of the primary information cached in many places, and the information is updated every couple of days before it's refreshed.

So if you had a disruption in connectivity, everything would still go along, but the updates would be disrupted. Meanwhile, service on the root servers would be restored. This is not something where you need a five-second response.

The root servers, then, aren't in immediate danger?

The last thing in the world I want to suggest is that the sky is about to fall in. It's quite the opposite. That's not to say that there's not some serious work to do. But the system has been running for quite a long time, and there is considerable amount of work that's been put into it. I think we are in reasonable shape. That said, this is definitely the time to take a comprehensive look at the overall system.

Read more on Antivirus, firewall and IDS products

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchCIO

SearchSecurity

SearchNetworking

SearchDataCenter

SearchDataManagement

Close