The Registrar Data Escrow (RDE) program is an ICANN initiative designed to enhance protection of registrants by requiring ICANN-accredited registrars to escrow critical registration data so that it can be released to ICANN upon termination of the registrar's accreditation agreement. ICANN has performed tests of the RDE system, including a "process test" and "stress test" designed to ensure effectiveness of the program's technical specifications and test the data-release procedures used by escrow agents in the event of registrar termination.

Both the "process" and "stress" tests were concluded satisfactorily, leading to some enhancements to data-release procedures, such as redundant authentication of release requests by out-of-channel means (i.e., telephone verification by an ICANN officer or attorney), and clarification of registrar on-boarding documentation.

Having concluded quality assurance testing, ICANN and its designated escrow agent have begun enrolling and on-boarding registrars in the live RDE environment. To date, nearly 750 registrars have elected to use ICANN's designated escrow agent and 8 registrars have begun making deposits in accordance with their RDE obligations.

Background

ICANN announced on 9 November 2007 that it had concluded negotiations with Iron Mountain to serve as ICANN's designated Registrar Data Escrow (RDE) agent, and had begun implementation of the RDE program to enhance registrant protection in the event of registrar failure. Through the RDE program, all ICANN-accredited registrars will regularly deposit a backup copy of their gTLD registration data with Iron Mountain or a Third Party Provider (TPP) of RDE services that has been approved by ICANN. The data held in escrow can be released to ICANN upon termination of a registrar's accreditation agreement or expiration of the accreditation agreement without renewal to facilitate transfer of registrations from the failed registrar to another registrar.

Summary of RDE Specifications

The terms, schedule, and formatting requirements for the RDE program (the "RDE specifications") were established by ICANN in consultation with a working group of registrar-volunteers and technical experts, and are published on ICANN's website at http://www.icann.org/rde/rde-specs-09nov07.pdf [PDF, 33K] .

