Information Security News mailing list archives

Q&A with ICANN's security chairman, Stephen Crocker


From: InfoSec News <isn () c4i org>
Date: Tue, 26 Feb 2002 01:14:08 -0600 (CST)

http://www.computerworld.com/storyba/0,4125,NAV47_STO68514,00.html

By PATRICK THIBODEAU 
February 22, 2002

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. 



-
ISN is currently hosted by Attrition.org

To unsubscribe email majordomo () attrition org with 'unsubscribe isn' in the BODY
of the mail.


Current thread: