ICANN participation

In the wake of the September 11 terrorist attacks, ICANN is making a sustained effort to devote energy and resources to security matters relating to the Internet's naming and address allocation systems.� This document provides background on that effort, summarizes the assessments made at ICANN's recent meeting on DNS security, and details the next steps to be taken by ICANN and a range of its constituent organizations.

(Note: This document is intended as a general overview; in some areas, we have simplified complexities
to make it readable for a general, non-technical audience.� It does not necessarily reflect the opinions of the individual speakers and panelists who took part in the November 2001 ICANN meeting.� Suggestions for improvement are actively invited!)

Background on ICANN, the DNS, and DNS security

ICANN is the global non-profit organization responsible for coordinating the Internet's core systems of unique identifiers, most notably the Domain Name System (DNS).� The DNS is a distributed online database service that translates easy-to-remember domain names to numerical Internet protocol (IP) addresses (for example, the DNS will translate www.icann.org to 192.0.34.65).

The DNS is organized hierarchically.� ICANN is responsible for designating and coordinating the top-level domain name database operators ("registries").� The top-level domain (TLD) registries provide authoritative, publicly-accessible online database services for their respective top-level domain name (i.e. .de, .net, .info).� In turn, registrants – those who have registered second- or third-level domain names (for example:� icann.org or buckingham-palace.co.uk) – are responsible for DNS services relating to their own domains.� In addition,
some TLD registries do not provide registration services directly to registrants, but rather utilize networks of authorized specialist companies ("registrars"), which compete for registrant customers, authorize changes to the online registry database, and handle payments.

Within this framework of distributed responsibility, ICANN's role is primarily to set global policies for the TLD and IP address registries to assure the stability and integrity of the Internet's naming and address allocation systems.� In addition, for the non-country-specific top-level domain registries (.com, .net, .org, .biz, .info, .name, etc.), ICANN acts as the neutral accrediting body for the competitive registrars, and monitors their compliance with their accreditation agreements and published DNS standards.� ICANN also directly provides a range of services, such as the management of the root DNS zone file – the authoritative list of the top-level domain registries and the master name servers for each – that is made publicly available through a system of thirteen root name servers.� Many of these services are commonly known as the "IANA functions" – prior to ICANN's
creation in 1998, they had been performed by the Internet Assigned Numbers Authority (IANA).

Thus, ICANN is not responsible for the general security of the Internet, nor does it carry operational responsibilities throughout each level of the DNS.� Neither is ICANN directly responsible for technical protocols – these are defined by the protocol organizations that together make up ICANN�s Protocol Support Organization, including the Internet Engineering Task Force.� ICANN, however, is responsible for top-level coordination and global policymaking for the DNS, and as such plays a central role in assuring the integrity and stability of the Internet's naming and address allocation systems.

Overview of ICANN Meeting on DNS Security, November 2001

In view of its central coordination role and in the aftermath of the September 11 events, ICANN devoted its Annual Meeting (held in Marina del Rey in mid-November) to the security of the Internet�s domain name and address allocation systems. The meeting attracted over 1,100 members of the Internet community, including a broad cross-section of registry managers, operational staff, and DNS technical experts, along with interested participants from government,
industry, academe, the press, and the general public.

Over the course of three intensive days, the articipants conducted an in-depth examination of security requirements related to the Internet's domain name and address allocation systems, the extent to which these requirements are currently being met, and what individual, organizational, and collective actions are needed to create a security environment for the domain name and address allocation systems that assures their continued operation under emergency conditions.

More specifically, the meeting agenda was to:

(a) improve the knowledge base and heighten awareness about DNS security by ICANN constituents and the broader public,

(b) develop and adopt suggestions for security improvements by all DNS service providers, including registries, registrars, and name server
operators,

(c) develop recommendations to the ICANN Board for any near-term actions by ICANN that may be advisable, and

(d) launch continuing efforts to assess and improve security and readiness across the defined scope of ICANN's activities and communities.

The program was intended to strike a balance between the managerial and the technical aspects of DNS security, and also to stay within the scope of ICANN's responsibilities for the stability and integrity of the domain name and address allocation systems.

The program featured plenary speakers, topic-specific panels, parallel sessions focusing on management and operational/technical considerations, cross-community breakout groups, and constituency-specific meetings. At the end of the program, representatives of various ICANN constituent groups made reports to the community, including lists of specific future action items:

