25 Extensible Provisioning Protocol (EPP)

Prototypical answer:

1. INTRODUCTION

In compliance with ICANN requirements, while interacting with registrars SRS uses EPP protocol. The EPP protocol implementation used by SRS was developed in compliance with RFC 5730-5734.

SRS uses standardized EPP extensions: Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP) implemented in compliance with RFC 3915 and Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP) implemented in compliance with RFC 5910.

In addition to the standardized EPP protocol extensions, in gTLD .ДЕТИ two proprietary EPP protocol extensions are used, which were implemented in compliance with RFC 3735. These extensions are designated to implement the following functionalities:
- «contact» object extension is designated for storing contact objectʹs additional attributes;
- «domain» object extension is designated for storing domain objectʹs additional attributes.

A more detailed description of the non-standard extensions is given below.

The Applicant will outsource EPP functionality as a part of Full Registry Solution to an external subcontractor, namely, JSC Technical Center Internet (hereinafter referred to as Registry Service Provider or RSP). The Registry Service Provider’s (RSP) duties will encompass initial EPP implementation and ongoing maintenance in accordance with Registry Operator’s requirements.

About the Technical Center of Internet (TCI)

The Technical Center of Internet, JSC (incorporated in Russian Federation, Primary State Registration Number (OGRN): 1097746536117, Taxpayer Identification Number (INN): 7702714697) is one of the largest worldwide and the only Russian technical centers to service registry operators. A legitimate successor to Russian Institute for Public Networks, the Technical Center of Internet has a 20 year-long background and is already two years in operation in its current status. TCI provides Full Registry Solution and DNS service with DNSSEC support to 2 ccTLD registry operators, supporting a total of 4.5m plus second level domains in ccTLDs .SU, .RU (5th worldwide) and .РФ (1st worldwide IDN ccTLD). TCI serves 26 registrars, among them several ICANN-accredited ones. TCI is in possession of a number of scattered worldwide DNS nodes, the geographically distributed fully redundant state-of the-art infrastructure and highly qualified staff.

2. IMPLEMENTATION

2.1. General Principles

The EPP server’s functionality is implemented on Java SE 5.0 (JSR 176) platform.

Registrars are recommended to use the EPP RTK library for Java (see http:⁄⁄epp-rtk.sourceforge.net) as a client along with the custom module developed by Registry Service Provider wherein API for the work with the contact and domain objects extensions is implemented (See below).

The detailed description of Registry Service Provider implementation is provided in the respective sections below.

2.2. Transport Mapping

The transport mapping is implemented in full compliance with RFC 5734.

2.2.1. Transport Mapping’s compliance with RFC 5730

1) The transport mapping MUST preserve command order.
- The commands order is preserved.
2) The transport mapping MUST address the relationship between sessions and the client-server connection concept.
- Each EPP session is mapped to a single TCP connection.
3) The transport mapping MUST preserve the stateful nature of the protocol.
- The original structure of the protocol is preserved.
4) The transport mapping MUST frame data units.
- The data block format explicitly defines the number of bytes used to transfer the EPP message.
5) Basing on a protocol, such as TCP, transport mapping should ensure congestion prevention.
- Load balancing is implemented according to the guidelines and practices described in RFC2581 and RFC2914.
6) The transport mapping MUST ensure reliability.
- TCP includes functions ensuring resiliency, flow control and multiplexing, as described in Section 1.5 RFC793.
7) The transport mapping MUST explicitly allow or prohibit pipelining.
- The pipelining is possible, but is explicitly PROHIBITED.
8) Commands must be processed independently of each other.
- Commands are processed independently of each other.
9) Depending on the transport, pipelining MAY be possible in the form of sending a complete session in a well-defined ʺbatchʺ.
- The pipelining in the form of sending a complete session in one ʺbatchʺ, IS NOT PERMITTED.
10) The transport mapping MUST describe how an error in processing a command affects continued operation of the session.
- The session can be interrupted because of an internal server error, authorization error, exhaustion of the open session limit or the session lifetime.

2.2.2. TCP-based transport mapping security

EPP as-is provides only simple client authentication services using identifiers and plain text passwords. A passive attack is sufficient to recover client identifiers and passwords, allowing trivial command forgery. Protection against most other common attacks MUST be provided by other layered protocols.

When layered over TCP, the Transport Layer Security (TLS) Protocol version 1.0, as described in RFC2246 or its successors, using the latest version supported by both parties, MUST be used to provide integrity, confidentiality, and mutual strong client-server authentication.

