ICANN and Iron Mountain Complete Registrar Data Escrow QA [...]

Executive Summary

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

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

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

Background

ICANN announced on9 November 2007 that it had concluded negotiations with Iron Mountain to serveas ICANN's designated Registrar Data Escrow (RDE) agent, and had begun implementationof the RDE program to enhance registrant protection in the event of registrarfailure. Through the RDE program, all ICANN-accredited registrars will regularlydeposit a backup copy of their gTLD registration data with Iron Mountain ora 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'saccreditation agreement or expiration of the accreditation agreement withoutrenewal to facilitate transfer of registrations from the failed registrar toanother registrar.

Summary of RDE Specifications

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

The RDE specifications require all registrars to deposit a copy of theirregistration database on a weekly basis, with high-volume registrars depositingincremental updates daily. In accordance with the terms of the Registrar AccreditationAgreement (RAA), the database must include full Whois data for all gTLD registrations(including sponsored gTLDs), plus billing contact information. Registrars areencouraged to provide contact data for customers of Whois privacy and proxyservices, although this would not be made mandatory until the RAA is amended.(A process is underway to amend the RAA, addressing this and other proposedenhancements to registrant protection. See https://www.icann.org/topics/raa/.)

To ensure the security and usability of RDE information, registrars are requiredto compile the required registration data into comma-separated value (CSV)text files, no larger than one gigabyte or one million rows each, and generatea SHA hash for each. The files must be compressed and encrypted and securelysubmitted to the escrow agent for verification and storage. The escrow agentwill hold all deposits for at least one year and will release them to ICANNor a designated third party within five business days of a demand by ICANNfor 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 notifyingall registrars of their obligation to escrow data and collecting registrarelections to use either Iron Mountain or a TPP.

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

To date, nearly 750 of the 900 ICANN-accredited registrars have stated anelection to use ICANN's designated escrow agent and two registrars have electedto utilize a TPP at their expense. Efforts continue to collect elections fromthe remaining registrars. Compliance enforcement measures are planned for thoseregistrars 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 systemto ensure viability of the data deposit and release procedures that were developedby ICANN in consultation with registrars. This document describes the QA testsperformed by ICANN as well as future initiatives that are planned.

RDE Process Testing

Although the RDE program's technical specifications published in November2007 set out the procedures involved in depositing and releasing RDE data,the development of the QA tests was helpful to staff in identifying areas wherefurther clarification was needed to ensure mutual understanding of expectationsbetween ICANN and escrow agents. The process also provided an opportunity toenhance data release safeguards through discussion and implementation of bestpractices in the technology escrow industry.

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

RDE Process Test

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

To carry out the RDE Process Test, ICANN enrolled "IANA Registrar" (anaccount maintained by ICANN with registries to hold a number of reserved domainnames, with registration/Whois data that looks much like that of an accreditedregistrar) in Iron Mountain's RDE program. Specifically, ICANN completed theon-boarding and security key-exchange procedures with Iron Mountain, prepared,compressed, and encrypted a CSV of the IANA Registrar registration data inconformance with the RDE specifications, and uploaded the data. At the otherend, Iron Mountain received, decrypted, and unpacked the data, performed checksumvalidation in accordance with the RDE specifications, and provided verificationof receipt to ICANN's RDE compliance email account. After completion of thevalidation process, the unencrypted data was destroyed and the original encrypteddata 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 procedureis available at https://www.icann.org/rde/rde-release-procedure-13feb08.pdf [PDF,93K].) Simulating a typical release situation, ICANN's registrar liaison staffconfirmed with legal counsel that the release was appropriate and permissibleunder the terms of the RDE agreement (and registrar accreditation agreementin the case of an actual registrar). An informal notice was then transmittedto Iron Mountain by email, indicating that ICANN might submit formal demandfor release of IANA Registrar's data within five days. (The informal noticeis intended to provide Iron Mountain with advance notice of a potential releaseand an opportunity for Iron Mountain to brief ICANN about the availabilityof RDE data for the registrar at issue.)

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

Before the RDE data could be released, it was again decrypted by Iron Mountainusing its private key and then re-encrypted with ICANN's public key. Withintwo business days of ICANN's demand for release, Iron Mountain effected therelease by overnight courier and sFTP.1  Logincredentials for the online release were provided to ICANN via PGP-encryptedemail.2  Upon receipt ofboth data sets, ICANN compared the released data to the original, and confirmedthat they were bit-for-bit identical.

RDE Stress Test

The second round of QA testing was designed to again test the RDE depositand release procedures, but under conditions simulating a large registrar-depositor(i.e., a registrar managing more than one million gTLD registrations). As notedabove, under the provisions of the RDE specifications, registrars are requiredto 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 datato achieve a file size of approximately 3 gigabytes. The files were then split,compressed, encrypted, and uploaded to Iron Mountain in accordance with theRDE specifications. As in the RDE Process Test, Iron Mountain decrypted, uncompressed,and performed checksum validation of the data, and then destroyed the unencrypteddata and stored the original encrypted files. Similarly, as before, ICANN followedthe agreed release procedures and the re-encrypted files were released to ICANNby 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 somewhatunreliable. Specifically, staff found that when the simulated registrationdata 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 forthe RDE program experienced a data compression rate of 13:1. The redundantnature of the simulated registration data appeared to have contributed to anabnormally high compression rate, so ICANN determined that the technical procedures(the file preparation, uploading, and release) involved in the RDE Stress Testshould be repeated with more conservative compression rates.

In the second round of stress testing, simulated registrar data was createdwith 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 ofapproximately 3:1.

By re-running the RDE Stress Test, ICANN and Iron Mountain were able to assessboth the viability of the RDE specifications and the capacity of ICANN andIron Mountain to effect a release of data for a large registrar. Through therepeated test, ICANN observed an upload rate of 700 KB/second, which correlatesto a total upload time of around 20 minutes. Iron Mountain reported that theprocessing 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 wasable to download the data by sFTP in 15 minutes (950 KB/second) and completedecryption and decompression in under two minutes. Checksum verification provedthe data to be identical. Given these results, the RDE Process and Stress Testswere 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 refinementto the procedures and safeguards used by ICANN and Iron Mountain in the RDEprogram. Among the minor occurrences were a typographical error in the configurationof an email account, an offline fax machine, and a registrar instruction documentthat referred to "registries" instead of "registrars." Theseitems were all quickly addressed and corrected during the course of the QAtests.

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

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

Additional Testing and Compliance Initiatives Planned

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

Over the coming months, ICANN will periodically conduct tests to protectregistrants and ensure compliance by registrars with their RDE requirementsthrough development of RDE deposit validation scripts and compliance auditing.ICANN anticipates completing initial auditing script development work by July2008, and has scheduled RDE compliance auditing to take place between Augustand December 2008.

1 ICANN's agreement with Iron Mountainrequires Iron Mountain to effect a release of escrowed data within five businessdays of a formal demand by ICANN.

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