• DNS root name server operators
• Regional Internet registries (IP addresses and Autonomous System numbers)
• Generic top-level domain (TLD) registries
• Generic TLD registrars
• Country-code TLD registries
• Governmental Advisory Committee
• ICANN's Domain Name Supporting Organization and its constituencies

The full multimedia archives of the meeting are available online at:

<http://cyber.law.harvard.edu/icann/mdr2001/archive>

General Themes

The welcoming keynote was delivered by Senior Vice Minister Kosaka of Japan�s Ministry for Public Management, Home Affairs, Posts, and Telecommunications.� Senior Vice Minister Kosaka set the tone for the meeting by emphasizing the vital role played by the Internet in general – and the naming and addressing systems in particular – for the world�s economies and communications.� He emphasized:� �The Internet does not run on root name servers alone. ensuring the safety and stability of the Internet depends on every member of the Internet community, business, individuals, and governments, all fulfilling their respective duties on the global, regional, and national levels.�

The lead-off technical keynote address was given by Steve Bellovin, a distinguished Internet security expert and Fellow at AT&T Labs.� Setting the tone for the discussions to follow, Bellovin stated that "ICANN cannot solve 'the' whole Internet security problem – and it shouldn't try to.� It can – and should – promote protection of the name and number services upon which the Internet relies."� Bellovin identified the three key areas of responsibility for ICANN:� IP address allocation;� domain name system management;� and DNS root name server management.

With regard to IP address allocation, Bellovin observed that there remains a significant amount of inaccurate data regarding assignments.� Secure routing requires accurate data about the entities to which addresses have been assigned.� The problem of bad data is particularly notable in older assignments.� Here, ICANN must work with the regional Internet registries and ISPs, who are responsible for the quality of that data.

With regard to the DNS root name servers, Bellovin identified numerous issues:� host security;� availability;� routing;� and the lack of diverse software implementations.� Because of the highly distributed nature of the DNS system (i.e., ISPs control routing
across their networks, and the root name server operators determine their own host software), ICANN must coordinate cooperation and negotiate improvements among a wide range of entities.

With regard to the DNS itself, Bellovin emphasized that its complexity, observing that "bad guys don't go through security, they go around it."� Accordingly, the total system must be secured, including name servers, resolvers, the name and address registries (and their hosts, databases, and software), the accredited registrars (and their hosts, databases, and software), the protocols for registry-registrar and customer-registrar communications, and the various back-end protocols and software.� While ICANN cannot – and should not – dictate choice of operating system, or the definition of protocols, it can – and should – develop the requirements for them, in consultation with its community of registries, registrars, root server operators, and users.

As Bellovin's themes were developed and applied over the course of the three-day meeting, there was broad agreement that this framework makes good sense.� The various constituency groups generally responded with work plans oriented toward the drafting of best practice documents, detailing requirements for themselves, and identifying areas where future efforts are required.

In addition, there emerged a set of common themes about specific steps that ICANN should be taking in its areas of operational responsibility.� Those steps are summarized at the end of this update.

Other keynote speakers were John Tritak, Director of the U.S. Critical Infrastructure Assurance Office, who emphasized that governments can play a facilitating role, but that the private sector must take the lead in ensuring Internet security: and Bruce Schneier, Chief Technology Officer of Counterpane Internet Security, Inc.� Speaking on "Resilient Security – An Ongoing Process," Schneier stressed the security trilogy of protection, detection, and recovery. He argued that chasing 100% protection is a popular but elusive goal in the "security arms race" between the good guys and the bad guys.� Rather, a robust security strategy must optimize among the three approaches according to desired outcomes.� Practically, this approach translates into a strong emphasis
on detection and recovery.

The following sections summarize the key reports that were made at the ICANN meeting, including assessments, conclusions, and next steps.

DNS Root Name Server System

In a set of presentations to the community at the November 2001 ICANN meeting, operators of the DNS root name servers stressed that the distributed architecture of the system was designed to be robust in the face of disaster or malicious attack.� Still, some improvements to the system are planned.� This section begins with an overview of the DNS root name server system, then proceeds to a discussion of security considerations.

The resolution of domain names depends on the reliable and secure operation of the root domain name servers.� Due to its fundamental design assumption of a singly rooted hierarchical namespace, the DNS is one of the few Internet protocols that depends upon a limited number of defined infrastructural elements. The root of the Internet namespace is made available through 13 geographically distributed root name servers operated by ten independent organizations. In a worst case scenario, loss of all 13 of the root name servers would result in significant disruption to Internet operation as name to address translation (and vice versa) would no longer function.

