25 Extensible Provisioning Protocol (EPP)

Prototypical answer:

EPP

As part of the SRS implementation .LAT registry will provide an EPP interface to registrars that fulfill the requirements to maintain objects within the LAT TLD. The EPP service is based in a long proved implementation by NIC México, currently in use for the .MX ccTLD. The EPP response messages currently support English and Spanish.

NIC Mexico’s implementation complies with all related RFC’s as required by the Applicant Guidebook and the Registry Agreement:

* RFC5730 Extensible Provisioning Protocol (EPP)
* RFC5731 Extensible Provisioning Protocol (EPP) Domain Name Mapping
* RFC5732 Extensible Provisioning Protocol (EPP) Host Mapping
* RFC5733 Extensible Provisioning Protocol (EPP) Contact Mapping
* RFC5734 Extensible Provisioning Protocol (EPP) Transport over TCP
* RFC5910 Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP) 
* RFC3915 Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP) 
* RFC3735 Guidelines for Extending the Extensible Provisioning Protocol (EPP) 

EXTENSIBLE PROVISIONING PROTOCOL IMPLEMENTATION

NIC Mexico’s EPP service is implemented over TCP transport, as it is the most widely used transport protocol. The technical staff has enough experience to work with the TCP transport having a long-time proved framework to implement any kind of service over the TCP transport.

SECURITY

Access to the EPP service is granted only to registrars that have signed the registrar agreement to operate with the .LAT TLD. Access is controlled in a multi-layered approach. The first level of security is a firewall whitelist where only allowed registrar’s IP addresses can establish a connection. The firewall is responsible for the TCP three way handshake and after it’s completed the connection is forwarded to the actual EPP backend server, this helps to mitigate the risk of TCP attacks like half-sync attacks. The registrar must use TLS with a certificate that will be issued by .LAT registry and that will be validated by the EPP LAT server. Once the TLS channel is in place, the registrar can send an EPP Login command with its username and password to open an EPP session.

In order to gain access to the EPP server, upon signing of the .LAT Registrar agreement, the registrars must send a CSR to the .LAT Registry to get a valid certificate to use on its EPP Client implementation. The CSR must be created using a rsa:1024 key to sign the certificate.

The .LAT EPP implementation is developed in house using JAVA as the programming language. The EPP XML formation and parsing libraries were developed in house and they will be made public to interested registrars of .LAT TLD.

.LAT REGISTRY EPP DATA COLLECTION POLICY

The .LAT Registry EPP privacy policy for data collection is described in the epp:greeting as shown in the following table:

Element Description
-------- ---------------------
Access ALL: Access is given to all identified data
Purpose ADMIN: Administrative purpose
CONTACT: Contact for market research only
OTHER: Other purposes
Recipient OURS: The data is processed by .LAT Registry
only for the completion of the stated purpose
Retention INDEFINITE: Data persists indefinitely.

Each registrar is allowed to have up to 10 concurrent connections by default. The LAT registry can allow more concurrent connections for a particular registrar after a justification from the registrar is reviewed and approved by the LAT registry.

After 10 failed authentication (origin IP address, TLS certificate, or username⁄password) attempts the registrar account is blocked and a manual procedure must be performed by LAT registry operators to unblock it. This is a security measure in case the registrar is compromised.

If the number of query commands or transformations commands per second is above a normal threshold the registry operators can choose to delay each response to the registrar. This is a security measure in case a registrar is being attacked and the attack is indirectly reaching the EPP system.

An established EPP TCP connection has a maximum time to live of 86400 seconds, after this TTL is reached the connection is closed by the EPP server. The connection timeout of the EPP TCP connection is 3600 seconds.

EPP COMMANDS

All EPP commands will be supported by the .LAT registry with exception of contact.delete, contact.transfer. Session Management, Query Commands and Transformation Commands will be implemented following the RFC5730. NIC Mexico’s implementation uses the message queue as defined by the EPP protocol as the principal mean to send information to registrars.

Following EPP standards all EPP commands are atomic (there is no partial success or partial failure) and designed so that they can be made idempotent (executing a command more than once has the same net effect on system state as successfully executing the command once). Also the responses to commands include response codes, along with response information, needed control or automate online and offline processes. The response also includes information of the EPP Service Message Queue.