The RDE specifications require all registrars to deposit a copy of their registration database on a weekly basis, with high-volume registrars depositing incremental updates daily. In accordance with the terms of the Registrar Accreditation Agreement (RAA), the database must include full Whois data for all gTLD registrations (including sponsored gTLDs), plus billing contact information. Registrars are encouraged to provide contact data for customers of Whois privacy and proxy services, although this would not be made mandatory until the RAA is amended. (A process is underway to amend the RAA, addressing this and other proposed enhancements to registrant protection. See http://www.icann.org/topics/raa/.)

To ensure the security and usability of RDE information, registrars are required to compile the required registration data into comma-separated value (CSV) text files, no larger than one gigabyte or one million rows each, and generate a SHA hash for each. The files must be compressed and encrypted and securely submitted to the escrow agent for verification and storage. The escrow agent will hold all deposits for at least one year and will release them to ICANN or a designated third party within five business days of a demand by ICANN for release.

RDE Program Implementation

Since the arrangement with Iron Mountain was formalized in early November, ICANN and Iron Mountain began to make operational the RDE program by notifying all registrars of their obligation to escrow data and collecting registrar elections to use either Iron Mountain or a TPP.

The notices sent to registrars indicated both the required deposit frequency and the scheduled on-board date for each registrar. On the schedule that was established, all registrars will be on board (depositing data in compliance with the RDE technical specifications) by no later than 1 July 2008. ICANN's contractual compliance team will monitor this process closely to ensure that registrars enroll and are on-boarded in accordance with their deadlines.

To date, nearly 750 of the 900 ICANN-accredited registrars have stated an election to use ICANN's designated escrow agent and two registrars have elected to utilize a TPP at their expense. Efforts continue to collect elections from the remaining registrars. Compliance enforcement measures are planned for those registrars who do not state an election by 15 February 2008.

Contemporaneous with the notification and election-collection processes, ICANN and Iron Mountain began Quality Assurance (QA) testing of the RDE system to ensure viability of the data deposit and release procedures that were developed by ICANN in consultation with registrars. This document describes the QA tests performed by ICANN as well as future initiatives that are planned.

RDE Process Testing

Although the RDE program's technical specifications published in November 2007 set out the procedures involved in depositing and releasing RDE data, the development of the QA tests was helpful to staff in identifying areas where further clarification was needed to ensure mutual understanding of expectations between ICANN and escrow agents. The process also provided an opportunity to enhance data release safeguards through discussion and implementation of best practices in the technology escrow industry.

The technical infrastructure and software used by Iron Mountain to perform registrar data escrow has been in use by Iron Mountain for registry escrow for a number of years. Accordingly, ICANN and Iron Mountain determined that this round of testing should focus on evaluating the planned deposit and release procedures and protections. To accomplish this, a "process test" and "stress test" were developed.

RDE Process Test

The first round of testing was designed to test the RDE deposit and release processes themselves and ICANN and Iron Mountain's ability to timely carry out these processes in the event of a simulated registrar failure situation.

To carry out the RDE Process Test, ICANN enrolled "IANA Registrar" (an account maintained by ICANN with registries to hold a number of reserved domain names, with registration/Whois data that looks much like that of an accredited registrar) in Iron Mountain's RDE program. Specifically, ICANN completed the on-boarding and security key-exchange procedures with Iron Mountain, prepared, compressed, and encrypted a CSV of the IANA Registrar registration data in conformance with the RDE specifications, and uploaded the data. At the other end, Iron Mountain received, decrypted, and unpacked the data, performed checksum validation in accordance with the RDE specifications, and provided verification of receipt to ICANN's RDE compliance email account. After completion of the validation process, the unencrypted data was destroyed and the original encrypted data was stored.

After ICANN was able to confirm that its deposit by IANA Registrar was successful, the release procedure was initiated. (A flowchart of the release procedure is available at http://www.icann.org/rde/rde-release-procedure-13feb08.pdf [PDF, 93K].) Simulating a typical release situation, ICANN's registrar liaison staff confirmed with legal counsel that the release was appropriate and permissible under the terms of the RDE agreement (and registrar accreditation agreement in the case of an actual registrar). An informal notice was then transmitted to Iron Mountain by email, indicating that ICANN might submit formal demand for release of IANA Registrar's data within five days. (The informal notice is intended to provide Iron Mountain with advance notice of a potential release and an opportunity for Iron Mountain to brief ICANN about the availability of RDE data for the registrar at issue.)

A week after the informal notice was transmitted to Iron Mountain, ICANN's legal counsel transmitted by fax and PGP-signed email a demand for release of IANA Registrar's escrowed data. In accordance with pre-established release procedures, Iron Mountain verified the authenticity of the release demand by confirming the release details by telephone with a designated ICANN staff member. (To help protect against spoofed or forged release requests, ICANN requires its escrow agents to place the verification call to the letter's author through the ICANN switchboard, using the telephone number published on ICANN's website.)

Before the RDE data could be released, it was again decrypted by Iron Mountain using its private key and then re-encrypted with ICANN's public key. Within two business days of ICANN's demand for release, Iron Mountain effected the release by overnight courier and sFTP.¹  Login credentials for the online release were provided to ICANN via PGP-encrypted email.²  Upon receipt of both data sets, ICANN compared the released data to the original, and confirmed that they were bit-for-bit identical.

RDE Stress Test

The second round of QA testing was designed to again test the RDE deposit and release procedures, but under conditions simulating a large registrar-depositor (i.e., a registrar managing more than one million gTLD registrations). As noted above, under the provisions of the RDE specifications, registrars are required to split CSV files to be no larger than one gigabyte or one million rows.

To complete the RDE Stress Test, ICANN manipulated the IANA Registrar data to achieve a file size of approximately 3 gigabytes. The files were then split, compressed, encrypted, and uploaded to Iron Mountain in accordance with the RDE specifications. As in the RDE Process Test, Iron Mountain decrypted, uncompressed, and performed checksum validation of the data, and then destroyed the unencrypted data and stored the original encrypted files. Similarly, as before, ICANN followed the agreed release procedures and the re-encrypted files were released to ICANN by sFTP and overnight courier within one business day of the release demand.

Although the RDE Stress Test concluded with a generally successful result, staff observed an irregularity in the process that made the result appear somewhat unreliable. Specifically, staff found that when the simulated registration data had been prepared for uploading, it compressed uncharacteristically effectively. The simulated large registrar data compressed at a rate of approximately 7,000:1. In comparison, registrars who had begun their own preparation and testing for the RDE program experienced a data compression rate of 13:1. The redundant nature of the simulated registration data appeared to have contributed to an abnormally high compression rate, so ICANN determined that the technical procedures (the file preparation, uploading, and release) involved in the RDE Stress Test should be repeated with more conservative compression rates.

In the second round of stress testing, simulated registrar data was created with greater randomization. This allowed for more realistic data compression. The uploaded files the second time were considerably larger at 349 MB each (versus 142 KB in the prior stress test), reflecting a compression rate of approximately 3:1.

By re-running the RDE Stress Test, ICANN and Iron Mountain were able to assess both the viability of the RDE specifications and the capacity of ICANN and Iron Mountain to effect a release of data for a large registrar. Through the repeated test, ICANN observed an upload rate of 700 KB/second, which correlates to a total upload time of around 20 minutes. Iron Mountain reported that the processing time for the uploaded data (i.e., the time needed to decrypt, uncompress, and verify the deposit) was under two minutes and thirty seconds. ICANN was able to download the data by sFTP in 15 minutes (950 KB/second) and complete decryption and decompression in under two minutes. Checksum verification proved the data to be identical. Given these results, the RDE Process and Stress Tests were deemed to have been satisfactorily concluded.

Identification of Issues

Through the course of ICANN's QA testing, a handful of issues were observed. Although most such issues were generally minor, some resulted in further refinement to the procedures and safeguards used by ICANN and Iron Mountain in the RDE program. Among the minor occurrences were a typographical error in the configuration of an email account, an offline fax machine, and a registrar instruction document that referred to "registries" instead of "registrars." These items were all quickly addressed and corrected during the course of the QA tests.

Additionally, through the testing process and from feedback by registrars, Iron Mountain was able to identify areas were its implementation instructions could be improved to provide greater clarity to registrars and streamline the deposit process for users of its RDE systems.

Of somewhat greater significance were "hardening" of procedural changes related to escrowed data release processes. In particular, ICANN determined that the preferred method of authentication of release requests was out-of-channel, meaning that PGP-signed emails from ICANN would not be necessary, provided that its escrow agents utilized the prescribed telephone verification steps. In conforming to industry best practices, the telephone verification procedure was augmented to require that escrow agents contact the author of the release demand letter and a second corporate fiduciary, such as a corporate officer or an attorney identified as legal counsel on ICANN's website, through the ICANN switchboard. These steps will ensure that, before acting on a release demand letter, the escrow agent can be confident the letter is both genuine and duly authorized by ICANN.

Additional Testing and Compliance Initiatives Planned

Having completed ICANN's QA testing, Iron Mountain has begun accepting escrow deposits from registrars. To date, several registrars have begun system testing and eight registrars have begun escrowing data on their designated schedule. ICANN has begun outreach to these early program participants to continually monitor performance and make procedural modifications as appropriate.

Over the coming months, ICANN will periodically conduct tests to protect registrants and ensure compliance by registrars with their RDE requirements through development of RDE deposit validation scripts and compliance auditing. ICANN anticipates completing initial auditing script development work by July 2008, and has scheduled RDE compliance auditing to take place between August and December 2008.

¹ ICANN's agreement with Iron Mountain requires Iron Mountain to effect a release of escrowed data within five business days of a formal demand by ICANN.

² Under the terms of the RDE agreement, Iron Mountain would notify the registrar upon release of its data to ICANN.