Authentication using the TLS Handshake Protocol confirms the identity of the client and server machines. EPP uses an additional client identifier and password to identify and authenticate the clientʹs user identity to the server, supplementing the machine authentication provided by TLS. The identity described in the client certificate and the identity described in the EPP client identifier can differ, as a server can assign multiple user identities for use from any particular client machine. Acceptable certificate identities MUST be negotiated between client operators and server operators using an out-of-band mechanism. Presented certificate identities MUST match negotiated identities before EPP service is granted.

There is a risk of login credential compromise if a client does not properly identify a server before attempting to establish an EPP session. Before sending login credentials to the server, a client needs to confirm that the server certificate received in the TLS handshake is an expected certificate for the server. A client also needs to confirm that the greeting received from the server contains expected identification information.

EPP TCP servers are vulnerable to common TCP denial-of-service attacks including TCP SYN flooding. Servers SHOULD take steps to minimize the impact of a denial-of-service attack using combinations of easily implemented solutions, such as deployment of firewall technology and border router filters to restrict inbound server access to known, trusted clients. These solutions are implemented and described in the respective sections of the Application.

For more detailed security considerations on TCP and TLS usage, see Sections 8 and 9 of RFC5734.

2.3. Protocol Identification

After establishing the TCP session, the EPP server MUST return a greeting to the client.

2.4. Greeting

Example EPP server greeting is provided in the attachment Q25_EPPServerGreetingExample.

Comments on the Registry data collection policy:
- Access is granted to all the identified data («all⁄»).
- Information is collected for the purpose of domain names registration («prov⁄») and may be used for administrative and technical support of the registration system («admin⁄»).
- Consumers of the information is provided are Registry Operators and Registrars («ours⁄»), as well as users of the WHOIS service («public⁄»).
- The data storage period is limited by the need to support the DNS system.

2.5. Protocol Extensions

2.5.1. Command-Response Extension

- Extension to operate the domain objectʹs DS records is implemented in compliance with RFC 5910.
- Extension to operate the domain objectʹs grace period is implemented in compliance with RFC 3915.
- Extension to operate an extended set of attributes of the domain object (see section 7.1 of the present document).
- Extension to operate an extended set of attributes of the contact object (see section 7.2 of the present document).

2.6. Objects Identification

All Registry Service Provider’s registry objects have continuous numbering.

2.7. Session Control Commands

2.7.1. EPP «login» Command

The EPP «login» command is implemented in compliance with RFC 5730.

In reply to a successful EPP «login» command EPP server will return an EPP response of a successful authentication.

The number of failed login attempts and the idle expiration time are parameterized and defined by the security policy.

Example «login» command is provided in the attachment Q25_ExampleLoginCommand.

2.7.2. EPP «logout» Command

The EPP «logout» command is implemented in compliance with RFC 5730.

Where the server receives an EPP «logout» command, the EPP server will close the EPP session and the associated with it TCP connection, in compliance with RFC 5734.

2.8. Query Commands

2.8.1. The «check» Command

The «check» command is implemented for the objects: Domain, Host and Contact, in compliance with RFC 5730-5733.

In order to save resources and boost the EPP server’s performance the number of objects subject to verification is parameterized and may be specified explicitly. By default, the number of objects subject to verification is not limited.

2.8.2. The «info» Command

The «info» command can be is implemented for the objects Domain, Host and Contact, in compliance with RFC 5730-5733.

2.8.3. The «poll» Command

The «poll» command is implemented in compliance with RFC 5730.

2.8.4. The «transfer» Query Command

The «transfer» command can be implemented for the objects Domain and Contact in compliance with RFC5730, RFC5733.

2.9. Object Transformation Commands

2.9.1. The «create» Command

The EPP «create» command is implemented for to the objects Domain, Host and Contact, in compliance with RFC5730-5733.

2.9.2. The «renew» Command

The «renew» command is implemented for the domain object, in compliance with RFC 5731.

2.9.3. The «transfer» Command

The «transfer» command is implemented for the objects Domain and Contact, in compliance with RFC 5730, RFC 5733.

2.9.4. The «update» Command

The «update» command is implemented for the objects: Domain, Host and Contact, in compliance with RFC 5730-5733.

2.10. Result Codes

The EPP commands result codes used in the Registry Service Provider’s EPP server implementation fully comply with RFC 5730.

2.11. Internationalization