EPP EXTENSIONS

NIC Mexico uses extension with its current clients. Although it is possible to register domain name without using the extensions, NIC Mexico encourages registrars to use them to fully interoperate with the SRS and take advantage of all its features.

Service Messages Extension: NIC Mexico’s implementation of the EPP protocol includes an extension to handle additional service message types. This is useful to send notifications to registrars related to both online and offline processes like any RPM related issues (UDRP, URS) or other notification related to other processes supported by the registry.

Domain extension for Administrative Status: This extension adds another piece of information to the domain:info command. The administrative status is introduced to track the domain status on special processes (mostly offline) that affect the visibility and manageability or of the domain name, for example a UDRP or URS process.

OBJECT MAPPING IMPLEMENTATION

NIC Mexico’s EPP implementation complies with the standards for the object mappings; nevertheless, NIC Mexico’s implementation enforces some additional business rules that may add slightly differences, especially in relation to mandatory data and supported operations. The following description of the EPP Registry Object Mappings describes only the additional verification included in NIC Mexico’s EPP implementation. Everything that is not mentioned will follow the corresponding RFC as –is.Domain Mapping

.LAT Registry will offer domain registration at the second level only, without any restrictions other than the ones described in the Applicant Guidebook and included in the Registry Agreement.

DOMAIN MAPPING: DOMAIN ATTRIBUTES

Additionally to domain object attributes included in RFC 5731 NIC Mexico defined an extension to include and Administrative Status, that as described above is used to track the domain status on special processes, mostly offline that affect the manageability and visibility of the domain name, for example a UDRP or URS process. The Administrative status can only be set by the Registry and will be included in the domain:info query command response. It will be discussed in detail in the corresponding extension specification.

The registrant and all domain contacts (admin, tech and billing) of a domain name are defined as mandatory in .LAT Registry implementation of the EPP domain mapping. The AuthInfo element is also mandatory.

.LAT Registry will implement a configurable limit for the host objects a domain name can be linked to. The current value is set to 5.

DOMAIN MAPPING: DOMAIN COMMANDS

Domain:check.

There is a configurable limit on the number of names that can be checked in the same command. The current value is set to 100.

Domain:info

The option to include an ROID attribute to specify that the authorization information provided corresponds to a contact object associated to the domain is not supported in the EPP implementation.

Domain:create

The attributes domain:registrant and domain:contact are mandatory in the implementation of EPP by NIC Mexico for .LAT Registry, then they must exist in the registry database prior to the creation of the domain name.

The registration period can be provided in months or years, but the period must be supported by the registry. Valid registration periods will be defined prior to launch but are expected to be complete years. The response to the domain:create command will include the optional element domain:exDate that contains the expiration date of the domain name that was created.

Domain:delete

If a domain object that has subordinated host objects is deleted, all existing links of the subordinated hosts with other domain objects will be removed and the subordinated host objects will also be deleted. All relations between internal hosts (.lat hosts) and .lat domain names are always complete by the previous rule. This enables the zone file generator to verify that all glue records included in the zone must also have its superordinate domain name also in the zone. In case contraire the glue records will be removed from the zone file.

Domain:renew

The response to the domain:renew command will include the updated expiration date of the domain name.

Domain:transfer

The domain:period attribute will not be supported. All transfers extend the domain name registration period by 1 year only. All subordinated host objects will be transferred altogether with the domain name. While the transfer operation is active, all involved objects will have a “pendingTransfer” status.

Information on a pending transfer will be available only to the registrars involved in the transfer. The exDate element is not included in the response to transfer query commands.

The option to include a ROID attribute to specify that the authorization information provided corresponds to a contact object associated to the domain object will not be supported in the .LAT EPP implementation.

Domain:update

There cannot be a domain name without a registrant so, to change the registrant contact it will be necessary to use the domain:chg element. In the same direction, the domain:authInfo element is mandatory for a domain name so, the .LAT registry will not allow to use the domain:null attribute to remove it.

To change any of the domain contacts it will be necessary to put the current contact in the 〈domain:rem〉 element of the command and the new one in the 〈domain:add〉 element. This will be validated by .LAT Registry.

HOST MAPPING