The Root Name server System is comprised of three major components:� the DNS protocol itself, the root zone file, and the root name servers.

The DNS protocol defines a critical Internet database, which is distributed over a diverse collection of servers and used by client software for to translate an easy-to-remember segmented name into an IP address, or to locate a host that accepts mail for some mailbox address.

The root of the Internet namespace consists of a single file, the root zone file, which describes the delegations of the top level domains and the associated records necessitated by the DNS protocol to implement those delegations. Currently, this file is made available to the 12 secondary servers from the primary ("a.root-servers.net"). Change control of this file is held by the IANA with changes, typically modifications of the name servers for top level domains, being made approximately once or twice a week.� The a.root-servers.net primary root name server is operated by VeriSign Inc. pursuant to an agreement with the U.S. Government.� Once generated, the master zone file is replicated to a disaster recovery site, with backups stored at off-site locations.� Changes to the zone file are subjected to an elaborate system of review and verification, including human scrutiny of the file before it is published.

The root name servers are the machines that provide access to the root zone file for proper DNS protocol operation. Due to protocol limitations, the number of these machines is currently limited to 13, although efforts are underway to remove this limitation. A conscious effort has been made to diversify the administration of these 13 machines in several areas: diverse organizations, locations, types of operators, operating environments etc. Diversity provides one level of protection making it more difficult to attack all thirteen roots servers with a uniform approach. As of this writing, the root name servers are operated by commercial organizations, non-profit organizations, universities, research institutes, NASA, and the US military, with 3 of the 13 servers being operated outside the US, one in London (administered from the Netherlands), one in Japan, and one in Sweden.

The specification for root name server performance (a document called "RFC 2870") specifies that the root name servers have physical security �in a manner expected of data centers critical to a major enterprise.�� All of the 13 root name servers are located at professional facilities.� All have been "hardened," to some degree, with respect to environmental contingencies. This hardening includes the use of controlled physical access, protection against power grid and cooling failures with UPS protected
power with local generator capacity for extended outages, and diverse Internet connectivity in layers 1 through 3. The root servers themselves all use some variant of the Unix operating system, however both the hardware base and the vendors' Unix variants are relatively diverse: of the 13 root servers, there are 7 different hardware platforms running 8 different operating system versions from 5 different vendors.�

The bad news for root name server security is that the loss of all 13 root name servers at once would make many Internet services unreachable.� The good news, however, is that the Internet is connectionless, meaning that routing information can change rapidly, because routing information is injected into the system by the destination site.� Put another way, the DNS is a service, which does not depend on any one root name server.� If one root name server machine stops functioning, it can quickly be replaced by another, even one at another location (subject to the difficulties inherent in changing the fixed IP address pointed to by domain name resolvers).

The distributed and redundant nature of the root server system makes it less vulnerable to physical attack than, say, the public switched telephone communications system that has to protect numerous single points of failure.

Given that the name servers are widely geographically distributed, it is unlikely that all root name servers could be damaged by an environmental crisis, catastrophe, attack, or set of attacks. It has been estimated, given the amount of traffic each individual root name server receives, that root name service can function given current loads with little to no disruption when 40% of the name servers are offline, thus should a significant catastrophe or attack occur, the diversity of location will permit the root name server system to continue operation while the disrupted name servers are restored.

As stated in RFC 2870:� �The domain name system has proven to be sufficiently robust that we are confident that the, presumably temporary, loss of most of the root servers would not significantly affect operation of the Internet.�

However, as was pointed out at the meeting, the root server system could be vulnerable to DDOS (distributed denial of service) attacks and related software-based threats. Protection against DDOS attacks is problematic under current network architectures, requiring a shift in focus – as Schneier suggests – to detection and rapid recovery.

Administratively, the root name server operators have all taken steps to minimize susceptibility to disruption, and to enable rapid detection and recovery. Each root name server site keeps backup copies of zone files, thus should a disruption occur in the generation or transmission of the root zone file, the root servers can make use of backup copies until the situation is resolved. In addition, each root name server operator has contact information (in hard copy) for all other operators, thus should an issue be detected, the root name server operators can get in contact with each other (assuming the telephone system is operational). As all root name servers run recent versions of BIND, expertise in troubleshooting and resolving name server issues can be shared.

With respect to the administration of the root name server hardware itself, each root name server has redundant hardware available to it. In some cases, the hardware is in the form of a hot spare, able to be made operational with human intervention. In other
cases, the hardware is operated as a live spare able to take on the full load of serving the root zone without human intervention should there be a hardware failure. However, should disruption occur, each root name
server operator has multi-level system administration personnel and support with internally defined escalation procedures.