- The Registry Service Providerʹs EPP server accepts EPP commands and delivers EPP responses ONLY using in the UTF-8 encoding.
- The descriptions of the EPP commands result codes specified in RFC 5730 have been translated. That is why the Registrars can receive them in both the Russian and English languages, at the Registrarʹs discretion.
- The error descriptions and causes for denial cited in EPP responses can be delivered in the Russian and English languages, at the Registrarʹs discretion.
- All date-time values presented through EPP are represented in UTC format with the use of the extended format in compliance with W3С Recommendation REC-xmlschema-2-20041028).

2.12. Security

To implement the interaction with EPP server through the TLS protocol (see more details in Section 2.2.2. of the present document), users must use only trusted certificates issued by Registry Service Provider. The peculiarities of generation and usage of trusted certificates are as follows:
- The trusted certificates are issued individually, for each Registrar and they are unique for the cluster of EPP servers of each registry.
- The trusted certificates are issued for a limited period, determined by the registry’s security policy and terms of the contract with the Registrar.
- The individual trusted certificates are available through the Registrarʹs Web-interface.

2.13. The distinction of the Registry Service Providerʹs implementation from the standard one.

The distinctive feature of the Registry Service Providerʹs implementation lies in employment of extensions for the objects: Domain and Contact (for greater details, see Section 7 of the present document).

3. EPP PROTOCOL IMPLEMENTATION’ S COMPLIANCE WITH RFC 5730-5734

The EPP protocol implementation is compliant with RFC 5730-5734: The extensions do not modify the existing protocol structure. The extensions are described by XML-schemas tci-contact-ext-1.0.xsd и tci-domain-ext-1.0.xsd. The extensions MAY NOT be modified, for greater details, see Section 7 of the present document).

4. PERSONNEL

The following staff roles are engaged in development, initial implementation and maintenance of the EPP service:

(i) Initial implementation and maintenance:
- Applied Systems engineer (Registry Services Department., RS Support Group), 1 person;
- Database Administrator (Registry Services Department, RS Support Group), 2 persons;
- Network Engineer of NOC (Networking Department, IP-Network for RS, DNS Group), 2 persons;
- Duty operators (Monitoring Department) 4 shifts of 2 officers each;
- Duty engineers of NOC (Networking Department, IP-Network for RS, DNS Group), 2 persons;
- RS Duty Engineer (Registry Services Department, RS Support Group), 2 persons.

(ii) Development:
- Application Developer (Registry Services Department, R & D group), 1 person;
- Database Developer (Registry Services Department, R & D Group), 1 person;
- System Testing engineer (Registry Services Department, , Testing and Versioning Group), 1 person.

5. THE EPP PROTOCOL’S SCALE IN RELATION TO THE PLANNED SIZE OF THE REGISTRY

Theoretically, the number of EPP servers (Application servers) in the registry cluster is unlimited, which is why the cumulative performance (response time) of an EPP service depends only on performance (response time) of the registry’s database.

6. THE OUTLAY AND ITS CORRELATION WITH THE DESCRIPTION IN THE FINANCIAL SECTION

The costs are a combination of the hardware, software development and operational costs. No additional costs is related to the EPP environment.

7. PROPRIETARY EPP PROTOCOL EXTENSIONS

7.1. Extension for the EPP Domain Mapping

This mapping, an extension of the domain name mapping described in RFC 5731.

7.1.1. Objectʹs attributes

The extension adds new attributes to the domain object. This section describes each attribute in detail. For attributeʹs formal syntax, see Section 7.1.5, the Formal Syntax.

7.1.1.1. Additional information about the domain

The «description» attribute contains additional information about the domain name, e.g. a brief description of the resource properties, for example its content.

7.1.2. Description of EPP commands

Extensions to the EPP commands «create», «update» and the response to the EPP «info» command are provided for to operate an extended set of attributes to the domain object.

7.1.2.1. EPP «create» command

This extension determines additional elements for the command «create» described in RFC5731. Additional elements for the response to the command «create» are not determined.

The command «create» allows the customer to create a domain object. In addition to the elements of the command described in RFC5731, the command MUST contain the element «extension», which MUST comprise a child element «domain:create» which identifies the namespace and the location of the extensionʹs XML schema. The element «domain:create» contains the following child element:
- A single element «domain:description» containing an arbitrary comment.

7.1.2.2. EPP command «update»