The EPP implementation will include host objects to handle delegation of domain names to be included in the zone files. Hosts that are internal to the .LAT registry will be created only by the sponsor of the superordinate domain name; in this way, internal host objects will be unique in the registry system but can be used by any registrar and can be linked to any domain name.

External hosts can be created by any registrar and will be unique to that registrar only. To simplify object relationships management every registrar can have his own copy of an external host object. Such hosts can be linked only to domain names sponsored by the registrar that created the external host.

If a domain name is not included in the zone file, neither will be their subordinated host objects (glue records).

HOST MAPPING: HOST COMMANDS

Host:check

There is a configurable limit on the number of names that can be checked in the same command. The current value is set to 100. The host:reason element will always be present in the response.

Host:create

Host objects store information of name servers. To create an internal host object the superordinate domain name object must exist in the registry database. The .LAT registry will not allow specifying IP addresses for external host objects.

Host:update

If a host:update command changes the name of an external host so it becomes an internal host and also a glue record, the required IP addresses must be added in the same command, or the command will fail. In the same sense, .LAT Registry implementation will not allow the complete removal of the IP addresses of an internal host object that is also a glue record.

If a host:update command changes the name of an internal host that is also a glue record so it becomes an external host, the existing IP addresses must be removed in the same command, or the command will fail.

Host:delete

The .LAT registry will not allow the deletion of a host object if it is linked to one or more domain objects. All links must be removed prior to the delete command. Nevertheless, if a domain object that has subordinate host objects is deleted then all links that the host objects could have will be removed automatically and the host objects will be deleted as well.

CONTACT MAPPING

The .LAT registry will use contact objects to store information of organizations and individuals that are related to domain names. Contact objects can be linked to domains as the registrant or administrative, technical or billing contact. .LAT Registry implementation will only support the localized postal info for contact objects.

CONTACT MAPPING: CONTACT COMMANDS

Contacts can be created and updated in the .LAT registry. Deletion and transfer will not be supported.

Contact:check

There is a configurable limit on the number of contacts that can be checked in the same command. The current value is set to 100. The contact:reason element will always be present in the response.

Contact:info

This command will return either of two information sets. A full information set will be returned for objects sponsored by the registrar that executes the command. A restricted information set will be showed for contacts sponsored by a different registrar. A non-sponsoring registrar can provide the contact:authInfo element within the command to get the full information set.

Contact:create

.LAT registry will only support contact:postalInfo of type=local. The address information will be mandatory. Also the contact disclose element will not be supported, even though .LAT registry could define a general policy for that matter in case necessary.

Contact:update

Mandatory information cannot be removed.

OTHER MAPPINGS.

DOMAIN REGISTRY GRACE PERIOD MAPPING

NIC Mexico’s EPP implementation will include the Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol. The implementation will follow RFC3915 and will include both the 〈rgp:restore〉 and 〈rgp:report〉 functionality to implement the domain recover functionality as described in the RFC3915 and also to comply with the Restored Names Accuracy Policy.

EPP EXTENSIONS

EPP ADMINISTRATIVE STATUS EXTENSION FOR .LAT REGISTRY

1. INTRODUCTION

The EPP protocol provides a complete description of EPP command and response structures. A thorough understanding of the base protocol specification is necessary to understand the mapping described in is document.

This document is written in consideration with the Guidelines for Extending the Extensible Provisioning Protocol as defined in [RFC3735].

This extension adds elements to the EPP 〈info〉 response, to allow LAT Registry show information about administrative statuses applied to a domain name.

2. OBJECT ATTRIBUTES

This extension adds additional elements to EPP domain object mapping described in [RFC5731]. Only new elements descriptions are described here.

2.1 Administrative Status

.LAT Registry introduces administrative status to EPP to track the domain status on special processes (mostly offline) that affect the manageability of the domain name, for example a UDRP or URS process, or an abuse complaint. The administrative status supported by .LAT registry is:

Status Description
--------------------------- ------------------------------------
suspendedByExternalAuthority The domain has been suspended on request
by an External Authority

suspendedByIllegalActivites The domain has been suspended because
of other Illegal Activities


3. EPP COMMAND MAPPING

A detailed description of the EPP syntax and semantics can be found in [RFC5730].