Beyond the software and hardware, the operators of the 13 authoritative root name servers mirror the diversity of the system itself, bringing different personalities and different organizational settings to the mix.� Nevertheless, they have developed a strong social network of trust, and make use of well-established encrypted communication channels to share information.

The root server operators have been working on a number of planned security enhancements to the root name server system, such as the use of a dedicated primary for distribution of zone file updates.

Generic Top-Level Domain (gTLD) Registries

The organizations responsible for administering the current gTLD registries – .com, .net, .org, .info, .biz, .name, .aero, .coop, and .museum – are critical actors for the stability and integrity of the DNS.� A gTLD registry maintains the authoritative database for all the names within its TLD.� In addition, gTLD registries provide a range of related services, such as the Whois database service, which provides free, online registration information about domain name registrations.� For most of the gTLD registries, interactions with registrants are actually handled by competitive registrar companies.

At the ICANN meeting in November, the gTLD Registry Constituency worked together to draft a comprehensive statement of Registry Security Best Practices.� In June 2001, the gTLD registry operators had created a Registry Failure Task Force to research and develop procedures for handling situations in which a registry fails.� Sources of registry failure could include natural disaster, malicious attack, or technical errors.� In preparation for the November 2001 ICANN meeting, the gTLD registry operators expanded the mission of the task force to include registry security and added technical representatives from each registry.� In their report to the community on 14 November, the gTLD registries reiterated their "principal commitment to the preservation and promotion of the stability of the Internet," recognizing that "one of the most important elements of this commitment is to ensure operational integrity of all registries."�

The Registry Security Best Practices document will focus on two key elements of operational integrity:� reliability and performance.� More specifically, the DNS requires that Internet users, domain name holders, and registrars have confidence not only in the reliability and performance of the gTLD name server constellations, also in the online registration systems.� Accordingly, the Registry Security Best Practices document will provide specifications for:

• Physical security
• Backup and redundancy
• Disaster recovery
• Network security
• Application security
• Availability in crisis situations

In addition, the gTLD registries agreed on the need for a confidential security audit and/or self-assessment by each registry, ideally in consultation with organizations like the CERT Coordination Center.

Country-Code Top-Level Domain (ccTLD) Registries

Together with the gTLD registries, the DNS has 244 TLD registries that correspond to countries and geographically distinct territories around the world.� These TLDs can be distinguished by their 2-letter codes (for example:� .au, .br, .cn, .de, .jp, .uk, .us, .za).� Each ccTLD is operated by a registry manager, who acts as a trustee for the local Internet community.� Some ccTLD registries are quite large, with millions of registrations (e.g., .de and .uk), others are quite small, with fewer than 1000 registrations (e.g., .mz and .om).

In general, security considerations for ccTLD registries are no different that those for gTLD registries:� as all provide top-level domain name registration and resolution services, all must ensure the integrity and reliability of their online registration and information systems, their communications with registrars and/or registrants, and their TLD name server constellations.� As has been emphasized repeatedly by ccTLD managers, registry security is only as strong as the weakest link, and requires attention to all parts and processes involved.� Thus, ccTLD registry managers were encouraged to include security considerations in all internal reviews and in the design of every new service or procedure.� The manager of the German ccTLD registry stated:� "Security is not a status;� security is a concept."

At the ICANN meeting in November 2001, a group of 37 ccTLD managers and their colleagues held three sessions focusing on DNS security:

• "Special workshop on Internet stability and security," led by Dr. Kilnam Chon of Korea
• "The DNS after 11 September 2001," led by Jaap Akkerhuis of the Netherlands
• "Shared name secondary name server for ccTLD registries," led by Sabine Dolderer of Germany

The ccTLD managers developeda list of action items and task forces focusing on the following points:

• Communications with IANA
  • Establishment of emergency procedures for updates to the IANA database due to ccTLD primary name server failure
  • Secure, reliable authentication of transactions between IANA and ccTLD registries
  • Round-the-clock means to contact someone at the IANA
• Development of a ccTLD Security Best Practices document, including references to existing standards and new, model practices developed by individual ccTLD registries
• Research, testing, and implementation of a shared ccTLD back-up/secondary server system

Regional Internet registries