This extension determines additional elements for the command «update» described in RFC5731. Additional elements for the response to the command «update» are not determined.

The EPP command «update» allows the customer to modify attributes to the contact object. In addition to the command elements described in RFC5731, the command MUST contain the element «extension», which MUST contain a child element «domain:update», which identifies the namespace and the location of the extensionʹs XML schema. The element «domain:update» contains the element «domain:chg», which contains the following child element:
- A single element «domain:description» containing an arbitrary comment.

7.1.2.3. EPP «info» Command

This extension does not add elements to the EPP «info» command described in RFC5731, but it does define additional elements for response.

Once the «info» command was successfully processed, the element «resData» MUST contain child elements described in RFC5731. Besides, the «extension» element MUST contain a child element «domain:infData» that identifies the namespace and the location of the extensionʹs XML schema. The «domain:infData» element contains the following child element:
- A single element «domain:description» containing an arbitrary comment.

7.1.3. Documentation

The documentation is written in RFC-like style, following the recommendations of RFC 3735, based on the template from RFC 5730 (Appendix A).

7.1.4. Formal Syntax

The extension formal syntax is described in the attachment Q25_XMLSchemaTCIDomain.

7.2. Extension for the EPP Contact Mapping

This mapping, an extension of the contact mapping described in RFC 5733.

7.2.1. Description of attributes

The extension adds new attributes to the contact object. In this section, each attribute is described in detail. For the attributes’ formal syntax see Section 7.2.5, ʺFormal Syntaxʺ.

7.2.1.1. Interface ʺPersonʺ

Interface ʺPersonʺ should be used where the registrant is a private individual. The «contact:person» element is employed for description.

(i) Individual Tax Identification Number
The attribute that contains the registrant’s individual taxpayer identification number has a string data type and has a fixed maximum length.

(ii) Date of birth
The attribute contains the registrant’s date of birth and is of the ʺdateʺ type.

(iii) Passport data
The attribute contains the registrant’s passport details and is of string type.

(iv) Information Disclosure Policy
The Registry defines the default disclosure policy. However, by using the «contact:disclose» element, the Registrar can determine those attributes of the contact which can be disclosed or hidden as an exception from the disclosure policy.

If the «contact:disclose» element has been determined, it MUST contain the attribute ʺflagʺ which takes a Boolean value. The value ʺtrueʺ or ʺ1ʺ means that the client authorizes disclosure of the said elements as an exception from the established policy, while the value ʺfalseʺ or ʺ0ʺ (decimal zero) means that disclosure is not permitted.

The «contact:disclose» element contains the following child elements:
- «contact:TIN⁄»;
- «contact:birthday»;
- «contact:passport».

7.2.1.2. Interface ʺOrganizationʺ

Interface ʺOrganizationʺ is used if the registrant is a corporation. Element «contact:org» is employed for description.

(i) Legal address

- The street, city, region
The description of the street, city and region is a string-type one and has a certain minimum and maximum length.

- Postal code
Postal code is a string-type presentation and has a certain minimum and maximum length.

- Country
The ISO3166-1 two-character code is used to identify the country.

(ii) Individual Taxpayer Identification Number

Attribute that contains the registrant’s individual taxpayer identification number is a string-type presentation and has a certain maximum length.

(iii) Disclosure Policy

The registry defines the disclosure policy by default. However, using the «contact:disclose» element, the Registrar can determine the attributes of the contact which may be disclosed or hidden as an exception from the disclosure policy.

If the «contact:disclose» element is determined, it MUST contain the attribute ʺflagʺ which takes a Boolean value. The ʺtrueʺ or ʺ1ʺ value means that the client authorizes disclosure of these elements as an exception from the established policy, while the value ʺfalseʺ or ʺ0ʺ (decimal zero) means that disclosure is not allowed.

Element «contact:disclose» contains the following child elements:
- «contact:legalAddr type=”int”»
- «contact:legalAddr type=”loc”»
- «contact:TIN⁄»

7.2.2. Description of EPP commands

7.2.2.1. EPP command «create»

This extension defines additional elements to the EPP command «create», as described in RFC5733. Additional elements to the respond to command «create» are not defined.

The EPP command «create» allows the client to create a contact object. In addition to the command elements described in RFC5731, the command MUST contain the element «extension», which MUST contain a child element «contact:create», which identifies the namespace and the location of the extensionʹs XML schema. Element «contact:create» contains child elements «contact:org» or «contact:person», depending on a type of the contact.