3.1. EPP Query Commands

This extension does not add any elements to the EPP 〈check〉, 〈poll〉 or 〈transfer〉 commands or responses.

3.1.2. EPP 〈info〉 Command

This extension does not add any elements to the EPP 〈info〉 command.

On the 〈info〉 response, if the queried domain is in a .LAT Registry Administrative status, the EPP 〈extension〉 element MUST contain a child 〈nicmx-as:adminStatus〉 element that identifies the administrative status for the domain name. The 〈nicmx-as:adminStatus〉 element contains the following child elements:

- A 〈nicmx-as:value〉 element that contains the current administrative status for the domain.
- A 〈nicmx-as:msg〉 element that contains the description of the administrative status. Contains an element 〈lang〉 that indicate the description language.


Example 〈info〉 response:

S:〈?xml version=ʺ1.0ʺ encoding=ʺISO-8859-1ʺ standalone=ʺnoʺ?〉
S:〈epp xmlns=ʺurn:ietf:params:xml:ns:epp-1.0ʺ〉
S: 〈response〉
S: 〈result code=ʺ1000ʺ〉
S: 〈msg lang=ʺenʺ〉Command completed successfully〈⁄msg〉
S: 〈⁄result〉
S: 〈msgQ count=ʺ10ʺ id=ʺ2659194ʺ⁄〉
S: 〈resData〉
S: 〈domain:infData xmlns:domain=ʺurn:ietf:params:xml:ns:domain-1.0ʺ〉
S: 〈domain:name〉example.mx〈⁄domain:name〉
S: 〈domain:roid〉DOMAIN_11235813213455-MX〈⁄domain:roid〉
S: 〈domain:status s=ʺclientTransferProhibitedʺ⁄〉
S: 〈domain:registrant〉conexample〈⁄domain:registrant〉
S: 〈domain:contact type=ʺadminʺ〉conexample〈⁄domain:contact〉
S: 〈domain:contact type=ʺbillingʺ〉conexample〈⁄domain:contact〉
S: 〈domain:contact type=ʺtechʺ〉conexample〈⁄domain:contact〉
S: 〈domain:ns〉
S: 〈domain:hostObj〉ns.example.com〈⁄domain:hostObj〉
S: 〈⁄domain:ns〉
S: 〈domain:clID〉rar_example〈⁄domain:clID〉
S: 〈domain:crID〉rar_example〈⁄domain:crID〉
S: 〈domain:crDate〉2008-05-15T22:00:49.0Z〈⁄domain:crDate〉
S: 〈domain:upID〉rar_example〈⁄domain:upID〉
S: 〈domain:upDate〉2011-05-20T15:47:57.0Z〈⁄domain:upDate〉
S: 〈domain:exDate〉2012-05-14T05:00:00.0Z〈⁄domain:exDate〉
S: 〈domain:authInfo〉
S: 〈domain:pw〉*****〈⁄domain:pw〉
S: 〈⁄domain:authInfo〉
S: 〈⁄domain:infData〉
S: 〈⁄resData〉
S: 〈extension〉
S: 〈nicmx-as:adminStatus
S: xmlns:nicmx-as=ʺhttp:⁄⁄www.nic.mx⁄nicmx-admstatus-1.0ʺ〉
S: 〈nicmx-as:value〉suspendedByIllegalActivites〈⁄nicmx-as:value〉
S: 〈nicmx-as:msg lang=ʺenʺ〉The domain has been suspended because other Illegal Activities〈⁄nicmx-as:msg〉
S: 〈⁄nicmx-as:adminStatus〉
S: 〈⁄extension〉
S: 〈trID〉
S: 〈clTRID〉EXAMPLE-011235813〈⁄clTRID〉
S: 〈svTRID〉21345589144〈⁄svTRID〉
S: 〈⁄trID〉
S: 〈⁄response〉
S:〈⁄epp〉


3.2. EPP Transform Commands

This extension does not add any elements to the EPP 〈create〉, 〈delete〉, 〈renew〉, 〈update〉 nor 〈transfer〉 commands or responses.

4. FORMAL SYNTAX

An EPP object mapping is specified in XML Schema notation. The formal syntax presented here is a complete schema representation of the object mapping suitable for automated validation of EPP XML instances.

〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ?〉

〈schema targetNamespace=ʺhttp:⁄⁄www.nic.mx⁄nicmx-admstatus-1.0ʺ
xmlns:nicmx-msg=ʺhttp:⁄⁄www.nic.mx⁄nicmx-admstatus-1.0ʺ
xmlns:epp=ʺurn:ietf:params:xml:ns:epp-1.0ʺ
xmlns:eppcom=ʺurn:ietf:params:xml:ns:eppcom-1.0ʺ
xmlns=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchemaʺ
elementFormDefault=ʺqualifiedʺ〉

〈!--
Import common element types.
--〉
〈import namespace=ʺurn:ietf:params:xml:ns:eppcom-1.0ʺ
schemaLocation=ʺeppcom-1.0.xsdʺ ⁄〉
〈import namespace=ʺurn:ietf:params:xml:ns:epp-1.0ʺ
schemaLocation=ʺepp-1.0.xsdʺ ⁄〉

〈annotation〉
〈documentation〉
Extensible Provisioning Protocol v1.0
NIC-MX Administrative Status Extension Schema v1.0
〈⁄documentation〉
〈⁄annotation〉

〈!--
Child element found in 〈extension〉 tag
--〉
〈element name=ʺnicmxʺ type=ʺnicmx-as:adminStatusTypeʺ ⁄〉

〈!--
Child Elements of nicmxAsType
--〉
〈complexType name=ʺadminStatusTypeʺ〉
〈sequence〉
〈element name=ʺvalueʺ type=ʺnicmx-as:adminStatusCodeTypeʺ⁄〉
〈element name=ʺmsgʺ type=ʺepp:msgTypeʺ minOccurs=ʺ0ʺ ⁄〉
〈⁄sequence〉
〈⁄complexType〉

〈simpleType name=ʺadminStatusCodeTypeʺ〉
〈restriction base=ʺtokenʺ〉
〈enumeration value=ʺsuspendedByExternalAuthorityʺ ⁄〉
〈enumeration value=ʺsuspendedByIllegalActivitesʺ ⁄〉
〈⁄restriction〉
〈⁄simpleType〉


〈!--
END of schema
--〉
〈⁄schema〉


SERVICE MESSAGE EXTENSION FOR LAT REGISTRY

1. INTRODUCTION

The EPP protocol provides a complete description of EPP command and response structures. A thorough understanding of the base protocol specification is necessary to understand the mapping described in is document.

This document is written in consideration with the Guidelines for Extending the Extensible Provisioning Protocol as defined in [RFC3735].

This extension adds new elements to the EPP 〈poll〉 request response, to allow .LAT Registry to send additional information in the service messages not specified in the EPP standard.

2 OBJECT ATTRIBUTES

This extension adds additional elements to EPP mapping described in [RFC5730]. Only new elements descriptions are described here.

2.1 Message Type

The message type element is used to provide additional information in the service messages. This type contains the message type identifier, the domain name related to the message and dates related with the message. Valid values for message type identifiers are defined by the EPP implementation.

msgTypeID Description
----------------- -------------------------------------
5 Domain delete notification
6 Domain auto-renew notification
9 Domain suspension by External Authority notification
11 Domain suspension by External Authority release notification
13 Domain delete redemption period notification
14 Domain restauration notification
15 Domain update by associated host deletion notification


3. EPP COMMAND MAPPING

A detailed description of the EPP syntax and semantics can be found in [RFC5730].

3.1. EPP Query Commands

This extension does not add any elements to the EPP 〈check〉, 〈info〉 or 〈transfer〉 commands nor responses.

3.1.1. EPP 〈poll〉 Command

This extension does not add any elements to the EPP 〈poll〉 command.

On the 〈poll〉 request response, if the message retrieved contains additional information from the .LAT Registry then the server MUST include a 〈extension〉 element in the EPP response with a child 〈nicmx-msg〉 element that identifies the additional information from .LAT Registry. The 〈nicmx-msg〉 element contains the following child elements:

- A 〈msgTypeID〉 element that contains the message type identifier.
- A 〈object〉 element that identified the object related to the message.
- A 〈msDate〉 element that contains the date of the action that triggered the message.
- An OPTIONAL 〈exDate〉 element that contains the expiration date from the domain included in this message.

