Untitled Document

[ISN] Q&A with ICANN's security chairman

The software that runs the Internet's addressing system that helps
make Web commerce and communication possible led the CERT Coordination
Center's list of systems that faced serious intruder problems last
year.

The Internet Software Consortium's Berkeley Internet Name Domain
(BIND) server software is key to running the Internet's Domain Name
System (DNS). Since Sept. 11, the Internet Corporation for Assigned
Names and Numbers (ICANN), the nonprofit group overseeing many of the
Internet's technical issues, has been spending more time on security
issues. It 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. In an interview,
Crocker discussed some of the issues facing his committee.

Q: ICANN is responsible for ensuring the stability of the DNS. From a
security perspective, what does that entail?

A: ICANN has a fair amount of responsibility, but there are a lot of
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, etc. [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.

Q: Virtually all the DNS servers operate from a single code base,
BIND, which was recently cited by CERT as its top vulnerability
concern. How susceptible is BIND to attack, and what can be done about
it?

A: 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.

I think it 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.

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

A: It's 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 through 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 in Redwood City, Calif.] 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.

Q: How vulnerable is the DNS?

A: 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.

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

A: 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's 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.



	*Home* *Biografia e approfondimenti* *Interviste* *Articoli* Indice corso Credits				[ISN] Q&A with ICANN's security chairman The software that runs the Internet's addressing system that helps make Web commerce and communication possible led the CERT Coordination Center's list of systems that faced serious intruder problems last year. The Internet Software Consortium's Berkeley Internet Name Domain (BIND) server software is key to running the Internet's Domain Name System (DNS). Since Sept. 11, the Internet Corporation for Assigned Names and Numbers (ICANN), the nonprofit group overseeing many of the Internet's technical issues, has been spending more time on security issues. It 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. In an interview, Crocker discussed some of the issues facing his committee. Q: ICANN is responsible for ensuring the stability of the DNS. From a security perspective, what does that entail? A: ICANN has a fair amount of responsibility, but there are a lot of 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, etc. [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. Q: Virtually all the DNS servers operate from a single code base, BIND, which was recently cited by CERT as its top vulnerability concern. How susceptible is BIND to attack, and what can be done about it? A: 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. I think it 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. Q: What are your options in terms of BIND? Should there be diversification to other codes? A: It's 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 through 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 in Redwood City, Calif.] 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. Q: How vulnerable is the DNS? A: 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. Q: The root servers, then, aren't in immediate danger? A: 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's 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.