Element «contact:org» contains the following child elements:

(i) One or two «contact:legalAddr» elements containing the legal address. The reason for using two elements is that the postal address information can be presented in two forms, namely, the international and local ones; attribute ʺtypeʺ identifies one of the either formats. If the information is presented in the international format (type=ʺintʺ), then contents of the element HAS to be presented in the US-ASCII encoding. If the information is presented in the local format (type=ʺlocʺ), then contents of the element can be presented in the UTF-8 encoding. Element «contact:legalAddr» contains the following child elements:
- Element «contact:name» contains a particular name or the name of the registrant’s role.
- OPTIONAL element «contact:org» contains the name of the entity that the Registrar is affiliated with.
- Element «contact:addr» describes the Registrant’s address . Element «contact:addr» contains the following child elements:
a) One, two or three OPTIONAL «contact:street» elements containing the address of the Registrar.
b) Element «contact:city» contains the name of the city.
c) OPTIONAL element «contact:sp» contains the name of the region or area.
d) OPTIONAL element «contact:pc» contains the postal code.
e) Element «contact:cc» contains the code of the country of residence.
f) Element «contact:city» contains the name of the city.
g) OPTIONAL element «contact:sp» contains the name of the region or area.
h) OPTIONAL element «contact:pc» contains the postal code.
i) Element «contact:cc» contains the code of the country of residence.

(ii) Element «contact:TIN» contains the registrant’s TIN (Taxpayer Identification Number).

(iii) Element «contact:disclose» stands for the disclosure policy (par. 6.2.1.1.(iv))

Element «contact:person» contains the following child elements:
(i) Element «contact:TIN» the registrant’s TIN.
(ii) Element «contact:birthday» - registrantʹs date of birth.
(iii) Element «contact:passport» the registrant’s passport data.
(iv) Element «contact:disclose» stands for disclosure policy (par. 6.2.1.2.(iii)).

7.2.2.2. EPP command «update»

This extension defines additional elements to the command «update», as described in RFC5733. Additional elements to the respond to command «update» are not defined.

The EPP command «update» allows the customer to modify attributes to the contact object. In addition to the command elements described in RFC5731, the command MUST contain element «extension», which MUST contain a child element «contact:update» which identifies the namespace and the location of the extensionʹs XML schema. Element «contact:update» contains child element «contact:chg», which contains child elements «org» or «person», depending on the type of contact.

Element «contact:org» contains the following child elements:

- One or two OPTIONAL «contact:legalAddr» (described above).
- OPTIONAL element «contact:TIN» contains the registrant’s TIN (Taxpayer Identification Number).
- OPTIONAL element «contact:disclose» stands for the disclosure policy (par. 7.2.1.1.(iv)).

Element «contact:person» contains the following child elements:

- OPTIONAL element «contact:TIN» the registrant’s TIN.
- OPTIONAL element «contact:birthday» - registrant ʹs date of birth.
- OPTIONAL element «contact:passport» the registrant’s passport data.
- OPTIONAL element «contact:disclose» stands for disclosure policy (par. 7.2.1.2.(iii)).

7.2.2.3. EPP Command «info»

This extension does not add elements to the EPP «info» command, as described in RFC5731. But it does define additional elements to the response.

Upon successful processing of the EPP «info» command, element «resData» MUST contain child elements, as described in RFC5733. Additionally, element «extension» MUST contain a child element «contact:infData» that identifies the namespace and the location (location) of the extensionʹs XML schema. Element «contact:infData» contains child elements «org» or «person», depending on the type of contact.

Element «contact:org» contains the following child elements:
- One or two «contact:legalAddr» (described above)
- Element «contact:TIN» contains the registrant’s TIN (Taxpayer Identification Number).
- Element «contact:disclose» stands for the disclosure policy (par. 7.2.1.1.(iv))

Element «contact:person» contains the following child elements:
- Element «contact:TIN» the registrant’s TIN.
- Element «contact:birthday» -the registrantʹs date of birth.
- Element «contact:passport» the registrant’s passport data.
- Element «contact:disclose» stands for disclosure policy (par. 7.2.1.2.(iii)).

7.2.3. Documentation

The documentation has been drafted in the RFC-like style per the recommendations of RFC 3735 and basing on a template from RFC 5730 (Appendix A).

7.2.4. Formal Syntax

The extension formal syntax is described in the attachment Q25_XMLSchemaTCIContact.

Similar gTLD applications: (2)