Example 〈poll〉 request response:

S:〈?xml version=ʺ1.0ʺ encoding=ʺISO-8859-1ʺ standalone=ʺnoʺ?〉
S:〈epp xmlns=ʺurn:ietf:params:xml:ns:epp-1.0ʺ〉
S: 〈response〉
S: 〈result code=ʺ1301ʺ〉
S: 〈msg lang=ʺenʺ〉Command completed successfully; ack to dequeue〈⁄msg〉
S: 〈⁄result〉
S: 〈msgQ count=ʺ6ʺ id=ʺ3053565ʺ〉
S: 〈qDate〉2012-04-07T04:00:04.0Z〈⁄qDate〉
S: 〈msg lang=ʺenʺ〉Domain has been deleted〈⁄msg〉
S: 〈⁄msgQ〉
S: 〈extension〉
S: 〈nicmx-msg:nicmx xmlns:nicmx-msg=ʺhttp:⁄⁄www.nic.mx⁄nicmx-msg-1.0ʺ〉
S: 〈nicmx-msg:msgTypeID〉5〈⁄nicmx-msg:msgTypeID〉
S: 〈nicmx-msg:object〉example.mx〈⁄nicmx-msg:object〉
S: 〈nicmx-msg:msDate〉2012-04-07T04:00:04.0Z〈⁄nicmx-msg:msDate〉
S: 〈⁄nicmx-msg:nicmx〉
S: 〈⁄extension〉
S: 〈trID〉
S: 〈clTRID〉EXAMPLE-011235813〈⁄clTRID〉
S: 〈svTRID〉21345589144〈⁄svTRID〉
S: 〈⁄trID〉
S: 〈⁄response〉
S:〈⁄epp〉

3.2. EPP Transform Commands

This extension does not add any elements to the EPP 〈create〉, 〈delete〉, 〈renew〉, 〈update〉 nor 〈transfer〉 commands or responses.

4. FORMAL SYNTAX

An EPP object mapping is specified in XML Schema notation. The formal syntax presented here is a complete schema representation of the object mapping suitable for automated validation of EPP XML instances.

〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ?〉
〈schema targetNamespace=ʺhttp:⁄⁄www.nic.mx⁄nicmx-msg-1.0ʺ
xmlns:nicmx-msg=ʺhttp:⁄⁄www.nic.mx⁄nicmx-msg-1.0ʺ
xmlns:epp=ʺurn:ietf:params:xml:ns:epp-1.0ʺ
xmlns:eppcom=ʺurn:ietf:params:xml:ns:eppcom-1.0ʺ
xmlns=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchemaʺ
elementFormDefault=ʺqualifiedʺ〉

〈!--
Import common element types.
--〉
〈import namespace=ʺurn:ietf:params:xml:ns:eppcom-1.0ʺ
schemaLocation=ʺeppcom-1.0.xsdʺ ⁄〉
〈import namespace=ʺurn:ietf:params:xml:ns:epp-1.0ʺ
schemaLocation=ʺepp-1.0.xsdʺ ⁄〉

〈annotation〉
〈documentation〉
Extensible Provisioning Protocol v1.0
NIC- MX Messages Extension Schema v1.0
〈⁄documentation〉
〈⁄annotation〉

〈!--
Child element found in 〈extension〉 tag
--〉
〈element name=ʺnicmxʺ type=ʺnicmx-msg:nicmxTypeʺ ⁄〉

〈!--
Child Element of nicmxMsgType
--〉
〈complexType name=ʺnicmxTypeʺ〉
〈sequence〉
〈element name=ʺmsgTypeIDʺ type=ʺunsignedShortʺ ⁄〉
〈element name=ʺobjectʺ type=ʺeppcom:labelTypeʺ ⁄〉
〈element name=ʺmsDateʺ type=ʺdateTimeʺ ⁄〉
〈element name=ʺexDateʺ type=ʺdateTimeʺ minOccurs=ʺ0ʺ ⁄〉
〈⁄sequence〉
〈⁄complexType〉

〈!--
END of schema
--〉
〈⁄schema〉

Similar gTLD applications: (0)