Underneath the layer of domain names lie numerical Internet protocol (IP) addresses.� For example, the IP address for www.icann.org is 192.0.34.65.� Each computer on the Internet is identified by a unique numerical IP address;� the domain name system simply allows users to use easy-to-remember text names, rather than complex and lengthy numbers.� To reach its designated recipient on the Internet, a packet of data will generally start with the domain name for the destination
computer, utilize the DNS to discover its the IP address associated with the domain name (this is known as "resolving" the domain name), and then ask intermediate networks to be routed to the destination IP
address.

In order to assure that IP addresses are globally unique, they are allocated according to a hierarchical system in which Regional Internet Registries (RIRs) play the central role.� There are currently three RIRs:� ARIN (for the Americas and sub-Saharan Africa);� RIPE NCC (for Europe, the Middle East, and North Africa);� and APNIC (for the Asia/Pacific region).� Each RIR is an open, non-profit membership organization that seeks to balance two competing considerations in address allocation:� providing sufficient IP addresses to every organization that needs them, while conserving the limited IP address space so that it is not prematurely exhausted.

At the November 2001 ICANN meeting, the RIRs made a joint presentation on security considerations for RIRs.� Like the gTLD registrars, the RIRs do not constitute single points of failure for the DNS.� Rather, they provide important services (such as the reverse mapping function and a Whois database for assigned IP addresses, in addition to day-to-day IP address allocation services) that are relied upon by many Internet users.� As such, the RIRs build their operations to conform to the conventional standards for medium-level security IT organizations, for example: servers (the member database, their local DNS and Whois servers), network, facilities, databases, and the DNS reverse mapping functions.

The security-related work of the RIRs thus consists of typical considerations for online service providers.� For their Internet servers:� configuration;� authentication, authorization, and accountability;� back-up;� and recovery.� For their networks:� the
use of security zones (such as registration, engineering, and administration/finance), filters and firewalls, routers, and reverse mapping.� For their facilities:� heating, ventilation and air conditioning;� fire detection and retardation;� access control for personnel and cabling;� and power supply and backup.

The reverse mapping function is a critical online DNS service that allows IP addresses to be translated into the domain names (the reverse of the more commonly-understood name-to-address translation performed by the DNS).� The RIRs together administer this
function, which consists of a distributed online database identified by the domain name "in-addr.arpa".� The IANA is responsible for the .arpa top-level domain (in collaboration with the Internet Architecture Board), and for the in-addr.arpa second-level domain.� The RIRs are responsible
for all of the zones underneath in-addr.arpa.� Accordingly, the RIRs will be working to implement the latest secure DNS protocols and tools as they become standardized and deployable.� In that regard, the RIPE NCC has
launched a project called Deployment of Internet Security Infrastructures (DISI), which is testing the feasibility of the secure DNS protocols for the reverse mapping tree.

Generic Top-Level Domain (gTLD) Registrars

At the November 2001 ICANN meeting, the gTLD registrars focused their security discussions on back-up, recovery, and restoration.� As already explained, the gTLD registrars are accredited by ICANN and are responsible for interacting with domain name registrants in the generic top-level domains (.com, .net., .org, .info, .biz, .name, etc.), and for making changes to the authoritative TLD databases on behalf of their customers.� Over 180 organizations have been accredited as gTLD registrars;� approximately 100 of them are currently active.

While no gTLD registrar is a single point of failure for DNS in general, each is potentially a single point of failure for its own customers.� In addition, the .com, .net, and .org TLDs utilize a distributed Whois architecture, in which each registrar provides a public, online, query-based database of information about the domain name registrations for which it is the sponsoring registrar.� In the event of a registrar's failure, the online Whois information for its customers will disappear (even though the domain names themselves will continue to be resolved by the registry database).� Likewise, the entire Internet community depends on each registrar not to be compromised such that it become a conduit for corrupt data to be placed in the registry database.

Accordingly, the gTLD registrars have focused on vulnerability assessment, disaster recovery, and the requirements for possible improvements to the registry-registrar protocol (to counter vulnerabilities in the registry update process), and the distributed Whois system for the .com/.net/.org TLDs.

DNS Security Protocols

One of the panels at the November 2001 ICANN meeting addressed DNS security at the protocol level.� The panelists observed that the DNS is vulnerable to hacking precisely because it is such a highly distributed system:� every organization that depends on a domain name also depends upon the reliability of its own DNS.� Malicious attacks on local DNS servers on local networks can result in "falsified" DNS responses that divert or hijack traffic.� As a result, a falsified web page might appear to users, even though the victim's webserver is untouched by the attacker.� Even more seriously, corrupt DNS data can lead to the mis-directing or mis-delivery of e-mail.� The fact that there are so many DNS servers around the world (the number is in the millions) – and the fact that so many do not run updated DNS software, or, worse, run misconfigured software – makes them targets for malicious activity.� The widespread use of DNS data caches by ISPs and lower-level networks allows attackers to engage in cache poisoning and cache spoofing to accomplish similar results.� Likewise, the DNS depends on the accuracy of the information contained in the registry databases.� Though fewer in number, their importance makes the registry databases potential targets as well.

As a result of these and other deficiencies in the original DNS specification (which dates to the early 1980s), the Internet Engineering Task Force – the premiere standard-setting body for the Internet – has been working on a set of security-enhancing tools, known collectively as DNSSEC.� DNSSEC essentially uses public key cryptography techniques to verify the validity of DNS data.� In other words, DNSSEC is a mechanism to assure the authenticity and integrity of DNS data.� DNSSEC facilitates a chain of trust that starts with the root name servers and proceeds through the hierarchical resolution of a domain name.� At each level in the DNS, the signature of the upper level zone is verified using an associated public encryption key.

Though work has been progressing since 1996, the protocol specifications for DNSSEC have not been finalized.� A few testbed efforts are underway at research institutes and some TLD registries.� For example, the RIPE NCC's DISI project is now providing signed DNS and inverse mapping zones using the DNSSEC protocol.� Since the entire Internet will not switch to DNSSEC at once, the deployment of the protocols will have to begin with the core DNS infrastructure elements, including the root name servers and the in-addr.arpa zone.

While the DNSSEC protocols do not solve the problems of misconfiguration, outdated software, or denial of service attacks, they do prevent attacks based on the falsification of DNS data, such as cache poisoning and spoofing.� Until DNSSEC is deployable, however, organizations at every level of the DNS must pay attention to the importance of updating DNS software to the latest versions, and the danger of misconfiguration.� (As many as 12% of the DNS servers on the Internet are using "dangerously" misconfigured or outdated implementations of BIND.)� Likewise, the increasing prevalence of denial of service attacks means that organizations with DNS servers must deploy resistant software.�

In that spirit, Martin Lindner of the CERT Coordination Center provided for TLD registries a comprehensive configuration checklist, which is available in the ICANN meeting archive.

Next Steps for ICANN

A fundamental recognition by the ICANN Board is the need to establish an ongoing mechanism within ICANN to coordinate security requirements and priorities.� ICANN acts as a meeting point and forum for the various technical, operational, and managerial interests that underlie the security of the DNS and address allocation systems. A properly staffed, ongoing effort is needed to monitor and coordinate the DNS security agenda, to ensure that security threats and risks are properly identified and assessed, and to determine and communicate new requirements and priorities. The Board, therefore, decided to create an ongoing advisory committee charged with perform these functions.

The Board also recognized the need to perform a comprehensive threat/risk analysis and to establish an on-going audit capability to assess protection, detection, and recovery capabilities. These efforts should include assessments of the length of time that particular services can
acceptably be unavailable; in turn, those assessments will inform the calibration of escrow policies and backup testing procedures, and the triggering of recovery and restoration operations.� The Security Committee
will be tasked to coordinate these assessments across the community.

Near-Term Actions:� Pulling together the various threads from across the three-day ICANN meeting, the following near-term action items were identified for ICANN.� (Note:� These items were scribed by the ICANN staff, and should not be considered consensus points.� These items will be submitted to ICANN's Security Committee for its consideration and recommendation).

IANA function:� The IANA should develop emergency contact and authentication procedures to address crisis situations confronting gTLD or ccTLD registries.� This might include procedures for expedited processing of requests to change TLD nameservers in the zone file.� Also, the IANA should improve its redundancy capability.� All data on the IANA website (which includes all data of operational significance to the Internet) is mirrored and archived in Sweden with the assistance of the Royal Institute of Technology's Network Operations Centre, and Netnod AB, operators of the D-GIX. However, IANA records need to be redundantly maintained as well, and a backup operational plan needs to be developed.

Routing security:� ICANN should utilize its Address Supporting Organization (ASO) to examine the problem of out-of-date or improper IP address registration data, and to determine what policies requirements might improve the overall quality.� Ultimately, the requirement might be that for any address on the Internet, a user can find a knowledgeable operations contact who can address network problems.

gTLD registries and registrars:� Registrar-registrant communications is an area of evident vulnerability due to its dependence on human interaction, ICANN should determine whether minimum standards are needed, or whether the market is the best mechanism to correct for a lack of adequate security mechanisms and procedures.